# Cutting Dead Ends

Discovery drafting produces dead ends: subplots that stall, characters who
arrive and do nothing, mysteries that turn out uninteresting. Cutting them
is the job — but in a bible-tracked project, cutting has bookkeeping.

## Recognizing a dead end

A thread is a dead end when it meets two of these:

- It has not advanced for **two consecutive chapters** despite appearing.
- Removing it changes nothing downstream (no promises depend on it, no
  character's arc needs it).
- The writer's interest in it is gone — and the reconcile loop's post-hoc
  notes say so explicitly. "Might be useful later" without a concrete plan
  is hoarding, not craft.

Distinguish a dead end from a **slow burn**: a slow burn has a planned
payoff recorded in `continuity/promises/` with a target chapter. If the
payoff exists in the ledger, the thread is alive — leave it.

## Cutting procedure

1. **Decide with the user.** Cutting is a story decision. Present: what the
   thread is, where it appears (chapters/scenes), what depends on it, and
   the recommendation (cut, fold, or keep).
2. **Choose the cut type:**
   - **Cut clean:** the thread never mattered. Remove its scenes' claims
     (or leave the scenes if they do other work) and delete its ledger
     entries.
   - **Fold:** the thread's best element survives inside another thread
     (the interesting character joins an existing subplot; the clue becomes
     part of the main mystery). Record the fold in both threads' notes.
   - **Prune:** keep the thread but strip it to a single scene or mention —
     it becomes texture, not a thread.
3. **Bookkeeping (this is the part people skip):**
   - Mark removed promises/questions in `continuity/promises/` and
     `continuity/questions/` as `status: abandoned` with a reason — never
     just delete them. An abandoned record explains to future agents why the
     setup has no payoff; a deleted record looks like a forgotten setup.
   - Update affected scene records' `state-changes` if the cut removes a
     change other chapters assumed.
   - If a character is cut, set their file's `status: cut` (do not delete
     the file — it documents the decision) and remove them from registries.
   - Update `plot/timeline.md` for any removed events.
4. **Run maintenance:** `story reindex .`, `story links .`,
   `story validate .`, `story continuity .` — the checker should confirm
   nothing still references the cut thread.

## The darling log

Keep a `## Cut Threads` section in the project's notes (or in
`continuity/state.md` if the project prefers) listing every cut: what it
was, why it was cut, where its pieces went. Cut material is compost — a
folded character or a pruned subplot often returns in a later book. The log
is how the later book finds it.

# Drafting Cadence and Sprints

Discovery drafting works best in a rhythm: write forward in bursts, reconcile
in batches. This reference sets the cadence; the reconcile loop
(`reconcile-loop.md`) is what the batch reviews execute.

## Daily targets

Agree on a target with the user at the start of a discovery project and
record it in `story.md` frontmatter:

```yaml
draft-target: "{e.g. 1500 words/day, or 1 chapter/week}"
```

Rules for targets:

- **Words, not quality.** The target measures forward motion. Reconcile
  loops and revision passes are separate scheduled work, not things that
  happen "when the draft feels ready."
- **Small enough to keep daily.** A missed target should be recoverable the
  next day. Chronic misses mean the target is wrong, not the writer —
  renegotiate it.
- **Track streaks, not totals.** Record per-session word counts in the
  chapter notes or a simple `## Draft Log` in `story.md` notes. The log is
  motivation data, not a performance review.

## Batch reviews

Do not reconcile after every writing session if sessions are short — batch
the reconcile loop:

- **After every chapter** is the minimum (the loop's diff step needs a whole
  chapter to be meaningful).
- **Every 3–5 chapters**, run a batch review: re-read the post-hoc notes
  for the batch, check the promise/question ledgers for dangling setups,
  scan for dead ends (see `dead-ends.md`), and confirm the kernel still
  generates momentum.
- **At the midpoint and at draft completion**, run the `revision-continuity`
  developmental checks on the batch before continuing: arc progression,
  pacing, character-state carry-forward.

## Session shape

A discovery session has three phases; keep them separate:

1. **Re-read (10–15 min):** the kernel, the previous chapter's post-hoc
   notes, and the last few pages of prose. No editing — re-reading is for
   voice and momentum, not revision.
2. **Write (the bulk):** forward only. When stuck, cycle back a few hundred
   words and try a different choice. Do not open the bible mid-session —
   note questions in the chapter file as `[TODO: check bible]` and resolve
   them in the reconcile loop.
3. **Close (5 min):** jot a `[TODO]` line at the end of the chapter file
   with where the next session should start ("Mara is about to open the
   door — decide what's behind it"). Future-you is a different person;
   leave them a map.

## When cadence breaks

- **Stuck for two sessions:** the chapter may need its kernel refreshed —
  re-read the story kernel and ask what the character wants *right now*.
  Or the reconcile loop was skipped and contradictions are jamming the
  draft: run the loop before writing another word.
- **Draft wandering:** chapters accumulate but nothing deepens — run the
  `theme-craft` working-premise exercise on what the draft actually argues,
  then check whether the next chapter can test that premise.
- **Reconcile backlog:** more than two chapters without a loop means the
  bible is now fiction about a different book. Stop drafting, run the loops
  in order, then resume.

# The Reconcile Loop

The reconcile loop is the core discipline of discovery drafting: after each
discovered chapter, extract what the chapter invented, reverse-outline it,
diff it against the bible, and reconcile. This is what makes pantsing
compatible with a markdown-first story bible — the bible is maintained
*after* the prose, not before.

## The loop (run after every chapter, before the next)

### 1. Extract new entities and promises

Treat the finished chapter like `story import` treats a manuscript:

1. Read the chapter prose and list every new **entity candidate**: characters,
   locations, factions, artifacts, systems/rules the chapter introduced or
   implied. Present candidates to the user for approval, exactly as the
   import workflow does — do not auto-create bible files.
2. List every new **promise** (setup needing payoff) and **question**
   (mystery raised). Check each against `continuity/promises/` and
   `continuity/questions/` for duplicates before creating new records.

### 2. Reverse-outline the chapter

Write the outline the chapter *would* have had if it had been planned —
after the fact:

- One line per scene: what the scene accomplishes, POV, location.
- State changes the scene made (feeding the scene record in `scenes/`).
- Promises planted, questions raised, foreshadowing laid.

Store the reverse outline in the chapter file above the prose (same
convention as chapter-writing's approved outlines) and create/update the
`scenes/` records.

### 3. Diff against the bible

Compare the reverse outline and entity candidates against the existing
bible:

- **New** — genuinely new elements: create the files (after user approval).
- **Contradiction** — the chapter says X, the bible says Y: one of them is
  wrong. Decide with the user which one, then fix the loser.
- **Enrichment** — the chapter deepens something the bible sketched: update
  the bible file (character voice detail, location texture, system rule).
- **Dangling** — a promise or question with no plausible payoff yet: keep
  it open in the ledger, but flag it in the chapter notes so the next
  reconcile loop checks it again.

### 4. Reconcile

Apply the diff: update bible files, registries, `continuity/state.md`,
`plot/timeline.md`, and the chapter/scene records. The two legal outcomes
are **update the bible** (the chapter discovered something true) or
**revise the chapter** (the chapter broke something true). "Leave both"
is not an outcome — unresolved diffs become continuity bugs.

## Post-hoc chapter notes

After the loop, append a `## Chapter Notes (post-hoc)` section to the
chapter file recording:

- What was discovered (new entities, rules, relationships).
- What was cut or left dangling.
- Any open questions for future chapters.

These notes are the project's memory of *why* the bible looks the way it
does. Future agents read them before drafting the next chapter.

## The `mode: discovered` flag

Every chapter drafted in discovery mode carries this frontmatter:

```yaml
mode: discovered
```

The flag tells the CLI and later audits that the reconcile loop is a
**required step** for this chapter: a discovered chapter without post-hoc
notes and a completed diff is unfinished work, not a stylistic choice. When
`story.md` uses `draft-mode: discovered`, treat missing post-hoc notes on any
chapter as a maintenance finding. Chapters written outline-first in a mixed
project use `mode: outlined` (or omit the field).

## Reconcile checklist (per chapter)

- [ ] Entity candidates extracted and user-approved; new files created
- [ ] New promises/questions checked for duplicates, then recorded
- [ ] Reverse outline written into the chapter file
- [ ] Scene records created/updated with state changes
- [ ] Diff run: every contradiction resolved (bible updated OR chapter revised)
- [ ] `continuity/state.md`, `plot/timeline.md`, registries updated
- [ ] Post-hoc notes appended; `mode: discovered` in frontmatter
- [ ] `story wordcount . --write`, `story reindex .`, `story links .`,
      `story validate .`, `story continuity .`

# The Story Kernel

A story kernel is a one-paragraph starting point for discovery drafting —
enough to write from, not enough to be an outline. It replaces the beat
sheet as the draft's seed. Write the kernel before chapter one, then let the
chapters discover the rest.

## Kernel contents

One paragraph, 3–6 sentences, containing:

1. **A character in a situation** — who, and what unstable position they're in.
2. **A want** — what the character wants badly enough to act on.
3. **An obstacle or pressure** — what stands in the way, or what will go
   wrong if they don't act.
4. **A tone/genre signal** — one phrase that sets the register (noir,
   wonder, dread, farce).

What the kernel deliberately omits: plot beats, an ending, a theme statement,
a cast list, worldbuilding. Those get discovered (and reconciled later — see
`reconcile-loop.md`).

Example (original, for illustration):

> A retired cartographer who falsifies maps for smugglers discovers her
> latest commission describes a city that shouldn't exist — and someone is
> paying in real gold to reach it. She wants the money and wants to know if
> she drew something true by accident. The client is lying about why they
> need the route, and her old guild contacts are watching. A tense,
> low-magic caper with the unease of a ghost story.

## Recording the kernel

Store the kernel in `story.md` under a `## Story Kernel` section, and mark
the project as discovery-drafted in frontmatter:

```yaml
draft-mode: discovered
```

This tells every later skill and audit that chapters were written without a
pre-planned outline, so the reconcile loop (not the outline) is the source
of truth for what happened.

## Using the kernel

- **Starting a session:** re-read the kernel, then ask "what's the most
  interesting thing that could happen next?" Write that.
- **When stuck:** cycle back a few hundred words and try a different choice
  (the canonical discovery-writer recovery). Do not stop to outline forward.
- **When the kernel stops generating:** the kernel has done its job when
  chapters have their own momentum. Promote discovered elements into the
  bible via the reconcile loop; the kernel itself never needs updating.
- **Kernel vs. premise:** the kernel is a situation, not a theme. If a
  working premise emerges during drafting (see the `theme-craft` skill),
  record it as `premise:` in `story.md` — but do not force the draft to
  serve a premise that arrived late.

## When discovery mode is wrong

Use the outline-first `chapter-writing` workflow instead when: the story has
hard external constraints (a mystery whose fair-play clues must be planted —
see `genre-craft`), the user explicitly wants a beat sheet, or repeated
reconcile loops show the draft wandering without deepening. Discovery is a
method, not an identity — switch modes per project, and mark the switch in
`story.md` (`draft-mode: outlined` for chapters written outline-first;
mixed-mode projects are fine, tracked per chapter).