@zalom/plastic 2.0.0-alpha.2 → 2.0.0-alpha.21

package/scripts/validate-work-graph

@@ -0,0 +1,39 @@
+#!/usr/bin/env ruby
+# encoding: UTF-8
+# frozen_string_literal: true
+
+# validate-work-graph - deterministic CLI over WorkGraphValidator (intent 334, n4).
+#
+# Checks whether one intent directory's graph.md and nodes/ form a valid work
+# graph: needs targets resolve, node files reconcile with the declared graph,
+# per-kind body sections are present, and (above the trivial bar) a verify
+# node gates two or more work nodes with a failure-mode matrix per work node.
+# Modelled on scripts/validate-intent: errors to stderr, same exit-code shape.
+#
+# Usage:
+#   validate-work-graph <intent_dir>
+#
+# Exit codes: 0 (valid), 1 (invalid or unreadable; report on stderr),
+# 2 (usage - no argument given).
+
+require_relative "lib/work_graph_validator"
+
+intent_dir = ARGV.find { |a| !a.start_with?("--") }
+
+if intent_dir.nil?
+  warn "usage: validate-work-graph <intent_dir>"
+  exit 2
+end
+
+dir = File.expand_path(intent_dir)
+result = WorkGraphValidator.validate(dir)
+
+if result[:ok]
+  puts "OK: #{dir}"
+  exit 0
+end
+
+warn "INVALID: #{dir}"
+result[:missing].each { |m| warn "missing: #{m}" }
+result[:errors].each { |e| warn e }
+exit 1

package/scripts/verify-intent

@@ -15,7 +15,8 @@
 # other flags exist.
 #
 # Checks, all run every invocation (the fourth only when --suite is given):
-#   1. doctor    - Doctor#run_intent_check(id, store: scope), fail-open on a crash
+#   1. doctor    - Doctor#run_intent_check(id, store: scope), fail-open on a crash; the doctor
+#                  scan includes the intent_ticks_lag warning (intent 329)
 #   2. em-dash   - added lines only of `git diff <base>...HEAD`, never the whole tree
 #   3. diffstat  - `git diff --stat <base>...HEAD`, never a failure on its own
 #   4. suite     - the supplied --suite command, run with RUBYOPT cleared

package/skills/auto/SKILL.md

@@ -13,20 +13,18 @@ user-invocable: true
 Announce: "Taking over intent [ID] - [name] for autonomous delivery."
 
 **Advisory (not a rule).** At auto-mode start, recommend once that the user run this
-orchestrating main session on the best available thinking model (Fable, Opus, or whatever
-supersedes them). This is advice only: it changes no behavior. Dispatched agents keep their
-configured model and never resolve to Fable unless an explicit `agents.models.<name>` config
-override names Fable for that role. The two advisors, `plastic-advisor` and
-`plastic-faux-advisor`, are consultation roles the user or the main session summons
-deliberately; the auto pipeline never dispatches them.
+orchestrating session on the best available thinking model (Fable, Opus, or whatever supersedes
+them); this is advice only, and dispatched agents keep their configured model, never resolving
+to Fable without an explicit `agents.models.<name>` config override. `plastic-advisor` and
+`plastic-faux-advisor` are consultation roles the user or this session summons deliberately;
+the auto pipeline never dispatches them.
 
 ## Precondition
 
 An active intent MUST exist in INDEX.md. If none exists, refuse: "No active intent found.
 Create one first with /plastic-intent-creating."
 
-If several active intents exist, ask the user which one to deliver (the one question auto asks
-at boarding, before delivery starts).
+If several active intents exist, ask which to deliver (the one question auto asks at boarding).
 
 **Picking work when no intent is specified.** If the user says "auto" without naming an intent
 and none is active, consult the roadmap first (the primary planning surface), then fall back to
@@ -42,9 +40,8 @@ frontier batch is still delivering, report it and wait, never dispatch a later b
 `exhausted` means fall back to `ruby ~/.plastic/scripts/dashboard.rb all --json` and work its
 `dispatchable_queue` in `rank` order, leaving `human_only` and `next_big_thing` for the user.
 
-QMD-first (when available): when the user describes the work rather than naming an intent, run
-`ruby ~/.plastic/scripts/qmd-sync search "<terms>"` before scanning the store, then open the
-authoritative intent file for the hit you take over. The command is a no-op when QMD is absent.
+QMD-first (when available): when the user describes the work instead of naming an intent, run
+`ruby ~/.plastic/scripts/qmd-sync search "<terms>"` first, then open the hit's authoritative intent file; a no-op when QMD is absent.
 
 ## Take the intent (do this FIRST)
 
@@ -67,8 +64,9 @@ Replace `<STORE>` (`~/.plastic/projects/<slug>/store` or `~/.plastic/store`) and
 nonblank `CLAUDE_CODE_SESSION_ID` as Claude, otherwise passes no identity and the verb keys the
 lock by a derived session key. Never guess identity from an absent runtime variable; an
 unknown harness or thread stays unknown. Exit 1 means the lock is held, stale, excluded, or
-corrupt; the message names the `plastic-doctor` verb that resolves it. Do not proceed as the
-owner after an exit 1.
+corrupt - or `inline_refused`: a conversation session may not arm an intent at all (owner rule
+2026-08-31); dispatch the delivery team instead. `--allow-inline` exists only for an explicit
+owner override. Do not proceed as the owner after an exit 1.
 
 Read `../plastic-conventions/references/locks-and-worktrees.md` for what the lock and the
 worktree mean and the station table behind them. Code edits happen only inside the worktree.
@@ -89,6 +87,12 @@ tier and no stage agent; depth follows the work.
 Two boots is the normal delivery; the third is the exception the risk rule names. The lead is
 this session (the `plastic-enforcer` role), never a dispatched agent.
 
+A lead is a choice, not a requirement (D8, 355). `runner step` computes the plan and prints a
+spawn block per node - agent, model, packet path, the test command, the call cap - fenced for a
+session to paste into the Agent tool; the runner never spawns (327 D42). A lead earns its keep
+on a graph carrying a decision node, weighing its `needs_decision` stop; a graph with none runs
+end to end from `runner step` alone.
+
 ## Team
 
 - **plastic-enforcer**: this session. Writes the Why and How record, dispatches, folds reviews,
@@ -147,13 +151,10 @@ each one as a delegate before (or when) it needs to write into the intent dir:
 
 Only the owner can delegate. Delegates cannot re-delegate or release.
 
-Headless note: in a headless or background run the session id may be unset; the arm verb then
-keys the lock by a derived key and the record hook still writes the savepoint ledger from the
-written path. Verify the lock with `plastic-lock status` rather than assuming.
+Headless note: in a headless or background run the session id may be unset; the arm verb then keys the lock by a derived key and the record hook still writes the ledger.
+Verify with `plastic-lock status` rather than assuming.
 
-Solo fallback: on a harness with no agent dispatch (Codex CLI today), this session walks the
-five steps itself: it still writes the matrix, still writes the tests first, and reviews its own
-plan against the matrix before code, saying so in `## Insights`.
+Solo fallback: on a harness with no agent dispatch (Codex CLI today), this session walks the five steps itself, still writing the matrix and the tests first and reviewing its own plan against the matrix before code, saying so in `## Insights`.
 
 ## Stage-Aware Entry
 
@@ -168,6 +169,7 @@ ledger is missing (then rebuild it with `Savepoint.rebuild_savepoint`).
 | `How  plan.md created` / `How  checklist.md created` / `Exec  started` | Exec (verify plan, matrix, checklist) |
 | `Exec  outcome.md created` | Exec done; complete the intent |
 | `Done  delivered|abandoned` | Terminal; do not resume |
+| A node or `Intent` transition line (`n1  running ...`, `Intent  needs_decision ...`) | Exec; a graph delivery is in progress - drive it through `scripts/runner`'s three public verbs, `step` (one turn of the dispatch loop), `status` (renders ledger state, safe to poll constantly), and `answer` (closes a `needs_decision` node) - read node status through `NodeLedger.status` before dispatching anything, never re-derive it by eye |
 
 Filesystem fallback, in order: `checklist.md` with items checked means resume Exec from the
 first unchecked item; `plan.md` plus `checklist.md` means enter Exec; `spec.md` alone means
@@ -183,9 +185,7 @@ Announce which stage you are entering and why.
 3. Decide: pick the best option per gap, record it in `## Context > ### Decisions` with the
    rationale, and log it in `## Insights` with the `(autonomous)` marker through
    `scripts/insight-append`.
-4. Write `spec.md`.
-
-Then How.
+4. Write `spec.md`. Then How.
 
 ## How (the lead), then the plan review
 
@@ -200,9 +200,9 @@ Then How.
    into the spec, the matrix, and the tests; record what was dropped and why in the action
    file's review fold. A REVISE verdict is folded and not re-reviewed unless a finding changes
    a decision.
-5. Notify the user (the one mid-flight briefing, per `references/human-report-contract.md`):
-   State, the plan shape and what it builds; Risk, the riskiest row of the matrix; Call,
-   proceeding to build. In auto mode this briefing informs; it does not wait.
+5. Print `ruby ~/.plastic/scripts/report-screen plan <intent_dir>` as the first characters of
+   the reply, nothing before it, no fence, before dispatching the executor (see
+   `references/human-report-contract.md` for the full binding table). It informs; it does not wait.
 
 Then Exec.
 
@@ -214,7 +214,7 @@ Then Exec.
    then builds, then drives the full suite green.
 2. Read its return by code: DONE or DONE_WITH_CONCERNS proceeds; NEEDS_CONTEXT re-dispatches
    with the missing context; BLOCKED stops under the error procedure.
-3. Tick the checklist as items land (the executor does this; verify it).
+3. Tick the checklist as items land (the executor does this); verify tick-versus-diff against the diff. A mismatch is a review finding, not a lead cleanup.
 
 ## Review by risk (boot 3, only when a rule fires)
 
@@ -251,8 +251,9 @@ every choice is non-destructive and the team has full autonomy.
 
 Read `../plastic-conventions/references/completion-and-done.md` for what "intent done" means.
 
-1. Verify every checklist item is checked and the suite is green once on the branch.
-2. Write `outcome.md` from `~/.plastic/templates/outcome.md` with `disposition: delivered`.
+1. This is the merge gate: verify every checklist item is checked, verify tick-versus-diff against the diff, and confirm the suite is green once on the branch.
+2. Write `outcome.md` from `~/.plastic/templates/outcome.md` with `disposition: delivered`,
+   `## Delivered` as the labeled table whose row labels match the action-file headings (317a).
 3. Release, if configured: match the working directory against `~/.plastic/projects.yml`, read
    `project.yml`'s `release` block, and act on `on_complete` (`commit`, `commit_and_push`,
    `manual`), `verify` (green proceeds; red follows `on_red`: `fix_and_retry` up to twice,
@@ -268,10 +269,16 @@ Read `../plastic-conventions/references/completion-and-done.md` for what "intent
      --session "$CLAUDE_CODE_SESSION_ID" \
      --index-note "<what shipped>; <suite result>"
    ```
-   Exit 4 means a live foreign session holds the lock; 5 means the worktree is dirty (commit
-   first, or pass `--discard-worktree-changes` deliberately); 3 means the lock survived the
-   disarm (`/plastic-doctor check the lock status`); 6 means the structure check refused. Never
-   leave an orphaned worktree; run `git worktree prune` on a stale reference.
+   Exit 4: a live foreign session holds the lock. 5: the worktree is dirty (commit first, or
+   pass `--discard-worktree-changes` deliberately). 3: the lock survived the disarm
+   (`/plastic-doctor check the lock status`). 6: the structure check refused. Never leave an
+   orphaned worktree; run `git worktree prune` on a stale reference.
+6. Print `ruby ~/.plastic/scripts/report-screen delivered <intent_dir>` once (D15/331f), and
+   `report-screen state` at each of the five triggers in `references/human-report-contract.md`
+   (a review verdict, a blocker, a merge/release, or an owner status ask; a mid-batch ask
+   instead runs `report-screen session <tier_root> --session "$CLAUDE_CODE_SESSION_ID"`, intent
+   330). Print each as the first characters of the reply: nothing before it, no fence, or the
+   hook cannot paint it.
 
 ## Error Handling
 
@@ -284,8 +291,8 @@ leaves the project broken.
 
 - Read `references/agent-architecture.md` for the team model, the risk list, the headless note,
   and the solo fallback when dispatching or when a harness has no agent dispatch.
-- Read `references/human-report-contract.md` for the State/Risk/Call briefing before sending the
-  How briefing.
+- Read `references/human-report-contract.md` for the three report screens and the five
+  triggers before printing the How or Completion screen above.
 - Read `references/agent-report-contract.md` for the completion report format when reading a
   dispatched agent's return or synthesizing one.
 - Read `references/end-tail.md` for what `Arm.disarm` does at the End tail and why the reindex

package/skills/auto/references/human-report-contract.md

@@ -1,72 +1,154 @@
-# Human Report Contract (per-stage EM-to-CTO briefing)
-
-This doc defines how the orchestrator briefs the human at each of the five stage boundaries
-(What, Why, How, Exec, Done) in auto mode; for small work only the How boundary fires (see
-`## Depth for small work`). It is the outward, human-facing counterpart to the
-internal report contract in `references/agent-report-contract.md`. Voice: an engineering
-manager briefing a CTO. Lead with impact, name the risk, leave the decision.
-
-## The skeleton
-
-One fixed 3-line shape, reused at every stage:
-
-1. **State**: what happened and what it means, impact first, one line.
-2. **Risk**: the one thing that could bite, or "nothing flagged."
-3. **Call**: the decision left to you, or the go-ahead I am taking.
-
-This is a shape, not a rigid template. Keep the order (State, then Risk, then Call) and keep it
-short. The words can flex to fit the stage.
-
-## Per-stage content
-
-- **What**: State = the work I picked up and why it matters now. Risk = scope uncertainty.
-  Call = confirm this is worth doing, or I proceed.
-- **Why**: State = the approach I chose, one line. Risk = the main trade-off. Call = the one
-  decision I need (approve, or pick an option).
-- **How**: State = the plan shape (task count and what it builds). Risk = the riskiest task or
-  dependency. Call = approve the plan to build.
-- **Exec**: State = what got built and the test result. Risk = residual failures or deviations.
-  Call = go to review, or done.
-- **Done**: State = the delivered impact. Risk = residual risk. Call = the decision left to you
-  (merge, release, accept).
+# Human Report Contract (the report screens, intent 317)
+
+D15: the prose EM-to-CTO briefing this doc used to define is retired. The orchestrator now
+prints one of these report screens, filled from the record by `scripts/report-screen`, never
+written by eye:
+
+- **`report-screen plan <intent_dir>`** - the pre-delivery report (intent 331b), printed once
+  at the How boundary, before the executor is dispatched: Asked, Decisions, Steps, Mode,
+  Reviewer, then the Steps table (Step, Action, What) and the Risks table.
+- **`report-screen state <intent_dir> [--changed "<text>"]`** - the mid-delivery report. One
+  intent's field table (Store, Status, Stage, Savepoint, Progress, Next, Insight) plus a
+  `Changed` row naming what caused the print, and its Steps table.
+- **`report-screen state --all <store_root>`** - the roster across every in-delivery intent,
+  most recently changed first, then one collapsed block (Stage, Next, Changed, first three
+  open steps) per intent.
+- **`report-screen delivered <intent_dir>`** - the post-delivery report, printed once at close:
+  Asked, Delivered (with a Proven-by column), Evidence, Needs you.
+- **`report-screen delay <intent_dir>`** - printed only on request ("why did X take so long"):
+  the delivery as a timeline plus the derived `Where the time went` line.
+- **`report-screen session <tier_root>`** - the answer to an UNNAMED status ask ("where are we
+  with delivery", "what is the status"): one `delivered` screen per intent this session
+  completed, oldest first, then the `state --all` roster. Intent 330's ruling: a status ask
+  answers with what actually shipped, not the in-flight roster alone.
+- **`dashboard.rb continue|project <slug> --screen`** - the dashboard screen (intent 331d):
+  Active, In delivery, Delivered, Roadmap, Sessions, Changed, then the Where-we-are and
+  Where-we-go-next tables. A separate script from the other four (`dashboard.rb`, not
+  `report-screen`), since it aggregates across a whole store or project rather than one
+  intent; it prints on `continue` and on loading a project, not as a delivery trigger.
+
+## Binding table (intent 331f)
+
+Every skill that shows state names its own report verb, one row per skill and trigger. Each
+bound skill's file carries the SAME rule next to its verb: print the screen as the first
+characters of the reply, nothing before it, no fence, or the hook cannot paint it.
+
+| Skill | Trigger | Verb |
+|---|---|---|
+| `plastic-intent-continuing` | project route (continue, load project) | `dashboard.rb ... --screen` |
+| `plastic-intent-continuing` | a named intent | `report-screen state` |
+| `plastic-intent-continuing` | "where are we" (a status ask) | `report-screen session` |
+| `plastic-intent-continuing` | "why so long" | `report-screen delay` |
+| `plastic-intent-continuing` | a roadmap route | `report-screen roadmap ... state` |
+| `plastic-auto` | the How boundary, before the executor | `report-screen plan` |
+| `plastic-auto` | each of the five triggers | `report-screen state` |
+| `plastic-auto` | close | `report-screen delivered` |
+| `plastic-intent-ending` | the close | `report-screen delivered` |
+| `plastic-intent-speccing` | the action files are written | `report-screen plan` |
+| `plastic-roadmap` | create | `report-screen roadmap ... plan` |
+| `plastic-roadmap` | read | `report-screen roadmap ... state` |
+| `plastic-roadmap` | close | `report-screen roadmap ... delivered` |
+| `plastic-dashboard` | any invocation | `dashboard.rb ... --screen` |
+| `plastic-intent-executing` | after the red commit, and after the suite | `report-screen state` |
+
+## A roadmap's own three reports (intent 331c)
+
+A roadmap gets the same pre-, in-, and post-delivery shape as an intent, through
+`report-screen roadmap <roadmap.md> plan|state|delivered [--ansi] [--store-root <dir>]`:
+
+- **`roadmap plan`** - the pre-delivery report: the Goal's first sentence, the batch (or legacy
+  wave) count and intent count, the batch order, and when the roadmap was created; then the
+  full entries table.
+- **`roadmap state`** - the in-delivery report: Goal, a Progress bar over intents delivered of
+  intents total (never batches), the frontier batch, who is delivering it and their lead, the
+  next queued entry, and the last ledger event; then the entries table with each entry's own
+  checklist progress and lead.
+- **`roadmap delivered`** - the post-delivery report: a meta line (closed time, or `in progress`
+  when the goal is not yet reached; intent count; duration) directly under the title, the
+  delivered table with each entry's merge sha, and the `## Log` table.
+
+Every cell traces to the roadmap file, `INDEX.md` (which always wins on status), the roadmap's
+own savepoint ledger, or (falling back when no ledger file exists) the roadmap's `## Log` -
+never a second parser: `RoadmapQueue`'s own public `roadmap` reader supplies every entry.
+
+## The five triggers for `state`
+
+Print `state` (one intent, or `--all` for the roster) on any of these; a checklist tick alone,
+an executor's intermediate commit, or an agent going idle is NOT one of them:
+
+| Trigger | Scope |
+|---|---|
+| A savepoint line lands (a stage boundary: Why, How, Exec started, outcome written, Done) | that intent |
+| A review verdict returns (plan review or post-execution review), naming what it changed | that intent |
+| A blocker or needs-input is logged | that intent |
+| A merge or a release lands | that intent |
+| The owner asks ("where are we", "state of X", "continue X") | all in delivery, or the one named |
+
+`delivered` prints exactly once, at Completion. `delay` prints only when the owner asks why a
+delivery took long.
+
+Every verb prints the same plain Markdown on every harness (owner ruling 2026-08-31); where a
+harness can paint it (Claude Code, through 316a's message-display hook), it substitutes a
+painted rendering of that same output, never a different one, and no skill or script branches
+on harness name to decide.
 
 ## Depth for small work
 
-For small work in auto mode the mid-flight briefings collapse to one. Only the How briefing fires, and
-it folds in what the What and Why briefings would have said: the work picked up and the approach
-chosen go into its State line. The Exec briefing folds into the final owner report at End. Larger
-work sends all four. The shape does not change: still State, then Risk, then Call, and the per-stage
-content above still says what each line covers. This is a depth cut, not a new report. A delivery
-still ends with `outcome.md` plus one owner report.
+For small work in auto mode, only the How-boundary `plan` screen prints mid-flight (intent
+331f moved this print off `state`, since there is no separate briefing per stage any more).
+Larger work prints `state` at every trigger in the table above. This is a
+depth cut, not a different report: the screen's shape never changes, only how often it fires.
+A delivery still ends with `outcome.md` plus one `delivered` screen.
 
 ## One report per audience
 
-A delivery produces exactly two artifacts: `outcome.md` (authored by `plastic-intent-ending`)
-and one EM-to-CTO owner report at the End stage. No stage or skill restates a delivery
-already written to `outcome.md`; point at it instead. Skills do not open with a banner that
-names the skill or restates the intent id and name the owner just typed. Announce only what
-the reader cannot already know: an error, a result, a choice with its reason, or a handoff.
+A delivery produces exactly two artifacts: `outcome.md` (generated by `scripts/end-intent`
+from `graph.md`, `nodes/`, and the ledger when the intent has one, intent 339; hand-authored
+by `plastic-intent-ending` otherwise) and one `delivered` screen at the End stage. No stage or skill restates a delivery already
+written to `outcome.md`; point at it instead. Skills do not open with a banner that names the
+skill or restates the intent id and name the owner just typed. Announce only what the reader
+cannot already know: an error, a result, a choice with its reason, or a handoff.
 
 ## Boundary vs intent 74
 
 Intent 74's report contract (`references/agent-report-contract.md`) is the INTERNAL,
 machine-checked handoff from a dispatched specialist back to the orchestrator: a structured
-envelope plus a per-role payload. This contract is the OUTWARD human briefing, orchestrator to
-user, in prose. Different direction, different audience, different form. The orchestrator
-CONSUMES the intent 74 report to WRITE the human briefing defined here. The two never merge.
+envelope plus a per-role payload. This contract is the OUTWARD screen shown to the owner.
+Different direction, different audience, different form. The orchestrator reads the intent 74
+report and reflects it into the record (savepoint, outcome.md) that `report-screen` then
+renders. The two never merge.
 
 ## Brevity: point, don't repeat
 
-Surface rules are owned by the `writing-style` skill. This contract does not restate them, in full
-or in summary. It defines the report's shape only: what to say, in what order, and when to stop.
-Apply the `writing-style` skill for the wording.
+Surface rules are owned by the `writing-style` skill. This contract does not restate them. Its
+job is naming which screen prints when, not the wording inside it - `report-screen` derives
+every cell from the record (D14), so there is no prose left to style here.
 
 ## Emission: guided vs auto
 
-In guided mode, the briefing lands at each stage boundary and the human acts on the Call line
-before the next stage starts.
+In guided mode, `state` prints at each stage boundary and the human decides before the next
+stage starts.
+
+In auto mode, `state` prints at every trigger for larger work; for small work only the How
+boundary's `plan` screen prints (see `## Depth for small work` above). The orchestrator takes
+the go-ahead itself and moves on, except at the existing hard stops (destructive action without
+a safe alternative, project-path confirm).
+
+## Column vocabulary (D5, intent 331f)
+
+Owner ruling 2026-09-05 11:05 UTC: "What" is never a column name, because What is a stage, not
+a value. The id column reads `Graph ID`; the title column reads `Intent`. Every Steps table
+reads `Step | Status | Detail` (the plan screen's own Steps table reads
+`Step | Action | Detail`); every Risks table reads `N | Risk`; the Delivered/Evidence/Needs-you
+tables on the `delivered` screen read `Row | Detail | Proven by`, `Kind | Detail | Source`, and
+`N | Need | Reason`. The plan screen's Asked row prints the intent title before its first
+colon, never the whole intent line. This applies to every screen the family prints: `state`,
+`roster`, `session`, `delivered`, `delay`, `plan`, `roadmap` (`plan`/`state`/`delivered`), and
+`dashboard`. `outcome.md`'s own `| Row | What |` heading is an AUTHORING convention inside the
+file a human writes, never a rendered header, and stays unchanged.
+
+## Width bound (D7, intent 331f)
 
-In auto mode, for larger work the orchestrator still emits the briefing at each boundary, as a
-running EM-to-CTO account. For small work only the How briefing fires; see `## Depth for small work` above for what it
-folds in. The Call line becomes the go-ahead the orchestrator takes itself and moves on, except at
-the existing hard stops (destructive action without a safe alternative, project-path confirm).
+No rendered row passes 115 visible columns. A long cell (the roadmap Goal, an intent title, an
+Asked line) truncates on a word boundary with a single ellipsis; `ReportScreen.fit_screen`
+shrinks a table's widest column first, floor 8, before it ever truncates a whole row.

package/skills/conventions/references/locks-and-worktrees.md

@@ -103,3 +103,15 @@ what gets written down.
 | Exec | code on the intent branch, checklist checked off | heartbeat; code edits confined to the provisioned worktree; delegates write under the owner's lock | checklist boxes; savepoint milestones; the day-ledger line promotes when a project file lands |
 | End (done) | mandatory `outcome.md` (`disposition: delivered\|abandoned`), INDEX moves to Completed or Abandoned | ordered End tail: verify, merge and remove worktrees, disarm clears `delivery.lock`, then the pointer is purge-eligible, and the QMD reindex runs LAST (after purge); `end-intent` backfills a placeholder `outcome.md` from the record and its structure check reports (never refuses) | savepoint `Done delivered` (or `abandoned`); takeover audits, if any, remain in savepoint.md |
 | Maintenance (Future, Terminal, or Active-with-a-stale-or-no-lock) | `revisions.md` move-and-record entries | detects (never acquires) `delivery.lock`; defers and reports while the target's lock is FRESH (`Lock.fresh?`); a stale or absent lock is not-active, maintenance proceeds | append-only, rule-tagged `revisions.md` entry written in the same operation as the change, or the change is refused; lands via a fresh branch off store main merged back as one closed op, never `git add -A` |
+
+## The write guard is not residue
+
+`<type>.write.lock` (usually `delivery.write.lock`) is a deliberate sibling
+inode used only for `flock`: no owner, no timestamp, no content, and it is
+NEVER unlinked - deleting it while a writer holds the flock hands the next
+writer a fresh inode at the same path, so two writers hold "the" guard at
+once (see `scripts/lib/lock.rb`, the write-guard comment). A zero-byte
+`*.write.lock` in a completed intent directory is by design; no cleaner may
+sweep it, and it is already inside the store's `*.lock` gitignore rule.
+(Intent 317a, A2: a review misread it as stale residue and nearly shipped
+the sweep.)

package/skills/dashboard/SKILL.md

@@ -7,7 +7,8 @@ user-invocable: false
 # Dashboard — Plastic Work Cockpit
 
 A deterministic overview of the intent store(s). It answers three questions at a glance:
-**where we are** (recently worked), **where we go next** (the most-valuable next work), and
+**where we are** (recently worked; `Graph ID | Intent | Stage | Progress | Lead`),
+**where we go next** (the most-valuable next work; `Rank | Graph ID | Intent | Reason`), and
 **how to conduct it** (a disposition per intent). The human-facing surface is **Markdown**,
 because the user's UI renders Markdown natively but collapses raw tool-call stdout.
 
@@ -22,6 +23,16 @@ state → byte-identical payload, regardless of model. Do NOT hand-summarize int
 - `plastic-intent-continuing` lands on the board on a bare resume
 - `plastic-auto` reads `--json` to choose the next dispatchable intent
 
+## The screen surface (intent 331d/331f)
+
+`dashboard.rb project <slug> --screen` (or `continue --screen` for the global board) is the
+default surface on every invocation: print it as the first characters of the reply, nothing
+before it, no fence, or the hook cannot paint it. It carries a title, six fields (Active, In
+delivery, Delivered, Roadmap, Sessions, Changed), then the Where-we-are and Where-we-go-next
+tables, its own grammar and painted form standing in for the filled Markdown template below.
+`plastic-intent-continuing`'s project route prints it this way. The Markdown board (Step 1-4
+below) stays available as the deeper prose surface a reader can ask for.
+
 ## Procedure (the Markdown board — default human surface)
 
 ### Step 1 — Get the data payload
@@ -70,7 +81,7 @@ Fill mechanically, no rewriting, no re-sorting:
   re-truncate, or reword them. Never emit `<br>`.
   - `next_work` → `| {id} | {what} | {value} | {disposition} | {flags_label} |`
   - `active` → `| {id} | {what} | {stage} | {worker} | {activity} |`
-  Empty list → one full-width row with `_(none)_` in the Id column and every other cell blank,
+  Empty list → one full-width row with `_(none)_` in the Graph 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

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

@@ -11,7 +11,7 @@
 
 ## Most-valuable next work
 
-| Id | What | Value | Disposition | Flags |
+| Graph ID | Intent | Value | Disposition | Flags |
 | --- | --- | --- | --- | --- |
 {{next_work.rows}}
 

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

@@ -4,13 +4,13 @@
 
 **Active**
 
-| Id | What | Stage | Worker | Activity |
+| Graph ID | Intent | Stage | Worker | Activity |
 | --- | --- | --- | --- | --- |
 {{active.rows}}
 
 **Most-valuable next work**
 
-| Id | What | Value | Disposition | Flags |
+| Graph ID | Intent | Value | Disposition | Flags |
 | --- | --- | --- | --- | --- |
 {{next_work.rows}}
 

package/skills/doctor/SKILL.md

@@ -78,10 +78,15 @@ project alone.
 Runs the install-wide surface: agent registration, core files (including config-honoring
 drift), manifest sync is core-only and not part of this run, deprecation checks, config-ask
 checks, install-integrity checks, skill-lint (advisory), QMD reachability (unscoped, every
-collection), and the global store's own conventions/done-signals content. **Never carries a
-per-project finding**; that is `--store <slug>`'s job (see above). This is what
-`/plastic-doctor` invokes, and it also runs automatically after every `plastic-update`
-(informational, does not block or revert the update).
+collection), the global store's own conventions/done-signals content, and the `display`
+category (intent 331e): `display_hook_registered` (also runs at `--core`), `display_hook_paints`
+(replays the shipped display fixture through the installed MessageDisplay hook and expects a
+painted screen back, a pass when a known defeater like `NO_COLOR` is active, never a fail),
+`display_not_defeated` (warns per active defeater and always names the undetectable verbose
+transcript view), and `display_surfaces_documented` (the harness-adapters doc still names every
+surface class). **Never carries a per-project finding**; that is `--store <slug>`'s job (see
+above). This is what `/plastic-doctor` invokes, and it also runs automatically after every
+`plastic-update` (informational, does not block or revert the update).
 
 ## When to Use
 
@@ -167,6 +172,7 @@ Use the `fix_hint` value to determine the correct action:
 | "Remove each listed .tmp/<session>/ directory after confirming that session is gone" | For each listed directory, confirm no live session uses it (a live session rewrites its heartbeat on every prompt and edit), then remove that directory by hand; never remove an unlisted one |
 | "For a day directory missing its <day>.md, run `file-session-intent --day <day> ...`" | Run `ruby ~/.plastic/scripts/file-session-intent --day <day> --carry-to <today> --store <store>` for the named day; rename or remove an entry that is not a `YYYYMMDD` day directory |
 | "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) |
+| "Re-run the Plastic installer to repair the hook registration ... (plastic-install --repair)" (`display_hook_registered`) | Run `npx -y @zalom/plastic@<channel> install --reinstall --claude` (the `plastic-install` skill's repair mode), then re-run doctor |
 
 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