The Architecture section is the shortest in the document at three sentences, and it is the section carrying the most weight. Two specific things to fix.
1. It says there is no AI layer. There already is one.
The current implementation consists of full C++ QT based editor shell, with no AI layer yet.
src/plugins/aiinlinecompletion.cpp is 209 lines of working inline completion against OpenAI compatible endpoints. It has:
- a debounce timer (400ms default) that fires on idle after a text change,
- request cancellation by ID so a stale reply cannot overwrite fresh ghost text,
- response parsing that already handles three shapes: OpenAI style
choices[0].message.content, Ollama's /api/chat message.content, and /api/generate response,
- ghost text rendering and accept wired into
CodeEditor via ghostTextAccepted,
- and a plugin manifest (
aiinlinecompletion.json) declaring "permissions": ["network.access"].
The defaults in mainwindow.cpp:888 are provider: ollama, endpoint: http://localhost:11434/api/chat, model: codellama, enabled: false.
That is a working local first completion loop, disabled by default, against a local endpoint. It is the strongest single piece of evidence in the whole proposal and the whitepaper currently claims it does not exist. "We already have inline completion running against a local Ollama model, and here is what it does not yet do" is a far better opening for this section than "no AI layer yet".
2. "Why this shape is the point" references steps that are not in the document.
A proprietary editor could do steps 2-4 with a better model. What it cannot do is step 5 by default, or let the developer swap the model in steps 2-4 for one they own.
There is no numbered list anywhere in the whitepaper. This paragraph appears to be a survivor from an earlier draft that had a numbered request pipeline (keystroke, context assembly, provider call, response, egress log, or something in that shape). As it stands the argument is unreadable, which is a shame because the point it is making (the provider seam is what makes the whole thing mean something) is the correct one.
Suggested fix for both: expand Architecture into a real section. Roughly what it needs to cover:
- The three layers already documented in the repo README (Qt UI in C++, a thin C FFI adapter layer, and the Rust backend holding LSP, DAP, event bus, plugin manager, task runner, workspace, config, and permissions). This is a genuinely good architecture and the whitepaper does not describe it at all.
- Where the AI surfaces attach: today the completion plugin sits in the Qt layer talking directly to
QNetworkAccessManager. Whether the agent and chat surfaces go through the Rust backend instead is a real decision with consequences for the permission model and the egress log (see the separate issue on those).
- The numbered request pipeline that "Why this shape is the point" is referring to, restored, so that paragraph resolves.
The document is currently selling the project short against its own repository. Fixing this section is the highest leverage editing work left in the review window.
The Architecture section is the shortest in the document at three sentences, and it is the section carrying the most weight. Two specific things to fix.
1. It says there is no AI layer. There already is one.
src/plugins/aiinlinecompletion.cppis 209 lines of working inline completion against OpenAI compatible endpoints. It has:choices[0].message.content, Ollama's/api/chatmessage.content, and/api/generateresponse,CodeEditorviaghostTextAccepted,aiinlinecompletion.json) declaring"permissions": ["network.access"].The defaults in
mainwindow.cpp:888areprovider: ollama,endpoint: http://localhost:11434/api/chat,model: codellama,enabled: false.That is a working local first completion loop, disabled by default, against a local endpoint. It is the strongest single piece of evidence in the whole proposal and the whitepaper currently claims it does not exist. "We already have inline completion running against a local Ollama model, and here is what it does not yet do" is a far better opening for this section than "no AI layer yet".
2. "Why this shape is the point" references steps that are not in the document.
There is no numbered list anywhere in the whitepaper. This paragraph appears to be a survivor from an earlier draft that had a numbered request pipeline (keystroke, context assembly, provider call, response, egress log, or something in that shape). As it stands the argument is unreadable, which is a shame because the point it is making (the provider seam is what makes the whole thing mean something) is the correct one.
Suggested fix for both: expand Architecture into a real section. Roughly what it needs to cover:
QNetworkAccessManager. Whether the agent and chat surfaces go through the Rust backend instead is a real decision with consequences for the permission model and the egress log (see the separate issue on those).The document is currently selling the project short against its own repository. Fixing this section is the highest leverage editing work left in the review window.