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

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

package/skills/intent-continuing/SKILL.md

@@ -5,7 +5,7 @@ description: >-
   where we left off", "where was I", "what should I work on", names a specific intent to
   resume (by id or description, or `--intent {id}`), or names a roadmap or delivery batch to
   resume (`--roadmap {slug}`, "where is the roadmap", "where did that batch land"). Presents
-  state and resumes at the last delivered station; it never asks auto or guided, never boots
+  state and resumes at the last delivered stage; it never asks auto or guided, never boots
   (the SessionStart hook owns boot), and never drives work autonomously (plastic-auto does).
   Absorbs the former continuing, project-continuing, and roadmap-continuing skills and the
   read half of the former intent-starting skill (intent 304).
@@ -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
 
@@ -79,19 +76,20 @@ QMD-first when the intent is named by description: run
 authoritative intent file. The command is a no-op when QMD is absent; fall back to
 `INDEX.md`.
 
-If the intent is terminal (`## Completed` or `## Abandoned` in `INDEX.md`): report only.
-Summarize its `outcome.md` and ask what is next; never reopen it.
+If the intent is terminal (`## Completed` or `## Abandoned` in `INDEX.md`): print the
+intent screen (Status shows the terminal section, Next is empty), summarize its
+`outcome.md`, and ask what is next; never reopen it.
 
 For a live intent's directory:
 
 1. **Read `savepoint.md` first.** It is a deterministic, append-only ledger, one line per
-   event, newest at the bottom: `{utc-iso8601}  {Stage}  {milestone}`. Classify the station
+   event, newest at the bottom: `{utc-iso8601}  {Stage}  {milestone}`. Classify the stage
    from the last line alone (the table in `references/boarding-matrix.md`, read when
    classifying), then verify only that line's artifact is real (sentinel-aware:
    `Savepoint.stage_file_present?`). Do not re-probe every lifecycle file.
-2. **Drift.** When the last line disagrees with the files on disk, rebuild the ledger from
+2. **Stale ledger.** When the last line disagrees with the files on disk, rebuild the ledger from
    disk and note the correction. A rebuilt ledger is the file-landing skeleton, which still
-   pins the station:
+   pins the stage:
    ```bash
    ruby -r ~/.plastic/scripts/lib/savepoint -e 'Savepoint.rebuild_savepoint("<intent_dir>")'
    ```
@@ -99,21 +97,32 @@ For a live intent's directory:
    else the newest prior day) is the prior session's own account of where things stand; read
    it after the ledger, never instead of it.
 4. **Derive the next step:** the first unchecked item in `checklist.md` when it exists, else
-   the next thing the station needs (see the matrix). The newest `## Insights` entry supplies
+   the next thing the stage needs (see the matrix). The newest `## Insights` entry supplies
    the human-readable context; an entry marked `(autonomous)` means an auto team was
    delivering it, so say so and offer to hand back to `plastic-auto`.
-5. **Announce, then continue at that station:**
-   ```
-   Resuming intent [ID] - [name]
-   Store: [global | project:<slug>]
-   Station: [from the ledger's last line]
-   Next step: [first unchecked checklist item | what the station needs]
-   Context: [newest ## Insights entry | hand-off summary]
-   Drift: [none | ledger rebuilt from disk]
-   ```
-   Then continue the work in the session's current mode. In auto mode the running team
-   already holds the delivery lock; if a lock is held by a session that is gone, the
-   `plastic-doctor` skill's lock section repairs or reclaims it.
+5. **Print the report screen as the first thing in the reply, then continue at that stage.**
+   The screen must open the message with nothing before it. On Claude Code, a fail-open
+   `MessageDisplay` hook recognizes a reply that opens this way and substitutes a styled ANSI
+   rendering for it there; the transcript and every other harness keep exactly this plain
+   form. For "where are we" on one named intent, run
+   `ruby ~/.plastic/scripts/report-screen state <intent_dir>` and print its output as it is:
+   the title, the field table, the `Changed` row, and the Steps table come from the record,
+   never by eye. For "where are we" with no intent named, run
+   `ruby ~/.plastic/scripts/report-screen session <tier_root> --session <this session's id>`
+   (intent 330; pass the id your harness gives you, or the screen widens to the whole day and
+   says so): it prints one
+   `delivered` screen per intent this session actually completed, oldest first, then the same
+   roster `report-screen state --all <store_root>` prints on its own - `state --all` stays the
+   right call when only the in-flight roster is wanted, with nothing delivered above it. Route
+   "why did X take so long" to `ruby ~/.plastic/scripts/report-screen delay <intent_dir>`
+   instead - every verb prints the same plain screen on any harness, painted only where the
+   harness supports it, with no branching on harness name. Under the `state` screen
+   write **What this means** as two to four bullets in plain words (what the intent is for,
+   what has landed, what is left, any defect named by step), then close with **needs input:**
+   naming the first open step. Then continue the work in the
+   session's current mode. In auto mode the running team already holds the delivery lock; if a
+   lock is held by a session that is gone, the `plastic-doctor` skill's lock section repairs or
+   reclaims it.
 
 ## Roadmap route: resume the mid-flight roadmap
 
@@ -127,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
@@ -141,6 +151,6 @@ For a live intent's directory:
 | Trigger | Read |
 |---|---|
 | Filling the board on the project route | `references/board-fill.md` |
-| Classifying the station from the ledger's last line | `references/boarding-matrix.md` |
+| Classifying the stage from the ledger's last line | `references/boarding-matrix.md` |
 | Explaining why one roadmap ranked above another | `references/liveness-ranking.md` |
 | Saving or restoring context across a long session, or debugging a resume | `references/context-management.md` |

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-continuing/references/boarding-matrix.md

@@ -1,8 +1,8 @@
-# Boarding matrix: which station a resume lands at
+# Boarding matrix: which stage a resume lands at
 
-The station is derived from `savepoint.md`'s last line plus the real artifacts on disk.
+The stage is derived from `savepoint.md`'s last line plus the real artifacts on disk.
 Classify from the last line alone, then verify only that line's artifact is real
-(sentinel-aware). On drift, rebuild the ledger from disk and note it.
+(sentinel-aware). When the ledger is stale, rebuild it from disk and note it.
 
 | savepoint last line | latest delivered | lands at | continue with |
 |---|---|---|---|
@@ -10,11 +10,12 @@ Classify from the last line alone, then verify only that line's artifact is real
 | `Why  started` (spec still sentinel) | What | **Why** | continue the conversation; rulings land as insights |
 | `Why  spec.md created` | Why | **How** | the action files, `plan.md`, `checklist.md` |
 | `How  started` / `How  plan.md created` | (How in progress) | **How** | finish `plan.md` and `checklist.md` |
-| `How  checklist.md created` / `Exec  started` | How | **Exec** | do the work, tick the checklist |
+| `How  checklist.md created` / `Exec  started` | How | **Exec** | do the work, check off the checklist |
 | `Exec  outcome.md created` | Exec | **ready to complete** | the ending procedure (`plastic-intent-ending`) |
 | `Done  delivered` / `Done  abandoned` | terminal | **report only** | immutable; ask what is next |
+| A node or `Intent` transition line (`n1  running ...`, `Intent  needs_decision ...`) | Exec | **Exec** | a graph delivery is in progress; read node status through `NodeLedger.status`, never re-derive it by eye |
 
-## Per-station behaviour (what "continue" means)
+## Per-stage behaviour (what "continue" means)
 
 - **Why**: continue the conversation, or run the work directly when the request is already
   clear; every ruling is recorded as it lands.

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

@@ -19,7 +19,7 @@ step looks stale):
    (see `SKILL.md`'s `## Conditional Ledger-Resume` for the full state table).
 2. Confirm the artifact that line implies (`plan.md`, `checklist.md`, `outcome.md`, ...) is
    present and non-empty on disk.
-3. If the two disagree, the ledger has drifted: rebuild it rather than hand-editing:
+3. If the two disagree, the ledger is stale: rebuild it rather than hand-editing:
    `ruby -r ~/.plastic/scripts/lib/savepoint -e 'Savepoint.rebuild_savepoint("<intent_dir>")'`
 4. Re-read the rebuilt last line and re-derive the next step from `checklist.md`'s first
    unchecked item.