@skill-map/cli 0.53.1 → 0.53.3

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

@@ -1,6 +1,6 @@
 # Part 0: The live map (prologue) - step library
 
-The live-UI prologue: the tester runs `sm init`, opens the browser, and watches the map update in real time as files are written and edited. `pace: per-step` (ask "¿seguimos?" between steps), `preflight: taught-init` (the tester runs `sm init` as the first taught step, not pre-flight), and the chapters lay the basics fixture progressively, one node at a time. Shared conventions (tone, provider detection / substitution, the `> ` rendering rule, the per-step cycle) live in `_core.md`; do not restate them here.
+The live-UI prologue: the tester runs `sm init`, opens the browser, and watches the map update in real time as files are written and edited. `pace: per-step` (one chapter per exchange; the chapter's own confirmation advances to the next, NO separate "¿seguimos?"), `preflight: taught-init` (the tester runs `sm init` as the first taught step, not pre-flight), and the chapters lay the basics fixture progressively, one node at a time. Shared conventions (tone, provider detection / substitution, the `> ` rendering rule, the per-step cycle) live in `_core.md`; do not restate them here.
 
 ## Chapter `init` - Your first node (~2 min)
 
@@ -8,25 +8,25 @@ The live-UI prologue: the tester runs `sm init`, opens the browser, and watches
 
 ```bash
 sm init
-ls -la .skill-map/
+sm
 ```
 
-Expected: `.skill-map/skill-map.db` appears (plus config files). The initial scan reports a small node / link / issue count from the demo-agent fixture, NOT 14+ phantom issues from the tutorial's own prose: pre-flight already wrote `.skillmapignore` with the right exclusions in place, so `sm init` leaves that file alone (it only writes when absent) and the scan never sees `sm-tutorial.md` / `findings.md` / `tutorial-state.yml`.
+Expected: `.skill-map/skill-map.db` appears (plus config files), and the initial scan reports a small node / link count from the demo-agent fixture. `sm init` runs and exits; `sm` then starts the UI server and stays running. (Agent context, do not narrate: pre-flight's `.skillmapignore` keeps the tutorial's own files, `sm-tutorial.md` / `findings.md` / `tutorial-state.yml`, out of the scan; `sm init` leaves that file alone since it only writes when absent.)
 
-Before launching the server, ask the tester to set up a **side-by-side view** so they can watch the magic happen without alt-tabbing every step, then launch the server and open the link it prints. Don't hardcode the URL here, the verb itself is the source of truth (it logs the bound `http://host:port` after listen). Tell the tester:
+Give the tester the whole flow in one message with ONE confirmation, do NOT pause for the `sm init` output separately. Don't hardcode the URL, the verb logs the bound `http://host:port` after listen. Tell the tester:
 
-> First, arrange your screen so the **browser** (where the **Map**
-> updates in real time) and **this chat** are both visible at once,
-> typical layout is browser on the left half, chat on the right
-> (or any split that lets you see both). The terminal running
-> `sm` can stay off to the side; it just prints scan progress
-> lines and you don't need to read them.
+> First, **open your browser** and put it side by side with this
+> chat (browser on one half, chat on the other, any split that lets
+> you see both) so you can watch the **Map** update in real time.
 >
-> Then run `sm`. After a couple of seconds it will print a line
-> with the URL where the UI is listening, copy that link and open
-> it in the browser you just arranged.
+> Then, in your second terminal, run the two commands above: `sm
+> init` sets the project up (it creates `.skill-map/` and runs a
+> first scan), and `sm` boots the live UI. After a couple of seconds
+> `sm` prints a URL, copy it and open it in your browser. The
+> terminal keeps printing scan lines, you don't need to read them.
 >
-> Tell me when the page is open showing one node, `demo-agent`.
+> You'll see one node in the **Map**: `demo-agent`. Tell me when the
+> page is open showing it.
 
 Wait for confirmation. Mark `init`: done.
 
@@ -127,7 +127,7 @@ Create these four files (with `Write`), exactly in this order. Per §Provider de
 Tell the tester:
 
 > Look at the browser. Four new nodes should have popped in:
-> `demo-skill`, `demo-command`, `notes/todo`, and `demo-guideline`.
+> `demo-skill`, `demo-command`, **Demo TODO list**, and `demo-guideline`.
 > Five total now, **still unconnected**: they're floating dots.
 > The viewport auto-fits whenever a node is added or removed, so
 > all five should be visible without panning.
@@ -183,9 +183,9 @@ You edit `notes/todo.md` so it becomes the **hub** that points to each of the ot
 - a `/slash` token → kind `invokes`
 - a markdown link `[text](path)` → kind `references`
 
-Four bullets, three kinds (the `invokes` kind shows up twice because both the command and the skill are addressed by slash).
+Five bullets, three kinds: `invokes` and `mentions` each appear twice, `references` once. The last two bullets both point at the **same** node (`demo-guideline`), on purpose: a markdown link AND an `@`-mention of it, so the next beat can contrast their confidence (the file link is certain, the name drop is a softer guess).
 
-Apply with `Edit` on `notes/todo.md` (do not rewrite the file). Per §Provider detection, **substitute `.claude/` with the detected `<provider_dir>` and drop any bullet whose target node was not created in the `kinds` chapter** (on `agent-skills` / Antigravity there is no agent and no command → skip the `@demo-agent` and `/demo-command` bullets, two connectors land).
+Apply with `Edit` on `notes/todo.md` (do not rewrite the file). Per §Provider detection, **substitute `.claude/` with the detected `<provider_dir>` and drop any bullet whose target node was not created in the `kinds` chapter** (on `agent-skills` / Antigravity there is no agent and no command → skip the `@demo-agent` and `/demo-command` bullets; the `@demo-guideline` mention stays and is the faint connector on those providers too).
 
 **Edit `notes/todo.md`**: append these bullets after the `# Pending` heading:
 
@@ -195,56 +195,61 @@ Apply with `Edit` on `notes/todo.md` (do not rewrite the file). Per §Provider d
 - [ ] Trigger /demo-skill when the input lands.
 - [ ] Re-read the
       [demo-guideline](./demo-guideline.md) before shipping.
+- [ ] Ping @demo-guideline if the conventions change.
 ```
 
 Tell the tester:
 
-> Look at the magic again. `notes/todo` is now the hub: four
-> arrows light up between it and the other nodes, and the UI
-> palette colours each arrow by the link kind it carries:
+> Look at the magic again. **Demo TODO list** is now the hub: five
+> arrows light up between it and the other nodes, and the UI palette
+> colours each arrow by the link kind it carries:
 >
-> - `notes/todo → demo-agent` (kind: `mentions`)
-> - `notes/todo → demo-command` (kind: `invokes`)
-> - `notes/todo → demo-skill` (kind: `invokes`)
-> - `notes/todo → demo-guideline` (kind: `references`)
+> - `Demo TODO list → demo-agent` (kind: `mentions`)
+> - `Demo TODO list → demo-command` (kind: `invokes`)
+> - `Demo TODO list → demo-skill` (kind: `invokes`)
+> - `Demo TODO list → demo-guideline` (kind: `references`, the markdown link)
+> - `Demo TODO list → demo-guideline` (kind: `mentions`, the @ handle)
 >
 > The kind comes from the syntax in the bullet: an `@handle` is
 > always a mention, a `/skill` or `/command` is always an invoke, a
-> markdown link is always a reference. Four arrows, three kinds,
-> three colours on the canvas (the two `invokes` share a colour, as
-> you would expect).
+> markdown link is always a reference. Five arrows, three kinds.
 >
-> Notice too that the connectors have different transparency.
-> Skill-map estimates how sure it is of each connection: a
-> `[text](file.md)` that points at a real file (confidence 1.00,
-> now that the target exists) looks solid. The opacity tells that
-> story at a glance: the more solid the arrow, the more reliable
-> the inference.
+> Now look closely: the two arrows to **demo-guideline** are not
+> equally solid. Skill-map draws each connector's **confidence** as
+> opacity, how sure it is the link is real. The markdown link
+> `[demo-guideline](./demo-guideline.md)` points at a real file, so
+> it's certain (1.00) and looks solid; the `@demo-guideline` mention
+> is a looser name drop, a softer guess (0.50), so it's drawn fainter.
+> A glance at the map tells you which links are rock solid and which
+> are skill-map's best guess; the exact number per link is in the
+> inspector, next chapter.
 >
 > Confirm when you see it. If a connector is missing, refresh the
 > browser and let me know.
 
 If a connector is missing, do not advance, the next chapter inspects the same hub edit. Mark `connectors`: done.
 
-## Chapter `inspector` - The inspector and linked nodes (~1 min)
+## Chapter `inspector` - The inspector and connections (~1 min)
 
 The connector opacity tells the confidence story at a glance; the exact per-link breakdown lives in the Inspector. Open it on the hub so the tester registers the surface before the `edit-link` chapter changes topology.
 
 > 🆕 Open the Inspector for **Demo TODO list** (click the node on
 > the map). **Expand** the **Connections** section (it's collapsed
 > by default): it has two sections, **Outgoing** and **Incoming**.
-> Demo TODO list lists 4 links under Outgoing (it's the hub pointing
-> at four nodes) and 0 under Incoming; if you open the Inspector for
-> any of the four targeted nodes, you'll see 1 under Incoming. Each
-> row shows the link kind (`mentions`, `invokes`, `references`) and
-> a badge with its confidence: the numeric value (`1.00`, `0.50`,
-> …).
+> Demo TODO list lists **5 links** under Outgoing (the hub) and 0
+> under Incoming; open the Inspector for a targeted node to see its
+> Incoming count (demo-guideline shows **2**, the reference plus the
+> mention; the others 1 each). Each row shows the link kind
+> (`mentions`, `invokes`, `references`) and a badge with its
+> confidence: the numeric value. Here you'll see the contrast in
+> numbers, the `references` to demo-guideline reads `1.00`, the
+> `mentions` of it reads `0.50`.
 >
 > 💡 Tip: if all these changes left the nodes crowded together, the
 > map toolbar has a **Re-arrange layout** button (tooltip "Re-arrange
-> the visible nodes (re-run auto layout)"): it re-runs the
-> auto-layout so everything reads better. If you've moved nodes by
-> hand it asks for confirmation first, otherwise it just re-arranges.
+> the visible nodes"): it tidies the layout so everything reads
+> better. If you've moved nodes by hand it asks for confirmation
+> first, otherwise it just re-arranges.
 >
 > Let me know when you see it.
 
@@ -260,7 +265,7 @@ The server has been live since the `init` chapter, leave it running; this chapte
 > delete the bullet that contains `@demo-agent`. Save. Watch the
 > UI.
 >
-> Expected: the `notes/todo → demo-agent` connector (kind:
+> Expected: the `Demo TODO list → demo-agent` connector (kind:
 > `mentions`) disappears in real time. The two nodes stay in the
 > **Map**; only the edge goes.
 
@@ -274,13 +279,12 @@ Per §Provider detection, on `agent-skills` / Antigravity the fixture has fewer
 
 **Beat 1, open the Files panel (tester does this).**
 
-> Make sure the **Files** panel is open, the one you expanded back
-> in the first chapter on the left edge. If you collapsed it since,
-> click the expand handle (the `>` arrow, tooltip "Expand files
-> panel") to reopen it. The sidebar shows a **folder tree** (a
-> nested view of your folders and the nodes inside them): your five
-> nodes grouped under `.claude/` and `notes/`, each row showing its
-> kind and how many links go in and out.
+> Open the **Files** panel. It sits collapsed against the left edge
+> by default: click the expand handle there (the `>` arrow, its
+> tooltip reads "Expand files panel"). The sidebar opens into a
+> **folder tree** (a nested view of your folders and the nodes inside
+> them): your five nodes grouped under `.claude/` and `notes/`, each
+> row showing its kind and how many links go in and out.
 >
 > Tell me when the tree is open.
 
@@ -297,19 +301,19 @@ Per §Provider detection, on `agent-skills` / Antigravity the fixture has fewer
 
 **Beat 3, isolate (tester does this).**
 
-> Last one. In the tree, find the `notes/todo` row: at its right
-> edge there's a small **sitemap** icon (its tooltip reads "Isolate
-> this node and its direct links on the map"). Click it.
+> Last one. In the tree, find the **Demo TODO list** row: at its
+> right edge there's a small **sitemap** icon (its tooltip reads
+> "Isolate this node and its direct links on the map"). Click it.
 >
-> The Map collapses to `notes/todo` plus only the nodes it links to
-> (`demo-command`, `demo-skill`, `demo-guideline`). `demo-agent`,
-> which lost its only connector back in the last step, drops out of
-> view, and the Inspector opens on `notes/todo`. That's how you
+> The Map collapses to **Demo TODO list** plus only the nodes it
+> links to (`demo-command`, `demo-skill`, `demo-guideline`).
+> `demo-agent`, which lost its only connector back in the last step,
+> drops out of view, and the Inspector opens on **Demo TODO list**.
+> That's how you
 > focus on one node's neighborhood when a map gets busy.
 >
 > To bring the rest back, look at the toolbar along the bottom of
-> the Map: there's a **Show all** button (an eye icon, tooltip
-> "Clear the map selection and show every node again"). Click it and
+> the Map: there's a **Show all** button (an eye icon). Click it and
 > all five nodes return.
 >
 > Did the map isolate and then restore?
@@ -320,9 +324,9 @@ Leave the server running, the next chapter (`.skillmapignore`) is the last one t
 
 Earlier chapters showed the watcher picking up new files and edits (yours and theirs). This chapter flips the direction: a file the tester DOES NOT want in the map (a draft, a scratch file, a secret) gets hidden by a single line in `.skillmapignore`. Same live mechanism, no restart.
 
-`sm init` already wrote a starter `.skillmapignore` at the scope root. The flow has three beats:
+`sm init` already wrote a starter `.skillmapignore` at the scope root. The chapter is one step with a single confirmation (the node vanishing): the agent seeds a file the tester would never want public, shows where it lives, and the tester hides it with one glob.
 
-**Beat 1, you create one new fixture file (the agent does this).**
+**The agent seeds the file (no tester action, no separate pause).**
 
 `Write` `notes/private-credentials.md`, kind `markdown`, simulates a file the tester would never want surfacing publicly:
 
@@ -340,13 +344,15 @@ description: |
 API_TOKEN: example-not-real
 ```
 
-Confirm the file appears in the map as a sixth node (`notes/private-credentials`). The watcher sees it like any other `.md`, that's the point of the demo. (If the tester doesn't see it, they may need to click **Show all** in the map toolbar to clear any leftover selection.)
+It lands in the map as a sixth node (`notes/private-credentials`); the watcher sees it like any other `.md`. Do NOT pause to confirm the appearance, it folds into the single vanish confirmation at the end of this step.
 
-**Beat 2, you show the project structure (the agent does this).**
+**The tester hides it (single tester-facing message, one confirmation).**
 
-Before asking the tester to touch `.skillmapignore`, give them a mental map of the folder so they know where the file lives and what's around it. Use `Bash` (`ls -la` and `ls -la notes/` if a deeper view helps) and present the listing as a tester-facing message (apply the host-dependent rendering rule) so the tester sees what their cwd holds:
+Give the tester a mental map of the folder so they know where the file lives, then the glob that hides it, all in ONE message. Use `Bash` (`ls -la`, plus `ls -la notes/` if a deeper view helps) for the real listing and apply the host-dependent rendering rule. Per Inviolable rule #2, the agent does NOT touch `.skillmapignore` with its `Edit` tool, the tester edits it from their own editor:
 
-> One last step. Here's what your directory looks like right now:
+> One last step. Your `private-credentials` note just popped into
+> the map as a sixth node, that's the watcher again. Now let's hide
+> it. Here's what your directory looks like right now:
 
 ```
 .                            ← your cwd
@@ -364,24 +370,20 @@ Before asking the tester to touch `.skillmapignore`, give them a mental map of t
     └── private-credentials.md   ← what we want to hide
 ```
 
-> The `.skillmapignore` at the root is the file we'll touch
-> next. Same syntax as `.gitignore`. Anything matching a pattern
-> there is invisible to skill-map's scan.
+> The `.skillmapignore` at the root uses the same syntax as
+> `.gitignore`: anything matching a pattern there is invisible to
+> skill-map's scan. Open it in your editor (it's at the cwd root)
+> and append this pattern on a new line at the end:
 
-Adjust the actual tree shown to whatever `ls -la` returns, the goal is "tester recognises their own filesystem", not a copy of the snippet above.
-
-**Beat 3, the tester edits `.skillmapignore` (NOT the agent).**
-
-Per Inviolable rule #2, the agent does NOT touch `.skillmapignore` with your `Edit` tool. Tell the tester to do it from their editor:
+```
+notes/private-*.md
+```
 
-> Last step. Open `.skillmapignore` (it's at the cwd root) in
-> your editor of choice. At the end of the file, on a new line,
-> append the literal pattern `notes/private-*.md`. Save the
-> file. The pattern uses a glob (same as `.gitignore`):
+> Save the file. It's a glob (same as `.gitignore`):
 > `notes/private-*.md` matches `private-credentials.md` and any
 > future sibling `private-*.md`. A literal path
-> (`notes/private-credentials.md`) would also work, the glob
-> teaches the broader habit.
+> (`notes/private-credentials.md`) would also work, the glob teaches
+> the broader habit.
 >
 > Watch the browser when you save. The
 > `notes/private-credentials` node should disappear from the
@@ -390,6 +392,7 @@ Per Inviolable rule #2, the agent does NOT touch `.skillmapignore` with your `Ed
 >
 > Did the node vanish?
 
-After they confirm, you MAY use `Read` on `.skillmapignore` to verify the appended pattern landed correctly (in case `sm check` later reports something odd), that is read-only and allowed. Once confirmed, ask them to stop the server with **Ctrl+C** in the terminal before continuing.
+Adjust the actual tree shown to whatever `ls -la` returns, the goal is "tester recognises their own filesystem", not a copy of the snippet above. After they confirm, you MAY use `Read` on `.skillmapignore` to verify the appended pattern landed correctly (in case `sm check` later reports something odd), that is read-only and allowed. Once confirmed, ask them to stop the server with **Ctrl+C** in the terminal before continuing.
 
-Mark `ignore`: done.
+Mark `ignore`: done. Last chapter of the part: apply §Closing a part
+(the close names the part by its title and routes back to the menu).

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

@@ -1,62 +1,57 @@
-# Part 5: The site, live (step library, finale, `generate` + `serve`)
-
-This is the finale, the climax of the whole campaign. Pace
-`auto-advance`, preflight `reuse` (it builds straight on the
-portfolio harness from the earlier parts, same cwd). Two chapters,
-in order: `generate` (the agent writes the real HTML pages) then
-`serve` (the tester runs the site and sees it in the browser).
-Shared conventions live in `_core.md`.
-
-## Chapter `generate` - The agent generates the HTML in public/ (~3 min)
-
-**Context**: this is the payoff of the whole harness. The
-`content-editor` agent exists to write the site's pages, so now you
-(playing that agent) generate the actual HTML into `public/`. The
-honest beat the tester must hear: writing HTML does NOT move the
-skill-map graph. The graph is Layer 1, the `.md` harness that builds
-the site; the HTML is Layer 2, the harness's OUTPUT, and skill-map
-does not map it (HTML is not `.md`). So the Map will sit still while
-real files land on disk, and that is correct, not a bug. Keep the
-markup plain per the style guide: no framework, no client JS, one H1
-per page, every page links back home.
-
-**Preparation**: `Write` two static pages into `public/`. The
-pre-flight already left a placeholder `public/index.html`; this
-overwrites it with the real home page and adds an about page. Keep
-the markup plain.
-
-`public/index.html`:
+# Part 6: Ship the site (the full publish pipeline) (step library, finale, `pipeline` + `golive`)
+
+The finale, the climax of the whole campaign. In Part 3 you ran the
+harness once, the simple way (generate two pages, serve them). Here you
+operate it exactly as it was designed: you drive the `/publish` command
+end to end, the way the handbook says to ship, and put a richer
+multi-page site live next to the full graph. Pace `auto-advance`,
+preflight `seed` (`harness-connected`), so a tester can jump straight
+here. Two chapters, in order: `pipeline` (run `/publish`: check the
+links, brief the editor, follow the deploy runbook) then `golive` (run
+the server and click through the finished site). Shared conventions
+live in `_core.md`.
+
+## Chapter `pipeline` - Run /publish end to end (check-links, brief, deploy runbook) (~4 min)
+
+**Context**: the harness is not just a picture, it is a set of
+instructions, and `/publish` is the one that ties them together. Its
+body says: run `/check-links`, brief `@content-editor` on any fix, then
+follow the deploy runbook. Here the tester (playing the harness) walks
+exactly those steps on a richer site. This is still Layer 1 vs Layer 2:
+the pages are output, so the Map stays put while the files change, same
+as Part 3, no need to re-teach it, just do not call it a bug if they
+notice.
+
+**Preparation** (the agent does this, playing `content-editor`):
+
+1. Ensure the two base pages exist. If they are not already on disk
+   from Part 3 (a tester can land here via the seed), lay
+   `public/index.html` and `public/about.html` exactly as in
+   part-run-harness.md, chapter `generate`. They are the single source
+   for those two pages; do not restate their markup, copy it from
+   there.
+2. Add a **Projects** link to the home nav. `Edit` `public/index.html`,
+   turning the About line of the nav into:
+
 ```html
-<!doctype html>
-<html lang="en">
-  <head>
-    <meta charset="utf-8" />
-    <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <title>My Portfolio</title>
-  </head>
-  <body>
-    <h1>My Portfolio</h1>
-    <p>Hi, I build small, sturdy things on the web.</p>
-    <nav>
-      <a href="/">Home</a> ·
-      <a href="/about.html">About</a>
-    </nav>
-  </body>
-</html>
+      <a href="/about.html">About</a> ·
+      <a href="/projects.html">Projects</a>
 ```
 
-`public/about.html`:
+3. `Write` the new page `public/projects.html` (plain markup, links
+   back home, per the style guide):
+
 ```html
 <!doctype html>
 <html lang="en">
   <head>
     <meta charset="utf-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1" />
-    <title>About</title>
+    <title>Projects</title>
   </head>
   <body>
-    <h1>About</h1>
-    <p>A short page about the person behind the portfolio.</p>
+    <h1>Projects</h1>
+    <p>A few small things I have shipped.</p>
     <nav>
       <a href="/">Home</a>
     </nav>
@@ -65,47 +60,57 @@ the markup plain.
 ```
 
 ```bash
-# Nothing for you to run yet. Look at both halves of your screen.
+# Still nothing to run in the terminal. The publish steps below are
+# you walking the harness; the server comes in the next chapter.
 ```
 
 Tell the tester:
 
-> Here it is, the moment the whole harness was built for. Your
-> `content-editor` agent did its real job: it wrote the actual web
-> pages. Two HTML files just landed in your project under `public/`:
-> the home page (`public/index.html`) and an about page
-> (`public/about.html`), plain static markup that follows the style
-> guide you set up earlier.
+> Time to ship it the way your handbook says to. Open
+> `.claude/commands/publish.md` and look at its steps: that command is
+> the recipe, and you are about to run it by hand, the way the agent
+> would. Three pages now live under `public/`: home, about, and a new
+> projects page, with the home nav linking all three.
 >
-> Now glance at the Map. It did not change, and that is exactly
-> right. Everything you watched grow on the canvas is your harness:
-> the `.md` files and how they reference each other (call that
-> Layer 1). The HTML pages are Layer 2, what the harness PRODUCES.
-> skill-map maps the harness, not the pages it outputs (HTML is not
-> `.md`), so writing real site files leaves the graph untouched. Two
-> layers, one project: the graph that builds the site, and the site
-> itself.
+> **Step 1, check the links** (`/check-links`). Walk the three pages
+> and follow every internal link: `/` resolves to the home page,
+> `/about.html` and `/projects.html` to files that exist, and each
+> page links back home. Nothing points at a missing file, so the link
+> check is clean.
 >
-> Ready to see the site running?
+> **Step 2, brief the editor** (`@content-editor`). The check found
+> nothing to fix, so there is no brief to hand off this time, that is
+> the happy path. (Part 4 is where a link actually breaks and this
+> step earns its keep.)
+>
+> **Step 3, follow the deploy runbook** (`docs/DEPLOY.md`). It lists:
+> generate the pages (done), run the link check (done), start the
+> server (next chapter). You have walked the whole `/publish` flow.
+>
+> Glance at the Map one more time: it did not move while you added a
+> page and ran the pipeline. The pages are Layer 2 output; the harness
+> on the canvas is Layer 1, and that is what skill-map maps.
+>
+> Ready to put it live?
 
-Wait for confirmation. Mark `generate`: done. Auto-advance to
-`serve`.
+Wait for confirmation. You MAY `Read` the three files in `public/`
+afterwards to confirm the edit and the new page landed. Mark
+`pipeline`: done. Auto-advance to `golive`.
 
-## Chapter `serve` - node server.js: your portfolio, live, next to the graph (~4 min)
+## Chapter `golive` - Ship it: the richer site live next to the full graph (~3 min)
 
-**Context**: the climax. The tester installs the single dependency
-(Express) and starts the tiny server that the pre-flight already left
-in `server.js`, then opens the site in the browser. They end with two
-things side by side: the real portfolio they can click through, and
-the skill-map graph of the harness that built it. Express runs on
-Node, which the tester has from pre-flight (Node 24+), so no new
-install beyond `npm install`. This chapter is one of the few where
-the tester runs a non-`sm` command themselves (`npm install`,
-`node server.js`); guide them, do not run it for them.
+**Context**: the climax. The tester starts the tiny Express server the
+pre-flight left in `server.js` and clicks through the three-page site,
+ending with the running portfolio on one side and the full skill-map
+graph of the harness that built it on the other. This is one of the
+few chapters where the tester runs non-`sm` commands themselves
+(`npm install`, `node server.js`); guide them, do not run it for them.
+`npm install` is idempotent, so it is safe whether or not they already
+ran it in Part 3.
 
-**Preparation**: none. `server.js` and `package.json` already exist
-from the kickoff pre-flight; the pages exist from the `generate`
-chapter. The tester runs everything in this chapter.
+**Preparation**: none. `server.js` and `package.json` exist from the
+kickoff pre-flight; the three pages exist from the `pipeline` chapter.
+The tester runs everything here.
 
 ```bash
 npm install
@@ -114,43 +119,37 @@ node server.js
 
 Tell the tester:
 
-> Last step, and it is the fun one. You have the pages; now let's
-> serve them. In your terminal, run these two commands:
->
-> The first, `npm install`, downloads the one small library the
-> server needs (Express, a tiny web server). It runs on Node, which
-> you already installed at the very start, so there is nothing new to
-> set up.
+> Last step, the fun one. In your terminal, run these two commands:
 >
-> The second, `node server.js`, starts the server. It prints a line
-> telling you it is listening, something like `Listening on
-> http://localhost:3000`.
+> `npm install` downloads the one small library the server needs
+> (Express). If you already ran it in Part 3 it just confirms it is
+> there. Then `node server.js` starts the server; it prints a line
+> like `Listening on http://localhost:3000`.
 >
-> Open `http://localhost:3000` in your browser. There it is: your
-> portfolio, live. Click the **About** link, then the **Home** link
-> to come back. Those are the very pages your harness produced.
+> Open `http://localhost:3000`. Click **About**, **Projects**, and
+> **Home** to move between all three pages. Those are the pages your
+> harness produced, shipped through the publish flow you just ran by
+> hand.
 >
-> Now take a second to look at everything at once. On one side, the
-> real running site you can click through. On the other, the
-> skill-map graph of the harness that built it: the handbook, the
-> agent, the style guide, the publish command, the link checker, the
-> MCP tool, all wired together. You started in an empty folder with
-> nothing, and you have ended with a real, running thing and a living
-> map of how it all fits.
+> Now take it all in at once. On one side, the real running site you
+> can click through. On the other, the skill-map graph of the harness
+> that built it: the handbook, the content editor, the style guide,
+> the publish command, the link checker, the MCP tool, all wired
+> together. You started in an empty folder with nothing, and you have
+> ended with a real, running site and a living map of how it all fits.
 >
-> Does the site load, and can you click between Home and About?
+> Does the site load, and can you click between Home, About and
+> Projects?
 
 Wait for confirmation. The tester runs the commands; do not run them
 for them. If `npm install` fails, check they are in the project root
-(the cwd they have used all along) and that Node is on PATH (`node
---version` should print 24 or higher). If the port is busy, they can
-stop the server with Ctrl+C and the edge case for ports applies the
-same as elsewhere.
-
-When they confirm, this closes Part 5 and the campaign. Tell the
-tester they went from an empty directory to a real portfolio site
-plus a complete map of its harness, congratulate them plainly, and
-remind them the server stays running until they press Ctrl+C. Mark
-`serve`: done. The orchestrator returns to the ToC menu (the
-campaign spine is complete; the final wrap-up in `_core.md` applies
-when the tester signals they are finished).
+and Node is on PATH (`node --version` should print 24 or higher). If
+the port is busy, stop the server with Ctrl+C and apply the ports edge
+case. Remind them the server stays running until they press Ctrl+C.
+
+This is the campaign finale. Congratulate them plainly: they went from
+an empty directory to a real, running portfolio plus a complete map of
+its harness. Mark `golive`: done. Last chapter of the part: apply
+§Closing a part (name the part by its title; since this closes the
+campaign spine, if every active part is now done route to the §Final
+wrap-up instead of the menu).

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

@@ -1,4 +1,4 @@
-# Part 3: Maintain the site (step library, `maintain`)
+# Part 4: Maintain the site (step library, `maintain`)
 
 This is the upkeep part. The harness from Part 2 is wired and clean; real projects drift, links break, drafts pile up, names collide. Here the tester breaks something on purpose and fixes it, meets the analyzer catalogue that catches those problems, finds an orphan nobody links to, clears a reserved-name warning, and learns the `.sm` companion files that carry the tool's bookkeeping. `pace: auto-advance` (walk straight into the next chapter once one is marked done), `preflight: reuse` (it builds on the portfolio harness from Parts 1 and 2, 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.
 
@@ -283,4 +283,4 @@ sm history content-editor
 >
 > Does `sm history` show the bump you just made?
 
-Wait for confirmation. Mark `versions`: done. This closes Part 3; the orchestrator returns to the ToC menu.
+Wait for confirmation. Mark `versions`: done. Last chapter of the part: apply §Closing a part (the close names the part by its title and routes back to the menu).

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

@@ -1,4 +1,4 @@
-# Part 4: MCP (step library, `mcp-*` ids)
+# Part 5: MCP (step library, `mcp-*` ids)
 
 This is a chapter apart, the one just before the finale. Pace
 `auto-advance`, preflight `reuse` (it builds straight on the
@@ -73,6 +73,6 @@ Tell the tester:
 Wait for confirmation. If the node did not appear, have the tester
 save the file again (the watcher reacts on save) or refresh the
 browser, then re-check; the `tools:` line must be valid YAML on one
-line. Mark `mcp-node`: done. This closes Part 4; the orchestrator
-returns to the ToC menu (Part 5, "The site, live", the finale, is
-next on the spine).
+line. Mark `mcp-node`: done. Last chapter of the part: apply §Closing
+a part (the close names the part by its title and routes back to the
+menu; the full publish finale is next on the spine).

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

@@ -1,4 +1,4 @@
-# Part 6 (b): Extend skill-map - plugins (step library, `tour-*` ids)
+# Part 7 (b): Extend skill-map - plugins (step library, `tour-*` ids)
 
 Guided tour of the **built-in plugins** that ship with `sm`. Three
 steps: a quick mental model of what plugins are plus a peek at