The whitepaper's plan for the agent loop rests on one clause:
The proposed solution will be adding a widget to the editor shell that provides AI functionality, by integrating with existing nanocoder agent (which is in typescript)
and then, in Composition:
Scriptura's agent loop is a thin UI over Nanocoder's non-interactive mode; the same prompts, the same tool access, the same local-first posture.
Scriptura is a native binary (Qt 6, C++17, a Rust static library, CMake, shipped as an AppImage, a DMG and an NSIS installer). Nanocoder is a Node application. The document never says how the two meet, and that choice drives packaging, latency, and whether "thin UI over Nanocoder" is even accurate.
The good news first: the seam the whitepaper assumes does exist. Nanocoder v1.29.0 supports non-interactive invocation:
nanocoder --provider openrouter --model google/gemini-3.1-flash run "analyze src/app.ts"
So the claim is not built on something imaginary. But there are at least three ways to consume it, and they are not equivalent:
- Spawn
nanocoder run per agent turn. Simplest to build. Costs Node process startup on every turn, gives no streaming granularity (the user watches nothing happen and then everything happens), and leaves you parsing prose out of stdout with no structured tool call events. Diff previews and per tool approval are hard to build on top of this.
- A long lived sidecar process over stdio or a local socket, speaking a JSON protocol. Much better latency and streaming, and it can surface structured tool call events that the editor renders as inline diffs. But you are now designing, versioning and maintaining that protocol, plus process lifecycle, crash recovery, and the coupling to Nanocoder's release cadence that comes with it. Worth noting Nanocoder does not currently expose such a protocol, so this is upstream work as well as Scriptura work.
- Reimplement the agent loop in the Rust backend against the same providers, treating "Nanocoder's prompt techniques" as shared conventions rather than shared code. This fits the existing architecture best (the Rust backend already carries
reqwest with rustls-tls and a permission manager) and gives full control over streaming and tool events. But it makes "a thin UI over Nanocoder" false, and it means maintaining a second agent loop in the collective.
This is close to the question raised on Nanoterm in #38 ("decoupled yet shared"), except harder, because there is a language boundary as well as a repository boundary.
The packaging consequence is worth calling out separately. The repo README currently promises Windows users that the installer bundles everything:
pre-built installers are available that bundle all Qt and Rust runtime dependencies, so no manual Qt or Rust installation is required
If the agent loop shells out to Nanocoder, either the installer bundles a Node runtime (installer size, update surface, and a second toolchain to keep patched) or the user needs Node on PATH and that promise no longer holds. If the agent loop lives in Rust, the promise survives intact. That is a real point in favour of option three that the whitepaper should weigh openly.
What would help: name the intended shape in the Architecture section, with the trade-off stated. It also affects sequencing, since options one and two make Scriptura's timeline partly dependent on Nanocoder maintainers, and option three does not.
The whitepaper's plan for the agent loop rests on one clause:
and then, in Composition:
Scriptura is a native binary (Qt 6, C++17, a Rust static library, CMake, shipped as an AppImage, a DMG and an NSIS installer). Nanocoder is a Node application. The document never says how the two meet, and that choice drives packaging, latency, and whether "thin UI over Nanocoder" is even accurate.
The good news first: the seam the whitepaper assumes does exist. Nanocoder v1.29.0 supports non-interactive invocation:
nanocoder --provider openrouter --model google/gemini-3.1-flash run "analyze src/app.ts"So the claim is not built on something imaginary. But there are at least three ways to consume it, and they are not equivalent:
nanocoder runper agent turn. Simplest to build. Costs Node process startup on every turn, gives no streaming granularity (the user watches nothing happen and then everything happens), and leaves you parsing prose out of stdout with no structured tool call events. Diff previews and per tool approval are hard to build on top of this.reqwestwithrustls-tlsand a permission manager) and gives full control over streaming and tool events. But it makes "a thin UI over Nanocoder" false, and it means maintaining a second agent loop in the collective.This is close to the question raised on Nanoterm in #38 ("decoupled yet shared"), except harder, because there is a language boundary as well as a repository boundary.
The packaging consequence is worth calling out separately. The repo README currently promises Windows users that the installer bundles everything:
If the agent loop shells out to Nanocoder, either the installer bundles a Node runtime (installer size, update surface, and a second toolchain to keep patched) or the user needs Node on PATH and that promise no longer holds. If the agent loop lives in Rust, the promise survives intact. That is a real point in favour of option three that the whitepaper should weigh openly.
What would help: name the intended shape in the Architecture section, with the trade-off stated. It also affects sequencing, since options one and two make Scriptura's timeline partly dependent on Nanocoder maintainers, and option three does not.