@skill-map/cli 0.53.2 → 0.53.4

package/dist/cli/tutorial/sm-tutorial/SKILL.md

@@ -132,18 +132,27 @@ Apply §Provider detection from `_core.md`. Persist the result into
 
 ### 4. Two-terminals heads-up (one time)
 
+Agent-only: in the `cd` block below, substitute `<cwd>` with the
+tester's actual cwd (the absolute path of the folder the tutorial is
+running in) so the command is copy-pasteable, same substitution as
+every other `<cwd>` mention.
+
 > ⚠️ Heads up: throughout the tutorial you'll be using **two
 > terminals**.
 >
 > 1. **This terminal**: the one you're using right now to talk to
 >    me (Claude Code). I show you the commands, you paste me the
 >    output, and I verify.
-> 2. **A second terminal**: open it now (new window or tab). In it
->    run `cd <cwd>` so it's anchored **exactly to this folder**.
+> 2. **A second terminal**: open it now (new window or tab), then run
+>    the command below so it's anchored **exactly to this folder**.
 >    That's where you copy and paste every `sm` command.
->
+
+```bash
+cd <cwd>
+```
+
 > Keep both terminals open until the end. If you accidentally close
-> the second one, reopen it and `cd <cwd>` again.
+> the second one, reopen it and run that `cd` again.
 >
 > Got the second terminal open and anchored to the folder? Confirm
 > before we move on.
@@ -151,9 +160,19 @@ Apply §Provider detection from `_core.md`. Persist the result into
 ### 5. Write the universal files and show the menu
 
 Pre-flight does NOT pre-lay any part's fixture and does NOT auto-enter
-a part. It writes only the two files every part needs, then routes to
-the menu:
-
+a part. It writes only the universal files every part needs, then
+routes to the menu:
+
+- `.skillmapignore` (block below). Universal, not a part fixture:
+  every part scans, and every part needs the tutorial's own machinery
+  kept out of the map (this skill's `.claude/skills/sm-tutorial/` dir,
+  `findings.md`, `tutorial-state.yml`, the CLI part's
+  `link-validation/`, and so on). Writing it here, once, before any
+  `sm init`, is what guarantees no part-entry can forget it on a
+  direct jump from the menu. `sm init` only writes `.skillmapignore`
+  when it is absent, so the tester's later `sm init` leaves this one
+  intact. Parts that need more append their own lines on entry (the
+  portfolio's `node_modules/` and `public/`).
 - `findings.md` (block below).
 - `tutorial-state.yml` (template below; it starts with `parts: {}`,
   empty, a part's entry is added the first time the tester picks it).
@@ -162,14 +181,30 @@ Then **route** per §Routing + menu in `_core.md`: render the **start
 menu** (numbered, Part 0 the prologue as option 1, the recommended
 first pick). The tester picks a part by number; that part's own
 `preflight` (see §Entering a part) lays its fixture when it begins.
-Part 0's demo fixture (the `demo-agent` + the demo `.skillmapignore`,
-blocks below) is laid by its `taught-init` entry, not here.
+Part 0's demo fixture (the `demo-agent` block below) is laid by its
+`taught-init` entry, not here.
 
 ## Fixture and state templates
 
-The `findings.md` and `tutorial-state.yml` here are universal (written
-in pre-flight); the `demo-agent.md` + the demo `.skillmapignore` are
-Part 0's fixture (laid by its `taught-init` entry).
+The `.skillmapignore`, `findings.md`, and `tutorial-state.yml` here are
+universal (written in pre-flight); the `demo-agent.md` is Part 0's
+fixture (laid by its `taught-init` entry).
+
+The **full Part 0 demo fixture** is the boot `demo-agent.md` above plus
+the files the prologue's own chapters lay as taught steps, exactly this
+set: `<provider_dir>/agents/demo-agent.md`,
+`<provider_dir>/skills/demo-skill/`,
+`<provider_dir>/commands/demo-command.md`, `notes/todo.md`,
+`notes/demo-guideline.md`, `notes/private-credentials.md`. This is the
+single source for that list. Four entry points delete exactly this set
+when the prologue ran first in the dir: `portfolio-init`, the campaign
+`seed` fast-forward, and `backstage-init` (Part 7), each so the part's
+own fixture starts from a clean slate, plus start-over (§Menu, resume,
+wrap-up). Part 8 `cli` is the inverse
+consumer: its `prologue-built` seed *lays* this fixture (the
+connector-chapter subset, without `notes/private-credentials.md`)
+instead of deleting it, see `fixtures.md` §Seed snapshots. Keep the list
+here in sync if a prologue chapter adds or drops a demo file.
 
 `<provider_dir>/agents/demo-agent.md`:
 ```markdown
@@ -275,60 +310,88 @@ When a part begins, honour its `preflight` from the manifest:
 
 - **`taught-init`** (Part 0): silently, before the tester's `sm init`
   in the `init` chapter, `Write` the demo fixture (the
-  `<provider_dir>/agents/demo-agent.md` boot node + the demo
-  `.skillmapignore`, both in the §Fixture blocks above), substituting
-  `<provider_dir>` per detection. Write `.skillmapignore` BEFORE the
-  tester runs `sm init` so the first scan never sees the tutorial's
-  own files (`sm init` only writes that file when absent). The tester
-  runs `sm init` themselves in the first chapter.
+  `<provider_dir>/agents/demo-agent.md` boot node, in the §Fixture
+  blocks above), substituting `<provider_dir>` per detection. The
+  universal `.skillmapignore` is already on disk from pre-flight, so
+  the first scan never sees the tutorial's own files; nothing to lay
+  here for it. The tester runs `sm init` themselves in the first
+  chapter (`sm init` only writes `.skillmapignore` when absent, so it
+  leaves the pre-flight one intact).
 - **`portfolio-init`** (Part 1 `project-kickoff`): the campaign's
   real project begins. Backstage, before the tester's `sm init` in
   the `kickoff` chapter: (1) if the prologue ran first in this dir,
-  clear its demo fixture so the map starts clean, delete ONLY the
-  Part 0 fixture files (`<provider_dir>/agents/demo-agent.md`,
-  `<provider_dir>/skills/demo-skill/`,
-  `<provider_dir>/commands/demo-command.md`, `notes/todo.md`,
-  `notes/demo-guideline.md`, `notes/private-credentials.md`) plus the
+  clear its demo fixture so the map starts clean, delete ONLY the full
+  Part 0 demo fixture set (§Fixture and state templates) plus the
   stale `.skill-map/` DB (a fresh `sm init` rebuilds it), never the
   tester's own files; (2) `Write` the portfolio fixture from
   `references/fixtures.md` (the Express skeleton + the handbook
-  `AGENTS.md`); (3) ensure `.skillmapignore` carries the portfolio
-  additions (`node_modules/`, `public/`). The tester runs `sm init`
+  `AGENTS.md`); (3) append the portfolio additions (`node_modules/`,
+  `public/`) to the universal `.skillmapignore` pre-flight already
+  wrote (its tutorial internals are already there). The tester runs `sm init`
   themselves in the first chapter. (The later campaign parts use
   `preflight: seed` to fast-forward into them directly, see the `seed`
   case below; `portfolio-init` is just Part 1's flavour of that,
   handling the Part 0 to Part 1 transition.)
-- **`backstage-init`** (Part 6 `extend`): silently, with no
-  narration: run `sm init --no-scan` from the cwd, then `Edit` the
-  freshly created `.skillmapignore` to append the tutorial's
-  internal entries (the `sm-tutorial.md` / `findings.md` /
-  `tutorial-state.yml` / skill-dir block above), then `Write` the
-  part's fixture (read `references/fixtures.md` for the verbatim
-  `master-agent` / `master-skill` / `notes/ideas` files; skip kinds
-  the provider doesn't claim). If `sm init --no-scan` fails because
-  the dir was already initialised by an earlier part, that is fine:
-  the DB already exists, skip the init and just ensure the fixture
+- **`backstage-init`** (Part 7 `extend`): the part teaches plugins on
+  its own **master fixture**, distinct from both the demo and the
+  portfolio, so on entry make the master fixture the only one on disk.
+  Silently, with no narration: (1) clear whatever prior-part fixture is
+  present so the master map starts clean (never the tester's own files;
+  the universal `.skillmapignore` stays):
+  - Part 0 demo fixture present (the tester came from the prologue) →
+    delete the full Part 0 demo fixture set (§Fixture and state
+    templates);
+  - portfolio fixture present instead (the tester ran the campaign) →
+    delete everything `portfolio-init` and the campaign chapters lay
+    (see `fixtures.md` §Portfolio fixture + §Seed snapshots);
+  - in either of those cases also drop the stale `.skill-map/` DB so a
+    fresh init rebuilds it.
+  (2) run `sm init --no-scan` from the cwd (the universal
+  `.skillmapignore` from pre-flight is already on disk, so init leaves
+  it intact and the tutorial's own files stay out of the scan); (3)
+  `Write` the part's fixture (read `references/fixtures.md` for the
+  verbatim `master-agent` / `master-skill` / `notes/ideas` files; skip
+  kinds the provider doesn't claim). If nothing needed clearing and the
+  dir was already initialised with the master fixture in place (Part 7
+  re-entry), that is fine: skip the init and just ensure the fixture
   files are present.
-- **`reuse`** (Part 7 `cli`): assumes the prologue fixture and
-  `.skill-map/` already exist; nothing to lay. The menu offers Part 7
-  only once its `prereq` (`fundamentals`) is done, so the state is
-  there. If `.skill-map/` is somehow missing, point the tester back to
-  the prologue rather than re-initialising mid-part.
-- **`seed`** (the campaign parts `connect-harness` / `maintain` /
-  `mcp` / `live-site`): the part builds on the accumulating portfolio
+- **`seed: prologue-built`** (Part 8 `cli`): the part reads the **Part 0
+  demo fixture**, NOT the cumulative portfolio, so on entry make that
+  fixture the one on disk. Read the state, then:
+  - Demo fixture already present (the tester came straight from the
+    prologue) → just `sm scan`, nothing to lay.
+  - **Portfolio** fixture present instead (the tester ran the campaign)
+    → clear it first (the inverse of `portfolio-init`: delete the
+    portfolio fixture, everything `portfolio-init` and the campaign
+    chapters lay, see `fixtures.md` §Portfolio fixture + §Seed snapshots,
+    plus the stale `.skill-map/` DB; never the tester's own files), then
+    lay the `prologue-built` snapshot from `fixtures.md` (§Seed
+    snapshots), `sm init`, `sm scan`.
+  - Nothing there → lay the snapshot, `sm init`, `sm scan`.
+- **`seed`** (the campaign parts `connect-harness` / `run-harness` /
+  `maintain` / `mcp` / `live-site`): the part builds on the accumulating portfolio
   harness, but the tester may have jumped straight here from the menu.
   On entry, read the state file:
   - If every predecessor campaign part up the `prereq` chain is `done`
     → reuse the accumulated state; an `sm scan` to refresh is enough,
     nothing to lay.
   - Else → **fast-forward, silently** (backstage, do not narrate the
-    plumbing): lay the part's `seed` snapshot from
+    plumbing): first, if the prologue ran first in this dir, clear the
+    full Part 0 demo fixture set (§Fixture and state templates) so the
+    seeded campaign map does not carry the prologue's demo nodes (the
+    `sm scan` below reconciles the removed files out of the DB). Then
+    lay the part's `seed` snapshot from
     `references/fixtures.md` (§Seed snapshots) by following its
     checklist, copy each file's canonical content from the chapter the
     row names, apply the `EDIT` rows on top, substituting
     `<provider_dir>` and skipping provider-unsupported kinds per
-    `_core.md`. Then run `sm init` if `.skill-map/` is missing, then
-    `sm scan` so the map reflects the seeded harness. Mark the skipped
+    `_core.md`. The snapshot's `.skillmapignore` additions
+    (`node_modules/`, `public/`) are appended to the universal
+    `.skillmapignore` pre-flight already wrote, so the tutorial's own
+    `.claude/skills/sm-tutorial/` files stay out of the scan even on a
+    direct jump here. Then run `sm init` if `.skill-map/` is missing
+    (it will not overwrite that `.skillmapignore`), then `sm scan` so
+    the map reflects the seeded harness. Mark the skipped
     predecessor campaign parts `skipped` in the state (they stay in the
     menu for later). Then emit exactly ONE tester-facing line:
 
@@ -350,18 +413,15 @@ All three are specified in `_core.md`:
   the **numbered start menu** (Part 0 is option 1, the recommended
   first pick); the menu (the ToC from `_manifest.yml`, numbered,
   completed parts ticked, `planned` parts hidden, `prereq` gating only
-  the parts that have no `seed`) is the entry point on the first
+  seedless parts, none today since Part 8 `cli` now self-seeds) is the
+  entry point on the first
   invocation and after every part closes / on resume. Render it with
   the format in `_core.md` §Menu format.
 - **Resume / restart**: §Resume / restart. On start-over, the exact
   wipe list is whatever the tester's parts actually created:
   `tutorial-state.yml`, `findings.md`, `.skillmapignore`,
-  `.skill-map/`, the Part 0 fixture
-  (`<provider_dir>/agents/demo-agent.md`,
-  `<provider_dir>/skills/demo-skill/`,
-  `<provider_dir>/commands/demo-command.md`, `notes/todo.md`,
-  `notes/demo-guideline.md`, `notes/private-credentials.md`), the
-  Part 6 fixture if `extend` ran
+  `.skill-map/`, the full Part 0 demo fixture set (§Fixture and state
+  templates), the Part 7 fixture if `extend` ran
   (`<provider_dir>/agents/master-agent.md`,
   `<provider_dir>/skills/master-skill/`, `notes/ideas.md`,
   `.skill-map/plugins/`), `link-validation/` if the CLI part ran,

package/dist/cli/tutorial/sm-tutorial/references/_core.md

@@ -149,9 +149,10 @@ first kind quoted, the second kind never.
    pre-flight only (both silent, no narration):
    - `sm version` ONCE to verify the install.
    - `sm init --no-scan` ONCE for parts whose manifest entry is
-     `preflight: backstage-init`, to provision `.skill-map/` and the
-     bundled `.skillmapignore` BEFORE any scan, so you can append the
-     tutorial's internal entries before the scanner sees the fixture.
+     `preflight: backstage-init`, to provision `.skill-map/` BEFORE
+     any scan. The universal `.skillmapignore` written in pre-flight
+     already keeps the tutorial's own files out, so there is nothing
+     to append here.
    Parts with `preflight: taught-init` (e.g. Part 0) do NOT run
    `sm init` in pre-flight, the tester runs it as the first taught
    step. You also DO NOT run `sm plugins create` on their behalf;
@@ -162,10 +163,10 @@ first kind quoted, the second kind never.
    `Read` files to verify what the tester modified. Everything else
    the tester runs.
 2. **Configuration files have two-mode access.**
-   - **Backstage setup (you DO edit)**: appending the tutorial's
-     internal entries to `.skillmapignore` right after a backstage
-     `sm init --no-scan`; writing the state file; writing fixture
-     `.md` files.
+   - **Backstage setup (you DO edit)**: writing the universal
+     `.skillmapignore` in pre-flight and appending a part's own
+     additions on entry (the portfolio's `node_modules/` / `public/`);
+     writing the state file; writing fixture `.md` files.
    - **Teach moment (you DO NOT edit)**: any change to
      `.skill-map/settings.json`, `.skill-map/settings.local.json`,
      `.skillmapignore`, or `.gitignore` that is part of a chapter
@@ -287,20 +288,53 @@ For every chapter:
   the book ToC, numbered, and let the tester pick a part by number.
   Part 0 (the prologue) is option 1, the recommended starting point,
   so a brand-new tester just types `1`. Do NOT auto-enter a part; the
-  menu is the entry point every time. On later renders, prefix any
-  completed part's title with `✓ `.
+  menu is the entry point every time. On later renders, mark completed
+  parts with a `✓` in their description line, not on the title (see
+  §Menu format).
 - **Which parts to list**: parts in `order`, `status: active` only
   (`planned` parts are hidden). A part with a `seed` (the campaign
-  parts) is always shown, even out of order, its `preflight: seed`
-  fast-forwards the project into it (SKILL.md §Entering a part). A
-  part with a `prereq` but NO `seed` (Part 7 `cli`) is shown only once
-  its `prereq` is `done`.
-- **After the tester picks**: walk that part; when it ends, return to
-  this menu.
+  parts plus Part 8 `cli`) is always shown, even out of order, its
+  `preflight: seed` fast-forwards the project into it (SKILL.md
+  §Entering a part). A part with a `prereq` but NO `seed` would be
+  shown only once its `prereq` is `done`; no active part is in that
+  state today (Part 8 `cli` used to be, now it self-seeds).
+- **After the tester picks**: walk that part; when it ends, run
+  §Closing a part (a tester-facing close, then this menu).
 - **Adding content** is data-only: a new chapter in a part (or a new
   `part-<id>.md` + a manifest row). Keep chapter-id prefixes matching
   the file name so dispatch stays mechanical.
 
+### Closing a part
+
+A part must FEEL finished before the menu comes back: the tester
+should never slide into the next part as if it auto-continued. When a
+part's last chapter (the last in `_manifest.yml` order) is confirmed,
+before re-rendering the menu emit a short tester-facing close:
+
+- A `✓` line naming the part just finished BY ITS TITLE (from
+  `_manifest.yml`), not the internal "Part N" index, which is off by
+  one from the menu numbering the tester sees.
+- One line recapping what they built or learned (same source as the
+  menu description).
+- A hand-off line: back to the menu, pick the next part.
+
+Then render the menu (§Menu format) with this part now marked done (a
+`✓` in its description line, not on the title); its intro may lean to
+"what's next" on a post-part render. The last
+chapter's own confirmation stays scoped to that chapter, it does NOT
+promise or pre-announce the next part, the close and the menu own the
+transition. Sample (Claude variant, mirror the tester's language,
+apply the host rendering rule):
+
+> ✓ Listo, terminaste **El proyecto desde cero**. Levantaste un
+> proyecto real, su handbook y el harness `.claude/` con sus primeros
+> nodos.
+>
+> Volvés al menú, elegí con qué seguir.
+
+If every active part is now `✓` (nothing left to pick), skip the menu
+and go straight to §Final wrap-up.
+
 ### Menu format
 
 Render the menu numbered and formatted (NOT a bare list), translated
@@ -308,6 +342,11 @@ to the tester's language. A one-line intro, then per part a **bold
 numbered title line** (number + title + `(~M min)`) as plain prose,
 immediately followed by a single-level `> ` blockquote one-line
 description (what the part covers, derived from its title + chapters).
+A **completed part** keeps its plain title (NO `✓` on the title line)
+and swaps its description for the done marker: `> ✓ ` plus a short
+"already done" note (e.g. `✓ Ya la hiciste.`). The green check lives
+inside the content, mirroring the `✓` confirmations used elsewhere,
+never as a title prefix.
 NO blank line between a title and its description; ONE blank line
 between parts; NO outer blockquote around the whole menu. Close with a
 short "¿Cuál?" / "Which one?" on its own line. Sample (Claude variant,
@@ -331,6 +370,17 @@ single blockquote" rule: the intro, the bold titles and the trailing
 non-Claude hosts the `> ` collapses to plain prose, indent each
 description two spaces so it stays subordinate to its title.
 
+Same menu after Part 1 is done (the `✓` sits in the description line,
+the title stays plain):
+
+```
+**1. El mapa en vivo** (~12 min)
+> ✓ Ya la hiciste.
+
+**2. El proyecto desde cero** (~8 min)
+> Arrancás un proyecto real (un portfolio) y su harness `.claude/`.
+```
+
 ## Resume / restart
 
 When re-invoked and the state file already exists, do NOT repeat

package/dist/cli/tutorial/sm-tutorial/references/_manifest.yml

@@ -15,11 +15,12 @@
 #   step_files   list form when a part spans several files; dispatch
 #                by chapter-id prefix.
 #   pace         per-step | auto-advance  (see _core.md per-step cycle).
-#   preflight    taught-init | backstage-init | portfolio-init | seed |
-#                reuse  (see _core.md rule #1 + SKILL.md §Entering a part).
-#   seed         which cumulative snapshot to fast-forward to when this
-#                part is entered out of order (see fixtures.md §Seed
-#                snapshot:*). Campaign parts only.
+#   preflight    taught-init | backstage-init | portfolio-init | seed
+#                (see _core.md rule #1 + SKILL.md §Entering a part).
+#   seed         which snapshot to fast-forward to when this part is
+#                entered out of order (see fixtures.md §Seed snapshot:*).
+#                Campaign parts use a cumulative portfolio snapshot;
+#                Part 8 `cli` uses the standalone `prologue-built` demo.
 #   prereq       recommended predecessor. Gates the menu ONLY for a part
 #                with NO `seed`; a seedable part is always shown (its
 #                seed bridges the gap, predecessors get marked `skipped`).
@@ -44,13 +45,13 @@ parts:
       - id: kinds           ; title: "The other kinds appear"               ; est_min: 1
       - id: first-edit      ; title: "Your first edit (the watcher reacts)" ; est_min: 1
       - id: connectors      ; title: "The connectors light up"             ; est_min: 2
-      - id: inspector       ; title: "The inspector and linked nodes"      ; est_min: 1
+      - id: inspector       ; title: "The inspector and connections"       ; est_min: 1
       - id: edit-link       ; title: "Edit a link, the topology changes"   ; est_min: 3
       - id: workspace       ; title: "Navigate the workspace (files, search, isolate)" ; est_min: 2
       - id: ignore          ; title: "Silence a file via .skillmapignore"  ; est_min: 2
 
   - id: extend
-    order: 6
+    order: 7
     title: "Extend skill-map for the site"
     # Spans three chapter libraries; dispatch by chapter-id prefix:
     #   settings-*  -> part-settings.md
@@ -80,12 +81,13 @@ parts:
       - id: authoring-6-upgrade      ; title: "Try `sm plugins upgrade`" ; est_min: 2
 
   - id: cli
-    order: 7
+    order: 8
     title: "The CLI in depth"
     step_file: part-cli.md
     pace: auto-advance
-    preflight: reuse           # reuses the fundamentals fixture + DB
-    prereq: fundamentals       # menu offers this only after Part 0
+    preflight: seed            # self-seeds the Part 0 demo fixture
+    seed: prologue-built       # the prologue demo fixture (not the cumulative portfolio)
+    prereq: fundamentals       # recommended predecessor; cli self-seeds, so it is always shown
     status: active
     chapters:
       - id: browse           ; title: "list / show / check" ; est_min: 3
@@ -130,8 +132,21 @@ parts:
       - id: links       ; title: "Mentions (@) and references between assets" ; est_min: 3
       - id: confidence  ; title: "Connector confidence (opacity = certainty)" ; est_min: 2
 
-  - id: maintain
+  - id: run-harness
     order: 3
+    title: "Run the harness (your site, live)"
+    step_file: part-run-harness.md
+    pace: auto-advance
+    preflight: seed
+    seed: harness-connected   # fast-forward to here if the earlier parts are not done
+    prereq: connect-harness
+    status: active
+    chapters:
+      - id: generate ; title: "The agent generates the HTML in public/" ; est_min: 3
+      - id: serve    ; title: "node server.js: your portfolio, live next to the graph" ; est_min: 3
+
+  - id: maintain
+    order: 4
     title: "Maintain the site"
     step_file: part-maintain.md
     pace: auto-advance
@@ -148,7 +163,7 @@ parts:
       - id: versions     ; title: "Versions: sm bump and history" ; est_min: 2
 
   - id: mcp
-    order: 4
+    order: 5
     title: "MCP"            # a chapter apart, just before the finale
     step_file: part-mcp.md
     pace: auto-advance
@@ -160,8 +175,8 @@ parts:
       - id: mcp-node ; title: "content-editor declares an MCP tool; the mcp:// node appears" ; est_min: 3
 
   - id: live-site
-    order: 5
-    title: "The site, live"  # the finale / climax
+    order: 6
+    title: "Ship the site (the full publish pipeline)"  # the finale / climax
     step_file: part-live-site.md
     pace: auto-advance
     preflight: seed
@@ -169,7 +184,7 @@ parts:
     prereq: connect-harness
     status: active
     chapters:
-      - id: generate ; title: "The agent generates the HTML in public/" ; est_min: 3
-      - id: serve    ; title: "node server.js: your portfolio, live, next to the graph" ; est_min: 3
+      - id: pipeline ; title: "Run /publish end to end (check-links, brief, deploy runbook)" ; est_min: 4
+      - id: golive   ; title: "Ship it: the richer site live next to the full graph" ; est_min: 3
 
 findings_file: "./findings.md"

package/dist/cli/tutorial/sm-tutorial/references/fixtures.md

@@ -1,12 +1,24 @@
 # Fixture templates
 
-Fixtures the orchestrator lays for the auto-fixtured parts. Two sets
-today: the **master fixture** (Part 6, "Extend skill-map",
-`backstage-init`) right below, and the **portfolio fixture** (Part 1,
-"The project from zero", `portfolio-init`) at the end of this file.
-Read the set for the part being entered.
-
-## Master fixture (Part 6): layout (per provider)
+Fixtures the orchestrator lays for the auto-fixtured parts. Two full
+templates live here: the **master fixture** (Part 7, "Extend
+skill-map", `backstage-init`) right below, and the **portfolio
+fixture** (Part 1, "The project from zero", `portfolio-init`) at the
+end of this file. The **Part 0 demo fixture** is not templated here:
+its content lives in `SKILL.md` (§Fixture and state templates) and
+`part-fundamentals.md`, and the `prologue-built` seed snapshot below
+just points at those. Read the set for the part being entered.
+
+**Authoring note (command fixtures).** A `command` node's H1 is a plain
+title (`# publish`), never the slash form (`# /publish`). The `slash`
+extractor reads a `/name` token anywhere in the body, the H1 included,
+as an `invoke`, so `# /publish` makes the command invoke itself and
+`sm check` emits a spurious `core/link-self-loop` the tester has no
+context for. Holds for every command fixture wherever it is defined
+(today: the prologue `demo-command`, the `publish` command, and the
+`reserved` chapter's `init`).
+
+## Master fixture (Part 7): layout (per provider)
 
 Per §Provider detection in `SKILL.md`, the `<provider_dir>`
 placeholder resolves to `.claude/` or `.agents/skills/` depending
@@ -134,7 +146,7 @@ Per finding:
 Laid backstage before the tester's `sm init` in Part 1. The Express
 skeleton (`server.js`, `package.json`, `public/index.html`) is plain
 scaffolding, not `.md`, so the scan ignores it; it makes the project
-real and runnable (Part 5 starts it). The one boot node is the
+real and runnable (Part 3 runs it, Part 6 ships it). The one boot node is the
 handbook `AGENTS.md`. On `agent-skills` / Antigravity (no `agent`
 kind) the harness still works: the agent member is created as a skill
 in a later chapter.
@@ -154,15 +166,12 @@ Layout:
 
 ### File: `AGENTS.md` (kind: markdown, the boot node)
 
-```markdown
----
-name: portfolio-handbook
-description: |
-  Operating manual for this portfolio site: how its pages get
-  written, checked, and published by the .claude/ harness.
-tags: [docs, portfolio]
----
+No frontmatter: a real handbook is plain prose (this repo's own
+`AGENTS.md` and the tutorial's `CLAUDE.md` carry none either), and a
+`name:` that differs from the filename only confuses the tester. The
+node displays by its path, `AGENTS.md`.
 
+```markdown
 # Portfolio handbook
 
 A small static portfolio site, served by Express (`server.js`). The
@@ -196,7 +205,7 @@ app.listen(port, () => console.log(`Portfolio live at http://localhost:${port}`)
 }
 ```
 
-### File: `public/index.html` (not scanned; placeholder until Part 5)
+### File: `public/index.html` (not scanned; placeholder until Part 3)
 
 ```html
 <!doctype html>
@@ -208,15 +217,16 @@ app.listen(port, () => console.log(`Portfolio live at http://localhost:${port}`)
 
 ### `.skillmapignore` additions
 
-Append to the portfolio `.skillmapignore` (on top of the tutorial
-internals from `SKILL.md`): `node_modules/` (the Express install) and
-`public/` (generated HTML, not part of the harness graph).
+Append to the universal `.skillmapignore` (written in pre-flight, see
+`SKILL.md`): `node_modules/` (the Express install) and `public/`
+(generated HTML, not part of the harness graph).
 
-## Seed snapshots (for `preflight: seed`, jumping into a campaign part)
+## Seed snapshots (for `preflight: seed`)
 
-When the orchestrator enters a campaign part out of order (its
-predecessors are not `done`), it fast-forwards the project by laying
-the snapshot below, then `sm init` (if `.skill-map/` is missing) +
+When the orchestrator enters a seedable part out of order (the campaign
+parts when their predecessors are not `done`, or Part 8 `cli` when the
+demo fixture is not the one on disk), it fast-forwards the project by
+laying the snapshot below, then `sm init` (if `.skill-map/` is missing) +
 `sm scan`. These are **checklists, not content**: each row names a file
 and the chapter that holds its canonical content. Lay each file by
 copying the content from the named chapter (substitute `<provider_dir>`
@@ -237,7 +247,7 @@ any cross-links:
 3. `<provider_dir>/agents/content-editor.md`  <-  part-project-kickoff.md, chapter `first-agent`.
 4. `docs/STYLE.md` and `docs/DEPLOY.md`  <-  part-project-kickoff.md, chapter `real-kinds`.
 
-### Seed snapshot: `harness-connected` (start of Parts 3, 4, 5)
+### Seed snapshot: `harness-connected` (start of Parts 3-6)
 
 Everything in `harness-built`, PLUS the Part 2 wiring:
 
@@ -246,6 +256,19 @@ Everything in `harness-built`, PLUS the Part 2 wiring:
 7. EDIT `AGENTS.md`: append the two hub bullets (mention `@content-editor`, invoke `/publish`)  <-  part-connect-harness.md, chapter `links`.
 8. EDIT `<provider_dir>/agents/content-editor.md`: add the `[style guide](../../docs/STYLE.md)` line  <-  part-connect-harness.md, chapter `links`.
 
-After laying a snapshot the map matches the state a tester would have at
-the END of the part just before the one being entered.
+After laying a campaign snapshot the map matches the state a tester would
+have at the END of the part just before the one being entered.
+
+### Seed snapshot: `prologue-built` (Part 8 `cli`)
+
+NOT cumulative and NOT the portfolio: this is the **Part 0 demo
+fixture**, the five standalone demo nodes with `notes/todo` wired as the
+hub, the clean state (`✓ No issues`) at the end of the prologue's
+connector chapters. Part 8 only reads it. Because it is a different
+fixture from the portfolio, entry first resets any portfolio on disk
+(see SKILL.md §Entering a part, the `cli` case).
+
+1. `<provider_dir>/agents/demo-agent.md`  <-  SKILL.md §Fixture and state templates. (The `.skillmapignore` is universal, already on disk from pre-flight; the snapshot does not lay it.)
+2. `<provider_dir>/skills/demo-skill/SKILL.md`, `<provider_dir>/commands/demo-command.md`, `notes/todo.md`, `notes/demo-guideline.md`  <-  part-fundamentals.md, chapter `kinds`.
+3. EDIT `notes/todo.md`: wire the hub bullets pointing at the four other nodes  <-  part-fundamentals.md, chapter `connectors`.
 

package/dist/cli/tutorial/sm-tutorial/references/part-authoring.md

@@ -1,6 +1,6 @@
-# Part 6 (c): Extend skill-map - build plugins (step library, `authoring-*` ids)
+# Part 7 (c): Extend skill-map - build plugins (step library, `authoring-*` ids)
 
-Step bodies for the plugin-authoring chapters of Part 6.
+Step bodies for the plugin-authoring chapters of Part 7.
 The SKILL.md orchestrator dispatches each `authoring-*` chapter id
 here; `settings-*` ids it dispatches to `part-settings.md`.
 
@@ -11,11 +11,11 @@ view-slot, and confirm the contribution lands in the UI.
 
 ## Precondition check
 
-Verify that `.skill-map/` exists in the cwd (pre-flight step 4 of
-the `SKILL.md` orchestrator ran `sm init --no-scan` and appended
-the master-tutorial's internal entries to `.skillmapignore`, so
-this is the expected state regardless of whether the tester ran
-the plugins chapters first). If `.skill-map/` is missing, the fixture
+Verify that `.skill-map/` exists in the cwd (the `extend` part's
+`backstage-init` preflight ran `sm init --no-scan` to provision it;
+the universal `.skillmapignore` from pre-flight keeps the tutorial's
+own files out of the scan, so this is the expected state regardless
+of whether the tester ran the plugins chapters first). If `.skill-map/` is missing, the fixture
 is corrupted: surface the mismatch ("the project bootstrap is
 gone, re-invoke the tutorial from an empty dir") and stop.
 

package/dist/cli/tutorial/sm-tutorial/references/part-cli.md

@@ -1,6 +1,6 @@
-# Part 7: The CLI in depth - step library
+# Part 8: The CLI in depth - step library
 
-The deep-dive into the rest of the CLI: browsing verbs, ASCII graph + export, broken-ref issues, the `.sm` annotation consent prompt, and validating links to folders outside the scan scope. `pace: auto-advance` (walk straight into the next chapter's Announcement once one is marked done) and it reuses the fundamentals fixture and DB built in Part 0 (no fresh fixture of its own). Shared conventions (tone, provider detection / substitution, the `> ` rendering rule, the per-step cycle) live in `_core.md`; do not restate them here.
+The deep-dive into the rest of the CLI: browsing verbs, ASCII graph + export, broken-ref issues, the `.sm` annotation consent prompt, and validating links to folders outside the scan scope. `pace: auto-advance` (walk straight into the next chapter's Announcement once one is marked done) and `preflight: seed` with the `prologue-built` snapshot: it self-seeds its own copy of the Part 0 demo fixture, so it works even if the campaign already replaced that fixture with the portfolio (see SKILL.md §Entering a part, the `cli` case). Shared conventions (tone, provider detection / substitution, the `> ` rendering rule, the per-step cycle) live in `_core.md`; do not restate them here.
 
 ## Chapter `browse` - list / show / check (~3 min)