@zalom/plastic 1.1.0 → 1.1.1

package/skills/intent-continuing/evals/evals.json

@@ -1,15 +1,15 @@
 {
   "skill_name": "plastic-intent-continuing",
-  "notes": "Intent 36, updated for 36a (boot moved into hook-session-start; the skill is now work-continuation only). Scopes: description triggering (1-8) and behavior/convention compliance of the work-continuation skill (9-14). Triggering assertions follow the plastic-auto eval style (one subagent router per case). Behavior assertions are convention checks against the SKILL.md.",
+  "notes": "Intent 158a1: slimmed to the specific-intent resume route of plastic-continuing (D8, extract not duplicate). Bare 'continue' now belongs to the router; triggering evals 1-4 were recast so this skill's positives always name a specific intent, and eval 4 asserts bare 'continue' does NOT settle here directly. Behavior eval 11 (dashboard selection) was removed, relocated to plastic-project-continuing's evals. Behavior eval 15 is new: the terminal handoff goes to plastic-intent-starting, not directly to plastic-auto. Scopes: description triggering (1-8) and behavior/convention compliance of the ledger-resume skill (9-15).",
   "results": {
-    "triggering": { "cases": 8, "passed": 8, "run": "2026-06-16, one subagent per case" },
-    "behavior": { "cases": 6, "passed": 6, "evidence": "convention checks against skills/intent-continuing/SKILL.md after the intent-36 rewrite; doctor --core verified at 0.07s with 9 liveness checks and full doctor unchanged at 30 checks" }
+    "triggering": { "cases": 8, "passed": 8, "run": "2026-07-10, one subagent per case" },
+    "behavior": { "cases": 7, "passed": 7, "evidence": "convention checks against skills/intent-continuing/SKILL.md after the 158a1 extraction" }
   },
   "evals": [
     {
       "id": 1, "scope": "triggering", "set": "train",
-      "prompt": "continue",
-      "expected_output": "Activates plastic-intent-continuing (the bare 'continue' keyword is the documented trigger).",
+      "prompt": "continue intent 4a",
+      "expected_output": "Activates plastic-intent-continuing (a specific intent named by id).",
       "files": [],
       "assertions": [
         { "type": "code", "check": "router CHOICE == plastic-intent-continuing", "observed": "plastic-intent-continuing", "result": "pass" }
@@ -17,8 +17,8 @@
     },
     {
       "id": 2, "scope": "triggering", "set": "train",
-      "prompt": "resume where we left off",
-      "expected_output": "Activates plastic-intent-continuing.",
+      "prompt": "resume the statusline-coloring intent",
+      "expected_output": "Activates plastic-intent-continuing (a specific intent named by description).",
       "files": [],
       "assertions": [
         { "type": "code", "check": "router CHOICE == plastic-intent-continuing", "observed": "plastic-intent-continuing", "result": "pass" }
@@ -26,8 +26,8 @@
     },
     {
       "id": 3, "scope": "triggering", "set": "validation",
-      "prompt": "pick up where we left off in this project",
-      "expected_output": "Activates plastic-intent-continuing.",
+      "prompt": "continuing --intent 96",
+      "expected_output": "Activates plastic-intent-continuing (the --intent form).",
       "files": [],
       "assertions": [
         { "type": "code", "check": "router CHOICE == plastic-intent-continuing", "observed": "plastic-intent-continuing", "result": "pass" }
@@ -35,11 +35,11 @@
     },
     {
       "id": 4, "scope": "triggering", "set": "train",
-      "prompt": "boot plastic and show me where things stand",
-      "expected_output": "Activates plastic-intent-continuing (continuing work + presenting state is the skill's purpose; boot itself is hook-owned).",
+      "prompt": "continue",
+      "expected_output": "Does NOT settle on plastic-intent-continuing directly. Bare 'continue' with no specific intent named belongs to the plastic-continuing router, which defaults to plastic-project-continuing.",
       "files": [],
       "assertions": [
-        { "type": "code", "check": "router CHOICE == plastic-intent-continuing", "observed": "plastic-intent-continuing", "result": "pass" }
+        { "type": "code", "check": "router CHOICE != plastic-intent-continuing", "observed": "plastic-continuing", "result": "pass" }
       ]
     },
     {
@@ -72,7 +72,7 @@
     {
       "id": 8, "scope": "triggering", "set": "validation",
       "prompt": "what's the dashboard look like right now",
-      "expected_output": "May activate plastic-dashboard rather than plastic-intent-continuing; an overview request without 'continue/resume' is a dashboard task.",
+      "expected_output": "Does NOT activate plastic-intent-continuing directly; an overview request without a specific intent named is a dashboard/project-board task.",
       "files": [],
       "assertions": [
         { "type": "code", "check": "router CHOICE != plastic-intent-continuing", "observed": "plastic-dashboard", "result": "pass" }
@@ -97,16 +97,7 @@
       ]
     },
     {
-      "id": 11, "scope": "behavior", "set": "train",
-      "prompt": "Is dashboard selection project-aware?",
-      "expected_output": "Project loaded -> `dashboard.rb project <slug>`; otherwise -> `dashboard.rb continue`. Skill only invokes, does not render.",
-      "files": ["skills/intent-continuing/SKILL.md"],
-      "assertions": [
-        { "type": "convention", "check": "both dashboard invocations present and gated on project detection", "observed": "'dashboard.rb project <slug>' and 'dashboard.rb continue' in the 'Continue (present the dashboard)' section", "result": "pass" }
-      ]
-    },
-    {
-      "id": 12, "scope": "behavior", "set": "validation",
+      "id": 11, "scope": "behavior", "set": "validation",
       "prompt": "Is ledger-resume conditional and ledger-driven?",
       "expected_output": "Resume fires only when a specific intent is named; reads savepoint.md last line as stage, verifies the stage file, rebuilds on drift, derives next step from first unchecked checklist item.",
       "files": ["skills/intent-continuing/SKILL.md"],
@@ -115,7 +106,7 @@
       ]
     },
     {
-      "id": 13, "scope": "behavior", "set": "validation",
+      "id": 12, "scope": "behavior", "set": "validation",
       "prompt": "Are the stale prose-savepoint fields gone?",
       "expected_output": "No 'In progress' / 'Blockers' fields read from a prose savepoint remain; the ledger model is used instead.",
       "files": ["skills/intent-continuing/SKILL.md"],
@@ -124,7 +115,7 @@
       ]
     },
     {
-      "id": 14, "scope": "behavior", "set": "validation",
+      "id": 13, "scope": "behavior", "set": "validation",
       "prompt": "Is the 'Determine Store' local-store gap filled?",
       "expected_output": "Step 2 of Determine Store describes local/project-store detection (no empty step).",
       "files": ["skills/intent-continuing/SKILL.md"],
@@ -133,13 +124,22 @@
       ]
     },
     {
-      "id": 15, "scope": "behavior", "set": "validation",
+      "id": 14, "scope": "behavior", "set": "validation",
       "prompt": "QMD is present. The user says: continue the work on the statusline coloring (names the intent by description, not id).",
       "expected_output": "Before scanning the store with grep/Read to locate the named intent, runs `ruby ~/.plastic/scripts/qmd-sync search \"statusline coloring\"` to surface the candidate intent, then opens the authoritative intent file for the hit it resumes. No-op fallback to INDEX.md / file scan when QMD is absent.",
       "files": ["skills/intent-continuing/SKILL.md"],
       "assertions": [
         { "type": "human", "check": "qmd-sync search is run before grep/Read when the intent is named by description; authoritative file opened for the hit", "observed": "Conditional Ledger-Resume carries the QMD-first step: run qmd-sync search before grep/Read, then open the authoritative file; no-op fallback when QMD is absent", "result": "pass" }
       ]
+    },
+    {
+      "id": 15, "scope": "behavior", "set": "train",
+      "prompt": "Does the ledger-resume's terminal handoff go to plastic-intent-starting or directly to plastic-auto?",
+      "expected_output": "Step 5 announces state then hands off to plastic-intent-starting, which takes the lock and asks 'auto or guided?' exactly once; plastic-intent-starting's own auto branch is the one that hands to plastic-auto. This skill never hands to plastic-auto directly.",
+      "files": ["skills/intent-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "step 5 hands off to plastic-intent-starting, not plastic-auto; the single ask is attributed to plastic-intent-starting", "observed": "present in 'Conditional Ledger-Resume' step 5", "result": "pass" }
+      ]
     }
   ]
 }

package/skills/intent-continuing/references/context-management.md

@@ -1,4 +1,4 @@
-# Context Management (Start-Save-Continue)
+# Context Management (Save, then resume-flow debugging)
 
 ## Save Point
 Triggered by PreCompact hook or manually:
@@ -7,26 +7,22 @@ Triggered by PreCompact hook or manually:
 3. Update active intent's `savepoint.md` (in-progress, next steps, blockers, discoveries)
 4. Add observations to `## Insights`
 5. Update INDEX.md
-6. Commit: `cd ~/.plastic && git add . && git commit -m "chore: savepoint — [intent name]"`
+6. Commit: `cd ~/.plastic && git add . && git commit -m "chore: savepoint - [intent name]"`
 7. Notify user to `/clear`
 
-## Continue
-Triggered by UserPromptSubmit hook when user says "continue". Priority order:
+## Debugging the resume flow
 
-**1. Active intents first (resume work):**
-1. Read INDEX.md → find active intent(s)
-2. Read active intent's `intent.md` → what and why
-3. Read active intent's `savepoint.md` → where we left off
-4. Read active intent's `checklist.md` → what's next
-5. Announce: intent name, current state, next step, blockers
-6. Resume
+When a resume looks wrong (the announced stage does not match what is on disk, or the next
+step looks stale):
 
-**2. No active intents → offer future intents:**
-1. List all future intents from INDEX.md
-2. Present them as options
-3. When user picks one, move to Active in INDEX.md
+1. Read `savepoint.md`'s last line directly; that line alone is the source of truth for stage
+   (see `SKILL.md`'s `## Conditional Ledger-Resume` for the full state table).
+2. Confirm the artifact that line implies (`plan.md`, `checklist.md`, `outcome.md`, ...) is
+   present and non-empty on disk.
+3. If the two disagree, the ledger has drifted: rebuild it rather than hand-editing:
+   `ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.rebuild_savepoint("<intent_dir>")'`
+4. Re-read the rebuilt last line and re-derive the next step from `checklist.md`'s first
+   unchecked item.
 
-**3. Stale future intents (untouched 3+ days) → triage:**
-- **activate** — start working on it now
-- **abandon** — mark as abandoned
-- **defer to agent** — implement, research, or ideate
+The general "land on the board / priority order / stale future intents" flow now lives in
+`plastic-project-continuing`; this file no longer duplicates it.

package/skills/intent-savepoint/SKILL.md

@@ -42,6 +42,18 @@ Read the active store's `INDEX.md` and extract intents under `## Active`.
 - Confirm the **last line's stage** matches the stage derived from files-on-disk
   (`Bridge.derive_stage`). If they disagree, or the file is missing/empty, the ledger has
   drifted.
+- Run `Bridge.savepoint_phantom_lines(intent_dir)` (pure, disk-only, no bridge or session
+  resolution; intent 134). It flags a line disk evidence contradicts: a file-landing milestone
+  whose file is absent or still a sentinel placeholder, a duplicate `(stage, milestone)` pair, or
+  a state line (`How  started` / `Exec  started`) whose stage prerequisites are absent. If it
+  returns any lines:
+  - **LIVE intent (INDEX `## Active`):** rebuild via step 3 below.
+  - **INDEX `## Completed`/`## Abandoned` intent:** REPORT the phantom lines and STOP. Do not
+    rewrite. Completed intents are immutable. A repair is available only under an explicit human
+    grant, following the 124a precedent: rebuild the file-landing skeleton (step 3), then
+    re-append the terminal `Done  <disposition>` bookend with the disposition read from
+    `outcome.md`'s `disposition:` frontmatter and the timestamp recovered from the merge commit or
+    the file's mtime, never invented.
 
 ### 3. Rebuild on drift
 Reconstruct from the filesystem rather than hand-editing:

package/skills/intent-starting/evals/evals.json

@@ -40,7 +40,7 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "continue",
-      "expected_output": "Does NOT activate plastic-intent-starting; bare 'continue' is plastic-intent-continuing (no specific intent named).",
+      "expected_output": "Does NOT activate plastic-intent-starting; bare 'continue' is plastic-continuing (the router, no specific intent named).",
       "files": [],
       "assertions": [
         { "type": "code", "check": "router CHOICE != plastic-intent-starting", "result": "expect-pass" }

package/skills/project-continuing/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: plastic-project-continuing
+description: >-
+  Use when the user wants to land on the project board, asks "what should I work on" in this
+  project, or wants active intents plus the most-valuable next work surfaced. This is the
+  default route of plastic-continuing for a bare "continue" with no specific intent or roadmap
+  named. It presents state and stops without asking how to proceed - that single mode question
+  lives in plastic-intent-starting, once the user names a specific intent to work.
+user-invocable: true
+---
+
+# Project Continuing - land on the board
+
+`plastic-project-continuing` is the project route of `plastic-continuing`. It lands on the
+Markdown board, presents active work and the most-valuable next work, and stops. It does not
+resume a specific intent by ledger (that is `plastic-intent-continuing`) and it asks nothing.
+
+## Continue (present the board)
+
+Land on the Markdown board via the `plastic-dashboard` skill. Rendering belongs there, not
+here - run the data payload and fill + present the matching template:
+- Project loaded -> `ruby ~/.plastic/scripts/dashboard.rb project <slug> --data`
+- Otherwise (no project loaded, the global fallback) -> `ruby ~/.plastic/scripts/dashboard.rb continue --data`
+
+Fill the matching template from `plastic-dashboard`'s `templates/` and **present the filled
+Markdown in your reply** (every time, non-optional). If the reply does not contain the filled
+Markdown, the user sees nothing - tool-call stdout and hook `additionalContext` are both
+invisible to them. `hook-continue` also emits a one-line `systemMessage` summary as a
+hook-owned fallback; treat it as a floor only, never as a substitute for presenting the full
+board here. See `plastic-dashboard` for the fill mechanics (`references/board-fill.md` has the
+scoped detail).
+
+The board load runs the scoped store check on every load (`doctor --store <scope>`): the
+global board runs `--store global` and a project board runs `--store <slug>`. The result
+arrives in the payload as `store_health`; surface it as a one-line store-health note. It is
+non-fatal (a warn or fail is shown as data, it does not block continuing).
+
+## Priority Order
+
+1. **Active intents first** - surface work in progress.
+2. **Project context** - if in a registered project, show governing + tactical intents.
+3. **Stale future intents** - surface for triage (see below).
+4. **Fresh future intents** - offer as next work.
+
+## Stale Future Intents
+
+If a future intent's `created` date is older than the configured `stale_threshold_days`
+(default 3), surface it for triage without taking action:
+
+```
+Stale future intents (no action taken):
+
+- [ID - name] (X days old)
+  a) Activate - start working on it now
+  b) Abandon - mark as abandoned
+  c) Defer to agent: implement | research | ideate
+  d) Auto - go fully autonomous (invokes plastic-auto)
+```
+
+When the user activates a future intent, move it to `## Active` in INDEX.md and auto-commit.
+
+**Defer to agent: research.** Selecting `research` is a real dispatch, not a label. Resolve
+`plastic-future-intent-researcher`'s model via `read-config agents.models.<basename> --project
+<repo>` (project override, then global, then the shipped tier default) rather than relying on
+bare frontmatter, which also honors a sanctioned `agents.models.<name>` override if one is
+configured. Dispatch the agent (Agent tool, `subagent_type: "plastic-future-intent-researcher"`)
+on the selected stale future intent, passing the resolved model explicitly. The agent writes its
+findings into that intent's `## Context` (see `agents/plastic-future-intent-researcher.md`); it
+does not itself dispatch further sub-agents. Once it returns, re-present the stale-future-intent
+triage so the user can act on the fresh findings now on record.
+
+## Deciding rules
+
+The board's ranked next-work order is deterministic, computed by `dashboard.rb`; this skill
+never re-derives it. Cite the rule NAMES only when explaining a ranking or disposition: Effort,
+Value, Flags, Override, Caps. Read `plastic-dashboard`'s `references/classification.md` for the
+definitions; do not restate or copy them here.
+
+## Then stop
+
+Present "here is the state, what next?" and wait. Offer active intents first, then future
+intents. Do not start executing work. The only follow-up from here:
+- User/agent names a specific intent to continue -> hand to `plastic-intent-continuing`
+  (which reads the ledger and, in turn, hands to `plastic-intent-starting` for the single
+  auto-or-guided ask).
+
+## Coordination
+
+Intent 149 has landed: the dashboard is demoted to prose (no Value x Effort grid). This skill
+was built against the live INDEX.md-parsing `--data` path (147, the DB cutover, has not
+landed). Its rule-name citations (`classification.md`, cited by name, not logic) and the
+`dashboard.rb project <slug> --data` -> `dashboard-project.md` path still resolve.
+
+Intent 148 landed: roadmaps are the primary planning surface. When the tier has a mid-flight
+roadmap (`ruby ~/.plastic/scripts/roadmap-next --roadmaps-dir <tier>/roadmaps` reports a `state`
+other than `none`), the roadmap route (`plastic-roadmap-continuing`) is the live surface for
+"what to work next", and `plastic-continuing` routes there. This board still presents project
+state and stops, asking nothing (unchanged): it does not itself dispatch, re-rank, or resume a
+roadmap. The global store and any project with no roadmap report `none`, so this board stays the
+default route for them.
+
+## References
+
+- `references/board-fill.md` - the template-fill mechanics and store-health surfacing detail.

package/skills/project-continuing/evals/evals.json

@@ -0,0 +1,100 @@
+{
+  "skill_name": "plastic-project-continuing",
+  "notes": "Intent 158a1. New project route, absorbing intent-continuing's Continue/Priority Order/Stale Future Intents sections (move, not duplicate). Scopes: description triggering (1-3) and behavior/convention compliance (4-10), the latter checked against SKILL.md.",
+  "results": {
+    "triggering": { "cases": 3, "passed": 3, "run": "2026-07-10, one subagent per case" },
+    "behavior": { "cases": 7, "passed": 7, "evidence": "convention checks against skills/project-continuing/SKILL.md after the 158a1 extraction; id 10 (intent 170) added for the research-dispatch wiring of plastic-future-intent-researcher" }
+  },
+  "evals": [
+    {
+      "id": 1, "scope": "triggering", "set": "train",
+      "prompt": "what should I work on in this project",
+      "expected_output": "Activates plastic-project-continuing.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-project-continuing", "observed": "plastic-project-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 2, "scope": "triggering", "set": "train",
+      "prompt": "land me on the project board",
+      "expected_output": "Activates plastic-project-continuing.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-project-continuing", "observed": "plastic-project-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 3, "scope": "triggering", "set": "validation",
+      "prompt": "continue",
+      "expected_output": "Bare 'continue' with no specific intent or roadmap named reaches plastic-project-continuing via plastic-continuing's default route.",
+      "files": [],
+      "assertions": [
+        { "type": "code", "check": "router CHOICE == plastic-project-continuing", "observed": "plastic-project-continuing", "result": "pass" }
+      ]
+    },
+    {
+      "id": 4, "scope": "behavior", "set": "train",
+      "prompt": "Is dashboard selection project-aware?",
+      "expected_output": "Project loaded -> `dashboard.rb project <slug> --data` -> fills dashboard-project.md; otherwise -> `dashboard.rb continue --data`. Skill only invokes, does not render.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "both dashboard invocations present and gated on project detection", "observed": "'dashboard.rb project <slug>' and 'dashboard.rb continue' in the 'Continue (present the board)' section", "result": "pass" }
+      ]
+    },
+    {
+      "id": 5, "scope": "behavior", "set": "train",
+      "prompt": "Does the skill cite the classification rules by name instead of copying the logic?",
+      "expected_output": "SKILL.md's 'Deciding rules' section names Effort/Value/Flags/Override/Caps and points to plastic-dashboard's references/classification.md; it does not restate the rule definitions.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "rule names cited, no copied Effort/Value/Flags/Override/Caps definitions", "observed": "present in 'Deciding rules'", "result": "pass" }
+      ]
+    },
+    {
+      "id": 6, "scope": "behavior", "set": "train",
+      "prompt": "Does the project route ask 'auto or guided?' before stopping?",
+      "expected_output": "No. The project route presents state then stops; it asks nothing. The single ask lives in plastic-intent-starting once a specific intent is named.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "no 'auto or guided' ask anywhere in SKILL.md", "observed": "absent", "result": "pass" }
+      ]
+    },
+    {
+      "id": 7, "scope": "behavior", "set": "validation",
+      "prompt": "Does the skill present the board before stopping?",
+      "expected_output": "The filled Markdown board is presented in the reply (non-optional), then a 'Then stop' section waits for the user.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "presentation is mandatory and precedes the 'Then stop' wait", "observed": "present", "result": "pass" }
+      ]
+    },
+    {
+      "id": 8, "scope": "behavior", "set": "validation",
+      "prompt": "Does the skill carry the intent-149 coordination note?",
+      "expected_output": "A 'Coordination' section records that intent 149 has landed (dashboard demoted to prose, no Value x Effort grid) and confirms the rule-name citations and the dashboard.rb project <slug> --data -> dashboard-project.md path still resolve.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "'149' present with the landed coordination note", "observed": "present: 'Intent 149 has landed' with confirmed rule-name citations and dashboard.rb path", "result": "pass" }
+      ]
+    },
+    {
+      "id": 9, "scope": "behavior", "set": "validation",
+      "prompt": "Are Priority Order and Stale Future Intents present here and only here (not in intent-continuing)?",
+      "expected_output": "Both sections are present verbatim in this skill; they no longer exist in skills/intent-continuing/SKILL.md.",
+      "files": ["skills/project-continuing/SKILL.md", "skills/intent-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "'## Priority Order' and '## Stale Future Intents' present here, absent from intent-continuing", "observed": "present here, absent there", "result": "pass" }
+      ]
+    },
+    {
+      "id": 10, "scope": "behavior", "set": "validation",
+      "prompt": "In the stale-future-intent triage, the user picks option c) Defer to agent: research. What happens?",
+      "expected_output": "A real dispatch, not a label: plastic-future-intent-researcher's model is resolved via `read-config agents.models.<basename> --project <repo>` (never bare frontmatter, sanctioned-override-aware), the agent is dispatched via the Agent tool on the selected stale future intent and writes its findings into that intent's `## Context`, then the skill re-presents the stale-future-intent triage.",
+      "files": ["skills/project-continuing/SKILL.md"],
+      "assertions": [
+        { "type": "convention", "check": "the 'Defer to agent: research' paragraph under Stale Future Intents resolves the model via read-config (not bare frontmatter), dispatches plastic-future-intent-researcher via the Agent tool, and re-presents the triage after the agent returns", "observed": "'Defer to agent: research.' paragraph present: resolves via read-config agents.models.<basename> --project <repo>, dispatches subagent_type plastic-future-intent-researcher, findings land in ## Context, then re-presents the triage", "result": "pass" }
+      ]
+    }
+  ]
+}

package/skills/project-continuing/references/board-fill.md

@@ -0,0 +1,33 @@
+# Board Fill Mechanics
+
+Depth reference for the "Continue (present the board)" section of `SKILL.md`. The fill itself
+is mechanical; `plastic-dashboard` owns the rules, this page is a pointer plus the detail that
+would otherwise bloat the SKILL.md body.
+
+## Fill rules (owned by plastic-dashboard, summarized here for convenience)
+
+- `{{a.b.count}}` -> the integer (e.g. `counts.active` is that count).
+- `{{...lines}}` -> join the list's `.line` strings with real newlines (one per line). These
+  are ordinary prose lines; never add a `-` prefix, never emit `<br>`. An empty list renders
+  `_(none)_`.
+- `next_work.lines` -> the most-valuable next work, already ranked and capped.
+- `active.lines` / `future.lines` (project board) -> one line per intent, already formatted.
+- Scalars (`{{date}}`, `{{slug}}`, `{{description}}`) -> substitute verbatim.
+
+No re-sorting, no re-summarizing, no hand-written prose replacing a line the payload already
+supplies. Same store state produces a byte-identical payload regardless of model.
+
+## Store-health surfacing
+
+Every board load runs the scoped `doctor --store <scope>` check server-side (inside
+`dashboard.rb`, not this skill). The payload carries the result as `store_health` (`{scope,
+status, summary, failing_checks}`). Render it as a single line, for example `store health:
+pass (3/3)` or `store health: warn (orphaned_intents)`. A warn or fail is informational only;
+it never blocks presenting the board.
+
+## Project vs. global fallback
+
+The project route's default target is the project board. When no project is loaded (the rare
+case where this route is reached without a registered project in scope), fall back to the
+global board payload (`dashboard.rb continue --data`) rather than failing. This mirrors the
+router's D6 default: a bare "continue" always lands somewhere useful.

package/skills/releasing/SKILL.md

@@ -15,6 +15,7 @@ Project configuration drives the workflow - no hardcoded assumptions.
 - [ ] All tests pass (or verification skipped per config)
 - [ ] Merge feature branch to main
 - [ ] Bump version in configured version files
+- [ ] Stable-cut guard passes (version files agree, no pre-release suffix; stable/latest cuts only)
 - [ ] Commit version bump
 - [ ] Create annotated tag
 - [ ] Push to remote with tags
@@ -94,6 +95,25 @@ the full rationale and the already-merged-by-hand no-op case, read
 
 ### 4. Bump Version
 
+**Stable-cut guard.** Before touching any version file for a stable (no pre-release suffix,
+`latest`) cut, run the guard in `scripts/lib/release_guard.rb`:
+
+```ruby
+require "./scripts/lib/release_guard"
+result = ReleaseGuard.check(
+  package_json: "package.json",
+  plugin_json: ".claude-plugin/plugin.json",
+  marketplace_json: ".claude-plugin/marketplace.json",
+  stable: true
+)
+raise "release guard failed: #{result.mismatches} #{result.prerelease_suffix}" unless result.ok?
+```
+
+If it reports a mismatch or a pre-release-suffix violation, stop and resolve it before bumping
+any file. For a beta or alpha cut, pass `stable: false`; only version-file agreement is checked,
+a pre-release suffix is expected. Read `references/release-lines.md` for the stable-line
+guarantees this guard protects.
+
 Determine which files to update from project.yml:
 
 - If `release.version_files` is set: update ALL listed files (they must stay in sync).
@@ -252,6 +272,32 @@ prune` in the affected repo if you hit a stale reference. For why this is the on
 merge-vs-remove policy lands on merge, and the fail-open/idempotent guarantees of `finish`,
 read `references/promotion-and-tagging.md`.
 
+## Release lines and channels
+
+Two lanes get code to a release, on top of the workflow above.
+
+- **Default lane.** Branch, merge to main, cut stable, publish to npm `latest`. This is the
+  workflow in the steps above, unchanged. Use it for additive, suite-verifiable,
+  low-blast-radius work.
+- **Beta-verified lane.** Branch, merge to `beta`, publish to the npm `beta` channel, verify in
+  real use, then merge to main and cut stable. Use it for work that changes operational
+  substrate, or carries data, migration, lock, or state-format risk, or that a hermetic suite
+  cannot fully validate on its own.
+
+**Stable-line guarantees.** An external `latest` user can rely on:
+
+- `main` is always green and releasable; no pending revert awaiting re-land sits on `main`.
+- A stable release carries no pre-release suffix, publishes to `latest`, and the newest release
+  always carries the GitHub "Latest" badge.
+- The three version files always agree, checked by `scripts/lib/release_guard.rb` (see Bump
+  Version above).
+- A stable cut collects only intents that cleared their lane's verification bar.
+- Channel semantics are fixed: `latest` is stable, `beta` is the verification line, `alpha` is
+  experimental.
+
+Read `references/release-lines.md` for the full lane-routing detail, the version-line map, and
+the intent-41 re-land playbook.
+
 ## Conventions
 
 - **Annotated tags only** - `git tag -a`, never lightweight tags
@@ -266,6 +312,8 @@ read `references/promotion-and-tagging.md`.
 
 ## References
 
+- Read `references/release-lines.md` for the two release lanes, the stable-line guarantees,
+  the version-line map, and the intent-41 re-land playbook before starting any release
 - When promoting a pre-release across channels (`--promote beta`/`--promote stable`) or
   tagging a historical release retroactively, read `references/promotion-and-tagging.md`
   for the exact commands and rules first

package/skills/releasing/references/release-lines.md

@@ -0,0 +1,105 @@
+# Release Lines and Channels
+
+The two release lanes, the version-line map, and the intent-41 re-land playbook: the deep
+material behind SKILL.md's "Release lines and channels" section.
+
+## Table of Contents
+
+- [The two lanes](#the-two-lanes)
+- [Routing rule](#routing-rule)
+- [Stable-line guarantees](#stable-line-guarantees)
+- [Version-line map](#version-line-map)
+- [Intent 41 re-land playbook](#intent-41-re-land-playbook)
+
+## The two lanes
+
+**Default lane.** Branch, merge to `main` with `--no-ff`, cut stable, publish to npm `latest`.
+This is the workflow SKILL.md documents step by step. It is the path for additive,
+suite-verifiable, low-blast-radius work: new skills, prose, deterministic scripts, anything a
+green Minitest run can fully vouch for.
+
+**Beta-verified lane.** Branch, merge to the `beta` branch, publish to the npm `beta` dist-tag,
+verify in real use, then merge `beta` into `main` and cut stable. It sits on top of the existing
+promotion mechanics (`--promote beta` / `--promote stable`, linear only, see
+`promotion-and-tagging.md`); it names when to use them, not new machinery.
+
+## Routing rule
+
+Work rides the beta-verified lane when it changes operational substrate, carries data,
+migration, lock, or state-format risk, or cannot be fully validated by a hermetic suite alone.
+Everything else merges straight to main.
+
+Intent 41's DB layer is the archetypal beta-lane case: it replaces the bridge, lock, and session
+file formats with a new persistent SQLite substrate. A green suite proves the code correct; it
+cannot prove the new substrate survives real, uncontrolled usage, so real-use verification on
+beta comes first.
+
+The manual-first roadmap's eight 1.1.0 intents (158a, 163, 161, 164, 165, 168, 166, 159) are all
+default-lane: skill directory renames, prose rewrites, deterministic step scripts. Additive, and
+fully suite-verified.
+
+## Stable-line guarantees
+
+What an external `latest` user can rely on:
+
+1. `main` is always green and releasable. No pending revert awaiting re-land sits on `main`.
+   When something needs beta verification, it comes out of `main` the same day that need is
+   found (the 226023f precedent), never left half-landed.
+2. A stable release carries no pre-release suffix, publishes to npm `latest`, and the newest
+   stable release always carries the GitHub "Latest" badge (`gh release create --latest` on
+   every cut).
+3. The three repo version files (`package.json`, `.claude-plugin/plugin.json`,
+   `.claude-plugin/marketplace.json`) always agree. Checked mechanically by
+   `scripts/lib/release_guard.rb`.
+4. A stable cut collects only intents that cleared their lane's bar: default-lane intents by a
+   green suite, beta-lane intents by suite green plus their lane's own verification (real-use
+   signal, owner sign-off).
+5. Channel semantics are fixed: `latest` is stable and what an external user should run; `beta`
+   is the verification line, published but expected to move; `alpha` is experimental,
+   pre-verification.
+
+## Version-line map
+
+| Line | State | What lands here |
+|---|---|---|
+| `1.1.x` | Current stable line (main) | Additive or low-risk work merged straight to main; interim stable cuts, including 171's wave-6 cut, stay in this line |
+| `1.2.0-beta.1` | On beta (`9ec194b`, unpublished) | Intent 41's DB layer, restored over 1.1.0 by revert-of-revert (`c48601a` then `9ec194b`) |
+| `1.2.0` | Reserved | The stable graduation of the DB layer, once beta verification passes; not claimed by any interim `1.1.x` cut |
+
+A beta-graduated substrate change claims its reserved minor at the moment it actually merges to
+main, not before. Nothing else on the `1.1.x` line is blocked waiting for `1.2.0`.
+
+## Intent 41 re-land playbook
+
+Written for the wave-6 cut intent (171) and any future reader to pick a version without
+re-deriving this decision.
+
+**Current state.** The revert-of-revert already sits on the `beta` branch at `9ec194b`, on top
+of 1.1.0, versioned `1.2.0-beta.1` (`c48601a`). There is nothing left to execute on the git side;
+this playbook describes what happens next, not a pending action.
+
+**Preconditions**, both required before any npm publish of `1.2.0-beta.1`:
+
+- (a) One documentation pass over beta-line skills and docs for the hybrid savepoint contract:
+  on beta, only the terminal Done bookend still writes a live `savepoint.md`; every other
+  milestone lives in `savepoint_events` plus a committed JSONL export. Beta-line prose that
+  still assumes an always-live ledger needs updating first, so a beta-line reader does not
+  mistake an empty ledger for a broken one.
+- (b) The owner's manual verification of the DB layer in real use. This is a dogfood signal,
+  distinct from the independently-reviewed green suite that already exists on beta.
+
+**Trigger**, owner-gated: the owner publishes `1.2.0-beta.1` to the npm `beta` dist-tag. This is
+explicitly not this intent's, nor any agent's, call to make.
+
+**Verification.** An external tester plus the owner verify the DB layer on the beta channel.
+
+**Completion.** Once verified, `beta` merges into `main`, `1.2.0` is cut stable, and it publishes
+to npm `latest`.
+
+**Version mechanics.** `1.2.0` is reserved for this graduation. The `1.1.x` line stays the
+stable line until `1.2.0` actually lands. `1.2.0-beta.1` graduates to `1.2.0` stable by dropping
+the pre-release suffix; nothing else about the version number changes.
+
+**Consumed by 171.** The wave-6 consistency-dividend cut stays in the `1.1.x` line. It does not
+ride intent 41 and needs no further derivation: intent 41 keeps its own `1.2.0` line on beta,
+independent of whatever `1.1.x` number 171 lands on.