@zalom/plastic 2.0.0-alpha.7 → 2.0.0-alpha.9

package/skills/intent-continuing/SKILL.md

@@ -103,20 +103,25 @@ For a live intent's directory:
    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. **Print the intent screen as the first thing in the reply, then continue at that stage.**
+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, and nothing about how the screen is printed here ever changes. Run
-   `ruby ~/.plastic/scripts/intent-screen <intent_dir>` and print its output as it is: the
-   title, the field table, and the Steps table come from the record, never by eye. Under it
+   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 state --all <store_root>` for the roster across every
+   in-delivery intent. 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. The screen's shape is
-   `~/.plastic/templates/intent-screen.md`; the script fills it, the session never edits the numbers.
-   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.
+   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
 

package/skills/intent-ending/SKILL.md

@@ -63,8 +63,14 @@ on disk is what the record becomes, so before the call:
 
 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
+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 (`### S1 - ...` proves row S1); 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). A placeholder outcome.md is backfilled from the record instead, 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

package/skills/intent-executing/SKILL.md

@@ -61,6 +61,8 @@ 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.
+
 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 +71,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 whichever `actions/ACTION_N.md` heading carries that row's label as a standalone token - `### Row A -` proves row A, `### S1 -` proves row S1. Write action-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 matches.
+
 ### Step 4: Update Intent and Complete
 Capture observations in `## Insights`. When ALL checklist items are checked:
 

package/templates/outcome.md

@@ -7,10 +7,23 @@ disposition: delivered|abandoned
 (what was delivered)
 
 ## Delivered
-- ...
+<!-- One row per thing delivered, in plain wording a reader recognizes, not
+an implementation summary; the technical detail belongs in ## Summary. Each
+row's label must appear as a standalone token in an actions/*.md heading
+(for example "### S1 - ..." proves row S1): that heading's matrix rows become
+the row's Proven-by cell on the delivered screen (intent 317 D19, 317a). -->
+| Row | What |
+| --- | --- |
+| S1 | ... |
 
 ## Verification
 - <acceptance criterion> — verified by ... → result
 
+## Needs you
+<!-- The literal None, or a table shaped | N | What | Why | with one row per
+open owner action. Prose is tolerated by the reader but renders as a single
+untyped row - write the table. -->
+None
+
 ## Follow-ups
 None

package/templates/report-state.md

@@ -0,0 +1,11 @@
+## ▶ {{id}} · {{name}}
+
+| | | |
+| --- | --- | --- |
+{{fields.rows}}
+
+**Steps**
+
+| Step | Status | What |
+| --- | --- | --- |
+{{steps.rows}}