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

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.

package/skills/intent-ending/SKILL.md

@@ -51,21 +51,39 @@ on disk is what the record becomes, so before the call:
    reported gap that lands verbatim in the backfilled `## Follow-ups`.
 2. Confirm every acceptance criterion in spec.md is verifiable (tests pass,
    or the manual check described in its HOW line was actually run).
-3. Decide what you have to say. A spec.md, plan.md, action file, or outcome.md
-   left as the scaffold placeholder is written from the record by
-   `scripts/end-intent` (the intent file's `## Intent`, `### Decisions`, and
-   `## Insights`, the checklist, the diff on the intent's own worktree). A
-   file you wrote, even under a still-present sentinel, is never touched.
-   Write outcome.md yourself when the summary deserves more than the
-   `--outcome-summary` line; otherwise let the backfill carry it.
+3. Decide what you have to say. For an intent with a `graph.md`, `outcome.md` is
+   GENERATED by `scripts/end-intent` itself, through `scripts/lib/outcome_report.rb`
+   (`scripts/outcome-report` is its standalone CLI, useful for checking the
+   generated text before the close): `## Delivered`, `## Verification`,
+   `## Graph diff`, and `## Findings` are read straight from `graph.md`, `nodes/`,
+   and the ledger every time, never hand-typed. `## Summary`, `## Needs you`, and
+   `## Follow-ups`, and every frontmatter key but `disposition`, are preserved
+   byte for byte when you author them and generated as plain facts otherwise, so
+   writing a summary yourself still works exactly as before. For an intent with
+   no `graph.md`, or when the generated text would be refused by the close's own
+   gates, a spec.md, plan.md, action file, or outcome.md left as the scaffold
+   placeholder is written from the record by `scripts/end-intent` (the intent
+   file's `## Intent`, `### Decisions`, and `## Insights`, the checklist, the
+   diff on the intent's own worktree). A file you wrote, even under a
+   still-present sentinel, is never touched.
 
 ### Step 1-5. Run `scripts/end-intent`
 
-Author outcome.md yourself when it deserves prose: copy `templates/outcome.md`,
-set the frontmatter to `disposition: delivered` or `disposition: abandoned`, and
-fill `## Summary`, `## Delivered`, `## Verification`, `## Follow-ups`. On
-abandon, `## Summary` states the abandonment reason and the trail (see Pivot
-below). A placeholder outcome.md is backfilled from the record instead, with the
+Author outcome.md yourself when the summary deserves more prose than the generator's
+plain facts: copy `templates/outcome.md`, set the frontmatter to `disposition: delivered`
+or `disposition: abandoned`, and fill `## Summary`, `## Delivered`, `## Verification`,
+`## Follow-ups`. `## Delivered` is a `| Row | What |` table: one row per thing delivered,
+in plain wording a reader recognizes, not a method name or an implementation summary
+(that detail belongs in `## Summary`). Each row's label must appear as a standalone token
+in an action-file heading (or a node-file heading, for an intent whose graph replaces
+actions/ with nodes/) that owns the matrix table (`### S1 - ...` or
+`## n1 failure-mode matrix` with a table beneath it proves that row; a table-less
+heading naming the label is skipped); that heading's matrix rows become the row's
+Proven-by cell on `report-screen delivered`'s post-delivery screen. `## Needs you` is
+the literal None or a `| N | What | Why |` table. On abandon, `## Summary` states the
+abandonment reason and the trail (see Pivot below). An intent with a `graph.md` and no
+hand-written outcome.md gets one generated instead (Step 0.3 above); a placeholder
+outcome.md on an intent with no `graph.md` is backfilled from the record, with the
 close's disposition and the `--outcome-summary` line as its summary. Also author
 the rich INDEX entry note now (a short line in the store's existing
 Completed/Abandoned convention: mode, what shipped or why it was
@@ -138,11 +156,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

@@ -44,6 +44,10 @@ Dispatches subagents to do the work. The controller never implements. It dispatc
 
 The post-execution review in Step 3 runs by risk (the rule lives in the auto skill). When it runs, the reviewer is a separate agent with fresh context, never the maker. The plan itself is reviewed before code by the adversarial plan reviewer (`plan-reviewer-prompt.md`), dispatched by the lead at How.
 
+### Graph dispatch: the paste
+
+When the plan is a graph (`nodes/*.md`, not `plan.md` plus action files), the dispatch step is the paste, not a lead's hand-typed brief. `runner step` computes readiness, applies policy, and prints a spawn block per dispatched node - agent, model, packet path, the one test command, the call cap - fenced in its own stdout. Copy each block into the Agent tool as its own dispatch, verbatim; the runner itself never spawns an agent (327 D42).
+
 ### Inline (Fallback)
 Executes tasks sequentially in the current session. Use when subagents aren't available or user explicitly requests inline mode.
 
@@ -61,6 +65,10 @@ Run Step 0 (Sync Worktree First) before this step.
 
 Dispatch ONE executor subagent and give it the whole delivery: every task's full text from `plan.md` (pasted in, never a file reference), every action file with its failure-mode matrix, the checklist items it must tick, the project context from CLAUDE.md, the active intent context from `{ID}--{slug}.md`, and the worktree path. In auto mode this is the `plastic-executor` agent; elsewhere use the `implementer-prompt.md` template. The executor writes the matrix's tests and commits them red, implements the consolidated action in order, ticks each item as it lands (see `## Tick-as-you-land`), and drives the test suite green.
 
+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.
@@ -69,6 +77,10 @@ Read its response by code:
 ### Step 3: Review by Risk
 Apply the auto skill's risk rule to the executor's return and the diff: a matrix row no test could prove, a diff touching a hook, the lock, the worktree code, the installer, or a release file, a DONE_WITH_CONCERNS or a deviation from the matrix, or an owner-facing surface no test pins. When a rule fires, dispatch the post-execution reviewer with `code-quality-reviewer-prompt.md` (a separate agent with fresh context, never the maker); if it returns changes, re-dispatch the executor to fix them, then run the suite once more. When no rule fires, the green suite is the review.
 
+Whenever a review verdict returns - the plan review before code, or the post-execution review above - the lead appends a `Review` line: `ruby ~/.plastic/scripts/savepoint-note <intent_dir> --kind Review --text "<verdict, what changed>"` (intent 317, D17). This is the other half of what `report-screen delay` reads.
+
+**The D19 heading convention.** An action file's `## Delivered` row (in `outcome.md`) is proven by the first `actions/ACTION_N.md` OR `nodes/*.md` heading that carries that row's label as a standalone token AND owns the matrix table (322 D1r, 334 D10r) - `### Row A -` with a table beneath it proves row A, `### S1 -` proves row S1, `## n1 failure-mode matrix` proves row n1; a heading that only names the label, with no table under it, is skipped. Readers check `actions/` first, then `nodes/` (334 D15r). Write action-file or node-file section headings so the label they prove is unambiguous (never a substring another label could also match, like `A` inside `AB`); `report-screen delivered`'s Proven-by column renders `not recorded` when no heading owns a matching table and no matrix row cell carries the label either.
+
 ### Step 4: Update Intent and Complete
 Capture observations in `## Insights`. When ALL checklist items are checked:
 
@@ -102,11 +114,15 @@ Capture observations in `## Insights`. When ALL checklist items are checked:
 
 ## Tick-as-you-land
 
-As each task lands, in the same edit: move its checklist item from `## In
-Progress` to `## Completed` in `checklist.md`, and add one `## Session Log`
-row (Date, Items Completed, Notes). Do not batch several tasks' worth of
-checklist updates into one later edit; tick the moment the task is verified,
-before moving to the next task.
+A tick is two edits, made together: mark the item's box `[x]`, and move its
+checklist item from `## In Progress` to `## Completed` in `checklist.md`;
+then add one `## Session Log` row (Date, Items Completed, Notes). The box is
+the half the state screen's Progress bar reads: `IntentScreen::ITEM_RE` and
+`progress_fields` count `[x]`, not which section the line sits in, so a line
+moved to `## Completed` with its box left unmarked still reads as zero
+progress. Do not batch several tasks' worth of checklist updates into one
+later edit; tick the moment the task is verified, before moving to the next
+task.
 
 ## Verify before every owner review
 

package/skills/intent-executing/implementer-prompt.md

@@ -20,12 +20,17 @@ You are implementing a specific task from a plan. You have been given the full t
 2. Implement exactly what the task specifies — nothing more, nothing less.
 3. Write tests first when the task includes test steps (TDD).
 4. Follow the file paths specified in the task exactly.
-5. Commit after each logical unit of work.
+5. Commit after each logical unit of work, and in the same step tick the checklist item that
+   unit lands: mark its box `[x]` and move the line to `## Completed`, then append the
+   savepoint `Commit` line
+   (`scripts/savepoint-note <intent_dir> --kind Commit --text "<sha> <what it proves>"`). A
+   commit without its tick is incomplete.
 6. When done, self-review against this checklist:
    - [ ] All steps in the task are completed
    - [ ] Tests pass
    - [ ] Code is clean and follows project conventions
    - [ ] No unrelated changes
+   - [ ] Every landed unit's checklist item is ticked
 
 ## Report Format
 

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/releasing/SKILL.md

@@ -206,6 +206,45 @@ The dist-tag is derived from the version string in `package.json`:
 - Contains `-beta` → `--tag beta`
 - No pre-release suffix → no `--tag` flag (publishes to `latest`)
 
+#### `npm_publish_workflow`
+
+The tag pushed in step 6 starts the project's publish workflow (GitHub Actions, keyed on the
+workflow file `publish.yml`) instead of a local `npm publish`. The workflow runs with a
+short-lived, per-run OIDC credential, so no npm token exists in this session or on this
+machine.
+
+1. **Confirm a run exists for the tag.** A tag cut from a ref that does not carry the
+   workflow starts no run at all, and silence would read as success:
+
+   ```bash
+   gh run list --workflow publish.yml --limit 5
+   ```
+
+2. **Follow the run.**
+
+   ```bash
+   gh run watch <run-id>
+   ```
+
+3. **Verify the registry, not just the run.** The release is not done until the new version
+   shows up on the expected channel:
+
+   ```bash
+   npm view <package> dist-tags
+   ```
+
+The dist-tag is derived from the version string in `package.json`, the same rule
+`ReleaseGuard.dist_tag` implements:
+
+| Version contains | dist-tag |
+| --- | --- |
+| `-alpha` | `alpha` |
+| `-beta` | `beta` |
+| no pre-release suffix | `latest` |
+
+Do not run `npm whoami` on this path. npm documents that `whoami` does not reflect OIDC
+authentication, so on a workflow-published project it can only mislead.
+
 #### Other values
 
 If `on_green` contains an action not listed above, log it:

package/skills/releasing/references/promotion-and-tagging.md

@@ -34,18 +34,22 @@ cleared is a no-op.
 ## Promotion
 
 Promotion is not a CLI flag; there is no `--promote` command. It is a set of steps the
-agent performs during the releasing workflow, reusing the normal release mechanics
-(version bump, tag, `npm publish` with the channel's dist-tag, GitHub release):
+agent performs during the releasing workflow, reusing the normal release mechanics (version
+bump, tag, GitHub release). For a project on the `npm_publish_workflow` post-push action,
+the tag push itself starts the publish; there is no local publish command to run.
 
 ```bash
-# Promote alpha → beta: set version files from -alpha.N to -beta.1, commit, tag, then
-npm publish --access public --tag beta
+# Promote alpha → beta: set version files from -alpha.N to -beta.1, commit, tag, push.
+# The publish workflow reads the new version and publishes to the beta dist-tag.
 
 # Promote beta → stable: strip the pre-release suffix (e.g., 1.0.0-beta.3 → 1.0.0),
-# commit, tag, then
-npm publish --access public          # no --tag flag publishes to latest
+# commit, tag, push. The publish workflow reads the new version and publishes to latest.
 ```
 
+A project still on the `npm_publish` action (publishing locally from the session) runs
+`npm publish --access public --tag <channel>` at this point instead, per that action's own
+section in SKILL.md.
+
 **Promotion rules:**
 - Linear only: alpha → beta → stable. Cannot skip channels.
 - Version files are bumped and committed as in a normal release.

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

@@ -78,7 +78,7 @@ re-deriving this decision.
 of 1.1.0, versioned `1.2.0-beta.1` (`c48601a`). There is nothing left to execute on the git side;
 this playbook describes what happens next, not a pending action.
 
-**Preconditions**, both required before any npm publish of `1.2.0-beta.1`:
+**Preconditions**, both required before any publish of `1.2.0-beta.1`:
 
 - (a) One documentation pass over beta-line skills and docs for the hybrid savepoint contract:
   on beta, only the terminal Done bookend still writes a live `savepoint.md`; every other

package/skills/roadmap/SKILL.md

@@ -43,10 +43,36 @@ See `references/file-format.md` for the exact entry-line shape, status vocabular
 format, and a worked example. See `references/operations.md` for step-by-step mechanics of each
 verb above.
 
+## Graph (intent 337)
+
+A roadmap may carry an optional `## Graph` section - the same `needs` edge grammar as an
+intent's own `graph.md` (`- <id> needs <id> <id>`, or `- <id> needs nothing` for a root). When
+present, batches are computed from it (`roadmap-graph check`/`render`), not hand-ordered; the
+template scaffolds a fenced example so a new roadmap starts with the section already in place.
+Three verbs, all `--dry-run`-able:
+
+| Verb | What it does |
+|------|--------------|
+| `roadmap-graph check <roadmap.md>` | Prints the computed batches, the ready set, and any dangling id (a graph names it, no batch lists it); exits 1 on a cyclic graph or a dangling id. |
+| `roadmap-graph render <roadmap.md>` | Writes `## Tree` (a box-drawing render of the graph) and regroups the batch/wave section from the computed batches, entry lines carried over verbatim. |
+| `roadmap-graph migrate <roadmap.md>` | Derives a conservative `## Graph` for a graphless roadmap from its existing batch order (batch N needs every entry of batch N-1); never overwrites an existing graph. |
+
+A roadmap with no `## Graph` section keeps working exactly as before (wave-order dispatch); the
+graph is additive, never required.
+
 Read `../plastic-conventions/references/roadmaps.md` for the roadmap file format, batch
 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/config.yml

@@ -2,11 +2,11 @@ version: 3
 project_roots:
   - ~/.plastic/projects
 stale_threshold_days: 3
-# When to compact. Absolute token counts for a 1M window (35 and 50 percent), not
+# When to compact. Absolute token counts for a 1M window (15 and 25 percent), not
 # percentages: models are reliable only to roughly 50 to 65 percent of advertised
 # context, so a percentage that is right at 200k floats to an untested size at 1M.
-context_offer_tokens: 350000
-context_insist_tokens: 500000
+context_offer_tokens: 150000
+context_insist_tokens: 250000
 execution_mode: subagent-driven
 hash_length: 6
 hash_algorithm: sha256-base36

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/graph.md

@@ -0,0 +1,16 @@
+# Graph: <intent name>
+
+## Goal
+<What this intent's graph delivers once every node reaches done.>
+
+## Decisions
+- D1 <first ruling made while building this graph>
+
+## Graph
+Edges, `needs` only; the head needs the tail done. The literal target `nothing` declares a root.
+- n1 needs nothing
+
+## Status
+| Node | State | Detail |
+| --- | --- | --- |
+| n1 | planned |  |

package/templates/intent-screen.md

@@ -0,0 +1,17 @@
+## ▶ {{id}} · {{name}}
+
+| | | |
+| --- | --- | --- |
+| **Store** | {{store}} | {{store.note}} |
+| **Status** | {{status}} | {{status.note}} |
+| **Stage** | {{stage}} | {{stage.note}} |
+| **Savepoint** | {{savepoint}} | {{savepoint.note}} |
+| **Progress** | {{progress.bar}} {{progress.done}} / {{progress.total}} | {{progress.note}} |
+| **Next** | {{next}} | {{next.note}} |
+| **Insight** | {{insight}} | {{insight.note}} |
+
+**Steps**
+
+| Step | Status | Detail |
+| --- | --- | --- |
+{{steps.rows}}