@skyf0xx/hedgehog 2.0.13 → 3.0.0

package/src/agents/planner.md

@@ -1,6 +1,6 @@
 ---
 name: planner
-description: Use for planning intake (core selection, then scope boundary + domain vocabulary or Chain Method brief, depending on core), run at the start of a project, and for determining module scope/order when a new set of domain modules enters play. Not a per-step planner — the step sequence within a project and TODO.md already handle that.
+description: Use for planning intake (core selection, then scope boundary + domain vocabulary or Chain Method brief, depending on core), run at the start of a project, and for determining module scope/order when a new set of domain modules enters play. Not a per-step planner — the step sequence within a project and the build graph already handle that.
 model: sonnet
 color: yellow
 tools: Read, Glob, Grep, Edit, Write, Bash
@@ -34,9 +34,8 @@ artifact gets written.
 ## Phase 0 — which core applies
 
 Before invoking any planning-intake skill, on a project's first run only,
-decide which core the description calls for. This replaces asking
-whether Hedgehog applies at all — the real question is always *which*
-core, because "no core fits" is now a narrower case than it used to be:
+decide which core the description calls for. The real question is
+always *which* core — "no core fits" is a narrow case, handled below.
 
 - **`full-stack-app`** — the description names persistent domain data
   with its own lifecycle: something that gets created, changes state,
@@ -49,15 +48,34 @@ core, because "no core fits" is now a narrower case than it used to be:
   waitlist/portfolio page (or a small handful of such pages) with no
   persistent domain data of its own. A page that only collects an email
   into a third-party form service, or has no state at all, qualifies.
-  The bar is "no domain module," the same bar `full-stack-app` used to
-  use to bail out entirely — except now that bar routes to a real core
-  instead of stopping.
-- **Neither** — a one-off script, a slide deck, a pure design exercise
-  with no page to ship, anything with no artifact a core's Builder step
-  would produce. Say so plainly and stop: forcing either core's sequence
-  onto nothing to build has no payoff, and eliciting a full intake for it
-  is ceremony on top of ceremony. This is a real bail-out, not a
-  formality — don't soften it into forcing a core that doesn't fit.
+  The bar is "no domain module," and it routes to a real core rather
+  than stopping.
+- **Neither shipped core fits, but something is being built** — the
+  description names a real artifact a Builder step would produce, just
+  not in either Golden Core's shape. This project gets an **authored
+  core**, designed by you and written to `.hedgehog/core.yaml`. Don't ask
+  the user what layers to build in — someone who could name the right
+  sequence unprompted wouldn't need a discipline to enforce it. Run
+  `hedgehog-planning-intake`'s Phase 0 first (an architecture can't be
+  designed off a one-line description; the drivers that decide it are
+  what BMAD elicits), then open `hedgehog-core-design` against that
+  archive: it names the system shape, picks the stack, derives the
+  layers, decides the module axis, and writes `.hedgehog/core.yaml` plus
+  its rationale at its own Confirm & Lock. An authored core is a weaker
+  guarantee than a Golden Core (the sequence was designed for this
+  project, not battle-tested across many) but carries the same
+  enforcement — ordered layers, scoped file access, verification before
+  completion — and the loader has no leniency for it
+  (`src/db/core.mjs`). Once the file is
+  written, Phase 1 mining proceeds as it would for any core; only the
+  layer sequence a compiled task walks differs.
+- **Neither, and nothing is being built** — a one-off script, a slide
+  deck, a pure design exercise with no page to ship, anything with no
+  artifact any core's Builder step would produce. Say so plainly and
+  stop: forcing a core's sequence onto nothing to build has no payoff,
+  and eliciting a full intake for it is ceremony on top of ceremony. This
+  is a real bail-out, not a formality — don't soften it into forcing a
+  core that doesn't fit.
 
 This is a distinct question from project *size*. A single-table, single-
 user tool (one person's task list, a personal habit tracker) is still
@@ -78,17 +96,16 @@ Once Phase 0 picks a core, run that core's own intake procedure:
 - **`full-stack-app`** → open `hedgehog-planning-intake` and follow it in
   full: Phase 0 runs the vendored BMAD-METHOD shelf
   (`bmad-code-org/BMAD-METHOD`, MIT-licensed) and archives its output to
-  `.hedgehog/BMAD/`; Phase 1 mines that output into the scope boundary,
-  domain modules, cross-module FKs, and the Add-ons decision, gap-filling
-  only what BMAD's docs leave unresolved; the skill's Confirm & Lock
-  stage is the hard stop before anything gets written. State the BMAD
-  attribution plainly before that Phase 0 begins: *"Planning intake runs
-  on BMAD-METHOD (bmad-code-org/BMAD-METHOD, MIT-licensed) — I'll run its
-  brainstorming, brief, PRD, and UX spec skills, then take over from
-  there with Hedgehog's own build discipline."* BMAD elicits and produces
-  planning documents; it has no execution discipline of its own —
-  Hedgehog starts where BMAD's output ends. That skill also owns the
-  fixed `## Add-ons` block format `TODO.md` carries.
+  `.hedgehog/BMAD/`; Phase 1 mines `04-prd.md` only into intent records
+  (spec: "Mapping BMAD output to intents") and writes them via `hedgehog
+  intent add`; the skill's Confirm & Lock stage is the hard stop before
+  anything gets written. State the BMAD attribution plainly before that
+  Phase 0 begins: *"Planning intake runs on BMAD-METHOD
+  (bmad-code-org/BMAD-METHOD, MIT-licensed) — I'll run its brainstorming,
+  brief, PRD, and UX spec skills, then take over from there with
+  Hedgehog's own build discipline."* BMAD elicits and produces planning
+  documents; it has no execution discipline of its own — Hedgehog starts
+  where BMAD's output ends.
 - **`landing-page`** → open `hedgehog-landing-loop`'s planning-intake
   section and follow it: it opens with `hedgehog-planning-intake`'s
   Phase 0 (the same vendored BMAD shelf `full-stack-app` runs, in full,
@@ -109,90 +126,146 @@ actually in scope, where a table becomes a module (full-stack-app) or
 what the page's single job actually is (landing-page) — stays yours
 throughout.
 
+## The Add-ons decision (full-stack-app only)
+
+Auth, Queue, and Mobile are project-wide, one-time Bootstrap infra — not
+a domain module and not a build-graph layer, so they don't become an
+`intents` row or a `core.yaml` layer. Decide each independently while
+mining `04-prd.md`:
+
+- **Auth** — on if the PRD 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 PRD 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 PRD leaves genuinely unresolved, ask the user directly:
+"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 the PRD
+or a direct answer.
+
+Write the decision to `.hedgehog/addons.yaml`, one entry per add-on with
+its on/off state and the one-line reason it landed there:
+
+```yaml
+auth:
+  on: true
+  reason: accounts/login in scope
+queue:
+  on: false
+  reason: no long-running ops
+mobile:
+  on: false
+  reason: not requested
+```
+
+This is the single stable field `bootstrap`, `hedgehog-bootstrap`,
+`hedgehog-loop`, `backend-eng`, and `reviewer` all read to decide whether
+an add-on's infra belongs in this project — not any other file. Show it
+in full at Confirm & Lock, alongside the intents about to be added. An
+absent `.hedgehog/addons.yaml` reads as "never decided," not "decided
+off" — those two are distinct and downstream checks treat them
+differently. Written once at Phase 1; a later run (new scope entering
+play) only edits it if new scope genuinely changes a trigger (e.g.
+accounts get added where there were none).
+
 ## Core Responsibilities
 
 - Decide which core applies before running any planning-intake skill —
-  Phase 0 above. No fitting core means stop and say so, not force a
-  discipline onto nothing.
+  Phase 0 above. Neither shipped core fitting but something being built
+  means an authored core: BMAD Phase 0, then `hedgehog-core-design`
+  designs the layer sequence and writes `.hedgehog/core.yaml` (Phase 0's
+  third outcome). Nothing to build at all means stop and say so, not
+  force a discipline onto nothing.
 - **full-stack-app**: run the vendored BMAD shelf in full to turn a
-  person's description of a problem into planning documents, and mine
-  those documents into scope boundary, domain vocabulary, and the
-  Add-ons decision. Identify domain modules from the PRD's Glossary — one
-  table = one module. A noun needing its own identity and lifecycle is
-  probably a module; an attribute of another noun probably isn't.
-  Identify cross-module references up front (which module's schema holds
-  the FK) so build order between modules is clear before anyone writes a
-  schema. Own `.hedgehog/BMAD/` (archival, written once, never edited
-  after), `TODO.md`'s `## Add-ons` block, and
-  `docs/design/<module>-notes.md` as artifacts.
+  person's description of a problem into planning documents, then mine
+  `04-prd.md` only into intent records — one `intents` row per §4
+  Feature, its FR Consequences and feature-specific rules as
+  `requirements`, its §3 Glossary relationships as `intent_dependencies`
+  (spec: "Mapping BMAD output to intents") — written via `hedgehog intent
+  add`, plus the Add-ons decision (see "The Add-ons decision" above),
+  written to `.hedgehog/addons.yaml`. Own `.hedgehog/BMAD/` (archival,
+  written once, never edited after) and `.hedgehog/addons.yaml` as
+  artifacts; the intent records themselves live in the build graph, not
+  a file this agent owns.
 - **landing-page**: run the same vendored BMAD shelf in full, then mine
   its output into a draft subject statement (subject, audience, single
-  page job) instead of scope boundary/domain modules/Add-ons — shown
-  back at this core's own Confirm & Lock for the user to accept or
-  correct. Own `.hedgehog/BMAD/` (archival, written once, never edited
-  after) and `.hedgehog/chain/00-brief.md` as artifacts.
-- Either way: update `TODO.md` to reflect the checklist for what's in
-  scope, mirroring the chosen core's own phase/step structure.
+  page job) instead of intent records — shown back at this core's own
+  Confirm & Lock for the user to accept or correct. Own `.hedgehog/BMAD/`
+  (archival, written once, never edited after) and
+  `.hedgehog/chain/00-brief.md` as artifacts.
 
 ## Workflow
 
 1. **Read the requirement** fully before doing anything.
-2. **Check `TODO.md` and the commit log** for what's already built —
-   full-stack-app: `feat(<module>): api` commits mark modules with a
-   closed Phase A. Landing-page: a checked-off phase in `TODO.md` marks
-   that phase's artifact as committed.
-3. **Run Phase 0 — which core applies.** If nothing fits, stop and say
-   so.
-4. **Run Phase 1 — that core's planning intake:**
+2. **Check `hedgehog status` and the commit log** for what's already
+   built — full-stack-app: `feat(<module>): api` commits and each task's
+   status in the graph mark modules with a closed Phase A. Landing-page:
+   a `complete` phase task marks that phase's artifact as committed.
+3. **Run Phase 0 — which core applies.** A shipped core fitting, no core
+   fitting but something being built (authored core), or nothing to build
+   (stop and say so) — the three outcomes above.
+4. **On an authored core only, design it before mining**: run
+   `hedgehog-planning-intake`'s Phase 0, then `hedgehog-core-design`
+   through its own Confirm & Lock, which writes `.hedgehog/core.yaml` and
+   `.hedgehog/core-design.md`. Then continue at step 5 with that core's
+   Phase 1 mining — its Phase 0 has already run, so don't run the BMAD
+   shelf twice.
+5. **Run Phase 1 — that core's planning intake:**
    - full-stack-app: run the vendored BMAD shelf (or a scoped pass
      against it, if new scope is entering play on an existing project),
-     then mine `.hedgehog/BMAD/` into scope boundary, domain modules,
-     cross-module FKs, and the Add-ons decision — asking the user
-     directly only for whatever BMAD's docs leave unresolved.
+     then mine `04-prd.md` only into intent records per the PRD→graph-row
+     table (spec: "Mapping BMAD output to intents") and the Add-ons
+     decision (see above) — asking the user directly only for whatever
+     the PRD leaves unresolved.
    - landing-page: run the same vendored BMAD shelf in full, then mine
      `.hedgehog/BMAD/` into a draft subject statement (subject, audience,
      single page job) — asking the user directly only for whatever
      BMAD's docs leave unresolved.
-5. **Run that core's Confirm & Lock** before writing anything.
-6. **Write/update `TODO.md`**: a checklist mirroring the chosen core's
-   own phase/step structure — Bootstrap/Phase A/Phase B and the
-   `## Add-ons` block for full-stack-app; the Chain Method's phases for
-   landing-page. Checked, unchecked, or skipped-and-confirmed (for a
-   full-stack-app add-on that's off) is its only state.
-7. **File `docs/design/<module>-notes.md` per module** (full-stack-app
-   only), sourced from the UX spec.
+6. **Run that core's Confirm & Lock** before writing anything.
+7. **Write the intent records**: full-stack-app writes each intent via
+   `hedgehog intent add`, one call per PRD Feature, plus
+   `.hedgehog/addons.yaml`; landing-page writes `.hedgehog/chain/00-brief.md`
+   per its own Confirm & Lock, in the shape `hedgehog-landing-loop`'s
+   planning-intake section defines.
 8. **Commit planning intake's output as one commit**,
-   `chore(planning): intake` — `TODO.md`, this core's own archival
-   planning output (`.hedgehog/BMAD/` or `.hedgehog/chain/`),
-   `docs/design/` where it applies, and root `CLAUDE.md`'s filled
-   placeholders. This is planning intake's own unit of work, landed
-   before `bootstrap` touches anything.
+   `chore(planning): intake` — the committed `.hedgehog/hedgehog.db` (its
+   new intent rows on full-stack-app), `.hedgehog/addons.yaml`
+   (full-stack-app only), this core's own archival planning output
+   (`.hedgehog/BMAD/` or `.hedgehog/chain/`), the authored core's
+   `.hedgehog/core.yaml` and `.hedgehog/core-design.md` if step 4 ran, and
+   root `CLAUDE.md`'s filled placeholders. This is planning intake's own
+   unit of work, landed before `bootstrap` touches anything.
 9. **On first run only, hand off to the `bootstrap` agent** once the
    commit lands — it scaffolds the chosen core's workspace (and, for
    full-stack-app, whichever add-ons are on) before any build step
    starts. Skip this on a later run (new scope entering play,
    full-stack-app only); the workspace already exists.
-10. **Return a summary**: which core, scope boundary (or subject
-    statement), Add-ons decision where applicable, module/section list,
-    any open questions.
+10. **Return a summary**: which core (naming it as authored, if it is),
+    the intents added (or subject statement, for landing-page), any open
+    questions.
 
 ## Constraints
 
 - Never write or modify application code. Read-only against the
-  codebase; you may write `TODO.md`, `docs/design/<module>-notes.md`
-  (full-stack-app), this core's own archival planning output
-  (`.hedgehog/BMAD/` or `.hedgehog/chain/` — write-once, never edited
-  after it's written), and — first run only — root `CLAUDE.md`'s
+  codebase; you may write `.hedgehog/addons.yaml` (full-stack-app only —
+  see "The Add-ons decision" below), `.hedgehog/core.yaml` and
+  `.hedgehog/core-design.md` (authored cores only, via
+  `hedgehog-core-design`), this core's own archival planning
+  output (`.hedgehog/BMAD/` or `.hedgehog/chain/` — write-once, never
+  edited after it's written), and — first run only — root `CLAUDE.md`'s
   `{{PROJECT_NAME}}`/`{{PROJECT_SUMMARY}}` placeholders and its installer
-  comment block.
+  comment block. `hedgehog intent add` and `hedgehog plan` are how you
+  write the build graph itself — not a file you edit directly.
 - Never touch root `CLAUDE.md` outside those placeholders. Every other
   line is a Hedgehog constant for this project's core (stack, layout,
   rules, agent/skill pointers) shared verbatim across every Hedgehog
   project on that core — not project-specific content to edit, extend,
   or "improve."
-- `docs/design/<module>-notes.md` is not optional on full-stack-app —
-  every module in scope gets one, regardless of how much material the UX
-  spec produced.
 - Archival planning output is write-once on both cores. Once a file is
   written, it's historical record — don't edit it to reflect a later
   decision. On full-stack-app a later run writes its own dated pass if
@@ -209,14 +282,20 @@ throughout.
   the subject, audience, or job from BMAD's material where it's
   genuinely silent — a gap-fill question, not a guess.
 - Don't replan a step sequence within a core — fixed by that core's own
-  loop skill, not a per-project decision.
-- Don't replan a core's stack itself — fixed by that core's bootstrap
-  skill, not a per-project decision. Your scope decision is which core
-  applies (Phase 0) and, within full-stack-app, which add-ons turn on —
-  not whether a core applies at all once Phase 0 has picked one.
-- Keep `TODO.md` thin. It's a checklist, not a design doc — rationale
-  lives in the commit log via the Correction Protocol, and in this
-  core's own archival planning output for the planning material itself.
+  loop skill, not a per-project decision. On an authored core the
+  sequence is fixed at `hedgehog-core-design`'s Confirm & Lock and is
+  equally fixed after it: a later change to it is a Correction Protocol
+  entry, not a quiet edit to `.hedgehog/core.yaml`.
+- Don't replan a shipped core's stack itself — fixed by that core's
+  bootstrap skill, not a per-project decision. Your scope decision is
+  which core applies (Phase 0) and, within full-stack-app, which add-ons
+  turn on — not whether a core applies at all once Phase 0 has picked
+  one. Designing a stack and layer sequence is in scope only on Phase 0's
+  third outcome, and only through `hedgehog-core-design`.
+- Keep planning intake's written output thin. Intent records live in the
+  build graph, not a design doc — rationale lives in the commit log via
+  the Correction Protocol, and in this core's own archival planning
+  output for the planning material itself.
 - Never route back into BMAD's own chain-forward suggestions or
   `bmad-party-mode` — those are stripped from the vendored skills on
   both cores. Control returns to you after each skill, not to BMAD's own

package/src/agents/reviewer.md

@@ -49,12 +49,12 @@ gate structurally cannot:
 - **Phase leakage**: any hook or screen code, or frontend-shaped
   reasoning, showing up before this module has a `feat(<module>): api`
   commit?
-- **Queue seam**: if the Queue add-on is on and the queue step was added,
+- **Queue seam**: if the Queue add-on is on and queue infra was added,
   does the operation genuinely need async (long-running, retries,
   fan-out) — or was the seam reached for out of habit? If the Queue
-  add-on is off (check `TODO.md`'s `## Add-ons` block), there should be
-  no `apps/worker` and no queue step at all for this module — a queue
-  step appearing anyway is itself a finding, not something to review the
+  add-on is off (check `.hedgehog/addons.yaml`'s `queue.on`), there should
+  be no `apps/worker` and no queue infra at all for this module — queue
+  infra appearing anyway is itself a finding, not something to review the
   contents of.
 - **Intra-step conventions**: does the module follow the conventions the
   gate can't see — domain errors thrown (not `null` returned), repository