scriveno 2.0.8 → 2.0.9

package/docs/architecture.md

@@ -4,7 +4,7 @@ How Scriveno works under the hood -- for developers who want to understand the s
 
 ## Overview
 
-Scriveno is a pure skill system. There is no compiled code, no runtime library, no framework. AI coding agents (Claude Code, Cursor, Gemini CLI, and others) read markdown command files and follow their instructions using their built-in tools (Read, Write, Bash).
+Scriveno is a markdown-first skill system with a small Node.js support layer. AI coding agents (Claude Code, Cursor, Gemini CLI, and others) read markdown command files and follow their instructions using their built-in tools (Read, Write, Bash). Node.js handles installation, packaging, runtime synchronization, and the shared read-only status engine.
 
 The entire system is a collection of files:
 
@@ -13,7 +13,7 @@ The entire system is a collection of files:
 - **CONSTRAINTS.json** is the central registry that controls which commands are available for which work types
 - **Templates** provide starting content for new projects
 
-Nothing compiles. Nothing bundles. Changes take effect immediately because the agent reads files at runtime.
+Nothing compiles for the command layer. Changes to markdown commands take effect immediately because the agent reads files at runtime. Changes to the installer or shared status engine are tested and shipped through the npm package.
 
 ## Skill System Design
 
@@ -353,7 +353,17 @@ Codex uses a skill-native variation of this strategy. The installer generates on
 
 Scriveno also ships `lib/auto-invoke-engine.js`, exposed through `scriveno status --project .` and `scriveno status . --json`. The installer copies this library into the shared Scriveno asset directory for global and project installs, so command surfaces can call a single read-only status engine before falling back to embedded markdown logic.
 
-The engine checks disk evidence only: project presence, STATE.md, CONTEXT.md freshness, review files, translation work, exports, history, and save signals. It recommends the next command, but it does not mutate files and does not spawn agents by itself. That boundary keeps proactive behavior portable across Claude Code, Codex, Cursor, Gemini CLI, OpenCode, GitHub Copilot, Windsurf, Antigravity, Manus, Perplexity Desktop, and the generic fallback.
+The engine checks disk evidence only: project presence, required project files, STATE.md, CONTEXT.md freshness, plan files, draft files, review coverage, unresolved notes, revision-track proposals, translation work, publishing prerequisites, exports, history, and save signals. It recommends the next command, but it does not mutate files and does not spawn agents by itself. That boundary keeps proactive behavior portable across Claude Code, Codex, Cursor, Gemini CLI, OpenCode, GitHub Copilot, Windsurf, Antigravity, Manus, Perplexity Desktop, and the generic fallback.
+
+The engine now reports three automation lanes:
+
+- **Candidate agents**: bounded specialist routes that may spawn when the host supports it, such as `drafter`, `voice-checker`, `continuity-checker`, `translator`, `plan-checker`, beta-reader workers, and import analysis workers.
+- **Candidate local helpers**: deterministic file or status helpers such as `/scr:save`, `/scr:scan`, `/scr:check-notes`, `/scr:progress`, `/scr:session-report`, and `/scr:sync`.
+- **Manual gates**: writer-owned routes that need explicit confirmation, including publishing packages, export overwrites, and revision-track merge or proposal decisions.
+
+Every command registry category has an automation lane through `getCommandAutomationPolicy()`. This makes route coverage testable: core routes are mixed, navigation routes are read-only, quality and review routes are agent-or-local, publishing and collaboration routes are manual-gated, utility and session routes are local-helper, and structure-management routes stay manual because they can rename or remove manuscript units.
+
+This turns disconnected side features into visible routes. A plan without a draft recommends `/scr:draft` and lists the drafter route as a candidate agent path. Drafts without reviews recommend `/scr:editor-review` before export. Notes route to `/scr:check-notes`. Revision proposals route to `/scr:editor-review --proposal` or `/scr:track`. Publishing gaps route to `/scr:front-matter`, `/scr:back-matter`, `/scr:blurb`, `/scr:cover-art`, or `/scr:publish` depending on disk evidence.
 
 ### Installation modes
 

package/docs/auto-invoke-policy.md

@@ -4,6 +4,10 @@ Scriveno can be proactive, but it must be proactive from disk evidence. Commands
 
 The executable policy lives in `lib/auto-invoke-engine.js` and is exposed through `scriveno status --project .`. The installer copies it to `.scriveno/lib/auto-invoke-engine.js` for project installs and `~/.scriveno/lib/auto-invoke-engine.js` for global installs, so every runtime can use the same read-only status logic.
 
+The engine reports candidates instead of silently acting. It can identify planned-but-undrafted work, drafts without review coverage, unresolved note files, revision proposals, translation follow-ups, publishing prerequisite gaps, stale exports, and stale session context. It then separates what could spawn an agent, what could run as a local helper, and what must stay behind a manual gate.
+
+The same file exports `getCommandAutomationPolicy()`, which classifies every command registry route into an automation lane. Tests assert that every command category is covered, so newly added routes cannot sit outside the proactive policy by accident.
+
 ## Cross-Platform Agent Rules
 
 Scriveno agent prompts live in `agents/*.md`. Each host runtime exposes them differently:
@@ -23,8 +27,14 @@ Agent status:
 Trigger: <command or state condition>
 Spawned agents:
 - <agent-name>: <count, none, or prompt-run fallback used>
+Candidate agents:
+- <command>: <agent names or none>
 Local operations:
 - <operation>: <result>
+Candidate local helpers:
+- <command>: <reason or none>
+Manual gates:
+- <command>: <reason or none>
 Auto-invoked:
 - <command or helper>: yes/no
 Why: <one sentence tied to disk state>
@@ -47,8 +57,12 @@ Run these read-only checks in `/scr:next`, `/scr:progress`, and closeouts for ma
 
 - If `STATE.md`, `CONTEXT.md`, `HISTORY.log`, or draft mtimes disagree, suggest `/scr:scan`.
 - If voice or continuity reports have unresolved issues, suggest `/scr:voice-check`, `/scr:continuity-check`, or `/scr:editor-review`.
+- If plan files exist with no corresponding drafts, suggest `/scr:draft` before reopening planning.
+- If drafts exist without review coverage, suggest `/scr:editor-review` before export.
 - If editor notes or track proposals exist, suggest `/scr:editor-review --notes`, `/scr:editor-review --respond`, or `/scr:track`.
+- If note files contain unresolved items, suggest `/scr:check-notes`.
 - If translation folders exist or config lists target languages, suggest translation follow-ups.
+- If front matter, back matter, blurb, or cover handoff assets are missing, surface the specific publishing prerequisite before packaging.
 - If export outputs are older than source files, suggest `/scr:export` or `/scr:publish`.
 - If no save exists after recent manuscript changes, suggest `/scr:save`.
 

package/docs/configuration.md

@@ -57,7 +57,7 @@ When a writer runs `/scr:new-work`, Scriveno creates `.manuscript/config.json`.
 
 ```json
 {
-  "scriveno_version": "2.0.8",
+  "scriveno_version": "2.0.9",
   "work_type": "<chosen>",
   "group": "<group>",
   "command_unit": "<unit>",

package/docs/getting-started.md

@@ -31,7 +31,7 @@ scriveno status --project .
 scriveno status . --json
 ```
 
-That status command is the same shared auto-invoke engine used by `/scr-next`, `/scr:next`, `/scr:progress`, `/scr:session-report`, and `/scr:sync` when local command execution is available. It recommends the next safest command, but does not mutate files or spawn agents by itself.
+That status command is the same shared auto-invoke engine used by `/scr-next`, `/scr:next`, `/scr:progress`, `/scr:session-report`, and `/scr:sync` when local command execution is available. It recommends the next safest command, but does not mutate files or spawn agents by itself. Current status output separates candidate agents, candidate local helpers, and manual gates so you can tell whether Scriveno is pointing at a specialist route, a deterministic file helper, or a writer-owned decision.
 
 ## Step 2: Explore the Demo (Optional)
 

package/docs/release-notes.md

@@ -2,6 +2,39 @@
 
 This document is the public-facing summary of what changed between package releases. For package history, see the root [CHANGELOG](../CHANGELOG.md).
 
+## 2.0.9 - 2026-05-16
+
+### What changed
+
+- `scriveno status --project .` now detects connected workflow gaps instead of only broad project state.
+- The shared engine can route planned-but-undrafted work to `/scr:draft`, drafts without review coverage to `/scr:editor-review`, unresolved notes to `/scr:check-notes`, revision proposals to `/scr:editor-review --proposal`, translation work to verification follow-ups, and publishing gaps to the specific missing prerequisite.
+- Status output now separates `Candidate agents`, `Candidate local helpers`, and `Manual gates`.
+- Every command registry category now has an automation lane through `getCommandAutomationPolicy()`.
+- Markdown fallback contracts for `/scr:next`, `/scr:progress`, `/scr:session-report`, `/scr:save`, `/scr:scan`, and `/scr:health` now show the same route-intelligence shape when a host cannot call the Node engine.
+- README badges, README status copy, Architecture, Auto-Invoke Policy, Configuration, changelog, and package metadata are aligned on `2.0.9`.
+
+### Why it matters
+
+The status engine now connects previously separate flows. A writer can see whether Scriveno is recommending an agent-backed route, a deterministic local helper, or a writer-owned manual action. That makes automation more proactive without making it mysterious or pushy.
+
+### Affected areas
+
+- shared auto-invoke engine
+- public status CLI output
+- route automation policy
+- command fallback status blocks
+- README badges and launch copy
+- architecture and auto-invoke documentation
+- package metadata and generated project examples
+- regression tests for route intelligence and command policy coverage
+
+### Verification
+
+- `npm test`
+- `npm run release:check`
+- `npm pack --json`
+- `git diff --check`
+
 ## 2.0.8 - 2026-05-16
 
 ### What changed

package/docs/runtime-support.md

@@ -71,7 +71,7 @@ Every install target receives the same read-only status engine through Scriveno'
 - project installs: `.scriveno/lib/auto-invoke-engine.js`
 - source checkouts: `lib/auto-invoke-engine.js`
 
-The engine computes proactive state from disk evidence: missing or stale context, unresolved review files, translation work, stale exports, missing history, and the recommended next command. It does not mutate manuscript files and does not spawn agents. Host commands such as `/scr:next`, `/scr:progress`, `/scr:session-report`, and `/scr:sync` should call it first when local command execution is available, then fall back to their embedded markdown logic when the host cannot run Node.
+The engine computes proactive state from disk evidence: missing or stale context, plan and draft coverage, unresolved review files, unresolved notes, revision proposals, translation work, publishing prerequisites, stale exports, missing history, and the recommended next command. It does not mutate manuscript files and does not spawn agents. Host commands such as `/scr:next`, `/scr:progress`, `/scr:session-report`, and `/scr:sync` should call it first when local command execution is available, then fall back to their embedded markdown logic when the host cannot run Node.
 
 The public CLI entrypoint is:
 
@@ -82,6 +82,8 @@ scriveno status . --json
 
 The JSON form is intended for CI, host adapters, and future runtime smoke tests.
 
+Status output uses the same route-intelligence shape across runtimes: `Candidate agents`, `Candidate local helpers`, and `Manual gates`. That keeps Claude Code, Codex, Cursor, Gemini CLI, OpenCode, GitHub Copilot, Windsurf, Antigravity, Manus, Perplexity Desktop, and generic skill installs aligned even when their native spawning mechanisms differ.
+
 ## What Scriveno Proves Today
 
 Scriveno currently proves all of the following in-repo: