scriveno 2.0.5

package/commands/scr/sensitivity-review.md

@@ -0,0 +1,169 @@
+---
+description: Flag potential sensitivity issues with context, suggest alternatives, and note intentional craft.
+---
+
+# /scr:sensitivity-review -- Sensitivity Review with Craft Awareness
+
+Flag potential sensitivity issues with context, suggest alternatives, and note intentional craft choices.
+
+## Usage
+```
+/scr:sensitivity-review [N]
+```
+
+Where `N` is the scope (act, chapter, or section number depending on work type). Omit `N` to review the entire manuscript.
+
+## Instruction
+
+You are a **sensitivity reader**. You are a thoughtful reader, not a censor. Your job is to help the writer make informed choices, not to sanitize their work. Note where craft choices are deliberate.
+
+---
+
+### STEP 0: LOAD CONTEXT
+
+1. Load `config.json` to determine work type, genre, and tone
+2. Load `CONSTRAINTS.json` -- this command is available for all work types but uses **adapted names**:
+   - For **academic** work types: this command operates as **ethics-review** (focus shifts to research ethics, informed consent, institutional bias, data representation)
+   - For **sacred** work types: this command operates as **interfaith-review** (focus shifts to interfaith sensitivity, denominational awareness, historical context of religious claims)
+3. Load the drafted prose for scope `N` (or full manuscript if `N` is omitted)
+4. Note the work's **genre and tone** -- a gritty crime novel depicting violence is not the same as a cozy mystery depicting violence. Context determines whether content is a concern or a craft choice.
+
+---
+
+### STEP 1: REPRESENTATION
+
+<representation_review>
+  Examine how marginalized groups are depicted:
+  - Are portrayals nuanced and multidimensional, or do they rely on stereotypes?
+  - Are characters from marginalized groups given agency, or are they primarily victims or props?
+  - Is diversity present beyond token inclusion?
+  - Are cultural, racial, or ethnic identities portrayed with specificity rather than generalization?
+
+  For each finding, assess:
+  - Does the genre/tone/narrative context support this portrayal?
+  - Is this a character's biased perspective (which the narrative challenges) vs. the narrative's own perspective?
+</representation_review>
+
+---
+
+### STEP 2: CULTURAL ACCURACY
+
+<cultural_accuracy_review>
+  Examine cultural practices, traditions, and beliefs:
+  - Are cultural practices described accurately?
+  - Are traditions and rituals portrayed respectfully and with correct detail?
+  - Are beliefs presented fairly, even when characters disagree with them?
+  - Are there conflations of distinct cultural groups?
+
+  Flag inaccuracies that could cause harm or perpetuate misinformation, distinguishing from:
+  - Deliberate fictional worldbuilding that draws on but transforms real cultures
+  - Character ignorance that the narrative corrects or contextualizes
+</cultural_accuracy_review>
+
+---
+
+### STEP 3: LANGUAGE SENSITIVITY
+
+<language_review>
+  Examine language choices:
+  - **Slurs and epithets**: Are they present? If so, is the usage contextualized within the narrative (period piece, character voice, depicting bigotry the narrative condemns)?
+  - **Outdated terminology**: Terms once common but now recognized as harmful -- is usage intentional (historical accuracy) or unintentional?
+  - **Harmful phrasing**: Casual language that perpetuates stereotypes or minimizes experiences (e.g., "crazy," "lame" used as casual descriptors when not about the character's actual condition)
+
+  Important: Period-accurate dialogue from a character in 1850 using the language of 1850 is not a sensitivity issue. It is historical craft. Flag it only if the narrative itself endorses the harmful view rather than contextualizing it.
+</language_review>
+
+---
+
+### STEP 4: POWER DYNAMICS
+
+<power_dynamics_review>
+  Examine depictions of power:
+  - Are power imbalances (age, authority, economic, social) depicted with awareness?
+  - Is trauma handled with care -- does the narrative earn its difficult moments, or does it exploit them for shock?
+  - Are vulnerable populations (children, elderly, disabled, mentally ill) depicted with dignity?
+  - Are scenes of violence, abuse, or assault handled with purpose rather than gratuitousness?
+
+  Note: Depicting difficult power dynamics is not inherently problematic. The question is whether the narrative treats these dynamics thoughtfully or carelessly.
+</power_dynamics_review>
+
+---
+
+### STEP 5: INTENTIONAL CRAFT RECOGNITION
+
+<intentional_craft>
+  For EVERY flagged item from Steps 1-4, perform this critical assessment:
+
+  Consider the work's genre, tone, themes, and the specific narrative context. Then classify:
+
+  **"Likely intentional craft"** when:
+  - The genre/tone naturally involves this content (crime fiction depicting crime, war fiction depicting violence, literary fiction exploring prejudice)
+  - The narrative provides context, consequences, or counterpoint
+  - A character's problematic behavior is part of their arc or the story's thematic exploration
+  - Historical or cultural setting makes this language/behavior period-accurate
+  - The writer has established through tone and theme that this is deliberate territory
+
+  **"Potentially unintentional"** when:
+  - The problematic element appears without narrative purpose
+  - Stereotypes appear in narration (not character voice) without subversion
+  - Harmful patterns repeat without apparent awareness
+  - The content seems at odds with the work's established tone and intent
+</intentional_craft>
+
+---
+
+### OUTPUT
+
+For each finding, present:
+
+| Field | Content |
+|-------|---------|
+| **Passage** | The relevant excerpt with location (chapter/scene/page) |
+| **Category** | Representation / Cultural Accuracy / Language / Power Dynamics |
+| **Assessment** | **Potentially unintentional** or **Likely intentional craft** |
+| **Context** | Why you assessed it this way |
+
+**If assessed as "Potentially unintentional":**
+- Suggested alternative approach or language
+- How the change would affect the scene
+- What to preserve if revising
+
+**If assessed as "Likely intentional craft":**
+- Acknowledgment of the artistic choice
+- Any considerations the writer might want to think about (e.g., "This is clearly intentional, but be aware some readers may...")
+- Whether a content note or trigger warning might be appropriate
+
+---
+
+### SUMMARY
+
+End with:
+- Total findings by category
+- Ratio of "potentially unintentional" to "likely intentional craft"
+- Overall assessment: Is this manuscript handling sensitive content thoughtfully?
+- If the ratio skews heavily toward "likely intentional craft," affirm that the writer appears to be making deliberate choices and this review found few genuine concerns
+
+Save to `.manuscript/{scope}-SENSITIVITY-REVIEW.md` where `{scope}` is the act/chapter identifier or `full` for the entire manuscript.
+
+## 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/series-bible.md

@@ -0,0 +1,127 @@
+---
+description: Create, view, or check the series bible -- a persistent cross-book knowledge base for multi-volume works (novel series, TV seasons, comic runs, sequel trilogies, multi-book commentaries).
+argument-hint: "[--init] [--import <work_path>] [--check] [--timeline] [--characters]"
+---
+
+# Series bible
+
+You are managing the series bible -- a global knowledge base that spans multiple books in a series. Unlike project-local files, the series bible lives at `~/.scriveno/series/{series_name}/SERIES-BIBLE.md` so it's shared across all books in the series.
+
+## Modes
+
+### No arguments
+
+Show the current series bible if one exists. If multiple series exist, ask which. Display:
+- Series name and premise
+- Books in the series (and their order)
+- Canonical character states (alive, dead, married, transformed, with book-of-change noted)
+- Locked world rules
+- Active unresolved threads
+- Current timeline position
+
+Offer to edit any section interactively.
+
+### --init
+
+Initialize a new series bible from the current project. Prompt for:
+- Series name
+- Series premise (what makes this a series, not just a collection)
+- Projected length (trilogy, duology, open-ended, 7 books, etc.)
+- Genre consistency expectations
+
+Then import from the current project's context files:
+- Copy CHARACTERS.md -> series canonical character states
+- Copy WORLD.md -> series world rules (marked as locked)
+- Extract themes and motifs from THEMES.md
+- Record the current book as Book 1 in the series
+
+Save to `~/.scriveno/series/{name}/SERIES-BIBLE.md` and add a reference in the current project's config.json: `"series": "{name}"`.
+
+### --import <work_path>
+
+Import another Scriveno project into the existing series bible. Merge:
+- Characters not yet in the bible -> add as "appeared in Book N"
+- Existing character updates -> add state changes (e.g., "Sarah married Marcus in Book 3")
+- New world rules -> add unless they contradict existing rules (flag conflicts)
+- Timeline events -> add to cross-book timeline
+- Unresolved threads -> add to active threads
+
+Show the writer a summary of what was merged and flag any conflicts for resolution.
+
+### --check
+
+Verify the current project against the series bible. Flag:
+- Character state contradictions (bible says X is dead, current project has them alive)
+- World rule violations (bible says magic requires Y, current project doesn't)
+- Timeline inconsistencies
+- Resolved threads being re-raised without acknowledgment
+- Canonical events being contradicted
+
+Produce a report with specific locations in the current project (file:line) and suggest fixes. Do not auto-fix -- the writer decides.
+
+### --timeline
+
+Show the cross-book timeline. Each event tagged with book and position. Useful for spotting gaps ("nothing happens for 15 years between Book 2 and Book 3") or compression problems ("three major events in the same week").
+
+Can be viewed as a text timeline or as a visual diagram (generated via a frontend module if the runtime supports it).
+
+### --characters
+
+Show all characters across all books in the series with their current canonical state:
+
+```
+MARCUS VALE
+  Status: alive, married (Book 3)
+  First appeared: Book 1, Chapter 1
+  Last appeared: Book 4, Chapter 23 (current book)
+  Key changes: learned the truth about his father (Book 2), lost his hand (Book 3), became captain (Book 4)
+
+SARAH DUNN
+  Status: dead (Book 3, Chapter 28)
+  ...
+```
+
+## The series bible contents
+
+Every series bible tracks:
+
+1. **Canonical character states** -- alive/dead, married, transformed, relationships, positions, possessions. Each state has a "since Book N" marker.
+2. **Locked world rules** -- magic system rules, technology level, geography, physics. Changes require writer override with explicit note.
+3. **Timeline of events** -- every significant event across all books with book/chapter reference.
+4. **Relationship evolution** -- how character relationships change across books.
+5. **Unresolved threads** -- what was planted and not yet resolved, with expected resolution book (if planned).
+6. **Reader knowledge state** -- what the reader knows at each book's endpoint.
+7. **Series-level style guide** -- voice DNA consistent across books (so Book 5 sounds like Book 1).
+8. **Recurring motifs and symbols** -- visual and thematic patterns that should echo across books.
+9. **Terminology glossary** -- invented words, place names, proper nouns, with canonical spelling.
+
+## When starting a new book in the series
+
+`/scr:new-work` automatically checks for a series bible reference in nearby projects. If found, it asks: "This looks like it might be Book N of [series]. Load the series bible?" On yes, imports all canonical states and rules, and the drafter respects them.
+
+## 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
+
+Clerical. The series bible is a reference document, not a creative one. Be precise, be complete, flag contradictions loudly. The whole point is that the writer can trust Book 7 to remember what Book 1 established -- don't let your summaries drift from source facts.

package/commands/scr/session-report.md

@@ -0,0 +1,80 @@
+---
+description: See what you accomplished this session. Shows units drafted, words written, and time spent.
+argument-hint: ""
+---
+
+# Session Report
+
+You are summarizing the writer's current session. Your job is to compute actionable metrics from STATE.md and present them clearly.
+
+## What to do
+
+1. **Read STATE.md "Last actions" table** to get the full history of actions.
+
+2. **Identify session boundaries:** The current session started at the first action after the last `/scr:pause-work` or `/scr:resume-work` entry in the Last actions table. If no pause/resume exists, the session started at the first action in the table.
+
+3. **Compute metrics:**
+   - **Units drafted:** Count distinct units that went through the "draft" stage this session (e.g., "1 chapter (4 scenes)").
+   - **Words written:** Sum word counts from draft actions this session. If word counts are not in the Last actions table, count words in newly created DRAFT.md files by reading them.
+   - **Time estimate:** Difference between the first and last action timestamps this session. Present as hours and minutes (e.g., "~2 hours 15 minutes").
+   - **Quality passes run:** Count voice-check, continuity-check, editor-review, and other review actions this session. Note whether they passed or had issues.
+
+4. **Read STATE.md "Session metrics" section** for `Current session started` if available. Use it as the strongest boundary anchor when timestamps are present there.
+
+## Output format
+
+Present the report in this format:
+
+```
+## Session Report
+
+**Duration:** ~2 hours 15 minutes
+**Units drafted:** 1 chapter (4 scenes)
+**Words written:** 1,247
+**Quality passes:** voice-check (passed)
+
+**Actions this session:**
+| Time | What happened |
+|------|---------------|
+| 1:00 PM | Started session |
+| 1:15 PM | Discussed chapter 3 |
+| 1:30 PM | Planned chapter 3 (4 scenes) |
+| 2:45 PM | Drafted chapter 3 (1,247 words) |
+| 3:00 PM | Voice check passed |
+| 3:15 PM | Editor review complete |
+```
+
+## Edge cases
+
+- **No actions this session:** If the Last actions table is empty or has no entries after the last pause/resume marker, say: "Nothing to report yet. Start working with `/scr:next`."
+
+- **Missing timestamps:** If timestamps are not available in the Last actions table, only estimate duration when you can still anchor the current session boundary safely. Prefer `Session metrics` start time from `STATE.md`; if present, restrict the save history lookup to save commits at or after that timestamp. Otherwise, use save-history timestamps only if you can confidently match the first current-session action to a save commit after the last recorded `/scr:pause-work` or `/scr:resume-work` marker in the Last actions table. Use save commits only: `git log --format="%ai|%s" --grep="^(Saved|Initial save)" --extended-regexp .manuscript/`. Do not use administrative manuscript commits such as revision-track creation, proposals, or merges for session timing. If you cannot isolate the current session from save history with confidence, omit the Duration line and note: "Duration not available (session boundary timestamps unavailable)."
+
+- **Per D-12:** Session state is per-project. Do not reference other projects. All data comes from this project's STATE.md and git history.
+
+## 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
+
+Encouraging and factual. Show the writer what they accomplished. Even small sessions have value -- "You discussed chapter 4 and shaped the direction. Good foundation for the next drafting session."

package/commands/scr/settings.md

@@ -0,0 +1,58 @@
+---
+description: View or modify project settings.
+argument-hint: ""
+---
+
+# Settings
+
+You are showing or modifying the project settings.
+
+## Prerequisites
+
+- `.manuscript/config.json` must exist
+
+## What to do
+
+1. Load `.manuscript/config.json`
+2. If no arguments, display current settings in a readable format:
+   - Work type and group
+   - Command unit (how commands adapt)
+   - Autopilot profile (if set)
+   - Developer mode (on/off)
+   - Voice drift threshold
+   - **Draft rigor** (`standard` or `strict` -- strict prepends a per-sentence rules check, useful when routing to weaker models)
+   - **Context profile** (`minimal`, `standard`, or `full` -- controls how much context the drafter loads per atomic unit)
+   - **Pitfalls enabled** (on/off -- whether the drafter loads the per-work-type pitfall pack)
+   - Export defaults
+3. If the writer wants to change a setting, update `config.json` accordingly. For the `draft` block, accept these values:
+   - `draft.rigor`: `standard` or `strict`
+   - `draft.context_profile`: `minimal`, `standard`, or `full`
+   - `draft.pitfalls_enabled`: `true` or `false`
+4. Report what changed
+
+## 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
+
+Straightforward. Settings are utilitarian.

package/commands/scr/split-unit.md

@@ -0,0 +1,123 @@
+---
+description: Split one unit into two at a specified point.
+argument-hint: "[unit-id] [split-point]"
+---
+
+# /scr:split-unit -- Split Unit
+
+Split one structural unit into two, with draft content allocation if drafted.
+
+## Usage
+```
+/scr:split-unit [unit-id] [split-point]
+```
+
+## Instruction
+
+You are a structure management assistant. 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 find `work_types[work_type].hierarchy` and determine unit terminology)
+- `.manuscript/OUTLINE.md` (current structural outline)
+- `.manuscript/STATE.md` (progress tracking)
+
+**Work-type adaptation:** Determine the correct unit name from CONSTRAINTS.json hierarchy:
+- Novel: "chapter" (hierarchy.mid)
+- Screenplay: "scene" (hierarchy.atomic) or "act" (hierarchy.top)
+- Short story: "section" (hierarchy.mid)
+- Scripture (Biblical): "chapter" (hierarchy.mid)
+- Use `command_unit` from CONSTRAINTS.json as the default unit level
+
+Use the adapted unit terminology throughout all output and prompts.
+
+---
+
+### SPLIT UNIT FLOW
+
+<split_unit>
+1. **Resolve unit type** from CONSTRAINTS.json `work_types[work_type].hierarchy`
+   - Use `command_unit` to determine which level this command operates on
+
+2. **Validate unit-id:**
+   - Parse OUTLINE.md and locate the specified unit
+   - If not found, show available units and ask for correction
+
+3. **Draft safety check** (D-07):
+   - Scan `.manuscript/drafts/body/` for a draft file matching this unit
+   - **If a draft file exists:**
+     - Show the full draft content summary (word count, paragraph count, scene breaks)
+     - Ask how to split the content:
+
+       **This [chapter/scene/etc.] has drafted content ([N] words, [P] paragraphs).**
+
+       **How would you like to split the content?**
+       1. **By scene break**: Split at an existing scene break marker (`---` or `***`)
+       2. **By paragraph**: Split after a specific paragraph number
+       3. **By percentage**: Split at approximately [X]% of the content
+       4. **Manual**: You specify the exact split point
+
+     - Show a preview of what goes into each new unit
+     - Require explicit confirmation before splitting the draft:
+       "Split this draft into two files? Content in both halves will be preserved."
+
+   - **If no draft exists:** Proceed directly to outline split
+
+4. **Prompt for new unit details:**
+   - Title for the first half (default: keep original title with " (Part 1)" suffix)
+   - Title for the second half (default: original title with " (Part 2)" suffix)
+   - Ask writer for preferred titles -- the defaults are just suggestions
+
+5. **Execute split:**
+   - Replace the original unit entry in OUTLINE.md with two new entries
+   - The first new unit keeps the original position number
+   - The second new unit takes position + 1
+   - Renumber all subsequent units
+   - If draft exists: create two draft files in `.manuscript/drafts/body/` with the split content
+   - Rename subsequent draft files in `.manuscript/drafts/body/` to match new numbering
+
+6. **Update related files:**
+   - Update `.manuscript/STATE.md` to reflect the two new units
+   - Update PLOT-GRAPH.md (or adapted equivalent) if arc positions are affected
+   - Update cross-references in OUTLINE.md
+
+7. **Show result:**
+   - Display the updated outline with both new units highlighted
+   - If draft was split, show word count for each half
+   - Show renumbered subsequent units
+</split_unit>
+
+Commit: `structure: split {unit_type} {N} into {N} and {N+1}`
+
+## Edge Cases
+
+- **Unit with very short draft:** Warn if either half would be very short (under 100 words) and suggest reconsidering.
+- **No scene breaks in draft:** If splitting by scene break but none exist, suggest paragraph or percentage split instead.
+- **No OUTLINE.md:** Prompt to run `/scr:plan` first.
+- **Single-unit outline:** Splitting will create a 2-unit outline -- confirm this is intentional.
+- **Draft with images or special formatting:** Preserve all formatting in both halves.
+
+## 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
+
+Collaborative and precise. Splitting is a creative decision -- help the writer find the right break point without being prescriptive.