hayao 0.4.0 → 0.4.2

package/design/00-process/README.md

@@ -0,0 +1,49 @@
+# 00-process/ — The Design Pipeline
+
+The **process** modules are the spine of the Codex: the ordered steps that turn a
+one-line request into a design that's *designed enough to build*. Where the other
+sections are a **parts bin** (anchors, genres, systems, worlds, patterns), these
+six are the **method** for using it. Run them in order — each stage names the
+sections it draws on and hands its output to the next.
+
+```
+INTENT ──▶ ANCHOR ──▶ COMPOSE ──▶ TWIST ──▶ SHAPE ──▶ HANDOFF ──▶ (FUN/JUICE/JUDGE)
+```
+
+**Intent-to-brief** parses the ask. **Pillars** distill it into a three-way
+decision filter. **The twist** picks the creative bend and **composition** sources
+and blends the parts, scored against the pillars. **Core-loop** shapes the play
+into a nested stack. **Refine-and-handoff** converts the whole thing into a
+verification contract and passes it to the proof playbook — the seam where the
+Codex ends and [docs/FUN.md](../../docs/FUN.md), [docs/JUICE.md](../../docs/JUICE.md),
+and [docs/JUDGE.md](../../docs/JUDGE.md) begin. The Codex never duplicates the
+proof docs; it *routes* to them.
+
+## The six modules
+
+| id | title | summary |
+|---|---|---|
+| [process-intent-to-brief](intent-to-brief.md) | Intent → Brief | Parse a vague request into a one-page brief: player fantasy, one-line hook, scope, hard constraints, target session length. |
+| [process-pillars](pillars.md) | The Three Pillars | Derive exactly three pillars — evocative + testable — and use them as the scoring function for every later choice. |
+| [process-core-loop](core-loop.md) | The Core Loop Stack | Design the nested moment/encounter/session/meta loops and the verb→challenge→feedback→reward→growth cycle inside each. |
+| [process-the-twist](the-twist.md) | The Twist — "X but Y" | Anchor to a proven core, then bend it along one of six twist vectors so it's yours, not a clone. *(the quality exemplar)* |
+| [process-composition](composition.md) | Composition | Assemble the design from anchor + genre template + implied systems; blend genres by satisfying every parent's verify pattern. |
+| [process-refine-and-handoff](refine-and-handoff.md) | Refine & Handoff | Turn the finished design into a verification contract and hand off to FUN / JUICE / JUDGE / CONVENTIONS. |
+
+## Order notes
+
+The arrows are the default path, not a straitjacket. In practice:
+
+- **Pillars gate the twist and composition** — both are *scored against* the three
+  pillars, so pillars come before either even though the pipeline draws twist next.
+- **The twist happens *inside* composition** — it's the creative bend you apply
+  while assembling parts, not a separate assembly.
+- **The loop stack is the SHAPE step** — design it once the systems are chosen; the
+  systems are what fill the loop's layers.
+- **Handoff is always last** — you can only write the verification contract once
+  the pillars, loop, and system list exist to be proven.
+
+See [`design/README.md`](../README.md) for the full pipeline and how these feed the
+[`10-anchors/`](../10-anchors/), [`20-genres/`](../20-genres/),
+[`30-systems/`](../30-systems/), [`40-worldbuilding/`](../40-worldbuilding/), and
+[`50-patterns/`](../50-patterns/) sections.

package/design/00-process/composition.md

@@ -0,0 +1,148 @@
+---
+id: process-composition
+title: Composition — Assembling the Design
+kind: process
+tags: [composition, genre-blend, systems, assembly, coherence, parent-genres, checklist]
+summary: Assemble a design from anchor + genre template + the systems it implies; blend genres by satisfying every parent's verify pattern.
+use-when: You have a brief and pillars and need to assemble the actual design — which genre template, which systems, and how a genre blend holds together.
+composes-with: [process-intent-to-brief, process-pillars, process-the-twist, process-refine-and-handoff]
+verify-with: docs/FUN.md#part-2--per-genre-cheat-sheet
+---
+
+# Composition — Assembling the Design
+
+**What it is.** The assembly step. Take the **anchor** (the X), lay down its
+**genre template**, and bolt on the **systems** that genre implies — progression,
+economy, combat, factions. Composition is *sourcing the parts*; [[process-the-twist]]
+is the bend you apply while you assemble.
+
+**Why it's fun.** You don't re-derive what a roguelite knows about meta-progression;
+you *compose* it, pre-solved, and spend your invention on the twist. The craft here
+is picking the right parts and making a blend **cohere** rather than collide.
+
+## The step
+
+Anchor + pillars → a composed design: one genre template, N systems, a coherent
+whole. Every included part must pass the [[process-pillars]] filter and serve the
+loop stack ([[process-core-loop]]).
+
+## Inputs → outputs
+
+| In | Out |
+|---|---|
+| Anchor(s) + brief + 3 pillars | A named genre template (a [genre](../20-genres/)) as the spine |
+| The twist vector ([[process-the-twist]]) | A **system list** — each `[[system-*]]` justified by a pillar |
+| Session length + scope | A blend map: parent genres and their verify patterns |
+
+## The assembly
+
+1. **Anchor → genre spine.** The anchor names the genre. Pull the deep template
+   from [`20-genres/`](../20-genres/) — its pillars, loop stack, and *essential
+   systems*. This is your skeleton; you're not starting from zero.
+2. **Genre → implied systems.** Every genre *implies* systems. A roguelite implies
+   meta-progression and procgen; an RTS implies rosters, economy, and asymmetry.
+   Use the checklist below.
+3. **Twist → added/swapped system.** The twist usually *is* a system swap or add
+   (Loop Hero adds placement + a deck to auto-combat). Slot it in.
+4. **Filter every system.** Score each against the pillars. Include only what
+   serves one. When in doubt, cut — an unverified system is presumed broken.
+
+## Which systems does this genre imply?
+
+A starting checklist. Presence isn't mandatory — but *decide* on each, don't
+forget it.
+
+| If the design has… | It almost certainly implies… |
+|---|---|
+| Runs / permadeath | [[system-meta-progression]] · [[system-procgen-design]] · [[system-session-structure]] |
+| A power curve | [[system-progression]] · [[system-mastery-curve]] · [[pattern-pacing-and-tension]] |
+| Currency / shops | [[system-economy]] · [[system-resource-loops]] · [[system-reward-schedules]] |
+| Combat | [[system-combat-model]] · [[system-telegraphs]] · [[system-enemy-archetypes]] · [[system-encounter-design]] |
+| Multiple factions/classes | [[system-faction-asymmetry]] · [[system-unit-rosters]] · [[system-counter-systems]] |
+| Builds / loadouts | [[system-build-diversity]] · [[system-skill-trees]] · [[system-status-effects]] |
+| Precision movement | [[system-grace]] · [[pattern-anti-frustration]] |
+| Bosses / set-pieces | [[system-boss-design]] |
+| A new player | [[system-onboarding]] · [[system-accessibility]] · [[system-difficulty-and-dda]] |
+| Emergent story | [[system-emergent-systems]] |
+| Coop / PvP | [[system-coop-and-competition]] |
+| Any game at all | [[system-save-and-checkpoint]] · [[pattern-readability]] · [[pattern-juice-choreography]] |
+
+Two systems on that last row are *always on*: readability (JUDGE hook) and juice
+choreography (JUICE hook). Skip nothing there.
+
+## Genre-blend rules
+
+Most interesting games are **blends** — two or more genres under one loop
+(Loop Hero = auto-battler + deckbuilder + placement; rhythm = roguelike + input
+legality). The rule that keeps a blend from collapsing:
+
+> **Satisfy every parent genre's verify pattern.** FUN.md's closing note is law:
+> *"If the genre is a blend, satisfy every parent genre's verify pattern — genres
+> compose (rhythm = roguelike + input legality; Peggle = physics + aim search)."*
+> A blend is not an average of two verify suites; it is the **union** of them.
+
+Practically:
+
+1. **List the parents.** Name each genre in the blend and its FUN.md section.
+2. **Union the verify patterns.** A physics-arcade + deckbuilder owes *both* the
+   swept-collision/energy invariant (FUN.md §19) *and* the draft-delta + win-rate
+   window (FUN.md §11). Neither is optional.
+3. **Find the seam.** Where two systems meet is where blends break — the moment a
+   card *modifies* a physics shot, both models must stay honest. Name that seam and
+   plan a proof for it specifically.
+4. **Pick the dominant parent.** One genre owns the moment verb; the others modify.
+   The dominant one's loop stack is the spine; the others graft on.
+
+## Worked example
+
+**Intent:** *"a tower defense where the towers are a deck you draft each wave."*
+Pillars: (1) *build decisions that matter*, (2) *drafts with teeth*, (3) *the range
+ring is the UI*. X = tower defense × deckbuilder blend.
+
+**Composition:**
+
+- **Spine:** [[genre-tower-defense]] owns the moment verb (place a tower). FUN.md
+  §8 is the primary verify pattern.
+- **Grafted parent:** [[genre-deckbuilder]] supplies the *draft-of-3 per wave*.
+  FUN.md §11's draft-delta + win-rate window applies to the tower draft.
+- **Implied systems:** [[system-economy]] (gold faucet from kills), [[system-counter-systems]]
+  (near-hard tower↔enemy counters — §8 demands it), [[system-encounter-design]]
+  (wave composition), [[system-reward-schedules]] (the draft is the reward).
+- **The seam:** a drafted tower must respect coverage geometry (§8's range × lane
+  chord) *and* the draft must have teeth (§11's delta). The seam-proof: a mixed
+  drafted build survives 10/10 while a mono-draft (bigger budget) fails **and**
+  never-drafting loses by a margin. Both parents, one scenario.
+- **Cut:** a proposed crafting system — serves no pillar, adds a third verify
+  suite for no fantasy gain. Out.
+
+## Traps
+
+- **Averaging verify suites.** A blend owes the *union*, not the intersection. Two
+  parents = both proofs, in full.
+- **Two dominant parents.** If two genres fight for the moment verb, the game has
+  no center. Pick one spine; the rest modify it.
+- **Ignoring the seam.** Blends break where systems touch. The seam needs its own
+  named proof, not a hope that both halves compose cleanly.
+- **System sprawl.** Every system you add is a verify suite you owe. Compose the
+  fewest systems that serve the pillars; each extra one is scope you must prove.
+- **Composing from the corpus.** Don't survey `examples/` for which systems to
+  bolt on (see [CLAUDE.md](../../CLAUDE.md)). Decide from the mechanic and the
+  pillars; borrow *structure*, not a menu.
+
+## Composes with
+
+- [[process-the-twist]] — the twist is chosen *during* composition; it's the
+  creative bend on the parts you're assembling.
+- [[process-pillars]] — the filter that decides which systems are in.
+- [[process-core-loop]] — the systems fill the loop stack's layers.
+- [[process-refine-and-handoff]] — the composed system list becomes the list of
+  verify suites you owe.
+
+## See also
+
+- [docs/FUN.md](../../docs/FUN.md) Part 2 + closing note — the per-genre verify
+  patterns and the blend law you must satisfy for every parent.
+- [`20-genres/`](../20-genres/) · [`30-systems/`](../30-systems/) — the parts bin
+  you assemble from.
+- [`examples/`](../../examples/) — *convention* references for how a composed
+  design wires state/view, **not** an idea menu (per AGENTS.md).

package/design/00-process/core-loop.md

@@ -0,0 +1,146 @@
+---
+id: process-core-loop
+title: The Core Loop Stack
+kind: process
+tags: [core-loop, gameplay-loop, verb, feedback, reward, progression, pacing, engagement]
+summary: Design the nested loop stack — moment / encounter / session / meta — and the verb→challenge→feedback→reward→growth cycle inside each layer.
+use-when: You have pillars and need to design the actual moment-to-moment play and how it nests up into a session and a reason to return.
+composes-with: [process-pillars, process-composition, process-refine-and-handoff]
+verify-with: docs/FUN.md#part-2--per-genre-cheat-sheet
+---
+
+# The Core Loop Stack
+
+**What it is.** A game is **loops inside loops**. The smallest is one input and its
+answer; the largest is the reason you open it again tomorrow. Design each layer,
+then **nest** them so every turn of a small loop advances a bigger one.
+
+**Why it's fun.** Fun is a satisfying loop, repeated, that keeps meaning more. A
+loop that doesn't feed the loop above it is a treadmill; a stack where each turn
+compounds is *"one more run."* The nesting is the engagement.
+
+## The step
+
+Pillars → the loop stack. You design four layers and the single cycle that runs
+inside each of them, then check every layer expresses a pillar.
+
+## The four layers
+
+| Layer | Timescale | The question it answers | Reference |
+|---|---|---|---|
+| **Moment** | 1 frame – 2 s | "Does the second-to-second feel good?" | the dash, the shot, the swap, the placement |
+| **Encounter** | 10 s – 2 min | "Is a single unit of challenge satisfying?" | a room, a wave, a hand, a corner, a fight |
+| **Session** | 5 – 40 min | "Is one sitting a complete arc?" | a run, a level set, a match, a day |
+| **Meta** | across sessions | "Why open it again?" | unlocks, mastery, collection, story |
+
+Not every game needs all four fully loaded. A pure-mastery arcade game
+([[anchor-tetris]]) is almost all *moment*, thin meta. A roguelite
+([[anchor-hades]]) leans hard on *meta*. Match the weight to the brief's
+**session length** and fantasy — but design each layer *consciously*, even the
+thin ones.
+
+## The cycle inside every layer
+
+Each layer runs the same five-beat cycle. The layers differ in timescale, not in
+shape.
+
+```
+VERB ──▶ CHALLENGE ──▶ FEEDBACK ──▶ REWARD ──▶ GROWTH ──┐
+  ▲                                                      │
+  └──────────────────────────────────────────────────────┘
+```
+
+- **Verb** — the thing the player *does*. One primary verb per layer; the moment
+  layer's verb is the game's soul (jump, place, draft, fire).
+- **Challenge** — what resists the verb. A gap, a guard, a wave, a bad hand.
+- **Feedback** — the game answers *legibly and on ≥ 2 senses*. This is a
+  JUICE.md concern — design the *event*, prove the feel there (see
+  [docs/JUICE.md](../../docs/JUICE.md) Part 3).
+- **Reward** — what the success buys: territory, a pickup, a clear, a card.
+- **Growth** — how the reward changes future turns: more power, more options, a
+  new verb. Growth is the hook into the *next layer up*.
+
+## How to run it
+
+1. **Name the moment verb first.** The one input the whole game orbits. If it
+   isn't fun alone, in a grey box, nothing above it saves the game. Prototype it
+   as a `sandboxes/*-lab` before anything else.
+2. **Build the encounter around the verb.** One clean unit of challenge that
+   demands the verb. This is your smallest shippable, verifiable thing.
+3. **Shape the session** as a *sequence* of encounters with a curve — rise,
+   breather, peak (pacing is [[pattern-pacing-and-tension]]). A session must
+   *end*, and end at its peak.
+4. **Design the meta hook.** What does finishing a session *change*? Unlock,
+   record, story beat, collection tick. Weight it to session length: short
+   sessions need strong meta; long ones can carry themselves.
+5. **Nest — the load-bearing step.** Wire each layer's **growth** to the layer
+   above: encounter reward feeds the session build; session reward feeds meta
+   progression. If a layer's growth feeds nothing above, it's a dead end.
+6. **Score against pillars.** Each layer should *dramatise* a pillar. A loop that
+   expresses no pillar is a mechanic with no reason to exist.
+
+## Worked example
+
+**Intent:** *"a chill deckbuilder I can play in short bursts."* Pillars: (1) *every
+run rewrites the deck*, (2) *decisions with teeth*, (3) *a clean 20-minute arc*.
+X = [[anchor-slay-the-spire]].
+
+| Layer | Verb | Challenge | Feedback | Reward | Growth (→ up) |
+|---|---|---|---|---|---|
+| Moment | play a card | mana + timing | number pops, sfx, flash | damage / block | tempo this turn |
+| Encounter | win a fight | enemy intent | telegraph resolves as shown | HP kept, gold | **card reward → session build** |
+| Session | finish a run | boss + curve | run summary | victory / death | **unlock → meta** |
+| Meta | unlock cards | rarer picks | new draft-of-3 options | expanded pool | **future runs diverge (pillar 1)** |
+
+The nesting is explicit: the card reward (encounter) *is* the session's deck; the
+run's unlock *is* the meta's new option. Every arrow points up. Pillar 1 lives in
+the meta→moment feedback: yesterday's unlock changes today's draft.
+
+**Verify the loop, don't just draw it.** The deckbuilder's *"decisions with teeth"*
+pillar becomes a FUN.md §11 draft-delta proof (drafting on beats drafting off by a
+margin) — declared here, proven there.
+
+## Diagnosing a weak loop
+
+| Symptom | Likely broken layer | Fix |
+|---|---|---|
+| "Feels like a treadmill" | growth feeds nothing above | wire the nesting; make a reward change the next layer |
+| "Great for 5 min then boring" | encounter has no variety | vary the challenge, not the verb ([[system-enemy-archetypes]]) |
+| "No reason to come back" | thin/absent meta | add a meta hook sized to the session |
+| "Every run feels the same" | growth doesn't diverge | make rewards branch ([[system-build-diversity]]) |
+| "The core just isn't fun" | the **moment verb** | stop; the verb is wrong — re-prototype it in isolation |
+| "Rewards feel hollow" | feedback, not reward | it's a feel gap → [docs/JUICE.md](../../docs/JUICE.md), not more loot |
+
+The single most common failure is a **weak moment verb** propped up by heavy meta
+— unlocks papering over a core that isn't fun. No amount of meta fixes a bad
+moment. Fix the bottom of the stack first.
+
+## Traps
+
+- **Skipping the moment prototype.** Designing session/meta before the verb is fun
+  is building a tower on sand. Grey-box the verb first.
+- **Loops that don't nest.** Four independent loops are four treadmills. The stack
+  is only alive if growth climbs it.
+- **Meta as a bribe.** Progression that exists to mask a dull core is a
+  psychological trick, not a design ([[system-reward-schedules]] has the ethics).
+- **A session with no end.** "Endless" still needs a peak and a resolution per
+  sitting, or it's just noise until you quit.
+- **Confusing feedback with reward.** Juicy feedback on a worthless reward still
+  feels empty; a great reward with no feedback feels flat. You need both.
+
+## Composes with
+
+- [[process-pillars]] — every layer must dramatise a pillar; the loop is where
+  pillars become play.
+- [[process-composition]] — the systems you compose are *what fills the layers*
+  (progression → meta, economy → session, combat → encounter).
+- [[pattern-mastery-and-flow]] / [[pattern-pacing-and-tension]] — the moment and
+  session layers live or die on flow and pacing.
+- [[system-progression]] / [[system-meta-progression]] — the meta layer's engine.
+
+## See also
+
+- [docs/FUN.md](../../docs/FUN.md) Part 2 — each genre's *mechanical truth* is the
+  proof that its core loop actually holds; find your genre and its verify pattern.
+- [`sandboxes/`](../../sandboxes/) — the place to prototype a moment verb in
+  isolation before you build the stack on top of it.

package/design/00-process/intent-to-brief.md

@@ -0,0 +1,128 @@
+---
+id: process-intent-to-brief
+title: Intent → Brief
+kind: process
+tags: [intent, brief, scope, fantasy, hook, constraints, requirements, parse]
+summary: Parse a vague request into a one-page brief — player fantasy, one-line hook, scope, hard constraints, target session length.
+use-when: You have a high-level ask ("make a polished platformer") and need a concrete brief before you anchor, compose, or twist.
+composes-with: [process-pillars, process-the-twist, process-composition]
+verify-with: none
+---
+
+# Intent → Brief
+
+**What it is.** The first step of the pipeline. Turn a one-line request into a
+**brief**: five fields an agent can build against. The intent is the seed; the
+brief is the contract you'll pressure-test everything else against.
+
+**Why it's fun.** A brief protects fun. Left implicit, a request like *"a polished
+platformer with responsive controls"* silently expands into scope you can't
+verify. Pin the **fantasy** and you know what feeling to protect; pin the
+**constraints** and you know what to refuse.
+
+## The step
+
+Parse intent → brief. You are not designing yet — you are *reading the request
+correctly* so the design lands on what was actually asked.
+
+## Inputs → outputs
+
+| In | Out |
+|---|---|
+| A high-level request, one sentence to a paragraph | A five-field brief (below) |
+| Named genres, feels, adjectives ("responsive", "impressive", "chill") | Each adjective resolved to a **fantasy** or a **constraint** |
+| Implicit scope ("an RTS", "a roguelite") | An explicit scope + target session length |
+
+The five brief fields:
+
+1. **Player fantasy** — what the player *feels they are*. Not "a platformer" but
+   *"a body you trust completely, threading gaps by a hair."* One sentence.
+2. **One-line hook** — the store sentence, provisionally in [[process-the-twist]]'s
+   "X but Y" shape. It may still be pure X here; the twist sharpens it later.
+3. **Scope** — how big: one screen vs. a campaign, one system vs. six. The honest
+   size, phrased as content units (levels, rooms, waves, cards).
+4. **Hard constraints** — the non-negotiables. Some come from the ask ("couch
+   coop", "one button"); some are *always on* for Hayao (deterministic sim, pure
+   logic, DOM chrome — see [CLAUDE.md](../../CLAUDE.md)).
+5. **Target session length** — 90-second run? 20-minute sitting? A weekend? This
+   sets the loop stack ([[process-core-loop]]) and the meta.
+
+## How to run it
+
+1. **Read the request twice.** First for genre, then for *adjectives*. Every
+   adjective is a smuggled requirement — "responsive" = grace system, "impressive
+   battles" = mass + spectacle, "chill" = a tonal constraint against fail-states.
+2. **Extract the fantasy.** Ask "what does the player get to *feel they are*?"
+   Write it as a person doing a thing, not a genre label.
+3. **Draft the hook.** One sentence. If a touchstone game is obvious, name it —
+   that's your provisional **X** for [[process-the-twist]].
+4. **Size the scope honestly.** Convert "an RTS" into countable content and the
+   systems it implies (this is where [[process-composition]]'s checklist starts).
+   Under-scope on purpose; a small proven thing beats a large unverifiable one.
+5. **List hard constraints.** Split into *asked* (from the request) and *inherited*
+   (Hayao invariants). Constraints are gifts — each one collapses the design space.
+6. **Set session length.** Pick the sitting the fantasy wants, then let it drive
+   the loop layers you'll design in [[process-core-loop]].
+7. **Write it as one page.** If it doesn't fit a page, the intent isn't parsed yet.
+
+## Worked example A
+
+**Intent:** *"make a polished platformer with really responsive controls."*
+
+| Field | Parsed |
+|---|---|
+| Fantasy | *"A body you trust completely — every death is your fault, never the game's."* |
+| Hook | *"A precision platformer where the controls are the whole promise."* (X = [[anchor-celeste]]; twist TBD.) |
+| Scope | ~12 handcrafted levels, one movement kit, one hazard family. No combat. |
+| Hard constraints | *Asked:* "responsive" = a full grace system ([[system-grace]]). *Inherited:* deterministic sim, movement envelope derived not vibed, DOM menus. |
+| Session length | 2–5 min per level; 30–45 min for the set. Instant retry. |
+
+"Responsive" was the load-bearing word: it resolved straight to [[system-grace]]
+and to FUN.md's coyote/buffer/apex canon — proven, not designed here (see FUN.md
+§2). The brief now *knows what to protect*.
+
+## Worked example B
+
+**Intent:** *"design an RTS with faction asymmetry and impressive battles."*
+
+| Field | Parsed |
+|---|---|
+| Fantasy | *"A commander whose faction plays like nobody else's, watching a hundred units answer one order."* |
+| Hook | *"An RTS where three factions share no units and still balance."* (X = [[anchor-starcraft]].) |
+| Scope | 3 factions × ~6 units, ~5 skirmish maps, 1 economy, 1 tech ramp. No campaign v1. |
+| Hard constraints | *Asked:* asymmetry that *balances* ([[system-faction-asymmetry]]); "impressive" = mass pathing + spectacle. *Inherited:* flow-field pathing, deterministic sim, exported arrival tolerances. |
+| Session length | 10–20 min per skirmish; sit-down, not snackable. |
+
+Two adjectives, two systems: *asymmetry* → [[system-faction-asymmetry]] +
+[[system-unit-rosters]]; *impressive* → mass under command (FUN.md §9) +
+[[system-boss-design]]-grade spectacle. "Impressive" is a **feel** claim — it will
+hand off to JUICE.md's gates, not get argued here.
+
+## Traps
+
+- **Adjective blindness.** "Polished", "responsive", "impressive", "chill" are
+  requirements in disguise. Leave one unparsed and it becomes untestable scope.
+- **Genre as fantasy.** "A roguelite" is not a fantasy; *"every death teaches you
+  the dungeon"* is. Push past the label to the feeling.
+- **Scope inflation.** The request rarely asks for the biggest version. Build the
+  smallest thing that delivers the fantasy; grow only what verifies.
+- **Skipping inherited constraints.** Determinism, pure logic, and the cosmetic
+  rule are constraints on *every* brief even when unasked — bake them in now, not
+  in a painful refactor later.
+- **Hook without an anchor.** If no touchstone comes to mind, the intent may be
+  under-specified — name the closest X anyway; [[process-the-twist]] needs one.
+
+## Composes with
+
+- [[process-pillars]] — the brief's fantasy + hook are the raw material the three
+  pillars distill from.
+- [[process-the-twist]] — the provisional hook here becomes the **X** to bend.
+- [[process-composition]] — scope + constraints feed the systems-checklist.
+
+## See also
+
+- [`design/README.md`](../README.md) — where this sits in the pipeline (step 1).
+- [CLAUDE.md](../../CLAUDE.md) / [AGENTS.md](../../AGENTS.md) — the inherited
+  invariants every brief must list as hard constraints.
+- [docs/FUN.md](../../docs/FUN.md) — the mechanical truths the parsed adjectives
+  will eventually be proven against. Design here; prove there.

package/design/00-process/pillars.md

@@ -0,0 +1,139 @@
+---
+id: process-pillars
+title: The Three Pillars
+kind: process
+tags: [pillars, vision, decision-filter, scope-guard, priorities, focus, scoring]
+summary: Derive exactly three design pillars — evocative but testable — and use them as the scoring function for every later choice, including the twist.
+use-when: You have a brief and need a decision filter that resolves every downstream "should we?" including the twist and the cut list.
+composes-with: [process-intent-to-brief, process-the-twist, process-core-loop, process-composition]
+verify-with: none
+---
+
+# The Three Pillars
+
+**What it is.** Three short statements of what this game **is about** — the
+feelings and truths every later decision must serve. Not features, not a to-do
+list. The pillars are the **scoring function** you run every candidate mechanic,
+twist, and level through.
+
+**Why it's fun.** Focus is fun's precondition. A game that's about three things is
+about *something*; a game about ten is about nothing. When two ideas conflict, the
+pillars decide — that's the whole point of writing them down.
+
+## The step
+
+Brief → exactly three pillars. Then everything downstream is scored, not
+debated: [[process-the-twist]]'s candidate bends, [[process-composition]]'s system
+list, and the cut list all resolve against these three.
+
+## Why exactly three
+
+Two under-constrains — you can't triangulate a decision. Four+ dilutes: a fourth
+pillar is almost always a *feature* masquerading as a value, or a restatement of
+one you already have. Three forces prioritisation and still fits in your head at
+every choice. If you have five candidates, two are subordinate — demote them.
+
+## Inputs → outputs
+
+| In | Out |
+|---|---|
+| The brief's **fantasy** + **hook** ([[process-intent-to-brief]]) | Exactly 3 pillars |
+| The named anchor(s) | Each pillar phrased **evocative + testable** |
+| Nothing else — resist adding features | A one-line **test** per pillar |
+
+## How to phrase a pillar
+
+Each pillar is **two halves**: an evocative name you can say out loud, and a
+testable clause that a design decision can pass or fail.
+
+| Bad (vague / feature) | Good (evocative + testable) |
+|---|---|
+| "Fun combat" | **Readable violence** — *a player can name the threat that killed them.* |
+| "Deep progression" | **Every run rewrites the deck** — *no two victories share a build.* |
+| "Nice graphics" | **The screen reads at a glance** — *the avatar is the brightest thing on it.* |
+| "Hard but fair" | **Your fault, never the game's** — *every death traces to an input, not a frame.* |
+
+The testable clause is what makes a pillar a *filter*. "Readable violence" alone
+is a mood; the clause *"can name the threat that killed them"* you can hold a
+telegraph design up against and get a yes/no.
+
+## How to run it
+
+1. **Mine the brief.** The fantasy usually contains one pillar almost verbatim.
+   The hook's **X** (anchor) contributes one — its load-bearing structure. The
+   twist-to-be contributes the third (its differentiator).
+2. **Draft five, cut to three.** Write candidates freely, then merge and demote
+   until exactly three remain. If two overlap, they're one pillar.
+3. **Add the test clause.** For each, write the one-line predicate a decision must
+   pass. If you can't write a test, it's a mood — sharpen or cut it.
+4. **Rank them.** Order matters: when pillars conflict (they will), the higher one
+   wins. Pillar 1 is the hill you die on.
+5. **Sanity-check coverage.** Between them, the three should touch *feel*,
+   *depth/structure*, and *the twist*. A gap there means a missing pillar or a
+   wrong cut.
+
+## Using pillars as the decision filter
+
+This is the payoff. Every downstream question becomes a **score**, not an argument:
+
+- **The twist.** In [[process-the-twist]] step 3 you score six candidate bends
+  against the pillars and keep the one that *most sharpens* a pillar. A twist that
+  fights pillar 1 is a different game — drop it.
+- **System inclusion.** In [[process-composition]], a system earns its place only
+  if it serves a pillar. "Does crafting serve any pillar? No → cut it."
+- **The cut list.** When scope must shrink, cut the content that serves the
+  *lowest-ranked* pillar first.
+- **Content & difficulty.** A level or encounter that expresses no pillar is
+  filler. Every encounter should be a pillar, dramatised.
+
+> **The filter test.** If a proposed feature passes zero pillars, it's out — no
+> discussion. If it passes one, it's optional. If it passes two, it's core. This
+> is the entire value of writing them down.
+
+## Worked example
+
+**Brief (from [[process-intent-to-brief]] example B):** an RTS with faction
+asymmetry and impressive battles; X = [[anchor-starcraft]].
+
+**Five candidates → three pillars:**
+
+1. **Three armies, one balance** — *every faction shares zero units and still wins
+   its share of mirrorless matchups.* (from the hook; the twist lives here)
+2. **A hundred hands, one will** — *mass answers a single order and paths around
+   walls without micro.* (from the fantasy + FUN.md §9's mechanical truth)
+3. **The order you gave is the battle you get** — *unit behaviour is legible and
+   deterministic; no surprise from the sim.* (an inherited-constraint pillar)
+
+*Cut:* "deep tech tree" (demoted — it serves pillar 1, not its own thing) and
+"cinematic camera" (a JUICE.md feel goal, not a pillar).
+
+**Filter in action:** a proposed hero-unit mechanic — does it serve a pillar? It
+sharpens pillar 1 (faction identity) *only if* each faction's hero is distinct;
+generic heroes serve nothing and are cut. Pillar-scoring made the call in one line.
+
+## Traps
+
+- **Pillars that are features.** "Has a skill tree" is a feature; *"builds diverge
+  by hour two"* is a pillar. Features are downstream of pillars.
+- **Untestable moods.** "Epic", "immersive", "juicy" with no clause can't filter
+  anything. Every pillar needs a predicate.
+- **Four pillars.** The fourth is usually a demoted feature or a dupe. Force three.
+- **Unranked pillars.** If they never conflict, they're too vague; if they conflict
+  and you haven't ranked them, the next hard call stalls.
+- **Pillars nobody enforces.** Written and forgotten is worse than none. Re-score
+  against them at every stage — they are only worth the decisions they make.
+
+## Composes with
+
+- [[process-intent-to-brief]] — the brief is the ore; pillars are the refined metal.
+- [[process-the-twist]] — pillars are literally the scoring function for the bend.
+- [[process-core-loop]] — the loop must express the pillars beat by beat.
+- [[process-composition]] — every included system must pass the pillar filter.
+
+## See also
+
+- [`design/00-process/the-twist.md`](the-twist.md) — where pillars do their most
+  important work: choosing the twist.
+- [docs/FUN.md](../../docs/FUN.md) Part 1 — the mechanical truths a testable pillar
+  clause often points straight at (a pillar clause is frequently a FUN.md law,
+  named for *your* game).