@zalom/plastic 1.4.0 → 1.5.0

package/skills/auto/SKILL.md

@@ -93,13 +93,15 @@ edited before the plan exists (the gate applies to YOU, the orchestrator):
 
 ```bash
 ruby -r ~/.plastic/scripts/lib/bridge -e \
-  'Bridge.arm_auto(ENV["CLAUDE_CODE_SESSION_ID"], intent_id: "<ID>", intent_dir: "<STORE>/<dir>", store: "<STORE>", name: "<name>")'
+  'codex=ENV["CODEX_THREAD_ID"].to_s.strip; claude=ENV["CLAUDE_CODE_SESSION_ID"].to_s.strip; harness=!codex.empty? ? "codex" : (!claude.empty? ? "claude" : nil); session=!codex.empty? ? codex : (!claude.empty? ? claude : nil); Bridge.arm_auto(session, intent_id: "<ID>", intent_dir: "<STORE>/<dir>", store: "<STORE>", name: "<name>", harness: harness, agent: "plastic-enforcer", thread: (!codex.empty? ? codex : nil))'
 ```
 
 Replace `<ID>`, `<STORE>` (e.g. `~/.plastic/projects/<slug>/store` or `~/.plastic/store`),
 `<dir>` (the `ID--slug` directory), and `<name>`. The first argument is the session id you
-want the bridge keyed by: pass the hook stdin `session_id` when you have it, otherwise
-`ENV["CLAUDE_CODE_SESSION_ID"]`, otherwise `nil`. Arming always succeeds and acquires the
+want the bridge keyed by: pass the hook stdin `session_id` when you have it. The executable
+snippet trusts a nonblank `CODEX_THREAD_ID` as Codex, otherwise a nonblank
+`CLAUDE_CODE_SESSION_ID` as Claude, otherwise leaves harness and thread unknown. Never guess
+identity from an absent runtime variable. Arming always succeeds and acquires the
 durable `delivery.lock` in the intent dir. For the `resolve_session` fallback chain
 (why arming never needs a non-empty session env var, and what the lock ownership model
 implies for later tool calls) read `references/end-tail.md`.
@@ -148,12 +150,33 @@ The enforcer's session owns the delivery lock. Per-stage specialists run in
 their own sessions and would be denied by the lock gate, so register each one
 as a delegate before (or when) it needs to write into the intent dir:
 
-1. Instruct each spawned specialist to report its session id
-   (`CLAUDE_CODE_SESSION_ID`) in its first message.
+1. Instruct each spawned specialist to report its session id and runtime identity in its first
+   message: `CODEX_THREAD_ID` for Codex, or `CLAUDE_CODE_SESSION_ID` for Claude. Use the
+   specialist/hook identity when known; never infer a harness or model from missing context.
 2. As the lock owner, run:
-   `ruby ~/.plastic/scripts/plastic-lock delegate --delegate <specialist-session-id>`
+   `ruby ~/.plastic/scripts/plastic-lock delegate --intent-dir <intent-dir> --delegate <specialist-session-id> --harness <specialist-harness-when-known> --agent <role> --model <resolved-model-when-known> --thread <reported-CODEX_THREAD_ID-when-Codex>`
+   Omit `--harness`, `--model`, or `--thread` when that value is unknown; `--agent <role>` is
+   always known from the dispatch roster.
 3. If a specialist hits a lock-gate deny, the deny message names this exact
    command; run it and have the specialist retry.
+4. Immediately after the specialist returns, and before validating or dispatching
+   the next handoff, classify the return and record its activity status as the owner:
+   - `finished` means the specialist returned a usable completion report, whether
+     agent-authored or synthesized through `scripts/agent-report`.
+   - `failed` means the specialist returned blocked, errored, or without a usable
+     completion report that can be synthesized.
+5. Record the classification with exactly one of:
+   ```bash
+   ruby ~/.plastic/scripts/plastic-lock delegate --intent-dir <intent-dir> \
+     --delegate <specialist-session-id> --status finished --harness <same-specialist-harness-when-known> \
+     --agent <same-role> --model <same-resolved-model-when-known> --thread <same-CODEX_THREAD_ID-when-Codex>
+   ruby ~/.plastic/scripts/plastic-lock delegate --intent-dir <intent-dir> \
+     --delegate <specialist-session-id> --status failed --harness <same-specialist-harness-when-known> \
+     --agent <same-role> --model <same-resolved-model-when-known> --thread <same-CODEX_THREAD_ID-when-Codex>
+   ```
+   Apply the same omission rule to unknown values on terminal status commands.
+   A failed specialist stops that handoff under the normal blocker/error procedure;
+   never dispatch the next specialist first.
 
 Only the owner can delegate. Delegates cannot re-delegate or release.
 

package/skills/auto/references/agent-architecture.md

@@ -81,6 +81,13 @@ account therefore always exists: agent-authored when present, deterministically
 otherwise. This structures the finish notification only; in-flight observations stay in
 `## Insights`, no progress chatter is added.
 
+Immediately after a specialist returns and before the next handoff, the enforcer records the
+delegate's activity through `plastic-lock delegate --intent-dir <intent-dir> --delegate <id>
+--status finished|failed`. `finished` requires a usable agent-authored or synthesized completion
+report. A blocked or errored return, or one with no report that can be synthesized, is `failed`
+and stops the handoff under the normal error procedure. Activity status is descriptive and does
+not revoke the registered delegate's authorization.
+
 ### Gate Ownership
 
 The enforcer arms and verifies the lifecycle gate, then gates every stage transition.

package/skills/auto/references/end-tail.md

@@ -44,12 +44,14 @@ deliberately); and the durable lock file is checked again after disarm, never me
 trusted (exit 3 if it is somehow still present).
 
 **Worktree cleanup (mandatory, intent 73c3).** `end-intent`'s step 5 calls
-`Bridge.disarm_auto` by default, which calls `Worktree.release`, which removes both
-per-intent worktrees (the code worktree under `<repo>/.claude/worktrees/{id}--{slug}` and
-the paired store worktree under `<plastic_home>/.worktrees/{id}--{slug}`), prunes both
-repos, and clears the worktree block from the bridge. This is the plain remove path: the
-disarm route does NOT merge, so use it only when no release merges the branch (the branch
-survives and can be reclaimed).
+`Bridge.disarm_auto` by default, which calls `Worktree.release`, which removes the
+intent's code worktree under `<repo>/.claude/worktrees/{id}--{slug}`, prunes the repo, and
+clears the worktree block from the bridge. (Plastic used to also provision a paired store
+worktree under `<plastic_home>/.worktrees/{id}--{slug}`; intent 178 retired it, since
+lifecycle-doc writes go straight to the main store checkout, and intent 197's
+branch-from-main plus scoped commit already gives them their own write safety.) This is the
+plain remove path: the disarm route does NOT merge, so use it only when no release merges
+the branch (the branch survives and can be reclaimed).
 
 When the work is being shipped through a release, do NOT rely on this plain remove.
 `skills/releasing/SKILL.md` reorders its own two steps for exactly this reason (intent 188,

package/skills/dashboard/SKILL.md

@@ -33,14 +33,19 @@ ruby ~/.plastic/scripts/dashboard.rb [continue|project <slug>] --data
 - `continue` (default) → the **global** board payload (`mode: "global"`).
 - `project <slug>` → that **project** board payload (`mode: "project"`).
 
-The payload is read-only JSON. Global-board fields: `date`, `store_health`, `recently_worked`,
-`next_work`, `counts`, `projects`, `project_totals`. Project-board fields: `slug`, `store_health`,
-`description`, `recently_worked`, `next_work`, `counts`, `active`, `future`. Each list carries
-cell-ready fields for its table: `next_work` rows are
+The payload is read-only JSON. Global-board fields: `date`, `store_health`, `summary`,
+`next_work`, `next_total`, `next_shown`, `counts`, `projects`, `project_totals`, `footer`.
+Project-board fields: `slug`, `store_health`, `description`, `summary`, `counts`, `active`,
+`active_total`, `active_shown`, `next_work`, `next_total`, `next_shown`, `footer`. `summary`
+and `footer` are finished prose strings (2-3 sentences and one line respectively), built in
+`dashboard.rb` and substituted verbatim, exactly like `{{date}}`/`{{description}}` already
+are - never re-worded or re-derived by the skill. Each list carries cell-ready fields for
+its table: `next_work` rows are
 `{id, intent, scope, lifecycle, value, disposition, flags, what, flags_label, line}`;
-`recently_worked` rows carry `{id, status, glyph, last_accessed_at, what, state, scope, line}`;
-`active`/`future` rows carry `{id, intent, created, bullet, scope, what, stage, line}`. The `what`,
-`scope`, and `flags_label` cell fields arrive pipe-escaped and whitespace-normalized.
+`active` rows carry
+`{id, intent, created, bullet, scope, what, stage, worker, activity, line}`. The `what`,
+`scope`, `worker`, `activity`, and `flags_label` cell fields arrive pipe-escaped and
+whitespace-normalized.
 
 Each board load runs the scoped store check (`doctor --store <scope>`): the global board runs
 `--store global` and a project board runs `--store <slug>`. The result rides in the payload as
@@ -57,24 +62,42 @@ Templates live in this skill's `templates/` directory:
 
 Fill mechanically, no rewriting, no re-sorting:
 - `{{a.b.count}}` → the integer (e.g. `counts.active` = that count).
-- `{{<list>.rows}}` → the four intent lists (`recently_worked`, `next_work`, `active`, `future`)
-  render as **Markdown table rows**. The template hard-codes each table's header and separator;
-  this placeholder becomes one data row per list entry, joined with real newlines, in that table's
-  fixed column order (below). Drop each cell from the named payload field **verbatim**: cells
-  arrive pre-escaped and whitespace-normalized from the script (pipes escaped as `\|`), so never
-  re-escape, re-truncate, or reword them. Never emit `<br>`.
-  - `recently_worked` (global) → `| {id} | {what} | {state} | {scope} |`
-  - `recently_worked` (project) → `| {id} | {what} | {state} |`
+- `{{<list>.rows}}` → the two intent lists (`active`, `next_work`) render as **Markdown table
+  rows**. The template hard-codes each table's header and separator; this placeholder becomes
+  one data row per list entry, joined with real newlines, in that table's fixed column order
+  (below). Drop each cell from the named payload field **verbatim**: cells arrive pre-escaped
+  and whitespace-normalized from the script (pipes escaped as `\|`), so never re-escape,
+  re-truncate, or reword them. Never emit `<br>`.
   - `next_work` → `| {id} | {what} | {value} | {disposition} | {flags_label} |`
-  - `active` → `| {id} | {what} | {stage} |`
-  - `future` → `| {id} | {what} |`
-  Overflow entry (empty `id`, `what` = `+N more`) → one row with `+N more` in the Id column and
-  every other cell blank. Empty list → one full-width row with `_(none)_` in the Id column and
-  every other cell blank, matching that table's column count (e.g. `| _(none)_ | | | | |` for
-  the 5-column next_work table, `| _(none)_ | |` for the 2-column future table).
-- `{{projects.lines}}` → the project rollup stays **prose**, one line per project (not a table):
+  - `active` → `| {id} | {what} | {stage} | {worker} | {activity} |`
+  Empty list → one full-width row with `_(none)_` in the Id column and every other cell blank,
+  matching that table's column count (e.g. `| _(none)_ | | | | |` for the 5-column next_work
+  table, `| _(none)_ | | | |` for the 5-column active table). Neither list carries an overflow
+  "+N more" row anymore (D5, intent 202): the true pool size rides on the payload as
+  `active_total`/`next_total` (shown counts as `active_shown`/`next_shown`), and `{{footer}}`
+  states it in prose instead.
+- `{{projects.lines}}` (global board only) → the project rollup stays **prose**, one line per
+  project (not a table):
   `- **{slug}**: {description}, active {active}, done {done}, future {future}, last accessed {last_accessed_at[0,10]}`.
-- Scalars (`{{date}}`, `{{slug}}`, `{{description}}`) → substitute verbatim.
+- Scalars (`{{date}}`, `{{slug}}`, `{{summary}}`, `{{footer}}`) → substitute verbatim. `summary`
+  and `footer` are finished prose built in `dashboard.rb`; do not rewrite, shorten, or
+  re-derive them from the counts - that is exactly the non-determinism D5 rules out.
+
+### Paging (conversational, D4)
+
+The board shows a short page by default (Active capped at 3, Next-work at 5). When the
+user asks for "more" or "all", re-invoke Step 1 with an explicit flag and re-fill the
+template with the new payload - nothing is persisted to disk, the offset lives only in the
+chat turn:
+- "all" → add `--all` (lifts both caps to unbounded; the footer then shows equal shown/total).
+- "more" → add `--limit-active N`/`--limit-next N` with a larger `N` for whichever list the
+  user is paging.
+
+For a real, own-terminal pager instead, point the owner at `--plain`:
+`ruby ~/.plastic/scripts/dashboard.rb project <slug> --plain | less` (or `continue --plain`
+for the global board). `--plain` prints the full, uncapped board as plain text with no
+Markdown table syntax; it is a separate CLI mode from `--data`, not something this skill
+fills a template from.
 
 ### Step 3 — Present it (mandatory, every invocation)
 
@@ -139,8 +162,8 @@ intentional change means the skill is broken.
 
 ## Notes
 
-- The four intent lists (recently worked, active, future, next work) render as Markdown tables;
-  the narrative wrappers, counts, and the project rollup stay prose. No Value x Effort grid
+- The two intent lists (active, next work) render as Markdown tables; the prose summary,
+  footer, counts, and the project rollup stay prose (intent 202). No Value x Effort grid
   returns. Never emit `<br>`.
 - Clusters (Zettelkasten grouping in INDEX.md) are intentionally not rendered.
 - Additive: changes no core lifecycle, gate, or cycle logic.

package/skills/dashboard/evals/evals.json

@@ -22,14 +22,14 @@
       "id": 2,
       "scope": "behavior",
       "set": "validation",
-      "prompt": "How do the four intent lists render on the Markdown boards?",
-      "expected_output": "recently_worked, next_work, active, and future render as Markdown tables (fixed columns: next_work Id|What|Value|Disposition|Flags; active Id|What|Stage; future Id|What; recently_worked Id|What|State, plus a Scope column on the global board). The narrative wrappers, counts, and the projects rollup stay prose; no Value x Effort grid. Cells arrive pre-escaped from the payload and are dropped verbatim.",
+      "prompt": "How does the project board render after intent 202 (short by default, paged on request)?",
+      "expected_output": "The project board shows, in order, and nothing else: a 2-3 sentence prose summary of what was delivered most recently (built in dashboard.rb from completed/completed_on data, not the 24h-windowed recently_worked), an Active table capped at 3 rows (Id|What|Stage, ordered lifecycle-stage descending with a savepoint tie-break), a Next-work table capped at 5 rows (Id|What|Value|Disposition|Flags), and a one-line footer stating true totals (e.g. '3 of 12 active, 5 of 47 next work') plus how to see everything. The raw Future table and its {{future.rows}} placeholder, and the separate Recently-worked table, are both gone from dashboard-project.md. dashboard-global.md carries the equivalent fix (D6): a prose summary in place of its recently-worked table, the same honest footer, and the same --limit-active/--limit-next/--all/--plain mechanics.",
       "files": ["skills/dashboard/templates/dashboard-global.md", "skills/dashboard/templates/dashboard-project.md", "skills/dashboard/SKILL.md"],
       "assertions": [
         {
           "type": "convention",
-          "check": "the four intent lists render as Markdown tables with the fixed columns; wrappers and the projects rollup stay prose; no grid",
-          "observed": "templates hard-code table headers plus {{list.rows}} for recently_worked/next_work/active/future; SKILL.md Step 2 documents the fixed column order and verbatim pre-escaped cell fill; projects stays {{projects.lines}} prose",
+          "check": "project board template has summary+active+next_work+footer only (no future, no recently_worked table); global template has summary+footer added; SKILL.md documents the new payload fields and CLI flags",
+          "observed": "templates carry {{summary}}, {{active.rows}} (Id|What|Stage), {{next_work.rows}} (Id|What|Value|Disposition|Flags), {{footer}}; {{future.rows}} and the recently-worked table are removed from both; SKILL.md Step 1/2 document summary/footer/active_total/active_shown/next_total/next_shown and --limit-active/--limit-next/--all/--plain",
           "result": "pass"
         }
       ]

package/skills/dashboard/templates/dashboard-global.md

@@ -1,10 +1,6 @@
 # 🧩 Plastic · Global Board, {{date}}
 
-**Recently worked** (last 24h)
-
-| Id | What | State | Scope |
-| --- | --- | --- | --- |
-{{recently_worked.rows}}
+{{summary}}
 
 ## Where we are
 
@@ -19,4 +15,6 @@
 | --- | --- | --- | --- | --- |
 {{next_work.rows}}
 
+{{footer}}
+
 **What would you like to work on next?** (type an **intent id**, a **project name**, or anything **new** you'd like to start)

package/skills/dashboard/templates/dashboard-project.md

@@ -1,31 +1,19 @@
 # 📦 {{slug}} · Project Board, {{date}}
 
-{{description}}
-
-**Recently worked** (last active work, last 24h)
-
-| Id | What | State |
-| --- | --- | --- |
-{{recently_worked.rows}}
-
-## Intents, active {{counts.active}}, done {{counts.done}}, future {{counts.future}}
+{{summary}}
 
 **Active**
 
-| Id | What | Stage |
-| --- | --- | --- |
+| Id | What | Stage | Worker | Activity |
+| --- | --- | --- | --- | --- |
 {{active.rows}}
 
-**Future**
-
-| Id | What |
-| --- | --- |
-{{future.rows}}
-
-## Most-valuable next work
+**Most-valuable next work**
 
 | Id | What | Value | Disposition | Flags |
 | --- | --- | --- | --- | --- |
 {{next_work.rows}}
 
+{{footer}}
+
 **What would you like to work on next?** (type an **intent id**, or **global** to go back)

package/skills/doctor/SKILL.md

@@ -106,6 +106,11 @@ If any checks have `fixable: true` AND status is not `pass`:
 
 If no fixable issues exist, skip this step.
 
+This "Fix all / Select individually / Skip" prompt IS the router the spec calls
+`doctor --fix-all` (intent 197): doctor itself never mutates anything (see Step 5's table and
+"Important Notes" below); "Fix all" means "dispatch every fixable finding to the maintenance
+tool or skill that owns that class of repair," one row per fix_hint pattern.
+
 ### Step 5: Apply fixes
 
 Use the `fix_hint` value to determine the correct action:
@@ -121,6 +126,7 @@ Use the `fix_hint` value to determine the correct action:
 | "Run: provision-project-store {slug}" | Run `provision-project-store <slug>` (or invoke the `plastic-store-provisioning` skill) to create the missing store |
 | "Re-run installer" | Run `npx -y @zalom/plastic@<channel> install --agent <agent>` (channel: -alpha->@alpha, -beta->@beta, else @latest) |
 | "Dispatch plastic-store-curating ... revisions.md ..." | Invoke the `plastic-store-curating` (or the agent) to relocate the flagged section or ref into the intent's `revisions.md` via move-and-record (one dated, `[rule: <tag>]`-tagged entry per item), per PLASTIC.md > Structural maintenance and revisions.md. For a missing required section, restore or reproject it instead. |
+| "Run scripts/project-links ... PRESERVES ... --drop-unbacked-links" | Run `ruby ~/.plastic/scripts/maintenance-run --tool project-links --intent <id> --apply` for the one flagged id (never run bare `project-links` against a real store outside the rare owner-approved batch exception, D2) |
 
 For fixes the agent cannot handle automatically, explain what the user needs
 to do manually. The `revisions.md` remedy is curator-applied (a move-and-record

package/skills/intent-locking/SKILL.md

@@ -19,23 +19,41 @@ Run from the project (the intent resolves from this session's bridge), or pass
 
 | Verb | What it does | When |
 |---|---|---|
+| `who` | Print a compact owner, heartbeat, claim, and delegate view from durable files only | Safe human inspection; requires `--intent-dir` |
 | `status` | Report the lock file, bridge cache, freshness, agreement | Always safe; run first |
 | `fix` | Idempotent repair: rebuild lock + bridge from disk truth for THIS session. Never touches a fresh foreign lock | Interrupted work, corrupted state, /tmp wiped, legacy pid locks |
 | `release` | Owner clears the lock | Ending or abandoning a boarding |
 | `reclaim` | Explicit takeover of a STALE lock; appends an audit line to savepoint.md | The owner is gone and the lease expired |
-| `delegate` | Owner registers a subagent session under the lock (`--delegate <session-id>`) | Auto-mode orchestration |
+| `delegate` | Owner registers a subagent session and optional provenance, or marks it `finished`/`failed` | Auto-mode orchestration |
 
 ```
 ruby ~/.plastic/scripts/plastic-lock status
+ruby ~/.plastic/scripts/plastic-lock who --intent-dir <store>/<id>--<slug>
 ruby ~/.plastic/scripts/plastic-lock fix --intent-dir <store>/<id>--<slug>
 ruby ~/.plastic/scripts/plastic-lock reclaim --intent-dir <store>/<id>--<slug>
-ruby ~/.plastic/scripts/plastic-lock delegate --delegate <subagent-session-id>
+ruby ~/.plastic/scripts/plastic-lock delegate --delegate <subagent-session-id> \
+  --harness codex --agent plastic-executor --model <model> --thread <thread-id>
+ruby ~/.plastic/scripts/plastic-lock delegate --delegate <subagent-session-id> --status finished
 ```
 
+When the current controller knows its provenance, `fix` and `reclaim` accept
+`--harness`, `--agent`, `--model`, `--thread`, and `--mode auto|guided`.
+Provenance is descriptive; the session remains the authorization identity.
+
 ## Rules
 
 - `fix` exits non-zero when another session holds a FRESH lock: back off, do
   not retry in a loop. `status` shows the owner.
+- `who` is strictly read-only. It reads `delivery.lock`, its mtime, and claim
+  files; it never reads or repairs a bridge, searches transcripts, heartbeats,
+  or writes. Missing legacy provenance displays as `Unknown` rather than being
+  inferred.
+- The `delivery.lock` file mtime is the sole heartbeat and freshness truth.
+  Provenance timestamps do not replace it.
+- Only the lock owner may register delegates or mark them `finished` or
+  `failed`. Terminal status is observational and does not remove the delegate
+  session from the authorization list. Finished and failed activity history is
+  bounded to the 20 most recent terminal entries.
 - `reclaim` refuses a fresh lock. There is no silent reclaim anywhere; every
   takeover is audited in the intent's savepoint.md.
 - Acquiring a lock for new work is NOT this skill's job: board through

package/skills/intent-starting/SKILL.md

@@ -47,10 +47,10 @@ enforces it: without a held lock, mutating writes to this active intent's dir ar
    ```bash
    # guided (lock only):
    ruby -r ~/.plastic/scripts/lib/bridge -e \
-     'Bridge.arm_guided(ENV["CLAUDE_CODE_SESSION_ID"], intent_id: "<ID>", intent_dir: "<STORE>/<dir>", store: "<STORE>", name: "<name>")'
+     'codex=ENV["CODEX_THREAD_ID"].to_s.strip; claude=ENV["CLAUDE_CODE_SESSION_ID"].to_s.strip; harness=!codex.empty? ? "codex" : (!claude.empty? ? "claude" : nil); session=!codex.empty? ? codex : (!claude.empty? ? claude : nil); Bridge.arm_guided(session, intent_id: "<ID>", intent_dir: "<STORE>/<dir>", store: "<STORE>", name: "<name>", harness: harness, agent: "plastic-enforcer", thread: (!codex.empty? ? codex : nil))'
    # auto (lock + auto), then hand to plastic-auto:
    ruby -r ~/.plastic/scripts/lib/bridge -e \
-     'Bridge.arm_auto(ENV["CLAUDE_CODE_SESSION_ID"], intent_id: "<ID>", intent_dir: "<STORE>/<dir>", store: "<STORE>", name: "<name>")'
+     'codex=ENV["CODEX_THREAD_ID"].to_s.strip; claude=ENV["CLAUDE_CODE_SESSION_ID"].to_s.strip; harness=!codex.empty? ? "codex" : (!claude.empty? ? "claude" : nil); session=!codex.empty? ? codex : (!claude.empty? ? claude : nil); Bridge.arm_auto(session, intent_id: "<ID>", intent_dir: "<STORE>/<dir>", store: "<STORE>", name: "<name>", harness: harness, agent: "plastic-enforcer", thread: (!codex.empty? ? codex : nil))'
    ```
    Replace `<ID>`, `<STORE>` (`~/.plastic/projects/<slug>/store` or `~/.plastic/store`),
    `<dir>` (the `ID--slug` directory), and `<name>`.
@@ -67,8 +67,10 @@ enforces it: without a held lock, mutating writes to this active intent's dir ar
    discovery yields nothing, proceed to Why normally.
 
 **Session id resolution (verbatim from `plastic-auto`).** The first argument is the session
-id the bridge is keyed by: pass the hook stdin `session_id` when you have it, otherwise
-`ENV["CLAUDE_CODE_SESSION_ID"]`, otherwise `nil`. Both arms call `resolve_session`, which
+id the bridge is keyed by: pass the hook stdin `session_id` when you have it; in the executable
+snippets, a nonblank `CODEX_THREAD_ID` identifies Codex, otherwise a nonblank
+`CLAUDE_CODE_SESSION_ID` identifies Claude, otherwise identity remains unknown. Never infer a
+harness from an absent variable. Both arms call `resolve_session`, which
 picks the first non-empty of: the explicit id you pass → `CLAUDE_CODE_SESSION_ID` → a
 deterministic derived key (a hash of the store and intent id). It never returns nil, so the
 lock is taken even when every session env var is empty; arming prints a one-line stderr

package/skills/project-continuing/SKILL.md

@@ -104,6 +104,16 @@ state and stops, asking nothing (unchanged): it does not itself dispatch, re-ran
 roadmap. The global store and any project with no roadmap report `none`, so this board stays the
 default route for them.
 
+Intent 202 has landed on top of 149/149a: the project board is short by default. The
+Recently-worked table and the raw Future table are both gone, replaced by a 2-3 sentence
+prose summary (built in `dashboard.rb`, not by this skill) plus a one-line footer stating
+true totals. Active is capped at 3 (ordered lifecycle-stage descending, a later savepoint
+breaking a tie - D2), Next-work at 5. Conversational paging ("more"/"all") re-invokes
+`dashboard.rb ... --data` with `--limit-active`/`--limit-next`/`--all`, carrying no state on
+disk; `--plain` prints the full uncapped board as plain text for a real pager. The rule-name
+citations and the `dashboard.rb project <slug> --data` -> `dashboard-project.md` path still
+resolve.
+
 ## References
 
 - `references/board-fill.md` - the template-fill mechanics and store-health surfacing detail.

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

@@ -71,11 +71,11 @@
     },
     {
       "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 intent 149a has landed (the four intent lists render as Markdown tables), and confirms the rule-name citations and the dashboard.rb project <slug> --data -> dashboard-project.md path still resolve.",
+      "prompt": "Does the skill carry the intent-202 coordination note (project board short by default)?",
+      "expected_output": "A 'Coordination' section records that intent 202 has landed: the Recently-worked and raw Future tables are gone, replaced by a prose summary (built in dashboard.rb) and an honest-totals footer; Active is capped at 3 (lifecycle-stage descending, D2) and Next-work at 5; conversational paging re-invokes dashboard.rb --data with --limit-active/--limit-next/--all (no state on disk); --plain prints the full uncapped plain-text board. 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' and 'Intent 149a has landed' (lists render as Markdown tables) with confirmed rule-name citations and dashboard.rb path", "result": "pass" }
+        { "type": "convention", "check": "'202' present with the landed coordination note describing the new shape, caps, paging flags, and --plain", "observed": "present: 'Intent 202 has landed' paragraph with the described content", "result": "pass" }
       ]
     },
     {

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

@@ -7,20 +7,22 @@ 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).
-- `{{<list>.rows}}` -> the four intent lists (`recently_worked`, `next_work`, `active`, `future`)
-  render as Markdown table rows. The template hard-codes each table's header and separator; the
-  placeholder becomes one data row per entry, in that table's fixed column order, cells dropped
-  verbatim from the payload (cells arrive pipe-escaped and whitespace-normalized; do not re-escape
-  or re-truncate). Column order per table:
-  - `recently_worked` -> `| id | what | state | scope |` (global), `| id | what | state |` (project)
+- `{{<list>.rows}}` -> the two intent lists (`active`, `next_work`) render as Markdown table
+  rows. The template hard-codes each table's header and separator; the placeholder becomes one
+  data row per entry, in that table's fixed column order, cells dropped verbatim from the
+  payload (cells arrive pipe-escaped and whitespace-normalized; do not re-escape or
+  re-truncate). Column order per table:
   - `next_work` -> `| id | what | value | disposition | flags_label |`
-  - `active` -> `| id | what | stage |`; `future` -> `| id | what |`
-  Overflow entry (empty `id`, `what` = `+N more`) -> `+N more` in the Id column, other cells blank.
+  - `active` -> `| id | what | stage |`
   Empty list -> one full-width row with `_(none)_` in the Id column, other cells blank, matching
-  that table's column count (e.g. `| _(none)_ | | | | |` for the 5-column next_work table,
-  `| _(none)_ | |` for the 2-column future table). Never emit `<br>`.
+  that table's column count. Neither list carries an overflow "+N more" row (intent 202): the
+  true pool size rides on the payload (`active_total`/`next_total`, shown as
+  `active_shown`/`next_shown`), stated in prose by `{{footer}}` instead. Never emit `<br>`.
 - `{{projects.lines}}` (global board) -> the project rollup stays prose, one line per project.
-- Scalars (`{{date}}`, `{{slug}}`, `{{description}}`) -> substitute verbatim.
+- Scalars (`{{date}}`, `{{slug}}`, `{{summary}}`, `{{footer}}`) -> substitute verbatim.
+  `summary` (the 2-3 sentence "what was delivered most recently") and `footer` (the
+  honest-totals + how-to-see-everything line) are finished prose built in `dashboard.rb`,
+  replacing the old recently-worked table and the raw future table respectively.
 
 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.

package/skills/releasing/SKILL.md

@@ -247,11 +247,11 @@ lock correctly (G5): before intent 188 this path left the lock stranded, exactly
 of bug closed by the End-tail enforcement work.
 
 This is the release branch of `plastic-intent-ending`'s Step 5 disarm (`merge: true`), not a
-separate concern: a release is the merge-then-remove path for the intent's worktrees (intent
+separate concern: a release is the merge-then-remove path for the intent's worktree (intent
 73c3), so the intent's code branch is merged back into the default branch BEFORE the worktree
 is removed. Drive it through `Worktree.finish` with `merge: true`, which merges the code
-branch, then removes both worktrees (code + paired store), prunes both repos, and clears the
-worktree block from the bridge:
+branch, then removes the worktree, prunes the repo, and clears the worktree block from the
+bridge:
 
 ```bash
 ruby -r ~/.plastic/scripts/lib/worktree -r ~/.plastic/scripts/lib/bridge -e \

package/skills/store-curating/SKILL.md

@@ -45,3 +45,12 @@ When an intent reaches a terminal state, moved to Completed OR Abandoned, do the
 2. Call `plastic-intent-ending` for the terminal-transition close (INDEX move, savepoint `Done` bookend, store commit, disarm, and the QMD reindex last): `ruby ~/.plastic/scripts/end-intent --store <store> --id <id> --disposition delivered|abandoned`, then follow that skill's own disarm and reindex steps. Never restate those one-liners here.
 
 After the agent completes, report what changed.
+
+## Maintenance dispatch (intent 197)
+
+When invoked to fix a structural finding on an intent OTHER than one currently being delivered
+(for example, from `/plastic-doctor`'s fix-all routing), the `plastic-intent-curator` agent
+follows its own step 7: it detects (never acquires) the target's delivery lock, requires a
+clean working tree, and performs the fix on a fresh branch merged back to main as one closed
+operation, with an append-only `revisions.md` receipt in the same pass as the edit. See
+`agents/plastic-intent-curator.md` for the exact mechanics.

package/skills/store-curating/evals/evals.json

@@ -17,6 +17,22 @@
           "result": "pass"
         }
       ]
+    },
+    {
+      "id": 2,
+      "scope": "behavior",
+      "set": "validation",
+      "prompt": "The user says: intent 26 (Completed) has a stale ## Links comment that contradicts its own real chain edge; fix it. Intent 26 is NOT the intent currently being delivered by this session.",
+      "expected_output": "Before editing intent 26, checks its delivery lock freshness (plastic-lock status --intent-dir, reading lock_fresh) and defers if fresh; requires a clean store working tree; creates a fresh maintenance branch off main; makes the scoped edit AND appends a revisions.md receipt in the same pass, refusing the edit if the receipt cannot be written; stages only the changed paths (never git add -A); merges the branch back to main and deletes it before reporting done.",
+      "files": [],
+      "assertions": [
+        {
+          "type": "human",
+          "check": "agent file states detect-only lock check, clean-tree precheck, branch-and-merge-back, and refuse-without-receipt as an unconditional sequence for maintenance on a non-current intent",
+          "observed": "agents/plastic-intent-curator.md step 7 covers all five sub-steps (a-f) exactly as asked",
+          "result": "pass"
+        }
+      ]
     }
   ]
 }

package/skills/tutorial/SKILL.md

@@ -59,7 +59,7 @@ remember where they left off.
 
 ## Before any track
 
-Every track opens with the same two checks: run `/plastic-update` first, so the walkthrough
-matches what is actually installed, and work in a sandbox (a throwaway repo, or a global-store
-intent) so nothing real is touched by mistake. Each reference restates this briefly; do not
-skip it even if the user seems experienced.
+Every track opens with the same two checks: run `/plastic-update` first (`$plastic-update` on
+Codex), so the walkthrough matches what is actually installed, and work in a sandbox (a
+throwaway repo, or a global-store intent) so nothing real is touched by mistake. Each reference
+restates this briefly; do not skip it even if the user seems experienced.

package/skills/tutorial/references/track-1-guided.md

@@ -9,7 +9,8 @@ end to end: a piece of work moved through What, Why, How, and Exec, with a finis
 
 ## Before you start
 
-Run `/plastic-update` first, so the commands below match what is actually installed.
+Run `/plastic-update` first (`$plastic-update` on Codex), so the commands below match what is
+actually installed.
 
 Work in a sandbox: this track always creates a global-store intent; the throwaway repo below
 is never registered as a Plastic project. Pick a throwaway git repository if you have one

package/skills/tutorial/references/track-2-auto.md

@@ -9,7 +9,8 @@ agent end to end, and pausing and resuming that delivery will feel familiar.
 
 ## Before you start
 
-Run `/plastic-update` first, so the commands below match what is actually installed.
+Run `/plastic-update` first (`$plastic-update` on Codex), so the commands below match what is
+actually installed.
 
 Work in a sandbox: a throwaway git repository, or a global-store intent. Nothing in this
 track touches a real project.

package/skills/tutorial/references/track-3-projects-and-roadmaps.md

@@ -9,7 +9,8 @@ will exist with more than one intent inside it and a roadmap file describing the
 
 ## Before you start
 
-Run `/plastic-update` first, so the commands below match what is actually installed.
+Run `/plastic-update` first (`$plastic-update` on Codex), so the commands below match what is
+actually installed.
 
 Work in a sandbox: this whole track is a walked example. It creates a real project directory
 and a real roadmap file on disk, but the project is a throwaway one made for learning, not