@skyf0xx/hedgehog 2.0.13 → 3.0.0

package/src/skills/hedgehog-loop/SKILL.md

@@ -1,27 +1,34 @@
 ---
 name: hedgehog-loop
-description: Use for every unit of work once a Hedgehog project is bootstrapped — building one Order step (schema, contract, repository, service, controller, hook, screen), gating it, committing it, and checking it off TODO.md. Triggers on "next step", "build this module", "what's next", or the start of any work session on a bootstrapped project. Also covers the Correction Protocol for fixing a wrong upstream step.
+description: Use for every unit of work once a Hedgehog project is bootstrapped — building one layer (schema, contract, repository, service, controller, hook, screen) per module, gated by `hedgehog verify` and committed one layer at a time. Triggers on "next step", "build this module", "what's next", or the start of any work session on a bootstrapped project. Also covers the Correction Protocol for fixing a wrong upstream step.
 ---
 
 # Hedgehog Loop
 
-The operating loop for a bootstrapped Hedgehog project: pick the next step,
-build it, gate it, commit it, check it off. `TODO.md` at repo root is the
-live list — read it before starting. It's thin: a context blurb plus a
-checklist mirroring the phase/step structure below. Checked/unchecked is
-its only state.
+The operating loop for a bootstrapped Hedgehog project: `hedgehog next`
+emits the packet for one ready layer, build it, `hedgehog verify` gates
+and commits it. The build graph (`.hedgehog/hedgehog.db`) is the live
+list — query it via `hedgehog status`/`hedgehog next`, never re-derive
+state from prose. The step tables below mirror
+`src/golden-cores/full-stack-app/core.yaml`, already the source of truth
+for layer order, scope, and verify command per layer — read the tables
+for the human-readable shape, trust the YAML (and the packet `hedgehog
+next` emits from it) as the authoritative one if they ever seem to
+disagree.
 
 ## Determine phase
 
 Before touching code, know which phase applies to the module in scope:
 
 - **Phase A** — building/extending the backend. Every module in scope
-  needs schema → contract → repository → service → controller (→ queue)
-  before Phase B starts for any of them.
+  needs schema → contract → repository → service → controller before
+  Phase B starts for any of them.
 - **Phase B** — Phase A is closed for the module. Build hooks and screens.
 
-Check `TODO.md`, or the commit log for `feat(<module>): api` commits. No
-such commit means the module is in Phase A.
+Check `hedgehog status` (or `hedgehog why <path>` for a specific file),
+or the commit log for `feat(<module>): api` commits. No such commit (and
+no `controller` task `complete` for that module) means the module is in
+Phase A.
 
 ## The Domain Module Pattern
 
@@ -56,13 +63,16 @@ hook        (TanStack Query)       — Phase B only
 ```
 
 Plus, when an operation needs async **and the Queue add-on is on for this
-project** (check `TODO.md`'s `## Add-ons` block): **queue = port +
+project** (check `.hedgehog/addons.yaml`'s `queue.on`): **queue = port +
 BullMQ adapter**, same port/adapter shape as the repository. The service
-imports only ports. If the Queue add-on is off, there's no `apps/worker`
-and no queue step, full stop — an operation that seems to want async
-processing on a Queue-off project is a signal to revisit that add-on
-decision with `planner`, not to build a one-off queue outside the
-add-on's scaffolding.
+imports only ports. Queue is one-time project infra, not a compiled
+layer — `full-stack-app/core.yaml` has no `queue` layer, so this step has
+no `hedgehog verify` gate of its own; build it as part of the
+`controller` layer's packet, verified by that layer's own check. If the
+Queue add-on is off, there's no `apps/worker` and no queue step, full
+stop — an operation that seems to want async processing on a Queue-off
+project is a signal to revisit that add-on decision with `planner`, not
+to build a one-off queue outside the add-on's scaffolding.
 
 Standard Nx generators (`@nx/nest`, `@nx/next`, `@nx/expo`, `@nx/js`)
 scaffold the app/lib shell. Each step's actual content (schema, contract,
@@ -72,58 +82,76 @@ sequence.
 ## Domain Module — Backend Steps (Phase A, every module in scope)
 
 A horizontal pass across the whole backend — every module goes through
-these before any module gets a hook or screen. Delegate each module's
-Phase A steps to the `backend-eng` agent — it builds one step, gates it,
-commits it, and reports back.
+these before any module gets a hook or screen. Each row is one compiled
+layer in `full-stack-app/core.yaml`; delegate each module's Phase A
+layers to the `backend-eng` agent, one `hedgehog next` packet at a time —
+it builds the layer, `hedgehog verify` gates and commits it.
 
-| # | Step | Lives in | Commit |
+| # | Layer | Lives in | Commit |
 |---|---|---|---|
-| 1 | Schema | `packages/db` (Drizzle) | `feat(<module>): schema` |
-| 2 | Contract | `packages/contracts` (Zod via `drizzle-zod` + ts-rest) | `feat(<module>): contract` |
-| 3 | Repository | `libs/<module>/repository` (port + Drizzle adapter) | `feat(<module>): repository` |
-| 4 | Service | `libs/<module>/service` (domain logic — imports only ports) | `feat(<module>): service` |
-| 5 | Controller | `apps/api` (thin HTTP, wires contract → service) | `feat(<module>): api` |
-| 5a | Queue *(if needed, and only if the Queue add-on is on)* | `apps/worker` (port + BullMQ adapter) | `feat(<module>): queue` |
+| 1 | `schema` | `packages/db` (Drizzle) | `feat(<module>): schema` |
+| 2 | `contract` | `packages/contracts` (Zod via `drizzle-zod` + ts-rest) | `feat(<module>): contract` |
+| 3 | `repository` | `libs/<module>/repository` (port + Drizzle adapter) | `feat(<module>): repository` |
+| 4 | `service` | `libs/<module>/service` (domain logic — imports only ports) | `feat(<module>): service` |
+| 5 | `controller` | `apps/api` (thin HTTP, wires contract → service; bundles Queue infra, see above, if that add-on is on and this module needs it) | `feat(<module>): api` |
 
-Repeat 1–5(a) per module in scope. The API is complete, typed, and
-callable (Postman/curl/contract tests) before frontend work starts.
+Repeat 1–5 per module in scope, via `hedgehog next`/`hedgehog verify`.
+The API is complete, typed, and callable (Postman/curl/contract tests)
+before frontend work starts.
 
 ## Domain Module — Frontend Steps (Phase B, after Phase A closes for the module)
 
-| # | Step | Lives in | Commit |
+| # | Layer | Lives in | Commit |
 |---|---|---|---|
-| 6 | Hook | `packages/hooks` (TanStack Query) | `feat(<module>): hooks` |
-| 6a | UX rationale | `docs/design/<module>.md`, `ux-planner` agent | bundled into step 7's commit |
-| 7 | Screen | `apps/web` and/or `apps/mobile` | `feat(<module>): screen-web` / `feat(<module>): screen-mobile` |
+| 6 | `hook` | `packages/hooks` (TanStack Query) | `feat(<module>): hooks` |
+| 6a | UX rationale | `docs/design/<module>.md`, `ux-planner` agent | bundled into layer 7's commit |
+| 7 | `screen` | `apps/web` and/or `apps/mobile` | `feat(<module>): screen-web` / `feat(<module>): screen-mobile` |
 
 Phase B starts once Phase A is done for the scope. The frontend is a pure
-consumer of an already-finished API. Delegate each module's Phase B steps
-to the `front-end-eng` agent, same reasoning as `backend-eng` for Phase A
-— one step at a time, in its own context. Step 6a is where "how it should
-feel" gets decided — once per module, after the hook exists and before
-`front-end-eng` starts the screen — via `ux-planner`, starting from whatever
-`planner` filed in `docs/design/<module>-notes.md` at planning intake. Its first run
-for a module also signals to the user that Phase B has started, and is the
-point a mockup, screenshot, or export (Google Stitch, Figma) can be handed
-over. It writes `docs/design/<module>.md`, not its own step commit;
-`TODO.md` tracks only hooks/screen-web/screen-mobile per module.
+consumer of an already-finished API. Delegate each module's Phase B
+layers to the `front-end-eng` agent, same reasoning as `backend-eng` for
+Phase A — one `hedgehog next` packet at a time, in its own context. Step
+6a is where "how it should feel" gets decided — once per module, after
+the `hook` layer's task is `complete` and before `front-end-eng` starts
+the `screen` layer — via `ux-planner`, starting from whatever `planner`
+filed in `docs/design/<module>-notes.md` at planning intake, or the raw
+UX spec directly if that file is absent. Its first run for a module also
+signals to the user that Phase B has started, and is the point a mockup,
+screenshot, or export (Google Stitch, Figma) can be handed over. It
+writes `docs/design/<module>.md`, not its own compiled layer — the
+`screen` layer's `hedgehog verify` is what gates and commits it.
 
 ## The Loop (every unit of work)
 
-1. **Pick the next step** per the tables above, from `TODO.md`. One step
-   at a time, in order.
-2. **Check the gate.** The prior step compiles and passes tests first.
-3. **Delegate exactly one step** to `backend-eng` (Phase A) or
-   `front-end-eng` (Phase B) — one schema, one contract, one repository.
-4. The agent **runs the gate on its own work**: typecheck, lint, test
-   (mirrors lefthook, wired at bootstrap).
-5. The agent **commits** using the exact Conventional Commit format above.
-6. **Check off the line in `TODO.md`** once the agent reports the commit
-   landed.
-7. **Repeat**, one delegated step at a time.
-
-Each commit batches exactly one step, built right for what's known now; a
-wrong step is fixed forward later via the Correction Protocol.
+1. **Run `hedgehog next`.** It emits the task packet for one ready layer
+   (STATUS/WHY NOW/BLOCKED DOWNSTREAM/ALLOWED SCOPE/VERIFICATION) —
+   trust it: `hedgehog next` never emits a layer whose dependencies
+   aren't `complete`, so there's no separate gate check to run by hand.
+2. **Delegate the full packet** (not a step name) to `backend-eng`
+   (Phase A) or `front-end-eng` (Phase B) — one schema, one contract, one
+   repository, matching the packet's ALLOWED SCOPE.
+3. The agent **runs typecheck/lint/test on its own work** (mirrors
+   lefthook, wired at bootstrap) as a sanity check before reporting
+   back — necessary, not sufficient. The agent reports the work as done;
+   it does not move the task and does not commit.
+4. **Run `hedgehog verify <task-id>`.** It checks the touched files
+   against the packet's ALLOWED SCOPE, runs the layer's VERIFICATION
+   command, and on a pass writes the commit (the exact Conventional
+   Commit message from the tables above, plus the updated build graph)
+   and unlocks the next layer. On a scope violation or a failing check,
+   the task stays `implemented`/`failed` and nothing downstream unlocks —
+   fix it and re-run `hedgehog verify <task-id>`, don't hand-commit
+   around it.
+
+   A stalled task is not pickable by `hedgehog next`, so both `hedgehog
+   next` and `hedgehog status` list it under NEEDS ATTENTION with the
+   task id to re-verify. If `hedgehog next` reports the graph blocked,
+   fix that task — don't treat it as "nothing left to do."
+5. **Repeat** — `hedgehog next` again for the following layer.
+
+Each `hedgehog verify` call commits exactly one layer, built right for
+what's known now; a wrong layer is fixed forward later via the
+Correction Protocol.
 
 ## Intra-step conventions
 
@@ -165,12 +193,14 @@ had to correct the same kind of mistake more than once, or user
 feedback implied something was wrong even without a direct correction
 (a preference stated once that, read plainly, means an earlier step
 missed something) — is signal worth keeping past this session, separate
-from the Correction Protocol that fixes it in the moment. Append one
-entry to `.hedgehog/friction.md` (create it if it doesn't exist) when
-that happens: what was tried, what went wrong or was implied, why if
-visible, and the commit/message it traces to. This is a log, not a todo
-list — don't let it block or slow the Loop; append and keep moving.
-`tweaker` reads it once the build reaches its Stop Condition.
+from the Correction Protocol that fixes it in the moment. Log one entry
+via `hedgehog friction add "<note>" [--task <task-id>]` when that
+happens: what was tried, what went wrong or was implied, why if visible,
+and the commit/message it traces to, all in the note text; pass `--task`
+with the layer's task id when the friction traces to one. This is a log,
+not a todo list — don't let it block or slow the Loop; log and keep
+moving. `tweaker` reads it (via `hedgehog friction list`) once the build
+reaches its Stop Condition.
 
 ## Correction Protocol
 
@@ -195,7 +225,8 @@ working-tree pass and needs splitting back into per-step commits.
 
 Before starting Phase B for a module, confirm:
 
-- A `feat(<module>): api` commit exists for that module.
+- `hedgehog status` shows that module's `controller` task `complete`
+  (equivalently, a `feat(<module>): api` commit exists).
 - The contract is callable and typed (contract tests pass).
 
 Use the `reviewer` agent for this — it checks what the mechanical gate
@@ -210,10 +241,10 @@ boundary from planning intake (`planner`). If not, stop and ask.
   working, tested API before any hook or screen starts.
 - **Sequential within a phase.** A step starts once the one before it
   compiles and passes tests.
-- **Step 5a is conditional twice over** — only if the Queue add-on is on
-  for this project at all (per `TODO.md`'s `## Add-ons` block), and even
-  then only when a given operation genuinely needs async (long-running,
-  retries, fan-out); the normal case has no queue.
+- **Queue infra is conditional twice over** — only if the Queue add-on is
+  on for this project at all (per `.hedgehog/addons.yaml`'s `queue.on`),
+  and even then only when a given operation genuinely needs async
+  (long-running, retries, fan-out); the normal case has no queue.
 - **A wrong step gets fixed at its source** — the Correction Protocol, not
   a downstream workaround.
 - **Tests gate every commit** in the sequence.
@@ -226,16 +257,17 @@ boundary from planning intake (`planner`). If not, stop and ask.
 
 ## Stop Condition
 
-A build session ends when every module in scope has completed both Phase
-A and Phase B, or when scope is ambiguous enough that continuing means
-guessing — ask one question and wait.
+A build session ends when `hedgehog status` shows every task for every
+module in scope `complete` (Phase A and Phase B both closed), or when
+scope is ambiguous enough that continuing means guessing — ask one
+question and wait.
 
 On the former (a real build completion, not an ambiguity stop), offer a
 fresh-context handoff before doing anything else: tell the user the
-build is complete, that clearing context now costs nothing (`TODO.md`
-and the commit log hold everything), and that a `tweaker` session is the
-right next step for any adjustments — it starts clean, reviews
-`.hedgehog/friction.md` once for a possible discipline-improvement
-suggestion, and takes tweak requests one at a time from there. Don't
-start making tweaks in the current, already-large context; that's what
-the fresh session is for.
+build is complete, that clearing context now costs nothing (the build
+graph and the commit log hold everything), and that a `tweaker` session
+is the right next step for any adjustments — it starts clean, reviews
+the friction log (`hedgehog friction list`) once for a possible
+discipline-improvement suggestion, and takes tweak requests one at a
+time from there. Don't start making tweaks in the current, already-large
+context; that's what the fresh session is for.

package/src/skills/hedgehog-planning-intake/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: hedgehog-planning-intake
-description: Use once per project, at the start, on either core — Phase 0 (running the vendored BMAD-METHOD planning shelf) is shared by full-stack-app and landing-page alike; Phase 1 (mining BMAD's output into scope boundary/domain modules/the Add-ons decision) is full-stack-app's own procedure, run again on a scoped pass when new domain scope enters play. Invoked by the `planner` agent after Phase 0 core selection; don't run standalone. landing-page runs this skill's Phase 0, then mines the same archive through `hedgehog-landing-loop`'s own planning-intake section, that core's counterpart to this skill's Phase 1.
+description: Use once per project, at the start, on either core — Phase 0 (running the vendored BMAD-METHOD planning shelf) is shared by full-stack-app and landing-page alike; Phase 1 (mining `04-prd.md` into intent records plus the Add-ons decision) is full-stack-app's own procedure, run again on a scoped pass when new domain scope enters play. Invoked by the `planner` agent after Phase 0 core selection; don't run standalone. landing-page runs this skill's Phase 0, then mines the same archive through `hedgehog-landing-loop`'s own planning-intake section, that core's counterpart to this skill's Phase 1.
 ---
 
 # Hedgehog Planning Intake
@@ -8,13 +8,12 @@ description: Use once per project, at the start, on either core — Phase 0 (run
 Turns a person's description of a problem into planning material, by
 running the vendored BMAD-METHOD planning shelf (Phase 0, shared by both
 cores) and mining its output. On full-stack-app that mining is this
-skill's own Phase 1, into scope boundary/domain modules/Add-ons; on
-landing-page it's `hedgehog-landing-loop`'s planning-intake section, into
-a subject/audience/job statement. This is the mechanics `planner` calls
-once its Phase 0 core-selection check has picked a core — the
-interpretive judgment (scope boundary, module split, Add-ons decision on
-full-stack-app; subject statement on landing-page; Confirm & Lock either
-way) belongs to `planner`; this skill (Phase 0, and Phase 1 on
+skill's own Phase 1, into intent records written via `hedgehog intent
+add`; on landing-page it's `hedgehog-landing-loop`'s planning-intake
+section, into a subject/audience/job statement. This is the mechanics
+`planner` calls once its Phase 0 core-selection check has picked a core —
+the interpretive judgment (which Feature becomes which intent, Confirm &
+Lock either way) belongs to `planner`; this skill (Phase 0, and Phase 1 on
 full-stack-app) and `hedgehog-landing-loop` (landing-page's own mining)
 are the fixed procedures that judgment runs inside.
 
@@ -73,86 +72,63 @@ relationship the commit log has to a merged PR.
 landing-page's counterpart to this Phase 1 is
 `hedgehog-landing-loop`'s own planning-intake section, run once Phase 0
 above completes: it mines the same `.hedgehog/BMAD/` archive into a
-subject/audience/job statement, in place of the scope boundary/domain
-modules/Add-ons decision this Phase 1 produces.
-
-Read `.hedgehog/BMAD/` once and do the interpretive work BMAD's docs
-don't do for you — none of BMAD's outputs contain a ready-made
-Auth/Queue/Mobile toggle or a module-ownership/FK table; the PRD's
-Glossary is the closest thing, but it's vocabulary-shaped prose, not a
-decision table:
-
-1. **Scope boundary** — derive from the brief's Scope section plus the
-   PRD's Glossary/Features. In scope: what the elicited material actually
-   called for. Out of scope: anything the brief or PRD flagged as
-   deferred, painful-but-not-now, or explicitly excluded.
-2. **Domain modules** — derive from the PRD's Glossary (entity,
-   relationships, cardinality): one table = one module, same rule as
-   Hedgehog has always used. A cluster with its own lifecycle, referenced
-   by other things, is a candidate module; a thing mentioned only as a
-   property of another isn't.
-3. **Cross-module references** — from the Glossary's relationships/
-   cardinality, identify which module's schema holds the FK, so build
-   order between modules is clear before anyone writes a schema.
-4. **Add-ons decision** (Auth, Queue, Mobile) — check BMAD's docs (brief,
-   PRD, UX spec) for each trigger first:
-   - **Auth** — on if the material describes accounts, logins, or
-     per-user/per-account data.
-   - **Queue** — on if at least one described operation is genuinely
-     long-running, needs retries, or fans out.
-   - **Mobile** — on if the material explicitly wants a mobile app
-     alongside or instead of web.
-
-   Infer first, gap-fill second — this is not a second full interview.
-   For any add-on the text leaves genuinely unresolved (not mentioned
-   either way), ask the user directly, the same direct-question posture
-   as an ambiguous scope boundary: "does this need user accounts/login,
-   or is it just for you?", "is anything here a background job, or is it
-   all instant reads and writes?", "web only, or mobile too?" A "no" is a
-   resolved answer, not a gap. Never default an add-on on or off without
-   either a concrete trigger in BMAD's docs or a direct answer — an
-   unasked add-on question is a guess.
-5. **Run Confirm & Lock** (below) before writing anything.
-6. **Write `TODO.md`** — the checklist mirroring Bootstrap, Phase A, and
-   Phase B steps per module and add-on in scope, plus the `## Add-ons`
-   block (see "The Add-ons block" below).
-7. **File `docs/design/<module>-notes.md` per module** — sourced from
-   `.hedgehog/BMAD/05-ux-spec/EXPERIENCE.md` (information architecture,
-   states, flows) and `DESIGN.md` (visual identity): file each module's
-   slice into its own notes file, same fixed filename pattern, same
-   "every module gets one, even if empty" rule as always — a module with
-   no UX-spec material yet still gets a `docs/design/<module>-notes.md`
-   stating that plainly, not a missing file. `ux-planner` reads this file
-   as raw screen/flow material at that module's Phase B.
-8. **Fill root `CLAUDE.md`'s `{{PROJECT_NAME}}` and `{{PROJECT_SUMMARY}}`
+subject/audience/job statement, in place of the intents this Phase 1
+produces.
+
+Read `.hedgehog/BMAD/04-prd.md` only — §3 Glossary and §4 Features.
+Nothing else in `.hedgehog/BMAD/` is read again: brainstorming, brief,
+PR-FAQ, and deep-recon existed to produce a good PRD, and the UX spec is
+read later, once per module, by `ux-planner`, not by this mining pass.
+Mining is mechanical, not interpretive — one graph row per PRD element,
+per this table:
+
+| PRD element | Graph row |
+| --- | --- |
+| §4 Feature | one `intents` row — the feature's description already reads as `goal` + `outcome` |
+| FR "Consequences (testable)" item | `requirements` row, `kind='acceptance'` |
+| Feature-specific NFR / cross-cutting rule | `requirements` row, `kind='rule'` |
+| §3 Glossary relationship/cardinality | `intent_dependencies` row (the referencing feature's intent depends on the referenced feature's intent) |
+
+Procedure:
+
+1. **Walk §4 Features top to bottom.** For each Feature, that's one
+   intent: `id` a short kebab-case slug of the Feature's name, `goal` and
+   `outcome` drawn directly from the Feature's description (split the
+   description across the two if it names both the capability and the
+   result; otherwise the same sentence can serve both).
+2. **Walk that Feature's FRs.** Each FR's "Consequences (testable)" list
+   items become that intent's `requirements` with `kind='acceptance'`,
+   one per item, verbatim or lightly tightened — no rephrasing that
+   changes what's being tested.
+3. **Collect any NFR or cross-cutting rule scoped to that Feature**
+   (not a project-wide NFR with no single owning Feature) as a
+   `requirements` row with `kind='rule'` on that intent.
+4. **Walk §3 Glossary relationships and cardinality.** Each relationship
+   between two entities that belong to different Features' intents
+   becomes one `intent_dependencies` row: the intent for the entity
+   holding the foreign key depends on the intent for the entity it
+   references. A relationship entirely inside one Feature's entities
+   produces no row — it's already the same intent.
+5. **Run the Add-ons decision** (`planner`'s own judgment call — see that
+   agent's "The Add-ons decision") for Auth, Queue, and Mobile.
+6. **Run Confirm & Lock** (below) before writing anything.
+7. **Write each intent via `hedgehog intent add`** — one invocation per
+   Feature: `--acceptance` per row from step 2, `--rule` per row from step
+   3, `--depends-on` per row from step 4, or an equivalent `--file
+   <path.json>` batch matching the same shape (`{ id, goal, outcome,
+   rules, acceptance, depends_on, priority }`). This is Phase 1's only
+   write to the build graph.
+8. **Write `.hedgehog/addons.yaml`** with the Add-ons decision from step 5.
+9. **Fill root `CLAUDE.md`'s `{{PROJECT_NAME}}` and `{{PROJECT_SUMMARY}}`
    placeholders**, first run only, then delete the installer's HTML
    comment block at the top of that file. Leave every other line
    untouched.
 
-On a later run (new scope entering play), skip steps 4 and 8 unless new
-scope genuinely changes an add-on trigger (e.g. accounts get added where
-there were none) or the project's identity itself changed — append new
-module sections to `TODO.md` only, never touch an existing module's
-checked boxes or reorder modules already in progress.
-
-## The Add-ons block
-
-`TODO.md` carries the Add-ons decision directly — no side-channel
-document. Write a short, fixed-format `## Add-ons` block into `TODO.md`:
-
-```
-## Add-ons
-- Auth: on — accounts/login in scope
-- Queue: off — no long-running ops
-- Mobile: off — not requested
-```
-
-Each line: the add-on, on/off, a one-line reason it landed there. This is
-the single stable, machine-checkable field every downstream check reads
-— `hedgehog-bootstrap`, `bootstrap`, `hedgehog-loop`, and `reviewer` all
-check `TODO.md`'s `## Add-ons` block, not any other file. An absent
-`## Add-ons` block reads as "never decided," not "decided off" — those
-two are distinct and downstream checks treat them differently.
+On a later run (new scope entering play), skip steps 8 and 9 unless new
+scope genuinely changes an add-on trigger or the project's identity
+itself changed — mine only the PRD's new or changed Features into
+additional `hedgehog intent add` calls, never re-add or edit an intent
+already in the graph.
 
 ## Confirm & Lock
 
@@ -162,25 +138,24 @@ stops being true, so it's a hard stop, not a recap in passing.
 
 🔒 **Confirm & Lock**. Show, in full, not condensed:
 
-- The scope boundary (in / out), sourced from the brief + PRD.
+- Each intent about to be added: `id`, `goal`, `outcome`, its
+  `requirements` (rule/acceptance), and its `depends_on` list.
 - The Add-ons decision (Auth / Queue / Mobile, each explicitly on or
-  off, with the one-line reason — from BMAD's docs or a direct answer).
-- The domain vocabulary / module list, in build order, with any
-  cross-module FK dependencies flagged.
+  off, with the one-line reason).
 - Which BMAD skills ran and where their output lives
   (`.hedgehog/BMAD/`).
 
 Then state plainly what happens on confirmation, before it happens:
 
-> This locks in `TODO.md` (with the `## Add-ons` block) and
-> `docs/design/<module>-notes.md` per module, commits them in one pass
-> (`chore(planning): intake`), and hands off to the `bootstrap` agent to
-> scaffold the workspace and whichever add-ons are on. Phase A build
-> (schema first) starts on the first module once that closes. Anything
-> wrong or missing — say so now; it's a normal edit before this point,
-> and a Correction Protocol entry after. Confirm to proceed, or tell me
-> what to change.
+> This writes each intent above via `hedgehog intent add` and the
+> Add-ons decision to `.hedgehog/addons.yaml`, then shows the compiled
+> graph with `hedgehog status`. Phase A build (schema first) starts on
+> the first ready task once that closes. Anything wrong or missing — say
+> so now; it's a normal edit before this point, and a Correction Protocol
+> entry after. Confirm to proceed, or tell me what to change.
 
 Wait for an explicit go-ahead. A revision here is just another mining
 pass — update the draft, re-run this stage, don't write anything until
-the confirmation holds.
+the confirmation holds. Once confirmed, after every `hedgehog intent add`
+call lands, run `hedgehog status` and show it in full as the graph's
+confirmation view.

package/src/templates/CLAUDE.core.full-stack-app.md

@@ -4,18 +4,20 @@ Backend-first, schema → contract → repository → service → controller, th
 hook → UX rationale → screen, per domain module. See `.hedgehog/BMAD/` for
 the archival planning intake output — BMAD-METHOD's brainstorming, brief,
 PRD, and UX spec, written once by `planner` and never edited after.
-`TODO.md` also carries this core's `## Add-ons` block (Auth/Queue/Mobile,
-each on or off) — check it before assuming any add-on's infra exists.
+`.hedgehog/addons.yaml` carries this core's Add-ons decision
+(Auth/Queue/Mobile, each on or off) — check it before assuming any
+add-on's infra exists.
 
 ### The skills — invoke these, don't improvise
 
 The discipline is packaged as skills. Use them; don't reconstruct their
 steps from memory:
 
-- **`hedgehog-loop`** — every unit of work once bootstrapped: pick the
-  next step from `TODO.md`, build exactly one, gate it, commit it, check
-  it off. Also holds the Correction Protocol for fixing a wrong upstream
-  step. Invoke it at the start of any build session and for "what's next".
+- **`hedgehog-loop`** — every unit of work once bootstrapped: `hedgehog
+  next` emits the packet for one ready layer, build exactly one, gate it
+  via `hedgehog verify`, which commits it on a pass. Also holds the
+  Correction Protocol for fixing a wrong upstream step. Invoke it at the
+  start of any build session and for "what's next".
 - **`hedgehog-bootstrap`** — run **once**, at project start, to scaffold
   the core stack, the enforcement config, and whichever add-ons (Auth,
   Queue, Mobile) planning intake turned on. Skip if `nx.json` already
@@ -28,22 +30,25 @@ steps from memory:
 
 - **`planner`** — planning intake (which core applies, then
   `hedgehog-planning-intake`'s BMAD-METHOD brainstorming/brief/PRD/UX-spec
-  shelf, mined into scope boundary, the Add-ons decision, and domain
+  shelf, mined into intent records, the Add-ons decision, and domain
   vocabulary) at project start, and module scoping when new scope enters
-  play. Writes `TODO.md` (including its `## Add-ons` block),
-  `.hedgehog/BMAD/`, and `docs/design/<module>-notes.md`. On first run,
-  hands off to the `bootstrap` agent once Confirm & Lock holds.
+  play. Writes intents via `hedgehog intent add`, `.hedgehog/addons.yaml`,
+  and `.hedgehog/BMAD/`. On first run, hands off to the `bootstrap` agent
+  once Confirm & Lock holds.
 - **`bootstrap`** — runs `hedgehog-bootstrap`'s core steps (always) plus
   whichever add-on steps planning intake turned on. Triggered
   automatically by `planner` after its first run; skip if `nx.json`
   already exists.
-- **`backend-eng`** — builds each module's Phase A steps (schema →
-  contract → repository → service → controller → queue?), one step at a
-  time, gated and committed in its own context.
+- **`backend-eng`** — builds each module's Phase A layers (schema →
+  contract → repository → service → controller → queue?), one
+  `hedgehog next` packet at a time, gated by `hedgehog verify`.
 - **`ux-planner`** — once per module in Phase B, after the hook exists and
-  before the screen: writes `docs/design/<module>.md`.
-- **`front-end-eng`** — builds each module's Phase B steps (hook, screen)
-  from the ux-planner rationale, one step at a time, in its own context.
+  before the screen: writes `docs/design/<module>.md`, reading
+  `.hedgehog/BMAD/05-ux-spec/` directly (or
+  `docs/design/<module>-notes.md` if a prior run already filed one).
+- **`front-end-eng`** — builds each module's Phase B layers (hook, screen)
+  from the ux-planner rationale, one `hedgehog next` packet at a time,
+  gated by `hedgehog verify`.
 - **`reviewer`** — phase-transition and Correction Protocol checks the
   mechanical gate can't make (port discipline, FK-by-ID discipline,
   contract shape).
@@ -61,8 +66,8 @@ Pino logging · Vitest + Playwright (tests) · Conventional Commits +
 commitlint + lefthook · Sentry.
 
 **Add-ons** — each on or off per project, decided at planning intake and
-recorded in `TODO.md`'s `## Add-ons` block; check that block for this
-project's actual picks rather than assuming any of these are present:
+recorded in `.hedgehog/addons.yaml`; check that file for this project's
+actual picks rather than assuming any of these are present:
 
 | Add-on | Adds |
 | --- | --- |
@@ -72,8 +77,8 @@ project's actual picks rather than assuming any of these are present:
 
 An add-on that's off means the corresponding piece of infra genuinely
 isn't in this codebase — don't write code assuming `packages/auth`,
-`apps/worker`, or `apps/mobile` exist without checking `TODO.md`'s
-`## Add-ons` block first.
+`apps/worker`, or `apps/mobile` exist without checking
+`.hedgehog/addons.yaml` first.
 
 Don't substitute libraries, in core or in whichever add-ons are on. If a
 package or generator name changed upstream, verify against current docs
@@ -99,13 +104,15 @@ packages/
 libs/
   <module>/port · <module>/repository · <module>/service   (one triplet per table)
 .hedgehog/
-  BMAD/      archival planning intake output (brief, PRD, UX spec, research) — write-once, from planner
+  hedgehog.db    the build graph — intents, tasks, dependencies, verifications, committed to git
+  addons.yaml    the Add-ons decision (Auth/Queue/Mobile), from planner
+  BMAD/          archival planning intake output (brief, PRD, UX spec, research) — write-once, from planner
 docs/
-  design     <module>-notes.md (planner, sourced from BMAD's UX spec) and <module>.md (ux-planner)
+  design     <module>.md (ux-planner, reading .hedgehog/BMAD/05-ux-spec/ directly)
 ```
 
-Check `TODO.md`'s `## Add-ons` block before assuming any "only if" line
-above is actually present in this codebase.
+Check `.hedgehog/addons.yaml` before assuming any "only if" line above is
+actually present in this codebase.
 
 ### Core rules