@skill-map/cli 0.53.4 → 0.53.5

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

@@ -113,7 +113,7 @@ Wait for confirmation. Mark `analyzers`: done.
 
 ## Chapter `orphans` - A page nobody links to (~3 min)
 
-**Context**: a different kind of loose end. A node can be perfectly valid and still be an orphan: nothing in the harness links to it. We create a draft page that no one references, and `sm orphans` finds it. The point is to separate three ideas the tester now has names for: orphan (nothing points at it) vs broken-ref (a link with no target) vs issue (a rule violation).
+**Context**: a different kind of loose end. A node can be perfectly valid and still be an orphan: nothing in the harness links to it. We create a draft page that no one references; it lands on the **Map** as a floating dot, and `sm show` confirms it has no incoming links. The point is to separate three ideas the tester now has names for: orphan (nothing points at it) vs broken-ref (a link with no target) vs issue (a rule violation). Note: orphan-ness is a property of the graph (visible on the Map / inspector), there is no `sm check` analyzer for it. The separate `sm orphans` verb is unrelated, it surfaces history stranded by a rename, not unlinked pages, so do NOT use it here.
 
 `Write` `docs/draft.md` (markdown kind), a half-finished page nobody has wired up yet:
 
@@ -138,19 +138,28 @@ Tell the tester:
 > I dropped a new note into your project, `docs/draft.md`, a
 > half-finished page. Look at the **Map**: it shows up as a floating
 > dot with no arrows touching it. Nothing in your harness links to it,
-> which makes it an **orphan**.
+> which makes it an **orphan**. Click the dot, the inspector shows no
+> connections in or out.
+>
+> You can confirm the same thing from the CLI:
 >
 > ```bash
-> sm orphans
+> sm show docs/draft.md
 > ```
 >
-> `sm orphans` lists exactly that: nodes nothing points at. It is
-> worth keeping three ideas apart, because they are easy to confuse:
+> It prints the node's details, and there is **no "Links in"
+> section**, nothing references it. That absence is exactly what
+> "orphan" means here.
+>
+> It is worth keeping three ideas apart, because they are easy to
+> confuse:
 >
 > - **orphan**: a real, valid node that simply has no incoming link
->   (your `docs/draft`). Not an error, just unreferenced.
+>   (your `docs/draft`). Not an error, just unreferenced, and visible
+>   on the Map as a floating dot.
 > - **broken-ref**: a link whose target file does not exist (the one
->   you triggered by renaming the runbook). That is a real issue.
+>   you triggered by renaming the runbook). That is a real issue
+>   `sm check` reports.
 > - **issue**: any rule violation `sm check` reports (broken-ref is
 >   one family; name-reserved, self-loop and the rest are others).
 >
@@ -159,7 +168,14 @@ Tell the tester:
 > reachable from anywhere. When you link to it later, it stops being
 > an orphan.
 >
-> Did `sm orphans` list `docs/draft`?
+> (Heads up: there is also an `sm orphans` command, but it is a
+> different tool. It tracks history left stranded when you rename a
+> file that had tracked state, not pages with no links, so it will
+> not list `docs/draft`. Running it here prints "no orphan issues",
+> which is correct.)
+>
+> Did `docs/draft` land as a floating dot, with `sm show` confirming
+> no links in?
 
 Wait for confirmation. Mark `orphans`: done.
 
@@ -266,36 +282,4 @@ sm sidecar annotate AGENTS.md
 >
 > Did the prompt appear, and does `AGENTS.sm` exist now?
 
-Wait for confirmation. You MAY use `Read` on `AGENTS.sm` to verify it landed. Mark `sidecar`: done.
-
-## Chapter `versions` - Bump a version, read its history (~3 min)
-
-**Context**: now that the consent is granted, the day-to-day versioning verbs go through silently. `sm bump` increments a node's frontmatter version and appends a record to its `.sm` companion; `sm history` reads that trail back. We bump the content editor and read its history. Same consent gate as the previous chapter, already satisfied.
-
-This is a CLI beat, the tester runs everything (substitute `<provider_dir>` in the path per `_core.md`):
-
-```bash
-sm bump content-editor
-sm history content-editor
-```
-
-> `sm bump <node>` is the everyday versioning verb: it nudges the
-> `version` field in the node's frontmatter up by one and appends an
-> entry to that node's `.sm` companion file, recording that the bump
-> happened. Because you already granted consent in the last chapter,
-> it runs without prompting (the `.sm` write is pre-authorized for
-> this checkout).
->
-> `sm history <node>` reads that trail back: it prints the version
-> entries skill-map has recorded for the content editor, so you can
-> see how it has changed over time. Right after one bump you will see
-> the single entry the bump just wrote.
->
-> The two verbs are a pair: `sm bump` writes a version checkpoint into
-> the companion file, `sm history` reads the checkpoints back out.
-> Your `.md` body never gets cluttered with this, it all lives in the
-> `.sm` alongside it.
->
-> Does `sm history` show the bump you just made?
-
-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).
+Wait for confirmation. You MAY use `Read` on `AGENTS.sm` to verify it landed. Mark `sidecar`: 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,10 +1,10 @@
-# Part 5: MCP (step library, `mcp-*` ids)
+# Part 8: 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
-connected portfolio harness from the earlier parts, same cwd, same
-live `sm` session). One chapter only. Shared conventions live in
-`_core.md`.
+This is a chapter apart, a standalone appendix that comes last in the
+book. Pace `auto-advance`, preflight `seed` (`harness-connected`, so it
+fast-forwards onto the connected portfolio harness whether the campaign
+was just run in this directory or you jumped straight here). One chapter
+only. Shared conventions live in `_core.md`.
 
 ## Chapter `mcp-node` - The agent reaches for an MCP tool (~3 min)
 

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

@@ -1,4 +1,4 @@
-# Part 7 (b): Extend skill-map - plugins (step library, `tour-*` ids)
+# Part 6 (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

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

@@ -5,7 +5,7 @@ starts an actual project: a tiny personal **portfolio website**,
 fully static, served by a ~15-line Express server, plus the
 `.claude/` **harness** that maintains it. skill-map maps the harness
 (the `.md` assets and how they reference each other); the site itself
-is plain HTML the harness produces (Part 3 runs it, Part 6 ships it).
+is plain HTML the harness produces (Part 3 runs it, Part 5 ships it).
 `pace: per-step`, `preflight: portfolio-init`. Shared
 conventions live in `_core.md`.
 
@@ -54,8 +54,9 @@ Wait for confirmation. Mark `kickoff`: done.
 
 **Context**: the dogfood beat. Real Claude Code projects keep a
 `CLAUDE.md` that just points at `AGENTS.md` (this very repo does).
-That one-line pointer is a real `mentions` link, the tester's first
-connector on the real project.
+That one-line pointer is a real `references` link (the `.md` extension
+makes `@AGENTS.md` a file pointer, not a bare mention), the tester's
+first connector on the real project.
 
 Tell the tester to create the file themselves (it is their project's
 file, Inviolable rule #2):
@@ -68,10 +69,13 @@ file, Inviolable rule #2):
 > ```
 >
 > Save it. Watch the map: a new `CLAUDE.md` node appears, with a
-> `mentions` connector pointing at `AGENTS.md`. The `@name` token is
-> the same mention syntax from the prologue, now doing real work: it
-> tells anyone (and skill-map) that `CLAUDE.md` defers to the
-> handbook. This is exactly how this tool's own repo is wired.
+> `references` connector pointing at `AGENTS.md`, solid at 1.00.
+> Because `@AGENTS.md` carries the `.md` extension, skill-map reads it
+> as a file pointer (the same `@name.md` reference you met in the
+> prologue, not a bare mention), and since the handbook is right there
+> the link resolves with full confidence. It tells anyone (and
+> skill-map) that `CLAUDE.md` defers to the handbook. This is exactly
+> how this tool's own repo is wired.
 >
 > Did the connector light up?
 

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

@@ -1,11 +1,12 @@
-# Part 3: Run the harness (your site, live) (step library, `generate` + `serve`)
+# Part 3: Run the harness (your site, live) (step library, `generate` + `serve` + `editor-live`)
 
 The first payoff: the harness you built and wired in the earlier parts
 finally does its job and you see a real site running, without waiting
 for the finale. Pace `auto-advance`, preflight `seed` (`harness-connected`,
-so a tester can jump straight here). Two chapters, in order:
-`generate` (the agent writes the HTML pages) then `serve` (the tester
-runs the site and sees it next to the graph). This is a deliberately
+so a tester can jump straight here). Three chapters: `generate` (the
+agent writes the HTML pages), `serve` (the tester runs the site next to
+the graph), then an optional `editor-live` (the tester lets the real
+`content-editor` agent write a posts page). This is a deliberately
 simple, working pass: maintenance, MCP and the full publish pipeline
 come in the parts after it. Shared conventions live in `_core.md`.
 
@@ -149,7 +150,32 @@ stop the server with Ctrl+C and the edge case for ports applies the
 same as elsewhere. Remind them they can leave the server running or
 stop it with Ctrl+C; either way the next parts do not need it.
 
-Mark `serve`: done. Last chapter of the part: apply §Closing a part
-(the close names the part by its title and routes back to the menu;
-this is a mid-campaign payoff, NOT the campaign finale, so do not
-sign the campaign off here).
+Mark `serve`: done. Auto-advance to the optional `editor-live` chapter.
+
+## Chapter `editor-live` - Let the content-editor agent write a posts page for real (optional) (~3 min)
+
+**Context**: optional payoff, and the first time the tester runs a harness member for real instead of playing it. In `generate` the tester (as the agent) wrote the HTML by hand; here the actual `content-editor` agent does the job. The tester asks for a new **posts** page, the tutorial invokes the agent, and a real `public/posts.html` lands, proof that the nodes on the map are runnable, not just a diagram. The Layer-1 / Layer-2 split still holds: the new HTML does NOT move the graph (HTML is not `.md`). Fully skippable; run it or skip it, the part closes either way.
+
+On `agent-skills` / Antigravity the `content-editor` member is a **skill**, not an `agent`; invoke it as a skill and keep everything else identical.
+
+This chapter is OPTIONAL and the tester opts in. Offer it; if they skip, go straight to the part close below.
+
+Tell the tester:
+
+> Optional last beat, and the fun one: so far you have *played* the
+> `content-editor` yourself. Want to see it run for real? Ask me to add
+> a **posts** page with your agent, for example: "use the
+> content-editor agent to add a posts page". I'll invoke the real
+> `content-editor` in your project; it reads its own rules and the
+> style guide, then writes a new static page into `public/`.
+>
+> Watch two things: the new page lands in `public/` (and shows on the
+> live site when you open it), and the **Map does NOT move**, same
+> Layer-1 / Layer-2 split as before, the agent's HTML output is not
+> part of the harness graph.
+>
+> Or just tell me to skip it and we'll wrap up this part.
+
+If the tester opts in: invoke the project's `content-editor` (the `<provider_dir>/agents/content-editor.md` agent, or the skill on `agent-skills`) via the Task tool to write ONE new static page `public/posts.html`, following the agent's own rules and `docs/STYLE.md` (plain HTML, no framework, no client JS, one page per file, a nav link back to Home), holding two or three short sample posts (a heading plus a sentence or two each). Do NOT edit `public/index.html` or any `.md` harness file, and do NOT edit the agent definition. If the subagent is not invocable in the tester's setup, act as the `content-editor` yourself following the same rules so the beat still lands. Then tell the tester to open `http://localhost:3000/posts.html` (refresh and navigate there), confirm the posts page is live and links back home, and confirm the **Map stayed still**.
+
+Wait for confirmation (ran it or skipped). Mark `editor-live`: done. Last chapter of the part: apply §Closing a part (the close names the part by its title and routes back to the menu; this is a mid-campaign payoff, NOT the campaign finale, so do not sign the campaign off here).

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

@@ -1,6 +1,6 @@
-# Part 7 (a): Extend skill-map - settings (step library, `settings-*` ids)
+# Part 6 (a): Extend skill-map - settings (step library, `settings-*` ids)
 
-Step bodies for the settings chapters of Part 7 (config layers, the
+Step bodies for the settings chapters of Part 6 (config layers, the
 `sm config` verbs, the active provider lens), plus the shared step
 `settings-6-contributions` that the plugin-authoring chapters reuse.
 The SKILL.md orchestrator dispatches each `settings-*` chapter id

package/dist/cli.js

@@ -1,6 +1,6 @@
 // cli/entry.ts
 
-!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof globalThis?globalThis:"undefined"!=typeof self?self:{},n=(new e.Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="888d57e8-17f0-5013-89d1-f60f3ef2828b")}catch(e){}}();
+!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof globalThis?globalThis:"undefined"!=typeof self?self:{},n=(new e.Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="ab2725f4-cc31-54b9-b0c4-0d9778b2143e")}catch(e){}}();
 import { existsSync as existsSync33 } from "fs";
 import { Builtins, Cli as Cli2 } from "clipanion";
 
@@ -246,7 +246,7 @@ function bucketByKind(kind, instance, bag) {
 // package.json
 var package_default = {
   name: "@skill-map/cli",
-  version: "0.53.4",
+  version: "0.53.5",
   description: "skill-map reference implementation \u2014 kernel + CLI + adapters.",
   license: "MIT",
   type: "module",
@@ -30251,4 +30251,4 @@ function resolveBareDefault() {
   process.exit(ExitCode.Error);
 }
 //# sourceMappingURL=cli.js.map
-//# debugId=888d57e8-17f0-5013-89d1-f60f3ef2828b
+//# debugId=ab2725f4-cc31-54b9-b0c4-0d9778b2143e

package/dist/index.js

@@ -1,6 +1,6 @@
 // kernel/i18n/registry.texts.ts
 
-!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof globalThis?globalThis:"undefined"!=typeof self?self:{},n=(new e.Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="66543317-554b-53e5-b2d4-5ed32dfdc81a")}catch(e){}}();
+!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof globalThis?globalThis:"undefined"!=typeof self?self:{},n=(new e.Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="47677efe-5ea6-5c32-bc68-24254a2513dd")}catch(e){}}();
 var REGISTRY_TEXTS = {
   duplicateExtension: "Extension already registered: {{kind}}:{{qualifiedId}}",
   unknownKind: "Unknown extension kind: {{kind}}",
@@ -102,7 +102,7 @@ import { Tiktoken as Tiktoken2 } from "js-tiktoken/lite";
 // package.json
 var package_default = {
   name: "@skill-map/cli",
-  version: "0.53.4",
+  version: "0.53.5",
   description: "skill-map reference implementation \u2014 kernel + CLI + adapters.",
   license: "MIT",
   type: "module",
@@ -3632,4 +3632,4 @@ export {
   runScanWithRenames
 };
 //# sourceMappingURL=index.js.map
-//# debugId=66543317-554b-53e5-b2d4-5ed32dfdc81a
+//# debugId=47677efe-5ea6-5c32-bc68-24254a2513dd

package/dist/kernel/index.js

@@ -1,6 +1,6 @@
 // kernel/i18n/registry.texts.ts
 
-!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof globalThis?globalThis:"undefined"!=typeof self?self:{},n=(new e.Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="3034c153-d87d-57ef-9e51-8770d99ad465")}catch(e){}}();
+!function(){try{var e="undefined"!=typeof window?window:"undefined"!=typeof global?global:"undefined"!=typeof globalThis?globalThis:"undefined"!=typeof self?self:{},n=(new e.Error).stack;n&&(e._sentryDebugIds=e._sentryDebugIds||{},e._sentryDebugIds[n]="e395a3a8-34ff-5d90-ae21-95ad61f53649")}catch(e){}}();
 var REGISTRY_TEXTS = {
   duplicateExtension: "Extension already registered: {{kind}}:{{qualifiedId}}",
   unknownKind: "Unknown extension kind: {{kind}}",
@@ -102,7 +102,7 @@ import { Tiktoken as Tiktoken2 } from "js-tiktoken/lite";
 // package.json
 var package_default = {
   name: "@skill-map/cli",
-  version: "0.53.4",
+  version: "0.53.5",
   description: "skill-map reference implementation \u2014 kernel + CLI + adapters.",
   license: "MIT",
   type: "module",
@@ -3632,4 +3632,4 @@ export {
   runScanWithRenames
 };
 //# sourceMappingURL=index.js.map
-//# debugId=3034c153-d87d-57ef-9e51-8770d99ad465
+//# debugId=e395a3a8-34ff-5d90-ae21-95ad61f53649