@zalom/plastic 2.0.0-alpha.13 → 2.0.0-alpha.15

package/scripts/savepoint-note

@@ -2,15 +2,16 @@
 # encoding: UTF-8
 # frozen_string_literal: true
 
-# savepoint-note - the writer CLI for the two savepoint kinds intent 317 adds:
-# Review (one line per plan-review or post-execution-review verdict) and
-# Commit (one line per commit landing during Exec). D17: there is no automatic
-# seam for either (session-commit writes the day ledger, not the intent
-# ledger; the executor's own commits are plain git), so this is an explicit
-# thin wrapper on Savepoint.append_review_savepoint / append_commit_savepoint.
+# savepoint-note - the writer CLI for three savepoint kinds: Review (one line per
+# plan-review or post-execution-review verdict) and Commit (one line per commit landing
+# during Exec), both from intent 317, D17; and Report (one line per report screen printed,
+# intent 331f). None has an automatic seam (session-commit writes the day ledger, not the
+# intent ledger; the executor's own commits are plain git; a printed screen is a skill's own
+# reply, not a file write), so this is an explicit thin wrapper on
+# Savepoint.append_review_savepoint / append_commit_savepoint / append_report_savepoint.
 #
 # Usage:
-#   savepoint-note <intent_dir> --kind Review|Commit --text "<text>"
+#   savepoint-note <intent_dir> --kind Review|Commit|Report --text "<text>"
 #
 # --text is normalized (D21): runs of two or more spaces collapse to one, so a
 # free-text kind that happens to contain a double space cannot key the dedup
@@ -46,12 +47,12 @@ while (arg = args.shift)
   end
 end
 
-usage_abort("usage: savepoint-note <intent_dir> --kind Review|Commit --text \"<text>\"") unless positional.length == 1
+usage_abort("usage: savepoint-note <intent_dir> --kind Review|Commit|Report --text \"<text>\"") unless positional.length == 1
 
 intent_dir = File.expand_path(positional.first)
 usage_abort("#{intent_dir} is not an intent directory") unless File.exist?(Savepoint.intent_file(intent_dir))
 
-KINDS = %w[Review Commit].freeze
+KINDS = %w[Review Commit Report].freeze
 usage_abort("--kind must be one of #{KINDS.join(', ')}, got #{kind.inspect}") unless KINDS.include?(kind)
 usage_abort("--text is required") if text.nil? || text.empty?
 usage_abort("--text must not contain a newline") if text.include?("\n")
@@ -62,6 +63,7 @@ usage_abort("--text is empty after normalization") if normalized.empty?
 case kind
 when "Review" then Savepoint.append_review_savepoint(intent_dir, normalized)
 when "Commit" then Savepoint.append_commit_savepoint(intent_dir, normalized)
+when "Report" then Savepoint.append_report_savepoint(intent_dir, normalized)
 end
 
 exit 0

package/skills/auto/SKILL.md

@@ -201,11 +201,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. Print `ruby ~/.plastic/scripts/report-screen state <intent_dir> --changed "How written, plan review next"`
-   (D15; see `references/human-report-contract.md` for the full trigger list). This replaces
-   the old prose State/Risk/Call briefing at this boundary. In auto mode the screen informs;
-   it does not wait. The screen opens the reply with nothing before it and no code fence: the
-   `MessageDisplay` hook paints only a reply whose first characters are the screen marker.
+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.
 
@@ -276,10 +274,12 @@ Read `../plastic-conventions/references/completion-and-done.md` for what "intent
    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): the owner
-   report at End, replacing the old prose Done briefing. A mid-batch status ask instead runs
-   `report-screen session <tier_root> --session "$CLAUDE_CODE_SESSION_ID"` (intent 330). Print
-   it as the first thing in the reply, no code fence, or the hook cannot paint it.
+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
 

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

@@ -1,9 +1,12 @@
-# Human Report Contract (the three report screens, intent 317)
+# 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 three report screens, filled from the record by `scripts/report-screen`, never
+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.
@@ -18,6 +21,55 @@ written by eye:
   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`
 
@@ -42,9 +94,9 @@ on harness name to decide.
 
 ## Depth for small work
 
-For small work in auto mode, only the How-boundary `state` screen prints mid-flight (its
-`Changed` row names what the What and Why steps did, since there is no separate briefing per
-stage any more). Larger work prints `state` at every trigger in the table above. This is a
+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.
 
@@ -77,6 +129,25 @@ In guided mode, `state` prints at each stage boundary and the human decides befo
 stage starts.
 
 In auto mode, `state` prints at every trigger for larger work; for small work only the How
-boundary 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).
+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)
+
+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/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

package/skills/intent-continuing/SKILL.md

@@ -45,32 +45,29 @@ specific intent or roadmap named.").
 
 ## Project route: land on the board
 
-Land on the Markdown board through the `plastic-dashboard` skill; rendering belongs there.
-Run the data payload and fill the matching template:
-- project loaded: `ruby ~/.plastic/scripts/dashboard.rb project <slug> --data`
-- otherwise (the global fallback): `ruby ~/.plastic/scripts/dashboard.rb continue --data`
-
-Fill the template from `plastic-dashboard`'s `templates/` and present the filled Markdown in
-your reply, every time: tool-call stdout and hook context are invisible to the user. Read
-`references/board-fill.md` for the fill mechanics and the store-health line when filling the
-board. The board load runs the scoped store check (`doctor --store <scope>`); its result
-arrives in the payload as `store_health` and is shown as one line of data, never a blocker.
-
-Priority order on the board: active intents first, then project context (governing plus
-tactical intents in a registered project), then stale future intents for triage, then fresh
-future intents as next work. A future intent older than `stale_threshold_days` (default 3) is
-surfaced for triage without action: activate, abandon, or leave. Activating moves it to
+Print `ruby ~/.plastic/scripts/dashboard.rb project <slug> --screen` (or `continue --screen`
+for the global fallback) as the first characters of the reply: nothing before it, no fence, or
+the hook cannot paint it (intent 331d/331f). It carries a title, six fields (Active, In
+delivery, Delivered, Roadmap, Sessions, Changed), then the Where-we-are and Where-we-go-next
+tables. The board load runs the scoped store check (`doctor --store <scope>`); its result
+rides in the payload as `store_health` and prints as one line of data, never a blocker.
+
+Priority order on the underlying data: active intents first, then project context (governing
+plus tactical intents in a registered project), then stale future intents for triage, then
+fresh future intents as next work. A future intent older than `stale_threshold_days` (default
+3) is surfaced for triage without action: activate, abandon, or leave. Activating moves it to
 `## Active` in `INDEX.md` and auto-commits. The board's ranked next-work order is computed by
 `dashboard.rb`; cite the rule names only (Effort, Value, Flags, Override, Caps) and read
 `plastic-dashboard`'s `references/classification.md` for their definitions.
 
 When the tier root (the directory holding `INDEX.md`) has a mid-flight roadmap
 (`ruby ~/.plastic/scripts/roadmap-next --roadmaps-dir <root>/roadmaps` reports a `state`
-other than `none`), say so in one line and offer the roadmap route; the board still presents
+other than `none`), say so in one line and offer the roadmap route; the screen still presents
 project state and stops.
 
 Then stop: "here is the state, what next?". Do not start executing work. When the user names
-an intent, take the intent route.
+an intent, take the intent route. Read `references/board-fill.md` only when the reader asks
+for the deeper prose board (`plastic-dashboard`'s Markdown surface still exists for that ask).
 
 ## Intent route: resume one intent from its ledger
 
@@ -139,10 +136,11 @@ For a live intent's directory:
    `delivering` or `blocked` entry wins, else the newest ledger or `## Log` timestamp.
    `roadmaps/<slug>.savepoint.md` is a derived signal read here, never a status field;
    `INDEX.md` stays the sole status writer.
-2. **Present state:** the roadmap's `## Goal`, the current batch with each entry's mirrored
-   status, the ledger's newest line beside the newest `## Log` line. Read
-   `../plastic-conventions/references/roadmaps.md` for the file format and the status-mirror
-   rule when a roadmap file needs interpreting.
+2. **Print state.** Print `ruby ~/.plastic/scripts/report-screen roadmap <roadmap.md> state` as
+   the first characters of the reply: nothing before it, no fence, or the hook cannot paint it.
+   It carries Goal, Progress, Frontier, Delivering, Next, and Changed, then the entries table -
+   never hand-typed. Read `../plastic-conventions/references/roadmaps.md` for the file format
+   and the status-mirror rule when a roadmap file needs interpreting.
 3. Then continue with the next dispatchable entry in the session's mode: direct work on it,
    or `plastic-auto` when the owner says auto. The coordinator that drives a batch appends
    to `roadmaps/<slug>.savepoint.md` at its dispatch, merge, park, and handoff points with

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

@@ -41,3 +41,12 @@ The project route's default target is the project board. When no project is load
 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.
+
+## The screen surface (intent 331d)
+
+`dashboard.rb project <slug> --screen` (or `continue --screen`) prints the identical state -
+Active, In delivery, Delivered, Roadmap, Sessions, Changed, then the Where-we-are and
+Where-we-go-next tables - as a screen with its own grammar instead of a filled Markdown
+template. It replaces this fill mechanism once intent 331f wires the project route to print
+it first, the way the intent route already prints the intent screen first today; until then,
+this page's fill rules stay the route's own surface.

package/skills/intent-ending/SKILL.md

@@ -144,11 +144,13 @@ ruby ~/.plastic/scripts/qmd-sync reindex --store <store-root> --async
 No-op when QMD is absent. Runs in the background so it never blocks the
 turn.
 
-### Step 7. EM-to-CTO report
+### Step 7. Print `delivered`
 
-Brief the human like an engineering manager to a CTO: impact and risk first,
-in plain language, the decision left to them (merge, release, or accept).
-See `outcome.md` for the details; do not restate it verbatim.
+Print `ruby ~/.plastic/scripts/report-screen delivered <intent_dir>` as the first characters
+of the reply: nothing before it, no fence, or the hook cannot paint it. Asked, Delivered (with
+its Proven-by column), Evidence, and Needs you come straight from the record - the EM-to-CTO
+report, impact and risk first, in plain language, with the decision left to the human (merge,
+release, or accept). See `outcome.md` for the details; do not restate it verbatim.
 
 ## Abandoned is the same procedure
 

package/skills/intent-executing/SKILL.md

@@ -63,6 +63,8 @@ Dispatch ONE executor subagent and give it the whole delivery: every task's full
 
 After each commit lands (the red commit and every commit after it), append a `Commit` line to the savepoint ledger: `ruby ~/.plastic/scripts/savepoint-note <intent_dir> --kind Commit --text "<sha> <what it proves>"` (intent 317, D17). This is what feeds `report-screen delay`; a commit with no line is a gap the delay report cannot explain.
 
+Print `ruby ~/.plastic/scripts/report-screen state <intent_dir> --changed "<what just landed>"` as the first characters of the reply, nothing before it, no fence, right after the red commit and again once the suite goes green (intent 331f).
+
 Read its response by code:
 - DONE or DONE_WITH_CONCERNS → proceed to Step 3.
 - NEEDS_CONTEXT → provide the missing context, re-dispatch the executor.

package/skills/intent-speccing/SKILL.md

@@ -111,10 +111,13 @@ When the rulings are enough to build from:
    rulings say more than the record already does.
 3. **Self-verify.** Read `references/self-verify-checklist.md` before presenting; fix any
    failing check and re-verify from the top.
-4. **Present and hand off.** Present `spec.md` and the action files. Then offer the routes:
-   run it now inline when the work is small enough for direct mode; hand to `plastic-auto`
-   when the owner says auto and the checklist above passes (all decisions resolved, scope
-   bounded, dependencies named, success criteria defined); or keep thinking.
+4. **Present and hand off.** Print `ruby ~/.plastic/scripts/report-screen plan <intent_dir>` as
+   the first characters of the reply: nothing before it, no fence, or the hook cannot paint it.
+   It carries Asked, Decisions, Steps, Mode, Reviewer, then the Steps and Risks tables, filled
+   from `spec.md` and the action files just written, never restated by eye. Then offer the
+   routes: run it now inline when the work is small enough for direct mode; hand to
+   `plastic-auto` when the owner says auto and the checklist above passes (all decisions
+   resolved, scope bounded, dependencies named, success criteria defined); or keep thinking.
 
 Report, in this order: which files were written (`spec.md` new or rewritten, the action
 files), the count of acceptance criteria, which `## Insights` rulings superseded an earlier

package/skills/roadmap/SKILL.md

@@ -47,6 +47,15 @@ Read `../plastic-conventions/references/roadmaps.md` for the roadmap file format
 semantics, and the status-mirror rule that this skill's own file-format reference builds on. This
 path resolves relative to this skill's own installed directory.
 
+## Reports (intent 331f)
+
+Each verb prints its report screen as the first characters of the reply: nothing before it, no
+fence, or the hook cannot paint it.
+
+- Create prints `ruby ~/.plastic/scripts/report-screen roadmap <roadmap.md> plan`.
+- Read / consume prints `ruby ~/.plastic/scripts/report-screen roadmap <roadmap.md> state`.
+- Close / archive prints `ruby ~/.plastic/scripts/report-screen roadmap <roadmap.md> delivered`.
+
 ## Notes
 
 - File location and the four-section shape are identical across tiers; do not invent a different

package/skills/roadmap/references/file-format.md

@@ -96,6 +96,16 @@ The ledger is derived and rebuildable (`ruby ~/.plastic/scripts/roadmap-savepoin
 roadmaps/{slug}.md`, reconstructing it from `## Log`), never a status source: `INDEX.md` stays the
 single writer of intent status, exactly as for the roadmap file itself.
 
+## Screens read this format (intent 331c)
+
+`report-screen roadmap <roadmap.md> plan|state|delivered` reads exactly the shapes above and
+nothing else: `## Goal`'s first sentence, the `## Batches` (or legacy `## Waves`) grouping and its
+entries (through `RoadmapQueue`'s own reconciled reader - INDEX still wins), and the events from
+the savepoint ledger, falling back to `## Log` classified through the same keyword vocabulary when
+no ledger file exists (an archived roadmap moved before intent 134 shipped, `manual-first.md`
+among them). A screen never invents a status, a time, or a merge sha the file, `INDEX.md`, or the
+ledger did not already carry - the same `not recorded` floor the intent screens use.
+
 ## Worked example
 
 ```

package/templates/dashboard-screen.md

@@ -0,0 +1,22 @@
+## ▶ {{scope}} · dashboard
+
+| | | |
+| --- | --- | --- |
+| **Active**      | {{active}} | intents |
+| **In delivery** | {{in_delivery}} | with a fresh lock |
+| **Delivered**   | {{delivered}} | in the last 7 days |
+| **Roadmap**     | {{roadmap}} | frontier batch |
+| **Sessions**    | {{sessions}} | alive |
+| **Changed**     | {{changed}} | newest savepoint |
+
+**Where we are**
+
+| Graph ID | Intent | Stage | Progress | Lead |
+| --- | --- | --- | --- | --- |
+{{where_we_are.rows}}
+
+**Where we go next**
+
+| Rank | Graph ID | Intent | Reason |
+| --- | --- | --- | --- |
+{{where_we_go_next.rows}}

package/templates/display-fixture.md

@@ -0,0 +1,21 @@
+<!-- Doctor's display self-test fixture (intent 331e). Replayed through the
+     installed MessageDisplay hook by `display_hook_paints` to prove painting
+     still works; this is NOT a report-screen scaffold (no {{...}} mustache
+     placeholders) and ships no data of its own. -->
+
+## ▶ 331e · Doctor display check
+
+| | | |
+| --- | --- | --- |
+| **Store**     | project:plastic                | the plastic project store |
+| **Status**    | Active                          | listed under ## Active in INDEX.md |
+| **Stage**     | Exec                            | What, Why, How, Exec delivered; the work is open |
+| **Progress**  | ██████████░░░░░░░░░░ 3 / 6      | 3 steps open |
+
+**Steps**
+
+| Step | Status | What |
+| --- | --- | --- |
+| S1 | done | Tests red |
+| S2 | done | check_display_registration in doctor_core.rb |
+| S3 | open | The three full-run checks in doctor.rb |

package/templates/intent-screen.md

@@ -12,6 +12,6 @@
 
 **Steps**
 
-| Step | Status | What |
+| Step | Status | Detail |
 | --- | --- | --- |
 {{steps.rows}}

package/templates/report-plan.md

@@ -0,0 +1,15 @@
+## ▶ {{id}} · {{name}} · plan
+
+| | | |
+| --- | --- | --- |
+{{fields.rows}}
+
+**Steps**
+
+| Step | Action | Detail |
+| --- | --- | --- |
+{{steps.rows}}
+
+**Risks**
+
+{{risks.block}}

package/templates/report-roadmap-delivered.md

@@ -0,0 +1,10 @@
+## ✔ {{slug}} · roadmap · delivered
+{{meta}}
+
+**Delivered**
+
+{{delivered.table}}
+
+**Log**
+
+{{log.table}}

package/templates/report-roadmap-plan.md

@@ -0,0 +1,9 @@
+## ▶ {{slug}} · roadmap · plan
+
+| | | |
+| --- | --- | --- |
+{{fields.rows}}
+
+**Batches**
+
+{{entries.table}}

package/templates/report-roadmap-state.md

@@ -0,0 +1,9 @@
+## ▶ {{slug}} · roadmap
+
+| | | |
+| --- | --- | --- |
+{{fields.rows}}
+
+**Batches**
+
+{{entries.table}}

package/templates/report-state.md

@@ -6,6 +6,6 @@
 
 **Steps**
 
-| Step | Status | What |
+| Step | Status | Detail |
 | --- | --- | --- |
 {{steps.rows}}