@skyf0xx/hedgehog-core-full-stack-app 1.1.0 → 1.2.0

package/CLAUDE.core.md

@@ -22,46 +22,25 @@ steps from memory:
   `hedgehog verify`, which commits it on a pass. Also holds the Correction
   Protocol for fixing a wrong upstream step. Invoke it at the start of any
   build session and for "what's next".
+<!-- hedgehog:bootstrap-only start -->
 - **`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.
+<!-- hedgehog:bootstrap-only end -->
 - **`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 (which core applies, then
-  `hedgehog-planning-intake`'s BMAD-METHOD brainstorming/brief/PRD/UX-spec
-  shelf, mined into intent records, the Add-ons decision, and domain
-  vocabulary) at project start. Writes intents via `hedgehog intent add`,
-  `.hedgehog/addons.yaml`, and `.hedgehog/BMAD/`. On first run, hands off
-  to the `bootstrap` agent once Confirm & Lock holds. Runs again whenever
-  new scope enters play — including after the build is complete — taking
-  `hedgehog-planning-intake`'s **Re-entry pass**: the BMAD shelf and
-  `bootstrap` are both skipped, new modules are mined into additional
-  intents, and `hedgehog plan` appends their tasks without touching
-  anything already built.
-- **`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 layers (schema →
-  contract → repository → service → controller → queue?), one
-  `hedgehog claim`ed packet at a time, gated by `hedgehog verify`.
-- **`ux-planner`** — once per module in Phase B, after the hook exists and
-  before the screen: writes `docs/design/<module>.md`, reading
-  `.hedgehog/BMAD/05-ux-spec/` directly (or
-  `docs/design/<module>-notes.md` if a prior run already filed one). Where
-  the archive holds no UX spec, it asks for visual input rather than
-  inferring a direction.
-- **`front-end-eng`** — builds each module's Phase B layers (hook, screen)
-  from the ux-planner rationale, one `hedgehog claim`ed packet at a time,
-  gated by `hedgehog verify`.
-- **`reviewer`** — phase-transition and Correction Protocol checks the
-  mechanical gate can't make (port discipline, FK-by-ID discipline,
-  contract shape).
+`backend-eng` builds each module's Phase A layers (schema → contract →
+repository → service → controller → queue?), one `hedgehog claim`ed
+packet at a time, gated by `hedgehog verify`. `front-end-eng` builds
+each module's Phase B layers (hook, screen) from `ux-planner`'s
+rationale, the same way. See `hedgehog-loop` for exactly which agent
+owns which layer and the claim/verify sequencing — that skill is the
+source, not restated here.
 
 ## The constants (do not deviate)
 
@@ -121,9 +100,6 @@ docs/
   design     <module>.md (ux-planner, reading .hedgehog/BMAD/05-ux-spec/ directly)
 ```
 
-Check `.hedgehog/addons.yaml` 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.

package/agents/backend-eng.md

@@ -51,12 +51,12 @@ catch.
 ## Core Responsibilities
 
 - **`schema`**: define the table in `packages/db` (Drizzle). One domain
-  module = one table. Cross-module references are FK-by-ID columns
-  only — never a foreign schema import. Add one re-export line for the
-  module to `packages/db/src/schema/index.ts` (in scope for this
-  layer) so the table is importable outside `packages/db` — the
-  package's own `src/index.ts` re-exports that barrel and never
-  changes after bootstrap.
+  module per table, cross-module references FK-by-ID only (root
+  CLAUDE.md's Core rules) — never a foreign schema import. Add one
+  re-export line for the module to `packages/db/src/schema/index.ts`
+  (in scope for this layer) so the table is importable outside
+  `packages/db` — the package's own `src/index.ts` re-exports that
+  barrel and never changes after bootstrap.
 - **`contract`**: derive the Zod schema from Drizzle (`drizzle-zod`) and
   wire the ts-rest contract in `packages/contracts`. A `date`-mode
   `timestamp` column reflected through `createSelectSchema` is overridden
@@ -101,8 +101,7 @@ catch.
    the packet's scope and rules don't account for; your own tests prove
    internal consistency, never coverage of what was asked. INHERITED DEBT
    is what the layers you depend on declared they left for you; declare
-   your own with `hedgehog debt add <task-id> "<note>"` rather than a
-   code comment nothing reads. Its WHY NOW section
+   your own with `hedgehog debt add <task-id> "<note>"`. Its WHY NOW section
    already confirms the module is in scope and every dependency is
    `complete` — no need to re-derive that by hand. Cross-module FK
    targets should already have their own schema landed (the packet's
@@ -122,14 +121,10 @@ catch.
    name the shared files that changed (typically `pnpm-lock.yaml`, root
    `tsconfig.json`) in your report — the orchestrating session commits
    them separately, since you report but never commit (next step).
-3. **Report the work as done; do not commit it yourself.** Per the build
-   graph's design, an agent reporting success never moves a task — only
-   `hedgehog verify <task-id>`'s passing exit code does. It checks your
-   changes against the packet's ALLOWED SCOPE, re-runs the real
-   verification command, and on a pass writes the commit (the packet's
-   exact Conventional Commit message) itself. Any shared workspace files
-   you flagged in step 2 are a separate commit the orchestrating session
-   makes before dispatching `hedgehog verify`, not something you commit.
+3. **Report the work as done; do not commit it yourself.** Any shared
+   workspace files you flagged in step 2 are a separate commit the
+   orchestrating session makes before dispatching `hedgehog verify`, not
+   something you commit.
 4. One layer at a time — never start the next layer before
    `hedgehog verify` reports the current one `complete`.
 5. Once `hedgehog verify` reports the `controller` layer (and any bundled
@@ -154,7 +149,7 @@ catch.
   reported rather than chosen here. `verify` cannot check any of this,
   which is exactly why it's on you.
 - Never import another module's repository, service, or schema directly
-  — cross-module references are FK-by-ID, resolved at the
+  — FK-by-ID only (root CLAUDE.md's Core rules), resolved at the
   contract/controller layer (parallel calls) or via a same-repository
   Drizzle join against the other module's *schema*, never its adapter.
 - Never write queue infra when the Queue add-on is off (per

package/agents/front-end-eng.md

@@ -96,8 +96,7 @@ don't reach for a second one.
    and rules don't account for; your own tests prove internal
    consistency, never coverage of what was asked. INHERITED DEBT is what
    the layers you depend on declared they left for you; declare your own
-   with `hedgehog debt add <task-id> "<note>"` rather than a code comment
-   nothing reads. Its WHY NOW section already
+   with `hedgehog debt add <task-id> "<note>"`. Its WHY NOW section already
    confirms Phase A is closed for this module (the `hook`/`screen`
    layer's dependencies wouldn't be `complete` otherwise) — no need to
    re-derive that by hand. If you're handed a step outside a packet with
@@ -116,12 +115,10 @@ don't reach for a second one.
    the workspace, and name the shared files that changed (typically
    `pnpm-lock.yaml`, root `tsconfig.json`) in your report — the
    orchestrating session commits them separately (next step).
-3. **Report the work as done; do not commit it yourself.** Only
-   `hedgehog verify <task-id>`'s passing exit code moves the task to
-   `complete` and writes the commit (the packet's exact Conventional
-   Commit message). Any shared workspace files you flagged in step 2 are a
-   separate commit the orchestrating session makes before dispatching
-   `hedgehog verify`, not something you commit.
+3. **Report the work as done; do not commit it yourself.** Any shared
+   workspace files you flagged in step 2 are a separate commit the
+   orchestrating session makes before dispatching `hedgehog verify`, not
+   something you commit.
 4. Build the screen consuming the hook the same way — packet, build,
    report, `hedgehog verify`.
 5. One layer at a time — `hook` fully `complete` before the `screen`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog-core-full-stack-app",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "description": "Hedgehog's full-stack-app core: an Nx/pnpm/NestJS/Next.js workspace, backend-first domain module build discipline, and the agents and skills that drive it.",
   "type": "module",
   "scripts": {

package/skills/hedgehog-loop/SKILL.md

@@ -44,14 +44,14 @@ Phase A.
 
 ## The Domain Module Pattern
 
-A **domain module = one table.** `users`, `orders`, `order_items` are each
-their own module, carrying the full step sequence below. The schema is the
-source of truth for module boundaries.
+Root CLAUDE.md's Core rules own "one table = one domain module" and
+"FK-by-ID only" — this section is their mechanics. `users`, `orders`,
+`order_items` are each their own module, carrying the full step sequence
+below. The schema is the source of truth for module boundaries.
 
-**Cross-module references are FK-by-ID only.** If `orders.user_id`
-references `users`, the `orders` schema holds a plain FK column. The
-`orders` repository and service depend only on their own ports — a service
-knows related entities only as an ID.
+If `orders.user_id` references `users`, the `orders` schema holds a plain
+FK column. The `orders` repository and service depend only on their own
+ports — a service knows related entities only as an ID.
 
 - Need the related row? Resolve it at the contract/controller layer
   (parallel calls to each module's own endpoint), or join against the
@@ -193,12 +193,8 @@ writes `docs/design/<module>.md`, not its own compiled layer — the
    `hedgehog verify <task-id> --owner <owner>` (the same owner that
    claimed it; verify requires the lease owner). Building happens in
    parallel; verifying does not — verify writes a commit, and commits go
-   through one at a time. It checks the touched files against the
-   packet's ALLOWED SCOPE, runs the layer's VERIFICATION command, and on
-   a pass writes the commit (the exact Conventional Commit message from
-   the tables above, plus the updated build graph) and unlocks the next
-   layer. On a scope violation or a failing check, the task moves to
-   `blocked` with a `blocked_reason` of `scope_violation` or
+   through one at a time. On a scope violation or a failing check, the
+   task moves to `blocked` with a `blocked_reason` of `scope_violation` or
    `verification_failed`, and nothing downstream unlocks. Fix the work,
    then run `hedgehog retry <task-id>` to return the task to `planned`,
    claim it again (by task id — see below), and verify again —
@@ -238,7 +234,7 @@ the built work against it there, because nothing else in the build does.
 A layer that hits a limitation the next layer must compensate for
 declares it with `hedgehog debt add <task-id> "<note>"`; the note lands
 in the **INHERITED DEBT** section of every packet that depends on that
-task. A comment in a source file is not a mechanism — nothing reads it.
+task.
 
 Each `hedgehog verify` call commits exactly one layer, built right for
 what's known now; a wrong layer is fixed forward later via the
@@ -615,8 +611,8 @@ the graph doesn't have a task for.
   committed.
 - The screen step doesn't start blank — `ux-planner` runs once per module,
   after the hook is committed, before `front-end-eng` starts the screen.
-- `packages/config` is the single source for shared config; a per-app
-  override request signals to fix the base config at the source.
+- `packages/config` is the single source for shared config (root
+  CLAUDE.md's Core rules).
 
 ## Stop Condition