Two items in the v1 scope list are single bullet points with no design in the document and no foundation in the repository. Both are load bearing for the pitch.
1. The @codebase context engine.
The chat and inline-edit surfaces with @codebase retrieval through the local context engine.
The definite article implies the engine was described earlier. It is not described anywhere in the document. Searching the repo for indexing, chunking, embedding or retrieval code turns up nothing: src/rust_backend/src/ has LSP, DAP, event bus, plugin manager, task runner, updater, workspace, config, permissions, plus diff, emmet, encoding, blame, test and session engines, and no retrieval layer. The Rust dependency list has no embedding or vector store crate.
The whitepaper itself identifies this as the hard part:
The context engine and the agent loop are the hard parts
and then gives the context engine one clause of v1 scope. This is the piece most likely to blow the schedule. Some of the questions it needs answered: is retrieval lexical (ripgrep style, symbol aware via the LSP client that already exists) or semantic (embeddings, which means an embedding model, a vector index, and an incremental reindex story on a codebase that changes under you)? Does it reuse the LSP workspace symbol index the project already has, which would be a genuinely distinctive local first answer and much cheaper than embeddings? What is the story for a repository too large to index on a laptop that is also running a completion model?
A defensible v1 answer might be: lexical and symbol aware retrieval built on the existing LSP and project search, with semantic retrieval as a future idea. That is smaller, honest, plays to what the repo already has, and would not need an embedding model on a machine already running one model. But whichever way it goes, it needs its own section rather than a bullet.
2. The egress log.
The egress log, local and readable, marking every request as local or remote with its destination.
Also absent from the repo, also one bullet. This one is the concrete proof behind the privacy principle, so it is the bullet a sceptical reader will check first:
the editor can prove this because the provider call is a localhost request the user can observe
The asset the document is not using. src/rust_backend/src/permission.rs implements a permission manager keyed by plugin ID with a bitmask that includes Network = 2, FileSystem = 1 and Process = 4. The AI completion plugin already declares "permissions": ["network.access"] in its manifest. That is exactly the chokepoint the egress log needs, and the whitepaper never mentions any of it.
Today the completion plugin talks straight to QNetworkAccessManager in the Qt layer, so the permission declaration is documentation rather than enforcement. Routing AI network calls through a permission checked path in the Rust backend would turn the privacy claim into architecture: one place where every outbound request is authorised, one place where it is logged, and a plugin model where a third party plugin cannot quietly phone home. "Prove, not promise" needs a mechanism, and the project already has most of one.
Suggested fix: give the context engine its own section with a v1 decision on lexical versus semantic, and describe the egress log as a property of the permission checked network path rather than as a standalone feature. If either turns out to be too big for v1, cutting it explicitly is better than carrying it as a bullet, and the "What it is not" section is the right place to say so.
Two items in the v1 scope list are single bullet points with no design in the document and no foundation in the repository. Both are load bearing for the pitch.
1. The
@codebasecontext engine.The definite article implies the engine was described earlier. It is not described anywhere in the document. Searching the repo for indexing, chunking, embedding or retrieval code turns up nothing:
src/rust_backend/src/has LSP, DAP, event bus, plugin manager, task runner, updater, workspace, config, permissions, plus diff, emmet, encoding, blame, test and session engines, and no retrieval layer. The Rust dependency list has no embedding or vector store crate.The whitepaper itself identifies this as the hard part:
and then gives the context engine one clause of v1 scope. This is the piece most likely to blow the schedule. Some of the questions it needs answered: is retrieval lexical (ripgrep style, symbol aware via the LSP client that already exists) or semantic (embeddings, which means an embedding model, a vector index, and an incremental reindex story on a codebase that changes under you)? Does it reuse the LSP workspace symbol index the project already has, which would be a genuinely distinctive local first answer and much cheaper than embeddings? What is the story for a repository too large to index on a laptop that is also running a completion model?
A defensible v1 answer might be: lexical and symbol aware retrieval built on the existing LSP and project search, with semantic retrieval as a future idea. That is smaller, honest, plays to what the repo already has, and would not need an embedding model on a machine already running one model. But whichever way it goes, it needs its own section rather than a bullet.
2. The egress log.
Also absent from the repo, also one bullet. This one is the concrete proof behind the privacy principle, so it is the bullet a sceptical reader will check first:
The asset the document is not using.
src/rust_backend/src/permission.rsimplements a permission manager keyed by plugin ID with a bitmask that includesNetwork = 2,FileSystem = 1andProcess = 4. The AI completion plugin already declares"permissions": ["network.access"]in its manifest. That is exactly the chokepoint the egress log needs, and the whitepaper never mentions any of it.Today the completion plugin talks straight to
QNetworkAccessManagerin the Qt layer, so the permission declaration is documentation rather than enforcement. Routing AI network calls through a permission checked path in the Rust backend would turn the privacy claim into architecture: one place where every outbound request is authorised, one place where it is logged, and a plugin model where a third party plugin cannot quietly phone home. "Prove, not promise" needs a mechanism, and the project already has most of one.Suggested fix: give the context engine its own section with a v1 decision on lexical versus semantic, and describe the egress log as a property of the permission checked network path rather than as a standalone feature. If either turns out to be too big for v1, cutting it explicitly is better than carrying it as a bullet, and the "What it is not" section is the right place to say so.