@skyf0xx/hedgehog 6.1.0 → 6.1.1

package/bin/cli.mjs

@@ -424,6 +424,17 @@ async function writePlannedFile(f) {
       const existing = await readFile(f.dest, 'utf8');
       if (!existing.includes('{{PROJECT_NAME}}') && existing.includes('{{CORE_SECTION}}')) {
         out = existing;
+      } else if (!existing.includes('{{PROJECT_NAME}}') && !f.merge.include) {
+        // Brownfield: hand-written content that predates Hedgehog, with
+        // no shell markers at all, on the coreless deferred path (no
+        // `include` — there's no core section yet to fill in). Nothing
+        // to merge in here; the file is untouched until `hedgehog-adopt`
+        // later appends its own core section via appendCoreSection
+        // (src/hosts/claude-md-merge.mjs). Overwriting it with the
+        // greenfield shell, or even just filling {{HOST_DISPATCH}} into
+        // it, would assert a fresh-install shape onto a repo that isn't
+        // new.
+        return;
       }
     }
     if (out === null) out = await readFile(join(PKG_ROOT, f.merge.shell), 'utf8');
@@ -688,11 +699,26 @@ async function init({ force, core, host = DEFAULT_HOST, hostOnly = false, global
   // the project, so rewriting it loses nothing and never counts as a
   // conflict — that's what lets a second host be added to a project the
   // first one already set up.
+  //
+  // A deferred (coreless) install's root-instructions merge is exempted
+  // too, but only when the existing file is a brownfield one: hand-written
+  // content with no {{PROJECT_NAME}} shell marker. That file was never a
+  // Hedgehog shell to overwrite — writePlannedFile leaves it untouched,
+  // for hedgehog-adopt's own merge step to append its delimited core
+  // section into later (src/hosts/claude-md-merge.mjs), once a core is
+  // actually known. A file still carrying {{PROJECT_NAME}} (a previous
+  // deferred init's untouched shell) is not brownfield content and keeps
+  // hitting the ordinary conflict/--force path below.
   const conflicts = [];
   for (const { entry, files } of groups) {
     if (entry.type === 'generated') continue;
     for (const f of files) {
-      if (await exists(f.dest)) conflicts.push(f.dest);
+      if (!(await exists(f.dest))) continue;
+      if (core === null && f.merge) {
+        const existing = await readFile(f.dest, 'utf8');
+        if (!existing.includes('{{PROJECT_NAME}}')) continue;
+      }
+      conflicts.push(f.dest);
     }
   }
 
@@ -719,7 +745,15 @@ async function init({ force, core, host = DEFAULT_HOST, hostOnly = false, global
   for (const { files } of groups) {
     for (const f of files) {
       const already = await exists(f.dest);
+      // Brownfield CLAUDE.md on the coreless path: writePlannedFile
+      // leaves it untouched (see its own comment) rather than overwriting
+      // it, so this write must not be logged or counted as one.
+      const before = already && f.merge ? await readFile(f.dest, 'utf8') : null;
       await writePlannedFile(f);
+      if (before !== null && (await readFile(f.dest, 'utf8')) === before) {
+        console.log(`  ${dim('keep')}  ${relative(DEST_ROOT, f.dest)}`);
+        continue;
+      }
       if (already) overwritten++;
       else written++;
       const label = already ? yellow('overwrite') : green('create');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog",
-  "version": "6.1.0",
+  "version": "6.1.1",
   "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

@@ -202,9 +202,11 @@ none of them is a description matching a `when` paragraph:
   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. 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
+  core**. Run `hedgehog core record-adopted` first — a no-flag `init`
+  never fetched the `adopted` package, so `hedgehog-adopt` is not yet on
+  disk to route to — then route 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
@@ -389,18 +391,23 @@ as full-stack-app's Auth/Queue/Mobile trio.
      run.** Continue at step 3.
    - **No intents in the graph, and the request is adoption onto an
      existing repo → brownfield first run.** Skip Phase 0's core
-     selection and every step below through step 9 — go straight to
-     `hedgehog-adopt`. It runs its own intake and Confirm & Lock, writes
-     `.hedgehog/core.yaml` and `.hedgehog/adoption.md`, and adds the
-     first intent(s) itself. Return the summary (step 10) once it's done.
+     selection and every step below through step 9. Run `hedgehog core
+     record-adopted` first — a no-flag `init` never fetched the
+     `adopted` package, so `hedgehog-adopt` is not yet on disk — then go
+     straight to `hedgehog-adopt`. It runs its own intake and Confirm &
+     Lock, writes `.hedgehog/core.yaml` and `.hedgehog/adoption.md`, and
+     adds the first intent(s) itself. Return the summary (step 10) once
+     it's done.
    - **One or more intents, on `.hedgehog/core.yaml` written by
      `hedgehog-adopt` → adoption re-entry.** New change-work on a repo
-     already under adoption. Skip steps 3 through 9 — route straight to
-     `hedgehog-adopt` again instead, same as brownfield first run above.
-     It owns everything the other path's steps 5, 7, 8, and 9 would
-     otherwise do: it sizes the request (a large or ambiguous one gets its
-     own short clarifying pass, a clear small one doesn't), adds the
-     intent(s), runs `hedgehog plan`, and commits its own work as `chore
+     already under adoption. Skip steps 3 through 9. Run `hedgehog core
+     record-adopted` first — safe and idempotent to re-run, and the only
+     guarantee that `hedgehog-adopt` is on disk in this session — then
+     route straight to `hedgehog-adopt` again, same as brownfield first
+     run above. It owns everything the other path's steps 5, 7, 8, and 9
+     would otherwise do: it sizes the request (a large or ambiguous one
+     gets its own short clarifying pass, a clear small one doesn't), adds
+     the intent(s), runs `hedgehog plan`, and commits its own work as `chore
      (planning): adopt change`. Don't run `hedgehog-planning-intake`'s
      Re-entry pass here — there is no BMAD archive to read as context on
      this path, since adoption never runs one. Return the summary (step

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

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