@skyf0xx/hedgehog 3.0.2 → 3.0.3

package/README.md

@@ -117,11 +117,12 @@ npx @skyf0xx/hedgehog init
 
 Then open Claude Code and describe what you want to build.
 
-Plain `init` (no core flag) scaffolds a placeholder — planning intake
-designs an opinionated build order and stack for what you actually
-describe, then bootstrap replaces the placeholder with the real
-workspace. Don't pick `--ts-full-stack-app` or `--landing-page` by
-elimination when neither actually fits.
+Plain `init` (no core flag) installs the agents, skills, and build graph
+only — no workspace, no framework, nothing core-specific. Planning
+intake designs an opinionated build order and stack for what you
+actually describe, then bootstrap lands that workspace for the first
+time. Don't pick `--ts-full-stack-app` or `--landing-page` by elimination
+when neither actually fits.
 
 To update:
 

package/bin/cli.mjs

@@ -3,8 +3,9 @@
 // into the current repo, so the discipline travels with the project.
 //
 // Usage:
-//   npx @skyf0xx/hedgehog init                        scaffold, ts-full-stack-app core (default)
-//   npx @skyf0xx/hedgehog init --landing-page          scaffold the landing-page core instead
+//   npx @skyf0xx/hedgehog init                        no workspace yet — planner picks the core
+//   npx @skyf0xx/hedgehog init --ts-full-stack-app     scaffold the full-stack-app core now
+//   npx @skyf0xx/hedgehog init --landing-page          scaffold the landing-page core now
 //   npx @skyf0xx/hedgehog init --force                 overwrite files that already exist
 //   npx @skyf0xx/hedgehog update                       refresh .claude/agents + .claude/skills
 //   npx @skyf0xx/hedgehog --help
@@ -74,8 +75,16 @@ async function availableCores() {
 // Agents and skills for every core install regardless of which one is
 // chosen — planner needs the full toolset to run core selection at all,
 // and a project can only switch cores before it's bootstrapped anyway.
+//
+// `core` is `null` on a deferred install (plain `init`, no explicit
+// flag): which core applies hasn't been decided yet, so nothing
+// core-specific — no golden-core workspace, no filled CLAUDE.md section —
+// gets written speculatively. `bootstrap` lands the real workspace, for
+// whichever core `planner` picks, the first time either way. An explicit
+// flag (`--ts-full-stack-app`, `--landing-page`) is a confirmed choice,
+// not a guess, so it scaffolds immediately as before.
 function plan(core) {
-  return [
+  const base = [
     { type: 'dir', from: 'src/agents', to: '.claude/agents' },
     { type: 'dir', from: 'src/skills', to: '.claude/skills' },
     // The vendored BMAD-METHOD planning shelf that hedgehog-planning-intake
@@ -85,26 +94,26 @@ function plan(core) {
     // The vendored GSAP animation skill shelf that front-end-eng loads for
     // motion work — same repo-root-relative referencing as skills/BMAD.
     { type: 'dir', from: 'skills/GSAP', to: 'skills/GSAP' },
+  ];
+
+  if (core === null) {
+    return [
+      ...base,
+      // The shell with its {{CORE_SECTION}} placeholder left unfilled —
+      // whichever bootstrap-core skill runs first fills it in for the
+      // core planner actually picked.
+      { type: 'file', from: 'src/templates/CLAUDE.md', to: 'CLAUDE.md' },
+    ];
+  }
+
+  return [
+    ...base,
     {
       type: 'merge',
       shell: 'src/templates/CLAUDE.md',
       include: `src/templates/CLAUDE.core.${core}.md`,
       to: 'CLAUDE.md',
     },
-    // The shell plus the authored-core section, landed unmerged so
-    // `hedgehog-bootstrap-authored-core` can rebuild CLAUDE.md from them
-    // when planning intake designs a core instead of taking a shipped
-    // one. Removed by that same step once it has used them.
-    {
-      type: 'file',
-      from: 'src/templates/CLAUDE.md',
-      to: '.hedgehog/templates/CLAUDE.md',
-    },
-    {
-      type: 'file',
-      from: 'src/templates/CLAUDE.core.authored.md',
-      to: '.hedgehog/templates/CLAUDE.core.authored.md',
-    },
     // The pre-built, pre-verified workspace for the chosen core —
     // everything a fresh project of that shape needs at repo root
     // (lands the root package.json too, so there's no separate
@@ -182,9 +191,9 @@ CLAUDE.md template and an empty build graph (${bold('.hedgehog/hedgehog.db')})
 into the repo root, so the discipline is committed alongside your code.
 
 ${bold('Usage')}
-  npx @skyf0xx/hedgehog init                      scaffold, ${DEFAULT_CORE} core (default)
-  npx @skyf0xx/hedgehog init --ts-full-stack-app  scaffold the full-stack-app core explicitly
-  npx @skyf0xx/hedgehog init --landing-page       scaffold the landing-page core instead
+  npx @skyf0xx/hedgehog init                      no workspace yet — planner picks the core
+  npx @skyf0xx/hedgehog init --ts-full-stack-app  scaffold the full-stack-app core now
+  npx @skyf0xx/hedgehog init --landing-page       scaffold the landing-page core now
   npx @skyf0xx/hedgehog init --force              overwrite existing files
   npx @skyf0xx/hedgehog update                    refresh .claude/agents + .claude/skills
   npx @skyf0xx/hedgehog db init                   create .hedgehog/hedgehog.db if absent
@@ -208,10 +217,10 @@ off to bootstrap.
 Building something else (a CLI, library, browser extension, data
 pipeline, desktop app, etc.)? Run plain 'init' with no core flag rather
 than picking --ts-full-stack-app or --landing-page by elimination — it
-scaffolds ${DEFAULT_CORE}'s payload as a placeholder, but the planner
-agent designs and switches in an authored core at planning intake
-(hedgehog-core-design) before any workspace is generated for real.
-Describe the actual project and let Phase 0 route it.
+installs the agents, skills, and build graph only, nothing core-specific.
+The planner agent designs a core at planning intake (hedgehog-core-design)
+and bootstrap generates that workspace once it's confirmed. Describe the
+actual project and let Phase 0 route it.
 
 ${bold('update')} re-copies only .claude/agents and .claude/skills from the
 installed Hedgehog version, so an already-bootstrapped project can pick up
@@ -223,19 +232,22 @@ updated deliberately, not by this command.
 }
 
 async function init({ force, core, explicitCore }) {
-  const cores = await availableCores();
-  if (!cores.includes(core)) {
-    console.error(
-      `${red('Unknown core:')} ${core}\n\nAvailable cores: ${cores.join(', ')}\n`,
-    );
-    process.exitCode = 1;
-    return;
+  if (explicitCore) {
+    const cores = await availableCores();
+    if (!cores.includes(core)) {
+      console.error(
+        `${red('Unknown core:')} ${core}\n\nAvailable cores: ${cores.join(', ')}\n`,
+      );
+      process.exitCode = 1;
+      return;
+    }
   }
 
   // Resolve the full list of writes up front so we can detect conflicts
-  // before touching anything.
+  // before touching anything. A deferred install (no explicit core) plans
+  // against `null` — no golden-core workspace, nothing core-specific.
   const groups = [];
-  for (const entry of plan(core)) {
+  for (const entry of plan(explicitCore ? core : null)) {
     const files = await plannedFiles(entry);
     groups.push({ entry, files });
   }
@@ -282,30 +294,40 @@ async function init({ force, core, explicitCore }) {
     )}\n`,
   );
   console.log('Next steps:');
-  console.log(`  1. ${bold('git add -A && git commit -m "chore: install Hedgehog"')}`);
-  console.log(`  2. ${bold('pnpm install')}`);
-  console.log(`  3. Open Claude Code and describe what you want to build.`);
+  if (explicitCore) {
+    console.log(`  1. ${bold('git add -A && git commit -m "chore: install Hedgehog"')}`);
+    console.log(`  2. ${bold('pnpm install')}`);
+    console.log(`  3. Open Claude Code and describe what you want to build.`);
+  } else {
+    console.log(`  1. ${bold('git add -A && git commit -m "chore: install Hedgehog"')}`);
+    console.log(`  2. Open Claude Code and describe what you want to build.`);
+  }
   console.log(
     dim(
       `     The ${bold('planner')} agent runs planning intake, then hands off to bootstrap.`,
     ),
   );
   console.log();
-  console.log(
-    dim(
-      explicitCore
-        ? `Core: ${bold(core)}.`
-        : `Core: ${bold(core)} (installer default — planner may design an authored core instead).`,
-    ),
-  );
-  console.log(
-    dim(
-      core === DEFAULT_CORE
-        ? '(Nx, packages/config, packages/db, apps/api, apps/web) — bootstrap\n' +
-            'runs whichever add-ons (Auth, Queue, Mobile) intake calls for.'
-        : 'bootstrap runs whichever add-on steps this core defines, if any.',
-    ),
-  );
+  if (explicitCore) {
+    console.log(dim(`Core: ${bold(core)}.`));
+    console.log(
+      dim(
+        core === DEFAULT_CORE
+          ? '(Nx, packages/config, packages/db, apps/api, apps/web) — bootstrap\n' +
+              'runs whichever add-ons (Auth, Queue, Mobile) intake calls for.'
+          : 'bootstrap runs whichever add-on steps this core defines, if any.',
+      ),
+    );
+  } else {
+    console.log(
+      dim(
+        'Core: not chosen yet. Nothing core-specific landed — no workspace,\n' +
+          'no framework, no lockfile. planner decides which core applies at\n' +
+          'planning intake, then bootstrap lands that core\'s workspace for\n' +
+          'the first time.',
+      ),
+    );
+  }
 }
 
 async function update() {
@@ -359,8 +381,10 @@ async function dbCommand(args) {
 
 // Resolves the project's core definition: an authored .hedgehog/core.yaml
 // takes precedence (spec: "Authored cores"); otherwise the shipped Golden
-// Core landed at repo root by `init` (its core.yaml copies there along
-// with the rest of src/golden-cores/<core>).
+// Core landed at repo root by `bootstrap` (its core.yaml copies there
+// along with the rest of src/golden-cores/<core>). Neither exists yet on
+// a deferred install (plain `init`, no explicit core flag) until
+// `bootstrap` runs — this returns null until then.
 async function resolveCorePath() {
   if (await exists(join(DEST_ROOT, AUTHORED_CORE_PATH))) {
     return join(DEST_ROOT, AUTHORED_CORE_PATH);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog",
-  "version": "3.0.2",
+  "version": "3.0.3",
   "description": "Install the Hedgehog build discipline (agents + skills) into a repo.",
   "type": "module",
   "repository": {

package/src/agents/bootstrap.md

@@ -1,6 +1,6 @@
 ---
 name: bootstrap
-description: Use once per invocation, at the start of a new Hedgehog project, to land the workspace for whichever core `planner` selected at Phase 0. On full-stack-app, that's core (via hedgehog-bootstrap-full-stack-app-core, one pass) then exactly ONE add-on step of the hedgehog-bootstrap skill (0-3 steps depending on planning intake scope), handing off to a fresh instance of itself for the next add-on step. On landing-page, that's a single pass of hedgehog-bootstrap-landing-page-core with no add-on steps — one invocation, done. On an authored core (`.hedgehog/core.yaml` present), that's a single pass of hedgehog-bootstrap-authored-core, which also removes whatever default golden-core scaffold `init` speculatively landed before generating the real workspace. Not for per-phase/per-module work — that's this core's own loop skill and its agents. Skip entirely if the core's workspace already exists (nx.json for full-stack-app, astro.config.mjs for landing-page, or the matching `feat(<id>): workspace` commit for an authored core).
+description: Use once per invocation, at the start of a new Hedgehog project, to land the workspace for whichever core `planner` selected at Phase 0 — the first real workspace this project gets, since `init` with no explicit core flag lands only agents/skills/the build graph, nothing core-specific. On full-stack-app, that's core (via hedgehog-bootstrap-full-stack-app-core, one pass) then exactly ONE add-on step of the hedgehog-bootstrap skill (0-3 steps depending on planning intake scope), handing off to a fresh instance of itself for the next add-on step. On landing-page, that's a single pass of hedgehog-bootstrap-landing-page-core with no add-on steps — one invocation, done. On an authored core (`.hedgehog/core.yaml` present), that's a single pass of hedgehog-bootstrap-authored-core, generating the workspace live for the stack `hedgehog-core-design` chose. Not for per-phase/per-module work — that's this core's own loop skill and its agents. Skip entirely if the core's workspace already exists (nx.json for full-stack-app, astro.config.mjs for landing-page, or the matching `feat(<id>): workspace` commit for an authored core).
 model: sonnet
 color: green
 tools: Read, Glob, Grep, Edit, Write, Bash
@@ -27,10 +27,7 @@ What "bootstrap" means differs by core:
   there's no "next step" to hand off to.
 - **an authored core** (`.hedgehog/core.yaml` present, written by
   `hedgehog-core-design`) has one part, no add-on layer, like
-  landing-page: `hedgehog-bootstrap-authored-core` first removes whatever
-  default golden-core scaffold `init` speculatively landed (`init` always
-  scaffolds `full-stack-app` by default, since the CLI has to copy
-  something before `planner` ever runs Phase 0), then generates a fresh
+  landing-page: `hedgehog-bootstrap-authored-core` generates a fresh
   workspace live for the stack `hedgehog-core-design` chose — there's no
   pre-built template for an authored core's stack the way there is for
   the two shipped cores — verifies it, one commit. One invocation closes
@@ -145,10 +142,9 @@ Bootstrap is already closed and `hedgehog-authored-loop` owns everything
 from here (stop, say so).
 
 Open `hedgehog-bootstrap-authored-core` and follow it in full: confirm not
-already run, clear the default scaffold `init` landed (`nx.json` at repo
-root is the tell) and rebuild root `CLAUDE.md` from
-`.hedgehog/templates/`, read the stack choice from
-`.hedgehog/core-design.md` and `.hedgehog/core.yaml`, generate that
+already run, fill root `CLAUDE.md`'s `{{CORE_SECTION}}` placeholder with
+`CLAUDE.core.authored.md` if it's still unfilled, read the stack choice
+from `.hedgehog/core-design.md` and `.hedgehog/core.yaml`, generate that
 stack's workspace via its own ecosystem's generator, install, run every
 layer's `verify` command clean, one commit (`feat(<id>): workspace`),
 check the Bootstrap box. That's the whole of Bootstrap on this core —
@@ -167,8 +163,8 @@ there's no next Bootstrap step.
   add-on-style steps for this core; it doesn't have any.
 - **authored core**: one pass, one commit, no hand-off, no add-on layer.
   This pass generates the workspace from the stack in
-  `.hedgehog/core-design.md` and clears the default scaffold `init`
-  landed; `hedgehog-bootstrap-authored-core` owns both.
+  `.hedgehog/core-design.md` and fills root `CLAUDE.md`'s core section;
+  `hedgehog-bootstrap-authored-core` owns both.
 - Never re-run a step whose commit already exists — see the per-core
   "which step is yours" sections above. A felt need to redo a landed
   step is a Correction Protocol case (patch it at its source, per that

package/src/skills/hedgehog-bootstrap-authored-core/SKILL.md

@@ -1,25 +1,17 @@
 ---
 name: hedgehog-bootstrap-authored-core
-description: Use once, at the start of a new Hedgehog project on an authored core (`hedgehog-core-design` wrote `.hedgehog/core.yaml`), to clear the default scaffold `init` landed and generate a verified workspace for the stack `hedgehog-core-design` chose. Runs as the `bootstrap` agent's only move on this core, and closes Bootstrap.
+description: Use once, at the start of a new Hedgehog project on an authored core (`hedgehog-core-design` wrote `.hedgehog/core.yaml`), to generate a verified workspace for the stack `hedgehog-core-design` chose. Runs as the `bootstrap` agent's only move on this core, and closes Bootstrap.
 ---
 
 # Hedgehog Bootstrap — authored core
 
 Lands the workspace for a project whose core `hedgehog-core-design`
-designed. The stack varies per project (that skill's Step 2 stack
-table), so this workspace is generated live from the ecosystem's own
-tooling and verified before it's committed.
-
-## Why this exists
-
-`hedgehog init` scaffolds a default golden-core payload before `planner`
-runs Phase 0 — a CLI has to pick something to copy, and `full-stack-app`
-is that default (`bin/cli.mjs`'s `DEFAULT_CORE`). When Phase 0 designs a
-core instead, that scaffold (`nx.json`, `packages/`, `apps/api`,
-`apps/web`, the root `package.json`, full-stack-app's section of root
-`CLAUDE.md`) is speculative output this project never confirmed. Clearing
-it is this skill's first job: left in place, it collides with the
-generated workspace on `package.json`, lockfiles, and root config.
+designed. `hedgehog init` never scaffolds anything core-specific until a
+core is actually chosen, so nothing needs clearing here — this skill is
+the first thing that writes a workspace for this project. The stack
+varies per project (`hedgehog-core-design`'s Step 2 stack table), so it's
+generated live from the ecosystem's own tooling and verified before it's
+committed.
 
 ## Steps
 
@@ -33,43 +25,19 @@ produce (e.g. `wxt.config.ts` for a WXT browser extension,
 there. A workspace that looks wrong is a Correction Protocol case against
 the specific file.
 
-### 2. Remove the speculative default scaffold
-
-`init` lands `full-stack-app`'s golden-core payload by default, so
-`nx.json` at the repo root is the tell. Its presence means the scaffold
-is still in place; clear it before generating the real workspace:
-
-- Delete these root files: `nx.json`, `package.json`,
-  `pnpm-workspace.yaml`, `pnpm-lock.yaml`, `docker-compose.yml`,
-  `core.yaml` (full-stack-app's own core definition — the authored one
-  lives at `.hedgehog/core.yaml`), `tsconfig.json`, `tsconfig.base.json`,
-  `vitest.workspace.ts`, `eslint.config.mjs`, `commitlint.config.cjs`,
-  `lefthook.yml`, `.env.example`, `.prettierrc`, `.prettierignore`,
-  `.gitignore`.
-- Delete these root directories in full: `packages/` (`config`, `db`),
-  `apps/` (`api`, `api-e2e`, `web`, `web-e2e`), `tools/`
-  (`phase-gate.cjs`), `.github/` (`workflows/phase-gate.yml`),
-  `.vscode/`. None of it was ever installed — `pnpm install` hasn't run
-  on a fresh `init` — so this removes scaffolded source files, with no
-  running infra and no data involved.
-- The generator in step 4 lands its own `.gitignore`; if it doesn't,
-  write one for the chosen stack before committing.
-- Rebuild root `CLAUDE.md` from the templates `init` landed in
-  `.hedgehog/templates/`: take `CLAUDE.md` (the shell) and replace its
-  `{{CORE_SECTION}}` placeholder with the full contents of
-  `CLAUDE.core.authored.md`. Carry over the `{{PROJECT_NAME}}` and
-  `{{PROJECT_SUMMARY}}` values `planner` already filled into the current
-  root `CLAUDE.md` — those are project content, written at planning
-  intake, and the rebuild must not blank them. Delete
-  `.hedgehog/templates/` once the rebuild lands; it exists for this one
-  step.
-- Leave `.claude/agents/`, `.claude/skills/`, `skills/BMAD/`,
-  `skills/GSAP/`, and the rest of `.hedgehog/` in place — the build
-  graph, the planning archive, and the design files this step reads from
-  install the same regardless of which core Phase 0 picks.
-
-`nx.json` absent means the scaffold was already cleared — skip straight
-to the `CLAUDE.md` rebuild, which still applies.
+### 2. Fill in `CLAUDE.md`'s core section
+
+Root `CLAUDE.md` was landed by `init` as a shell with its
+`{{CORE_SECTION}}` placeholder still unfilled (no core was known yet).
+Read `src/templates/CLAUDE.core.authored.md` from the installed Hedgehog
+package and write its contents in place of the placeholder — every other
+line in root `CLAUDE.md`, including the `{{PROJECT_NAME}}`/
+`{{PROJECT_SUMMARY}}` values `planner` already filled at planning intake,
+stays untouched.
+
+If the placeholder is already filled (a project that ran `init` with an
+explicit core flag and only reached an authored core through a later
+redesign), this step is a no-op — move on.
 
 ### 3. Read the stack choice
 
@@ -151,9 +119,6 @@ core's bootstrap, which closes Bootstrap. State plainly that
 - Write no domain content in the generated workspace — no business
   logic, no first layer's files. That's the first build task, started
   once this Bootstrap commit lands.
-- Step 2's deletions are safe by construction: `init`'s default scaffold
-  has never been installed or run on a project that reaches this skill,
-  since Phase 0 completes before any `pnpm install`. It's unused
-  template output.
-- A repo with no default scaffold at all makes step 2 a no-op on the
-  workspace files; the `CLAUDE.md` rebuild still runs.
+- Never overwrite `{{PROJECT_NAME}}`/`{{PROJECT_SUMMARY}}` in root
+  `CLAUDE.md` while filling `{{CORE_SECTION}}` — those are `planner`'s
+  content, not this skill's.

package/src/skills/hedgehog-bootstrap-full-stack-app-core/SKILL.md

@@ -86,14 +86,18 @@ natively-installed Postgres. See **Local infra: Docker, always** below.
 
 ### 3. Land `src/golden-cores/full-stack-app/`
 
-In the common case this is already done — `hedgehog init`'s installer
-copies `src/golden-cores/full-stack-app/` to the repo root at install time, the same way
-it copies `src/agents` to `.claude/agents`. Check whether the core files
-are already present (same check as step 1). If they're missing —
-`hedgehog init` ran against an older package version, or the files were
-deleted — copy `src/golden-cores/full-stack-app/`'s contents to the repo root now as a
-fallback. Either way, by the end of this step every file listed in "What
-lands" above should be on disk.
+`hedgehog init --ts-full-stack-app` copies `src/golden-cores/full-stack-app/`
+to the repo root at install time, the same way it copies `src/agents` to
+`.claude/agents` — check whether the core files are already present
+(same check as step 1) before copying again. On a project that ran
+plain `init` (no core flag) and only reaches `full-stack-app` because
+`planner` picked it at Phase 0, this hasn't happened yet: copy
+`src/golden-cores/full-stack-app/`'s contents to the repo root now. Also
+merge this core's `CLAUDE.md` section into root `CLAUDE.md`
+(`src/templates/CLAUDE.core.full-stack-app.md` fills the shell's
+`{{CORE_SECTION}}` placeholder left unfilled by a deferred install) —
+skip this if the section is already filled. Either way, by the end of
+this step every file listed in "What lands" above should be on disk.
 
 ### 4. Install and start local infra
 

package/src/skills/hedgehog-bootstrap-landing-page-core/SKILL.md

@@ -59,15 +59,18 @@ re-copy: patch the specific file at its source.
 
 ### 2. Land `src/golden-cores/landing-page/`
 
-In the common case this is already done — `hedgehog init --landing-page`'s
-installer copies `src/golden-cores/landing-page/` to the repo root at
-install time, the same way it copies `src/agents` to `.claude/agents`.
-Check whether the core files are already present (same check as step 1).
-If they're missing — `hedgehog init` ran against an older package
-version, or the files were deleted — copy
-`src/golden-cores/landing-page/`'s contents to the repo root now as a
-fallback. Either way, by the end of this step every file listed in "What
-lands" above should be on disk.
+`hedgehog init --landing-page` copies `src/golden-cores/landing-page/` to
+the repo root at install time, the same way it copies `src/agents` to
+`.claude/agents` — check whether the core files are already present
+(same check as step 1) before copying again. On a project that ran plain
+`init` (no core flag) and only reaches `landing-page` because `planner`
+picked it at Phase 0, this hasn't happened yet: copy
+`src/golden-cores/landing-page/`'s contents to the repo root now. Also
+merge this core's `CLAUDE.md` section into root `CLAUDE.md`
+(`src/templates/CLAUDE.core.landing-page.md` fills the shell's
+`{{CORE_SECTION}}` placeholder left unfilled by a deferred install) —
+skip this if the section is already filled. Either way, by the end of
+this step every file listed in "What lands" above should be on disk.
 
 ### 3. Install
 

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

@@ -239,10 +239,9 @@ runs `hedgehog-planning-intake`'s Phase 1 mining against this core the
 same way it would against a shipped one, then hands off to `bootstrap`.
 
 This skill never touches the workspace itself — no `pnpm init`, no
-generator, no install. `init` already scaffolded a default golden-core
-payload speculatively before Phase 0 ever ran (the CLI has to copy
-something; `full-stack-app` is that default), and this skill's job ends
-at the design artifacts. `bootstrap`'s `hedgehog-bootstrap-authored-core`
-is what later removes that speculative default and generates the real
+generator, no install. `hedgehog init` lands nothing core-specific until
+a core is chosen, so there's nothing on disk yet for this skill to
+conflict with; its job ends at the design artifacts. `bootstrap`'s
+`hedgehog-bootstrap-authored-core` is what later generates the real
 workspace for the stack chosen here — a separate step, run only once
 Phase 1 mining and Confirm & Lock have both landed.