Add Jev-first context and ultra-fast semantic search - #1
codejunkie99 wants to merge 2 commits into
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Macroscope skipped reviewing this pull request. Per-review cost limit exceeded (workspace setting). This review would cost an estimated $33.16, which exceeds your per-review limit of $10.00. The top 3 files driving up this estimate:
Tip To get this pull request reviewed, you can:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f1a5ac6a06
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| rows = list(unique.values()) | ||
| result['coverage'].update(candidateCount=len(rows), omittedCount=max(0, len(rows) - max_items), hasMore=has_more, candidateLimit=max_items) | ||
| bounded = [] | ||
| for row in rows[:max_items]: |
There was a problem hiding this comment.
When an update request contains enough explicit targets and incoming replacements to exceed max_items—the validator permits up to 16 of each—this slice keeps the targets first and silently drops the incoming items. The resulting partial plan remains applicable, so applying a 16-target/16-replacement update can retract all 16 existing claims while remembering none of their replacements. Ensure all authorized update items are evaluated together, or make any plan that omits one of them non-applicable.
Useful? React with 👍 / 👎.
| if self.topic: | ||
| rows = [r for r in rows if self.topic in r.get('topics', [])] |
There was a problem hiding this comment.
When a topic is selected, this filter removes every conversation and approved source because those rows have no topics field. A project conversation search can therefore return no conversation evidence even when matching conversations exist. Filter only source types with topic labels, or define how conversations and approved sources should participate.
Prompt To Fix With AI
This is a comment left during a code review.
Path: harness_manager/workspaces/memory_sources.py
Line: 115-116
Comment:
**Topics remove conversation results**
When a topic is selected, this filter removes every conversation and approved source because those rows have no `topics` field. A project conversation search can therefore return no conversation evidence even when matching conversations exist. Filter only source types with topic labels, or define how conversations and approved sources should participate.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
| workspace = references.store.get('workspace', wid) | ||
| path = workspace.get('projectPath') | ||
| row = next((r for r in references._live() if r['id'] == identifier and path and r.get('projectPath') == path), None) | ||
| row = next((r for r in getattr(references, '_cache', []) if r['id'] == identifier and path and r.get('projectPath') == path), None) |
There was a problem hiding this comment.
A pinned live conversation now resolves only from the in-memory chat inventory. After a service restart, that inventory is empty until someone searches or attaches a live conversation. context.prepare therefore reports an existing pinned conversation as unavailable and omits its evidence. Ordinary Local context runs also silently omit external conversations when no prior search has populated the inventory.
Prompt To Fix With AI
This is a comment left during a code review.
Path: harness_manager/workspaces/context_packs.py
Line: 143
Comment:
**Pinned conversations disappear after restart**
A pinned live conversation now resolves only from the in-memory chat inventory. After a service restart, that inventory is empty until someone searches or attaches a live conversation. `context.prepare` therefore reports an existing pinned conversation as unavailable and omits its evidence. Ordinary Local context runs also silently omit external conversations when no prior search has populated the inventory.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.| # must not enumerate a personal history store before it can reach the runner. | ||
| inventory = references._live() if discover else list(getattr(references, '_cache', [])) | ||
| live = [r for r in inventory if path and r.get('projectPath') == path | ||
| and (discover or r['id'].startswith(('live:codex-session:', 'live:claude-session:', 'live:cursor-session:')))] |
There was a problem hiding this comment.
When Local context builds candidates from discovered conversations, this filter accepts Codex, Claude and Cursor IDs but excludes OpenCode IDs. A relevant OpenCode conversation cannot be selected automatically, even when it is already in the chat inventory.
Prompt To Fix With AI
This is a comment left during a code review.
Path: harness_manager/workspaces/context_packs.py
Line: 114
Comment:
**Local context drops OpenCode conversations**
When Local context builds candidates from discovered conversations, this filter accepts Codex, Claude and Cursor IDs but excludes OpenCode IDs. A relevant OpenCode conversation cannot be selected automatically, even when it is already in the chat inventory.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
Project context and Command-K content search now share one Jev planner. Eligible source excerpts receive typed semantic decisions in a bounded batch; selected evidence reaches the context pack with its exact provenance.
Ultra-fast Jev search/context uses up to eight candidates and 17 questions, with a versioned read-only cache. Search displays measured app request time, logical provider-call count, cache status, and exact source previews. Standard Jev and explicit Local search remain available for their supported scopes.
Settings now supports adding or replacing the TypeSafe key later, and disconnecting it. Jev search/context choices are hidden until this host has a configured key, enablement and hosted-processing consent; saved Jev choices show unavailable if setup disappears. Local search stays usable. Implicit backend runs preserve approved source bodies when Jev is unconfigured, and automatic Local retrieval avoids scanning external chat history.
The backend also provides reviewed atomic remember/forget/update, read-only MCP planning, extractive trace compaction, complete skill loading, validated tool proposals, citation-support assessment and bounded semantic code search. Incomplete updates cannot apply; hosted input receives credential screening; stale import previews can refresh. Hosted response validation accounts for hosted probability rounding without weakening typed or authorization checks.
Validation: 570 Python tests plus four subtests; native state checks; Swift release build; actual native provider setup and missing-key state inspection; bundled-Python RPC/MCP and fast-cache checks; ZIP/DMG integrity and strict extracted-app signatures.
Live demo through the installed bundled backend: three synthetic memories, one seven-question hosted batch, correct SQLite memory selected in 392.99 ms; identical cached search in 10.05 ms with zero new provider calls. These are measured backend request timings for a small synthetic example, not a general retrieval-quality benchmark or end-to-end UI latency claim. No credentials or real user memories are included in the PR.
Note
Add Jev-first context planning and ultra-fast semantic search
jevthe default context mode.ContextPacksroutes jev/jev-fast requests through a new planner (context_packs.py, jev_context.py), andWorkspaceServicerecords ledger receipts for context packs and handoffs (service.py).search.context— a bounded, cached, read-only Jev search over project memory and conversations (jev_retrieval.py, jev_runtime.py) — with fast/standard limits and coverage metadata. The macOS Spotlight search UI exposes Local/Jev modes, grouped results, and Jev previews (SpotlightSearchView.swift).plan_contextand five runtime tools (context_mcp.py).Palette/StackTypeand reusable components in DesignSystem.swift), a new sidebar, a Jev project-memory screen, and an imported-memory migration view.contextOptionsno longer defaults tolocal— new requests default tojevmode, andlocalis forced only when the provider is unavailable. Jev modes get a 5-second serialized timeout vs 20 for others. Local mode no longer performs conversation discovery. See docs/jev-first-context.md and docs/jev-provider-setup.md.Macroscope summarized 31e0778.
The PR does not appear safe to merge until Local context reliably retains available project conversations.
Fix with agent prompt
Summary
The PR adds Jev-backed context planning and semantic search, reviewed memory operations, provider setup, and native search and memory views. The latest revision adds provider-aware Local defaults, tighter credential screening, and complete-update checks. Local conversation retrieval now depends on a pre-populated inventory and excludes OpenCode from automatic selection.
Diagram
%%{init: {'theme': 'neutral'}}%% flowchart LR Run[Run or context request] --> Mode{Retrieval mode} Mode -->|Jev| Planner[Jev planner] Mode -->|Local| Cache[Cached chat inventory] Cache --> Selection[Bounded context selection] Planner --> Selection Selection --> Pack[Context pack]Reviews (2) · Last reviewed commit: "Gate Jev on provider setup and validate ..."