@skyf0xx/hedgehog 3.0.12 → 3.0.14

package/README.md

@@ -55,7 +55,7 @@ The build order is encoded into the project. The AI does not have to remember wh
 Unlike stories and epics, **the graph locks build order** into an **signal-dense, context-light** path the agents can use.
 
 ```bash
-npx @skyf0xx/hedgehog graph
+npx @skyf0xx/hedgehog graph # show graph
 ```
 
 ![The Hedgehog build graph](https://raw.githubusercontent.com/skyf0xx/hedgehog/master/docs/images/graph.png)
@@ -165,7 +165,7 @@ npx @skyf0xx/hedgehog update
 This refreshes the installed agents and skills — for every coding agent
 the project was set up for — along with the `AGENTS.md` index derived
 from them. It never touches the instructions file, the build graph, the
-core workspace, or `skills/BMAD`, since those carry project-specific or
+core workspace, or `vendor-skills/BMAD`, since those carry project-specific or
 write-once content.
 
 ## Why Hedgehog
@@ -200,7 +200,7 @@ The `nx-generate`, `nx-run-tasks`, `nx-workspace`, and
 (`nrwl/nx-ai-agents-config`) MIT-licensed, pinned to commit `9609810`
 (2026-07-23) and rewritten for Hedgehog's pnpm-only workspace convention.
 
-`front-end-eng`'s animation skills (`skills/GSAP/`) are vendored from
+`front-end-eng`'s animation skills (`vendor-skills/GSAP/`) are vendored from
 [gsap-skills](https://github.com/greensock/gsap-skills)
 (`greensock/gsap-skills`) MIT-licensed, pinned to commit `aed9cfd`
 (2026-07-27).

package/bin/cli.mjs

@@ -108,12 +108,12 @@ function plan(core, host = DEFAULT_HOST, { hostOnly = false } = {}) {
     : [
         // The vendored BMAD-METHOD planning shelf that
         // hedgehog-planning-intake runs — referenced by repo-root-relative
-        // path (skills/BMAD/...), so it lands there rather than under a
-        // host's own directory.
-        { type: 'dir', from: 'skills/BMAD', to: 'skills/BMAD' },
+        // path (vendor-skills/BMAD/...), so it lands there rather than under
+        // a host's own directory.
+        { type: 'dir', from: 'vendor-skills/BMAD', to: 'vendor-skills/BMAD' },
         // The vendored GSAP animation skill shelf that front-end-eng loads
         // for motion work — same repo-root-relative referencing.
-        { type: 'dir', from: 'skills/GSAP', to: 'skills/GSAP' },
+        { type: 'dir', from: 'vendor-skills/GSAP', to: 'vendor-skills/GSAP' },
       ];
 
   const base = [...perHost, ...shared];
@@ -157,8 +157,9 @@ function plan(core, host = DEFAULT_HOST, { hostOnly = false } = {}) {
 // this, always overwriting, since a consuming project's installed agents
 // and skills are supposed to match upstream verbatim. The bootstrap file
 // carries project-filled content, the build graph and core workspace are
-// verified once by their own init/bootstrap-core steps, and skills/BMAD
-// and skills/GSAP are re-vendored only deliberately (a manual re-vendor,
+// verified once by their own init/bootstrap-core steps, and
+// vendor-skills/BMAD and vendor-skills/GSAP are re-vendored only
+// deliberately (a manual re-vendor,
 // per each shelf's ATTRIBUTION.md) — none of those belong in an update.
 function updatePlan(host = DEFAULT_HOST) {
   const h = HOSTS[host];
@@ -293,8 +294,9 @@ derived from them) from the installed Hedgehog version, so an
 already-bootstrapped project can pick up changes from a newer release. It
 refreshes every host the project was installed for, always overwriting
 those directories. The instructions file, the build graph, the core
-workspace, and skills/BMAD and skills/GSAP stay as they are — those are
-project-specific or updated deliberately, not by this command.
+workspace, and vendor-skills/BMAD and vendor-skills/GSAP stay as they
+are — those are project-specific or updated deliberately, not by this
+command.
 `);
 }
 
@@ -452,7 +454,7 @@ async function update({ hosts }) {
   console.log(
     dim(
       `${bootstraps}, the build graph, the core workspace, and\n` +
-        'skills/BMAD and skills/GSAP are untouched — those carry\n' +
+        'vendor-skills/BMAD and vendor-skills/GSAP are untouched — those carry\n' +
         'project-specific or write-once content.',
     ),
   );

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog",
-  "version": "3.0.12",
+  "version": "3.0.14",
   "description": "Install the Hedgehog build discipline (agents + skills) into a repo, for Claude Code, Cursor, or Gemini CLI.",
   "type": "module",
   "repository": {
@@ -25,8 +25,8 @@
     "src/skills",
     "src/templates",
     "src/golden-cores",
-    "skills/BMAD",
-    "skills/GSAP"
+    "vendor-skills/BMAD",
+    "vendor-skills/GSAP"
   ],
   "engines": {
     "node": ">=22.5.0"

package/src/agents/backend-eng.md

@@ -31,11 +31,10 @@ gated by `hedgehog verify` before the next starts.
   `controller` layer's packet, verified by that layer's own check.
 - **PostgreSQL** via Docker Compose — never a natively-installed Postgres.
 
-Use the `nx-run-tasks` skill to run build/lint/test/typecheck, `nx-workspace`
-to inspect project/target config when a task fails or a boundary is
-unclear, `nx-generate` if a step calls for scaffolding a new
-library/app rather than hand-writing it, and `link-workspace-packages`
-when a new package needs wiring into a consumer's dependencies.
+Use `nx-run-tasks` (build/lint/test/typecheck), `nx-workspace` (inspecting
+project/target config), `nx-generate` (scaffolding a new library/app), and
+`link-workspace-packages` (wiring a new package into a consumer) as
+needed.
 
 ## Core Responsibilities
 
@@ -87,9 +86,8 @@ when a new package needs wiring into a consumer's dependencies.
 
 ## Constraints
 
-- Never self-certify a task as done. Report what was built and that
-  local checks pass; only `hedgehog verify`'s exit code moves the task to
-  `complete`. Never run `git commit` for the task's own changes.
+- Never self-certify a task as done or run `git commit` for its changes —
+  see Workflow step 3.
 - Never import another module's repository, service, or schema directly
   — cross-module references are FK-by-ID, resolved at the
   contract/controller layer (parallel calls) or via a same-repository

package/src/agents/front-end-eng.md

@@ -29,17 +29,16 @@ exactly what its ALLOWED SCOPE names, one layer at a time, gated by
   you talk to the API. Never call `fetch`/`axios` against `apps/api`
   routes directly.
 
-Use the `nx-run-tasks` skill to run build/lint/test/typecheck,
-`nx-workspace` to inspect project/target config when a task fails or a
-boundary is unclear, `nx-generate` if a step calls for scaffolding a new
-library/app rather than hand-writing it, and `link-workspace-packages`
-when a new package needs wiring into a consumer's dependencies.
+Use `nx-run-tasks` (build/lint/test/typecheck), `nx-workspace` (inspecting
+project/target config), `nx-generate` (scaffolding a new library/app), and
+`link-workspace-packages` (wiring a new package into a consumer) as
+needed.
 
 If the screen step calls for animation or motion — entrances, sequencing,
 scroll-driven effects, drag, SVG/morph effects — use GSAP, loading the
-relevant skill from `skills/GSAP/` (`gsap-core`, `gsap-timeline`,
+relevant skill from `vendor-skills/GSAP/` (`gsap-core`, `gsap-timeline`,
 `gsap-scrolltrigger`, `gsap-plugins`, `gsap-utils`, `gsap-react`,
-`gsap-performance`, `gsap-frameworks`; see `skills/GSAP/llms.txt` for
+`gsap-performance`, `gsap-frameworks`; see `vendor-skills/GSAP/llms.txt` for
 which to load). GSAP is the one animation library in the locked stack —
 don't reach for a second one.
 
@@ -48,14 +47,12 @@ don't reach for a second one.
 - **`hook`**: build the TanStack Query hook in `packages/hooks`, wrapping
   the ts-rest contract client. One hook per contract operation, typed end
   to end from the Zod contract. The client's base URL comes from a
-  `NEXT_PUBLIC_`-prefixed env var (added to
-  `packages/config/env.schema.ts` if it isn't there yet) — never a
-  hardcoded `http://localhost:<port>` literal, even as a "temporary"
-  fallback. `apps/api`'s dev port is `3333` (see `hedgehog-bootstrap-full-stack-app-core`
-  — chosen specifically to not collide with `apps/web`'s `next dev`
-  default of `3000`); a literal fallback drifts out of sync with that the
-  moment either port changes and produces a silent 404 that looks like a
-  routing bug, not a config bug.
+  `NEXT_PUBLIC_`-prefixed env var (add to `packages/config/env.schema.ts`
+  if missing) — never a hardcoded `http://localhost:<port>` fallback,
+  which silently drifts out of sync with `apps/api`'s dev port (`3333`,
+  per `hedgehog-bootstrap-full-stack-app-core` — chosen to not collide
+  with `apps/web`'s `next dev` default of `3000`) and produces a 404 that
+  looks like a routing bug, not a config bug.
 - **`screen`**: build the screen/component in `apps/web` and/or
   `apps/mobile`, consuming the hook and `ux-planner`'s rationale for that
   module (screen inventory, interaction pattern, information hierarchy).
@@ -92,9 +89,8 @@ don't reach for a second one.
 
 ## Constraints
 
-- Never self-certify a task as done. Report what was built and that
-  local checks pass; only `hedgehog verify`'s exit code moves the task to
-  `complete`. Never run `git commit` for the task's own changes.
+- Never self-certify a task as done or run `git commit` for its changes —
+  see Workflow step 3.
 - Never add a data-fetching call that bypasses the hook/contract layer —
   the Nx boundary rule (`scope:web` / `scope:mobile` only depend on
   `scope:contracts`, `scope:hooks`, `scope:shared`) makes a direct

package/src/agents/layer-eng.md

@@ -68,9 +68,8 @@ parsing and typing, and the layer after it consumes the result.
 
 ## 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 self-certify a task as done or run `git commit` for its changes —
+  see Workflow step 4.
 - 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

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 the build graph already handle that.
+description: Use for planning intake (core selection, then scope boundary + domain vocabulary or Chain Method brief, depending on core) at the start of a project, and for re-entry when new scope enters play on a project already built or mid-build — including after a build has reached its Stop Condition, where it is the exit `tweaker` routes new scope to. Runs a first-run or a re-entry path depending on whether the build graph already holds intents. 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
@@ -19,23 +19,35 @@ artifact gets written.
 
 ## When you run
 
-- **Phase 0 — core selection** (every project, before anything else): the
-  gate below.
-- **Phase 1 — planning intake**, in the shape the chosen core defines
-  (once per project, before step 1 of anything).
-- **New scope entering play** (full-stack-app only): modules added to
-  scope need placing in build order. Run a scoped pass — BMAD's
-  brief/PRD update flows against what's new, then re-mine — before
-  decomposing. Landing-page has no equivalent: it's a fixed one-page (or
-  few-page) scope set once at Phase 1, not grown incrementally.
-- When the user says "plan", "scope", "break down", or before a large
-  refactor that might cross module boundaries (full-stack-app).
+You run on two paths, and Workflow step 2 decides which:
+
+- **First run** (the graph holds no intents): **Phase 0 — core
+  selection**, the gate below, then **Phase 1 — planning intake** in the
+  shape the chosen core defines, then the `bootstrap` handoff.
+- **Re-entry** (the graph already holds intents): new scope entering play
+  on a project that's already been built or is mid-build, on a core with
+  a module axis to add an intent to (full-stack-app, authored). The core
+  is already chosen and its workspace already scaffolded, so Phase 0 and
+  the `bootstrap` handoff are both skipped — run
+  `hedgehog-planning-intake`'s **Re-entry pass** instead, which mines new
+  scope into additional intents without re-running the BMAD shelf.
+  Landing-page has no module axis, so this path doesn't apply to it — see
+  the landing-page constraint below for where its new scope actually
+  goes.
+
+Either path is entered when the user says "plan", "scope", "break down",
+asks for something that's new scope rather than a tweak (routed here by
+`tweaker`), or before a large refactor that might cross module boundaries
+(full-stack-app).
 
 ## 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. The real question is
-always *which* core — "no core fits" is a narrow case, handled below.
+Before invoking any planning-intake skill, on a first run only (Workflow
+step 2 establishes which run this is), decide which core the description
+calls for. The real question is always *which* core — "no core fits" is a
+narrow case, handled below. On re-entry this whole phase is skipped: the
+core is a settled fact of the project, readable from `.hedgehog/core.yaml`
+and the scaffolded workspace.
 
 - **`full-stack-app`** — the description names persistent domain data
   with its own lifecycle: something that gets created, changes state,
@@ -93,7 +105,9 @@ rather than guess.
 
 ## Phase 1 — planning intake
 
-Once Phase 0 picks a core, run that core's own intake procedure:
+Once Phase 0 picks a core, run that core's own intake procedure. This is
+the first-run shape; on re-entry, run `hedgehog-planning-intake`'s
+**Re-entry pass** instead of anything below.
 
 - **`full-stack-app`** → open `hedgehog-planning-intake` and follow it in
   full: Phase 0 runs the vendored BMAD-METHOD shelf
@@ -178,77 +192,85 @@ accounts get added where there were none).
 ## Core Responsibilities
 
 - Decide which core applies before running any planning-intake skill —
-  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, 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 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
+  Phase 0 above.
+- **full-stack-app**: owns `.hedgehog/BMAD/` (archival, written once,
+  never edited after) and `.hedgehog/addons.yaml` as artifacts; the
+  intent records Phase 1 writes via `hedgehog intent add` live in the
+  build graph, not a file this agent owns.
+- **landing-page**: owns `.hedgehog/BMAD/` and
   `.hedgehog/chain/00-brief.md` as artifacts.
 
 ## Workflow
 
 1. **Read the requirement** fully before doing anything.
-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.
+2. **Run `hedgehog status` and decide which path you're on.** This is a
+   branch, not a survey — the rest of the workflow depends on its answer:
+   - **No intents in the graph → first run.** Continue at step 3.
+   - **One or more intents → re-entry.** Skip steps 3, 4, and 9 entirely
+     and go to step 5's re-entry branch. The core is already chosen and
+     its workspace already scaffolded; re-deciding either is destructive,
+     not a fresh start.
+
+   Read the commit log alongside it 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.
    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.
-4. **On an authored core only, design it before mining**: run
+   `.hedgehog/core.yaml`'s own commit messages. On re-entry this is what
+   tells you which modules the new scope can depend on.
+3. **First run only — 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. **First run only, on an authored core, 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 `04-prd.md` only into intent records per the PRD→graph-row
+   shelf twice. On re-entry these two files are locked; a layer sequence
+   that turns out to be wrong is a Correction Protocol case, not a quiet
+   rewrite here.
+5. **Run planning intake**, in the shape this path calls for:
+   - **First run, full-stack-app**: run the vendored BMAD shelf, 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.
-6. **Run that core's Confirm & Lock** before writing anything.
+   - **First run, 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.
+   - **Re-entry (any core)**: run `hedgehog-planning-intake`'s **Re-entry
+     pass**. It reads the existing `.hedgehog/BMAD/` as context and elicits
+     only what's new — the BMAD shelf does not run again.
+6. **Run the matching Confirm & Lock** before writing anything — the
+   first-run stage on a first run, the extension variant on re-entry.
 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` — 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
+   `hedgehog intent add`, one call per PRD Feature (per new module, on
+   re-entry), 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 — on a first
+   run only, since re-entry there requires the existing brief to still
+   hold. Then run **`hedgehog plan`** to compile those intents into
+   tasks. On re-entry this is append-only: `plan` only reads intents still
+   `proposed`/`planned`, so already-compiled work is untouched and its
+   `complete` tasks keep their status.
+8. **Commit planning intake's output as one commit** —
+   `chore(planning): intake` on a first run, `chore(planning): extend
+   scope` on re-entry, so the two passes are distinguishable in the log.
+   It carries the committed `.hedgehog/hedgehog.db` (its new intent and
+   task rows on full-stack-app), `.hedgehog/addons.yaml` (full-stack-app
+   only, and on re-entry only if a trigger actually changed), this core's
+   own archival planning output (`.hedgehog/BMAD/` or `.hedgehog/chain/`,
+   first run only), the authored core's `.hedgehog/core.yaml` and
+   `.hedgehog/core-design.md` if step 4 ran, and root `CLAUDE.md`'s filled
+   placeholders (first run only). This is planning intake's own unit of
+   work, landed before `bootstrap` touches anything.
+9. **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.
+   starts. On re-entry the workspace already exists: hand straight to
+   this core's loop skill instead, which picks the new work up from
+   `hedgehog next`.
 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.
@@ -272,13 +294,34 @@ accounts get added where there were none).
   or "improve."
 - 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
-  re-entered, so its `.hedgehog/BMAD/` and `.hedgehog/chain/00-brief.md`
-  are written exactly once, ever.
+  decision. `.hedgehog/BMAD/` and `.hedgehog/chain/00-brief.md` are
+  written exactly once, on the first run, and read as context on every
+  re-entry after. A re-entry pass never rewrites them: what's new lives
+  in the new intents it adds, and the commit log carries the rest.
 - Never invent scope. Ambiguous scope means stop and ask — this applies
   equally to a full-stack-app module boundary and a landing-page subject
   statement, whether or not BMAD's docs offered a mineable answer.
+- **On landing-page, new scope after the build is complete is governed by
+  the subject statement, not by page or section count — and it is not
+  routed to you.** This core has no module axis, so there's no intent for
+  a later `planner` run to add: the single `landing` intent already
+  compiles into the fixed five-phase chain. `.hedgehog/chain/00-brief.md`
+  is the root every downstream phase's traceability audit walks back to,
+  so the only question is whether it still holds:
+  - **It holds** (a pricing section on a page whose subject is
+    unchanged — the page still sells the same thing to the same audience
+    for the same job): this is additive work inside the existing chain,
+    handled by `hedgehog-landing-loop`'s Correction Protocol post-build
+    entry, not by you.
+  - **It doesn't hold** (a different product, a different audience, a
+    different job): that's a new subject, and a new subject is a new
+    landing-page project through your first run there — not an edit to
+    this one's locked brief.
+
+  If a request like this reaches you anyway, read `00-brief.md`, say
+  which of the two it is, and route it correctly rather than absorbing
+  it. Never rewrite the brief to accommodate new scope; that inverts the
+  traceability the whole core rests on.
 - Never default a full-stack-app add-on on or off without either a
   concrete trigger in BMAD's docs or a direct answer to a gap-fill
   question — an unresolved add-on left as a guess is the same mistake as

package/src/agents/tweaker.md

@@ -54,10 +54,27 @@ discipline as the rest of the build (`fix(<scope>): <what>` or
 
 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; authored core: new scope, or a change
-to the layer sequence itself) rather than absorbing it here.
+out to be either of those, say so and route it onward — a completed
+build is extendable, not sealed, and the user should not hear "no" where
+the answer is "that's a different session." Where it routes depends on
+the core:
+
+- **full-stack-app** — a new domain module, or a feature that needs one,
+  routes to `planner`, which runs `hedgehog-planning-intake`'s
+  **Re-entry pass**: it adds intents for the new work without re-running
+  planning from scratch, and without disturbing anything already built.
+- **authored core** — new scope on the module axis routes to `planner`'s
+  Re-entry pass the same way. A change to the layer sequence itself is
+  the Correction Protocol instead (`.hedgehog/core.yaml` is locked).
+- **landing-page** — the test is whether `.hedgehog/chain/00-brief.md`
+  still holds. This core has no module axis, so a new section under a
+  brief that still holds does **not** route to `planner` — it routes to
+  the Correction Protocol's post-build entry (this core's own loop skill),
+  which re-runs the sequencer and copy phases for that section and
+  rebuilds the artifact. A different subject, audience, or job is a
+  different page and belongs in its own landing-page project — say so
+  rather than routing it, and never rewrite `00-brief.md` to fit new
+  scope into the old chain.
 
 ### Job 2 — Friction review, user feedback, and issue suggestion
 
@@ -191,18 +208,17 @@ discipline as `.hedgehog/BMAD/`. A later related incident is its own new
   asking.
 - Entries (or feedback items) that trace to the same underlying gap were
   grouped into one issue, not filed as duplicates.
-- Each issue shown to the user for approval is the literal, final
-  content, with the correct label(s) for its source (`bug` +
-  `help wanted` for friction, `suggestion` for user feedback) — not a
-  summary of what will be filed, and not silently altered after the user
-  approved it.
-- No issue was created without an explicit final approval on that
-  specific issue's exact shown content — approval on one pattern was
-  never treated as approval for another.
+- Shown content is literal/final and correctly labeled — never a
+  summary, never altered post-approval, and never created without an
+  explicit approval on that specific issue's exact shown content.
 - Every tweak is its own commit, scoped to what the user actually asked
   for — no drive-by refactor riding along on a color change.
-- A request that's actually new scope (a new module, a new page section)
-  was routed back to `planner`, not built here.
+- A request that's actually new scope (a new module on full-stack-app or
+  an authored core, or a new landing-page section whose subject
+  statement still holds) was routed onward — to `planner`'s Re-entry
+  pass, or on landing-page to the Correction Protocol's post-build entry
+  — not built here, and the user was told the build is extendable, not
+  that the request was refused.
 
 ## Constraints
 
@@ -214,10 +230,12 @@ discipline as `.hedgehog/BMAD/`. A later related incident is its own new
   having happened in this conversation. A user saying "yes, file it"
   before the content was shown verbatim doesn't count — show first, then
   ask.
-- **If delegated**, an approval relayed by the orchestrating session is
-  sufficient only if it quotes the user's actual words with provenance
-  stated plainly — e.g. "user said: '\<exact words\>'" — not a bare "the
-  user approved" or "approved via UI."
+- **If delegated**, the orchestrating session relays approval on the
+  user's behalf. A quoted, attributed relay (`user said: "<exact
+  words>"`) **is** sufficient approval — treat it as you would the user
+  typing it directly. A bare unquoted assertion ("the user approved") is
+  not. Don't demand the user type "here" when they have no channel to do
+  so.
 - File one issue per distinct real pattern or feedback item, not one per
   log entry or remark, and not capped at a single issue per source — a
   log (or a round of feedback) with several unrelated genuine points gets
@@ -242,8 +260,13 @@ discipline as `.hedgehog/BMAD/`. A later related incident is its own new
   write-once per row, same as `.hedgehog/BMAD/`.
 - Don't expand a tweak into a rebuild. If a "tweak" actually requires
   redoing a phase (e.g. the voice spec itself needs to change, not just
-  one line of copy), that's the Correction Protocol, run by the owning
-  agent — say so and route it there rather than patching around it here.
+  one line of copy), that's the Correction Protocol — say so and route it
+  there rather than patching around it here. Use its **post-build entry**
+  (in this core's own loop skill): the build is already at its Stop
+  Condition, so there's no task in flight to stop and no loop to resume,
+  and the correction is fixed forward in new commits rather than by
+  reopening a `complete` task. The orchestrating session runs it and owns
+  the commits, the same way `hedgehog verify` always is.
 - Don't run job 2's friction detection against anything other than
   `hedgehog friction list` — don't re-scan the whole commit log or
   conversation history looking for friction; if it wasn't logged, it