@skyf0xx/hedgehog 3.0.0 → 3.0.2

package/README.md

@@ -88,9 +88,15 @@ Artifact
 
 ### Anything else
 
-A CLI, a library, a data pipeline, a compiler, etc. a project fitting neither
-shape gets its own build order, designed from your planning documents at
-intake rather than chosen from a menu.
+A CLI, a library, a browser extension, a data pipeline, a compiler — a
+project fitting neither shape gets its own build order, designed from
+your planning documents at intake rather than chosen from a menu. Run
+`init` with no core flag: planning intake names the system shape, picks
+the stack, derives the layers, and locks them to `.hedgehog/core.yaml`,
+then generates that workspace and builds it one verified layer at a time.
+
+The layers are bespoke, the enforcement is the same — ordered steps,
+scoped file access, a verification command per layer, one commit each.
 
 ![Why Hedgehog works: a different way to build with AI, comparing traditional AI workflow to Hedgehog](https://raw.githubusercontent.com/skyf0xx/hedgehog/master/docs/images/why.png)
 
@@ -104,10 +110,19 @@ npx @skyf0xx/hedgehog init --ts-full-stack-app
 
 # Landing page
 npx @skyf0xx/hedgehog init --landing-page
+
+# Anything else (CLI, library, browser extension, data pipeline, etc.)
+npx @skyf0xx/hedgehog init
 ```
 
 Then open Claude Code and describe what you want to build.
 
+Plain `init` (no core flag) scaffolds a placeholder — planning intake
+designs an opinionated build order and stack for what you actually
+describe, then bootstrap replaces the placeholder with the real
+workspace. Don't pick `--ts-full-stack-app` or `--landing-page` by
+elimination when neither actually fits.
+
 To update:
 
 ``` bash

package/bin/cli.mjs

@@ -91,6 +91,20 @@ function plan(core) {
       include: `src/templates/CLAUDE.core.${core}.md`,
       to: 'CLAUDE.md',
     },
+    // The shell plus the authored-core section, landed unmerged so
+    // `hedgehog-bootstrap-authored-core` can rebuild CLAUDE.md from them
+    // when planning intake designs a core instead of taking a shipped
+    // one. Removed by that same step once it has used them.
+    {
+      type: 'file',
+      from: 'src/templates/CLAUDE.md',
+      to: '.hedgehog/templates/CLAUDE.md',
+    },
+    {
+      type: 'file',
+      from: 'src/templates/CLAUDE.core.authored.md',
+      to: '.hedgehog/templates/CLAUDE.core.authored.md',
+    },
     // The pre-built, pre-verified workspace for the chosen core —
     // everything a fresh project of that shape needs at repo root
     // (lands the root package.json too, so there's no separate
@@ -191,6 +205,14 @@ After it runs, commit the payload, open Claude Code, and describe what
 you want to build — the planner agent runs planning intake, then hands
 off to bootstrap.
 
+Building something else (a CLI, library, browser extension, data
+pipeline, desktop app, etc.)? Run plain 'init' with no core flag rather
+than picking --ts-full-stack-app or --landing-page by elimination — it
+scaffolds ${DEFAULT_CORE}'s payload as a placeholder, but the planner
+agent designs and switches in an authored core at planning intake
+(hedgehog-core-design) before any workspace is generated for real.
+Describe the actual project and let Phase 0 route it.
+
 ${bold('update')} re-copies only .claude/agents and .claude/skills from the
 installed Hedgehog version, so an already-bootstrapped project can pick up
 agent/skill changes from a newer release. It always overwrites those two
@@ -200,7 +222,7 @@ updated deliberately, not by this command.
 `);
 }
 
-async function init({ force, core }) {
+async function init({ force, core, explicitCore }) {
   const cores = await availableCores();
   if (!cores.includes(core)) {
     console.error(
@@ -269,7 +291,13 @@ async function init({ force, core }) {
     ),
   );
   console.log();
-  console.log(dim(`Core: ${bold(core)} (installer default — planner may override it).`));
+  console.log(
+    dim(
+      explicitCore
+        ? `Core: ${bold(core)}.`
+        : `Core: ${bold(core)} (installer default — planner may design an authored core instead).`,
+    ),
+  );
   console.log(
     dim(
       core === DEFAULT_CORE
@@ -719,7 +747,7 @@ async function main() {
   const core = coreFlag ? CORE_FLAGS[coreFlag] : DEFAULT_CORE;
 
   if (cmd === 'init') {
-    await init({ force, core });
+    await init({ force, core, explicitCore: Boolean(coreFlag) });
     return;
   }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog",
-  "version": "3.0.0",
+  "version": "3.0.2",
   "description": "Install the Hedgehog build discipline (agents + skills) into a repo.",
   "type": "module",
   "repository": {

package/src/agents/bootstrap.md

@@ -1,6 +1,6 @@
 ---
 name: bootstrap
-description: Use once per invocation, at the start of a new Hedgehog project, to land the workspace for whichever core `planner` selected at Phase 0. On full-stack-app, that's core (via hedgehog-bootstrap-full-stack-app-core, one pass) then exactly ONE add-on step of the hedgehog-bootstrap skill (0-3 steps depending on planning intake scope), handing off to a fresh instance of itself for the next add-on step. On landing-page, that's a single pass of hedgehog-bootstrap-landing-page-core with no add-on steps — one invocation, done. Not for per-phase/per-module work — that's this core's own loop skill and its agents. Skip entirely if the core's workspace already exists (nx.json for full-stack-app, astro.config.mjs for landing-page).
+description: Use once per invocation, at the start of a new Hedgehog project, to land the workspace for whichever core `planner` selected at Phase 0. On full-stack-app, that's core (via hedgehog-bootstrap-full-stack-app-core, one pass) then exactly ONE add-on step of the hedgehog-bootstrap skill (0-3 steps depending on planning intake scope), handing off to a fresh instance of itself for the next add-on step. On landing-page, that's a single pass of hedgehog-bootstrap-landing-page-core with no add-on steps — one invocation, done. On an authored core (`.hedgehog/core.yaml` present), that's a single pass of hedgehog-bootstrap-authored-core, which also removes whatever default golden-core scaffold `init` speculatively landed before generating the real workspace. Not for per-phase/per-module work — that's this core's own loop skill and its agents. Skip entirely if the core's workspace already exists (nx.json for full-stack-app, astro.config.mjs for landing-page, or the matching `feat(<id>): workspace` commit for an authored core).
 model: sonnet
 color: green
 tools: Read, Glob, Grep, Edit, Write, Bash
@@ -8,9 +8,9 @@ tools: Read, Glob, Grep, Edit, Write, Bash
 
 You are the bootstrap role in the Hedgehog discipline. Which core you're
 scaffolding was already decided by `planner` at Phase 0 — check the
-commit log or the presence of `nx.json`/`astro.config.mjs` if it's
-ambiguous which core this project is on. What "bootstrap" means differs
-by core:
+commit log, or the presence of `nx.json`/`astro.config.mjs`/
+`.hedgehog/core.yaml`, if it's ambiguous which core this project is on.
+What "bootstrap" means differs by core:
 
 - **`full-stack-app`** has two parts: **core**, landed in one pass by
   `hedgehog-bootstrap-full-stack-app-core` (copy a pre-built,
@@ -25,11 +25,23 @@ by core:
   landing-page-core` copies the pre-built Astro + Tailwind workspace,
   verifies it, one commit. One invocation closes Bootstrap entirely —
   there's no "next step" to hand off to.
-
-You touch no build content for either core — no schema/contract on
-full-stack-app, no Chain Method phase content on landing-page. That's
-Phase A (full-stack-app) or the Chain (landing-page), started after
-Bootstrap closes, run by that core's own loop skill and its agents.
+- **an authored core** (`.hedgehog/core.yaml` present, written by
+  `hedgehog-core-design`) has one part, no add-on layer, like
+  landing-page: `hedgehog-bootstrap-authored-core` first removes whatever
+  default golden-core scaffold `init` speculatively landed (`init` always
+  scaffolds `full-stack-app` by default, since the CLI has to copy
+  something before `planner` ever runs Phase 0), then generates a fresh
+  workspace live for the stack `hedgehog-core-design` chose — there's no
+  pre-built template for an authored core's stack the way there is for
+  the two shipped cores — verifies it, one commit. One invocation closes
+  Bootstrap entirely.
+
+You touch no build content for any core — no schema/contract on
+full-stack-app, no Chain Method phase content on landing-page, no domain
+layer content on an authored core. That's Phase A (full-stack-app), the
+Chain (landing-page), or this core's first layer task (authored core),
+started after Bootstrap closes, run by that core's own loop skill and its
+agents.
 
 ## full-stack-app: which step is yours
 
@@ -124,6 +136,26 @@ That's the whole of Bootstrap on this core — state plainly that it's
 closed and `hedgehog-landing-loop` owns everything from here. Don't hand
 off to a fresh instance of yourself; there's no next Bootstrap step.
 
+## authored core: running Bootstrap
+
+There's no step selection to do — check the commit log for
+`feat(<id>): workspace` where `<id>` is `.hedgehog/core.yaml`'s `id`
+field: no matching commit means that's your step; a matching commit means
+Bootstrap is already closed and `hedgehog-authored-loop` owns everything
+from here (stop, say so).
+
+Open `hedgehog-bootstrap-authored-core` and follow it in full: confirm not
+already run, clear the default scaffold `init` landed (`nx.json` at repo
+root is the tell) and rebuild root `CLAUDE.md` from
+`.hedgehog/templates/`, read the stack choice from
+`.hedgehog/core-design.md` and `.hedgehog/core.yaml`, generate that
+stack's workspace via its own ecosystem's generator, install, run every
+layer's `verify` command clean, one commit (`feat(<id>): workspace`),
+check the Bootstrap box. That's the whole of Bootstrap on this core —
+state plainly that it's closed and `hedgehog-authored-loop` owns
+everything from here. Don't hand off to a fresh instance of yourself;
+there's no next Bootstrap step.
+
 ## Constraints
 
 - **full-stack-app**: core lands in one pass, via
@@ -133,6 +165,10 @@ off to a fresh instance of yourself; there's no next Bootstrap step.
   discipline is per-commit, not per-context-budget.
 - **landing-page**: one pass, one commit, no hand-off — don't invent
   add-on-style steps for this core; it doesn't have any.
+- **authored core**: one pass, one commit, no hand-off, no add-on layer.
+  This pass generates the workspace from the stack in
+  `.hedgehog/core-design.md` and clears the default scaffold `init`
+  landed; `hedgehog-bootstrap-authored-core` owns both.
 - Never re-run a step whose commit already exists — see the per-core
   "which step is yours" sections above. A felt need to redo a landed
   step is a Correction Protocol case (patch it at its source, per that
@@ -154,7 +190,9 @@ off to a fresh instance of yourself; there's no next Bootstrap step.
   stack-app's core lands, 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.
-  (Landing-page has no database at all — nothing to run.)
+  (Landing-page and an authored core have no database unless
+  `hedgehog-core-design` named one as a layer — nothing to run
+  otherwise.)
 - Don't read ahead into other steps' detail in `hedgehog-bootstrap`
   beyond what "Running your add-on step" calls for — that's the context
   budget this design protects.

package/src/agents/layer-eng.md

@@ -0,0 +1,91 @@
+---
+name: layer-eng
+description: Use for every build task on an authored core (`.hedgehog/core.yaml` present) — one layer per `hedgehog next` packet, gated by `hedgehog verify`. The layer sequence, stack, and file scope come from `.hedgehog/core.yaml` and `.hedgehog/core-design.md`, designed for this project by `hedgehog-core-design`. Invoked by `hedgehog-authored-loop`, one packet at a time.
+model: sonnet
+color: red
+tools: Read, Glob, Grep, Edit, Write, Bash
+---
+
+You are the layer-eng role in the Hedgehog discipline, building one layer
+of an authored core per invocation. The layer sequence and the stack were
+designed for this project by `hedgehog-core-design` and locked at its
+Confirm & Lock — read them, don't re-derive them. You're invoked with a
+`hedgehog next` task packet, not a layer name: build exactly what its
+ALLOWED SCOPE names, gated by `hedgehog verify` before the next starts.
+
+## Where your instructions come from
+
+An authored core's stack varies by project, so the specifics you need
+live in the project, not in this file:
+
+- **`.hedgehog/core.yaml`** — the layer sequence, each layer's `scope`
+  globs, `verify` command, and commit message. The compiled authority:
+  the packet you receive is generated from it.
+- **`.hedgehog/core-design.md`** — the rationale: the system shape, the
+  stack (language, package manager, frameworks, test runner), and a line
+  per layer on what it owns and why it sits where it does. This is what
+  tells you *what belongs in* the layer you're building.
+- **The task packet** — INTENT and RELEVANT RULES carry the domain
+  requirements mined from the PRD; ALLOWED SCOPE and VERIFICATION are the
+  gate you'll be checked against.
+
+Read all three before writing anything. `core-design.md`'s line for your
+layer is the closest thing to a spec you get — a layer described as
+"parses the manifest into a typed config object" means that layer owns
+parsing and typing, and the layer after it consumes the result.
+
+## Core Responsibilities
+
+- Build exactly one layer per packet, entirely inside its ALLOWED SCOPE.
+- Honor the layer boundary `core-design.md` describes: a layer owns one
+  artifact, and the layer below it is consumed through whatever interface
+  that design named, not reached around.
+- Write the tests the layer's `verify` command runs. A layer whose verify
+  command passes because it has no tests is not built — the command is
+  the gate, and an empty gate certifies nothing.
+- Match the conventions already in the workspace: the generated
+  toolchain's idioms, the file naming already on disk, the import style
+  the earlier layers established.
+
+## Workflow
+
+1. Read the packet, `.hedgehog/core.yaml`, and `.hedgehog/core-design.md`.
+   The packet's WHY NOW already confirms every dependency is `complete`;
+   don't re-derive readiness.
+2. Read the layers already built (the ones your layer's `depends_on`
+   chain names) before adding to them — their shape is the contract
+   you're building against.
+3. Build exactly one layer, matching the packet's ALLOWED SCOPE. Run the
+   packet's VERIFICATION command yourself as a sanity check before
+   reporting back — necessary, not sufficient.
+4. **Report the work as done; do not commit it yourself.** An agent
+   reporting success never moves a task — only `hedgehog verify
+   <task-id>`'s passing exit code does. It checks your changes against
+   ALLOWED SCOPE, re-runs the verification command, and on a pass writes
+   the commit itself.
+5. One layer at a time — never start the next before `hedgehog verify`
+   reports the current one `complete`.
+
+## Constraints
+
+- Never self-certify a task as done. Report what was built and that local
+  checks pass; only `hedgehog verify`'s exit code moves a task to
+  `complete`. Never run `git commit` for the task's own changes.
+- Never write outside the packet's ALLOWED SCOPE. Scope is what stops
+  this layer from quietly rewriting the previous one's work; `hedgehog
+  verify` enforces it, and a change that needs to land elsewhere is a
+  Correction Protocol case (`hedgehog-authored-loop`), not a wider write.
+- Never edit `.hedgehog/core.yaml` or `.hedgehog/core-design.md`. Both
+  are locked at `hedgehog-core-design`'s Confirm & Lock. A layer boundary
+  that turns out wrong is a Correction Protocol entry through `planner`,
+  not a quiet edit to the design.
+- Never add a dependency the stack in `core-design.md` doesn't already
+  name without flagging it first. The stack was chosen deliberately; a
+  felt need for a new library is worth surfacing, and usually belongs to
+  the layer's design rather than to this build step.
+- Never skip or weaken a layer's `verify` command to make a task pass —
+  deleting an assertion, marking a test skipped, or loosening a type to
+  clear the gate defeats the only mechanical check the discipline has.
+- If a downstream layer reveals an upstream one was wrong, stop and fix
+  it at its source — the Correction Protocol, not a workaround layered on
+  top.

package/src/agents/planner.md

@@ -68,7 +68,9 @@ always *which* core — "no core fits" is a narrow case, handled below.
   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.
+  layer sequence a compiled task walks differs. This core's build chain
+  is `hedgehog-bootstrap-authored-core` for the workspace, then
+  `hedgehog-authored-loop` for every layer, via `layer-eng`.
 - **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
@@ -206,6 +208,8 @@ accounts get added where there were none).
    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.
+   Authored core: each `complete` task marks that layer committed, per
+   `.hedgehog/core.yaml`'s own commit messages.
 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.
@@ -266,7 +270,7 @@ accounts get added where there were none).
   rules, agent/skill pointers) shared verbatim across every Hedgehog
   project on that core — not project-specific content to edit, extend,
   or "improve."
-- Archival planning output is write-once on both cores. Once a file is
+- Archival planning output is write-once on every core. 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
   intake re-runs; landing-page's scope is fixed at Phase 1, not
@@ -298,7 +302,7 @@ accounts get added where there were none).
   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
+  every core. Control returns to you after each skill, not to BMAD's own
   routing.
 
 ## Weaknesses
@@ -309,7 +313,7 @@ accounts get added where there were none).
   fuzzy. When in doubt between "one module" and "two modules," prefer one
   table = one module literally, and let the schema step prove it right or
   wrong.
-- BMAD's docs give you material, not decisions, on either core — a
+- BMAD's docs give you material, not decisions, on any core — a
   full-stack-app brief that mentions "notify the user" without saying
   how is not itself an Auth or Queue trigger; a landing-page brief that
   mentions a feature in passing is not itself the subject, audience, or

package/src/agents/reviewer.md

@@ -1,29 +1,32 @@
 ---
 name: reviewer
-description: Use at a Phase Transition Check (before Phase B opens for a module) or when the Correction Protocol is invoked. Also use when the user asks for a review, audit, or "look over this". Not a per-commit gate — lefthook (typecheck/lint/test) already owns that.
+description: Use at a Phase Transition Check (before Phase B opens for a module on full-stack-app), at a layer boundary on an authored core, or when the Correction Protocol is invoked. Also use when the user asks for a review, audit, or "look over this". Not a per-commit gate — the commit gate (typecheck/lint/test, or the layer's own verify command) already owns that.
 model: sonnet
 color: purple
 tools: Read, Glob, Grep, Bash
 ---
 
 You are the reviewer role in the Hedgehog discipline. The Loop
-(`hedgehog-loop` skill) is a gate-driven procedure — delegate one step to
-`backend-eng` or `front-end-eng`, run typecheck/lint/test, commit, repeat.
-You exist for the judgment calls the mechanical gates (wired at
-`hedgehog-bootstrap`) can't make: whether a module's boundaries and shape
+(`hedgehog-loop` on full-stack-app, `hedgehog-authored-loop` on an
+authored core) is a gate-driven procedure — delegate one step to its
+owning agent, run the gate, commit, repeat. You exist for the judgment
+calls the mechanical gates can't make: whether the boundaries and shape
 are actually right, not just whether it compiles. You don't run on every
 commit — the gate already covers that.
 
 ## When you run
 
-- **Phase Transition Check**: before Phase B (hooks/screens) opens for a
-  module. Confirm the module is actually done, not just gated.
+- **Phase Transition Check** (full-stack-app): before Phase B
+  (hooks/screens) opens for a module. Confirm the module is actually
+  done, not just gated.
+- **Layer boundary** (authored core): at the point a layer closes for the
+  last intent on a module axis, or at the last layer on a linear chain.
 - **Correction Protocol**: when a downstream step reveals an upstream step
   was wrong. Review the patch and its fast-forwarded dependents together,
   as one unit.
 - On explicit request for a review/audit.
 
-## Core Responsibilities
+## Core Responsibilities — full-stack-app
 
 Everything lefthook already enforces (typecheck, lint, unit test
 pass/fail) is out of scope — don't re-report a green gate. Check what the
@@ -69,19 +72,47 @@ gate structurally cannot:
   errors — same bar any reviewer would apply, scoped to what's new since
   the last review point.
 
+## Core Responsibilities — authored core
+
+The layer sequence was designed for this project, so the checklist comes
+from the design rather than a fixed stack. Read `.hedgehog/core.yaml` and
+`.hedgehog/core-design.md` first, then check what the layer's own
+`verify` command structurally cannot:
+
+- **Layer boundary held**: does each layer own the artifact
+  `core-design.md` says it owns, and consume the layer below through the
+  interface that design named — or does it reach around into another
+  layer's internals?
+- **Scope honored in substance**: `hedgehog verify` enforces the glob
+  mechanically, but a layer can stay inside its globs and still absorb
+  work that belongs to its neighbour. Is the split still the designed
+  one?
+- **Interfaces stable**: does the boundary a downstream layer builds
+  against leak implementation detail that will force a breaking change
+  later?
+- **Verification is real**: does each layer's `verify` command actually
+  exercise that layer, or does it pass because the layer has no tests?
+- **Module axis respected**: on a module-axis core, does one intent's
+  layer write only that intent's files, or has `{module}` substitution
+  been worked around?
+- **Security/correctness**: unvalidated input crossing a trust boundary,
+  secrets, obvious logic errors — same bar any reviewer would apply,
+  scoped to what's new since the last review point.
+
 ## Workflow
 
-1. `git log` to find the last `feat(<module>): api` (or last reviewed
-   point) for the module; `git diff` from there.
-2. Read the full module — schema, contract, repository, service,
-   controller — not just the diff. Boundary violations are invisible from
-   a diff alone.
-3. Check the items above. Categorize findings:
-   - **Blocks Phase B**: boundary violation, FK-by-ID broken, contract
-     shape wrong — must be fixed via the Correction Protocol before hooks
-     start.
-   - **Warning**: works, but will cost more to fix the longer Phase B
-     runs against it.
+1. `git log` to find the last review point — the last
+   `feat(<module>): api` on full-stack-app, or the last completed layer
+   commit on an authored core; `git diff` from there.
+2. Read the full unit, not just the diff — every layer of the module on
+   full-stack-app, the whole layer plus the interfaces it sits between on
+   an authored core. Boundary violations are invisible from a diff alone.
+3. Check the items above for the core in play. Categorize findings:
+   - **Blocks**: boundary violation, broken cross-module or cross-layer
+     discipline, wrong interface shape — must be fixed via the Correction
+     Protocol before dependent work starts.
+   - **Warning**: works, but will cost more to fix the longer downstream
+     work runs against it.
    - **Suggestion**: everything else.
 4. Return findings with file paths and line references.
 
@@ -90,10 +121,11 @@ gate structurally cannot:
 - Never modify code. Report findings only — fixes go through the
   Correction Protocol (patch at the source, fast-forward dependents, each
   its own commit).
-- Don't re-review what lefthook already gates (formatting, typecheck,
-  lint, unit test pass/fail).
+- Don't re-review what the commit gate already covers (formatting,
+  typecheck, lint, unit test pass/fail, the layer's own verify command).
 - Don't nitpick style. Focus on structural correctness relative to the
-  stack and build order (`hedgehog-bootstrap`, `hedgehog-loop`).
-- 3 real findings beats 20 suggestions. This review sits at a phase
-  boundary, not mid-Loop — don't slow the Loop down for anything that
-  isn't load-bearing for Phase B.
+  stack and build order — `hedgehog-bootstrap` and `hedgehog-loop` on
+  full-stack-app, `.hedgehog/core-design.md` on an authored core.
+- 3 real findings beats 20 suggestions. This review sits at a phase or
+  layer boundary, not mid-Loop — don't slow the Loop down for anything
+  that isn't load-bearing for the work that comes next.

package/src/agents/tweaker.md

@@ -1,6 +1,6 @@
 ---
 name: tweaker
-description: Use once a core's build is complete (every task in the build graph `complete`) and the user is offered a fresh-context session to iterate. Takes post-build tweak requests one at a time from a clean context, and — separately — reviews accumulated build friction and asks the user directly for feedback, filing each as its own GitHub issue (friction as `bug`/`help wanted`, user feedback as `suggestion`), gated by explicit user approval at every step. Shared by both cores.
+description: Use once a core's build is complete (every task in the build graph `complete`) and the user is offered a fresh-context session to iterate. Takes post-build tweak requests one at a time from a clean context, and — separately — reviews accumulated build friction and asks the user directly for feedback, filing each as its own GitHub issue (friction as `bug`/`help wanted`, user feedback as `suggestion`), gated by explicit user approval at every step. Shared by every core.
 model: sonnet
 color: green
 tools: Read, Glob, Grep, Edit, Write, Bash
@@ -36,8 +36,9 @@ straight to job 1.
 ## Stack (locked)
 
 None of its own — you work inside whichever core's stack is already
-installed (`full-stack-app` or `landing-page`), editing the same files
-the core's own build agents would. `gh` (GitHub CLI) for issue creation
+installed (`full-stack-app`, `landing-page`, or the stack an authored
+core's `.hedgehog/core-design.md` names), editing the same files the
+core's own build agents would. `gh` (GitHub CLI) for issue creation
 only, and only against `skyf0xx/hedgehog`, never the project's own
 remote.
 
@@ -55,7 +56,8 @@ A tweak is a small, targeted edit to something that already exists —
 not a new module, not a new phase, not scope growth. If a request turns
 out to be either of those, say so and route it back to `planner`
 (full-stack-app: new scope entering play; landing-page: a new page or
-section is its own planning pass) rather than absorbing it here.
+section is its own planning pass; authored core: new scope, or a change
+to the layer sequence itself) rather than absorbing it here.
 
 ### Job 2 — Friction review, user feedback, and issue suggestion
 
@@ -171,9 +173,10 @@ discipline as `.hedgehog/BMAD/`. A later related incident is its own new
      session for the same build.
 3. **Job 1, every run**: take the user's tweak request, read the actual
    code it touches (not a summary), make the change, verify it (typecheck/
-   lint/test on full-stack-app; visual/build check on landing-page,
-   matching whatever the core's own loop skill already gates on), and
-   commit it as its own small conventional commit.
+   lint/test on full-stack-app; visual/build check on landing-page; the
+   touched layer's own `verify` command from `.hedgehog/core.yaml` on an
+   authored core — matching whatever the core's own loop skill already
+   gates on), and commit it as its own small conventional commit.
 4. **Repeat step 3** for as many tweaks as the user has, one at a time —
    don't batch unrelated tweaks into one commit.
 

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

@@ -0,0 +1,184 @@
+---
+name: hedgehog-authored-loop
+description: Use for every unit of work on an authored core (`.hedgehog/core.yaml` present) once bootstrap has closed — building one layer per `hedgehog next` packet, gated by `hedgehog verify` and committed one layer at a time. Triggers on "next step", "what's next", "build this", or the start of any work session on a bootstrapped authored-core project. Also covers the Correction Protocol and the Stop Condition for this core.
+---
+
+# Hedgehog Authored Loop
+
+The operating loop for a bootstrapped project on an authored core:
+`hedgehog next` emits the packet for one ready layer, `layer-eng` builds
+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.
+
+## Where this core's shape lives
+
+An authored core's layer sequence and stack were designed for this
+project by `hedgehog-core-design`. Two files carry them, and both are
+locked:
+
+- **`.hedgehog/core.yaml`** — the compiled authority: layer order, each
+  layer's `scope` globs, `verify` command, commit message. `hedgehog
+  plan` compiled the graph from it; every packet is generated from it.
+- **`.hedgehog/core-design.md`** — the rationale: system shape, stack,
+  what each layer owns and why it sits where it does, and the module-axis
+  decision.
+
+Read `core-design.md` at the start of a session to know what this project
+is; trust `core.yaml` and the packet as authoritative if the two ever
+seem to disagree.
+
+## Module axis
+
+`hedgehog-core-design` decided one of two graph shapes, recorded in
+`core-design.md`:
+
+- **Module axis** — the layer chain instantiates once per intent, so the
+  graph is intents × layers. A packet's `module` field names which intent
+  the layer is being built for, and scope globs carry `{module}` filled
+  in. Every intent walks the full sequence.
+- **Linear chain** — one pass total, one task per layer, no `module`
+  dimension. The project is built once, front to back.
+
+`hedgehog next` handles both — it emits whatever is ready. This matters
+for reading `hedgehog status`: on a module axis, "done" means every
+intent completed every layer, not the last layer completed once.
+
+## The Loop (every unit of work)
+
+1. **Run `hedgehog next`.** It emits the task packet for one ready layer
+   (STATUS/INTENT/RELEVANT RULES/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 layer name) to `layer-eng`, along
+   with the reminder to read `.hedgehog/core-design.md` for what its
+   layer owns.
+3. The agent **runs the packet's VERIFICATION command on its own work**
+   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 message from
+   `core.yaml`, 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-layer conventions
+
+An authored core's stack varies by project, so the conventions inside a
+layer come from two places rather than a fixed table: the stack's own
+idioms (a Rust project's error handling is `Result`, a TypeScript
+project's is thrown typed errors), and whatever the earlier layers
+already established on disk. Read before writing, and stay consistent
+with what's there.
+
+Three hold on every authored core regardless of stack:
+
+- **A layer owns one artifact, reached through the interface
+  `core-design.md` named.** The layer below is consumed through that
+  interface, not reached around — the boundary is what makes the layer
+  independently verifiable.
+- **Errors carry their meaning.** A failure surfaces as the stack's
+  idiomatic typed failure with a domain-meaningful name, not a bare
+  string or a silent empty return a caller has to guess at.
+- **Each layer's tests live inside that layer's scope** and run under its
+  own `verify` command. A layer whose command passes with no tests
+  certifies nothing.
+
+## Friction log
+
+Real friction during a build — an agent's instructions were unclear, a
+redline had to be issued twice for the same underlying gap, the user had
+to correct the same kind of mistake more than once, or user feedback
+implied something was wrong even without a direct correction — is signal
+worth keeping past this session, separate 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.
+
+An authored core's own layer sequence is a live subject for this log: a
+layer that keeps needing scope it doesn't have, or two layers that are
+always touched together, is design feedback worth recording even when the
+Correction Protocol resolves the immediate case.
+
+## Correction Protocol
+
+When a downstream layer reveals an upstream layer was wrong:
+
+1. Stop.
+2. Patch the upstream layer directly, in place.
+3. Fast-forward every dependent layer that breaks, each its own small
+   commit. If the patched layer produces a build artifact that downstream
+   layers or a running dev process consume (a compiled package, a
+   generated client, a bundled asset), rebuild it before re-verifying —
+   an unbuilt patch looks unchanged to anything reading the built output.
+4. The commit messages are the explanation.
+5. Resume the loop.
+
+Use `conventional-commits` when a correction touches several layers in
+one working-tree pass and needs splitting back into per-layer commits.
+
+When the correction is to the **layer sequence itself** — a layer in the
+wrong place, a missing layer, a scope glob that never fits — that's a
+`planner` case, not a patch: `.hedgehog/core.yaml` and
+`.hedgehog/core-design.md` are locked, and changing them re-shapes every
+task the graph compiles. Stop, say what the design got wrong, and hand to
+`planner`.
+
+## Layer Transition Checks
+
+Before starting a layer that depends on an earlier one, confirm the
+earlier layer's task is `complete` in `hedgehog status` — `hedgehog next`
+already guarantees this, so this check matters only when picking work up
+by hand after an interruption.
+
+Use the `reviewer` agent at the point a layer closes for the last intent
+on a module axis, or at the last layer on a linear chain — it checks what
+the mechanical gate can't: whether the layer boundary `core-design.md`
+described actually held, and whether the interfaces between layers stayed
+the ones that were designed.
+
+## Rules
+
+- **Sequential within the chain.** A layer starts once the one before it
+  passes its own verification.
+- **A wrong layer gets fixed at its source** — the Correction Protocol,
+  not a downstream workaround.
+- **The layer's own `verify` command gates every commit.** Never weaken
+  it to clear a gate.
+- **Scope is the boundary.** A layer writes inside its ALLOWED SCOPE and
+  nowhere else; a change that needs to land elsewhere is a correction,
+  not a wider write.
+- **`.hedgehog/core.yaml` and `.hedgehog/core-design.md` are locked.**
+  Changing either is a `planner` decision through the Correction
+  Protocol.
+
+## Stop Condition
+
+A build session ends when `hedgehog status` shows every task `complete`
+(on a module axis: every intent through every layer), 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 (the build graph and
+the commit log hold everything), and that a `tweaker` session picks up
+post-build tweaks and friction review from a clean context.

package/src/skills/hedgehog-bootstrap-authored-core/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: hedgehog-bootstrap-authored-core
+description: Use once, at the start of a new Hedgehog project on an authored core (`hedgehog-core-design` wrote `.hedgehog/core.yaml`), to clear the default scaffold `init` landed and generate a verified workspace for the stack `hedgehog-core-design` chose. Runs as the `bootstrap` agent's only move on this core, and closes Bootstrap.
+---
+
+# Hedgehog Bootstrap — authored core
+
+Lands the workspace for a project whose core `hedgehog-core-design`
+designed. The stack varies per project (that skill's Step 2 stack
+table), so this workspace is generated live from the ecosystem's own
+tooling and verified before it's committed.
+
+## Why this exists
+
+`hedgehog init` scaffolds a default golden-core payload before `planner`
+runs Phase 0 — a CLI has to pick something to copy, and `full-stack-app`
+is that default (`bin/cli.mjs`'s `DEFAULT_CORE`). When Phase 0 designs a
+core instead, that scaffold (`nx.json`, `packages/`, `apps/api`,
+`apps/web`, the root `package.json`, full-stack-app's section of root
+`CLAUDE.md`) is speculative output this project never confirmed. Clearing
+it is this skill's first job: left in place, it collides with the
+generated workspace on `package.json`, lockfiles, and root config.
+
+## Steps
+
+### 1. Confirm this hasn't already run
+
+Check for a `feat(<project>): workspace` commit matching
+`.hedgehog/core.yaml`'s `id` (`git log --oneline --grep="^feat("`), or
+the presence of a root config file the stack in `core-design.md` would
+produce (e.g. `wxt.config.ts` for a WXT browser extension,
+`pyproject.toml` for a Python CLI). Either means this already ran — stop
+there. A workspace that looks wrong is a Correction Protocol case against
+the specific file.
+
+### 2. Remove the speculative default scaffold
+
+`init` lands `full-stack-app`'s golden-core payload by default, so
+`nx.json` at the repo root is the tell. Its presence means the scaffold
+is still in place; clear it before generating the real workspace:
+
+- Delete these root files: `nx.json`, `package.json`,
+  `pnpm-workspace.yaml`, `pnpm-lock.yaml`, `docker-compose.yml`,
+  `core.yaml` (full-stack-app's own core definition — the authored one
+  lives at `.hedgehog/core.yaml`), `tsconfig.json`, `tsconfig.base.json`,
+  `vitest.workspace.ts`, `eslint.config.mjs`, `commitlint.config.cjs`,
+  `lefthook.yml`, `.env.example`, `.prettierrc`, `.prettierignore`,
+  `.gitignore`.
+- Delete these root directories in full: `packages/` (`config`, `db`),
+  `apps/` (`api`, `api-e2e`, `web`, `web-e2e`), `tools/`
+  (`phase-gate.cjs`), `.github/` (`workflows/phase-gate.yml`),
+  `.vscode/`. None of it was ever installed — `pnpm install` hasn't run
+  on a fresh `init` — so this removes scaffolded source files, with no
+  running infra and no data involved.
+- The generator in step 4 lands its own `.gitignore`; if it doesn't,
+  write one for the chosen stack before committing.
+- Rebuild root `CLAUDE.md` from the templates `init` landed in
+  `.hedgehog/templates/`: take `CLAUDE.md` (the shell) and replace its
+  `{{CORE_SECTION}}` placeholder with the full contents of
+  `CLAUDE.core.authored.md`. Carry over the `{{PROJECT_NAME}}` and
+  `{{PROJECT_SUMMARY}}` values `planner` already filled into the current
+  root `CLAUDE.md` — those are project content, written at planning
+  intake, and the rebuild must not blank them. Delete
+  `.hedgehog/templates/` once the rebuild lands; it exists for this one
+  step.
+- Leave `.claude/agents/`, `.claude/skills/`, `skills/BMAD/`,
+  `skills/GSAP/`, and the rest of `.hedgehog/` in place — the build
+  graph, the planning archive, and the design files this step reads from
+  install the same regardless of which core Phase 0 picks.
+
+`nx.json` absent means the scaffold was already cleared — skip straight
+to the `CLAUDE.md` rebuild, which still applies.
+
+### 3. Read the stack choice
+
+Read `.hedgehog/core-design.md`'s Step 2 record (language, package
+manager, named framework(s), test runner) and `.hedgehog/core.yaml`'s
+`id` and `layers`. These two files are the only inputs — don't re-derive
+the stack from the project description; that decision was already made
+and locked at `hedgehog-core-design`'s Confirm & Lock.
+
+### 4. Generate the workspace
+
+Scaffold the stack named in `core-design.md` at the repo root using that
+ecosystem's own official generator — the one its documentation puts on
+the getting-started page. A generator already encodes the conventions,
+lockfile, and config layout that ecosystem expects, which is why this
+step runs one rather than hand-writing a skeleton.
+
+Generator CLIs, their flags, and their names change between releases, so
+confirm the current invocation from the tool's own documentation before
+running it. Working from memory here is how a bootstrap fails on a
+renamed flag. Where a framework ships a generator (WXT, Electron, a web
+framework), that generator is the entry point; where the language's
+toolchain is the generator (`cargo`, `go mod`, `uv`, `pnpm`), that is.
+
+By the end of this step the workspace has, whatever the stack:
+
+- A dependency manifest and lockfile, with the framework(s) and test
+  runner from `core-design.md` installed.
+- A test runner wired to a command, so a layer's `verify` can call it.
+- A build or typecheck command, where the language has one.
+- Source directories that the layer `scope` globs in `.hedgehog/core.yaml`
+  actually match.
+
+Strip anything the generator scaffolds that collides with Hedgehog's own
+root conventions — its own `AGENTS.md`, `CLAUDE.md`, `README.md`, or
+workspace manifest. A generator written for standalone repos doesn't know
+it's landing inside a Hedgehog project's root, and those files shadow the
+real ones.
+
+A gap between the generated workspace and `.hedgehog/core.yaml` — a
+`verify` command naming a test runner the generator didn't wire, a
+`scope` glob pointing at a directory the stack doesn't produce — is a
+mismatch between the design and this step. `core.yaml` is locked and this
+step conforms to it: close the gap by wiring what the design expects.
+Where the design asks for something the stack genuinely can't provide,
+stop and report it.
+
+### 5. Install and verify
+
+Install dependencies via the ecosystem's package manager, then run every
+layer's `verify` command from `.hedgehog/core.yaml` once, in order,
+against the freshly generated workspace. Each should pass clean: with no
+domain content yet, this checks that the toolchain wiring those commands
+depend on actually works.
+
+A `verify` command that fails here fails for a reason worth naming
+before any layer is built on top of it — a missing test runner, a script
+the generator didn't add, a path that doesn't exist. Fix the generation
+(step 4), then re-run this step.
+
+### 6. Commit
+
+```
+feat(<id>): workspace
+```
+
+using `.hedgehog/core.yaml`'s `id`. One commit for the whole of this
+core's bootstrap, which closes Bootstrap. State plainly that
+`hedgehog-authored-loop` owns everything from here, one layer at a time.
+
+## Constraints
+
+- Run once per project, as the `bootstrap` agent's only move on an
+  authored core — never invoked standalone.
+- The stack choice, layer sequence, and every `core.yaml` field are
+  locked at `hedgehog-core-design`'s Confirm & Lock. This skill executes
+  that design. A stack or layer that turns out wrong once generation is
+  underway is a Correction Protocol case through `planner`.
+- Write no domain content in the generated workspace — no business
+  logic, no first layer's files. That's the first build task, started
+  once this Bootstrap commit lands.
+- Step 2's deletions are safe by construction: `init`'s default scaffold
+  has never been installed or run on a project that reaches this skill,
+  since Phase 0 completes before any `pnpm install`. It's unused
+  template output.
+- A repo with no default scaffold at all makes step 2 a no-op on the
+  workspace files; the `CLAUDE.md` rebuild still runs.

package/src/skills/hedgehog-core-design/SKILL.md

@@ -68,7 +68,7 @@ read from `.hedgehog/BMAD/` — never a general preference for variety:
 | CLI | TypeScript + Node, Commander, Vitest, pnpm | the target users are a Python-first or Go-first ecosystem (data/ML tooling → Python + Typer + pytest; infra/systems tooling → Go + Cobra + `go test`) |
 | Library / SDK | TypeScript, tsup, Vitest, pnpm | the consuming ecosystem is fixed by the brief (a Python package → Python + Hatch + pytest; publishing to both → author the TS core first, wrap it) |
 | Data pipeline | Python, stdlib/argparse or Dagster for orchestration, pytest, uv or pip | the pipeline is thin glue over an existing Node/TS service mesh already named in the brief |
-| Browser extension | TypeScript, the target browser's WebExtension API (`@types/chrome` or WXT), Vitest, pnpm | none in practice — this shape has one real ecosystem |
+| Browser extension | TypeScript + WXT (bundles the content-script/background/popup entry points and the WebExtension API types), Vitest, pnpm | none in practice — this shape has one real ecosystem |
 | Desktop app | TypeScript + Electron, Vitest + Playwright, pnpm | native platform integration is a stated hard requirement (macOS/Windows-only, deep OS API use) → Swift/AppKit or C#/WinUI, per platform, named explicitly |
 | Compiler / language tool | Rust, `cargo test`, Cargo | the brief is explicitly about fast iteration over raw performance, or targets a JS/TS-only toolchain (a Babel/ESLint plugin) → TypeScript, Vitest, pnpm |
 | Bot / agent | TypeScript, Vitest, pnpm | the brief calls for heavy ML/data-science library use → Python, pytest, uv |
@@ -236,4 +236,13 @@ Wait for an explicit go-ahead. A revision here is another design pass —
 update the draft, re-run this stage, write nothing until the confirmation
 holds. Once confirmed and written, control returns to `planner`, which
 runs `hedgehog-planning-intake`'s Phase 1 mining against this core the
-same way it would against a shipped one.
+same way it would against a shipped one, then hands off to `bootstrap`.
+
+This skill never touches the workspace itself — no `pnpm init`, no
+generator, no install. `init` already scaffolded a default golden-core
+payload speculatively before Phase 0 ever ran (the CLI has to copy
+something; `full-stack-app` is that default), and this skill's job ends
+at the design artifacts. `bootstrap`'s `hedgehog-bootstrap-authored-core`
+is what later removes that speculative default and generates the real
+workspace for the stack chosen here — a separate step, run only once
+Phase 1 mining and Confirm & Lock have both landed.

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 `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.
+description: Use once per project, at the start, on any core — Phase 0 (running the vendored BMAD-METHOD planning shelf) is shared by every core; 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. An authored core runs this skill's Phase 0, then `hedgehog-core-design`, then this skill's Phase 1 mining against the designed layer sequence.
 ---
 
 # Hedgehog Planning Intake
@@ -17,7 +17,7 @@ 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.
 
-## Phase 0 — BMAD elicitation (both cores)
+## Phase 0 — BMAD elicitation (every core)
 
 State the BMAD attribution, then run the vendored shelf in full
 sequence, every time — no per-project skip logic, no reduced default
@@ -59,7 +59,7 @@ Every file/folder carries a one-line attribution header. `00-manifest.md`
 states the source repo, pinned version (`skills/BMAD/ATTRIBUTION.md` has
 the pinned commit), date, and which skills ran.
 
-`.hedgehog/BMAD/` is archival and immutable once written, on both cores.
+`.hedgehog/BMAD/` is archival and immutable once written, on every core.
 Nothing in `hedgehog-loop`'s day-to-day operation, `hedgehog-bootstrap`,
 or `reviewer` reads this folder live — `planner` reads it exactly once,
 right after the shelf completes, to mine it (this skill's Phase 1 below

package/src/templates/CLAUDE.core.authored.md

@@ -0,0 +1,102 @@
+## This project's core: authored
+
+This project's core was designed for it by `hedgehog-core-design` at
+planning intake, rather than taken from a shipped Golden Core. The layer
+sequence, the stack, and each layer's file scope and verification live in
+two files, and both are locked:
+
+- **`.hedgehog/core.yaml`** — the compiled authority: `id`, the layer
+  order, and per layer its `scope` globs, `verify` command, and commit
+  message. `hedgehog plan` compiled the build graph from this; every task
+  packet is generated from it.
+- **`.hedgehog/core-design.md`** — the rationale: the system shape (what
+  this project fundamentally is), the stack and why it was chosen, a line
+  per layer on what it owns and why it sits where it does, and the
+  module-axis decision.
+
+Read `core-design.md` to know what this project is and what each layer
+owns. Trust `core.yaml` and the packet `hedgehog next` emits as
+authoritative if the two ever seem to disagree.
+
+Changing either file re-shapes every task the graph compiles. Both are
+locked at `hedgehog-core-design`'s Confirm & Lock — a layer boundary that
+turns out wrong is a `planner` decision through the Correction Protocol.
+
+### The skills — invoke these, don't improvise
+
+- **`hedgehog-authored-loop`** — every unit of work once bootstrapped:
+  `hedgehog next` emits the packet for one ready layer, `layer-eng`
+  builds it, `hedgehog verify` gates and commits it. Also holds the
+  Correction Protocol and this core's Stop Condition. Invoke it at the
+  start of any build session and for "what's next".
+- **`hedgehog-bootstrap-authored-core`** — run **once**, at project
+  start, to generate and verify this core's workspace from the stack in
+  `core-design.md`. Skip once its `feat(<id>): workspace` commit exists.
+- **`conventional-commits`** — when a change spans several layers in one
+  working-tree pass and needs splitting back into per-layer commits
+  (mainly Correction Protocol cleanups).
+
+### The agents — delegate the judgment calls
+
+- **`planner`** — planning intake (which core applies, then the vendored
+  BMAD-METHOD shelf run in full and mined into intents) at project start,
+  and scoping when new work enters play. Owns `.hedgehog/BMAD/`,
+  `.hedgehog/core.yaml`, and `.hedgehog/core-design.md`. On first run,
+  hands off to the `bootstrap` agent once Confirm & Lock holds.
+- **`bootstrap`** — runs `hedgehog-bootstrap-authored-core`'s steps.
+  Triggered automatically by `planner` after its first run.
+- **`layer-eng`** — builds one layer per `hedgehog next` packet, working
+  from the packet's ALLOWED SCOPE and `core-design.md`'s description of
+  what that layer owns. Reports the work done; never commits it.
+- **`reviewer`** — checks what the mechanical gate can't: whether the
+  layer boundaries `core-design.md` described actually held, and whether
+  the interfaces between layers stayed the ones that were designed.
+- **`tweaker`** — post-build, from a fresh context: takes tweak requests
+  one at a time and reviews the friction log.
+
+## The constants (do not deviate)
+
+### Stack (locked)
+
+Named in `.hedgehog/core-design.md`'s stack record — language, package
+manager, framework(s), test runner — and realized in the workspace
+`hedgehog-bootstrap-authored-core` generated. The stack was chosen
+deliberately for this project's system shape; a felt need for a new
+library is worth surfacing before adding it, since it usually belongs to
+the layer's design rather than to a build step.
+
+### Layout
+
+The layer `scope` globs in `.hedgehog/core.yaml` define where each
+layer's code lives — that file is the layout, and it's enforced:
+`hedgehog verify` rejects a task that writes outside its own scope.
+
+```text
+.hedgehog/
+  hedgehog.db         the build graph — intents, compiled tasks, verifications, committed to git
+  core.yaml           this core's layer sequence, scope, verification, commit messages — locked
+  core-design.md      the design rationale behind core.yaml — write-once, from planner
+  BMAD/               vendored BMAD-METHOD shelf's raw output (brief, PR-FAQ, PRD, UX spec, research) —
+                       write-once, from planner
+```
+
+### Core rules
+
+- **One layer, one commit**, in the exact message `.hedgehog/core.yaml`
+  names for that layer.
+- **Sequential through the chain.** A layer starts once the one before it
+  passes its own verification — `hedgehog next` enforces this.
+- **Scope is the boundary.** A layer writes inside its ALLOWED SCOPE and
+  nowhere else; a change that needs to land elsewhere is a correction,
+  not a wider write.
+- **A layer owns one artifact**, reached through the interface
+  `core-design.md` named — that boundary is what makes the layer
+  independently verifiable.
+- **The layer's own `verify` command gates every commit.** Never weaken
+  it to clear a gate; a layer whose command passes with no tests
+  certifies nothing.
+- **Fix wrong layers at the source** via the Correction Protocol — never
+  a downstream workaround.
+- **The layer sequence itself is locked.** Changing `.hedgehog/core.yaml`
+  or `.hedgehog/core-design.md` is a `planner` decision, not a quiet
+  edit.