# Beats — Fiction Fork

The fiction fork of `docs/beats.md`. Same skill, same discipline, same 5-pass — the **beat unit** changes from a declarative CLAIM (nonfiction: one teaching move) to a **SCENE** (fiction: one dramatized unit of change). Everything upstream and downstream is identical: author owns substance + beat material, the agent QUERIES and structures, the DUMP comes first, and prose pours through /authors-voice.

Route here at the book-class question when the book is **fiction**. Nonfiction stays on `docs/beats.md`.

## The unit: a scene-beat

A fiction beat is a **scene** — the smallest unit that turns a value. Each scene-beat has:

- **Who wants what** — the POV character's goal in the scene.
- **What blocks it** — the conflict / opposition.
- **The turn** — the value flips by the end (safe→exposed, trusting→betrayed, winning→trapped). A scene that ends on the same charge it opened on is not a beat; it's filler.

Rule of thumb: scenes run on **"therefore / but," never "and then."** If two adjacent scene-beats connect with "and then," the sequence is inert.

**Naming (same principle as nonfiction):** the beat name states the dramatic move, active and substantive — `THE COURIER MISSES THE DROP`, `MARA REFUSES THE DEAL`, `THE RIVAL LEARNS HER NAME`. Not categorical labels (`THE INCITING INCIDENT`, `SETUP`, `MIDPOINT`) — those are structural metadata, not names.

## Query-first still holds (this is the whole point)

The author owns the story. The agent does **not** invent plot, character, or scenes from the premise. Same failure mode as nonfiction: agent mines the logline → proposes scenes → author rejects them because they came from outside the author's head. Pull the material out of the author, then structure it.

Query patterns that work for fiction:
- "What's the scene you can already see — the one you keep picturing?"
- "What does [character] want in this chapter, and who's standing in the way?"
- "What does the reader believe going in that you want to break by the end?"
- "What's the moment the value flips — where does it go wrong (or right)?"
- "Whose chapter is this? Whose head are we in?"

Proposing is the exception, and only in the documented cases (`docs/beats.md` → "When proposing IS the right move"): author asks for candidates, agent is restructuring material the author already gave, or author says move fast on a low-stakes draft. Agent output is a proposal, never "locked."

## The 5-pass (scene-shaped)

Driven with the author, one chapter at a time. Author owns substance; agent owns structure.

### Pass 1: DUMP
Author brain-dumps everything they can see of the chapter/story — scenes, images, lines of dialogue, characters, turns, the moments they can't stop thinking about. Unfiltered, unsequenced, no length limit. Agent captures verbatim. Target a wide net: more scene-candidates than will survive.

### Pass 2: DRIVE (fiction's TENSION)
For each dumped scene, the agent tags:
- **Goal** — what the POV character wants in the scene.
- **Obstacle** — what opposes it.
- **Turn** — the value that flips, and in which direction (+ → − or − → +).
Scenes with no turn are dead weight (flag for cut, merge, or reposition — a flat scene is fine only as a deliberate breather). Scenes with no goal are atmosphere, not beats.

### Pass 3: CATEGORY
Tag each scene by dramatic function: **ACTION** (dramatized event), **REVELATION** (information lands / secret surfaces), **REVERSAL** (fortune or allegiance flips), **DECISION** (character commits, no going back), **PLANT** (setup paid off later), **PAYOFF** (a plant lands), **CHARACTER** (interiority / relationship shift), **ATMOSPHERE** (world, dread, texture). Confirm the MIX: all ACTION reads relentless and numb; all CHARACTER reads static; a chapter wants variety and a spine of cause-effect.

### Pass 4: SEQUENCE
Order by **cause and effect** — each scene's exit value becomes the next scene's entry charge. Escalate. Watch for: stakes that don't rise, reveals that land before they're set up, "and then" seams (rewrite to "therefore / but"), and payoffs with no prior plant.

### Pass 5: COMPRESSION
State each scene as one line: **who wants what, what blocks it, how it turns.** If it takes three sentences, it's two scenes (or a scene with a second beat buried in it). Split or cut.

### Final artifact
A flat, sequenced list of scene-beats for the chapter, each one line, each turning a value, ordered by cause-effect. Recorded exactly like the nonfiction Beat Map — one numbered entry per scene-beat, Act groupings as visual scaffolding only. This is the chapter's Beat Map; it drives the per-beat /authors-voice dispatches.

## Everything else is shared with `docs/beats.md`

- **Beats are commitments, not content** — a scene-beat names the OUTCOME (who wants what, how it turns), not the prose. The minion brings the sensory specifics, the dialogue, the staging from its training data. Author injects only author-unique content (a specific line that must land, a plant that must be planted).
- **One beat = one dispatch** — each scene-beat gets its own Apply Protocol call. Never bundle.
- **Recording is flat**; density varies by scene job.
- **Research-after-draft**, workspace management, the minion handoff, per-author calibration — all identical. See `docs/beats.md`.

The only fork is the unit and the two passes that read on it (DRIVE, CATEGORY). Author-first, query-first, dump-first — unchanged.

# Beats — Methodology

A beat is the smallest unit of forward movement: one shift in the reader's understanding, attention, or emotional state. The fundamental unit the editor operates on with the author.

This doc: query-first principle, beats-as-commitments rule, the fractal hierarchy, beat density, the per-chapter beat map, the 5-pass extraction, the minion handoff.

## Beat unit definition (v2 lock 2026-05-20)

**One flat beat definition. No sub-beats.**

- **A beat = one atomic teaching move = one dispatch unit.** Each beat gets its own /authors-voice Apply Protocol call. Never bundle multiple beats in one dispatch.
- **Beat sizes vary by job, not by uniform target.** 80w aphoristic-compression beats ("Sleep is the foundation") through 800w grounded unpacks (mechanism walks, study breakdowns, historical context). 500-650w is the typical sweet spot for case-study and demonstration beats.
- **Beats group conceptually under Acts** in the chapter beats doc for chapter-architecture thinking. Acts are organizational headers, not dispatch units.
- **Empirically validated lock (2026-05-20):** seven pilot tests at single-beat scope (500-650w each) produced gold-standard prose. One multi-beat dispatch (~1300w covering 7 beats) collapsed density across all 7. Minion quality budget is per-dispatch, not per-word — give it one outcome to land.
- **Naming:** beats use declarative-claim names (`B6 — JET LAG IS THE CLEANEST DEMONSTRATION.`). Per-beat prose docs use `Ch N — Bk: <Short Name>` (`Ch 2 — B6: Jet lag`). Beat number is the dispatch handle — point at work by number+name, not by ambiguous group labels.

## Query-first principle: pull, don't propose

The editor STRUCTURES what the author owns. Author owns substance + beat material; editor owns process + shape.

When beats are needed — to add to a Beat Map, fill a gap, extend a chapter — the editor's DEFAULT is to QUERY the author, never propose from cold.

**Failure mode:** editor mines source docs / argument arc / their own intuition → proposes 2-3 candidate beats → author rejects them all because they came from outside the author's brain. Wasted turn, material the author doesn't recognize as theirs.

**Correct move:** editor identifies the SIGNAL in the author's recent modifications (what did the author just sharpen? what direction did they push? what categorical word did they kill?) → formulates ONE focused question that pulls the next beat material OUT of the author → author talks → editor structures the beat from the author's words.

The author's recent edits are always a signal. Sharpened B1 toward mechanism specificity → next beats in their head are likely also mechanism-sharpening. Killed a soft framing and named a force → next work is likely naming the next soft framing.

**Query patterns that work:**

- "You just sharpened B1 by adding the adenosine-clearance mechanism. Looking at the spine, which other beat feels soft on mechanism specificity?"
- "You killed TIREDNESS in B5 and replaced it with SLEEP PRESSURE as the named force. Is there another categorical word in the spine covering for a force that needs naming?"
- "You added these three sub-beats. What's the thread you've been thinking about that still hasn't made it into the beat map?"
- "Walking the spine top to bottom — which arc beat feels under-served when you read it back?"

Each query has the same shape: name the author's RECENT WORK as evidence, ask a SPECIFIC question with a CONCRETE direction, give the author room to talk.

**When proposing IS the right move** (rare):
- Author explicitly asks "give me 3 candidates"
- Candidates are mechanically derived from existing source material the author owns (e.g., "your concept doc lists 5 mechanisms; I'm proposing each becomes a beat — does that fit?") — presented as restructuring, not invention
- Low-stakes draft work, author wants to move fast

Otherwise: default to query. The editor's intuition for "missing" beats is dramatically worse than the author's; extract the author's intuition, don't substitute your own.

## Beats are commitments, not content

A beat is the OUTCOME the writer must produce in the reader. NOT the content the writer uses to produce it.

**Failure mode:** editor packs the beat with specifics — "use these 10 species," "cite this study," "name the mechanism in these terms." Minion has nothing left to invent; editor has quasi-written the prose by pre-selecting all load-bearing content. The minion's training data — which contains the reference material baked in — gets silenced; the minion can only reproduce what the editor pre-selected.

**Correct shape:** each beat = one sentence naming the OUTCOME (what registers in the reader). The writer brings the specifics from training data. Author owns the FRAME and AUTHOR-UNIQUE content; writer owns EXAMPLES, CITATIONS, CANONICAL REFERENCES.

**Example contrast:**

| Content brief (wrong) | Commitment (right) |
|---|---|
| "ROSTER: dolphins sleeping one hemisphere at a time, migrating birds micro-napping mid-flight, fruit flies losing coordination when deprived, elephants on two hours a night, brown bats on twenty — every species pays the sleep tax in its own currency" (~60 words, content) | "Land the cross-species roster — reader registers sleep as a universal biological mandate, not a human quirk" (~15 words, outcome) |
| "Cohort data: short sleepers show 40% impaired glucose response within one week of restriction (representative lab finding)" | "Land the empirical anchor — sleep restriction as one of the fastest measurable metabolic insults ever documented" |
| "Modern sleep-debt causal stack: artificial light, caffeine half-life, alcohol fragmentation, anxiety loops, screens in bed, irregular schedules" | "Name the sleep-debt causal stack — reader sees multiple intersecting modern attacks on a fixed biological need" |

The right-column beat tells the writer WHAT must land. The writer's training data contains the species examples, the study citations, the mechanism pathways. Minion picks specific examples that best serve the beat in voice register. Editor ensures the OUTCOME lands; minion curates supporting material.

**Beat commitments use the same shape as Apply Protocol TASK commitments.** The shape that produces excellent writing: abstract SEMANTIC statements of what must land — what claims, what register, what avoidances, what sequence — phrased so the model has freedom on HOW to deliver. When the editor specifies the prose instead of the move, the minion can't bring its moves. Same rule, same discipline, same shape at both layers.

When the minion drafts a chapter-arc beat, the section beats under it become TASK commitments VERBATIM. If a section beat reads like content-prescription (concrete examples packed in), it produces content-prescriptive prose. If it reads like an outcome commitment, the minion's training data brings the content in voice. The Beat Map IS a structured catalog of TASK commitments organized by chapter-arc beat.

**Inject specifics into a beat (the exceptions):**
- **Author-unique content.** Coined term, author-framed mechanism, lived-experience scene the minion cannot invent — list as MUST-APPEAR.
- **Load-bearing constraints.** Beat MUST land a specific phrase, callback to a prior chapter, or use a specific example for argumentative reasons — name it as a literal commitment (editor-as-co-author for that beat).
- **Author has strong preference on which example carries the beat.** "The dolphin's one-hemisphere sleep specifically, not just any animal example" — name it.

Otherwise: state the outcome, let the writer's training data bring the content.

## Research-after-draft inversion

Consequence of "beats are commitments": Research Notes are built AFTER the draft, not before.

Conventional order is research → outline → draft. With an AI minion drawing from training data, that inverts:

1. **Beat Map** — outcome commitments (no content prescription)
2. **Draft** — minion writes against commitments; training data brings examples, citations, frameworks
3. **Research Notes (enrichment pass)** — editor + author review draft, identify references that need to be made canonical (specific URLs, DOIs, author-name-year citations), build Research Notes keyed to relevant draft passages

The model already has reference material baked into its weights. Editor's research-stage job: CATEGORIZE and CATALOG the references the draft used, so they become canonical and citable.

**When inversion does NOT apply:** topic at frontier of recent research (post-training-cutoff data), or niche source material the model can't be trusted on, or specific contested citations (author wants Smith 2019 not Jones 2020) — then Research Notes built BEFORE the draft and injected into the minion brief. Default is post-draft; flip when content demands it.

## What a beat is

The smallest unit of forward movement. One move. One click forward.

Not a paragraph (typography). Not a sentence. Not a section. A beat is the move itself — the moment the reader registers a shift.

**Test:** if you removed it, what does the reader stop registering? Nothing → not a beat, filler. A specific shift in recognition or emotion → beat.

Every beat has three parts:
1. **Purpose** — what work it does for the reader
2. **Delivery** — the actual prose that does the work
3. **Effect** — what changes in the reader after it lands

**A beat's prose carries NO headings** — no chapter title, no section header, not even its own title. A beat is pure prose: the move and nothing else. All heading structure (chapters, sections, sub-sections) is declared in the **manuscript binding** at compile time, never authored into the atom — a title baked into a beat couples it to one position and one book. If a section header should sit above a beat, it goes in the manifest, not at the top of the beat.

## Beat = dopamine

Beats and dopamine are functionally linked. Dopamine is the brain's forward-motion signal; it fires on four mechanisms — the same four that make a beat land:

1. **Prediction error** — gap between what reader expected and what arrived
2. **Reward anticipation** — not the payoff itself, the priming that says "payoff coming"
3. **Novelty / curiosity** — unfamiliarity flagged as "pay attention"
4. **Pattern recognition** — the reveal where noise resolves into signal

A beat that lands hits at least one (often all four): creates surprise (prediction error), resolves a tension planted earlier (anticipation paid off), opens a new tension (curiosity primed for next beat), reveals a pattern not yet seen.

Filler does none of these — dopamine-quiet prose. Reader's neurochemistry stops paying attention. The fourth restating of the same trait fires NO dopamine — habituation. **Repetition is metabolic cost for zero reward** — why bloated chapters feel long even when they aren't.

The chapter as a whole is a **dopamine sequence**: an interlocking chain of small tensions and resolutions, each beat both closing the prior cliffhanger and opening the next.

## Beat density (craft choice, not recording prescription)

Prose moves at different densities. An aphoristic Naval paragraph fires more dopamine hits per page than a Sapolsky mechanism walk. Both work; pick deliberately for the chapter's velocity and the voice register.

| Density anchor | Typical words/beat | Effect |
|---|---|---|
| Aphoristic (Naval) | 50-100 | Every line is the beat |
| Punchy (Manson, Taleb) | 150-250 | Mid-paragraph reveals, fast turns |
| Argumentative (Caplan) | 250-400 | Paragraph-per-claim |
| Developed (Peterson) | 400-600 | Heavy development per beat |
| Mechanism walk (Sapolsky) | 500-1000 | Long turns, slower dopamine spacing |

**Density is a craft choice. Recording structure is fixed: flat.** Within a chapter you might have an aphoristic 80w beat next to a 600w grounded unpack next to a 200w vignette — that variation IS the rhythm. But every beat is recorded the same way: one numbered entry in the chapter beats doc, one dispatch when prose lands. The two-level "chapter-arc beats with section beats nested underneath" recording style is deprecated (v2 lock 2026-05-20) — it produced multi-sub-beat dispatches that collapsed prose density.

**Beat-density math per voice setup** lives in `voice/beat-math.md` (the author's target density anchor). The chapter beats doc varies around that anchor by what each move's job demands.

## Beats run at two levels: global first, per-chapter after architecture

Beats methodology fires twice in the long-form pipeline, at two distinct scales:

**Level 1: Global Beat Sheet (book-level, pre-chapter).** Before chapter architecture, the 5-pass extraction runs at the BOOK level. Output: a FLAT list of every beat the book needs, in approximate argument order, with NO chapter assignment yet. Raw material chapter architecture chunks into containers. Without this, architecture has no concrete evidence to chunk on — tries to commit containers in the abstract from just the Argument Arc, and the chapter list ends up categorical and wrong.

**Level 2: Per-Chapter Beat Draft (chapter-level, post-Reorg).** After chapter architecture commits the TOC and the Reorg phase sorts global beats into containers, the 5-pass runs AGAIN — per chapter, on beats the container received. Output: a FLAT list of 15-30 beats per chapter (variable by chapter length and density), sequenced as that chapter's dopamine flow. Acts can group beats visually as organizational scaffolding, but acts are not dispatch units — only beats are.

Same methodology, two scales, two passes. Each pass produces a flat list at its scale. First feeds chapter architecture; second feeds the per-beat dispatches.

### Per-chapter beats live INSIDE committed chapter containers

Per-Chapter Beat Draft is downstream of Chapter Architecture (`docs/chapter-architecture.md`). The chapter container — substantive name, committed brief, boundary against adjacents — must exist BEFORE per-chapter beat work begins. Per-chapter beats with no committed container land in arbitrary places, spill across boundaries, produce a book the reader can't carry.

If a chapter container is unclear when per-chapter beat work begins (vague name, "and also" describing what it covers), STOP. Return to Chapter Architecture for that container. Architecture pass is cheap; beat work in a wrong container is expensive.

Signs the container is wrong, surfacing during per-chapter beat work:
- Beats consistently feel "too much" for the container (split the container or compress the beats)
- Beats consistently feel "too thin" (container is actually a sub-beat of an adjacent chapter)
- A beat keeps wanting to gesture at the next chapter's territory (boundary leak — re-validate adjacency or move the beat in Reorg)
- Chapter's promise can't be stated in one sentence (container hasn't crystallized)

## Beat naming convention

Every beat name must communicate the beat's SUBSTANCE — what the beat asserts, claims, shows, reveals — NOT what KIND of beat it is.

**Test:** can the author understand what the beat does from the name alone, without reading the beat? No → name is wrong.

The author uses the beat name to orient when formulating how to approach the beat. Categorical names ("THE CENTRAL THESIS," "MODERN DIAGNOSIS," "SETUP," "HOOK," "MECHANISM") force the author to read the beat to know what it asserts — mystery the author cannot use. A beat name that doesn't communicate is no different from a chapter titled "Chapter 2: The Central Thesis."

**Format:** declarative claim, present tense, 4-10 words, the active assertion the beat makes.

### Good (substantive, claim form)

- SLEEP IS THE PRICE OF PLASTICITY
- CAFFEINE BLOCKS THE SIGNAL, NOT THE DEBT
- EIGHT HOURS IS THE FLOOR AND YOU'RE TREATING IT AS A CEILING
- DREAMING IS OVERNIGHT THERAPY
- THE SHORT-SLEEP GENE IS VANISHINGLY RARE
- EVOLUTION NEVER MET THE ALARM CLOCK
- THE BODY KEEPS THE LEDGER
- THE DEBT COMPOUNDS, THE PAYMENT DOESN'T

Each tells the author exactly what the beat asserts. The author can picture the move, supporting beats, prose register required.

### Bad (categorical, meta-label)

- THE CENTRAL THESIS (thesis about what?)
- MODERN DIAGNOSIS (diagnosing what, finding what?)
- SETUP / HOOK / MECHANISM / TRANSITION / THE PAYOFF / SCOPE PRECISION

Structural-role labels, not substance.

### Where categorical tags DO belong

Category tags from the CATEGORY pass (REVEAL / REFRAME / MECHANISM / EVIDENCE / SCENE / APHORISM / PIVOT / REGISTER SHIFT) are analytical metadata, not beat names. Appear ALONGSIDE the beat name as a tag, never AS the beat name:

```
B3. SLEEP IS THE PRICE OF PLASTICITY [REVEAL]
```

Tag helps with structural balance checks (too many EVIDENCE beats = academic). Name carries the substance.

### Applied at every level

Convention applies equally to chapter-arc beats (8-12 per chapter), section beats (one tweet-length claim per beat), and project beats (argument arc — substantive claims at the book level).

## Per-chapter beat map artifact (v2 flat structure)

One doc per chapter (`Ch N — Beats: <Title>`). Reads top-to-bottom as the flow. Flat numbered list of beats with optional Act groupings as visual scaffolding. Pure beats only — no prose, no source detail, no research citations. Citations live in `Ch N — Research Notes`.

Structure:

```
# Ch N — Beats: <Chapter Title>

**Chapter brief.** [one paragraph]
**Word target:** ~Xw
**Pattern:** 4-act chapter structure. Single flat beat definition: one beat = one atomic teaching move = one dispatch unit. Beat sizes vary by job (80w naval-compression up to 800w grounded unpacks).

## Chapter arc — flat beat structure

### Act 1 — <Act name>  (~Xw)

**B1 — DECLARATIVE CLAIM IN CAPS.** (~Xw) One-paragraph outcome description carrying the load-bearing notes (the specific move, the citation handles, the closing aphorism if any). What must land in the reader after this beat.

**B2 — DECLARATIVE CLAIM.** (~Xw) Same shape.

[...]

### Act 2 — <Act name>  (~Xw)

**BN — DECLARATIVE CLAIM.** (~Xw) ...
```

Each beat = one declarative-claim name + a brief outcome paragraph naming the move, the references it carries, and any specific phrasing that MUST appear. Outcome shape (per the commitments-not-content rule) — the minion brings the prose, the editor names what must land.

**Why flat:** beat = dispatch unit. Recording structure matches dispatch structure. The minion writing B6 takes B6's beat entry verbatim into the TASK brief and writes ~500w of prose. No translation layer between recording and dispatch.

**Why Acts:** organizational scaffolding for the chapter's 4-act dopamine arc (mechanism → logic → bridge → setup-next). Acts let the author see the chapter's arc shape while scrolling the flat list. Acts are NOT dispatch units. A beat sits IN an act; an act does not get its own minion call.

Separation of concerns:

| Doc | Contents | Used by |
|---|---|---|
| **Chapter Beats** (`Ch N — Beats: <Title>`) | Flat beats with brief outcome notes, Act-grouped | Author (to see flow), editor (to assemble per-beat dispatch briefs) |
| **Chapter Research Notes** (`Ch N — Research Notes`) | Citations, URLs, hardened references | Editor when assembling dispatch briefs, author for verification |
| **Per-beat prose** (`Ch N — Bk: <Name>`, in `Ch N/Drafts/`) | One prose doc per beat — the minion's output | Author for review, editor for integration into full chapter draft |

The chapter beats doc is the load-bearing artifact. It drives every per-beat dispatch.

## The 5-pass extraction

The editor drives this with the author, one chapter at a time. Author owns substance; editor owns structure.

### Pass 1: DUMP

Author brain-dumps every interesting, counter-intuitive, sharp, lived, weird, or sticky idea on the chapter's topic. No filtering, no sequencing, no category, no length constraint. Editor captures verbatim into a working list.

Wide net by design. Target: 40-60 raw beat-candidates (more than will survive).

Editor prompts that help:
- "What's the counter-intuitive thing here?"
- "What's the scene from your own life that lands a piece of this?"
- "What's the part you keep coming back to in conversation?"
- "What's the reversal — the thing where the reader expected X and gets Y?"
- "What's the part where you go 'wait, but...'"
- "What's the part you'd put on a t-shirt?"

The DUMP must be unfiltered. Editor must not pre-judge what's "beat-sized" or "on-topic." Surprising material surfaces only when the author trusts the dump won't be criticized in flight.

### Pass 2: TENSION

For each raw beat, the editor tags:
- **What question does this beat ANSWER?** (the tension it resolves)
- **What question does this beat OPEN?** (the tension it primes — what the reader now wants to know)

Beats with no open question are dead ends. They land, but don't pull the reader forward. Flag for cut, merge, or repositioning at chapter close (where dead ends are fine — they're the resolution).

Beats with no answered question are non-sequiturs. Find the prior beat they SHOULD follow, or cut.

A clean beat: answers ONE question, opens ONE question. The dopamine handoff.

### Pass 3: CATEGORY

Tag each beat:

- **REVEAL** — new information lands, prediction-error fires
- **REFRAME** — old information gets re-seen in a new light
- **MECHANISM** — explains how/why something works
- **EVIDENCE** — proof for a prior claim (citation, study, data, scene)
- **SCENE** — lived experience that grounds an abstraction
- **APHORISM** — compressed claim, single-sentence beat
- **PIVOT** — directional turn (now we look at X)
- **REGISTER SHIFT** — emotional or rhetorical gear change

Confirm the MIX is right. All EVIDENCE reads academic. All APHORISM reads tweet-thready. All MECHANISM reads textbook. Good chapter has variety — typically 30-40% REVEAL/REFRAME, 20-30% EVIDENCE/MECHANISM, 10-20% SCENE, 10-15% APHORISM, with PIVOT and REGISTER SHIFT as connective tissue.

### Pass 4: SEQUENCE

Order beats by dopamine flow. Each beat's OPEN question becomes the next beat's TENSION.

Group section-beats under chapter-arc beats (B1, B2, etc).

Watch for:
- **Broken sequences** — beat N opens a question beat N+1 doesn't answer; reader waits and waits
- **Premature reveals** — payoff lands before setup primes the anticipation
- **Stacked openings without payoff** — chapter keeps promising and never delivers
- **Stacked payoffs without new tension** — chapter peaks then flatlines

The right sequence is the dopamine-optimal sequence — sometimes chronological, sometimes argumentative, sometimes thematic. Often it's the order where each beat hands the reader to the next.

### Pass 5: COMPRESSION

State each beat as one tweet-length sentence. If you can't compress it, it's still mush. The compression test forces the author to NAME the move precisely.

A beat that survives compression is shippable to the minion. A beat that requires three sentences to explain its move is two beats (or contains an embedded second beat). Split or cut.

### Final artifact

After all 5 passes: ~30 section beats grouped under 8-12 chapter-arc beats, each beat one sentence, ordered by dopamine flow, categorized by type. The Chapter Beat Map.

## The minion handoff

Chapter Beat Map becomes the minion's COMMITMENTS in the Apply Protocol TASK brief. Typical pattern:

- **One minion per chapter-arc beat** (B1, B2, ...) for long chapters
- Minion's commitments are the section beats under that chapter-arc beat
- Each section beat = one paragraph the minion writes
- Minion gets the beats, voice anchor, NEVER rules, examples — nothing else (no source prose, no prior chapter content unless substantively required)
- Cadence prescription varies per chapter-arc beat (see `docs/apply-protocol-deep.md`)

When the Beat Map has done its work — surface beats specific, sequenced, categorized, compressed — the minion's prose draft requires minimal surgery. The editor patches NEVER violations and meta-references; the structural shape was already locked at the beat layer.

## Per-author calibration: `voice/beat-math.md`

After the author's voice anchor exists, the editor calibrates beat math to their voice. Lives at `voice/beat-math.md`:

- **Target beats-per-chapter range** (e.g., "28-32 for a 6-7k word chapter")
- **Target words-per-beat average** (e.g., "~220, fast register")
- **Beat-category preferences** (which beat types this author hits best — e.g., "strong on REVERSAL beats and lived-SCENE beats, weaker on MECHANISM beats")
- **Beat density per chapter type** (different targets for tweet threads, essays, book chapters)
- **Author's coined beat shapes** (any reusable beat structures the author returns to)

Set up after the voice profile reaches Tier 1+ and the author has produced a few chapters/sections so density can be measured against output.

## Pipeline position

```
Argument Arc → Global Beat Sheet → Chapter Architecture → Reorg Beats by Chapter → Per-Chapter Beat Draft → Chapter Draft
                                                                                                              ↓
                                                                                                       Research Notes per chapter (companion)
```

Global Beat Sheet = raw material — every beat the book needs, no chapter assignment yet. Chapter Architecture chunks it into committed containers. Reorg sorts beats into containers. Per-Chapter Beat Draft refines per container. The per-chapter beat doc is pure beats inside a committed container, readable as the chapter's dopamine flow. Research Notes per chapter is the post-draft source-detail companion.

Full pipeline: `docs/long-form-orchestration.md`.

## When to skip beats methodology

- One-off short pieces (tweets, single-paragraph drafts, one-shot emails) — beats are overhead the piece can't earn back
- Iteration on already-drafted prose where structural rework isn't the goal — beats are upstream of prose, not downstream
- Author has a working draft they like and just wants polish — skip Beat Map, run Apply Protocol with existing prose as preservation-scope source

Beats methodology is the right investment for chapter-scale work, multi-section essays, and any piece where structure is load-bearing and the author wants the writing to land without massive post-draft surgery.

# Book Mode

Workflow for long-form book projects. Inverts the usual minion model: author conjures BEATS, minion materializes PROSE from beats ONE BEAT AT A TIME. Editor keeps beats sharp and detects when a specific beat's prose has gone stale relative to that beat.

Invoked when project is a multi-chapter book and author signals book-mode work (creating a new book project, working on a chapter, dumping ideas). Sits on top of Apply Protocol — Apply runs inside this per-beat orchestration loop.

Orienting principle: **done > polished.** Generate fast, polish never — until the whole book is generated. Anchor Iteration is deferred to a later phase.

## Prerequisites: Argument Arc → Global Beat Sheet → Chapter Architecture → Reorg

Book Mode operates INSIDE committed chapter containers, AFTER beats have been sorted into them. The upstream chain:

1. **Argument Arc** — book's logical spine, in the author's voice.
2. **Global Beat Sheet** — every beat the book needs, in approximate argument order, no chapter assignment yet. Built via 5-pass extraction (`docs/beats.md`) at the BOOK level. Supplies raw material for chapter architecture.
3. **Chapter Architecture** (`docs/chapter-architecture.md`) — reads Argument Arc AND Global Beat Sheet together as evidence; commits chapter container shapes with substantive names, validated boundaries, one-sentence chapter promises. 5-pass protocol: ARC + BEATS RE-READ → CHUNK → NAME → BOUNDARY VALIDATION → COMMIT TOC.
4. **Reorg Beats by Chapter** — sort the Global Beat Sheet into committed containers. Resolve fuzzy boundaries. Output: each chapter container holds its assigned beats.

Per-chapter beat work + prose materialization (Book Mode's core loop) begin AFTER all four prerequisites complete.

If a project enters Book Mode without these — no global beat sheet, no committed TOC, or with an "inherited" chapter list that was never validated — STOP. Run the upstream phases first. Generating per-chapter beats inside wrong containers is the most expensive error in the pipeline.

When the TOC shifts during the project (chapters merge, split, rename), the workspace container structure updates in lockstep — NEVER DELETE any chapter container; merged/absorbed chapters become Variants of the receiving chapter.

## Unit of sync is the BEAT, not the chapter

Load-bearing distinction. A chapter is not "stale" or "current" as a single unit. Each beat has its own materialization state:

- **not-written** — beat exists in beat sheet, no prose materialized yet. Default state. Most beats in most chapters at most points in time.
- **current** — beat is materialized AND beat sheet's revision matches the revision that produced the prose.
- **stale** — beat is materialized but beat sheet's revision of that beat has changed since.

Chapter "completeness" is a roll-up readout: "Ch 2 has 2/7 beats current, 0 stale, 5 not-written." Information for the author, not a binary flag the methodology acts on.

A chapter in mid-draft with most beats unwritten is the NORMAL state. Not a broken state. The methodology handles it as default.

## FIRM RULE: NEVER delete without explicit per-item permission

In book mode the editor never deletes anything. Not a materialized beat doc. Not a Variants doc. Not an Ideas doc. Not a Beats doc. Not a Concept Dump entry. Not a legacy draft. Not a "workshop fragment" that looks superseded. Nothing.

Editor MAY: move, rename, set frontmatter, append flags to titles (`[STALE]`), append annotations, propose deletions for the author to act on. Deletion only happens on explicit author approval for that specific doc.

Beat drafting is iterative. Same prose may be wanted again. A doc that looks like a "workshop fragment" today turns out to be the canonical source tomorrow when a regen disappoints. Recoverability from OS trash is not a substitute — trash gets cleared, restores get missed, author shouldn't have to hunt for what the editor judged "redundant."

When in doubt, move to Variants. Variants exists to hold anything the editor isn't sure about.

## Workspace structure

One container per chapter at workspace root, holding both the beats authority and the per-beat materializations:

```
<Book Workspace>/
├── Concept Dump                       (workspace-level scratchpad, unsorted ideas)
├── Book Spine/                        (Argument Arc, Thesis, Audience, Voice & Form, Decisions Log, TOC)
├── Ch 1/
│   ├── Ch 1 — Beats                   (canonical authority — beat headers + sub-beat commitments)
│   ├── Ch 1 — Ideas                   (chapter-scoped scratchpad)
│   ├── Materialized Beats/            (one doc per beat that has been written)
│   │   ├── B1 — <beat title>
│   │   ├── B2 — <beat title>
│   │   └── ...
│   └── Variants/                      (anything not in active rotation; nothing here is deleted by the editor)
│       └── ...
├── Ch 2/
│   └── (same shape)
└── ...
```

The Concept Dump catches ideas that don't yet belong to a specific chapter. Editor sweeps and proposes chapter/beat slots.

Each chapter's Ideas doc catches chapter-scoped fragments — scenes, mechanisms, citations, half-formed arguments. Editor sweeps and proposes which existing beat absorbs the idea or where to insert a new sub-beat.

The Materialized Beats subcontainer is the chapter's actual prose, one doc per beat. When B1 is regenerated, prior B1 doc moves to Variants and new one takes the B1 slot. Chapter's full text is the in-order concatenation of these docs. (A consolidated `Ch N — Manuscript` doc is OPTIONAL — generate only when chapter is materially complete or author needs to read the full flow.)

The Variants subcontainer holds anything older or alternative: prior beat versions after regeneration, legacy wholesale drafts predating per-beat materialization, alternate takes the author wants to keep around for line salvage.

## Per-beat sync link (frontmatter on each materialized beat doc)

Every materialized beat doc carries frontmatter linking it to its source beat:

```yaml
beat_id: B1
beat_title: "Adenosine is the chemistry of tiredness"
generated_from_beats_doc: <docId of the chapter's Beats doc>
generated_at: <ISO date>
status: current   # current | stale
source_note: <optional — where the prose came from if not a fresh minion run>
coverage_note: <optional — flags sub-beats that aren't fully covered>
```

`source_note` is set when prose was extracted from an existing doc (legacy wholesale draft, prior multi-beat workshop doc) rather than produced by a fresh Apply Minion run. Format: `"Extracted from <source-doc-title> (<docId>) in Variants. Apply + Rewrite passes applied."`

`coverage_note` is set when materialized prose doesn't cleanly cover every sub-beat in the current Beats doc. Format: `"Covers sub-beats 2.0-2.4, 2.6, 2.7. Missing 2.5 (visual-ornament roster) explicitly."` Use when a beat is "current but incomplete" — author then decides whether to add missing material or accept partial coverage.

When the editor regenerates the beat, these fields update on the new doc. When beat sheet's text for that beat changes but no regeneration has run yet, editor flips `status: stale` on the materialized doc and appends `[STALE]` to its title.

## Beat extraction (where beats come from)

Beats arrive in the Beats doc by two paths:

**1. Cold-start (greenfield chapter).** Chapter is empty, author has the topic in their head. Run the **5-pass extraction** in `docs/beats.md` (DUMP → TENSION → CATEGORY → SEQUENCE → COMPRESSION). Editor walks author through each pass, captures beats verbatim, structures into Beat Map artifact. Output: ~30 section beats grouped under 8-12 chapter-arc beats.

**2. Incremental sweep (ongoing additions).** Chapter already has beats; author dumps new ideas into workspace `Concept Dump` or chapter `Ideas` doc. Editor sweeps and proposes slots ("new sub-beat in Ch 5 between 5.3 and 5.4"; "expands beat 7.2 with the chimp-coalition mechanism"). Author approves. Editor writes the new sub-beat into the Beats doc. Any materialized beat whose commitment changed gets marked `stale`.

Both paths apply the principles from `docs/beats.md`: **query the author, never propose from cold; beats are commitments (outcomes), not content; let the minion's training data carry references.**

The 5-pass is for cold-start. Incremental sweep is the ongoing default once a chapter has an initial beat structure.

## Extraction path (existing prose → Materialized Beats)

When prior work exists as a wholesale chapter draft or multi-beat workshop doc, the editor can extract it into per-beat docs without regenerating. Use when existing prose is good enough to ship and re-materializing fresh would lose voice work already done.

Pattern:

1. Source doc stays in (or moves to) Variants with `draft_type` frontmatter (`legacy_wholesale`, `extraction_source`, etc.) and a clarifying note. NEVER DELETE the source.
2. Editor reads source and identifies beat boundaries (typically marked by h2 headers like `B1 — ...`, `B2 — ...`).
3. Editor creates one `B<N> — <title>` doc per beat in Materialized Beats and populates with beat's prose verbatim (just paragraphs, no h2 header).
4. Frontmatter on each new doc: `status: current` (prose IS current to source), `source_note: "Extracted from <source-doc-title> (<docId>) in Variants."`
5. If extracted prose doesn't cleanly cover every sub-beat in the current Beats doc, add `coverage_note` flagging missing material. Surface the gap to the author.

Source doc stays in Variants as audit trail. NEVER DELETE it.

## The loop

1. **Author dumps ideas.** Workspace Concept Dump for unsorted; chapter Ideas doc for chapter-scoped fragments.
2. **Editor sweeps.** Reads new entries, proposes slots: "new sub-beat in Ch 5 between 5.3 and 5.4" or "expands beat 7.2 with the chimp-coalition mechanism."
3. **Author approves.** Editor writes to the relevant Beats doc.
4. **Editor flips affected beat-doc status.** Only materialized beats the change touched get `status: stale` + `[STALE]` in title. Untouched beats stay current. Not-written beats stay not-written.
5. **Materialization signal.** Author signals "write B3" or "regenerate B1" OR a not-written beat hits saturation (no pending ideas) and author signals ready. Editor fires Apply Minion against THAT BEAT'S commitment (not the whole chapter).
6. **Old beat-doc → Variants.** If regenerating an existing beat, prior version moves to `Ch N / Variants / B<N> — <title> v<n>`. New beat doc takes the Materialized Beats slot with fresh frontmatter.
7. **No polish during draft phase.** Skip Anchor Iteration per beat. Goal is a complete book, not a polished beat.
8. **Polish phase opens later.** When every chapter has every beat materialized and current, polish phase opens. Editor consolidates beats into per-chapter Manuscript docs, runs Anchor Iteration per chapter, runs /anti-ai cleanup per chapter. Own phase, not interleaved with drafting.

## Editor's role per phase

**Drafting:**
- Sweep Concept Dump and Ideas docs (on-demand, when author dumps fresh material)
- Propose beat slots with specific positions ("between 5.3 and 5.4", "expands 7.2", "new top-level beat after B6")
- Maintain beat sheets — canonical authority
- Track per-beat sync state via frontmatter on materialized beat docs
- Fire Apply Minion per beat on materialization signals
- Archive superseded beat versions to Variants on regeneration
- Provide chapter completeness roll-ups on request

**Polish (later):**
- Per chapter: consolidate materialized beats into a single Manuscript doc
- Per chapter: fire Anchor Iteration to converge at 90/100
- Per chapter: fire /anti-ai cleanup pass (MANDATORY after Anchor Iteration)
- Surface anchor-critique convergent diagnostics to the author per FIRM RULE 2 — discuss before revising
- Apply agreed cuts directly; spawn revision minions for agreed rewrites
- Solicit author's read-through comments and inline marks; surgically address each

## Minion's role

Apply Minion materializes prose from a SINGLE beat's commitments. Brief shape per the standard Apply Protocol (`docs/apply-protocol-deep.md`) — COMMITMENTS section contains just that one beat's sub-beats (and any necessary adjacent-beat context for seam continuity if not the first beat).

Rewrite Minion is rarely needed in book mode. When a beat changes, editor re-fires Apply for that beat against the updated commitment. Apply's no-source-prose-ceiling property is preserved.

Anchor Iteration polish minion is NOT fired per beat during drafting. Save for polish phase, where it fires per CHAPTER on the consolidated Manuscript.

## Chapter completeness readout

On request ("status of Ch N", "how is the book"), editor produces a per-chapter table:

```
Ch 2 — Sleep Pressure (7 beats)
  B1 — Adenosine is the chemistry of tiredness        CURRENT
  B2 — Caffeine blocks the signal, not the debt       CURRENT
  B3 — Sleep pressure builds linearly while awake     not-written
  B4 — The circadian rhythm is an independent clock   not-written
  B5 — The two systems normally rise and fall together  not-written
  B6 — Jet lag is the two systems desynchronized      not-written
  B7 — The afternoon dip is built in, not earned      not-written

  Roll-up: 2/7 current, 0 stale, 5 not-written
```

Working dashboard for drafting.

## Anti-patterns

- **Treating the chapter as the sync unit.** Chapters aren't stale; beats are. Marking a whole chapter `[STALE]` because one beat drifted hides which beat needs regen and slows the loop.
- **Materializing the whole chapter at once.** Apply fires per beat in this mode. Wholesale generation produces prose that isn't independently regenerable beat-by-beat and forces full rewrites on small commitment changes.
- **Polishing during drafting.** Tempting after a beat lands well. Resist. Polish phase exists for a reason — prose isn't done until the whole book exists.
- **Editing the materialized beat directly during drafting.** If prose needs to change, change the BEAT in the Beats doc and regenerate that beat. Direct prose edits don't propagate to the beat sheet, so beats become a stale record of intent.
- **Hoarding ideas in your head.** Dump immediately. Even half-formed. Ideas docs are cheap; lost ideas are expensive.
- **Editor deleting Variants on its own initiative.** Variants is the audit trail and the line-salvage library. Editor never deletes its contents. Author may instruct deletion of specific docs at any time; that decision is the author's alone.
- **Spawning Clarity-style review passes.** Already tested. Already failed. Apply → (later) Anchor Iteration → (later) /anti-ai. Three passes, no more.

## Initial setup for a new book project

1. Create the workspace.
2. Create the Spine container with: Argument Arc, Thesis, Audience & Reader Journey, Voice & Form, Decisions Log.
3. Create workspace-level Concept Dump doc.
4. **Build the Argument Arc** — query the author through the book's logical spine; capture verbatim. Add as doc in Spine container.
5. **Build the Global Beat Sheet** — run 5-pass extraction (`docs/beats.md`) at the BOOK level. Every beat the book needs, in approximate argument order, NO chapter assignment yet. Add as doc in Spine container.
6. **Run Chapter Architecture** (`docs/chapter-architecture.md`) — 5-pass protocol (ARC + BEATS RE-READ → CHUNK → NAME → BOUNDARY VALIDATION → COMMIT TOC) that commits the TOC. Add TOC doc to Spine container. Do NOT skip to step 7 with an inherited or assumed chapter list.
7. For each chapter the COMMITTED TOC names: create `Ch N` container with `Ch N — Beats`, `Ch N — Ideas` docs, and empty `Materialized Beats/` and `Variants/` subcontainers. Chapter container names reflect the TOC's substantive chapter names, not categorical placeholders.
8. **Reorg Beats by Chapter** — sort the Global Beat Sheet into the `Ch N — Beats` docs. Each beat picks a home; beats that don't fit go to a chapter's Variants with a note; beats that suggest a missing chapter trigger a Chapter Architecture re-run.
9. **Per-Chapter Beat Draft** (per chapter, as ready to draft) — run 5-pass extraction again at chapter level on assigned beats; refine into 8-12 chapter-arc beats with sub-beats. `Ch N — Beats` now holds the per-chapter beat list ready for materialization.

After setup, the loop runs. Author dumps. Editor sweeps. Minion writes a beat at a time. The book materializes.

# Chapter Architecture

Phase: container commit. Output: committed TOC — N chapter containers, each with a substantive chapter brief, a one-sentence promise, a validated adjacent boundary, source/beat mapping. Run unconditionally for book-scale work.

**There are two pipelines, determined by the book class. Run the book-class question FIRST.**

## The book-class question (run FIRST)

Before any chapter work, answer: **what kind of book is this?**

Two classes, two pipelines:

### Argument-driven books
One extended argument is the value. Newport (*Deep Work*), Pinker, Haidt, popular essays that became books. The author's value-add is the argument itself; chapters are beats of the argument.

**Inputs:** Argument Arc, Global Beat Sheet.
**Pipeline:** Argument Arc → Global Beat Sheet → Chapter Architecture (5-pass) → Reorg → Per-Chapter Beats → Draft.

### Domain-driven books
Popular science / reference-rich / source-material-heavy. Sapolsky's *Behave*, Wrangham's *Catching Fire*, Dawkins' *Selfish Gene*, Christopher Ryan's *Sex at Dawn*. The author has pre-existing concept docs / research / a knowledge graph. The book's value is the COMPLETE PICTURE of a scientific or conceptual terrain. Chapters = the domains; the through-line is implicit, never stated as a single argument.

**Inputs:** Source-material inventory (concept docs, research notes, prior drafts), optionally an Argument Arc as implicit through-line.
**Pipeline:** Source Inventory → Domain Identification → Act Grouping → Chapter Pattern → Candidate TOC → Reshape → Lock → Pilot.

### How to decide

| Signal | Class |
|---|---|
| Author has an extended argument to make, no existing knowledge graph | Argument-driven |
| Author has a rich source library / concept docs / research notes | Domain-driven |
| Author has both | Domain-driven (the argument becomes implicit through-line) |
| Author has neither yet | Argument-driven (build the arc first to discover the book) |
| Book is prescriptive/transformation popular science | Domain-driven default — argument-driven starves on prescription |
| Book is one big idea unpacked | Argument-driven |
| Book is "the complete picture of X domain" | Domain-driven |

When in doubt for popular-science / reference / transformation work: **domain-driven is the better default**. Argument-driven books in this class collapse into one abstract action call ("fix your light, time your meals, protect your wind-down") that doesn't justify the word count. Domain-driven books deliver a complete operating picture; the reader leaves changed because he sees himself as evidence, not because he was told what to do.

## Pipeline A: Argument-driven (one-argument book)

### Where it sits

```
Argument Arc                    (book's logical spine)
  ↓
Global Beat Sheet               (all beats for the book, pre-chapter)
  ↓
CHAPTER ARCHITECTURE            ← 5-pass commit
  ↓
Reorg Beats by Chapter          (sort global beats into committed containers)
  ↓
Per-Chapter Beat Draft          (refine the per-container beat list)
  ↓
Chapter Draft                   (minion materializes prose, beat by beat)
```

Hybrid order is the model that holds: pure top-down (chapters from just the Argument Arc) fails for lack of evidence; pure bottom-up (per-chapter beats without containers) fails for lack of structure. Architecture reads the beat sheet as evidence ("what bounded chunks does this material naturally form?") and commits container shapes the beats can be sorted into.

### Pass 1: ARC + BEATS RE-READ

Editor and author re-read Argument Arc AND Global Beat Sheet together. Not as outline — as content. What does the book argue? What beats exist as raw material? Arc shows the spine; beats show the texture.

### Pass 2: CHUNK (with beats as evidence)

Editor asks: "Looking at the arc and the beat sheet together — what bounded conceptual chunks does this material naturally form? Which beats cluster?"

Author talks. Editor structures the chunks as candidate chapter containers using beat-sheet clustering as evidence. No naming yet. Count is whatever falls out — typically 5-12, driven by material not a target.

Query-first principle from `docs/beats.md`: editor STRUCTURES what the author is grouping, doesn't propose chunks from cold.

### Pass 3: NAME

For each candidate container: "What is the chapter brief — the one-sentence statement of what this chapter does for the reader?"

Each name must be substantive (telegraphs content, not category), declarative or descriptive (claims something specific), holdable in one sentence.

Test: can the author state the chapter's brief without looking at the arc? No → container hasn't crystallized; return to Pass 2.

### Pass 4: BOUNDARY VALIDATION (fuzzy is OK; shape must be right)

For each pair of adjacent containers:
- Do they share central concepts? (Spillover = wrong boundary)
- Is one too big / too thin? (Split or absorb)
- Does the transition feel natural? (Forced = wrong boundary)

Boundary commits as chunk SHAPE. Per-beat assignment refines in Reorg. Don't burn cycles on a single beat's home in Pass 4.

### Pass 5: COMMIT TOC

Output: chapter number, name, one-sentence promise, word target, arc-beat mapping. Reorg begins immediately after.

## Pipeline B: Domain-driven (source-material-rich book)

### Where it sits

```
Source Material Inventory          (read existing concept docs / research)
  ↓
Domain Identification              (natural containers → candidate domains)
  ↓
Act Grouping                       (3-act book structure: cluster domains)
  ↓
Chapter Pattern                    (4-act internal structure per chapter)
  ↓
Candidate TOC                      (title + beats + vignette slots + sources)
  ↓
Author Reshape (inline comments)
  ↓
Lock + Pilot                       (one chapter end-to-end to validate format)
  ↓
Draft the rest                     (pattern validated, proceed in parallel)
```

The pipeline reverses the argument-driven order: instead of "build the argument, then chunk it into chapters," it's "see what's already in the source material, find the natural domains, group into acts, design the chapter pattern, draft the TOC against what exists." Source-driven, not argument-driven.

### Phase 1: Source Material Inventory

Read or surface the author's existing material:
- If author has an OpenWriter Concepts workspace: `list_workspaces` → `get_workspace_structure` surfaces the structure. Crawl each container's docs for first paragraph (lightweight — don't read full bodies yet).
- If material is in files/notes scattered around: glob/grep to inventory. Get titles + first paragraphs into a single survey doc.
- If author has prior book drafts: list those too (they become vignette material later, not chapter material).

Goal: know what the author already has authority on. The inventory is the WORKING SET that all subsequent decisions reference.

### Phase 2: Domain Identification

**The natural groupings in the source material ARE the candidate scientific/conceptual domains.** Don't impose categories from outside.

If the Concepts workspace has containers (e.g., Sleep Pressure / Circadian Rhythm / Dreaming / Sleep Debt) — those containers are the candidate domains. If material is unstructured, propose groupings to the author and let them confirm.

Each domain becomes a CANDIDATE chapter (or 2-3 chapters if dense enough). Domain count per book typically 5-8 for trade nonfiction.

Note thin domains (1-2 docs only) — they may need to be absorbed into adjacent richer domains, or expanded with new source material.

### Phase 3: Act Grouping (3-act book structure)

**Cluster the domains into 3 acts that produce a coherent emotional/conceptual flow at book level.**

The 3-act grouping is the dopamine flow above chapter level. It's the meta-structure the reader feels even if it's never named. Typical patterns:

| Act pattern | Best for |
|---|---|
| Architecture / Mechanism / Behavior | Popular science. "What you are / how it works / how you live as it." |
| Diagnosis / Reframe / Practice | Transformation books with prescriptive lean |
| Origin / Evolution / Manifestation | Narrative-history popular science |
| Foundation / Forces / Application | Reference-rich domain books |

The 3-act grouping is for the author's structural clarity and the reader's emotional flow. **Acts don't need to be labeled in the book itself** — they're often invisible to the reader, but they make the chapter sequence feel like a journey rather than a checklist.

Chapter count per act is driven by source density. Roughly balanced is ideal (3+3+3 or 4+3+3), but uneven is fine if the material demands it.

### Phase 4: Chapter Pattern (4-act internal structure)

**Every chapter runs the SAME internal pattern. Defining the pattern explicitly is load-bearing — it's what makes domain-driven books feel coherent across chapters even when the domains are heterogeneous.**

The 4-act chapter pattern:

1. **Introduce the mechanism.** The science. What it is, how it works, why it exists.
2. **Explore the logic.** Comparative evidence (other species, ancestral data, cross-cultural examples), the implications of the mechanism, the deep unpack.
3. **Bridge to modern (vignettes).** Short 200-400 word a-ha moments showing the mechanism operating in current life. Punctuation, not main course. See "Vignette library" below.
4. **Setup next.** The implication that pulls the reader to the next chapter.

**Why this pattern is load-bearing for domain-driven books:**

Bridge-to-modern vignettes are how a domain-driven book delivers prescription WITHOUT self-help register. The reader sees the mechanism running in his actual life via the vignettes — and the action becomes obvious from accuracy. No "now do these 5 things" chapter is needed because the reader has already seen himself as evidence.

This is the structural answer to "how does a popular science book transform the reader without becoming a self-help book." Sapolsky's *Behave* does this. Wrangham's *Catching Fire* does this. The reader closes the book changed, but at no point was he prescribed a behavior change.

### Phase 5: Candidate TOC draft

For each chapter: **title + word target + 5-8 beats + bridge-to-modern vignette slots + source-doc mapping.**

Format: compact, scannable, one screen if possible. The candidate TOC is for the author to react to, not to read as prose.

```
### Ch N — Chapter Title  (Xk words)
- Beat one in short form
- Beat two
- ...
- *Vignettes:* candidate a-ha drops for the bridge-to-modern section
- *Sources:* Concept docs / research notes the chapter draws from
```

The source-doc mapping is critical. It:
- Prevents drift (chapter can be traced back to canonical source material)
- Lets the author verify coverage (no domain doc orphaned)
- Makes chapter drafting straightforward (the drafter knows what to read first)

### Phase 6: Author reshape via inline comments

Hand the candidate TOC to the author. **Author marks up directly via inline comments on the TOC doc** (or the editor's equivalent — OpenWriter agent marks, Google Docs comments, etc.). Editor reads the comments, identifies which are structural changes vs content additions vs confirmations, and updates the TOC accordingly.

Author owns substance; editor owns structure. Don't argue with author comments — incorporate or ask one clarifying question.

Iterate v1 → v2 → v3 until the author signals the shape is right ("this matches my view perfectly"). Resolve comments after each pass so the doc stays clean.

### Phase 7: Lock spine + pilot

Once author approves the reshape, **lock the TOC**.

Then pick ONE chapter to pilot end-to-end with the 4-act pattern — typically the chapter with the **densest source material** (lowest risk, fastest validation). The pilot tests the format: does the 4-act pattern work, do the vignettes land, does the chapter promise hold across the word count?

After pilot validation, the rest of the chapters draft in parallel against the validated pattern.

## The 4-act chapter pattern (deeper unpack)

Both pipelines benefit from a defined internal chapter pattern. For domain-driven, the 4-act pattern above is the load-bearing default. For argument-driven, the chapter pattern is usually simpler: setup → argument-beat → evidence → bridge.

### Act 1: Introduce the mechanism
- The scientific claim, named cleanly
- What it is, in plain language
- Why it exists (the evolutionary / structural reason)
- Establish the conceptual handle the rest of the chapter uses

Length: ~10-15% of chapter word count.

### Act 2: Explore the logic
- Comparative evidence (other species, other cultures, ancestral data)
- Deep unpack — the science with rigor, not abstraction
- Implications — what follows from the mechanism being true
- This is where the chapter EARNS the reader's belief; the science gets the room

Length: ~50-60% of chapter word count.

### Act 3: Bridge to modern (vignettes)
- 2-5 short vignettes (200-400 words each) showing the mechanism in current life
- Each vignette is punctuation, not main course — quick a-ha, then back to the science
- Vignettes drop in naturally where the science calls them, not as a separate section break
- The reader sees himself / sees current culture as the mechanism running

Length: ~20-25% of chapter word count, distributed throughout Acts 2 and 3.

### Act 4: Setup next
- The implication that the next chapter resolves
- The question the reader is now sitting with
- The pull that makes him turn the page

Length: ~5-10% of chapter word count.

### Failure modes
- **All mechanism, no bridge.** Chapter feels academic. Reader respects it but doesn't change.
- **All bridge, no mechanism.** Chapter feels like pop-culture writing. Reader skims.
- **Bridge as a separate section break.** Loses the inline rhythm. Vignettes should weave into the science, not punctuate from outside.
- **No setup-next.** Chapter ends. Reader closes the book.

## The 3-act book grouping (deeper unpack)

Acts at book level are the meta-structure above chapters. The reader rarely notices them explicitly, but they make the chapter sequence feel like a journey.

The act grouping answers: "What's the emotional flow across chapters?" Typical answers:

- **Architecture / Mechanism / Behavior** — what you are, then how it works, then how you live it.
- **Diagnosis / Reframe / Practice** — current state, new frame, new operation.
- **Origin / Evolution / Manifestation** — where it came from, how it changed, where it lives now.

**The 3-act grouping is a tool for the author, not a label for the reader.** Most domain-driven books don't print "Act 1" / "Act 2" / "Act 3" on the page. They just feel structured because the author grouped that way during architecture.

### When to use 4 acts vs 3

3 is the default. 4 works if the book has a clear closing synthesis chapter that stands apart from the prescription/manifestation act. Example: 3 acts of domain exposition + 1 closing chapter that pulls the whole picture together.

Don't go above 4 — beyond that, the reader can't hold the structure.

## The vignette library (flat, deploy by natural fit)

Vignettes are 200-400 word a-ha moments showing a scientific mechanism operating in modern life. The bridge-to-modern Act 3 of every chapter deploys vignettes.

### Library architecture

**Flat library, not pre-mapped to chapters.** Each vignette is its own short doc (or its own paragraph block in a single Vignettes doc). Tagged with the concepts it relates to. Vignettes deploy WHERE THEY NATURALLY FIT during chapter drafting — the science calls forth which vignettes drop in.

**Don't pre-assign vignettes to chapters.** Pre-assignment forces decisions before they need to be made. Flat library + natural-fit deployment is more flexible and matches how chapter drafting actually works.

### Vignette extraction

Sources for vignettes:
- **Prior book drafts (agent extracts).** Full chapters from prior drafts often distill to single 300-word vignettes in the new structure (the chapter's a-ha core, stripped of the scaffolding). The author already wrote them; the agent compresses.
- **Research notes (agent extracts).** Specific studies, case stories, surfaced moments worth naming.
- **The author's own observations (AUTHOR PROVIDES).** Field examples, personal anecdotes, lived recognitions. Agent never invents these — it asks. See "Scene = author, science = agent" below.
- **Cultural moments worth naming (mixed).** The looksmaxxer subculture. The QB as cultural icon. The rockstar enchanting the crowd. Agent can surface candidates from observable culture; if the vignette requires lived experience of the moment to land, ask the author.

### Vignette form

- 200-400 words. Shorter is better. Long-form is a sign the vignette wants to be a chapter (or is hiding multiple a-ha moments — split).
- Single mechanism per vignette. Don't try to make one vignette do double duty.
- Visceral, concrete, specific. Not abstract claim. Not list. A moment, a scene, a recognition shock.
- Ends without a moral. The mechanism speaks; the reader draws the implication.

### Inventory pass

Run a light vignette inventory pass during chapter drafting, not before. For each chapter being drafted, scan the vignette library for natural-fit candidates, drop them into the bridge-to-modern act. Iterate.

## Scene = author, science = agent (firm rule)

A load-bearing division of labor across both pipelines and every chapter: the AUTHOR supplies scenes; the AGENT supplies science. Violating this produces inauthentic books regardless of how polished the prose is.

### Definitions

**Scene** = any lived moment, autobiographical material, personal observation, recognition shock, specific human experience. The vignettes that drop into Act 3 of every chapter. The opening hook of an introduction. A credibility paragraph. Any place the reader needs to feel a person, not a model.

**Science** = mechanism, evidence, comparative biology, theory, structure, exposition, transitions, implication, setup-next hooks. Everything around the scene.

### The rule

The agent NEVER invents scenes. When a beat or section calls for lived material, the agent inserts a placeholder and asks the author:

```
[SCENE PLACEHOLDER — author provides]
What the slot needs: <one-line description>
Candidate moments from author's known material:
- <option from author's life / prior writing>
- <option>
- <option>
```

The author drafts 1-2 paragraphs of raw lived material (or signals which candidate to develop). The agent produces everything around it — opening framing, transition into the scene, implication after.

### Why

Invented scenes lack lived detail. Readers detect agent-confected experience instantly — the wrong sensory beats, the too-clean arc, the absent specific that someone who was actually there would have noticed. A book of agent-invented scenes reads as inauthentic even when technically polished.

The author's voice lives in the scenes. The agent's voice can carry the science. Mixing this up — author drafts dry mechanism, agent invents lived moments — produces the worst of both: the book reads as inhuman AND under-evidenced.

### When to ask vs when to write

| Material type | Source |
|---|---|
| Lived moment / personal anecdote | Author |
| Vignette (bridge-to-modern) | Author for the moment; agent for framing |
| Opening hook (introduction or chapter) | Author |
| Author credibility / biographical paragraph | Author |
| Cultural moment used as vignette | Either; if author has lived it, prefer author |
| Mechanism / theory / exposition | Agent |
| Comparative biology / cross-species evidence | Agent |
| Research synthesis / citations | Agent |
| Transitions between beats | Agent |
| Setup-next chapter hooks | Agent |
| Implication / "what follows" | Agent |

### Workflow

1. Agent identifies that a beat needs lived material
2. Agent inserts `[SCENE PLACEHOLDER — author provides]` with one-line description + 2-4 candidate scene TYPES pulled from the author's known life / source material (NOT invented scenes)
3. Author drafts 1-2 paragraphs of raw lived material, or names which candidate to develop
4. Agent produces everything around the scene — opening framing, transition into the scene, implication after, link to next beat

### Sub-rule: don't invent candidate scenes either

Drafting three "candidate opening hooks" for the author to pick from is still invention — even framed as a menu. The scenes aren't real and the author shouldn't have to react to confected material as if it were a real choice.

What the agent CAN do: list candidate scene SLOTS pulled from the author's known life / prior writing / source material ("the all-nighter that backfired," "the first week with a sleep tracker," "the jet-lag conference disaster"). The author then picks a slot and writes the actual scene.

What the agent CANNOT do: draft prose pretending to be the author's lived moment. Even labeled "candidate" or "draft for review" — it pollutes the doc and primes the author to react to fiction instead of supplying truth.

### Operational rule for chapter and intro drafting

Before drafting any section that calls for lived material:
1. STOP — do not draft the scene.
2. Insert the placeholder + slot candidates.
3. Ask the author which slot to develop, or ask for a fresh slot from his life.
4. Wait for the author's 1-2 paragraphs.
5. Resume drafting everything around the scene.

This applies to both pipelines. It applies in beats. It applies in introductions. It applies in transitions. It applies anywhere the human animal is required and the model is not enough.

## What a committed chapter container is (both pipelines)

1. **Bounded conceptual chunk.** Holds ONE coherent move. If describing requires "and also" multiple times, container is wrong — split, or rename to bundle under a unified frame.
2. **Substantive name (the chapter brief).** Names like "The Missing Manual" or "Sleep Pressure: The Chemistry of Tiredness" telegraph what's inside. Categorical labels ("Chapter 1", "Hook", "Setup", "Diagnosis") don't.
3. **Boundaries that don't bleed (but are fuzzy at commit).** Adjacent chapters don't share territory. Boundary SHAPE commits at architecture time. Per-beat assignment refines in Reorg.
4. **Holdable size.** Too big = reader can't carry. Too thin = the chapter is actually a sub-beat of an adjacent chapter.

## Downstream: Reorg Beats by Chapter (argument-driven only)

For argument-driven books, after TOC commits, sort the Global Beat Sheet INTO the chapter containers using the chapter brief as the test.

For domain-driven books, Reorg is unnecessary — chapter sources are already mapped (Phase 5 of the domain-driven pipeline). The equivalent step is the **vignette inventory pass** that runs during chapter drafting.

## Workspace implication (Book Mode integration)

Chapter containers in `docs/book-mode.md` get created AFTER the TOC commits. Container shape stays the same regardless of pipeline.

When TOC shifts (chapters merge, split, rename), update container structure in lockstep and move docs into their new homes. **NEVER DELETE** any chapter container — merged or absorbed chapter container becomes a Variant of the receiving chapter, preserving the work.

## When chapter architecture must re-run

- Argument Arc shifts materially (argument-driven)
- New source material lands that changes domain identification (domain-driven)
- Author re-class: book turns out to be the other class than originally assessed
- Chapter beats consistently feel "too much" or "too thin"
- Reader feedback shows confusion at chapter boundaries
- A new conceptual frame emerges that re-groups chapters more coherently

Architecture passes are cheap. Beat work in wrong containers is expensive. Re-validate when in doubt.

## Anti-patterns

- **Skipping the book-class question.** Defaulting to argument-driven because that's what `chapter-architecture.md` historically documented. For prescriptive popular science, this produces a "narrow" book — heavy diagnosis, thin prescription, one abstract action call. Always run the book-class question first.
- **Pillar method as the back-half fix.** Recognizing the argument-driven book is starving on prescription and bolting on a pillar-method back half (body / marriage / work / etc.). This works but turns the book into self-help. If the author wants popular science, switch to domain-driven and use the 4-act pattern + vignettes instead.
- **Inherited TOC unvalidated.** Chapter list fixed because someone wrote one. Validate through the protocol for the current book class.
- **Per-chapter beats before containers.** Generating beats inside a specific chapter before chapter containers are committed.
- **Architecture without source/beat evidence.** Trying to commit chunks in the abstract.
- **Categorical chapter names.** "Hook", "Setup", "The Central Thesis", "Mechanism", "Diagnosis" — writer's working labels, not reader's holding units.
- **Forcing a target count.** Right count is whatever the material's conceptual chunks demand.
- **Vignettes pre-mapped to chapters.** Forces decisions before they need to be made. Flat library, natural-fit deployment.
- **Vignettes as section breaks.** Loses the inline rhythm. Vignettes weave into the science, not punctuate from outside.
- **No 3-act book grouping (domain-driven).** Chapter sequence reads as a checklist rather than a journey. Group into acts even if invisible to the reader.
- **Agent invents scenes.** Drafting lived moments, autobiographical hooks, or "candidate" scene options for the author is invention even when labeled as a draft. ASK; don't write. See "Scene = author, science = agent" above.

## Pipeline (full reference)

```
Argument-driven:
  Argument Arc → Global Beat Sheet → Chapter Architecture (5-pass) → 
  Reorg Beats by Chapter → Per-Chapter Beat Draft → Materialized Beats → Manuscript

Domain-driven:
  Source Inventory → Domain Identification → Act Grouping → Chapter Pattern → 
  Candidate TOC → Reshape → Lock → Pilot → Draft (in parallel)
```

Each phase commits before the next begins. When a later phase exposes a problem with an earlier phase, return to that phase, fix, re-commit, propagate forward.

## When to skip chapter architecture

For one-off pieces (single essays, blog posts, tweets, threads) — sub-chapter scale, no boundaries to validate.

For book work: NEVER skip. Even if the book seems to have a "natural" structure, validate as a chapter-architecture pass (using whichever pipeline matches the book class). One architecture session saves weeks of beat rework.

## Precedent in the writing literature

- **Zinsser, *On Writing Well*** — chapter is the unit of organization.
- **Adler, *How to Read a Book*** — book is a hierarchy of containers; well-structured book = reader can restate each chapter's claim in one sentence.
- **Sol Stein, *Stein on Writing*** — chapter shape is the load-bearing decision.
- **McKee, *Story*** — every act/chapter is a promise + payoff. PROMISE is the chapter's identity.
- **Sapolsky, *Behave*** — domain-driven popular science exemplar; chapters organized by biological time scale, 4-act internal pattern.
- **Wrangham, *Catching Fire*** — domain-driven popular science exemplar; narrow thesis explored across ethological domains.
- **Newport, *Deep Work*** — argument-driven exemplar with structural Part 1 (argument) / Part 2 (practices) split.

Formal terms across these traditions: **chapter brief**, **chapter promise**, **chapter logline**. All describe the same thing — the one-sentence statement of what the chapter does for the reader.

# Long-Form Orchestration (book-scale work)

For book-scale projects with a logical arc or a rich source-material library. Editor builds architectural artifacts the minion drafts against and that survive context resets.

**Two pipelines, determined by book class. Always run the book-class question FIRST.** See `docs/chapter-architecture.md` for the decision criteria and the full protocols.

## The book-class question

| Class | Inputs | Pipeline |
|---|---|---|
| **Argument-driven** | Author has an extended argument to make | Argument Arc → Global Beat Sheet → Chapter Architecture (5-pass) → Reorg → Per-Chapter Beats → Draft |
| **Domain-driven** | Author has pre-existing concept docs / research / a knowledge graph | Source Inventory → Domain Identification → Act Grouping → Chapter Pattern → Candidate TOC → Reshape → Lock → Pilot → Draft |

When in doubt for popular-science / reference / transformation work: **domain-driven** is the better default. Argument-driven books in this class collapse into one abstract action call and starve on prescription. Full decision criteria in `docs/chapter-architecture.md`.

## Pipeline A: Argument-driven

```
Argument Arc  →  Global Beat Sheet  →  Chapter Architecture  →  Reorg Beats by Chapter  →  Per-Chapter Beat Draft  →  Chapter Draft  →  Research Notes
(book-level)     (all beats for the    (TOC + chapter briefs;    (sort global beats into    (refine per-container       (minion writes      (POST-draft enrichment:
                  book, pre-chapter,    bounded containers        committed containers;      beat list; sequence;        per beat;            canonicalize the references
                  raw material)         committed; fuzzy          resolve fuzzy              compression; sub-beats)     training data        the draft actually used)
                                        boundaries OK)            boundaries)                                            brings content)
```

Each phase commits before the next begins. Order is hybrid by design: Global Beat Sheet supplies raw material BEFORE architecture so containers commit on evidence; chapter architecture commits container shapes BEFORE reorg so beats have somewhere to land; per-chapter beat work refines INSIDE committed containers so dopamine flow is local. Skipping Chapter Architecture is the most common silent failure.

Stages, each built by querying the author:

1. **Argument Arc** — logical flow of the whole argument, beat by beat, in the author's words. Built by asking the author to talk through their argument and capturing verbatim where possible. Lives as a doc in the project workspace.

2. **Global Beat Sheet** — every beat the book needs, in approximate argument order, no chapter assignment yet. Built via 5-pass extraction in `docs/beats.md` (DUMP → TENSION → CATEGORY → SEQUENCE → COMPRESSION) at the BOOK level. Raw material chapter architecture will chunk into containers.

3. **Chapter Architecture** — TOC commit. 5-pass protocol (ARC + BEATS RE-READ → CHUNK → NAME → BOUNDARY VALIDATION → COMMIT TOC). Spec: `docs/chapter-architecture.md`.

4. **Reorg Beats by Chapter** — sort Global Beat Sheet into committed chapter containers using chapter brief as the test.

5. **Per-Chapter Beat Draft** — refine assigned beats into final per-chapter beat list. 5-pass extraction from `docs/beats.md` runs again at chapter level.

6. **Chapter Draft** — Apply Protocol per chapter-arc beat with section beats as commitments.

7. **Research Notes per chapter** — POST-draft enrichment. See `docs/beats.md` "research-after-draft inversion."

## Pipeline B: Domain-driven

```
Source Inventory  →  Domain ID  →  Act Grouping  →  Chapter Pattern  →  Candidate TOC  →  Reshape  →  Lock + Pilot  →  Draft
(read existing       (containers    (3-act book      (4-act chapter    (title + beats     (author       (one chapter      (parallel
 concept docs /       become         structure)       internal          + vignette         marks up      end-to-end to     against
 research notes)      candidate                       structure)        slots + source     inline)       validate          validated
                      domains)                                          mapping)                         format)           pattern)
```

Source-driven, not argument-driven. Reverses the argument-driven order: instead of "build the argument, then chunk it," it's "see what's already in the source material, find the natural domains, group into acts, design the chapter pattern, draft the TOC against what exists."

Stages:

1. **Source Material Inventory** — read or surface the author's existing material. If author has an OpenWriter Concepts workspace: `list_workspaces` → `get_workspace_structure` surfaces the structure. Crawl each container's docs for first paragraph (lightweight — don't read full bodies yet). Goal: know what the author already has authority on.

2. **Domain Identification** — the natural groupings in the source material ARE the candidate scientific/conceptual domains. Don't impose categories from outside. If the Concepts workspace has containers, those ARE the candidate domains.

3. **Act Grouping** — cluster the domains into 3 acts that produce a coherent emotional/conceptual flow at book level. Typical patterns: Architecture / Mechanism / Behavior; Diagnosis / Reframe / Practice; Origin / Evolution / Manifestation. The 3-act grouping is invisible to the reader but makes the chapter sequence feel like a journey.

4. **Chapter Pattern** — every chapter runs the same 4-act internal structure: introduce mechanism → explore logic → bridge to modern (vignettes) → setup next. This is load-bearing — it's how the book delivers prescription without self-help register.

5. **Candidate TOC** — for each chapter: title + word target + 5-8 beats + bridge-to-modern vignette slots + source-doc mapping. Compact, scannable.

6. **Author reshape via inline comments** — author marks up the TOC directly. Editor structures the reshape, iterates v1 → v2 → v3 until shape locks.

7. **Lock + Pilot** — lock the TOC, pick the chapter with densest source material, draft end-to-end to validate the 4-act pattern. Then draft the rest in parallel against the validated pattern.

8. **Vignette inventory** — runs DURING chapter drafting, not before. Flat library; vignettes deploy by natural fit.

9. **Research Notes per chapter** — same as Pipeline A.

Full domain-driven protocol in `docs/chapter-architecture.md`.

## Query method (build arc, beats, domains)

Architectural artifacts built the same way regardless of pipeline: editor asks the author focused questions, author talks, editor structures back. Author owns substance; editor owns structure.

**Query-first is the DEFAULT.** Even when author asks "what beats should we add?" or "what domains should we cover?", editor's first move is to ask back. Proposing structure from cold (editor brain → suggestion) is the failure mode. See `docs/beats.md` "Query-first principle: pull, don't propose" for the full rule.

**Scene = author, science = agent.** Anywhere a beat needs lived material — opening hooks, vignettes, autobiographical credibility paragraphs — the agent NEVER invents. It inserts a `[SCENE PLACEHOLDER — author provides]`, lists 2-4 candidate slots from the author's known life / source material, and waits for the author's 1-2 paragraphs of raw lived material. Then the agent produces everything around the scene. Full rule in `docs/chapter-architecture.md` "Scene = author, science = agent (firm rule)."

Pattern for the **Argument Arc**:

1. Ask one foundational question (e.g., "What's the central move of Ch X — the thing the reader walks out knowing?").
2. Author talks. Editor captures verbatim where possible, structures into arc-beat slots, writes to the doc.
3. Ask the next gap-filling question. Iterate until arc is dense enough.
4. Where project has a Concepts (source-material) workspace, MINE it before asking the author to recreate from scratch. Read the relevant source docs. Identify what's already canonical. Ask only for the gaps.

Pattern for the **Global Beat Sheet** (argument-driven): 5-pass extraction in `docs/beats.md` at BOOK level.

Pattern for **Chapter Architecture**:
- Argument-driven: 5-pass protocol (ARC + BEATS RE-READ → CHUNK → NAME → BOUNDARY VALIDATION → COMMIT TOC)
- Domain-driven: 7-phase pipeline (Inventory → Domain ID → Act Grouping → Chapter Pattern → Candidate TOC → Reshape → Lock + Pilot)

Pattern for **Per-Chapter Beat Draft**: 5-pass extraction again from `docs/beats.md` at chapter level.

Forward motion comes from asking the right next question — never from prescribing structure the author hasn't yet articulated.

## Companion: Research Notes per chapter (post-draft enrichment)

Built AFTER the chapter draft. Minion's training data brings reference material into the draft; Research Notes makes those references canonical. See `docs/beats.md` "research-after-draft inversion" — including when the default flips (frontier research, contested citations, niche source material).

Post-draft enrichment:

1. Editor + author read the draft together
2. Identify references that need to be canonical (specific URLs, DOIs, author-year, journal, page numbers)
3. Catalog into the Research Notes doc, keyed to the relevant draft passage

Each chapter's Research Notes typically contains:

- **Source-material docs cited** — every Concepts doc the draft drew from. Call `link_to(source, target)` for each (per SKILL.md firm rule 5 — metadata-only since v0.20; the target's inbound list fills in live, no body mutation). Apply universally across the workspace, not just here.
- **Research URLs** — every paper, study, or external reference the draft cited. Inline markdown links `[Author Year, Journal](URL)`. Web-search for DOIs / canonical URLs during the enrichment pass. External refs do not use `link_to`.
- **Key supporting concepts index** — clean enumerated list of every Concepts doc this chapter draws from. Each entry's `link_to` connection is already declared (per above); this list is the human-readable surface.
- **Key research citations index** — clean enumerated list of every cited study with its full URL.
- **Draft-passage-keyed evidence** — for each draft passage needing canonical citation, the reference lives here keyed to passage location (e.g., "Section on glucose response under restriction: representative cohort study, journal citation, [URL]").

When inversion flips (Research Notes built BEFORE the draft), editor packs the relevant entries into the minion's brief as MUST-CITE constraints. Default is post-draft; exception is content-driven.

## Scoping a chapter against the arc / domain

Before building a Per-Chapter Beat Draft (argument-driven) or drafting a chapter (domain-driven), RE-READ the chapter's committed brief from the TOC. The chapter brief is the boundary — beats stay inside it.

Common drift: pulling content from the next chapter into the current chapter because both touch the same domain. Fix is precision about what each chapter specifically accomplishes.

If beats consistently feel "too much" or "too thin" inside a container, the container is wrong — re-run Chapter Architecture (`docs/chapter-architecture.md`), don't paper over at the beat layer.

## Architectural artifact recovery (when chapters or beats get cut)

If the author cuts a chapter or beat as errant, preserve the work as a module doc in a project subfolder (e.g., a `Modules/` container in the workspace). Don't delete — book architecture pivots are common; previously-cut material often gets reintroduced in a later structural pass. Same for Beat Maps that get reshaped: keep prior version as a versioned doc, not a destructive overwrite. (FIRM RULE from `docs/book-mode.md`.)

## Suggested project workspace structure

```
<project workspace>/
├── Spine/
│   ├── Argument Arc                       (Pipeline A primary; Pipeline B optional through-line)
│   ├── Global Beat Sheet                  (Pipeline A only)
│   ├── Table of Contents                  (both — committed TOC artifact)
│   └── (other project-level architectural docs)
├── Ch 1/ ... Ch N/                        (per docs/book-mode.md)
│   ├── Ch N — Beats                       (Pipeline A primary; Pipeline B uses 4-act pattern instead)
│   ├── Ch N — Ideas
│   ├── Materialized Beats/
│   └── Variants/
├── Vignettes/                             (Pipeline B — flat library)
├── Research Notes/
│   ├── Ch 1 — Research Notes
│   └── ...
└── Concepts/ (source-material workspace, possibly separate workspace)
    └── (canonical concept docs — Pipeline B's load-bearing input)
```

Concepts workspace can be separate if source material warrants its own organization. Per-chapter docs and Research Notes always live in the same workspace as Chapters so cross-references resolve cleanly. For Pipeline B (domain-driven), the Vignettes container holds the flat vignette library that chapters draw from during drafting.

# Shape Table (book-level project dashboard)

A flat, scannable table that renders the state of a book project at a glance. Columns capture the three layers the book runs on: chapters, beats, drafts. Each chapter gets one row. A totals row at the bottom rolls everything up to a single project % done.

This is the canonical project dashboard for any book project. Same structure across books — substrate-agnostic, intuitively readable, and tight enough to fit in a single screen.

## When to render

Render the shape table when the user asks:
- "Where are we"
- "Shape table" / "project shape" / "book status"
- "% done" / "how far along"
- "What have we done"
- "Status check" / "progress" / "dashboard"
- Any open-ended state-of-the-project question

Render proactively at the start of a session when picking up a book project that has been worked across multiple sessions — gives the user (and the agent) a shared map before any new work starts.

## Output structure

Three components, in order:

1. **The shape table** — one row per chapter + a totals row at the bottom
2. **The % derivation** — small table showing how the project-level % was computed
3. **Reading the table** — short narrative paragraph naming what stands out (complete pilots, in-flight chapters, untouched chapters, structural debt, fastest path forward)

## The shape table columns

| Column | What it captures |
|---|---|
| Chapter | "Ch N — Title" exactly as the chapter container is named in the workspace |
| Beats sheet | "locked (N beats)" where N is the count of beats in the chapter's Beats doc. Add version suffix if the doc has been rebuilt (e.g., "locked v3", "locked v4"). |
| Research Notes | "canonical (Nw)" if a Research Notes doc exists and is marked canonical. "MISSING" in caps if absent. |
| Beats drafted | "X / Y" where X is the count of beat-prose docs in the chapter's Drafts subcontainer and Y is the total beat count from the Beats doc. Add parenthetical for orphans (e.g., "(1 orphan B23)"). |
| Prose words | Sum of word counts of all docs in the chapter's Drafts subcontainer. "0" if empty. |
| Target | The chapter's word target range from the committed TOC (e.g., "5-6k", "10-12k"). |
| % done | Composite weighted, computed per the formula below. Bold this column for emphasis. |

## % done formula

Three-component composite per chapter:

| Component | Weight | What it measures |
|---|---|---|
| Beats sheet locked | 15% | Architectural commitment (1.0 if locked, 0 if not) |
| Research Notes canonical | 15% | Citation infrastructure ready (1.0 if canonical, 0 if missing) |
| Beats drafted | 70% | Prose progress (drafted / total beats, proportional) |

Per chapter:

```
% done = (beats_sheet × 0.15) + (research_notes × 0.15) + (drafts_ratio × 0.70)
```

Round to integer percent.

Project total uses the same formula applied at project level:
- Beats sheet share: chapters with locked beats / total chapters
- Research Notes share: chapters with canonical RN / total chapters
- Drafts share: total beats drafted across all chapters / total beats across all chapters

## Conventions

- **Bold** the % done column values for emphasis.
- ✓ checkmark next to 100% chapters.
- "MISSING" in caps for absent canonical artifacts.
- Use exact chapter titles as they appear in the workspace.
- Show totals row at the bottom with the project-level numbers, body cells in **bold**.
- Target word range mirrors the TOC commitment; do not invent it.
- If the project has versioned Beats docs (v1, v2, v3 supersession), show the current locked version (e.g., "locked v3").

## Data gathering

For each chapter, the agent needs:

1. **Beat count from Beats doc.** Read the chapter's Beats doc. Count beat headers (typical patterns: `**Bn —`, `### Bn`, `**Bn:**`, or `[h3] Bn —`). The Beats doc usually states the beat count in its preamble; verify by counting against the body since the preamble can be stale after revisions.

2. **Research Notes status.** Check the chapter container for a doc titled `Ch N — Research Notes`. Read its `status` metadata (canonical vs draft). Capture word count.

3. **Drafts inventory.** List the chapter's Drafts subcontainer. Count docs that match the `Ch N — Bk:` naming pattern. Sum word counts. Note any docs that look orphaned (e.g., a B23 sitting in a top-level Drafts container instead of inside the chapter container).

4. **Word target.** From the committed TOC doc. The TOC names each chapter and gives a target range. If the chapter doesn't yet appear in the TOC, mark target "TBD".

Use `get_workspace_structure` first to map the whole workspace. Then `read_pad` on each Beats doc for beat counts. Then aggregate.

## Example output (a sleep book mid-draft)

```
| Chapter | Beats sheet | Research Notes | Beats drafted | Prose words | Target | % done |
|---|---|---|---|---|---|---|
| Ch 1 — Why Sleep Exists | locked (15 beats) | canonical (865w) | 3 / 15 | 1,694 | 5-6k | **44%** |
| Ch 2 — Sleep Pressure | locked (26 beats) | canonical (393w) | 4 / 26 | 2,132 | 8-10k | **41%** |
| Ch 3 — Deep Time | locked (13 beats) | canonical (244w) | 0 / 13 | 0 | 8-10k | **30%** |
| Ch 4 — Dreaming | locked (17 beats) | MISSING | 0 / 17 | 0 | 7-8k | **15%** |
| Ch 5 — Two Clocks | locked (14 beats) | canonical (956w) | 14 / 14 | ~6,700 | 6-8k | **100%** ✓ |
| Ch 6 — The Modern Assault | locked (19 beats) | canonical (2,841w) | 19 / 19 | ~11,380 | 10-12k | **100%** ✓ |
| Ch 7 — Sleep Debt | locked v3 (22 beats) | MISSING | 9 / 22 | ~4,900 | 10-11k | **44%** |
| Ch 8 — Repayment | locked v4 (31 beats) | MISSING | 0 / 31 (1 orphan B23) | 0 | 10-11k | **15%** |
| Ch 9 — Frame | locked (20 beats) | MISSING | 0 / 20 | 0 | 7-8k | **15%** |
| Ch 10 — Tribal Regulation | locked (20 beats) | MISSING | 0 / 20 | 0 | 6-7k | **15%** |
| Ch 11 — Modern Animal | locked (15 beats) | MISSING | 0 / 15 | 0 | 5-7k | **15%** |
| **TOTAL** | **11/11 chapters** | **5/11 chapters** | **49 / 212 beats** | **~26,800** | **~85-98k** | **38%** |
```

Followed by the derivation table:

```
| Project layer | Status | Weight |
|---|---|---|
| Beats sheets locked | 11 / 11 chapters = 100% | × 15% = **15.0%** |
| Research Notes canonical | 5 / 11 chapters = 45% | × 15% = **6.8%** |
| Beat-level prose drafts landed | 49 / 212 beats = 23% | × 70% = **16.2%** |
| | | **38.0%** |
```

Followed by a short narrative naming what stands out: complete pilots, in-flight chapters, zero-draft chapters with structural debt, missing Research Notes, fastest path forward by % gain.

## Why this composite

The three-layer weighting reflects the actual cost distribution of book work:

- The beats sheet is the architecture commit. Cheap to produce, but everything downstream rests on it. 15% reflects that landing it is real progress and most of the work still remains.
- Research Notes is the citation infrastructure that lets the prose stand on real science. Also cheap. 15% same.
- Beat-level prose drafts are where the book actually exists as readable text. 70% reflects that the prose pour is the bulk of book work.

A chapter with locked beats and canonical RN but zero drafts sits at 30% — three of ten parts done. A chapter with the full pilot drafted and beats and RN locked sits at 100%. A chapter with locked beats, no RN, and partial drafts (e.g., 9 of 22 beats) sits in the 40s, capturing that the architecture exists but the prose is in flight.

## Anti-patterns

- Do not render this table when the user asks a narrower question ("how many beats are in Ch 5?", "is Ch 6 done?"). Answer the narrower question directly.
- Do not skip the totals row. The project-level number is the primary read.
- Do not invent target word ranges. If the committed TOC doesn't specify, mark "TBD".
- Do not count orphan drafts as in-chapter beats drafted. Note them as orphans in the row's cell and exclude from the X count.
- Do not render the table without verifying beat counts against each Beats doc body. The preamble line can be stale after revisions; the body is ground truth.
- Do not add columns the user did not ask for. The seven columns above are the canonical layout. If a project needs additional state (e.g., vignette inventory status), surface it in the narrative below the table, not as a new column.

## Companion: per-beat inventory (drill-down)

When the user wants to see exactly which beats have been drafted (not just counts), follow the shape table with a per-beat inventory: a flat list of every drafted beat across the book, one row per beat, columns `Chapter | Beat | Title | Words`. This is a drill-down view, not a replacement for the shape table. Render only when the user explicitly asks for beat-level detail.

# Workspace Management

Conventions for organizing book-scale projects in OpenWriter (or any doc workspace). Applies to all long-form non-fiction and fiction work. The default container hierarchy + naming convention + rename discipline below prevents the mess that emerges when chapter beats, drafts, and meta docs accumulate without architecture.

This doc is loaded as part of any book-scale orchestration. Pairs with `docs/chapter-architecture.md` (which produces the chapter-container shape) and `docs/book-mode.md` (which integrates the workspace into the writing flow).

## The container hierarchy (v2 lock 2026-05-20: chapter-first)

```
<Book Title> (workspace)
├── Book Spine                       — architectural / meta docs (project-level)
├── Working Notes                    — scratch, pilot tests, open questions (project-level)
├── Ch 1 — <Title>/                  — chapter container
│   ├── Ch 1 — Beats: <Title>        — beats doc (loose in chapter container)
│   ├── Ch 1 — Research Notes        — citations (loose in chapter container)
│   └── Drafts/                      — sub-container for per-beat prose docs
│       ├── Ch 1 — B1: <Name>        — one prose doc per beat
│       ├── Ch 1 — B2: <Name>
│       └── ...
├── Ch 2 — <Title>/
│   ├── Ch 2 — Beats: <Title>
│   ├── Ch 2 — Research Notes
│   └── Drafts/
└── Ch 3 — <Title>/ ...
```

### Why chapter-first (supersedes the lifecycle-grouped v1)

- **Chapter is the natural mental unit.** Day-to-day work is "I'm working on Ch X" — everything for that chapter lives in one place.
- **Drafts sub-container scales with per-beat dispatches.** Each chapter accumulates 15-25 prose docs (one per flat beat per `docs/beats.md`). A flat sidebar would become unscannable; the sub-container contains it.
- **Beats + Research Notes stay loose inside chapter container** because each is single-doc per chapter — sub-container would be over-engineered.
- **Book-level docs (Book Spine, Working Notes) stay top-level** because they're cross-chapter.

### Container responsibilities

| Container | What lives here | Lifecycle |
|---|---|---|
| **Book Spine** (top-level) | TOC, Argument Arc, Global Beat Sheet, Thesis, Voice & Form, Audience & Reader Journey, Decisions Log, Source Material, Open Questions, Concept Dump, Introduction draft. | Stable. Edits rare after lock. |
| **Working Notes** (top-level) | Pilot prose tests, scratch, ad-hoc analysis, brainstorm dumps, transient experiments. | Ephemeral. Promote or delete when done. |
| **Ch N — <Title>** (per chapter) | The chapter's beats doc + research notes doc, plus the Drafts sub-container. | Active for the chapter's lifecycle. |
| **Drafts** (sub-container of each chapter) | One `Ch N — Bk: <Name>` doc per flat beat (e.g., `Ch 2 — B6: Sleep cycles`). | Accumulates as beats get dispatched via /authors-voice. |

## Ascending-order convention (locked)

**All ordered lists in the sidebar go ascending top to bottom.** Ch 1 at top, Ch 2 below, Ch N at bottom. Same rule for beat-prose docs inside Drafts (B1, B2, B3...). Same rule for any future numbered grouping.

Project-level containers (Book Spine, Working Notes) sit above the chapter containers. Within each chapter container: Beats doc → Research Notes → Drafts sub-container (creation order is fine; chapter materials are few).

When inserting / reordering / renumbering, fix the sidebar order in the same pass — newest-first is wrong default.

## v1 deprecation note

The previous lifecycle-grouped scheme (`Chapter Beats` / `Chapter Drafts` / `Research Notes` as flat top-level containers, all chapters' docs mixed by type) is deprecated. It broke down at the per-beat-dispatch density that flat-beat methodology produces (15-25 prose docs per chapter × 11 chapters = 165-275 docs in one `Chapter Drafts` container — unscannable). Existing v1 workspaces migrate by: create chapter containers, create Drafts sub-containers, move docs, delete the old flat containers.

## Doc naming convention

Per-chapter docs follow this exact pattern:

| Doc type | Filename pattern | Example |
|---|---|---|
| Beats | `Ch N — Beats: <Chapter Title>` | `Ch 1 — Beats: Circadian Rhythms (The Body Clock)` |
| Per-beat prose | `Ch N — Bk: <Beat Name>` | `Ch 2 — B6: Sleep cycles` |
| Research notes | `Ch N — Research Notes` | `Ch 3 — Research Notes` |

**Per-beat prose docs are the dispatch unit** (see `docs/beats.md` flat-beat convention). Each beat from the chapter beats doc gets its own prose doc in `Ch N/Drafts/`. Naming maps 1:1: beat `B6` in the beats doc → prose doc `Ch N — B6: <Name>`. When beat numbering changes in the beats doc, the prose doc renames in the same pass.

Architectural docs (Book Spine container) use natural names without `Ch N` prefix: `Argument Arc`, `Thesis`, `Voice & Form`, `Candidate TOC`, `Decisions Log`, etc.

Working notes use descriptive natural names: `Pilot Prose Tests`, `Open Questions`, `Concept Dump`.

### Rules

1. **Chapter number comes first** in the filename so the sidebar sorts numerically.
2. **Chapter title appears in the beats and draft filenames** so the doc is findable without opening it. Research notes drop the title for compactness (the chapter number is enough).
3. **Title format follows the substantive-name rule from `docs/chapter-architecture.md`** — declarative or descriptive, telegraphs content, holdable in one sentence. "The Ascent" fails; "Sleep Across the Lifespan" works.

## Rename discipline (load-bearing rule)

When a chapter renumbers (insert, delete, reorder, merge, split), the cascade is:

1. **All three docs for that chapter rename together.** Beats doc, draft doc, and research notes doc. Renaming only the beats doc orphans the others.
2. **Container memberships audit.** If renumbering moves a doc out of its lifecycle (e.g., a chapter gets absorbed into another), move it to the right container before renaming.
3. **All chapter-numbered docs DOWNSTREAM also renumber** if an insertion is happening (e.g., new Ch 1 inserted means old Ch 1 → Ch 2, old Ch 2 → Ch 3, all the way down).
4. **Update the TOC** (in Book Spine) in the same pass.
5. **Update cross-references** in Argument Arc, Global Beat Sheet, Decisions Log if any chapter number is hardcoded.

**Anti-pattern observed in the wild:** creating a new beats doc for a new chapter in one container while the old (now-renumbered) beats doc sits in a different container with its now-wrong name. Produces an unscannable sidebar with no clear hierarchy. The architecture lost its shape.

The fix when this happens: rename + move every affected doc in one structural-cleanup pass. Don't leave intermediate orphan state across a session boundary.

## Creation discipline

When creating a new chapter beats doc:
1. `create_document` with the proper `Ch N — Beats: <Title>` filename
2. Place in `Chapter Beats` container at creation (via `container` parameter on `create_document`)
3. Add the corresponding empty draft doc in `Chapter Drafts` and empty research-notes doc in `Research Notes` at the same time, OR defer their creation until the beat work locks (your call — but if deferred, track it as a TODO)

When creating ad-hoc working docs (pilot tests, scratch analysis):
1. Place in `Working Notes` container at creation
2. Use a descriptive natural name (no `Ch N` prefix unless the doc is genuinely chapter-scoped scratch)
3. Either promote to the right container when the doc earns its keep, or delete when its purpose is served

## The "where is this doc" test

The author should be able to answer "where is X doc" in one second by knowing the doc type:
- Beats doc → Chapter Beats container, sorted by `Ch N`
- Draft → Chapter Drafts container, sorted by `Ch N`
- Research → Research Notes container, sorted by `Ch N`
- Architectural → Book Spine, alphabetical or by stable conventional order (Thesis → Audience → Voice → TOC → Arc → Beat Sheet → Decisions → Source → Open Q → Concept Dump)
- Scratch / pilot → Working Notes

If the author has to ask "where did the agent put this," the convention has been violated.

## When the convention shouldn't apply

- Single-chapter projects or essays: one workspace, no chapter containers, just docs at root.
- Multi-book projects: separate workspace per book; this convention applies inside each workspace.
- Fiction with heavy character/setting/world-building load: add a `World Bible` container alongside `Book Spine` for character sheets, setting docs, glossary, timeline.
- Anthology-style books (independent essays under one cover): each essay is one doc in a single `Essays` container; no per-essay sub-docs needed.

## Loaded by

- `docs/long-form-orchestration.md` (book-scale orchestration entry point)
- `docs/book-mode.md` (per-session book-writing workflow)
- `docs/chapter-architecture.md` (chapter-container commit produces the structure this doc organizes)

When any of those load, this doc loads with them.