The review window closes on 14 August and "Resolved in review" still reads "(none yet)", while two of the three open questions have answers sitting in the repository already. Recording them would strengthen the document at the Stage 3 decision, since one of the criteria is whether concerns raised in review were addressed.
Open question 2, the default provider, is already answered, and the answer is the one the principles want.
The question as written:
If the user has no local model running, does v1 ship with a clear "install Ollama, here is the one-liner" flow, or fall back to a configured remote endpoint with a loud warning? The local-first principle says the former; activation cost says the latter.
mainwindow.cpp:888 already implements the former:
QSettings().value("ai/provider", "ollama").toString(),
QSettings().value("ai/endpoint", "http://localhost:11434/api/chat").toString(),
QSettings().value("ai/model", "codellama").toString(),
QSettings().value("ai/enabled", false).toBool(),Local endpoint, local model, disabled until the user turns it on, and no remote fallback anywhere in the code path. There is no silent degradation to a cloud provider, which is the failure mode the question was worried about.
So the decision is made and it is the right one. What is genuinely still open is narrower, and it is what #50 is circling: the first run experience when the endpoint is not reachable. Right now requestCompletionInternal returns silently if the endpoint or model is empty, and onReplyFinished drops network errors on the floor without telling the user anything. A user who enables completions without Ollama running gets no ghost text and no explanation.
That is the part worth designing and recording: does Scriptura detect an unreachable local endpoint and offer the Ollama install one liner, does the settings tab Jason mentions in #50 include a "test connection" action, and does a failed request surface in the notification centre (which already exists) rather than vanishing? Answering that converts open question 2 into a resolved entry plus a small piece of v1 scope.
Open question 3, the extension host, is pointed at something that does not exist. Covered in more detail in the separate issue about the VS Code premise, but it belongs in this list too: there is no VS Code extension host to keep or restrict. The question needs reframing around the custom plugin system the repo actually has before it can be resolved.
Open question 1, naming. Offering an opinion so #49 has something to react to rather than sitting open by default.
Scriptura fits the collective's Latin noun convention and there is no meaningful software collision. The npm name scriptura is unregistered, and no well known editor or developer tool carries the name. The nearest thing is a small web frontend framework under a scriptura GitHub org, which is not in the same category and is not widely used.
The one real cost is discoverability. Searching GitHub for repositories named scriptura returns 236 results and the top hits are biblical study tools and projects named after "sola scriptura", the theological term. The word skews heavily religious in general search too, so someone looking for the editor will wade through that. Since the project would live at Nano-Collective/scriptura, the taken org handle does not matter.
That is a soft cost, and against it the name is already embedded in the repository, the binary, the SDK headers and the plugin ID namespace (com.scriptura.*), and renaming gets more expensive every week. My read is keep it, close the question, and let the project's own results do the search ranking work over time. It is also currently the only open question blocking the repository transfer, which is a lot of friction for a soft cost.
Suggested fix: move 1 and 2 into "Resolved in review" with the rationale recorded (the convention DocsForest uses, where each resolved item states the decision and why), reframe 3, and add the first run failure behaviour to v1 scope.
The review window closes on 14 August and "Resolved in review" still reads "(none yet)", while two of the three open questions have answers sitting in the repository already. Recording them would strengthen the document at the Stage 3 decision, since one of the criteria is whether concerns raised in review were addressed.
Open question 2, the default provider, is already answered, and the answer is the one the principles want.
The question as written:
mainwindow.cpp:888already implements the former:Local endpoint, local model, disabled until the user turns it on, and no remote fallback anywhere in the code path. There is no silent degradation to a cloud provider, which is the failure mode the question was worried about.
So the decision is made and it is the right one. What is genuinely still open is narrower, and it is what #50 is circling: the first run experience when the endpoint is not reachable. Right now
requestCompletionInternalreturns silently if the endpoint or model is empty, andonReplyFinisheddrops network errors on the floor without telling the user anything. A user who enables completions without Ollama running gets no ghost text and no explanation.That is the part worth designing and recording: does Scriptura detect an unreachable local endpoint and offer the Ollama install one liner, does the settings tab Jason mentions in #50 include a "test connection" action, and does a failed request surface in the notification centre (which already exists) rather than vanishing? Answering that converts open question 2 into a resolved entry plus a small piece of v1 scope.
Open question 3, the extension host, is pointed at something that does not exist. Covered in more detail in the separate issue about the VS Code premise, but it belongs in this list too: there is no VS Code extension host to keep or restrict. The question needs reframing around the custom plugin system the repo actually has before it can be resolved.
Open question 1, naming. Offering an opinion so #49 has something to react to rather than sitting open by default.
Scriptura fits the collective's Latin noun convention and there is no meaningful software collision. The npm name
scripturais unregistered, and no well known editor or developer tool carries the name. The nearest thing is a small web frontend framework under ascripturaGitHub org, which is not in the same category and is not widely used.The one real cost is discoverability. Searching GitHub for repositories named
scripturareturns 236 results and the top hits are biblical study tools and projects named after "sola scriptura", the theological term. The word skews heavily religious in general search too, so someone looking for the editor will wade through that. Since the project would live atNano-Collective/scriptura, the taken org handle does not matter.That is a soft cost, and against it the name is already embedded in the repository, the binary, the SDK headers and the plugin ID namespace (
com.scriptura.*), and renaming gets more expensive every week. My read is keep it, close the question, and let the project's own results do the search ranking work over time. It is also currently the only open question blocking the repository transfer, which is a lot of friction for a soft cost.Suggested fix: move 1 and 2 into "Resolved in review" with the rationale recorded (the convention DocsForest uses, where each resolved item states the decision and why), reframe 3, and add the first run failure behaviour to v1 scope.