@skyf0xx/hedgehog 0.1.21 → 2.0.0

package/src/templates/CLAUDE.md

@@ -2,8 +2,10 @@
   Hedgehog project CLAUDE.md template.
 
   This file is copied into a consuming project's repo root at install
-  time. Placeholders wrapped in {{ }} are filled in once, at planning
-  intake, by the `planner` agent (or by hand). Everything outside the
+  time, with the core-section marker below filled in from this
+  project's chosen core's own CLAUDE.core.<name>.md (src/templates/).
+  Placeholders wrapped in {{ }} are filled in once, at planning intake,
+  by the `planner` agent (or by hand). Everything outside the
   placeholders is a constant of the Hedgehog discipline and should be
   left as-is.
 
@@ -14,25 +16,24 @@
 
 {{PROJECT_SUMMARY — 2–4 sentences the `planner` writes at planning
 intake: what this project is, who it's for, and what it does. State
-current intent, not history. Keep it tight — the full product narrative,
-scope boundary, and domain vocabulary live in `.hedgehog/BMAD/` (the
-planning documents) and `TODO.md`, not here.}}
+current intent, not history. Keep it tight — the full product narrative
+lives in this core's own planning-intake output and `TODO.md`, not
+here.}}
 
-This project is built with **Hedgehog**: a backend-first, one-step-at-a-time
-build discipline. The rules below aren't project preferences — they're how
-the build stays mechanically correct. Follow them exactly.
+This project is built with **Hedgehog**: a one-step-at-a-time build
+discipline. The rules below aren't project preferences — they're how the
+build stays mechanically correct. Follow them exactly.
 
 ## First message in a fresh install
 
 If `{{PROJECT_SUMMARY}}` above is still an unfilled placeholder, this is a
 brand-new install and nothing has been built yet. Open with something
 short and warm — 🦔 plus one line asking what the user wants to build —
-then hand straight to `planner`, which runs planning intake on
-BMAD-METHOD (brainstorming → brief → PRD → UX spec), then mines that
-output into Hedgehog's own scope boundary and `## Add-ons` decision.
-Don't re-explain the discipline or summarize this file; the greeting is
-one line, not a tour. Skip this entirely once the placeholder is filled
-in — every later session starts with `TODO.md`, not a greeting.
+then hand straight to `planner`, which decides which Hedgehog core
+applies and runs that core's planning intake. Don't re-explain the
+discipline or summarize this file; the greeting is one line, not a tour.
+Skip this entirely once the placeholder is filled in — every later
+session starts with `TODO.md`, not a greeting.
 
 ## How to work here
 
@@ -40,197 +41,67 @@ The build is a loop of small, gated, committed steps. You never hold the
 whole plan in context — the plan lives in the structure:
 
 - **`TODO.md`** is the live checklist and the source of truth for what's
-  next, including the `## Add-ons` block (Auth/Queue/Mobile, each on or
-  off). Read it at the start of every session. Its only state is
-  checked/unchecked.
-- **`.hedgehog/BMAD/`** is the archival record of planning intake —
-  BMAD-METHOD's brainstorming, brief, PRD, and UX spec output, written
-  once by `planner` and never edited after. It's historical record, the
-  same relationship the commit log has to a merged PR — nothing in the
-  day-to-day build reads it live.
+  next. Read it at the start of every session. Its only state is
+  checked/unchecked (or skipped-and-confirmed, wherever this core's own
+  optional steps allow it).
 - **The commit log** is the record of what's built and why. Conventional
-  commits (`feat(<module>): schema`, `feat(<module>): api`, …) are how
-  progress is read, not a conversation summary.
-- **The architecture is fixed and opinionated** — the same on every
-  Hedgehog project. Where a service lives, what it may import, the module
-  shape, the phase order: all of it is inferable from this file and the
-  skills *without reading a line of code*. You don't discover the
-  patterns; you already know them.
-- **The codebase carries the project-specific instances** — which modules
-  exist, what a given schema's columns are, what's already wired. That,
-  you re-read from the code when you need it, rather than remembering it.
+  commits are how progress is read, not a conversation summary.
+- **The architecture is fixed and opinionated for this project's core**
+  — the same on every Hedgehog project running that core. Where a piece
+  lives, what it may depend on, the build order: all of it is inferable
+  from this file and the skills *without reading a line of code*. You
+  don't discover the patterns; you already know them.
+- **The codebase carries the project-specific instances** — what's
+  actually been built, what a given piece's shape is, what's already
+  wired. That, you re-read from the code when you need it, rather than
+  remembering it.
 
 Because state lives in those places and not in the conversation, a fresh
 context loses nothing: the architecture is known a priori, and the
 project's specifics are re-read on demand. Use that (see **Managing
 context** below).
 
-### 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-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
-  exists.
-- **`conventional-commits`** — when a change spans several steps in one
-  working-tree pass and needs splitting back into per-step commits (mainly
-  Correction Protocol cleanups).
-
-### The agents — delegate the judgment calls
-
-- **`planner`** — planning intake (whether Hedgehog applies at all, then
-  `hedgehog-planning-intake`'s BMAD-METHOD brainstorming/brief/PRD/UX-spec
-  shelf, mined into scope boundary, 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.
-- **`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.
-- **`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.
-- **`reviewer`** — phase-transition and Correction Protocol checks the
-  mechanical gate can't make (port discipline, FK-by-ID discipline,
-  contract shape).
-
-## The constants (do not deviate)
-
-### Stack: core (locked, every project) + add-ons (this project's picks below)
-
-**Core** — applies regardless of project size or which add-ons are on:
-Nx monorepo · pnpm · **NestJS** (all domain logic + DB access) · **Drizzle**
-(+ `drizzle-zod`) · **PostgreSQL** · **Docker Compose** (local Postgres,
-every host OS) · Railway · **ts-rest** contracts · **Zod** validation ·
-**TanStack Query** hooks · **Next.js** + ShadCN + Tailwind (web, UI only) ·
-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:
-
-| Add-on | Adds |
-| --- | --- |
-| Auth | Better Auth, `packages/auth`, a global auth guard on `apps/api` |
-| Queue | BullMQ + Redis, `apps/worker`, a `Queue` port/adapter seam |
-| Mobile | Expo + React Native Reusables + NativeWind, `apps/mobile` |
-
-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.
-
-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
-before running — don't swap in a different library.
-
-### Layout
-
-```
-docker-compose.yml   local Postgres (+ Redis if Queue add-on is on) — every host OS, no native install
-apps/
-  web        Next.js — UI only
-  mobile     Expo — only if Mobile add-on is on
-  api        NestJS — owns all domain logic + DB access
-  worker     BullMQ consumers — only if Queue add-on is on
-packages/
-  db         Drizzle schema + client
-  contracts  ts-rest + Zod contracts
-  hooks      TanStack Query — shared web + mobile
-  jobs       typed job registry / queue definitions — only if Queue add-on is on
-  auth       Better Auth config — only if Auth add-on is on
-  config     locked ESLint/Prettier/tsconfig/env schema
-  shared     cross-cutting types + utils
-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
-docs/
-  design     <module>-notes.md (planner, sourced from BMAD's UX spec) and <module>.md (ux-planner)
-```
-
-Check `TODO.md`'s `## Add-ons` block before assuming any "only if" line
-above is actually present in this codebase.
-
-### Core rules
-
-- **One table = one domain module.** Each carries the full step sequence.
-- **Cross-module references are FK-by-ID only.** A service imports only
-  its own ports — never another module's adapter. (Enforced by Nx module
-  boundaries; building out of order fails `nx lint`.)
-- **Backend before frontend.** Phase A (schema → contract → repository →
-  service → controller → queue?) closes for a module before Phase B
-  (hooks → screen) opens. Enforced by the CI phase gate.
-- **Sequential within a phase.** A step starts only once the previous one
-  compiles and passes tests.
-- **One step = one commit**, in the exact Conventional Commit format from
-  `hedgehog-loop`. A commit that fails typecheck/lint/test does not happen
-  (lefthook gate).
-- **Fix wrong steps at the source** via the Correction Protocol — never a
-  downstream workaround.
-- **Local Postgres always runs through `docker-compose.yml`**, on every
-  host OS, regardless of add-ons; Redis joins it only if the Queue add-on
-  is on. Never a natively-installed Postgres or Redis, even to match a
-  contributor's existing local setup.
-- **`packages/config` is the single source** for shared config. A per-app
-  override request means fix the base config, not add an override.
+{{CORE_SECTION}}
 
 ## Consuming TODO.md
 
-`TODO.md` at repo root is a thin checklist mirroring the phase/step
-structure. To work from it:
+`TODO.md` at repo root is a thin checklist mirroring this core's phase/
+step structure. To work from it:
 
 1. Read it. Find the first unchecked step whose gate (the step before it)
    is satisfied.
-2. Confirm the phase: a module with a `feat(<module>): api` commit is in
-   Phase B; otherwise Phase A.
-3. Build that one step via `hedgehog-loop`.
-4. Check the line off after the commit lands. Checked/unchecked is the
+2. Build that one step via this core's loop skill (named in the section
+   above).
+3. Check the line off after the commit lands. Checked/unchecked is the
    only state — no notes, no rationale (that's the commit log's job).
 
-`planner` owns writing and extending `TODO.md`; the loop only checks boxes
-off. Keep it thin.
+`planner` owns writing and extending `TODO.md`; the loop only checks
+boxes off. Keep it thin.
 
-**When the build is done:** once every module in scope has both phases
-checked, the build session is complete. **Delete `TODO.md`** — a finished
-checklist is noise, and the commit log is the durable record of what was
-built. **`.hedgehog/BMAD/` stays** — it's the archival planning record,
-not a checklist.
+**When the build is done:** once every item in scope is checked, the
+build session is complete. **Delete `TODO.md`** — a finished checklist is
+noise, and the commit log is the durable record of what was built. Any
+archival planning-intake output this core produces stays — it's
+historical record, not a checklist.
 
 ## Managing context
 
 Hedgehog is designed so the conversation is disposable. Keep the working
 context small:
 
-- **Clear context at module boundaries.** After a module's Phase A (or a
-  whole module) is done and committed, `/clear` and start fresh — re-read
-  `TODO.md` and continue. Nothing is lost, because the checklist, commits,
-  and code hold all the state. Prefer this over letting one session
-  accumulate the entire project.
+- **Clear context at natural boundaries** — a module's Phase A, a
+  landing page section, whatever this core's own unit boundary is — once
+  that unit is done and committed. `/clear` and start fresh, then
+  re-read `TODO.md` and continue. Nothing is lost, because the
+  checklist, commits, and code hold all the state. Prefer this over
+  letting one session accumulate the entire project.
 - **A cleared or new session recovers by reading `TODO.md` and the
-  commit log**, never by needing the prior conversation. `.hedgehog/BMAD/`
-  is available if the product narrative itself needs re-reading, but
-  day-to-day recovery doesn't need it.
-- **Delegate heavy work to agents.** The project scaffold (`bootstrap`),
-  planning intake (`planner`), every Phase A step (`backend-eng`), every
-  Phase B step (`front-end-eng`), and reviews (`reviewer`) each run in
-  their own isolated context — so that work doesn't pile up in the main
-  thread.
+  commit log**, never by needing the prior conversation.
+- **Delegate heavy work to agents.** Planning intake, scaffolding, and
+  every build step each run in their own isolated context — so that work
+  doesn't pile up in the main thread.
 - **Don't paste large context back in.** If you find yourself
   re-explaining the architecture, stop — it's fixed and stated in this
-  file, not something to reconstruct. If you need a project specific, read
-  it from the code. That's the self-documenting design working as
-  intended.
+  file's core section, not something to reconstruct. If you need a
+  project specific, read it from the code. That's the self-documenting
+  design working as intended.

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

@@ -0,0 +1,46 @@
+## Add-ons
+
+<!-- Written by planner at planning intake. Each line: on/off + the
+one-line reason. An absent block reads as "never decided," not "off". -->
+
+- Auth: (fill in: on/off — reason)
+- Queue: (fill in: on/off — reason)
+- Mobile: (fill in: on/off — reason)
+ 
+## Bootstrap
+
+<!-- Add-on steps (planner marks each on/skipped at planning intake, per
+the ## Add-ons block above) run live, one at a time, after core. A
+skipped add-on gets checked off as skipped, not left unchecked. -->
+
+- [x] Nx workspace + `packages/config` (incl. `docker-compose.yml` for local Postgres) — core, landed via `hedgehog init`, verified via `hedgehog-bootstrap-full-stack-app-core`
+- [x] `packages/db` — Drizzle client — core, landed via `hedgehog init`, verified via `hedgehog-bootstrap-full-stack-app-core`
+- [x] `apps/api` — Nest shell, Pino — core, landed via `hedgehog init`, verified via `hedgehog-bootstrap-full-stack-app-core`
+- [x] `apps/web` — Next shell, TanStack Query provider — core, landed via `hedgehog init`, verified via `hedgehog-bootstrap-full-stack-app-core`
+- [ ] `packages/auth` — Better Auth config + global guard on `apps/api` — Auth add-on (fill in: on / skipped, not in scope)
+- [ ] `apps/worker` — BullMQ seam, Redis (no consumers yet) — Queue add-on (fill in: on / skipped, not in scope)
+- [ ] `apps/mobile` — Expo shell — Mobile add-on (fill in: on / skipped, not in scope)
+## Phase A — Backend
+ 
+<!-- One subsection per module in scope. Do not add hooks/screens here —
+that's Phase B, and doesn't start until every module below is checked. -->
+ 
+### <module-name>
+ 
+- [ ] schema
+- [ ] contract
+- [ ] repository
+- [ ] service
+- [ ] api (controller)
+- [ ] queue (only if this operation genuinely needs async)
+## Phase B — Frontend
+ 
+<!-- Do not touch this section until every module above has "api" checked. -->
+ 
+### <module-name>
+ 
+- [ ] hooks
+- [ ] ux-planner — writes docs/design/<module-name>.md; ask for a
+      mockup/screenshot/Stitch or Figma export here if one exists
+- [ ] screen-web
+- [ ] screen-mobile (only if building for mobile)

package/src/templates/TODO.core.landing-page.md

@@ -0,0 +1,24 @@
+## Brief
+
+<!-- Written by planner at planning intake: the subject statement,
+audience, and the page's single job — full detail in
+.hedgehog/chain/00-brief.md. -->
+
+- Subject: (fill in)
+- Audience: (fill in)
+- Page job: (fill in)
+
+## Bootstrap
+
+- [x] Astro workspace + Tailwind token layer — core, landed via `hedgehog init`, verified via `hedgehog-bootstrap-landing-page-core`
+
+## Chain
+
+<!-- The Chain Method, one phase at a time, in strict order except where
+noted. Do not start a phase until the one above it is checked. -->
+
+- [ ] strategy — subject/audience/job + awareness/sophistication diagnosis + narrative arc + objection map + adjective pairs + visceral/behavioral/reflective sort + note timing — `landing-strategist`
+- [ ] systems — dial table + voice spec (parallel) → token system → signature motif — `landing-systems`
+- [ ] sequence — per-section transitions, weight, spacing, beat structure — `landing-sequencer`
+- [ ] audit — traceability/distinctiveness + usability, reconciled to a pass — `landing-critic`
+- [ ] build — the artifact, in Astro — `landing-builder`

package/src/templates/TODO.md

@@ -1,56 +1,12 @@
 # TODO
  
-<!-- 2-3 sentences: what is this project. Full product narrative, scope
-boundary, and domain vocabulary live in .hedgehog/BMAD/04-prd.md — every
-project has one, written by planner from BMAD-METHOD's planning shelf. -->
+<!-- 2-3 sentences: what is this project. Full detail lives in this
+core's own archival planning-intake output — see CLAUDE.md's core
+section for where. -->
  
 ## Context
  
-(fill in per project — see .hedgehog/BMAD/04-prd.md for the full picture)
+(fill in per project — see this core's archival planning output for the
+full picture)
 
-## Add-ons
-
-<!-- Written by planner at planning intake. Each line: on/off + the
-one-line reason. An absent block reads as "never decided," not "off". -->
-
-- Auth: (fill in: on/off — reason)
-- Queue: (fill in: on/off — reason)
-- Mobile: (fill in: on/off — reason)
- 
-## Bootstrap
-
-<!-- Add-on steps (planner marks each on/skipped at planning intake, per
-the ## Add-ons block above) run live, one at a time, after core. A
-skipped add-on gets checked off as skipped, not left unchecked. -->
-
-- [x] Nx workspace + `packages/config` (incl. `docker-compose.yml` for local Postgres) — core, landed via `hedgehog init`, verified via `hedgehog-bootstrap-core`
-- [x] `packages/db` — Drizzle client — core, landed via `hedgehog init`, verified via `hedgehog-bootstrap-core`
-- [x] `apps/api` — Nest shell, Pino — core, landed via `hedgehog init`, verified via `hedgehog-bootstrap-core`
-- [x] `apps/web` — Next shell, TanStack Query provider — core, landed via `hedgehog init`, verified via `hedgehog-bootstrap-core`
-- [ ] `packages/auth` — Better Auth config + global guard on `apps/api` — Auth add-on (fill in: on / skipped, not in scope)
-- [ ] `apps/worker` — BullMQ seam, Redis (no consumers yet) — Queue add-on (fill in: on / skipped, not in scope)
-- [ ] `apps/mobile` — Expo shell — Mobile add-on (fill in: on / skipped, not in scope)
-## Phase A — Backend
- 
-<!-- One subsection per module in scope. Do not add hooks/screens here —
-that's Phase B, and doesn't start until every module below is checked. -->
- 
-### <module-name>
- 
-- [ ] schema
-- [ ] contract
-- [ ] repository
-- [ ] service
-- [ ] api (controller)
-- [ ] queue (only if this operation genuinely needs async)
-## Phase B — Frontend
- 
-<!-- Do not touch this section until every module above has "api" checked. -->
- 
-### <module-name>
- 
-- [ ] hooks
-- [ ] ux-planner — writes docs/design/<module-name>.md; ask for a
-      mockup/screenshot/Stitch or Figma export here if one exists
-- [ ] screen-web
-- [ ] screen-mobile (only if building for mobile)
+{{CORE_SECTION}}