scriveno 2.0.5

package/commands/scr/build-smashwords.md

@@ -0,0 +1,171 @@
+---
+description: Build a Smashwords/D2D-compliant DOCX from the manuscript.
+argument-hint: "[--skip-validate]"
+---
+
+# /scr:build-smashwords -- Smashwords/D2D DOCX Build Pipeline
+
+Assemble the manuscript and produce a Smashwords Style Guide-compliant DOCX for submission to Draft2Digital (D2D) or direct Smashwords upload. Uses `scriveno-smashwords.docx` as a Pandoc reference document to enforce no-tabs, first-line-indent-via-style, and auto-TOC rules.
+
+## Usage
+
+```
+/scr:build-smashwords [--skip-validate]
+```
+
+**Flags:**
+  `--skip-validate`    Skip the scaffold marker pre-flight check (not recommended).
+
+## Instruction
+
+You are a **manuscript build specialist** for Smashwords/D2D DOCX output.
+
+---
+
+### STEP 1: LOAD CONTEXT
+
+Load the following project files:
+
+- `.manuscript/config.json` -- to get `work_type`, title, author, language, and project settings
+- Scriveno's installed/shared `CONSTRAINTS.json` -- to check `exports` section for format availability
+
+**Check format availability:**
+
+Look up `build-smashwords` in `CONSTRAINTS.json` under the `commands` section. Check if the work type group is in the `available` list: `["prose", "visual"]`.
+
+If not available:
+> This command is not available for [work_type] projects. The Smashwords DOCX build is available for: prose and visual work types. Poets should use `/scr:build-poetry-submission` instead.
+
+Then **stop**.
+
+---
+
+### STEP 1.5: VALIDATE MANUSCRIPT
+
+**Check for scaffold markers in `.manuscript/drafts/`.**
+
+Scan all `.md` files in `.manuscript/drafts/` for:
+- Lines containing `[Fill in`
+- Lines containing `[Delete if not applicable:]`
+- Lines containing `Alternate 1:` or `Alternate 2:`
+- Files with more than one `# ` (top-level H1) heading
+
+**If `--skip-validate` was passed:**
+> **Warning: Validate gate skipped (`--skip-validate`). Your manuscript may contain unresolved scaffold markers.**
+
+Proceed to STEP 2.
+
+**If markers are found:**
+> **Build blocked: unresolved scaffold markers found.**
+>
+> [list each as: `path/to/file.md:LINE_NUMBER: marker text`]
+>
+> **Fix:** Run `/scr:cleanup --apply` to remove scaffold markers, then re-run this build command.
+
+Then **stop**.
+
+---
+
+### STEP 1.6: FRONT-MATTER GATE
+
+Follow /scr:build-ebook STEP 1.6a-1.6b (scaffold exclusion and GENERATE auto-refresh).
+Use the resulting scaffold exclusion list in STEP 3 assembly.
+
+---
+
+### STEP 2: CHECK PREREQUISITES
+
+Check for Pandoc:
+```bash
+command -v pandoc >/dev/null 2>&1
+```
+
+If not found:
+> **Pandoc is required for Smashwords DOCX build but is not installed.**
+> - macOS: `brew install pandoc`
+> - Linux: `sudo apt install pandoc`
+> - Windows: `choco install pandoc`
+
+Then **stop**.
+
+Check that the reference document exists:
+
+If `data/export-templates/scriveno-smashwords.docx` does not exist:
+> **Smashwords reference document missing at `data/export-templates/scriveno-smashwords.docx`.**
+> Re-install Scriveno or restore the file from the repository.
+
+Then **stop**.
+
+---
+
+### STEP 3: ASSEMBLE MANUSCRIPT
+
+Follow the same assembly steps as `/scr:build-ebook` STEP 3a-3e:
+- Read OUTLINE.md for document order
+- Scan front matter (scaffold-excluded)
+- Read body drafts in OUTLINE.md order
+- Scan back matter
+- Concatenate to `.manuscript/output/assembled-manuscript.md`
+- Generate `.manuscript/output/metadata.yaml`
+
+---
+
+### STEP 4: BUILD SMASHWORDS DOCX
+
+```bash
+pandoc .manuscript/output/assembled-manuscript.md \
+  -o .manuscript/output/smashwords.docx \
+  --reference-doc=data/export-templates/scriveno-smashwords.docx \
+  --metadata-file=.manuscript/output/metadata.yaml \
+  --toc \
+  --toc-depth=2
+```
+
+**Smashwords compliance notes applied automatically by the reference doc:**
+- First-line indent comes from the Normal paragraph style (not tabs or spaces)
+- No custom headers/footers -- removed by reference doc style
+- Auto-generated TOC field (Word-compatible) via `--toc`
+
+**Post-build reminder:**
+> **Smashwords submission checklist:**
+> 1. Open `smashwords.docx` and verify no tab characters (Find/Replace `^t` -- result should be zero matches)
+> 2. Confirm all body text uses the Normal paragraph style with first-line indent
+> 3. Confirm the auto-TOC updates when you open the document (Word: right-click TOC -> Update Field)
+> 4. Submit via https://www.smashwords.com/upload or Draft2Digital upload portal
+
+---
+
+### STEP 5: REPORT
+
+Show:
+```
+OK Smashwords DOCX built -> .manuscript/output/smashwords.docx ({file_size})
+```
+
+Get file size with:
+```bash
+ls -lh .manuscript/output/smashwords.docx | awk '{print $5}'
+```
+
+## 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/build-world.md

@@ -0,0 +1,158 @@
+---
+description: Generate or refine the world document through progressive questioning.
+argument-hint: "[--area <area>]"
+---
+
+# /scr:build-world -- Progressive World Building
+
+Generate or refine the world document through structured progressive questioning.
+
+## Usage
+```
+/scr:build-world [--area <area>]
+```
+
+**Areas:** `geography`, `culture`, `technology`, `rules`, `history`
+
+For technical work types, reinterpret `--area` as:
+- `geography` -> system boundaries and deployment shape
+- `culture` -> audience, ownership, and operating norms
+- `technology` -> stack, tooling, and interface surface
+- `rules` -> supported constraints, permissions, and safety boundaries
+- `history` -> change history, prior decisions, and known incidents
+
+## Instruction
+
+You are building the world document. 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 `file_adaptations` and `commands.build-world.adapted`)
+- `WORK.md` (genre, tone, setting context)
+- Existing world file from `.manuscript/` if it exists (WORLD.md / COSMOLOGY.md / CONTEXT.md per `file_adaptations`)
+
+Determine adapted terminology from CONSTRAINTS.json:
+- Default: "build world", generates `WORLD.md`
+- Sacred: "build cosmology" (renamed via CONSTRAINTS.json), generates `COSMOLOGY.md`
+- Academic: generates `CONTEXT.md`
+- Technical: "map system", generates `SYSTEM.md`
+
+---
+
+### INITIAL MODE (no existing world file)
+
+<world_build_initial>
+  The writer has no world document yet. Ask 3-5 seed questions (D-05) to establish the foundation.
+
+  For technical work types, ask instead:
+  1. "Who is this document for, and what are they trying to accomplish?"
+  2. "What system, service, or workflow does it describe?"
+  3. "What prerequisites or access does the reader need before they can follow it?"
+  4. "Which environment, platform, or version boundaries matter?"
+  5. "What can go wrong if the reader misunderstands this guidance?"
+
+  Otherwise use the default questions:
+  1. **Scale:** "What's the scale of your world? A single city, a region, a continent, a planet, or something larger?"
+
+  2. **Key conflict:** "What is the central tension or conflict that shapes this world? (War, scarcity, class division, magical imbalance, technological disruption, etc.)"
+
+  3. **Distinguishing feature:** "What makes this world different from the real world (or from a typical setting in this genre)? What's the one thing a reader would remember?"
+
+  4. **Time period feel:** "What era or time period does this world feel like? (Medieval, industrial, modern, far-future, timeless, or a specific blend?)"
+
+  5. **Tone of the world:** "Is this world fundamentally hopeful, bleak, ambiguous, whimsical, or gritty?"
+
+  Wait for answers. Do not proceed until the writer responds.
+
+  After receiving answers, generate an initial world/system document using the appropriate template (`templates/WORLD.md` or `templates/technical/SYSTEM.md`). Populate each section with what can be inferred from the seed answers:
+  - Geography: scale, key locations implied by the setting
+  - Culture: social dynamics implied by the conflict
+  - Technology/Magic: tech level from time period, any magic from distinguishing feature
+  - Rules/Laws: governance implied by conflict and culture
+  - History: backstory that would lead to the current state
+
+  For technical work types, translate those buckets into:
+  - system scope and boundaries
+  - operating context and ownership
+  - tooling, interfaces, and environment assumptions
+  - permissions, constraints, and failure conditions
+  - change history and prior decisions
+
+  Mark sections that need more detail with `<!-- needs refinement -->` comments.
+
+  Save the file to `.manuscript/WORLD.md` (or adapted name).
+
+  Commit: `world: create initial world document`
+
+  After saving, suggest: "Your world document is started. Refine any section with `/scr:build-world --area <area>`."
+</world_build_initial>
+
+---
+
+### REFINE MODE (--area flag)
+
+<world_build_refine>
+  The writer wants to deepen one section. Load the existing world file.
+
+  Based on the `--area` value, drill deeper into that section with targeted questions:
+
+  **geography:**
+  - "Describe the terrain around {key location}. Mountains, rivers, forests, deserts?"
+  - "How do people travel between locations? What routes are dangerous?"
+  - "What natural resources exist? What's scarce?"
+
+  **culture:**
+  - "What social classes exist? How rigid are the boundaries?"
+  - "What do people celebrate? What rituals mark major life events?"
+  - "What languages or dialects exist? Any that are forbidden or dying?"
+
+  **technology:**
+  - "What's the most advanced technology/magic in common use?"
+  - "What's rare or forbidden? Who controls access?"
+  - "What are the costs or consequences of using it?"
+
+  **rules:**
+  - "Who enforces the laws? How corrupt or fair is the system?"
+  - "What crimes are punished harshly? What's tolerated that shouldn't be?"
+  - "Are there different laws for different classes or regions?"
+
+  **history:**
+  - "What event in the last 100 years most shaped the current world?"
+  - "What ancient conflict is still unresolved?"
+  - "What does the general population believe about their history vs. what's actually true?"
+
+  After the writer answers, update the relevant section in the world file with richer detail. Preserve existing content -- add to it, don't replace.
+
+  Commit: `world: refine {area} section`
+</world_build_refine>
+
+---
+
+### Edge Cases
+
+- **Invalid --area value:** List valid areas: geography, culture, technology, rules, history
+- **Sacred work type:** Use "build cosmology" terminology; questions adapt to cosmological themes (divine geography, spiritual hierarchy, sacred history)
+- **Academic work type:** Use "build context" terminology; questions focus on intellectual landscape, institutional setting, field dynamics
+- **Technical work type:** Use "map system" terminology; questions focus on system boundaries, operating context, dependencies, and supported environments
+- **World file already comprehensive:** Acknowledge it looks thorough and ask if there's a specific aspect to explore further
+
+## 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/cast-list.md

@@ -0,0 +1,104 @@
+---
+description: Display the roster of all characters with roles and brief descriptions.
+---
+
+# /scr:cast-list -- Character Roster
+
+Display the complete roster of all characters in the work.
+
+## Usage
+```
+/scr:cast-list
+```
+
+## Instruction
+
+You are presenting the character roster. 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 `file_adaptations` and `commands.cast-list.adapted`)
+
+Determine the correct characters file from `file_adaptations`:
+- Default: `CHARACTERS.md`
+- Academic work types: `CONCEPTS.md`
+- Sacred work types: `FIGURES.md`
+
+Load the adapted characters file from `.manuscript/`.
+
+Determine adapted terminology:
+- Default: "cast list", "characters"
+- Sacred: "figures list", "figures" (renamed via CONSTRAINTS.json)
+- Academic: "concepts list", "concepts"
+
+---
+
+### DISPLAY ROSTER
+
+<cast_list_display>
+  Parse all character entries from the characters file.
+
+  Present a formatted table grouped by role category:
+
+  **Protagonists**
+  | Name | Arc Type | Status | Summary |
+  |------|----------|--------|---------|
+  | {name} | {Change/Growth/Fall/Steadfast/Flat} | {active/deceased/mentioned} | {1-line summary} |
+
+  **Antagonists**
+  | Name | Arc Type | Status | Summary |
+  |------|----------|--------|---------|
+
+  **Supporting Characters**
+  | Name | Arc Type | Status | Summary |
+  |------|----------|--------|---------|
+
+  **Mentioned / Off-stage**
+  | Name | Arc Type | Status | Summary |
+  |------|----------|--------|---------|
+
+  Determine role category from each character's "Role" field:
+  - Protagonist, main character, hero -> Protagonists
+  - Antagonist, villain, opposition -> Antagonists
+  - Supporting, mentor, love interest, foil, comic relief, sidekick -> Supporting Characters
+  - Mentioned, referenced, deceased (with no active role), off-stage -> Mentioned / Off-stage
+  - If role is ambiguous, place in Supporting Characters
+
+  After the table, show summary stats:
+  - Total characters: {N}
+  - By status: {active} active, {deceased} deceased, {mentioned} mentioned
+  - Characters missing voice anchors: {list of names without voice data}
+
+  If no characters exist:
+  - "No characters yet. Run `/scr:new-character <name>` to create your first character."
+</cast_list_display>
+
+---
+
+### Edge Cases
+
+- **Empty characters file:** Direct to new-character command
+- **Characters with incomplete profiles:** Include in roster but mark with indicator (e.g., "[incomplete]")
+- **Sacred work type:** Use "figures" terminology, group by role adapted to sacred context (prophet, disciple, angel, etc.)
+- **Academic work type:** Use "concepts" terminology, group by function (thesis, antithesis, supporting argument, counterpoint)
+
+## 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/chapter-header.md

@@ -0,0 +1,158 @@
+---
+description: Generate decorative chapter header/ornament design prompts.
+argument-hint: "[--style <style>] [--chapter <ref>]"
+---
+
+# /scr:chapter-header -- Chapter Header & Ornament Design
+
+Generate a structured prompt for decorative chapter openers, ornamental dividers, and header illustrations.
+
+## Usage
+```
+/scr:chapter-header [--style <style>] [--chapter <ref>]
+```
+
+**Style options:** `floral`, `geometric`, `art-deco`, `gothic`, `minimalist`, `ornate`, `hand-drawn`, `woodcut`, `custom`
+
+## Instruction
+
+You are generating a decorative chapter header/ornament design prompt. Load:
+- `.manuscript/config.json` (to get `work_type`, `genre`)
+- Scriveno's installed/shared `CONSTRAINTS.json` (global `~/.scriveno/data/CONSTRAINTS.json` or project `.scriveno/data/CONSTRAINTS.json`) (to check `commands.chapter-header` availability)
+- `ART-DIRECTION.md` from `.manuscript/` if it exists (for style consistency)
+- `OUTLINE.md` from `.manuscript/` if `--chapter` flag is provided (to get chapter title/theme)
+
+### Work Type Availability
+
+Check CONSTRAINTS.json:
+- **Available:** prose, sacred
+- **Hidden:** script, academic, visual, poetry, interactive, speech_song
+
+If the current work type is hidden, respond:
+*"The `chapter-header` command is designed for prose books and sacred texts. Your {work_type} project doesn't typically use chapter header ornaments."*
+
+### Determine Default Style
+
+If no `--style` flag is provided, derive the default from genre:
+- **Fantasy/Epic:** `ornate` (flowing filigree, mythical creatures, sword-and-shield motifs)
+- **Literary fiction:** `minimalist` (thin rules, subtle typography ornaments, small fleurons)
+- **Romance:** `floral` (roses, vines, hearts, delicate botanical elements)
+- **Thriller/Mystery:** `art-deco` (bold geometric lines, angular patterns)
+- **Horror/Gothic:** `gothic` (gargoyles, thorns, dark botanical, skull motifs)
+- **Historical:** `woodcut` (period-appropriate woodblock print style)
+- **Sacred:** `geometric` (arabesque patterns, mandala elements, sacred geometry, tradition-appropriate motifs)
+- **Children's:** `hand-drawn` (whimsical, playful line art)
+- **Sci-fi:** `minimalist` (clean lines, circuit-like patterns, futuristic geometry)
+- **Default fallback:** `minimalist`
+
+### Chapter-Specific Content
+
+If `--chapter` flag is provided with a chapter reference (number or title):
+1. Load OUTLINE.md and find the matching chapter
+2. Extract the chapter's title, themes, and key events
+3. Incorporate thematic elements into the ornament design:
+   - A battle chapter: crossed swords, shields, war imagery woven into the ornament
+   - A romance scene: intertwined flowers, hearts, delicate motifs
+   - A death/funeral: wilting flowers, hourglasses, somber symbols
+   - A journey/travel: compass roses, winding paths, maps
+   - A revelation/discovery: opening doors, light rays, keys, eyes
+   - A celebration: goblets, laurels, musical instruments, stars
+
+If no `--chapter` flag, generate a generic ornament design suitable for any chapter in this book.
+
+### Generate Structured Prompt
+
+Output a structured illustration prompt following the D-01 format:
+
+```markdown
+# Chapter Header Design: {Book Title or "Generic"}
+
+{If chapter-specific: "## For Chapter {ref}: {chapter title}"}
+
+## Subject
+{Ornamental design description. Specify motifs, symbols, and decorative elements relevant to the book's genre and theme (or chapter-specific theme if --chapter provided). Example: "An ornate horizontal ornament featuring intertwined oak branches with small acorns, a central medallion containing a compass rose, flanked by symmetrical scrollwork."}
+
+## Composition
+- **Format:** Horizontal banner, centered on page
+- **Dimensions:** Full text block width (typically 4.25" for a 6x9 trim)
+- **Height:** 1-2 inches (proportional to page size)
+- **Chapter number/title space:** {Describe where chapter number and title integrate -- centered below the ornament, within a central cartouche, superimposed on the design, etc.}
+- **Symmetry:** {Bilateral symmetry for formal styles, asymmetric for hand-drawn/whimsical}
+
+## Style: {selected style name}
+{Detailed style description:}
+- **Line weight:** {Thin and delicate / Bold and heavy / Variable / etc.}
+- **Detail level:** {Intricate with fine details / Clean and simple / Moderately detailed}
+- **Character:** {Formal and elegant / Rustic and handcrafted / Playful and whimsical / Solemn and reverent}
+{Reference specific artistic traditions or periods if relevant}
+
+## Color Palette
+{Many chapter headers are monochrome for practical print reasons}
+- **Primary:** {Single color -- black, dark brown, deep blue, etc., or match ART-DIRECTION.md}
+- **Approach:** {Monochrome (recommended for cost-effective printing) / Two-color / Full color}
+- **If full color:** {List 3-4 colors that match the book's palette from ART-DIRECTION.md}
+
+## Repeating Elements
+{If generating headers for multiple chapters, define the consistent elements:}
+- **Fixed elements:** {Border style, corner motifs, overall shape -- same every chapter}
+- **Variable elements:** {Central motif changes per chapter theme, specific symbols swap in/out}
+- **Unity:** All headers should feel like a cohesive set from the same book
+
+## Technical Specs
+- **Width:** Match page text block width ({trim_width} minus margins)
+- **Height:** 1.0-2.0 inches (250-500 px at 300 DPI)
+- **Resolution:** 300 DPI (print-ready)
+- **Background:** Transparent (PNG) -- will be placed on book page
+- **Format:** PNG with transparency or high-contrast SVG for vector scaling
+- **Color space:** Grayscale or CMYK for print (avoid RGB-only colors)
+```
+
+### Save Output
+
+Save the generated prompt to:
+- Generic: `.manuscript/illustrations/chapter-headers/chapter-header-prompt.md`
+- Chapter-specific: `.manuscript/illustrations/chapter-headers/chapter-{ref}-header-prompt.md`
+
+Where `{ref}` is the chapter number or hyphenated title reference.
+
+Create the directory path if it does not exist.
+
+Commit: `illustration: generate chapter header design prompt`
+
+After saving, suggest:
+- "Chapter header prompt saved. Use this with any AI image tool or share with your designer."
+- "For a cohesive set, generate headers for each chapter with `--chapter` to include thematic elements."
+- "Ensure visual consistency with `/scr:art-direction` before generating illustrations."
+
+---
+
+### Edge Cases
+
+- **No OUTLINE.md when --chapter used:** "No outline found. Run `/scr:plan` to create your outline, or describe the chapter theme and I'll design the header around that."
+- **Chapter ref not found in outline:** "Chapter {ref} not found in outline. Available chapters: {list}. Or describe the chapter theme directly."
+- **Sacred work type:** Adapt ornament suggestions to tradition-appropriate motifs (Islamic: geometric/arabesque, no figurative imagery; Christian: crosses, vine/branch motifs, illuminated manuscript style; Jewish: Star of David, menorah, olive branches; Buddhist: lotus, dharma wheel; generic sacred: sacred geometry, light motifs)
+- **--style custom:** Ask the writer to describe their desired ornament style, then build the prompt around their description
+- **ART-DIRECTION.md exists:** Style and color sections MUST reference it; override genre defaults with art direction established choices
+
+## 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.