@skill-map/cli 0.60.1 → 0.60.3

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

@@ -138,9 +138,21 @@ element. Decide with §Provider detection:
 
 Sample messages throughout the part files are written in the Claude
 variant (with `> `); strip the prefix when the host is non-Claude,
-the wording is unchanged. **Code / terminal blocks always stay at
-the top level** (never under `> `, even in the Claude variant) so
-copy-paste is clean.
+the wording is unchanged.
+
+**The rule, in one line**: every tester-facing line of prose carries
+the `> ` bar in the Claude variant, context sentences, intros, tips,
+expectations, confirmations, all of it, so a run of contiguous prose
+reads as one continuous separator bar (put `>` on the blank lines
+between paragraphs to keep the bar unbroken). The ONLY things that sit
+at the top level are the command / code / terminal blocks the tester
+copies (never under `> `, even in the Claude variant, so copy-paste is
+clean). A command block in the middle of a message naturally splits
+the bar, prose above it is one bar, prose below it another, and that
+is correct: commands are meant to stand outside the bar. The two
+documented exceptions to "all prose is quoted" are the plain
+`Capítulo S.N:` announcement line (§Per-step cycle) and the menu
+(§Menu format); everything else the tester reads is quoted.
 
 **Preservation rule, strict**: if a source line is already prefixed
 with `> `, keep that prefix verbatim (Claude mode). Do NOT strip
@@ -287,15 +299,21 @@ Never call `TaskCreate` / `TaskUpdate` (Inviolable rule #4).
 
 For every chapter:
 
-1. **Announcement**: "Capítulo S.N: `<title>`. ~M min." then a blank
-   line, then (optionally) one sentence of context on its own
-   paragraph. `S` is the section number (the part's 1-based menu
-   position) and `N` is the 1-based index of the chapter inside that
-   part, resetting per part (§Numbering), so section 5's third chapter
-   announces as `Capítulo 5.3`. The context paragraph renders ONLY when
-   the source has a `**Context**:` field; if omitted, announce the
-   title alone. The title comes from the chapter's `title` in
-   `_manifest.yml` (translated per §Tone), not the internal id.
+1. **Announcement**: "Capítulo S.N: `<title>`. ~M min." as a plain
+   line (NOT quoted), then a blank line. `S` is the section number
+   (the part's 1-based menu position) and `N` is the 1-based index of
+   the chapter inside that part, resetting per part (§Numbering), so
+   section 5's third chapter announces as `Capítulo 5.3`. The title
+   comes from the chapter's `title` in `_manifest.yml` (translated per
+   §Tone), not the internal id. When the source has a `**Context**:`
+   field, follow the announcement with one tester-facing sentence of
+   context, and render it **under the `> ` bar as the opening line of
+   the SAME blockquote as the chapter's instructions** (Claude variant:
+   put `>` on the blank line between the context and the instructions
+   so they read as one continuous separator bar, never two stacked
+   blocks; the context line is tester-facing, so it is never plain
+   prose). When the source has no `**Context**:` field, announce the
+   title alone.
 2. **Preparation** (if applicable): create or modify the fixture
    files the chapter calls for (silently, per §Silence).
 3. **The tester's part**: the command block(s) and instructions,

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

@@ -4,26 +4,30 @@ The live-UI prologue: the tester runs `sm init`, opens the browser, and watches
 
 ## Chapter `init` - Your first node (~2 min)
 
-**Context**: `sm init` creates a hidden `.skill-map/` folder in the cwd holding the database where skill-map stores what it learns about the project. It also runs an initial scan. Mandatory first step. Then typing `sm` alone (no arguments) in an initialised dir starts the UI server with the watcher built in (it is just an alias of `sm serve` with all defaults; the moment you need any flag you write `sm serve --flag ...` explicitly). One process, one terminal: it boots the server, scans the `.md` files, detects changes, and pushes events over WebSocket to the live UI. The next chapters all run against the same `sm` session, you boot it here and keep it alive through the `ignore` chapter.
-
-```bash
-sm init
-sm
-```
+Agent background (do NOT render this as a separate context paragraph; the tester-facing version is folded into the message below): `sm init` creates a hidden `.skill-map/` folder in the cwd holding the database where skill-map stores what it learns about the project, and runs an initial scan (mandatory first step). Typing `sm` alone (no arguments) in an initialised dir then starts the UI server with the watcher built in (it is just an alias of `sm serve` with all defaults; the moment you need any flag you write `sm serve --flag ...` explicitly). One process, one terminal: it boots the server, scans the `.md` files, detects changes, and pushes events over WebSocket to the live UI. The next chapters all run against this same `sm` session, you boot it here and keep it alive through the `ignore` chapter.
 
 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.)
 
-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:
+Give the tester the whole flow in ONE message with ONE confirmation, do NOT pause for the `sm init` output separately. Order matters: **lead with the browser setup**, then explain what the two commands do as you hand them over, then the command block, then the URL. Do NOT print the command block or an explanation paragraph before the browser instruction. Don't hardcode the URL, the verb logs the bound `http://host:port` after listen. Tell the tester:
 
 > 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, 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.
+> Then, in your second terminal, you'll run two commands. `sm init`
+> sets the project up: it creates the hidden `.skill-map/` folder
+> with the database where skill-map stores what it learns about the
+> project, and runs a first scan. `sm` on its own (no arguments)
+> then boots the live UI server, with the watcher built in.
+
+```bash
+sm init
+sm
+```
+
+> 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.
 >
 > You'll see one node in the **Map**: `demo-agent`. Tell me when the
 > page is open showing it.
@@ -235,8 +239,8 @@ Tell the tester:
 > One word on solidity: skill-map draws each connector's
 > **confidence** as opacity, and every arrow you see here is fully
 > solid (1.00) because each one lands on a real node. The faint,
-> partial case (a link to a real file the runtime would ignore) shows
-> up later in the campaign; for now the rule is simple, a reference
+> partial case shows up later in the campaign; for now the rule is
+> simple, a reference
 > that resolves draws a solid arrow, a reference that points at
 > nothing is not drawn at all and gets flagged instead. The exact
 > per-link numbers live in the inspector, next chapter.
@@ -251,6 +255,12 @@ Expected: four drawn arrows plus one `core/reference-broken` error on `notes/tod
 
 The canvas only draws the resolved arrows; the full per-link breakdown, including the broken one that never drew, lives in the Inspector. Open it on the hub so the tester registers the surface before the `edit-link` chapter changes topology.
 
+> 💡 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"): 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.
+>
 > 🆕 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**.
@@ -263,26 +273,20 @@ The canvas only draws the resolved arrows; the full per-link breakdown, includin
 > `mentions` to `demo-guideline` reads `0.50` and is marked broken,
 > that 0.5 is the broken-reference penalty, not a "halfway sure".
 >
-> Now open the Inspector for a couple of the targets to read their
-> Incoming count. The four resolved targets (`demo-agent`,
+> Now open the Inspector for a couple of the nodes to read their
+> Incoming count. The four resolved nodes (`demo-agent`,
 > `demo-command`, `demo-skill`, `demo-guideline2`) each show **1**
 > incoming. Open `demo-guideline` and it shows **0**: the broken
 > mention never landed on it, so nothing points in. Five outgoing
 > links on the hub, but only four of them reach a node.
 >
-> 💡 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"): 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.
 
 Mark `inspector`: done.
 
 ## Chapter `edit-link` - Edit a link, the topology changes (~3 min)
 
-**Context**: the `first-edit` chapter had the tester edit a scalar (`description`) and watch the inspector card refresh. This chapter raises the bar: edit a Markdown link and watch the MAP TOPOLOGY change (a connector disappears). Same watcher, different surface.
+**Context**: the `first-edit` chapter had the tester edit a scalar (`description`) and watch the inspector card refresh. This chapter raises the bar: edit a Markdown link and watch the MAP TOPOLOGY change (a connector disappears).
 
 The server has been live since the `init` chapter, leave it running; this chapter and the next two (the workspace tour, then `.skillmapignore`) reuse it.
 
@@ -298,7 +302,7 @@ You verify by reading `notes/todo.md` to confirm the change was applied. (On `ag
 
 ## Chapter `workspace` - Navigate the workspace (files, search, isolate) (~2 min)
 
-**Context**: you've built the graph and understood it; this beat is about *moving around* it. The workspace has two halves: the **Map** you've been working in, and a **Files** panel, a folder tree of every node. You'll open that tree and filter it with the search box. No file edits here, pure navigation, and the same `sm` session you booted back in the `init` chapter is still running.
+**Context**: you've built the graph and understood it; this beat is about *moving around* it. The workspace has two halves: the **Map** you've been working in, and a **Files** panel, a folder tree of every node. You'll open that tree and filter it with the search box. The same `sm` session you booted back in the `init` chapter is still running.
 
 Per §Provider detection, on `agent-skills` / Antigravity the fixture has fewer nodes (`demo-skill` plus the two `notes/` files), so swap the node names below for ones that exist in that set; the gestures are identical.
 
@@ -333,18 +337,20 @@ Per §Provider detection, on `agent-skills` / Antigravity the fixture has fewer
 >
 > The Map collapses to **Demo TODO list** plus only the nodes it
 > draws an arrow to (`demo-command`, `demo-skill`,
-> `demo-guideline2`).
-> Two nodes drop out of view: `demo-agent`, which lost its only
-> connector back in the last step, and `demo-guideline`, whose bare
-> mention never resolved so it has no drawn connector either. The
-> Inspector opens on **Demo TODO list**.
-> That's how you
-> focus on one node's neighborhood when a map gets busy.
+> `demo-guideline2`). 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). Click it and
 > all six nodes return.
 >
+> 💡 Tip: remember the search box from a moment ago? The map-icon
+> button right next to it controls whether the search also filters
+> the **Map**. It's on by default, that's why the **Map** narrowed
+> along with the tree when you searched `guideline`. Click it to
+> switch to filtering only the files list, leaving the map's layout
+> in place.
+>
 > Did the map isolate and then restore?
 
 Leave the server running, the next chapter (`.skillmapignore`) is the last one that uses it. Mark `workspace`: done.
@@ -380,8 +386,8 @@ It lands in the map as a seventh node (`notes/private-credentials`); the watcher
 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. Your `private-credentials` note just popped into
-> the map as a seventh node, that's the watcher again. Now let's hide
-> it. Here's what your directory looks like right now:
+> the map as a seventh node. Now let's hide it. Here's what your
+> directory looks like right now:
 
 ```
 .                            ← your cwd
@@ -412,8 +418,7 @@ notes/private-*.md
 > 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.
 >
 > Watch the browser when you save. The
 > `notes/private-credentials` node should disappear from the

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

@@ -51,12 +51,9 @@ Tell the tester:
 > `.claude/` folder is the **harness** (the helpers that maintain the
 > site). skill-map maps that harness.
 >
-> Run `sm init`. This folder has both a root `AGENTS.md` and a
-> `.claude/` folder, so skill-map can't tell on its own which runtime
-> you're authoring for and asks:
-> `⚠ Multiple provider markers detected. Pick the active lens: 1) claude 2) openai`.
-> Type `1` (or `claude`) and press Enter, this is a Claude project.
-> Then run `sm` to boot the live UI.
+> Run `sm init`. If it asks you to pick a lens (`⚠ Multiple provider
+> markers detected`), choose `claude`, this is a Claude project. Then
+> run `sm` to boot the live UI.
 >
 > Open the URL `sm` printed. You'll see **one node**: `AGENTS.md`,
 > the project's handbook (the operating manual for the site).
@@ -70,11 +67,11 @@ Wait for confirmation. Mark `kickoff`: done.
 
 ## Chapter `manual` - The handbook and CLAUDE.md (~2 min)
 
-**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 `references` link (the `.md` extension
-makes `@AGENTS.md` a file pointer, not a bare mention), the tester's
-first connector on the real project.
+**Context**: the dogfood beat. Real Claude Code projects can
+reference the generic `AGENTS.md` from their `CLAUDE.md` (this very
+repo does). 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):

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]="ca73146f-c295-5016-832b-cc65f69fa85b")}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]="d4d9801b-b9d6-5298-9ce5-eda6c347ce50")}catch(e){}}();
 import { existsSync as existsSync33 } from "fs";
 import { Builtins, Cli as Cli2 } from "clipanion";
 
@@ -250,7 +250,7 @@ function bucketByKind(kind, instance, bag) {
 // package.json
 var package_default = {
   name: "@skill-map/cli",
-  version: "0.60.1",
+  version: "0.60.3",
   description: "skill-map reference implementation \u2014 kernel + CLI + adapters.",
   license: "MIT",
   type: "module",
@@ -31058,4 +31058,4 @@ function resolveBareDefault() {
   process.exit(ExitCode.Error);
 }
 //# sourceMappingURL=cli.js.map
-//# debugId=ca73146f-c295-5016-832b-cc65f69fa85b
+//# debugId=d4d9801b-b9d6-5298-9ce5-eda6c347ce50

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]="c5cce3cb-db4a-5c0a-b02b-e6cb5dd6742c")}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]="d0f545db-4fe8-57c6-904a-2d7bacf3f8cd")}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.60.1",
+  version: "0.60.3",
   description: "skill-map reference implementation \u2014 kernel + CLI + adapters.",
   license: "MIT",
   type: "module",
@@ -3845,4 +3845,4 @@ export {
   runScanWithRenames
 };
 //# sourceMappingURL=index.js.map
-//# debugId=c5cce3cb-db4a-5c0a-b02b-e6cb5dd6742c
+//# debugId=d0f545db-4fe8-57c6-904a-2d7bacf3f8cd

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]="2b4abace-0a56-5647-88a4-9840c7001046")}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]="80354fd4-8ba5-5d44-bddb-926401a499be")}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.60.1",
+  version: "0.60.3",
   description: "skill-map reference implementation \u2014 kernel + CLI + adapters.",
   license: "MIT",
   type: "module",
@@ -3845,4 +3845,4 @@ export {
   runScanWithRenames
 };
 //# sourceMappingURL=index.js.map
-//# debugId=2b4abace-0a56-5647-88a4-9840c7001046
+//# debugId=80354fd4-8ba5-5d44-bddb-926401a499be