This one is not about the design, it is about the two questions the core team weighs at Stage 3: is maintainer commitment real, and is the scope buildable. The whitepaper does not currently address either, and Scriptura has an unusual answer to both.
Stack fit.
The collective is TypeScript on Node. Stack Suggestions covers TypeScript and nothing else. Creating a New Project names Nanocoder as the reference implementation to mirror when in doubt. Scriptura is Qt 6, C++17, Rust and CMake, built and packaged across Linux, macOS and Windows.
I think that choice is defensible. The whitepaper's own argument against Electron is sound, and it is sharper than the document makes it:
more performance overhead, which is not good for a machine already running a local LLM
A machine running a 7B completion model has no memory or CPU headroom to spare for a browser engine. That is a real argument and it is the strongest justification the project has for its stack. It deserves more than half a line in Alternatives considered.
But the choice has a cost the document should name: it narrows the contributor pool. The collective's existing contributors write TypeScript. The pool that can review a Qt widget change or a C FFI boundary is a different and smaller one, and NC's pitch to contributors depends on projects being approachable.
Maintainer pool.
Right now the repository has 239 commits from one person and 1 from another. That is not a criticism, it is what a six week old project by a motivated author looks like. But Stage 3 asks for:
At least one named maintainer ready to drive the project for an initial period (aim for three months of active maintenance after v1.0). Co-maintainers welcome.
For a project of this size (33k lines of C++ and Qt, 7.7k of Rust, three platform packaging targets, LSP and DAP clients, a plugin system, an auto updater) a single maintainer is a genuine risk to name and plan for rather than leave implicit. One thing that would help the argument: the AI layer specifically is contributable without deep Qt knowledge. The completion plugin is a self contained plugin, and if the agent loop lands in the Rust backend, then most of the AI work is Rust plus prompt engineering rather than Qt internals. Saying that explicitly turns "you need C++ and Qt experience to contribute" into "you need it for the shell, not for the part we are asking the collective to help build".
Which pipeline this runs on.
Related, and worth settling before Stage 3. The repository predates the whitepaper: first commit 20 June, review opened 15 July. It already has CI, tests, installers, a plugin SDK, docs, a code of conduct and a contributing guide. That is much closer to Bringing an Existing Project than to a new whitepaper, and that path is deliberately lighter because, as it puts it:
the biggest question a whitepaper answers, "should this exist?", your project has already answered
The honest description may be a hybrid: the editor is an existing project joining the collective, and the AI layer is the new build that needs the whitepaper argument. Worth naming which, because the two paths check different things and the existing project path checks things this document does not currently cover (history cleanliness, migration cost, and what the transfer actually involves).
Concrete items that fall out either way, all cheap:
LICENSE copyright currently reads "Scriptura". The playbook specifies MIT with copyright "Nano Collective".- The repo carries its own
CODE_OF_CONDUCT.md. The playbook says to link the collective Code of Conduct from CONTRIBUTING.md instead, and that a per project file is unnecessary.
- The README does not yet carry the canonical project tagline from the Brand Guidelines.
- Next steps says "A repository is created under
Nano-Collective" in the present tense, as though it had happened. It is still at jason1015-coder/scriptura. Worth making that an explicit checklist item, since the transfer is what actually moves the project in.
- One for the doc rather than the repo:
docs/feature-roadmap.md marks roughly 21 of 25 features as implemented. When this whitepaper becomes the project README, those claims come with it, and the brand guidelines ask for understated and honest copy. A verified baseline of what actually works end to end would be worth establishing first.
This one is not about the design, it is about the two questions the core team weighs at Stage 3: is maintainer commitment real, and is the scope buildable. The whitepaper does not currently address either, and Scriptura has an unusual answer to both.
Stack fit.
The collective is TypeScript on Node. Stack Suggestions covers TypeScript and nothing else. Creating a New Project names Nanocoder as the reference implementation to mirror when in doubt. Scriptura is Qt 6, C++17, Rust and CMake, built and packaged across Linux, macOS and Windows.
I think that choice is defensible. The whitepaper's own argument against Electron is sound, and it is sharper than the document makes it:
A machine running a 7B completion model has no memory or CPU headroom to spare for a browser engine. That is a real argument and it is the strongest justification the project has for its stack. It deserves more than half a line in Alternatives considered.
But the choice has a cost the document should name: it narrows the contributor pool. The collective's existing contributors write TypeScript. The pool that can review a Qt widget change or a C FFI boundary is a different and smaller one, and NC's pitch to contributors depends on projects being approachable.
Maintainer pool.
Right now the repository has 239 commits from one person and 1 from another. That is not a criticism, it is what a six week old project by a motivated author looks like. But Stage 3 asks for:
For a project of this size (33k lines of C++ and Qt, 7.7k of Rust, three platform packaging targets, LSP and DAP clients, a plugin system, an auto updater) a single maintainer is a genuine risk to name and plan for rather than leave implicit. One thing that would help the argument: the AI layer specifically is contributable without deep Qt knowledge. The completion plugin is a self contained plugin, and if the agent loop lands in the Rust backend, then most of the AI work is Rust plus prompt engineering rather than Qt internals. Saying that explicitly turns "you need C++ and Qt experience to contribute" into "you need it for the shell, not for the part we are asking the collective to help build".
Which pipeline this runs on.
Related, and worth settling before Stage 3. The repository predates the whitepaper: first commit 20 June, review opened 15 July. It already has CI, tests, installers, a plugin SDK, docs, a code of conduct and a contributing guide. That is much closer to Bringing an Existing Project than to a new whitepaper, and that path is deliberately lighter because, as it puts it:
The honest description may be a hybrid: the editor is an existing project joining the collective, and the AI layer is the new build that needs the whitepaper argument. Worth naming which, because the two paths check different things and the existing project path checks things this document does not currently cover (history cleanliness, migration cost, and what the transfer actually involves).
Concrete items that fall out either way, all cheap:
LICENSEcopyright currently reads "Scriptura". The playbook specifies MIT with copyright "Nano Collective".CODE_OF_CONDUCT.md. The playbook says to link the collective Code of Conduct fromCONTRIBUTING.mdinstead, and that a per project file is unnecessary.Nano-Collective" in the present tense, as though it had happened. It is still atjason1015-coder/scriptura. Worth making that an explicit checklist item, since the transfer is what actually moves the project in.docs/feature-roadmap.mdmarks roughly 21 of 25 features as implemented. When this whitepaper becomes the project README, those claims come with it, and the brand guidelines ask for understated and honest copy. A verified baseline of what actually works end to end would be worth establishing first.