scriveno 2.0.5

package/docs/contributing.md

@@ -0,0 +1,430 @@
+# Contributing to Scriveno
+
+Scriveno is a pure skill system -- markdown files that AI agents read and execute. There is no compiled code, no build step, no runtime dependencies. Contributing means adding or editing markdown files and updating the central constraint registry.
+
+This guide walks you through extending Scriveno: adding commands, agents, work types, templates, and export formats. Each section is self-contained -- jump to what you need.
+
+## File Structure Overview
+
+Before diving in, here is how the codebase is organized:
+
+```
+commands/scr/          Core command tree (100+ command files, including sacred subcommands)
+commands/scr/sacred/   8 sacred-exclusive subcommands
+agents/                6 specialized agents (drafter, voice-checker, etc.)
+data/CONSTRAINTS.json  Central constraint registry -- every command checks this
+data/demo/             Pre-baked demo project (watchmaker story)
+data/export-templates/ Export templates (Typst, CSS, LaTeX)
+templates/             Base project templates + technical/ and sacred/ variants
+templates/technical/   6 technical-writing context variants
+templates/sacred/      Sacred-specific context templates and tradition manifests
+bin/install.js         Multi-platform installer (Node.js)
+docs/                  Documentation suite (16 guides)
+```
+
+Key principle: the AI agent reads these files at runtime. There is no compilation, no bundling, no transpilation. If you can write markdown, you can contribute.
+
+## Adding a Command
+
+Every `/scr:*` command is a markdown file in `commands/scr/`. The agent reads the file and follows its instructions. Here is the complete process.
+
+### Step 1: Create the command file
+
+Create `commands/scr/{name}.md` with YAML frontmatter and a markdown body. Here is a minimal example based on the `add-note` command:
+
+```yaml
+---
+description: Add a quick note or reminder to the project notes file.
+argument-hint: "<note text>"
+---
+```
+
+The frontmatter has two fields:
+
+- **`description`** -- One-line summary shown in help and command listings
+- **`argument-hint`** -- Shows the expected arguments (use `<required>` and `[optional]` notation)
+
+After the frontmatter, write the command instructions in markdown. Here is what the body of `add-note.md` looks like:
+
+```markdown
+# Add Note
+
+You are adding a quick note to the project's notes file.
+
+## What to do
+
+1. Take the note text from the argument
+2. Open `.manuscript/NOTES.md` (create it if it doesn't exist)
+3. If creating: add header `# Project Notes\n\n`
+4. Append the note with a timestamp:
+   - [2026-04-07 14:30] Note text here
+5. Save the file
+6. Confirm: "Note added."
+```
+
+The body tells the AI agent exactly what to do -- step by step, in plain language.
+
+### Step 2: Add to CONSTRAINTS.json
+
+Open `data/CONSTRAINTS.json` and add an entry under the `"commands"` object:
+
+```json
+"add-note": {
+  "category": "utility",
+  "available": ["all"],
+  "description": "Add a quick note or reminder to the project notes file"
+}
+```
+
+The command entry fields:
+
+- **`category`** -- Groups the command in help output (core, navigation, structure, craft, publishing, utility, sacred_exclusive, etc.)
+- **`available`** -- Which work type groups can use this command. Use `["all"]` for universal commands, or list specific groups like `["prose", "script"]`
+- **`description`** -- Same as the frontmatter description
+
+Some commands have additional fields:
+
+```json
+"draft": {
+  "category": "core",
+  "available": ["all"],
+  "renames_by_unit": true,
+  "description": "Draft the planned unit"
+}
+```
+
+- **`renames_by_unit`** -- Legacy schema flag indicating that the command adapts its terminology based on the work type. A novel project still runs `/scr:draft`, but Scriveno presents the work as drafting a chapter; a screenplay presents it as drafting an act.
+- **`adapted`** -- Work-type-specific overrides (renames, behavior changes). For example, `editor-review` becomes `peer-review` for academic works.
+
+### Step 3: Understand adaptive terminology
+
+Commands that set `renames_by_unit: true` in CONSTRAINTS.json adapt their terminology based on `command_unit` in the project's `.manuscript/config.json`. The command file itself handles this:
+
+```markdown
+## Adaptive naming
+
+Load `.manuscript/config.json` for `command_unit`. This command stays `/scr:draft`; use the active unit term in prompts and output.
+```
+
+When a writer starts a novel project, `command_unit` is set to `"chapter"`, so `/scr:draft` is presented in chapter terms. For a screenplay, the same `/scr:draft` command is presented in act terms. The command file itself does not change -- the adaptation happens at runtime through config.json.
+
+### Step 4: Write a full command
+
+A full command file typically has these sections:
+
+1. **Title** -- `# Command Name`
+2. **Adaptive naming** (if applicable) -- How the command name adapts
+3. **Prerequisites** -- What must exist before this command runs
+4. **What to do** -- Step-by-step instructions for the agent
+5. **Tone** -- How the agent should communicate with the writer
+6. **Edge Cases** -- What to do when things go wrong
+
+Look at `commands/scr/draft.md` for a complex example (orchestrates the drafter agent) or `commands/scr/add-unit.md` for a structural command with work-type adaptation.
+
+### Minimal vs full
+
+A minimal command needs only frontmatter + basic instructions (like `add-note.md` at 29 lines). A full command like `draft.md` (46 lines) includes adaptive terminology, prerequisites, autopilot behavior, and tone guidance. Start minimal and add sections as needed.
+
+## Adding an Agent
+
+Agents are specialized markdown files in `agents/`. They are invoked by commands in fresh context -- each invocation starts with a clean slate.
+
+### Step 1: Create the agent file
+
+Create `agents/{name}.md` with YAML frontmatter:
+
+```yaml
+---
+name: drafter
+description: Drafts a single atomic unit in the writer's voice. Invoked in fresh context per atomic unit.
+tools: Read, Write
+---
+```
+
+The frontmatter fields:
+
+- **`name`** -- Agent identifier
+- **`description`** -- What the agent does
+- **`tools`** -- Which tools the agent needs (Read, Write, Bash, etc.)
+
+### Step 2: Write the agent body
+
+The body explains what the agent receives, what it does, and what it must never do. Here is the pattern from `agents/drafter.md`:
+
+```markdown
+# Drafter agent
+
+You are the Scriveno drafter. Your single job is to draft one atomic unit
+in the writer's established voice.
+
+## What you receive
+
+1. **STYLE-GUIDE.md** -- The voice DNA
+2. **.manuscript/plans/{N}-{A}-PLAN.md** -- The plan for this atomic unit
+3. **CHARACTERS.md excerpt** -- Relevant characters only
+4. **Previous unit tail** -- Last 200 words of previous unit
+5. **THEMES.md excerpt** -- Relevant thematic threads
+
+## What you do NOT receive
+
+- The full manuscript
+- The writer's conversation history
+- Other units' drafts
+
+## How to draft
+
+[Step-by-step instructions...]
+
+## What you must never do
+
+[Hard constraints...]
+```
+
+### The fresh-context-per-unit pattern
+
+This is the most important architectural pattern in Scriveno. When a command invokes an agent:
+
+- The agent is started in a **clean context** -- no prior conversation, no accumulated state
+- It receives only the specific files it needs for this one unit
+- STYLE-GUIDE.md is **always loaded first** -- voice DNA is the top priority
+- After completing its work, the agent context is discarded
+
+This prevents voice drift, context bloat, and cross-contamination between units. It is the key to voice fidelity.
+
+### Existing agents
+
+Scriveno ships with 6 agents:
+
+| Agent | Purpose |
+|-------|---------|
+| `drafter` | Drafts one atomic unit in the writer's voice |
+| `voice-checker` | Compares drafts against STYLE-GUIDE.md, flags drift |
+| `continuity-checker` | Catches contradictions, timeline errors, character drift |
+| `plan-checker` | Validates unit plans before drafting |
+| `researcher` | Gathers research material for a topic |
+| `translator` | Translates content with voice preservation |
+
+## Adding a Work Type
+
+Work types define what a writer is creating -- novel, screenplay, Quran commentary, etc. They live in `data/CONSTRAINTS.json` under two sections.
+
+### Step 1: Check if you need a new group
+
+Work types belong to groups. Existing groups:
+
+- `prose` -- novel, memoir, essay, etc.
+- `script` -- screenplay, stage play, TV pilot, etc.
+- `academic` -- research paper, thesis, journal article, etc.
+- `technical` -- technical guide, runbook, API reference, design spec
+- `visual` -- comic, graphic novel, children's book, etc.
+- `poetry` -- poetry collection, single poem, song lyric
+- `interactive` -- interactive fiction, game narrative
+- `speech_song` -- speech
+- `sacred` -- scripture, commentary, devotional, etc.
+
+If your work type fits an existing group, skip to Step 2. To add a new group:
+
+```json
+"work_type_groups": {
+  "your_group": {
+    "label": "Your Group",
+    "members": ["your_work_type"]
+  }
+}
+```
+
+### Step 2: Add the work type entry
+
+Add to the `"work_types"` object in CONSTRAINTS.json:
+
+```json
+"your_work_type": {
+  "label": "Your Work Type",
+  "group": "prose",
+  "hierarchy": { "top": "part", "mid": "chapter", "atomic": "scene" },
+  "command_unit": "chapter"
+}
+```
+
+The fields:
+
+- **`label`** -- Human-readable name
+- **`group`** -- Which group this belongs to
+- **`hierarchy`** -- Three structural levels:
+  - `top` -- Largest division (part, act, testament). Use `null` if not applicable.
+  - `mid` -- Middle division (chapter, scene, section)
+  - `atomic` -- Smallest draft unit (scene, beat, verse, stanza)
+- **`command_unit`** -- Which hierarchy level commands operate on by default
+
+For sacred work types, you can also add `config_defaults`:
+
+```json
+"scripture_quranic": {
+  "label": "Scripture (Quranic)",
+  "group": "sacred",
+  "hierarchy": { "top": null, "mid": "surah", "atomic": "ayah" },
+  "command_unit": "surah",
+  "config_defaults": {
+    "verse_numbering_system": "quranic_hafs",
+    "calendar_system": "hijri"
+  }
+}
+```
+
+### Step 3: Add to the group's members array
+
+Add your work type key to the appropriate group's `members` array:
+
+```json
+"prose": {
+  "label": "Prose",
+  "members": ["novel", "novella", "short_story", "your_work_type"]
+}
+```
+
+### Step 4: Update command availability
+
+Review commands in CONSTRAINTS.json. For each command, check its `available` array. If the command should work with your new work type's group, it probably already does (most commands use `["all"]`). If a command is group-restricted and should include your type, add the group name.
+
+## Adding a Template
+
+Templates are markdown files in `templates/` that define the starting content for project context files. When a writer runs `/scr:new-work`, these templates are copied into `.manuscript/`.
+
+### Step 1: Create the template file
+
+Create `templates/{NAME}.md` with placeholder content. Here is the pattern -- each template uses `{placeholders}` that the `new-work` command fills in:
+
+```markdown
+# {work_title} -- Work Overview
+
+## Premise
+
+{premise}
+
+## Tone & Mood
+
+[To be developed during /scr:discuss]
+```
+
+### Step 2: Technical and sacred variants
+
+If your template needs a technical-writing-specific or sacred-specific version, add it to `templates/technical/` or `templates/sacred/`. These templates replace or extend the standard ones for their work-type groups. For example:
+
+- `templates/CHARACTERS.md` is the standard character template
+- `templates/technical/AUDIENCE.md` replaces it for technical docs
+- `templates/sacred/FIGURES.md` replaces it for sacred works (uses "figures" instead of "characters")
+
+Existing technical templates: `DOC-BRIEF.md`, `AUDIENCE.md`, `DEPENDENCIES.md`, `SYSTEM.md`, `PROCEDURES.md`, `REFERENCES.md`.
+Existing sacred templates: `COSMOLOGY.md`, `DOCTRINES.md`, `FIGURES.md`, `FRAMEWORK.md`, `LINEAGES.md`, `THEOLOGICAL-ARC.md`.
+
+### Step 3: Register in config.json
+
+The `templates/config.json` file is the project configuration template. If your new template adds a configuration option, add the default value there.
+
+## Adding an Export Format
+
+Export templates live in `data/export-templates/` and define how manuscripts are converted to output formats.
+
+See `docs/shipped-assets.md` for the canonical inventory of shipped export templates and trust-critical launch assets.
+
+### Step 1: Create the template file
+
+Add your template to `data/export-templates/`. Existing templates:
+
+- `scriveno-book.typst` -- Book interior PDF (Typst template)
+- `scriveno-epub.css` -- EPUB styling (CSS)
+- `scriveno-academic.latex` -- Academic paper formatting (LaTeX)
+
+Name your file `scriveno-{purpose}.{ext}` following the existing pattern.
+
+### Step 2: Update the export command
+
+The export command (`commands/scr/export.md`) needs to know about your format. Add handling for the new format in the command's instruction body.
+
+### Step 3: Add CONSTRAINTS.json entry (if restricted)
+
+If your export format is only available for certain work types, add an entry to the `"export_formats"` section of CONSTRAINTS.json with an `available_for` array specifying which work type groups can use it.
+
+## Testing Your Changes
+
+Scriveno has a test suite that validates the constraint system and command structure.
+
+### Run the tests
+
+```bash
+node --test test/
+```
+
+This runs all tests, including:
+
+- **CONSTRAINTS.json validation** -- Ensures all work types, commands, and cross-references are consistent
+- **Command structure tests** -- Verifies command files have valid frontmatter
+- **Installer tests** -- Checks that the installer handles all platforms correctly
+
+### Manual verification
+
+After adding a command, verify:
+
+1. The command file exists at `commands/scr/{name}.md`
+2. The CONSTRAINTS.json entry matches the file
+3. The description in frontmatter matches CONSTRAINTS.json
+4. If the command references other files, those files exist
+
+## Documenting a Release
+
+When a package release changes the public story, update the release docs alongside the code.
+
+### Release docs to update
+
+- `CHANGELOG.md` -- package-level release history
+- `docs/release-notes.md` -- public-facing summary of what changed and why it matters
+- `README.md` -- current version/status blurb when the release changes the headline positioning
+- `docs/shipped-assets.md` -- canonical inventory when bundled docs, templates, proof assets, or trust-critical files change
+- `docs/command-reference.md` -- command contract reference when command behavior or flags change
+- `templates/*/README.md` and `data/proof/*/README.md` -- shipped profile and proof documentation when those assets change
+- `.planning/` milestone summary files -- only when the release closes out milestone work or changes the archive story
+
+### Minimum release checklist
+
+1. Bump the package version in `package.json` and any mirrored version metadata such as `data/CONSTRAINTS.json`
+2. Update `CHANGELOG.md` with the new version and the user-visible changes
+3. Update `docs/release-notes.md` with a concise explanation of what changed, why, and how it was verified
+4. Run `npm test`
+5. Run `npm run release:check`
+6. Publish only after the docs and package metadata tell the same story
+
+## Code Style
+
+Scriveno follows these conventions:
+
+- **Markdown files** -- All commands, agents, and templates are markdown
+- **YAML frontmatter** -- Delimited by `---` on its own line, top and bottom
+- **No build step** -- Changes take effect immediately (the agent reads files at runtime)
+- **Friendly, direct tone** -- Write instructions as if talking to a capable colleague
+- **Real examples** -- Use actual codebase patterns, not invented ones
+- **Self-contained sections** -- Each command file should work without reading other files (except CONSTRAINTS.json and config.json)
+
+### Frontmatter conventions
+
+Command frontmatter uses lowercase keys with hyphens:
+
+```yaml
+---
+description: What this command does in one line.
+argument-hint: "[optional args] <required args>"
+---
+```
+
+Agent frontmatter uses lowercase keys:
+
+```yaml
+---
+name: agent-name
+description: What this agent does.
+tools: Read, Write
+---
+```
+
+## Questions?
+
+Check the [architecture overview](architecture.md) for how the whole system fits together, or the [command reference](command-reference.md) for the full list of commands and their usage.

package/docs/creative-context.md

@@ -0,0 +1,158 @@
+# Creative Context
+
+Creative Context is Scriveno's writer-native context routing protocol. It gives commands a light way to know which project files matter for a task without turning a manuscript into a process artifact.
+
+The protocol is a pilot for the core writing loop:
+
+`discuss -> plan -> draft -> editor-review -> next`
+
+It is additive. Existing projects without metadata continue to work because every command still recognizes the historical `.manuscript/*.md` files.
+
+## Purpose
+
+Creative Context solves three problems:
+
+- **Memory:** choices made in conversation should travel into plans, drafts, and reviews.
+- **Trust:** commands should load the right creative truth instead of re-reading everything or guessing.
+- **Continuity:** open questions and watchpoints should remain visible without blocking creative momentum.
+
+## Principles
+
+1. `STYLE-GUIDE.md` is sovereign. It always loads first for drafting, voice checks, translation, and any task that can affect prose voice.
+2. Metadata routes context. It does not replace the existing files.
+3. Creative uncertainty is allowed. A `QUESTION` can block, but it can also travel forward as a `WATCHPOINT`.
+4. Writer-facing language stays writer-native. Commands should say voice, continuity, readiness, question, and watchpoint, not compliance or tier.
+5. Drafted prose never receives craft labels. Labels belong in context, plans, and reviews.
+
+## Domain Grilling
+
+Domain grilling is the Creative Context habit of making language precise before it becomes a plan, draft, review, or published document. It applies most strongly to technical, academic, sacred, series, and worldbuilding-heavy projects, but it can help any work where terms carry continuity.
+
+Use it when a writer introduces a fuzzy term, a loaded term, a term that conflicts with established project language, or a claim about how the work's world, system, doctrine, argument, procedure, or cast already behaves.
+
+The rules:
+
+1. Check the project first. If WORK.md, RECORD.md, STYLE-GUIDE.md, WORLD.md, SYSTEM.md, PROCEDURES.md, REFERENCES.md, DOCTRINES.md, QUESTIONS.md, CHARACTERS.md, FIGURES.md, or prior drafts can answer the question, read them instead of asking the writer.
+2. Challenge conflicts immediately. If the writer says "account" but REFERENCES.md defines "workspace" as the thing being discussed, name the mismatch and ask which term should win.
+3. Sharpen fuzzy language. Propose a precise canonical term when a phrase can mean more than one thing.
+4. Test concrete scenarios. Use one specific edge case to expose unclear boundaries, especially for procedures, doctrines, magic systems, character knowledge, source handling, and reader promises.
+5. Ask one question at a time and include a recommended answer. Do not make the writer sort through a survey unless the work is still in broad discovery.
+6. Capture the resolution where it belongs:
+   - Unit-specific choices go in `.manuscript/{N}-CONTEXT.md` as `CHOICE`, `QUESTION`, or `WATCHPOINT`.
+   - Durable established facts, definitions, promises, and procedure truths go in RECORD.md.
+   - Technical canonical terminology and sources of truth go in REFERENCES.md.
+   - World, doctrine, audience, system, procedure, character, or theme decisions go in their matching adapted source file.
+
+Do not turn `.manuscript/CONTEXT.md` into a glossary. It is an auto-regenerated bootstrap, not a decision notebook.
+
+## Pillar Map
+
+| Creative pillar | Existing source files | Role |
+|---|---|---|
+| `voice` | `STYLE-GUIDE.md` | Authorial voice, register, sentence music, hard do and do-not rules |
+| `work` | `WORK.md`, `BRIEF.md` | Project identity, premise, audience, reader promise |
+| `structure` | `OUTLINE.md`, `PLOT-GRAPH.md` | Unit order, arc shape, pacing, setup and payoff |
+| `record` | `RECORD.md` | Established content, open threads, promises, payoffs, continuity facts, movement, and next-unit obligations |
+| `cast` | `CHARACTERS.md`, `FIGURES.md` | Character state, voice anchors, relationships, figure continuity |
+| `world` | `WORLD.md`, `COSMOLOGY.md`, `SYSTEM.md` | Setting, constraints, environment, cosmology, operating rules |
+| `themes` | `THEMES.md`, `DOCTRINES.md`, `QUESTIONS.md` | Motifs, doctrine, argument, inquiry, recurring meaning |
+| `continuity` | `STATE.md`, `CONTEXT.md`, `HISTORY.log` | Current position, recent activity, open items, disk truth |
+| `publication` | front matter, back matter, build files | Export and publishing intent |
+| `translation` | glossary, translation memory, language config | Term consistency and cultural adaptation |
+| `art` | cover, illustration, storyboard assets | Visual continuity and image direction |
+
+The v2.1 pilot only changes the core writing loop. Publication, translation, art, and sacred expansion can adopt the same protocol later.
+
+## Template Metadata
+
+Templates may include optional frontmatter:
+
+```yaml
+---
+creative_pillar: voice
+always_load_for: [draft, voice-check, plan, editor-review, translate]
+authority: sovereign
+---
+```
+
+Commands should treat this metadata as routing help. If the metadata is absent, fall back to the file's established role.
+
+## Craft Notes
+
+Discuss, plan, and review artifacts can carry four labels:
+
+| Label | Meaning | Blocks drafting? |
+|---|---|---|
+| `CHOICE` | Confirmed creative decision | No |
+| `HUNCH` | Creative bet to test in drafting | No |
+| `QUESTION` | Unresolved issue for writer or editor | Only when marked blocking |
+| `WATCHPOINT` | Thing to preserve, test, or re-check later | No |
+
+Use labels in context files, plan files, and review reports. Do not insert them into manuscript prose.
+
+Recommended section:
+
+```markdown
+## Craft Notes
+
+- CHOICE: Keep the chapter close third from Mara's point of view.
+- HUNCH: Let the room feel colder after the argument without explaining why.
+- QUESTION: Blocking: does Elias know about the forged letter yet?
+- WATCHPOINT: Preserve Mara's clipped dialogue when she is afraid.
+```
+
+## Command Behavior
+
+### discuss
+
+Capture the writer's confirmed choices, creative hunches, open questions, and watchpoints in `.manuscript/{N}-CONTEXT.md`.
+
+When the conversation touches established content, also capture `## Record Notes`: what RECORD.md says this unit must honor, what thread or promise the unit may handle, and what the draft or review should add to RECORD.md after the unit lands.
+
+Before capturing, run domain grilling on any fuzzy term, overloaded term, or claim that may contradict the project's established language. Resolve only what matters for the current unit. If a canonical term or source-of-truth decision becomes durable, route it to RECORD.md, REFERENCES.md, or the adapted source file instead of leaving it only in the unit context.
+
+### plan
+
+Load craft notes from `{N}-CONTEXT.md`. Convert confirmed choices into plan constraints, hunches into draftable tests, questions into blocking or non-blocking items, and watchpoints into plan checks.
+
+Load RECORD.md as the compact established-content store. Plans should include `## Record Notes` when the unit touches established facts, open threads, reader promises, payoffs, continuity facts, or next-unit obligations.
+
+Run a domain model check before drafting: compare the plan's terms and assumptions against RECORD.md, REFERENCES.md, and the relevant adapted source files. If the plan uses a term differently than the project does, either revise the plan language or mark a blocking question.
+
+### draft
+
+Pass craft notes through the plan file to the drafter. The drafter follows `CHOICE`, dramatizes `HUNCH` where useful, respects `WATCHPOINT`, and makes the safest call on non-blocking `QUESTION` items. Blocking questions must be resolved before drafting.
+
+Pass Record Notes and RECORD.md to the drafter when present. After drafting, update RECORD.md with compact reader-visible changes: established facts, open threads, promises, payoffs, continuity facts, movement, and next-unit obligations. Do not turn every beat into a record entry.
+
+Character persona notes are part of the same loop. Plans can include `## Character Persona Notes` for pressure behavior, relationship-specific interactions, dialogue constraints, and pairwise trust or conflict patterns. The drafter turns those notes into behavior on the page, never exposition.
+
+Subject dynamics can layer onto any work type. Plans can include `## Subject Dynamics Notes` for the active idea, subject, process, place, object, doctrine, claim, evidence set, procedure, reader problem, or thematic pressure. These notes track the reader's starting state, the desired shift, the pressure or friction around the subject, and the interaction between ideas, evidence, steps, exceptions, images, objects, settings, or themes. The drafter turns those notes into movement on the page, never into visible craft labels.
+
+For character-based work, use both sections when both layers matter. `## Character Persona Notes` answers how people behave under pressure. `## Subject Dynamics Notes` answers how meaning, theme, object significance, setting pressure, doctrine, argument, or reader understanding moves through the unit. If the two sections conflict, the plan should resolve the conflict before drafting rather than asking the drafter to guess.
+
+When a draft changes subject movement after the plan has already landed, `/scr:subject-touch` updates the relevant living subject file, such as THEMES.md, QUESTIONS.md, REFERENCES.md, DOCTRINES.md, PROCEDURES.md, ARGUMENT-MAP.md, or an adapted context file.
+
+Edge cases:
+
+- If a unit has characters but they are not driving the scene, subject dynamics may be the primary section and character notes may be omitted.
+- If a unit has no named characters but does have a speaker, narrator, implied reader, or instruction-following user, use subject dynamics and voice notes rather than inventing character persona.
+- If an object, place, symbol, procedure, claim, or doctrine changes meaning because of a character interaction, include both sections and state the handoff clearly.
+- If subject dynamics repeat a character note without adding reader movement, omit the duplicate.
+- If subject dynamics would expose hidden craft scaffolding in drafted prose, keep it in the plan and review only.
+
+### editor-review
+
+Review whether choices held, hunches worked, questions were resolved, and watchpoints were preserved. Store results in `.manuscript/reviews/{N}-REVIEW.md`.
+
+Review whether the draft honored RECORD.md and list any confirmed record updates. If the draft contradicts RECORD.md, resolve the contradiction before marking the unit reviewed.
+
+### next
+
+When state is ambiguous, prefer the next core-loop step. If a blocking question exists, route to `/scr:discuss N`. If only non-blocking questions or watchpoints exist, allow drafting or review to proceed while naming the watchpoint.
+
+When RECORD.md shows a real branch, such as an open promise competing with the linear next unit, surface the branch instead of forcing a single path.
+
+## Backward Compatibility
+
+No command may require `creative_pillar` metadata for existing projects. The metadata is a hint for new templates and a future optimization surface, not a new file-format gate.