@skyf0xx/hedgehog 3.0.7 → 3.0.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog",
-  "version": "3.0.7",
+  "version": "3.0.8",
   "description": "Install the Hedgehog build discipline (agents + skills) into a repo, for Claude Code, Cursor, or Gemini CLI.",
   "type": "module",
   "repository": {

package/src/agents/landing-headline-writer.md

@@ -61,8 +61,8 @@ against its own archetype skill.
    without confirmation risks the same expensive unwind the strategist's
    Confirm & Lock protects against at step 1.
 5. Write the locked headline and its 2 backups to
-   `.hedgehog/chain/09-headline.md`.
-6. Commit as `feat(landing): headline`.
+   `.hedgehog/chain/09-headline.md` — you have no Bash tool, so the
+   orchestrating session commits it via `hedgehog verify`.
 
 ## Self-test
 

package/src/agents/landing-sequencer.md

@@ -118,7 +118,8 @@ rather than in separate passes.
 6. Confirm the peak moment and ending treatment land where
    `landing-strategist` specified, or flag the conflict.
 7. Self-test (below).
-8. Commit as `feat(landing): sequence`.
+8. Present the artifact — you have no Bash tool, so the orchestrating
+   session commits it via `hedgehog verify`.
 
 ## Self-test
 

package/src/agents/landing-strategist.md

@@ -56,7 +56,11 @@ as planning intake's own Confirm & Lock: every phase from here through
 `landing-copywriter` inherits this framing silently, and by the time
 copy is reviewed at phases 9–10, correcting the framing means unwinding
 multiple committed phases via the Correction Protocol instead of one
-quick revision now. A revision at this point is just another pass at
+quick revision now. **If delegated**, this confirmation arrives as a
+relay from the orchestrating session — accept it only if it quotes the
+user's actual words with provenance stated plainly, not a bare "the user
+approved" (see `hedgehog-landing-loop`'s Loop step 2 for the exact form).
+A revision at this point is just another pass at
 Step 1, not a Correction Protocol entry, since nothing downstream exists
 yet.
 
@@ -117,7 +121,8 @@ adjective is meant to fade rather than hold constant throughout the page.
    confirmed subject statement.
 5. Run step 4c (Perfumer) against the completed sort from step 3.
 6. Self-test (below) before presenting the combined artifact.
-7. Commit the combined artifact as `feat(landing): strategy`.
+7. Present the combined artifact — you have no Bash tool, so the
+   orchestrating session commits it via `hedgehog verify`.
 
 ## Self-test
 

package/src/agents/landing-systems.md

@@ -239,7 +239,8 @@ and generic clip-art geometry.
 4. Run step 6 against the completed token system. Write the signature
    element into `src/shapes/`.
 5. Self-test (below).
-6. Commit the combined artifact as `feat(landing): systems`.
+6. Present the combined artifact — you have no Bash tool, so the
+   orchestrating session commits it via `hedgehog verify`.
 
 ## Self-test
 

package/src/agents/tweaker.md

@@ -214,6 +214,10 @@ 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."
 - 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

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

@@ -167,7 +167,9 @@ alike:
 
 Four to seven layers is the usual range. Fewer than three means the
 project probably wanted a shipped core or no core at all; more than eight
-means several layers are one layer with internal steps.
+means several layers are one layer with internal steps. This list isn't
+final until Step 4 — a module axis can still add a cross-cutting layer to
+it.
 
 ## Step 4 — decide the module axis
 
@@ -193,6 +195,23 @@ intent A's task may write intent B's files and the scope enforcement that
 justifies authoring a core at all disappears. Check every glob before
 writing the file.
 
+On a module axis, also **ask explicitly whether the stack implies
+cross-cutting infrastructure no single module should own** — a shared
+background script coordinating state across every module's tabs (a
+browser extension), a shared event bus, global app state. Every layer in
+Step 3 instantiates once per intent; this is the thing that doesn't fit
+that shape, and left undesigned it either gets deferred with no owner or
+bolted onto whichever module's layer needs it first, quietly widening
+that layer's scope past what it was designed to own.
+
+If yes, add it to Step 3's layer sequence as its own layer, before the
+file is written — a layer whose `scope` is a fixed path with no
+`{module}` placeholder, the same way `full-stack-app`'s own `schema` and
+`contract` layers run once against a fixed scope on an otherwise
+module-axis core. Name it for what it owns (e.g. `background-infra`),
+give it its own `verify` command, and record in `core-design.md` why no
+single module was made to own it.
+
 ## Step 5 — write `.hedgehog/core.yaml`
 
 The loader parses `id` plus a `layers` list of flat maps. Every layer

package/src/skills/hedgehog-core-design/blueprints/browser-extension.md

@@ -17,6 +17,10 @@ popup      — the extension UI, consumes background/content only through messag
 - Drop `popup` entirely for an extension with no browser action UI.
 - Merge `content` into `background` when the extension never injects into
   page context (a pure background-worker extension).
+- On a module axis, `background` is often shared rather than
+  one-per-module (a single service worker coordinating state across every
+  module's tabs) — the cross-cutting infrastructure Step 4 asks about.
+  Give it its own fixed-scope layer there.
 
 ## Boundary that must hold
 
@@ -24,3 +28,35 @@ popup      — the extension UI, consumes background/content only through messag
 cross-context call goes through `messaging`, because a WebExtension's
 contexts are separate JS runtimes and a direct import silently fails at
 runtime rather than at build time.
+
+## WXT entrypoint naming (must decide up front, not discover mid-build)
+
+WXT derives an entrypoint's manifest name by splitting its `entrypoints/`
+folder or file name at the **first** `.`. Two entrypoints that derive the
+same name collide — observed failure modes include a build-time error
+("Multiple entrypoints with the same name detected") and, in at least one
+case, a colliding entrypoint silently missing from the built manifest
+(`.output/*/manifest.json`) with no error at all. Don't assume which one
+fires for a given WXT version or collision shape; treat any collision as
+unsafe rather than relying on the build to always catch it.
+
+Decide the naming convention in this step, per module, before any layer
+is built against it — not after the first collision is hit:
+
+- **Every entrypoint with more than one surface lives in its own folder**,
+  `entrypoints/{module}/index.ts`, never a flat `entrypoints/{module}.ts`
+  — a folder has no `.`-split ambiguity to collide on.
+- **Colocated tests go inside that same folder** as a sibling
+  (`entrypoints/{module}/index.test.ts`), never as a flat
+  `entrypoints/{module}.test.ts` next to a flat entrypoint file — that's
+  the same name-collision shape described above.
+- **A module with two entrypoint surfaces** (e.g. popup and content) gets
+  two folder names that don't share a prefix before the first `.` —
+  `entrypoints/{module}-popup/` and `entrypoints/{module}-content/`, never
+  a dotted variant like `entrypoints/{module}.content/`.
+
+Add a cheap, generic guard to the entrypoint layer's `verify` command
+regardless of the convention chosen: after `pnpm wxt build`, check the
+built manifest's entrypoint count against the expected count (e.g. `node
+-e "..."` reading `.output/*/manifest.json`) so a silent drop fails
+`verify` instead of surfacing later as a missing feature.

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

@@ -150,10 +150,27 @@ paragraph algorithm, and their self-tests.
    section, in `landing-sequencer`'s order, every section reviewed and
    locked before the next starts, all still inside the one `sequence`
    task.
+
+   **Relaying a live user-confirmation checkpoint to a delegated
+   subagent.** Phase 1 (Strategist) carries a hard-stop checkpoint per
+   Phase Transition Checks below, and a delegated subagent instance has no
+   channel for the user to address it directly. The orchestrating session
+   relays the confirmation instead, and the relay is sufficient only if it
+   quotes the user's actual words with its provenance stated plainly
+   (*"Relaying the user's own confirmation, verbatim — user said:
+   '\<exact words\>'"*) rather than asserting the outcome ("the user
+   approved"). This trusts the orchestrator's honesty about provenance,
+   the same trust the rest of this discipline already places in it for
+   relaying artifacts and task packets.
 3. Each agent **runs its own self-test** (see that agent's own file for
    what it checks) before presenting its artifact — necessary, not
    sufficient. This is a sanity check the agent does for itself; it does
-   not move the task and the agent does not commit its own work.
+   not move the task and the agent does not commit its own work, whether
+   run directly or delegated to a subagent instance. `landing-strategist`,
+   `landing-systems`, `landing-sequencer`, and `landing-headline-writer`
+   carry no Bash tool at all (`capabilities.mjs`), so the commit is always
+   the orchestrating session's act via `hedgehog verify`, never the phase
+   agent's own.
 4. Once every phase inside the packet's layer has been presented and
    locked by the user, **run `hedgehog verify <task-id>`.** It checks the
    touched files against the packet's ALLOWED SCOPE, runs the layer's
@@ -216,7 +233,10 @@ the whole chain to correct the core framing (nothing downstream exists
 yet); every phase after it inherits that framing silently, and by the
 time copy is reviewed at phases 9–10, a wrong framing means unwinding
 several committed phases via the Correction Protocol instead of one free
-revision here.
+revision here. If step 1 was run by a delegated `landing-strategist`
+subagent instance, the confirmation reaches it as a relay from the
+orchestrating session — see The Loop above for the provenance statement
+that relay must carry.
 
 Before `landing-copywriter` starts (phase 10), confirm
 `landing-headline-writer`'s headline has been presented to and locked by