feat: add Jungian Intelligence Layer service v3.2.0#7
Conversation
Add JungianService with 5 methods: searchWithContext, getIndividuationScore, getIndividuationHistory, getSynchronicityPatterns, getDreamHistory. Includes new types for archetypes, individuation, synchronicity, and dream consolidation.
Reviewer's GuideAdds a new JungianService to the SDK, wires it into the main client and package exports, and defines the associated Jungian Intelligence TypeScript types for individuation, archetypal search, synchronicity patterns, and dream history responses. Sequence diagram for client.jungian.getDreamHistory callsequenceDiagram
actor Developer
participant PluggedInClient
participant JungianService
participant AxiosInstance
participant PluggedInAPI
Developer->>PluggedInClient: new PluggedInClient(config)
PluggedInClient->>PluggedInClient: createAxiosInstance()
PluggedInClient->>JungianService: new JungianService(axios, config)
PluggedInClient->>JungianService: jungian.getDreamHistory()
JungianService->>AxiosInstance: get(/api/memory/dream/history)
AxiosInstance->>PluggedInAPI: HTTP GET /api/memory/dream/history
PluggedInAPI-->>AxiosInstance: 200 OK DreamConsolidation[]
AxiosInstance-->>JungianService: data: DreamConsolidation[]
JungianService-->>PluggedInClient: Promise(DreamConsolidation[])
PluggedInClient-->>Developer: DreamConsolidation[]
Class diagram for JungianService and Jungian Intelligence typesclassDiagram
class PluggedInClient {
- AxiosInstance axios
- Required_ClientConfig_ config
+ PluggedInClient(config: ClientConfig)
+ jungian: JungianService
}
class JungianService {
- AxiosInstance axios
- Required_ClientConfig_ config
+ JungianService(axios: AxiosInstance, config: Required_ClientConfig_)
+ searchWithContext(query: string, toolName: string, outcome: string, includeArchetypes: boolean): Promise~ArchetypeSearchResponse~
+ getIndividuationScore(): Promise~IndividuationResponse~
+ getIndividuationHistory(days: number): Promise~IndividuationResponse[]~
+ getSynchronicityPatterns(): Promise~SynchronicityPattern[]~
+ getDreamHistory(): Promise~DreamConsolidation[]~
}
class IndividuationResponse {
+ total: number
+ level: string
+ weeklyTrend: string
+ tip: string
+ components_memoryDepth: number
+ components_learningVelocity: number
+ components_collectiveContribution: number
+ components_selfAwareness: number
}
class ArchetypedPattern {
+ uuid: string
+ archetype: string
+ archetypeLabel: string
+ archetypeWeight: number
+ patternType: string
+ description: string
+ pattern: string
+ confidence: number
+ similarity: number
}
class ArchetypeSearchResponse {
+ patterns: ArchetypedPattern[]
}
class SynchronicityPattern {
+ uuid: string
+ patternType: string
+ description: string
+ confidence: number
+ uniqueProfiles: number
}
class DreamConsolidation {
+ uuid: string
+ sourceCount: number
+ tokenSavings: number
+ clusterSimilarity: number
+ createdAt: string
}
PluggedInClient --> JungianService
JungianService --> IndividuationResponse
JungianService --> ArchetypeSearchResponse
JungianService --> SynchronicityPattern
JungianService --> DreamConsolidation
ArchetypeSearchResponse --> ArchetypedPattern
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces the Jungian Intelligence Layer service, significantly expanding the client's capabilities. It provides a new set of advanced psychological and analytical tools, allowing users to interact with features such as archetype-contextualized memory search, individuation score tracking, synchronicity pattern analysis, and dream history retrieval, all accessible through a dedicated Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- The
includeArchetypesparameter insearchWithContextis accepted in the method signature but never sent to the API; either wire it into the request body/query or remove it from the public interface to avoid confusion. - The
config: Required<ClientConfig>constructor parameter inJungianServiceis currently unused; consider either removing it or leveraging it (e.g., for base URL or headers) to avoid dead code. - In
getIndividuationHistory, thedaysargument is always included inparamseven whenundefined; consider building theparamsobject conditionally so you don’t senddays: undefinedto the API.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `includeArchetypes` parameter in `searchWithContext` is accepted in the method signature but never sent to the API; either wire it into the request body/query or remove it from the public interface to avoid confusion.
- The `config: Required<ClientConfig>` constructor parameter in `JungianService` is currently unused; consider either removing it or leveraging it (e.g., for base URL or headers) to avoid dead code.
- In `getIndividuationHistory`, the `days` argument is always included in `params` even when `undefined`; consider building the `params` object conditionally so you don’t send `days: undefined` to the API.
## Individual Comments
### Comment 1
<location path="src/services/jungian.ts" line_range="19-23" />
<code_context>
+ /**
+ * Search memory with archetype context injection
+ */
+ async searchWithContext(params: {
+ query: string;
+ toolName?: string;
+ outcome?: string;
+ includeArchetypes?: boolean;
+ }): Promise<ArchetypeSearchResponse> {
+ const { data } = await this.axios.post('/api/memory/archetype/inject', {
</code_context>
<issue_to_address>
**issue (bug_risk):** `includeArchetypes` parameter is unused in the request
This flag is accepted in `searchWithContext` but never included in the request to `/api/memory/archetype/inject`. If the backend supports controlling archetype inclusion, this is a functional gap; if not, the parameter should be removed to avoid a misleading API surface.
</issue_to_address>
### Comment 2
<location path="src/services/jungian.ts" line_range="11-13" />
<code_context>
+} from '../types';
+
+export class JungianService {
+ constructor(
+ private axios: AxiosInstance,
+ private config: Required<ClientConfig>
+ ) {}
+
</code_context>
<issue_to_address>
**suggestion:** `config` is stored but never used in `JungianService`
`config` is stored but never read. If it isn’t needed (e.g., for base URL or headers), remove it from the constructor and class to avoid dead state and lint warnings. If it will be needed later, consider wiring it into at least one code path now (e.g., via a helper) so it isn’t effectively unused.
Suggested implementation:
```typescript
export class JungianService {
constructor(private axios: AxiosInstance) {}
```
Anywhere `JungianService` is instantiated, update the constructor calls to pass only the `AxiosInstance` and remove the `config` argument, e.g. change `new JungianService(axios, config)` to `new JungianService(axios)`. If any fields or methods in this file referenced `this.config`, those references should also be removed or refactored accordingly.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| async searchWithContext(params: { | ||
| query: string; | ||
| toolName?: string; | ||
| outcome?: string; | ||
| includeArchetypes?: boolean; |
There was a problem hiding this comment.
issue (bug_risk): includeArchetypes parameter is unused in the request
This flag is accepted in searchWithContext but never included in the request to /api/memory/archetype/inject. If the backend supports controlling archetype inclusion, this is a functional gap; if not, the parameter should be removed to avoid a misleading API surface.
| constructor( | ||
| private axios: AxiosInstance, | ||
| private config: Required<ClientConfig> |
There was a problem hiding this comment.
suggestion: config is stored but never used in JungianService
config is stored but never read. If it isn’t needed (e.g., for base URL or headers), remove it from the constructor and class to avoid dead state and lint warnings. If it will be needed later, consider wiring it into at least one code path now (e.g., via a helper) so it isn’t effectively unused.
Suggested implementation:
export class JungianService {
constructor(private axios: AxiosInstance) {}Anywhere JungianService is instantiated, update the constructor calls to pass only the AxiosInstance and remove the config argument, e.g. change new JungianService(axios, config) to new JungianService(axios). If any fields or methods in this file referenced this.config, those references should also be removed or refactored accordingly.
PR Review: feat: add Jungian Intelligence Layer service v3.2.0Overall the structure is clean and consistent with the existing service pattern. A few issues need attention before merging. Bugs
The async searchWithContext(params: {
query: string;
toolName?: string;
outcome?: string;
includeArchetypes?: boolean; // declared...
}): Promise<ArchetypeSearchResponse> {
const { data } = await this.axios.post('/api/memory/archetype/inject', {
query: params.query,
tool_name: params.toolName,
outcome: params.outcome,
// ...but never sent!
});Either remove it from the interface or forward it: Type SafetyMissing generic type parameters on axios calls ( Every other service in this codebase passes a type argument to axios, e.g. from const response = await this.axios.get<Agent[]>('/api/agents');
return response.data;
// current — data is `any`
const { data } = await this.axios.post('/api/memory/archetype/inject', ...);
return data;
// should be
const { data } = await this.axios.post<ArchetypeSearchResponse>('/api/memory/archetype/inject', ...);
return data;Apply this to all five methods for consistency and compile-time safety. Missing TestsThere is no test file for
Minor
Every other type in the codebase uses noun form: Unused
Summary
The integration wiring ( |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new JungianService to the SDK, exposing several new methods for interacting with a Jungian intelligence layer. The changes include adding the new service, defining its associated types, and integrating it into the main client. My review found a bug where a parameter in searchWithContext was not being used, and an inconsistency in date type handling in getDreamHistory compared to the rest of the SDK. I've provided suggestions to fix these issues.
| query: params.query, | ||
| tool_name: params.toolName, | ||
| outcome: params.outcome, |
There was a problem hiding this comment.
The includeArchetypes parameter is defined in the method signature but is not being passed to the API. This means the feature to include archetypes in the search context is not functional. The API likely expects this parameter as include_archetypes.
query: params.query,
tool_name: params.toolName,
outcome: params.outcome,
include_archetypes: params.includeArchetypes| const { data } = await this.axios.get('/api/memory/dream/history'); | ||
| return data; |
There was a problem hiding this comment.
To align with the recommended change in the DreamConsolidation interface (changing createdAt to a Date type), this method should transform the string date received from the API into a Date object.
const { data } = await this.axios.get('/api/memory/dream/history');
return (data as any[]).map((d) => ({ ...d, createdAt: new Date(d.createdAt) }));| sourceCount: number; | ||
| tokenSavings: number; | ||
| clusterSimilarity: number; | ||
| createdAt: string; |
There was a problem hiding this comment.
For consistency across the SDK, timestamp fields should use the Date type instead of string. Other interfaces like Document and ClipboardEntry already follow this pattern. This provides a more consistent and developer-friendly API.
| createdAt: string; | |
| createdAt: Date; |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| includeArchetypes?: boolean; | ||
| }): Promise<ArchetypeSearchResponse> { | ||
| const { data } = await this.axios.post('/api/memory/archetype/inject', { | ||
| query: params.query, | ||
| tool_name: params.toolName, | ||
| outcome: params.outcome, | ||
| }); |
There was a problem hiding this comment.
Bug: The includeArchetypes parameter in the searchWithContext method is defined but is never used in the API request, so it has no effect.
Severity: MEDIUM
Suggested Fix
Update the searchWithContext method to include the includeArchetypes parameter in the data payload of the axios.post call. This will ensure the backend API receives the parameter and can modify its response accordingly, aligning its behavior with the function's signature.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: src/services/jungian.ts#L23-L29
Potential issue: The `searchWithContext` method in `JungianService` defines an optional
boolean parameter `includeArchetypes`. However, this parameter is never actually used in
the body of the `axios.post` request sent to the API. Only the `query`, `tool_name`, and
`outcome` fields are passed. This is inconsistent with other services in the codebase
where optional parameters are explicitly included in API calls. Consequently, callers
who set `includeArchetypes` to `true` or `false` will find the parameter is silently
ignored, and the API's behavior will not change as expected.
Did we get this right? 👍 / 👎 to inform future reviews.
1 participant
Summary
JungianServiceclass exposed asclient.jungian.*searchWithContext(),getIndividuationScore(),getIndividuationHistory(),getSynchronicityPatterns(),getDreamHistory()Test plan
npm run buildto verify compilationSummary by Sourcery
Add a new Jungian intelligence service to the client SDK for accessing archetype-aware memory and individuation insights.
New Features: