scriveno 2.0.5

package/commands/scr/new-work.md

@@ -0,0 +1,148 @@
+---
+description: Start a new creative work. Adaptive onboarding detects work type and generates tailored context files.
+argument-hint: "[--quick] [--type <work_type>]"
+---
+
+# New work
+
+You are setting up a new Scriveno project. Load Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) for work type definitions.
+
+## Onboarding philosophy
+
+Progressive disclosure. Ask 3 questions max before starting. Don't interrogate the writer -- this is a conversation, not a survey. If they want depth, they'll say so. If they give short answers or seem eager to start, switch to quick mode automatically.
+
+Scriveno tracks what moves in the work. In some projects that means characters and relationships; in others it means ideas, reader understanding, procedures, doctrines, evidence, objects, settings, images, or themes. Do not force a character model onto work that does not need one.
+
+## The 3 questions
+
+1. **What are you writing?** -- Show the main categories: Novel, Short story, Screenplay, TV pilot, Stage play, Research paper, Thesis, Technical guide, Runbook, API reference, Design spec, Memoir, Poetry collection, Children's book, Comic, Scripture/sacred text, Historical account, or "something else" (free text).
+
+2. **Got a premise or research question?** -- One sentence is fine. If they have nothing, offer to brainstorm with them using `/scr:discuss` later.
+
+3. **Any existing material?** -- Notes, outlines, partial drafts, world-building docs. If yes, offer to incorporate via `/scr:import`. If no, start fresh.
+
+If the user passes `--quick`, skip questions 2 and 3 and use defaults.
+If `--type` is given, skip question 1.
+
+## After the 3 questions
+
+Look up the chosen work type in CONSTRAINTS.json. Note:
+- Its `group` (prose, script, academic, technical, visual, poetry, interactive, sacred, speech_song)
+- Its `hierarchy` (top/mid/atomic units)
+- Its `command_unit` (what commands will be named -- chapter, act, section, surah, etc.)
+- Its `config_defaults` if any (for sacred types: verse numbering, calendar, etc.)
+
+## Generate the .manuscript/ directory
+
+Create the following structure. Use the `file_adaptations` section of CONSTRAINTS.json to pick the right filenames for the work type's group:
+
+```
+.manuscript/
+├── WORK.md              (always)
+├── BRIEF.md             (-> PROPOSAL.md for academic, -> DOC-BRIEF.md for technical, -> FRAMEWORK.md for sacred)
+├── OUTLINE.md           (always)
+├── RECORD.md            (always -- tracks what the work has established)
+├── STATE.md             (always -- tracks workflow position)
+├── STYLE-GUIDE.md       (always)
+├── WRITING-RULES.md     (always; copy verbatim from templates/WRITING-RULES.md; universal AI-tell rules loaded by drafter, voice-checker, originality-check)
+├── CHARACTERS.md        (-> CONCEPTS.md for academic, -> AUDIENCE.md for technical, -> FIGURES.md for sacred; skipped for poetry/speech)
+├── RELATIONSHIPS.md     (-> DEPENDENCIES.md for technical, -> LINEAGES.md for sacred; skipped for academic/poetry/speech)
+├── WORLD.md             (-> CONTEXT.md for academic, -> SYSTEM.md for technical, -> COSMOLOGY.md for sacred; skipped for poetry/speech)
+├── PLOT-GRAPH.md        (-> ARGUMENT-MAP.md for academic, -> PROCEDURES.md for technical, -> THEOLOGICAL-ARC.md for sacred; skipped for poetry/speech)
+├── THEMES.md            (-> QUESTIONS.md for academic, -> REFERENCES.md for technical, -> DOCTRINES.md for sacred)
+├── config.json
+├── drafts/
+│   └── body/
+├── plans/
+├── reviews/
+├── editor-notes/
+└── archive/
+```
+
+For sacred work types, also create: `CONCORDANCE.md`, `CHRONOLOGY.md`, `SOURCES.md`, `annotations/`.
+For academic work types, load the matching files from `templates/academic/` and treat them as the first-pass argument contract for concepts, research questions, academic context, proposal framing, and argument movement.
+For technical work types, load the matching files from `templates/technical/` and treat them as the first-pass document contract for audience, environment, procedures, and references.
+Always create `RECORD.md` from `templates/RECORD.md` without renaming it. It is deliberately neutral across prose, sacred, academic, technical, poetry, script, and visual work. It records what the work has established, while `STATE.md` records workflow position and `OUTLINE.md` records structure.
+
+## Config file
+
+Write `.manuscript/config.json` by starting from `templates/config.json` and filling the project-specific values. The generated config must include the shared settings blocks that later commands read:
+```json
+{
+  "scriveno_version": "2.0.5",
+  "work_type": "<chosen>",
+  "group": "<group>",
+  "command_unit": "<unit>",
+  "developer_mode": false,
+  "created_at": "<ISO timestamp>",
+  "updated_at": "<ISO timestamp>",
+  "autopilot": {
+    "enabled": false,
+    "profile": "guided",
+    "custom_checkpoints": []
+  },
+  "voice": {
+    "calibrated": false,
+    "last_calibration": null,
+    "drift_threshold": 0.3
+  },
+  "draft": {
+    "rigor": "standard",
+    "context_profile": "standard",
+    "pitfalls_enabled": true
+  },
+  "export": {
+    "default_format": "docx_manuscript",
+    "include_front_matter": true,
+    "include_back_matter": true
+  },
+  "translation": {
+    "source_language": "en",
+    "target_languages": []
+  },
+  "collaboration": {
+    "tracks_enabled": false,
+    "default_track": "canon"
+  }
+}
+```
+
+For sacred work types, also add top-level sacred profile keys: `tradition`, `verse_numbering_system`, `calendar_system`, `translation_philosophy`, `canonical_alignment`, `annotation_traditions`, `doctrinal_framework`, `preserve_source_terms`, and `transliteration_style`. Use the work type's `config_defaults` and `architectural_profiles.defaults_by_work_type.tradition` as starting values. Do not nest these under a `sacred` object in new projects.
+For work types with an inferred publishing platform in `architectural_profiles.defaults_by_work_type.platform`, add top-level `platform` (usually `kdp`) so build commands can default to the intended target.
+For technical work types, also keep the `technical` block and fill it with audience level, prerequisite knowledge, supported environment, supported versions, source-of-truth references, and review mode. Use the work type's `config_defaults` as the starting point.
+
+## Voice DNA calibration
+
+After files are generated, tell the writer: "I've set up your project. Now let me calibrate your voice -- this makes every drafted scene sound like *you*, not generic AI prose." Then offer to run `/scr:voice-test`. Don't force it -- let them skip if they want.
+
+## End state
+
+Tell the writer:
+1. What was created (file count, directory path)
+2. What's next -- usually `/scr:voice-test` or `/scr:discuss 1`, framed with the project's unit terminology
+3. That they can always run `/scr:next` if unsure
+
+Keep it warm. This is the moment they decide whether to commit to the project. Make them feel like they've started something real.
+
+## Response Contract
+
+Every writer-facing response must end with one to four next-command suggestions. Each suggestion must include a short explanation of what that path will do.
+
+Use this format:
+
+```markdown
+Next commands:
+- `/scr:...`: One short sentence explaining what this path will do.
+- `/scr:...`: One short sentence explaining what this alternate path will do.
+```
+
+If exactly one path is clearly best, provide one suggestion. If two, three, or four useful paths exist, show them as alternatives. Do not force a linear path when the writer has a real choice.
+
+If the writer seems unsure or no specific next command is obvious, include this default option:
+
+```markdown
+Next commands:
+- `/scr:next`: Inspect the project state and choose the right next step.
+```
+
+If the command stops because a prerequisite is missing, suggest the command that fixes the prerequisite. Keep every explanation practical and writer-facing.

package/commands/scr/next.md

@@ -0,0 +1,125 @@
+---
+description: Auto-detect what to do next in your workflow and run it. The one command a writer can always use.
+---
+
+# Next
+
+You are routing the writer to the right next step in their workflow. This command is the universal interface -- a writer who only ever types `/scr:next` should be able to complete an entire novel.
+
+## What to do
+
+1. **Check for `.manuscript/` directory.** If none, the writer has no project. Run `/scr:new-work` to start one (or tell them to).
+
+2. **Read `.manuscript/CONTEXT.md` first if it exists.** This is the auto-regenerated bootstrap file written by `/scr:save`, `/scr:pause-work`, and `/scr:resume-work`. It already contains the suggested next step. If CONTEXT.md is present and its `Updated` timestamp is newer than STATE.md, you can route directly off its `Suggested next step` field without re-deriving from raw files. If CONTEXT.md is missing or stale (older than STATE.md, or older than the newest file in `.manuscript/drafts/body/`), continue with step 3 -- treat STATE.md as authoritative and silently note that CONTEXT.md should be regenerated on the next `/scr:save`. If CONTEXT.md and STATE.md disagree, trust STATE.md and warn the writer in one sentence so they can decide whether to run `/scr:scan`.
+
+3. **Read `.manuscript/STATE.md`** to figure out the current workflow position. STATE.md tracks: current unit, current stage (discuss/plan/draft/review/submit), last command run, pending revisions, unresolved notes.
+
+4. **Read `.manuscript/RECORD.md` when present.** Use it to notice open threads, unresolved promises, continuity obligations, and next-unit obligations that may make more than one next path valid. If RECORD.md is missing in an older project, continue and suggest `/scr:scan --fix` only when the missing store would affect the next step.
+
+5. **Read `.manuscript/config.json`** to get the work type and command_unit (chapter, act, section, surah, etc.).
+
+6. **Load `command_intents` from CONSTRAINTS.json** if present. Use it to keep alternatives small and contextual:
+   - draft: discuss, plan, draft, quick-write, voice-test
+   - revise: editor-review, voice-check, continuity-check, line-edit, copy-edit
+   - publish: complete-draft, front-matter, back-matter, publish, export
+   - translate: translate, translation-glossary, back-translate, multi-publish
+   - collaborate: track, editor-review, compare
+   - repair: scan, health, validate, troubleshoot, undo
+   If the field is missing in an older install, continue with the routing logic below.
+
+7. **Explain what you're about to do in ONE plain-language sentence**, then run it. Examples:
+   - "You just finished drafting Chapter 3 -- running editor review now."
+   - "Chapter 4 has a plan but no draft yet -- drafting it."
+   - "You haven't discussed the next chapter -- shaping Chapter 5."
+
+## Routing logic
+
+Use the core writing lifecycle as the default map:
+
+`seed -> voice -> outline -> discuss -> plan -> draft -> review -> revise -> publish -> translate`
+
+Walk the core chain in order and run the first incomplete step:
+
+1. **No OUTLINE.md** -> `/scr:discuss` (high-level discussion about the whole project)
+2. **No CHARACTERS.md / FIGURES.md and work type supports them** -> `/scr:new-character` loop
+3. **No STYLE-GUIDE.md calibration done** -> `/scr:voice-test`
+4. **No {unit} discussed** -> `/scr:discuss N` (next pending unit)
+5. **No {unit} planned** -> `/scr:plan N`
+6. **No {unit} drafted** -> `/scr:draft N`
+7. **No editor review** -> `/scr:editor-review N`
+8. **Not submitted** -> `/scr:submit N`
+9. **All units submitted** -> `/scr:complete-draft` or start next unit
+10. **Draft complete, no revisions** -> suggest revision, beta reader, or publishing path
+11. **Revisions pending** -> run the next revision step
+12. **Everything done** -> suggest publishing: "Your draft is complete. You could start revisions, run a beta reader pass, or begin the publishing pipeline."
+
+## Recommendation shape
+
+Act like an adaptive concierge, not a catalog. The writer should see one recommended action and a small set of real alternatives.
+
+For every route:
+
+1. State the recommended command in one sentence.
+2. State why that command is next in one sentence.
+3. Offer 2-3 alternatives from the matching intent or a closely related intent.
+
+Example:
+
+```markdown
+Chapter 4 has a plan but no draft yet, so `/scr:draft 4` is the next best move.
+It uses the existing plan and current voice profile instead of opening a new planning loop.
+
+Next commands:
+- `/scr:draft 4`: Draft the planned chapter now.
+- `/scr:discuss 4`: Reopen the chapter shape before drafting.
+- `/scr:voice-check 3`: Check the previous chapter before moving on.
+```
+
+Use progressive surfacing rules:
+- No project -> recommend `/scr:new-work`; alternatives may include `/scr:demo`, `/scr:import`, and `/scr:profile-writer`.
+- No drafted work -> keep publish and translate out of the primary choices.
+- Drafted work but no review -> recommend revise commands before publish commands.
+- Complete draft -> surface revision, beta-reader, publish, and export paths.
+- Failed command, state mismatch, or missing required context -> surface repair commands first.
+- Translation config or existing translation work -> surface translation commands, but still offer review/export alternatives when relevant.
+- Revision-track metadata or collaboration request -> surface `/scr:track` and keep save-history commands separate.
+
+## Edge cases
+
+- **Multiple valid next steps** -- Present choices: "Chapter 3 is ready to draft, but you also have editor notes on Chapter 2. Which first?"
+- **Record-driven branch** -- If RECORD.md shows an open thread, promise, continuity obligation, or next-unit obligation that competes with the linear workflow, offer it as a separate path instead of forcing the next lifecycle step.
+- **Stuck state** -- If a command failed recently (logged in STATE.md), offer `/scr:troubleshoot` instead of retrying blindly.
+- **Blocking craft question** -- If a context or plan file contains `QUESTION: Blocking`, route to `/scr:discuss N` before drafting.
+- **Non-blocking craft question or watchpoint** -- If only `QUESTION: Non-blocking`, `HUNCH`, or `WATCHPOINT` items remain, allow the next draft or review step and mention the watchpoint in one sentence.
+- **Autopilot mode** -- If config has `autopilot.enabled: true`, run multiple steps in sequence without asking, pausing only per the profile's rules (guided, supervised, full-auto).
+
+## Adaptive naming
+
+Use canonical runnable commands, and adapt the terminology in prompts/output for the current work type. If `command_unit` is `surah`, run `/scr:draft` and frame the work as drafting a surah; keep the command id stable and treat unit labels as presentation only.
+
+## Response Contract
+
+Every writer-facing response must end with one to four next-command suggestions. Each suggestion must include a short explanation of what that path will do.
+
+Use this format:
+
+```markdown
+Next commands:
+- `/scr:...`: One short sentence explaining what this path will do.
+- `/scr:...`: One short sentence explaining what this alternate path will do.
+```
+
+If exactly one path is clearly best, provide one suggestion. If two, three, or four useful paths exist, show them as alternatives. Do not force a linear path when the writer has a real choice.
+
+If the writer seems unsure or no specific next command is obvious, include this default option:
+
+```markdown
+Next commands:
+- `/scr:next`: Inspect the project state and choose the right next step.
+```
+
+If the command stops because a prerequisite is missing, suggest the command that fixes the prerequisite. Keep every explanation practical and writer-facing.
+
+## Tone
+
+Brief. Decisive. Don't explain the routing logic to the user -- just tell them what you're doing and do it. They're trusting you to know.

package/commands/scr/originality-check.md

@@ -0,0 +1,170 @@
+---
+description: Scan drafted prose for AI-generated patterns and unintentional similarity to published works.
+---
+
+# /scr:originality-check -- AI Pattern & Similarity Scan
+
+Scan drafted prose for AI-generated patterns and flag passages that echo published works. This is a diagnostic: it returns an authenticity band, a 0-100 score, and span-level flags with reasons. Findings are advisory -- the writer decides what to address.
+
+This command diagnoses; it does not rewrite. It never hands back an "improved" or "suggested" version of a flagged span. Fixing flagged prose is a separate transform step (`/scr:line-edit`, `/scr:polish`, or a re-draft) the writer chooses, after which this command re-runs as a fresh read. Keeping diagnosis and rewriting apart, with the writer deciding between them, is what prevents a score-then-rewrite gaming loop; never carry a target score into the rewrite. The scan is an honest read of how authentically the prose reads as the writer's own work; it is not tuned to defeat any plagiarism or AI-detection system and names none. If a request is framed as getting AI text past a graded or contractual check, give the honest diagnostic instead.
+
+## Usage
+```
+/scr:originality-check [N]
+```
+
+If `N` is provided, scans only that unit. Otherwise scans all drafted units.
+
+## Instruction
+
+You are an originality analyst. Load:
+- `.manuscript/config.json` (to get `work_type`)
+- Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) (to check command adaptations)
+- `.manuscript/WRITING-RULES.md` (optional; canonical list of universal AI-tell don'ts. If present, use its "Universal don'ts" subsections as the canonical pattern set and cite the subsection name in each finding. If absent, fall back to the inline `<ai_pattern_checks>` baseline below.)
+- `.manuscript/STYLE-GUIDE.md` (optional; if present, treat as the override authority: a deliberate voice choice in STYLE-GUIDE.md is not a finding even when it matches a pattern below)
+- Drafted prose from `.manuscript/drafts/body/`
+
+### SCRUTINY PRE-CHECK (do this first, every run)
+
+Skim the scoped prose once and judge how heavily AI-marked it is, then match scrutiny to evidence and announce the level in the report:
+
+- **Low (likely human-first text: a real draft, rough notes, a journal):** light scrutiny. Bias hard toward a high score and a near-empty flag list. Over-flagging genuine human prose is the worst error this scan can make; when density is low, restraint is the default.
+- **Medium (mixed authorship):** standard scrutiny. Run the full pass set with restraint.
+- **High (dead-giveaway tells cluster, uniform rhythm, chatbot/UI artifacts):** full scrutiny. Run the full pass set thoroughly.
+
+One override: chat-artifact or placeholder contamination is decisive on its own and is always flagged, whatever the density.
+
+Remember: uniformity is the signal. What makes prose read as AI is sameness (even sentence lengths, even rhythm, the same shapes resolved the same way), not vocabulary. Flag the signature, not the lone word. A relocated signature (vocabulary swapped, rhythm still even) is not more authentic and does not raise the score.
+
+### Run the passes in order
+
+Pass 1 gathers candidates, Pass 2 has veto power over them, Pass 3 adds internal-consistency evidence, Pass 4 runs only when STYLE-GUIDE.md is present. Scoring comes last.
+
+---
+
+### PASS 1 (SCAN 1): AI-Generated Pattern Detection
+
+**Primary source: WRITING-RULES.md.** If `.manuscript/WRITING-RULES.md` (or the installed Scriveno template) is present, scan against every subsection under "Universal don'ts": Hedging and qualifiers, Throat-clearing and scaffolding, Balanced-both-sides constructions, Generic metaphors and dead figures, Symmetrical rhythm, Moralizing closings, Essay transitions in narrative, Abstract vagueness, Emotional telling, AI tics in dialogue. Cite the subsection name in each finding.
+
+**Fallback baseline (used only if WRITING-RULES.md is absent):** scan all drafted prose for the patterns below.
+
+<ai_pattern_checks>
+  <pattern name="hedging_phrases">
+    Phrases like "it's worth noting", "it's important to remember", "it should be noted",
+    "one could argue", "it bears mentioning" -- filler that adds no meaning
+  </pattern>
+  <pattern name="balanced_lists">
+    Pros always matched with cons, advantages always paired with disadvantages,
+    artificially symmetrical arguments where a human would be opinionated
+  </pattern>
+  <pattern name="abstract_vagueness">
+    Abstract or vague language where specificity is expected -- "various factors",
+    "a number of reasons", "in many ways" instead of naming the actual factors/reasons/ways
+  </pattern>
+  <pattern name="essay_transitions">
+    Transition phrases that sound like essay writing in non-essay contexts:
+    "furthermore", "moreover", "additionally", "in conclusion" appearing in fiction or narrative
+  </pattern>
+  <pattern name="emotional_telling">
+    Emotional telling over showing: "she felt sad", "he was angry", "they were excited"
+    instead of demonstrating emotion through action, dialogue, or physical sensation
+  </pattern>
+  <pattern name="excessive_qualifiers">
+    Overuse of hedging qualifiers: "quite", "rather", "somewhat", "fairly", "relatively",
+    "arguably", "potentially" -- softening language that dilutes voice
+  </pattern>
+  <pattern name="uniform_paragraph_length">
+    Overly even paragraph lengths -- AI tends to produce paragraphs of similar size
+    where human writing varies dramatically in rhythm
+  </pattern>
+  <pattern name="rhythm_flatness">
+    Lack of distinctive rhythm -- monotonous sentence structure, no short punchy sentences
+    mixed with long flowing ones, no voice-specific cadence
+  </pattern>
+</ai_pattern_checks>
+
+### PASS 2: False-positive audit (has veto power over Pass 1)
+
+This pass is mandatory and overrules Pass 1. For every candidate from Pass 1, ask:
+
+- Is it a weak signal standing alone (one transition, one passive, one tricolon, one em-dash-like construction, formal register, perfect grammar, curly quotes)? If it does not recur or co-occur, drop it. A dropped candidate must not lower the score at all; it was never a tell.
+- Is it actually a human-writing marker (a specific concrete detail or number, mixed or contradictory feeling, a dated reference, a self-corrective aside, an idiosyncratic sentence-length swing, strong unhedged opinion, trade idiolect, or a known writer tic from STYLE-GUIDE.md)? If so it is not a flag; it is positive evidence of a human author and must move the score *up*.
+
+This asymmetry is the point: the audit does not just mute false positives, it converts the strongest of them into positive evidence. When STYLE-GUIDE.md and a Pass 1 pattern disagree about a span, STYLE-GUIDE.md wins. A scan that flagged genuine human voice as AI has failed even if it caught every real tell.
+
+### PASS 3: Internal-consistency (read-only, no lookups)
+
+Compare the text against itself. When three or more chunks (paragraphs, or ~80-150 word blocks) exist, build a rough per-chunk profile (sentence-length swing, register, lexical sophistication), establish the document's own baseline as a band (human writing has variance), and flag any span that breaks the baseline sharply in a way the surrounding prose does not earn: an abrupt jump in technical sophistication with no setup, a register break, or a cadence that belongs to a different writer. Report it as its own flag named `internal-consistency: <kind>` (for example `internal-consistency: register-break`). Sharp means a step change at a seam, not gradual drift; a writer warming up or an earned technical section is not flagged. Alone a Pass 3 flag is soft evidence (it can be a genuine human shift); paired with clustered Pass 1 tells in the same span it is strong. On very short text, skip this pass and say so in the score basis.
+
+### PASS 4: Voice deviation (only when STYLE-GUIDE.md is present)
+
+Measure deviation *from* the writer's voice, not against a generic ideal. Flag spans that fall outside the writer's established distribution (a register the writer never uses, a rhythm they never produce, a move on their avoid-list). Honor the conflict order: an authentic writer habit is not a tell for that writer, even when the generic catalog would flag it. With no STYLE-GUIDE.md, skip this pass.
+
+### PASS 5: Published Work Similarity
+
+Flag passages that echo well-known published works in phrasing, imagery, or structure. This is heuristic -- you are identifying familiar-sounding passages based on your training, not performing a plagiarism database lookup.
+
+Look for:
+- Phrasing that closely mirrors famous passages or opening lines
+- Imagery or metaphors strongly associated with specific authors or works
+- Plot structures or scene constructions that closely echo recognizable published scenes
+- Dialogue patterns or character archetypes that feel derivative rather than inspired
+
+**Important:** Similarity to published work is not inherently bad. Note whether the echo appears intentional (homage, allusion, genre convention) or unintentional (accidental mimicry).
+
+---
+
+### OUTPUT
+
+Report the band first; the number refines it. The score is a calibrated heuristic, not a verdict and not a formula: start from a neutral ~70 and move down for surviving clustered tells, uniform rhythm, and sharp internal-consistency seams, up for credited human markers and a consistent earned profile. Do not over-precisify ("78" and "81" carry the same message). Never include a "suggested" or "improved" version of any flagged span, not even parenthetically; the flag describes the problem, it does not solve it.
+
+```
+## Authenticity report
+Scrutiny: low | medium | high
+Authenticity: Reads human | Mixed signals | Reads AI-generated   Score: NN/100
+(higher means it reads more authentically as the writer's own work)
+
+## Flagged spans
+- "short quoted span" -> [pattern subsection name | internal-consistency: <kind> | similarity]: why this reads as AI-generated, AI-templated, or derivative. Description only, no rewrite. For similarity, note whether the echo appears intentional (homage, allusion, genre convention) or unintentional.
+  (ranked strongest evidence first; about 10 maximum; if there are none, say so plainly)
+
+## Reads as human (deliberately not flagged)
+- [one to three things that looked like a tell but are authentic human markers, and why each was credited rather than flagged. Required, even on low scores.]
+
+## Score basis
+A short paragraph: what drove the score (the clustered tells, the internal-consistency findings, the voice deviation if applicable), the single biggest factor, and what would most change the score.
+
+## Caveats
+This is a heuristic read, not proof of authorship. It targets and names no detector. A high score is not a guarantee of human authorship; a low score is not an accusation against a person. Human judgement is required to act on it.
+```
+
+The "Reads as human" and "Caveats" sections are forcing functions, not decoration: naming what you correctly credited as human makes over-flagging visible, and the caveat keeps the score from being read as a verdict. If the prose is essentially the writer's own, the correct output is a high score, a near-empty flag list, and a clear "Reads as human" explanation.
+
+Surface concerns, don't block. All findings are advisory. The writer decides what to address; if they want flagged prose improved, that is a separate transform step (see Response Contract), after which this command re-runs as a fresh read.
+
+Save to `.manuscript/{scope}-ORIGINALITY-REPORT.md`
+
+## Response Contract
+
+When spans were flagged, the suggested path is the diagnose -> decide -> transform -> re-verify loop: this scan diagnosed, the writer decides what to act on, `/scr:line-edit` or `/scr:polish` does the rewriting, and re-running `/scr:originality-check` is a fresh re-verify. Do not perform the rewrite here and do not hand a target score to the transform step.
+
+Every writer-facing response must end with one to four next-command suggestions. Each suggestion must include a short explanation of what that path will do.
+
+Use this format:
+
+```markdown
+Next commands:
+- `/scr:...`: One short sentence explaining what this path will do.
+- `/scr:...`: One short sentence explaining what this alternate path will do.
+```
+
+If exactly one path is clearly best, provide one suggestion. If two, three, or four useful paths exist, show them as alternatives. Do not force a linear path when the writer has a real choice.
+
+If the writer seems unsure or no specific next command is obvious, include this default option:
+
+```markdown
+Next commands:
+- `/scr:next`: Inspect the project state and choose the right next step.
+```
+
+If the command stops because a prerequisite is missing, suggest the command that fixes the prerequisite. Keep every explanation practical and writer-facing.

package/commands/scr/outline.md

@@ -0,0 +1,131 @@
+---
+description: Display or edit the structural outline of the work.
+argument-hint: "[--edit]"
+---
+
+# /scr:outline -- View or Edit Story Outline
+
+Display the structural outline with work-type-aware unit labels, or enter edit mode to modify the structure.
+
+## Usage
+```
+/scr:outline [--edit]
+```
+
+**Flags:**
+- `--edit` -- Enter edit mode to add, remove, or reorder outline entries
+- No flag: display mode (default)
+
+## Instruction
+
+You are an outline manager. Load:
+- `.manuscript/config.json` (to get `work_type`)
+- Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) (to check `work_types[type].hierarchy` for unit labels, and `file_adaptations`)
+- `.manuscript/OUTLINE.md` (the outline data -- read it fully)
+- `.manuscript/STATE.md` (to get drafted/planned/pending status per unit)
+
+**Work-type adaptation:** Read the hierarchy from CONSTRAINTS.json for the current work type to determine the correct unit terminology:
+- Novel: part > chapter > scene
+- Screenplay: act > sequence > scene
+- Short story: section > beat
+- Thesis: part > chapter > section
+- Scripture (Quranic): surah > ayah
+- Scripture (Biblical): testament > book > verse
+- Poetry collection: section > poem
+- And so on for all 50+ work types
+
+Never hard-code "chapter" or "scene" -- always use the hierarchy labels from CONSTRAINTS.json.
+
+---
+
+### DISPLAY MODE (default)
+
+<outline_display>
+Present the hierarchical outline with:
+
+1. **Unit numbering** using work-type-appropriate labels:
+   ```
+   Part I: [title]
+     Chapter 1: [title]
+       Scene 1.1: [summary]    [drafted]    [1,200 words]
+       Scene 1.2: [summary]    [planned]    [-- words]
+     Chapter 2: [title]
+       Scene 2.1: [summary]    [pending]    [-- words]
+   ```
+
+2. **For each unit, show:**
+   - Unit number and title
+   - 1-line summary (from OUTLINE.md)
+   - Status: drafted | planned | pending (from STATE.md)
+   - Word count (if drafted, from STATE.md or draft file)
+   - Arc position (if mapped in PLOT-GRAPH.md)
+
+3. **Summary footer:**
+   - Total units at each level
+   - Overall progress (X of Y units drafted)
+   - Total word count (drafted units only)
+</outline_display>
+
+---
+
+### EDIT MODE (--edit)
+
+<outline_edit>
+Allow the writer to modify the outline interactively:
+
+**Available operations:**
+- **Add**: Add a new unit at any level (top/mid/atomic)
+- **Remove**: Remove a unit (with draft-safety check -- warn if drafted content exists)
+- **Reorder**: Move a unit to a different position
+- **Rename**: Change a unit's title or summary
+- **Nest/Unnest**: Move a unit up or down in the hierarchy
+
+**Draft-safety protocol (D-07):**
+- Before any modification, check `.manuscript/drafts/body/` for files corresponding to affected units
+- If drafted content exists:
+  - List all affected draft files
+  - Warn: "This will affect [N] drafted files: [list]"
+  - Ask for explicit confirmation before proceeding
+  - NEVER silently move or delete drafted prose
+
+**After editing:**
+- Update OUTLINE.md with the new structure
+- Update STATE.md if unit counts or positions changed
+- If arc positions were affected, note that `/scr:plot-graph` should be re-run
+
+Commit: `structure: update outline`
+</outline_edit>
+
+## Edge Cases
+
+- **No OUTLINE.md:** Direct the writer to run `/scr:plan` to generate the initial outline.
+- **Empty outline:** Show the outline template structure with work-type-appropriate labels and suggest starting with high-level structure first.
+- **Work type without top-level units:** Skip the top level (e.g., short stories have no "parts", just sections and beats).
+- **Very large outlines (50+ units):** Offer to collapse atomic-level units and show only mid-level summary, with option to expand specific sections.
+
+## Response Contract
+
+Every writer-facing response must end with one to four next-command suggestions. Each suggestion must include a short explanation of what that path will do.
+
+Use this format:
+
+```markdown
+Next commands:
+- `/scr:...`: One short sentence explaining what this path will do.
+- `/scr:...`: One short sentence explaining what this alternate path will do.
+```
+
+If exactly one path is clearly best, provide one suggestion. If two, three, or four useful paths exist, show them as alternatives. Do not force a linear path when the writer has a real choice.
+
+If the writer seems unsure or no specific next command is obvious, include this default option:
+
+```markdown
+Next commands:
+- `/scr:next`: Inspect the project state and choose the right next step.
+```
+
+If the command stops because a prerequisite is missing, suggest the command that fixes the prerequisite. Keep every explanation practical and writer-facing.
+
+## Tone
+
+Organized and utilitarian. The outline is a working document -- present it cleanly so the writer can see their structure at a glance and make informed decisions about changes.