@skyf0xx/hedgehog 6.0.5 → 6.1.0

package/bin/cli.mjs

@@ -281,19 +281,6 @@ function corePayload(core, h, { hostOnly = false } = {}) {
     // than generating it live. A core that scaffolds nothing (its
     // workspace is designed during planning) declares no `workspace`.
     ...(manifest.workspace ? [{ type: 'dir', root, from: manifest.workspace, to: '.' }] : []),
-    // A second CLAUDE.md section for cores whose path fills
-    // {{CORE_SECTION}} after install rather than at it — adoption reads
-    // it from the project instead of the package it ships in.
-    ...(manifest.template_adopted
-      ? [
-          {
-            type: 'file',
-            root,
-            from: manifest.template_adopted,
-            to: `.hedgehog/${manifest.template_adopted}`,
-          },
-        ]
-      : []),
   ];
 }
 
@@ -526,7 +513,7 @@ ${bold('Usage')}
   npx @skyf0xx/hedgehog init --pwa-app            scaffold the pwa-app core now
   npx @skyf0xx/hedgehog init --landing-page       scaffold the landing-page core now
   npx @skyf0xx/hedgehog cores list                every core this release can install
-  npx @skyf0xx/hedgehog core record-adopted       land the authored core's agents/skills and record
+  npx @skyf0xx/hedgehog core record-adopted       land the adopted core's agents/skills and record
                                                    this project as adopted (hedgehog-adopt calls this
                                                    after writing .hedgehog/core.yaml; not for other cores)
   npx @skyf0xx/hedgehog init --cursor             install for Cursor (default: Claude Code)
@@ -1046,10 +1033,10 @@ async function resolveInstalledCore() {
 }
 
 // `hedgehog core record-adopted` — the record path for `hedgehog-adopt`
-// (shipped in @skyf0xx/hedgehog-core-authored), which brings the
+// (shipped in @skyf0xx/hedgehog-core-adopted), which brings the
 // discipline to an existing repo by writing `.hedgehog/core.yaml` and
 // `.hedgehog/adoption.md` directly. That path has no `init` step and so
-// never fetches the `authored` package or calls `recordCore` — a no-flag
+// never fetches the `adopted` package or calls `recordCore` — a no-flag
 // `init` (what the offer skill actually runs before adoption) installs
 // only the shared engine payload, never a core's own agents/skills, and
 // `bootstrap` (the only other place a core package gets fetched) is
@@ -1061,24 +1048,27 @@ async function resolveInstalledCore() {
 // `core.yaml` (the shipped-core workspace marker) and finds nothing for
 // an adopted repo's `.hedgehog/core.yaml`, so it would read as "no core
 // yet" and update would silently rewrite `.claude/agents`/`.claude/skills`
-// down to just the shared payload, deleting the authored package's files
+// down to just the shared payload, deleting the adopted package's files
 // with nothing put back.
 //
-// This command is both fixes at once: it fetches the `authored` package
+// This command is both fixes at once: it fetches the `adopted` package
 // and lands its agents/skills for every host this project already has
-// installed (never its workspace, template, or vendor_skills — adoption
-// already wrote its own CLAUDE.md section and root workspace is the one
-// thing adoption must never touch), then records the core with
-// `adopted: true` so `update` refreshes it correctly from here on.
-// Idempotent and safe to re-run — e.g. from a later `hedgehog-adopt` pass
-// adding new change-work — since it always overwrites from the current
-// package rather than merging.
+// installed (never its workspace or vendor_skills — root workspace is
+// the one thing adoption must never touch), plus a local copy of its
+// `CLAUDE.core.md` at `.hedgehog/CLAUDE.core.md` — `hedgehog-adopt`'s own
+// Confirm & Lock step reads that file from there to merge into root
+// `CLAUDE.md`, since a no-flag `init` never ran the normal
+// `{{CORE_SECTION}}` merge this project's core would otherwise get — then
+// records the core the same as any other, naming `adopted`, so `update`
+// refreshes it correctly from here on. Idempotent and safe to re-run —
+// e.g. from a later `hedgehog-adopt` pass adding new change-work — since
+// it always overwrites from the current package rather than merging.
 async function recordAdoptedCommand() {
   const entry = await resolveCore(ADOPTED_CORE_NAME);
   if (!entry) {
     console.error(
-      `${red('authored core not in this release.')} This Hedgehog release's registry has no\n` +
-        `entry named "authored" — nothing to install. Update Hedgehog and retry.\n`,
+      `${red('adopted core not in this release.')} This Hedgehog release's registry has no\n` +
+        `entry named "adopted" — nothing to install. Update Hedgehog and retry.\n`,
     );
     process.exitCode = 1;
     return;
@@ -1106,7 +1096,19 @@ async function recordAdoptedCommand() {
     }
   }
 
-  await recordCore(DEST_ROOT, { name: core.manifest.name, version: core.version, adopted: true });
+  const templateFile = (
+    await plannedFiles({
+      type: 'file',
+      root: core.root,
+      from: core.manifest.template,
+      to: '.hedgehog/CLAUDE.core.md',
+    })
+  )[0];
+  await writePlannedFile(templateFile);
+  written++;
+  console.log(`  ${green('install')}  ${relative(DEST_ROOT, templateFile.dest)}`);
+
+  await recordCore(DEST_ROOT, { name: core.manifest.name, version: core.version });
 
   console.log(
     `\n${green(bold('Adopted core recorded.'))} ${dim(

package/package.json

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

package/src/agents/planner.md

@@ -31,7 +31,8 @@ You run on two paths, and Workflow step 2 decides which:
   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.
+  goes. New change-work on an **adopted** core is a separate case again —
+  see "An existing repo, ongoing adoption" below.
 
 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
@@ -200,14 +201,14 @@ none of them is a description matching a `when` paragraph:
   repo", "add Hedgehog to my existing project", "I want scope/verify
   enforcement on my changes here"). This is a distinct question from
   everything above: it's not about which core fits new work, because no
-  new workspace gets built at all. Route straight to `hedgehog-adopt` —
-  bootstrap and every other Phase 0 outcome are skipped entirely, since
-  there is no workspace to scaffold and no shipped stack to adopt toward.
-  `hedgehog-adopt` runs its own read-only intake and writes its own
-  `.hedgehog/core.yaml`; don't run `hedgehog-planning-intake`'s BMAD shelf
-  first — the drivers that skill elicits (persistence, stack, deployment
-  target) are already settled facts of the existing repo, not open
-  decisions.
+  new workspace gets built at all. This project gets the **adopted
+  core**. Route straight to `hedgehog-adopt` — bootstrap and every other
+  Phase 0 outcome are skipped entirely, since there is no workspace to
+  scaffold and no shipped stack to adopt toward. `hedgehog-adopt` runs
+  its own read-only intake and writes its own `.hedgehog/core.yaml`;
+  don't run `hedgehog-planning-intake`'s BMAD shelf first — the drivers
+  that skill elicits (persistence, stack, deployment target) are already
+  settled facts of the existing repo, not open decisions.
 
 State the decision plainly before Phase 1 begins, with the one-line
 reason it landed there — this is cheap to correct now and expensive once
@@ -375,7 +376,7 @@ as full-stack-app's Auth/Queue/Mobile trio.
   the build graph.
 - **landing-page**: owns `.hedgehog/BMAD/` and
   `.hedgehog/chain/00-brief.md` as artifacts.
-- **brownfield adoption**: owns nothing here — `hedgehog-adopt` owns
+- **adopted**: owns nothing here — `hedgehog-adopt` owns
   `.hedgehog/core.yaml` and `.hedgehog/adoption.md`, the same way an
   authored core's design is `hedgehog-core-design`'s.
 

package/src/agents/reviewer.md

@@ -30,7 +30,8 @@ Everything the commit gate already enforces — the layer's own `verify`
 command, and whatever typecheck/lint/test it runs — is out of scope;
 don't re-report a green gate. Read the core's own design first: its loop
 skill for a shipped core, `.hedgehog/core.yaml` and
-`.hedgehog/core-design.md` for an authored one. That is where the layer
+`.hedgehog/core-design.md` for an authored one, `.hedgehog/core.yaml` and
+`.hedgehog/adoption.md` for an adopted one. That is where the layer
 boundaries, the interface between them, and this core's own conventions
 are stated. Your checklist is derived from it, not from a stack you
 recognize.
@@ -96,7 +97,7 @@ Check what the gate structurally cannot:
 - Don't nitpick style. Focus on structural correctness relative to the
   stack and build order the core's own design fixed — its loop and
   bootstrap skills on a shipped core, `.hedgehog/core-design.md` on an
-  authored one.
+  authored one, `.hedgehog/adoption.md` on an adopted one.
 - 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, then makes a single one-time, no-pressure mention that Hedgehog itself takes contributions via `ROADMAP.md`. Shared by every core with a Stop Condition — not an adopted repo (`hedgehog-adopt`), which has none; there, new change-work goes straight through `hedgehog-adopt` and `hedgehog-authored-loop` instead.
+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, then makes a single one-time, no-pressure mention that Hedgehog itself takes contributions via `ROADMAP.md`. Shared by every core with a Stop Condition — not the `adopted` core, which has none; there, new change-work goes straight through `hedgehog-adopt` and `hedgehog-authored-loop` instead.
 model: sonnet
 color: green
 tools: Read, Glob, Grep, Edit, Write, Bash
@@ -15,7 +15,7 @@ conversation. You start from a cleared context on purpose. Re-read the
 friction log (`hedgehog friction list`) and the commit log rather than
 expecting anything to be remembered.
 
-**Not for an adopted repo (`.hedgehog/core.yaml` written by
+**Not for the `adopted` core (`.hedgehog/core.yaml` written by
 `hedgehog-adopt`).** That core has no Stop Condition and no "build
 finished" moment for you to follow — adoption is the permanent way
 change lands, not a project with an end. A request there is just the
@@ -44,8 +44,8 @@ straight to job 1.
 
 None of its own — you work inside whichever core's stack is already
 installed (a shipped core's, or the stack an authored core's
-`.hedgehog/core-design.md` names — an adopted repo never reaches you, per
-the note above), editing the same files the core's own build agents
+`.hedgehog/core-design.md` names — the `adopted` core never reaches you,
+per the note above), 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.
 

package/src/hosts/claude-md-merge.mjs

@@ -13,7 +13,7 @@
 // instead of substituting into one.
 //
 // Referenced by name (not substance) from hedgehog-adopt's own SKILL.md
-// in the @skyf0xx/hedgehog-core-authored package — that skill invokes
+// in the @skyf0xx/hedgehog-core-adopted package — that skill invokes
 // `appendCoreSection` the same way it already invokes `loadCore` from
 // src/db/core.mjs, via `node -e "import('<path-to-hedgehog-install>/
 // src/hosts/claude-md-merge.mjs')..."`.

package/src/hosts/gemini/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hedgehog",
-  "version": "6.0.5",
+  "version": "6.1.0",
   "description": "Hedgehog build discipline: ordered, tested, verified build steps.",
   "contextFileName": "GEMINI.md"
 }

package/src/registry/cores.json

@@ -39,10 +39,18 @@
     {
       "name": "authored",
       "package": "@skyf0xx/hedgehog-core-authored",
-      "version": "^1.0.2",
+      "version": "^1.1.0",
       "language": "typescript",
       "repository": "https://github.com/skyf0xx/hedgehog-core-authored",
-      "selects_when": "Neither shipped core fits, but the description names a real artifact a Builder step would produce — just not in either shipped core's shape. This core is designed by the planner rather than chosen from a fixed set: hedgehog-planning-intake's Phase 0 elicits the drivers first, then hedgehog-core-design names the system shape, picks the stack, derives the layers, and writes .hedgehog/core.yaml. It carries the same enforcement as a shipped core — ordered layers, scoped file access, verification before completion — but the sequence is designed for this project rather than battle-tested across many."
+      "selects_when": "Neither shipped core fits, but the description names a real artifact a Builder step would produce — just not in either shipped core's shape. This core is designed by the planner rather than chosen from a fixed set: hedgehog-planning-intake's Phase 0 elicits the drivers first, then hedgehog-core-design names the system shape, picks the stack, derives the layers, and writes .hedgehog/core.yaml. It carries the same enforcement as a shipped core — ordered layers, scoped file access, verification before completion — but the sequence is designed for this project rather than battle-tested across many. This is the core most often confused with adopted: authored designs a workspace from scratch for a project being built new, while adopted brings Hedgehog's discipline to a repo that already exists — route here only when there is no existing codebase this work is being added to."
+    },
+    {
+      "name": "adopted",
+      "package": "@skyf0xx/hedgehog-core-adopted",
+      "version": "^1.0.0",
+      "language": "typescript",
+      "repository": "https://github.com/skyf0xx/hedgehog-core-adopted",
+      "selects_when": "The description is about bringing Hedgehog's discipline to a codebase that already exists, rather than building something new — the repo already has real source files, or the user says so explicitly: \"adopt this repo\", \"add Hedgehog to my existing project\", \"I want scope/verify enforcement on my changes here\". Not chosen by matching a `when` paragraph the way a shipped core is: hedgehog-adopt reads the repo read-only, proposes a linear-chain .hedgehog/core.yaml whose verify commands are the repo's own, and writes only .hedgehog/ — never a workspace, never a stack migration. This is the core most often confused with authored: adopted brings discipline to an existing repo, while authored designs and scaffolds a workspace from scratch for something being built new — route here only when the work is landing on a codebase that already exists."
     }
   ]
 }

package/src/registry/installed.mjs

@@ -7,21 +7,19 @@
 // the core — `installedCore` returns null until then, and `update` limits
 // itself to the shared payload.
 //
-// `authored` has a second entry point with no `init` step at all:
-// `hedgehog-adopt` brings the discipline to a repo that already exists by
-// writing `.hedgehog/core.yaml` itself, directly, and never calls
-// `recordCore` (see that skill, shipped in
-// @skyf0xx/hedgehog-core-authored — adoption has no npm package of its
-// own to fetch, just a core.yaml and adoption.md derived from the
-// existing repo). `hedgehog core record-adopted` (bin/cli.mjs) is the
-// record path for that case instead: it lands the authored package's
-// agents/skills — otherwise never installed, since adoption's `init` runs
-// with no `--core` flag and `bootstrap` is skipped entirely for adoption
-// — and calls `recordCore` with `adopted: true`. That flag is the one
-// thing distinguishing an adopted record from a normal one: `update`'s
-// resolveInstalledCore refreshes an adopted project's payload the same as
-// any other (same package, same agents/skills, kept current) but must
-// never treat `record.name` changing upstream, or the record going
+// `adopted` has no `init` step at all: `hedgehog-adopt` (shipped in
+// @skyf0xx/hedgehog-core-adopted) brings the discipline to a repo that
+// already exists by writing `.hedgehog/core.yaml` itself, directly, and
+// never calls `recordCore`. `hedgehog core record-adopted` (bin/cli.mjs)
+// is the record path for that case instead: it fetches the `adopted`
+// package and lands its agents/skills — otherwise never installed, since
+// adoption's `init` runs with no `--core` flag and `bootstrap` is skipped
+// entirely for adoption — and calls `recordCore` the same as any other
+// core, naming `adopted`. That name is the one thing distinguishing an
+// adopted record from a normal one: `update`'s resolveInstalledCore
+// refreshes an adopted project's payload the same as any other (same
+// package, same agents/skills, kept current) but must never treat
+// `record.name === 'adopted'` changing upstream, or the record going
 // missing, as license to fetch and install a *different* core the way it
 // would for a project that chose one at `init` — adoption's core is a
 // fixed fact of the repo (its `.hedgehog/core.yaml`), not a choice
@@ -30,38 +28,34 @@
 import { readFile, writeFile, mkdir } from 'node:fs/promises';
 import { dirname, join } from 'node:path';
 
-export const ADOPTED_CORE_NAME = 'authored';
+export const ADOPTED_CORE_NAME = 'adopted';
 
 const CORE_PATH = '.hedgehog/core.json';
 
 /**
  * Record the core a project installed and the exact version resolved for
  * it. Written after the core's files land, so the record describes what
- * is on disk. `adopted: true` marks a record written by `hedgehog core
- * record-adopted` rather than by `init` — see the module comment above.
+ * is on disk.
  */
-export async function recordCore(root, { name, version, adopted = false }) {
+export async function recordCore(root, { name, version }) {
   const path = join(root, CORE_PATH);
   await mkdir(dirname(path), { recursive: true });
   await writeFile(
     path,
-    `${JSON.stringify(
-      { core: name, version, installedAt: new Date().toISOString(), ...(adopted ? { adopted: true } : {}) },
-      null,
-      2,
-    )}\n`,
+    `${JSON.stringify({ core: name, version, installedAt: new Date().toISOString() }, null, 2)}\n`,
   );
 }
 
 /**
- * The core `update` should refresh — `{ name, version, adopted }` — or
- * null when this project has no core installed yet. `adopted` is always a
- * boolean, `false` for every record `init` writes.
+ * The core `update` should refresh — `{ name, version }` — or null when
+ * this project has no core installed yet. `name === 'adopted'` marks a
+ * record written by `hedgehog core record-adopted` rather than by `init`
+ * — see the module comment above.
  */
 export async function installedCore(root) {
   try {
-    const { core, version, adopted } = JSON.parse(await readFile(join(root, CORE_PATH), 'utf8'));
-    return core ? { name: core, version, adopted: adopted === true } : null;
+    const { core, version } = JSON.parse(await readFile(join(root, CORE_PATH), 'utf8'));
+    return core ? { name: core, version } : null;
   } catch {
     return null;
   }

package/src/registry/manifest.mjs

@@ -11,7 +11,6 @@
 //   engine: "^<major>.<minor>.<patch>" which CLI versions can install it
 //   workspace: workspace/              omitted by a core that scaffolds nothing
 //   template: CLAUDE.core.md           fills the CLAUDE.md shell's core section
-//   template_adopted: <path>           optional second section, for adoption
 //   agents: [<name>, ...]              agents/<name>.md in the package
 //   skills: [<name>, ...]              skills/<name>/ in the package
 //   vendor_skills: [<name>, ...]       vendor-skills/<name>/ in the package