@zalom/plastic 1.14.1 → 2.0.0-alpha.10

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

@@ -1,72 +1,78 @@
-# 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, at M and L; at S only the How boundary fires (see
-`## Depth at Tier S`). 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).
-
-## Depth at Tier S
-
-At Tier S 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. M and L
-send 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.
+# Human Report Contract (the three 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
+written by eye:
+
+- **`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.
+
+## 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, 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
+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.
+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, at M and L the orchestrator still emits the briefing at each boundary, as a running
-EM-to-CTO account. At S only the How briefing fires; see `## Depth at Tier S` 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).
+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).

package/skills/conventions/SKILL.md

@@ -2,7 +2,7 @@
 name: plastic-conventions
 description: >
   Chapters of Plastic doctrine used by more than one skill: the knowledge graph,
-  lifecycle and savepoints, tiers and dispatch, gates and enforcement, locks and
+  lifecycle and savepoints, locks and
   worktrees, completion, maintenance, and roadmaps. Read a chapter when its trigger
   applies to the work in front of you.
 user-invocable: false
@@ -18,8 +18,6 @@ when the trigger in the second column applies to the work in front of you.
 |---|---|
 | `references/knowledge-graph.md` | when creating, linking, curating, or indexing intents and you need the sources-vs-chain doctrine, the tiers of influence, the `## Links` projection, or branch-vs-root directory semantics |
 | `references/lifecycle-and-savepoints.md` | when running a lifecycle stage or a savepoint and you need the subagent report-home contract for how an insight reaches the intent |
-| `references/tiers-and-dispatch.md` | when sizing an intent, choosing agent models, routing to the advisor, or writing an auto-mode human report |
-| `references/gates-and-enforcement.md` | when a transition gate blocks you, or before using an audited escape, for the gate mechanics and the logging contract, or when naming, registering, or retiring a hook or skill |
 | `references/locks-and-worktrees.md` | before taking or releasing a delivery lock, and when working with claims, worktrees, solo mode, or the station ledger |
 | `references/completion-and-done.md` | when ending an intent, for what "intent done" means and the End-stage tail |
 | `references/maintenance-and-revisions.md` | before any structural maintenance edit, for WORK vs MAINTENANCE, the `revisions.md` move-and-record contract, the violation-tag catalog, and the context-economy measurement buckets |

package/skills/conventions/references/lifecycle-and-savepoints.md

@@ -1,6 +1,40 @@
 # Lifecycle and Savepoints
 
-This chapter holds the subagent report-home depth for how an insight reaches the intent when the writer cannot write the file itself.
+This chapter holds two things: what an intent records while the work runs versus what is
+backfilled when it ends, and how an insight reaches the intent when the writer cannot
+write the file itself.
+
+## The live record and the backfilled documents
+
+While working, an intent records four things, and only these are its truth of what
+happened:
+
+- the intent file: `## Context` and `### Decisions` (written in Why) and `## Insights`
+  (one line per ruling, appended as it happens);
+- checklist.md: the items, ticked as they are actually performed;
+- savepoint.md: the append-only stage ledger, written by the hooks and the scripts;
+- the commits on the intent's branch.
+
+The four judgment documents (spec.md, plan.md, actions/, outcome.md) are written when
+there is something to say. In thinking mode an agent writes them during Why and How. In
+direct mode they usually stay as the scaffold placeholder until the close, and
+`scripts/end-intent` then backfills each one still missing or still a placeholder from
+the live record (intent 308): `## Problem` from `## Intent`, `## Decisions` from
+`### Decisions`, `## Acceptance Criteria`, `## Steps`, `## Items`, `## Delivered`, and
+`## Follow-ups` from the checklist, `## Notes` from `## Insights`, `## Verification` from
+the diff on the intent's own worktree, and outcome.md's `disposition:` from the close.
+Every other section keeps the template's stub text; nothing is invented. A backfilled
+file carries a marker comment on the line after its title, and the savepoint gains one
+`Exec  backfilled <list>` line. A file with hand-written content, even under a leftover
+sentinel line, is never touched. The same writer is exposed as `scaffold-intent backfill`
+for the doctor fix hint `backfilled_complete`.
+
+The close never refuses for a document it can write itself. Doctor's per-intent structure
+check runs after the backfill as a report: an unchecked box, a malformed intent file, or
+a wrong-disposition outcome.md is named on stderr, the close proceeds, and
+`/plastic-doctor --intent <id>` keeps reporting it until fixed.
+
+## Insights from a writer that cannot write the file
 
 Background sessions and dispatched sub-agents do not write the insight themselves. They carry
 each nugget home in the completion report's `insights:` field, and the orchestrator (or any

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

@@ -1,21 +1,26 @@
 # Locks and Worktrees
 
-This chapter holds the delivery lock, claims, worktrees, solo mode, fail-safe doctrine, and the station-by-station delivery table.
+This chapter holds the delivery lock, claims, worktrees, the fail-safe doctrine, and the station-by-station delivery table. Since 2.0 (intent 302) nothing here blocks a write: the lock and the worktree are how an auto team keeps one delivery in one place, recorded by the record hook, not enforced by a hook.
 
 ### Delivery Isolation and the Single-Owner Lock
 
-Exactly one session or agent develops an intent's delivery at a time. Ownership is
+Locks and worktrees exist only for auto teams. An interactive session working direct or
+thinking takes no lock: it records into the day ledger, or into the intent its per-session
+pointer names (`~/.plastic/store/.tmp/<session>/current`, where `<session>` is the first eight
+characters of the session id; the file holds today's day id or an intent id).
+
+For an auto team, exactly one team develops an intent's delivery at a time. Ownership is
 session-keyed and durable: arming acquires `delivery.lock` inside the intent directory
 (atomically, O_EXCL). The session id is the authorization identity. Descriptive provenance
 records the controller's explicit `harness`, `agent`, `model`, `thread`, and `mode` values,
 but never grants access and is never inferred from transcripts or filesystem paths. Missing
-fields on legacy locks display as `Unknown`. Liveness is a lease: the owner's hooks refresh
-the lock file's mtime on tool activity, and that mtime is the sole heartbeat truth. The lock
-counts as stale only when the mtime is older than the TTL. No process id is consulted anywhere.
-The /tmp session bridge is a cache
-of this state; on any disagreement, or when the bridge is missing, the lock file wins.
-Another session that finds a fresh lock backs off; a stale lock is reclaimed only by
-explicit takeover, which replaces the lock and appends an audit line to the intent's
+fields on legacy locks display as `Unknown`. Liveness is a lease: the record hook refreshes
+the lock file's mtime on every write the owning session makes, and that mtime is the sole
+heartbeat truth. The lock counts as stale only when the mtime is older than the TTL. No
+process id is consulted anywhere. The pointer file is a cache of which intent a session
+records into; the lock file is the truth of who owns a delivery, and wins on any
+disagreement. Another team that finds a fresh lock backs off; a stale lock is reclaimed only
+by explicit takeover, which replaces the lock and appends an audit line to the intent's
 savepoint.md. Rearming the same session preserves its acquired identity and refreshes known
 provenance; an explicit takeover replaces the controller and starts new provenance.
 Subagents spawned by the owner write under the owner's lock once registered as delegates.
@@ -25,41 +30,27 @@ separate authorization-removal mechanism exists. Finished and failed delegate ac
 retained as descriptive history, bounded to the 20 most recent terminal entries. A controller,
 a delegate, and an artifact claim are distinct evidence: controller ownership authorizes the
 delivery, delegate registration authorizes a child session, and a claim selects one current
-writer for one artifact. Disarm clears the lock; the End tail is ordered: verify, merge and remove
-worktrees, clear the lock, and only then is the bridge purge-eligible. Repair is one
-idempotent function with two entry points: the `plastic-lock` command (`who`, status, fix,
-release, reclaim, delegate) and `/plastic-intent-starting`, so boarding self-heals. `who` is
-read-only and reports the controller, mtime heartbeat, delegates, and claims from durable files.
-This is
-mandatory, not a convention.
-
-Solo-mode gate defaults (intent 128): on a confirmed positive solo determination
-(`Bridge.solo_delivery?`, a single owner working alone with no sign of parallel or team
-delivery), the lock and worktree arbitration gates relax from enforced to advisory. The moment
-any parallel or team activity appears they return to strictly enforced. This is a real behavior
-difference, not just a message change: a solo session is not hard-blocked by these gates, a
-shared one still is.
-
-The bridge resolves the current session in a fixed precedence: the stdin `session_id` first, then
-the `CLAUDE_CODE_SESSION_ID` environment variable, then a derived key when neither is present. A
-bridge is purge-eligible by terminal state, not by age: it is removed only once its intent is no
-longer active, never on a timer. See [`docs/internals.md`](https://github.com/zalom/plastic/blob/main/docs/internals.md) for depth.
-
-The delivery lock arbitrates at the whole-intent grain: it decides who may work
-an intent at all. Underneath it, a per-artifact claim token (intent 111)
-arbitrates at the file grain: it decides who, among those already holding the
-delivery lock, is the one writer for one lifecycle file right now. A write to
-`spec.md`, `plan.md`, `checklist.md`, or the intent file must hold both the
-delivery lock and that file's claim. Claims live in `.claims/<artifact>.claim`
-inside the intent directory, one small JSON file per artifact, scoped strictly
-per-intent-per-artifact, never session-global. The claim gate is dormant
-(allows) when no claim file exists for an artifact, so ordinary single-owner
-work is unaffected; it engages, and denies, only when a second writer tries to
-take a fresh claim someone else already holds. A stale or corrupt claim fails
-open (the write proceeds, the claim yields) and the condition is surfaced in
-`plastic-lock status`, which lists any live claims alongside the delivery
-lock. See `plastic-lock claim`/`release-claim` and [`docs/internals.md`](https://github.com/zalom/plastic/blob/main/docs/internals.md) for the
-full mechanism.
+writer for one artifact. Disarm clears the lock; the End tail is ordered: verify, merge and
+remove worktrees, clear the lock, and only then is the session pointer purge-eligible. Repair
+is one idempotent function with two entry points: the `plastic-lock` command (`who`, status,
+fix, release, reclaim, delegate) and the `plastic-doctor` skill's lock section, so repair
+self-heals. `who` is read-only and reports the controller, mtime heartbeat, delegates, and
+claims from durable files. This is mandatory for auto teams, not a convention.
+
+The record hook resolves the current session in a fixed precedence: the stdin `session_id`
+first, then the `CLAUDE_CODE_SESSION_ID` environment variable, then a derived key when neither
+is present. A session's `.tmp/` directory is purge-eligible by terminal state, not by age: it
+holds nothing durable, and losing it costs nothing. See [`docs/internals.md`](https://github.com/zalom/plastic/blob/main/docs/internals.md) for depth.
+
+The delivery lock arbitrates at the whole-intent grain: it decides who may work an intent at
+all. Underneath it, a per-artifact claim token (intent 111) is a coordination record at the
+file grain: it names who, among those already holding the delivery lock, is the one writer for
+one lifecycle file right now. Claims live in `.claims/<artifact>.claim` inside the intent
+directory, one small JSON file per artifact, scoped strictly per-intent-per-artifact, never
+session-global. Since 2.0 nothing enforces a claim at write time; a team lead takes and
+releases claims through `plastic-lock claim` and `release-claim` to coordinate its executors,
+and `plastic-lock status` lists any live claims alongside the delivery lock. A stale or corrupt
+claim is reported there, never acted on. See [`docs/internals.md`](https://github.com/zalom/plastic/blob/main/docs/internals.md) for the full mechanism.
 
 There is exactly one lock in Plastic: `delivery.lock` (exclusive, one owner plus delegates),
 shipped by intent 108. An earlier two-lock doctrine proposed a second `maintenance.lock`
@@ -72,8 +63,8 @@ for an active delivery. Maintenance instead DETECTS `delivery.lock`'s freshness
 behind. See "WORK vs MAINTENANCE" in `references/maintenance-and-revisions.md` for the full
 doctrine.
 
-Every code-touching intent gets its own git worktree named `{id}--{slug}`, and all code edits
-for that intent happen only inside it. Plastic provisions the worktree deterministically: it
+Every code-touching auto intent gets its own git worktree named `{id}--{slug}`, and all code
+edits for that intent happen inside it. Plastic provisions the worktree deterministically: it
 resolves the project repo from `projects.yml` and runs `git -C <repo> worktree add`, so
 isolation never depends on the current working directory. There is one worktree per project
 intent, the code worktree at `<repo>/.claude/worktrees/{id}--{slug}` (branch
@@ -99,15 +90,28 @@ an orphaned worktree behind, and clear a stale worktree reference with `git work
 
 #### Intent delivery, station by station
 
-How one intent travels from boarding to Done, and what the lock, bridge, and gates do at
-each station.
-
-| Station | Delivered artifact | Lock and bridge steps | Pre-stage gate | Post-stage record |
-|---|---|---|---|---|
-| Start (board) | none (a procedure, not a stage) | `plastic-lock fix` self-heals stale, corrupt, or legacy state; arm acquires `delivery.lock` (O_EXCL, session-keyed), provisions the code worktree, writes the bridge cache | lock-gate denies any write into an active intent dir without this intent's lock; every deny names the resolving command | savepoint confirms the boarding station |
-| What (create) | `<id>--<slug>.md`, born complete | no lock yet; no bridge | create-gate validates the proposed intent content (Write, Edit, and MCP edits) | savepoint `What` line; intent listed in INDEX `## Active` |
-| Why | `spec.md` | owner writes refresh the lease (lock file mtime heartbeat) | gate-check requires the intent file with `## Intent` before spec.md; lock-gate admits only the owner or a delegate | savepoint `Why started`, `Why spec.md created` |
-| How | `plan.md`, `actions/ACTION_N.md` (at least one), `checklist.md` | heartbeat on writes; the code gate stays closed until plan.md, checklist.md, and a real action file all exist | gate-check requires spec.md before plan.md, and plan.md plus a real actions/ACTION_N.md before checklist.md | savepoint `How started`, `How plan.md created`, `How checklist.md created`, `Exec started` |
-| Exec | code on the intent branch, checklist checked off | heartbeat; code edits confined to the provisioned worktree; delegates write under the owner's lock; bash, interpreter, and MCP writes gated the same way | the five edit-path gates (savepoint-pre, lock-gate, code-gate with its stage and worktree rules, links-gate, create-gate) plus bash-gate for shell writes | checklist boxes; savepoint milestones |
-| 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 bridge is purge-eligible, and the QMD reindex runs LAST (after purge) | gate-check blocks outcome.md while checklist items are unchecked | 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 | none enforced by any gate; the maintenance tool or skill itself checks `Lock.fresh?` (see WORK vs MAINTENANCE in `references/maintenance-and-revisions.md`) | 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` |
+How one auto-team intent travels from boarding to Done, and what the lock, the pointer, and
+the record hook do at each station. Nothing in the third column blocks; the fourth column is
+what gets written down.
+
+| Station | Delivered artifact | Lock and pointer steps | Record |
+|---|---|---|---|
+| Start (board) | none (a procedure, not a stage) | `plastic-lock fix` self-heals stale, corrupt, or legacy state; arm acquires `delivery.lock` (O_EXCL, session-keyed), provisions the code worktree, writes the session pointer | savepoint confirms the boarding station |
+| What (create) | `<id>--<slug>.md`, born complete | no lock yet; `new-intent` validates the file it writes (`scripts/validate-intent`) | savepoint `What` line; intent listed in INDEX `## Active` |
+| Why | `spec.md` | owner writes refresh the lease (lock file mtime heartbeat) | savepoint `Why started`, `Why spec.md created` |
+| How | `plan.md`, `actions/ACTION_N.md` (at least one), `checklist.md` | heartbeat on writes | savepoint `How started`, `How plan.md created`, `How checklist.md created`, `Exec started` |
+| 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/conventions/references/maintenance-and-revisions.md

@@ -55,9 +55,9 @@ meaning an active agent is delivering that intent. Maintenance DETECTS this lock
 ACQUIRES it, even transiently, because a maintenance-held lock could be mistaken by a resuming
 or continuation session for an active delivery. Maintenance leaves no lock behind: there is
 nothing to clean up afterward, and no ambiguity about who, if anyone, holds the one lock.
-`bridge.rb:1195`'s `lock_gate_decision` already allows any write once an intent is not in
-INDEX `## Active` - there is no enforced freeze gate in the codebase today, and there never
-was one that shipped (see the corrected history below).
+No code freezes a terminal intent: since 2.0 (intent 302) nothing blocks a write anywhere,
+and before that the lock check already allowed any write once an intent left INDEX
+`## Active`. There never was a shipped freeze (see the corrected history below).
 
 Stranding and clobbering are avoided by construction, not by a second lock: a maintenance
 action creates a fresh branch from the CURRENT state of store main, applies only its own
@@ -82,8 +82,8 @@ already exists, a new run appends
 corrects v2 by appending a correction entry and explicitly leaving v2 in place). This is
 tool-enforced, not prose alone: `scripts/project-links`, `scripts/rebuild-graph`, and
 `scripts/restore-intent-v1` each write this receipt in the SAME write as the structural
-change, or refuse to proceed without one (`scripts/lib/revisions_writer.rb`); the intent
-curator (`agents/plastic-intent-curator.md`) holds itself to the identical rule by hand.
+change, or refuse to proceed without one (`scripts/lib/revisions_writer.rb`); a hand-applied
+relocation holds itself to the identical rule.
 
 Doctor stays a detector: core and full checks, every installed agent, both global and project
 stores. It gains no write path of its own. The "Fix all" prompt
@@ -94,9 +94,9 @@ those tools perform the mutation and write the `revisions.md` receipt - never do
 
 Corrected history (D18): an earlier version of this section described a terminal-immutability
 gate "intent 112 enforces" and a two-lock model. Intent 112 built that gate in full and was
-then ABANDONED before merge on a design pivot; nothing from it ever shipped. `bridge.rb:1195`
-confirms no such gate runs today: a write to a terminal intent is allowed unconditionally once
-the intent leaves INDEX `## Active`. The deadlock that stopped intents 189, 192, and 195 from
+then ABANDONED before merge on a design pivot; nothing from it ever shipped. No such check
+runs today: a write to a terminal intent is allowed unconditionally, as is every other write
+since 2.0 (intent 302). The deadlock that stopped intents 189, 192, and 195 from
 repairing three live `graph_links_projection` violations was self-imposed discipline (agents
 and the owner both treating undocumented doctrine as a real gate), not a technical one. This
 section is the corrected doctrine; intent 112's own history stays in INDEX as an abandoned,
@@ -115,8 +115,8 @@ legitimately accrued chain edge was destroyed by a hand-run restore and went und
 week).
 
 Fail-safe lock doctrine (the contract intent 111 implements): the lock system never traps a
-session or burns credits. When a gate cannot verify lock integrity it fails open, degrading
-to advisory (warn) rather than hard-blocking. Repair is orchestrator-driven: on a lock-issue
+session or burns credits. When a check cannot verify lock integrity it fails open, degrading
+to advisory (warn) rather than refusing. Repair is orchestrator-driven: on a lock-issue
 signal the orchestrator inspects and repairs the lock automatically, and the human
 `plastic-lock` command is a fallback path, not the trigger. Intent 93 states this doctrine;
 intent 111 builds the fail-open behavior, the lock-liveness surface, the lock-issue message,
@@ -144,7 +144,7 @@ not a revision.
 #### Structural maintenance and revisions.md
 
 When a delivered intent accumulates structural junk (an unsanctioned section, a stray file, a
-frontmatter edge to an intent that no longer exists), the intent-curator relocates it into
+frontmatter edge to an intent that no longer exists), a relocation moves it into
 `revisions.md` instead of reopening the work. Each entry is a versioned, dated header
 (`## Revision vN - YYYY-MM-DD-HH:MM`) plus `Why` (one sentence naming the broken rule, ending
 with `[rule: <tag>]`), `Prior location`, and either `Content held` (the verbatim removed
@@ -212,7 +212,7 @@ dropped, and skips (never aborts on) any intent dir holding a fresh delivery loc
 
 Intent 84 defines three buckets for sibling 84a to audit against; 84 does not run the audit.
 
-- (a) gate-hook prose tokens: the per-transition narration emitted by the gate hook.
+- (a) hook prose tokens: the narration the lifecycle hooks emit into context.
 - (b) main-loop store-read tokens: tokens the main agent spends reading or grepping the store
   in the transcript.
 - (c) authored-section sizes: sizes of authored artifacts (INDEX entries and the like).

package/skills/dashboard/SKILL.md

@@ -19,7 +19,7 @@ state → byte-identical payload, regardless of model. Do NOT hand-summarize int
 
 - User invokes `/plastic-dashboard`
 - User asks "where are we", "what's next", "what should I work on", "show me the intents"
-- `plastic-project-continuing` lands on the board on resume
+- `plastic-intent-continuing` lands on the board on a bare resume
 - `plastic-auto` reads `--json` to choose the next dispatchable intent
 
 ## Procedure (the Markdown board — default human surface)

package/skills/direct/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: plastic-direct
+description: Use when a prompt asks for a change, a fix, an edit, a file, or an answer, and no thinking conversation is open on an intent. Judges whether the work is small enough to run right now, asks one clarifying question when one answer would settle it, or offers a thinking intent when it would not. Do not use for a prompt that says "auto" or "continue", a prompt asking to start a new intent, or a prompt inside an open thinking conversation, which belong to plastic-auto, plastic-intent-continuing, plastic-intent-creating, and plastic-intent-speccing.
+user-invocable: false
+---
+
+# Direct mode
+
+Route the prompt in one read, then act. Direct work runs inline in this session, never through a
+dispatched agent, unless the user asks for agents.
+
+## 1. Estimate before you start
+
+Judge the prompt alone, before doing any of the work:
+
+1. Count the targets the prompt names, or that one grep finds.
+2. Require each change to be a named operation on a known target (rename this, add a check there,
+   delete that line), not an outcome ("clean it up", "make it faster").
+3. Budget about one minute per target and sum.
+4. At or under five minutes, run it now. Five minutes is an owner ruling, not a measured
+   threshold.
+5. A bounded sum above five minutes, offer a dedicated intent.
+6. An unknown target, or a change described only by its outcome, cannot be bounded. Ask one
+   question when one answer would supply the missing operation or target. Otherwise offer a
+   thinking intent. A target that only investigation can find is never settled by one
+   question.
+
+Tests or a build the prompt implies do not count against the budget. Verification is part of
+direct work, not a reason to leave direct mode.
+
+## 2. One question, then run
+
+A clarifying question is allowed in direct mode and does not by itself turn the request into a
+thinking intent. Ask one, then run. If the answer is still vague, offer a thinking intent rather
+than asking a second question or guessing.
+
+## 3. The routes
+
+| What the prompt looks like | Where it goes |
+|---|---|
+| Clear, and bounded at or under five minutes | Run it now, inline |
+| Clear, but the bounded estimate is above five minutes | Offer a dedicated intent, `plastic-intent-creating` |
+| Vague, and one answer would resolve it | Ask one clarifying question, then run |
+| Still vague after that one answer | Offer a thinking intent, `plastic-intent-speccing` |
+| Phrased as needing help rather than as an instruction | Offer grill plus a thinking conversation, `plastic-intent-speccing` |
+| Says "auto" explicitly | Hand off to `plastic-auto` |
+
+Read `references/request-signals.md` when a prompt sits on the boundary between two routes, for
+the 15 observable signals and the response each one selects.
+
+## 4. Record and verify
+
+- Verification in direct mode is the UI, the tests, or the user. There is no reviewer agent per
+  item.
+- Only a prompt that changes something on disk or produces an artifact becomes a checklist item.
+  A pure question is answered inline and recorded nowhere.
+- Direct work records into the day ledger that the per-session pointer names. Assume the pointer
+  exists. Never write it.
+
+## 5. What direct does not take
+
+The capture hook detects `auto` and `continue` before you read the prompt, so defer rather than
+keyword-match them yourself. `auto` goes to `plastic-auto`, and `continue` goes to
+`plastic-intent-continuing`. On `auto` with no registered intent, route through
+`plastic-intent-creating` first, because auto requires a registered intent. A prompt that arrives
+inside an open thinking conversation belongs to that conversation, not here.

package/skills/direct/references/request-signals.md

@@ -0,0 +1,59 @@
+# Request signals
+
+The table below is reproduced from
+`296--make-plastic-faster-small-work/resources/research--request-analysis.md`, the
+request-analysis research deposit of intent 296, with its source column renumbered against the
+eight-source list below. Read it when a prompt sits on the boundary between two routes. That
+deposit also carries seven worked examples, one per boundary, for a reader who wants them.
+
+## The signal table
+
+| Signal | What it looks like in a real prompt | Response it selects | Source or ruling |
+|---|---|---|---|
+| A concrete file and a concrete operation are named | "Rename `foo` to `bar` in `app/models/user.rb` and update its three callers." | execute now | D13, D14 |
+| The target is a single, already-known location | "Fix the typo in README.md line 12." | execute now | D14 |
+| The change is described only by its outcome, with no operation named | "Clean up the user model, it's gotten messy." | ask one clarifying question | Kamsties, "Understanding Ambiguity in Requirements Engineering" (source 5); D13 |
+| The prompt uses weak, hedging modal language ("might", "could", "maybe", "somewhere") | "This might need better error handling somewhere in the payment flow." | ask one clarifying question | "Automatic Detection of Ambiguous Terminology for Software Requirements" (weakness ambiguity, source 6); D13 |
+| The prompt admits several equally plausible readings with no cue that favors one | "Make the form better." (styling, validation, and accessibility are all live readings) | ask one clarifying question | "Knowing but Not Showing" (source 3); "Ask or Assume?" (source 1) |
+| One answer to the clarifying question fully resolves scope | User answers: "Just the null check on line 42, nothing else." | execute now | D10 |
+| The answer to the clarifying question is itself vague or open-ended | User answers: "I don't know, whatever seems right." | offer a thinking intent | D13; "Ask or Assume?" (source 1) |
+| The prompt is phrased as a request for help rather than an instruction | "I need help figuring out how to structure the billing refactor, not sure where to start." | offer a thinking intent | D13 |
+| The number of named or discoverable targets is small (roughly one to three) and each change is additive | "Update the copyright year in these three footer partials." | execute now | D14 |
+| The number of targets is large, or the work is described as spanning many files | "Migrate all 40 view partials to the new component library." | offer a thinking intent | D14 |
+| The target is not yet known and must be found by investigation before any edit is possible | "Something is causing the checkout page to be slow, find it and fix it." | offer a thinking intent | D14; sources 7 and 8 |
+| The action is destructive or hard to reverse and its scope is ambiguous | "Delete the old migrations directory." | ask one clarifying question | "Structured Uncertainty guided Clarification for LLM Agents" (source 4) |
+| The action is destructive but small, self-contained, and obviously scoped | "Delete the unused `tmp_debug.rb` file I just created." | execute now | D14 |
+| The request implies running tests or a build step the agent can run itself as part of verification | "Fix the failing test in user_test.rb." | execute now | D15 |
+| The prompt changes nothing on disk and produces no artifact | "What does the PaymentProcessor class do?" | execute now (answered inline; never admitted as a checklist item) | D17 |
+
+Row 8 uses the deposit's wording. Ruling D13 makes the help-needed route grill plus a
+thinking conversation, as `SKILL.md` section 3 states.
+
+## Rulings, not findings
+
+Four things in the table above are owner rulings with no literature behind them. Apply
+them, and know they are policy knobs the owner can turn, not measured results.
+
+- The five-minute total and the one-minute-per-target budget. Task-complexity research (sources 7
+  and 8) correlates target count and search depth with lower agent success, which supports
+  counting targets, but no source sets these numbers.
+- The one-question cap. The clarification research (sources 1, 2, and 4) treats question count as
+  a calibrated, cost-weighted choice that can be zero, one, or more. A hard cap of one is the
+  owner's choice.
+- "Auto" meaning auto mode. It is an interface convention, a keyword that names the mode instead
+  of asking for a judgement.
+- "Help needed" phrasing meaning grill plus a thinking conversation. It is a register cue
+  specific to how this owner phrases requests, not a general finding.
+
+## Sources
+
+1. "Ask or Assume? Uncertainty-Aware Clarification-Seeking in Coding Agents." https://arxiv.org/abs/2603.26233
+2. "Learning to Ask: When LLM Agents Meet Unclear Instruction." EMNLP 2025. https://aclanthology.org/2025.emnlp-main.1104.pdf
+3. "Knowing but Not Showing: LLMs Recognize Ambiguity but Rarely Ask Clarifying Questions." https://arxiv.org/pdf/2605.25284
+4. "Structured Uncertainty guided Clarification for LLM Agents." https://openreview.net/forum?id=dc8ebScygC
+5. Kamsties, Erik. "Understanding Ambiguity in Requirements Engineering." https://link.springer.com/chapter/10.1007/3-540-28244-0_11
+6. "Automatic Detection of Ambiguous Terminology for Software Requirements." https://www.eecis.udel.edu/~yuewang/paper/nldb2013.pdf
+7. "An Approach for Systematic Decomposition of Complex LLM Tasks." https://arxiv.org/html/2510.07772v1
+8. "On the Importance of Task Complexity in Evaluating LLM-Based Multi-Agent Systems." https://arxiv.org/html/2510.04311
+
+All eight were accessed 2026-08-29. The D-numbers in the table are decisions in `296/spec.md`.