@zalom/plastic 1.14.0 → 2.0.0-alpha.1

package/skills/auto/evals/evals.json

@@ -132,13 +132,13 @@
       "scope": "triggering",
       "set": "validation",
       "prompt": "what's the status of my active intents?",
-      "expected_output": "Does NOT activate plastic-auto; this is a read/intent-continuing/store-indexing query.",
+      "expected_output": "Does NOT activate plastic-auto; this is a read/intent-continuing query.",
       "files": [],
       "assertions": [
         {
           "type": "code",
           "check": "router CHOICE != plastic-auto",
-          "observed": "plastic-store-indexing",
+          "observed": "plastic-intent-continuing",
           "result": "pass"
         }
       ]
@@ -170,12 +170,12 @@
       "scope": "behavior",
       "set": "train",
       "prompt": "Active intent X exists. Deliver it in auto mode on a harness that supports subagents.",
-      "expected_output": "Spins up one enforcer-led team per intent (brainstorming, spec-specialist, planner, executor, plastic-enforcer). The enforcer IS the orchestrator. Dispatches one specialist per stage sequentially on one branch, gating each deliverable (Context+Decisions, then spec.md, then plan.md+actions+checklist, then code) against the stage exit criteria before handoff, and dispatches an independent reviewer subagent at the final gate only.",
+      "expected_output": "Spins up one enforcer-led team per intent (plastic-enforcer, executor, an on-request reviewer). The enforcer IS the orchestrator: it writes spec.md, the action files, and checklist.md itself, dispatches one executor for the consolidated action on one branch, and dispatches an independent reviewer subagent at the final gate only.",
       "files": [],
       "assertions": [
         {
           "type": "human",
-          "check": "five-role roster spun up; specialists dispatched stage-sequentially with per-stage gating; independent reviewer only at final gate",
+          "check": "enforcer writes Why and How itself; one executor dispatched; independent reviewer only at final gate",
           "observed": "dogfood: intents 60-62 delivered by exactly this enforcer-led team on a shared branch",
           "result": "pass"
         },
@@ -208,13 +208,13 @@
       "scope": "behavior",
       "set": "validation",
       "prompt": "A power-tool is present (qmd on PATH, or a .serena marker / serena on PATH). A substantive prompt arrives in auto mode.",
-      "expected_output": "The UserPromptSubmit power-tools hook appends a MANDATORY obligation per present tool: a MUST-use-QMD line when qmd is present (to check for an existing or related intent before treating work as new), and a MUST-use-Serena line when serena is present (symbolic tools before grep/Read). No search hits are injected: intent 246 removed the per-prompt qmd hit search, so the hook emits the mandate and nothing else.",
+      "expected_output": "The agent prefers the present tool because PLASTIC.md (loaded at session start) recommends QMD for intents and Enola, or Serena when Enola is absent, for code navigation. No hook appends a per-prompt line: the power-tools hook was removed in 2.0 (intent 309).",
       "files": [],
       "assertions": [
         {
           "type": "code",
-          "check": "PowerTools.mandate returns MUST/MANDATORY lines for each present tool; QmdHook.run appends the mandate",
-          "observed": "power_tools_test.rb + qmd_hook_test.rb assert MUST wording; serena line gated on the serena detector; qmd_hook_test.rb test_no_retrieval_hits_are_ever_injected asserts no hit header for any tool combination",
+          "check": "PLASTIC.md carries the recommendation (doctrine_305_test) and PowerTools presence probes still back doctor's readiness checks (power_tools_test.rb)",
+          "observed": "doctrine_305_test test_plastic_md_carries_the_power_tools_mandate_as_a_recommendation; power_tools_test.rb presence probes",
           "result": "pass"
         }
       ]
@@ -224,13 +224,13 @@
       "scope": "behavior",
       "set": "validation",
       "prompt": "Neither qmd nor serena is present (no qmd on PATH, no .serena marker, no serena on PATH). A substantive prompt arrives.",
-      "expected_output": "Detect-then-degrade: the hook emits nothing (silent no-op, exit 0). No mandate text appears. Nothing is required to install.",
+      "expected_output": "Detect-then-degrade: PLASTIC.md's recommendation applies only when a tool is present, so nothing is required to install and no per-prompt line appears (there is no hook to emit one since intent 309).",
       "files": [],
       "assertions": [
         {
           "type": "code",
-          "check": "PowerTools.mandate returns nil and QmdHook.run returns nil when neither tool is present",
-          "observed": "power_tools_test.rb test_mandate_neither_is_nil + qmd_hook_test.rb test_nil_when_neither_tool_present",
+          "check": "PowerTools.mandate returns nil when neither tool is present",
+          "observed": "power_tools_test.rb test_mandate_neither_is_nil",
           "result": "pass"
         }
       ]

package/skills/auto/references/agent-architecture.md

@@ -12,68 +12,66 @@ The Main Orchestrator manages the global store (Main Knowledge Base). It:
 
 Project Orchestrators manage project stores (Project Knowledge Bases). They:
 - Care about intents and execution within their project
-- Spin up an enforcer-led team to deliver an intent
+- Lead an auto team to deliver an intent
 - Contribute back to the Main Orchestrator when new intents are born
   that could enrich the Main Knowledge Base
 
 ## The Auto-Mode Team
 
-Auto mode spins up exactly ONE enforcer-led team per intent. The plastic-enforcer
-IS the auto orchestrator itself, not a separately dispatched agent. Making the
-orchestrator the enforcer avoids the who-gates-the-gater regress (the gate-keeper
-can never be ungated).
+Auto mode runs exactly ONE team per intent, led by the orchestrating session itself: the
+plastic-enforcer IS the lead, not a separately dispatched agent. The team has two standing
+roles plus two reviewer prompts dispatched as fresh agents (the four stage agents were removed
+in 2.0, intent 304; the lead writes the Why and How record itself):
 
-The team has five roles, one per place in the What, Why, How, Exec cycle:
+- **plastic-enforcer** (the lead, spans the whole cycle): takes the intent, writes `spec.md`,
+  `plan.md`, the action files with their failure-mode matrix, and `checklist.md`; has the plan
+  reviewed before code; dispatches the executor; applies the risk rule; closes.
+- **plastic-executor** (Exec): commits the matrix's tests red, writes the code, checks off
+  `checklist.md`, appends `## Insights`, and drives the suite green.
+- **the plan reviewer**: a fresh agent on `plastic-intent-executing`'s
+  `plan-reviewer-prompt.md`, dispatched once before any code exists.
+- **the post-execution reviewer**: a fresh agent on `code-quality-reviewer-prompt.md`,
+  dispatched only when the auto skill's risk rule fires; never the maker.
 
-- **plastic-brainstorming** (Why exploration): enriches `## Context` and records
-  `### Decisions` with rationale.
-- **plastic-spec-specialist** (Why-to-How boundary): consolidates the Why into
-  `spec.md` (Problem, Goals, Non-Goals, Approach, Decisions, Acceptance Criteria).
-- **plastic-planner** (How): produces `plan.md`, `actions/ACTION_N.md`, and
-  `checklist.md`.
-- **plastic-executor** (Exec): writes the code, checks off `checklist.md`, appends
-  `## Insights`, and drives the suite green.
-- **plastic-enforcer** (spans the whole cycle): orchestrates and gates.
+Two agent boots is the normal delivery (the plan reviewer, the executor); the post-execution
+reviewer is the third only when risk calls for it.
 
 ### Handoff Contracts
 
-Each specialist receives the prior stage's deliverable and produces the next stage's
-input. The enforcer dispatches one specialist per stage with a constructed context
-bundle, gates that deliverable against the stage's exit criteria, and only then hands
-off to the next stage. Dispatch is sequential on a single branch, because the stage
-deliverables share files (a parked spec, plan, and checklist all live in the same
-intent directory).
+The lead hands the executor one constructed context bundle: the spec decisions, the plan, the
+action files with their matrix, the checklist, and the worktree path. The executor hands back
+the code, the red and green commits, a checked-off checklist, `## Insights`, and its completion
+report. Dispatch is sequential on a single branch, because the deliverables share files.
 
-The chain: intent `## Intent` / `## Context`, then enriched `## Context` plus
-`### Decisions`, then `spec.md`, then `plan.md` plus `actions/` plus `checklist.md`,
-then the code changes plus a checked-off checklist plus `## Insights`.
+The chain: intent `## Intent` / `## Context`, then enriched `## Context` plus `### Decisions`,
+then `spec.md`, then `plan.md` plus `actions/` plus `checklist.md`, then the plan review, then
+the code changes plus a checked-off checklist plus `## Insights`.
 
 ### Spawn Preamble (L2 live-state injection)
 
-Every dispatched specialist is booted with a spawn preamble: the enforcer runs
-`scripts/spawn-preamble <intent_dir> --role <role>` and prepends its output to the
-specialist's prompt. The preamble is a pure function of the intent directory on disk
-(no network, no clock, no randomness), so it is deterministic and rebuildable. It
-carries the active intent id and intent line, the current lifecycle stage (the last
-savepoint line, else stage derived from which lifecycle files exist), the cycle
-role, and the honoring instruction that the agent must emit valid lifecycle artifacts
-and not hallucinate intents or stages. This is the standard L2 live-state mechanism
-for harnesses whose spawned sub-agents do not inherit the top-level session event. See
-[`harness-adapters.md`](https://github.com/zalom/plastic/blob/main/docs/reference/harness-adapters.md) for how it slots into the per-harness contract.
+Every dispatched agent is booted with a spawn preamble: the lead runs
+`scripts/spawn-preamble <intent_dir> --role <role>` and prepends its output to the agent's
+prompt. The preamble is a pure function of the intent directory on disk (no network, no clock,
+no randomness), so it is deterministic and rebuildable. It carries the active intent id and
+intent line, the current lifecycle stage (the last savepoint line, else the stage derived from
+which lifecycle files exist), the cycle role, and the honoring instruction that the agent must
+emit valid lifecycle artifacts and not hallucinate intents or stages. This is the standard L2
+live-state mechanism for harnesses whose spawned sub-agents do not inherit the top-level
+session event. See [`harness-adapters.md`](https://github.com/zalom/plastic/blob/main/docs/reference/harness-adapters.md) for how it slots into the per-harness contract.
 
 ### Completion Reports
 
-Every dispatched specialist ends its turn with a structured completion report as its final
-message (its return value), so the agent that did the work is the one that accounts for it. The
-report carries a common envelope plus a role-specific payload that fulfils the agent's place in
-the cycle; the planner explains the plan back to the orchestrator, the executor reports what was
-built and the test result, and so on. The format lives in `references/agent-report-contract.md`,
-and the verbatim instruction is injected once via the spawn preamble's `REPORT_CONTRACT`
-constant, which the role prompts reproduce.
+Every dispatched agent ends its turn with a structured completion report as its final message
+(its return value), so the agent that did the work is the one that accounts for it. The report
+carries a common envelope plus a role-specific payload that fulfils the agent's place in the
+cycle; the executor reports what was built and the test result, a reviewer reports its verdict
+and findings. The format lives in `references/agent-report-contract.md`, and the verbatim
+instruction is injected once via the spawn preamble's `REPORT_CONTRACT` constant, which the
+role prompts reproduce.
 
 Enforcement is require-report then synthesize-fallback. The preamble and prompts make the report
 mandatory (decision-shaping), but child-agent honor is best-effort across harnesses (Tier B/C),
-so it is never a hard block. When a specialist returns no usable report, the enforcer runs
+so it is never a hard block. When an agent returns no usable report, the lead runs
 `scripts/agent-report <intent_dir> --role <role>`, a pure function of the intent dir (no network,
 clock, or randomness, mirroring `spawn-preamble`) that emits a filesystem-derived report from the
 savepoint, the artifacts present, the checklist checked/total, and the outcome line. A handoff
@@ -81,77 +79,82 @@ account therefore always exists: agent-authored when present, deterministically
 otherwise. This structures the finish notification only; in-flight observations stay in
 `## Insights`, no progress chatter is added.
 
-Immediately after a specialist returns and before the next handoff, the enforcer records the
+Immediately after an agent returns and before the next handoff, the lead records the
 delegate's activity through `plastic-lock delegate --intent-dir <intent-dir> --delegate <id>
 --status finished|failed`. `finished` requires a usable agent-authored or synthesized completion
 report. A blocked or errored return, or one with no report that can be synthesized, is `failed`
 and stops the handoff under the normal error procedure. Activity status is descriptive and does
 not revoke the registered delegate's authorization.
 
-### Gate Ownership
+### Review Ownership
 
-The enforcer arms and verifies the lifecycle gate, then gates every stage transition.
-It never delegates gate ownership. At the final gate only, it dispatches an
-INDEPENDENT reviewer subagent to review the delivered work. That reviewer is not a
-permanent sixth role, it exists only for the final review.
+The lead owns every review decision: it dispatches the plan reviewer before code, folds the
+findings itself, and decides from the risk rule whether the post-execution reviewer runs. It
+never delegates that decision, and neither reviewer is ever the maker of what it reviews.
+Nothing blocks a write in 2.0 (the gate hooks were removed, intent 302); the lock, the
+worktree, and the record are how the team keeps one delivery in one place.
 
-### Headless Manual Gate
+### The risk list
 
-When running headless or in the background, the enforcer enforces gates manually rather
-than relying on hooks alone. The savepoint ledger and PostToolUse gate hook still fire
-(the gate hook reads `session_id` from stdin; the savepoint write is path-derived and
-bridge-independent), so they do not blanket no-op. Only the bridge-keyed stage-enforcement
-step degrades when no session id reaches the bridge and no bridge is discovered. The
-enforcer arms via `CLAUDE_CODE_SESSION_ID` or the bridge's derived-key fallback and
-verifies state itself.
+The post-execution reviewer runs when the executor's diff touches any of these paths, or when
+the auto skill's other two risk clauses fire:
+
+- `hooks/`, `scripts/hook-*`, `scripts/lib/hook_registry.rb`
+- `scripts/lib/lock.rb`, `scripts/lib/arm.rb`, `scripts/plastic-lock`, `scripts/end-intent`
+- `scripts/lib/installer_core.rb`, `scripts/install*`, `scripts/update.rb`
+- `package.json`, `.claude-plugin/*.json`, `CHANGELOG.md`
+
+Grow this list here, not in the skill body.
+
+### Headless Note
+
+In a headless or background run the session id may be unset. `plastic-lock arm` then keys the
+lock by a derived session key, the record hook still writes the savepoint ledger from the
+written path, and the lead verifies state from the files (`plastic-lock status`,
+`savepoint.md`, the diff) rather than from a hook it assumes fired.
 
 ### Delegation
 
-The roles are thin handoff contracts, not a spawning engine. Dispatch and review run
-by default through Plastic's own engine, `plastic-intent-executing` (implementer plus
-two-stage review, no external plugin). When `superpowers:subagent-driven-development`
-and `superpowers:dispatching-parallel-agents` are available, or the user asks for them,
-they delegate to those as an enhancement. The team model defines who hands what to whom
-and where the gates sit; the dispatch engine, native or superpowers, does the actual
-spawning.
+The roles are thin handoff contracts, not a spawning engine. Dispatch runs through Plastic's
+own engine, `plastic-intent-executing`: one executor for the consolidated action, the two
+reviewer prompts as fresh agents. The team model defines who hands what to whom and where the
+reviews sit; the engine does the actual spawning.
 
 ### Fallback by Case
 
-The default is always Plastic's native engine, so a user without superpowers still gets
-the full behavior. If the harness supports subagents but superpowers is absent, auto
-mode dispatches through `plastic-intent-executing`. If the harness has no subagent dispatch
-at all, auto mode falls back to a single agent walking the full What, Why, How, Exec
-cycle itself. The enforcer's gate discipline still applies in every case.
+If the harness supports agent dispatch, auto mode dispatches through
+`plastic-intent-executing`. If the harness has no agent dispatch at all (Codex CLI today), the
+lead walks the five steps itself: it still writes the matrix and the tests first, and reviews
+its own plan against the matrix before code, saying so in `## Insights`.
 
 ### Dogfood Proof
 
-Intents 60, 61, and 62 were delivered by exactly this enforcer-led team on a shared
-branch, which is the dogfooded proof that the model works end to end.
+Intents 60, 61, and 62 were delivered by the enforcer-led team on a shared branch, and the
+simplify-plastic roadmap's batch 2 (intents 302 to 306) was delivered in the ruled two-boot
+shape: the lead wrote the matrix, one adversarial plan reviewer read it, the lead built inline
+tests first, one suite run per intent.
 
 ## Two Modes
 
-- **Human-driven:** Human chats with the Main Orchestrator, creates intents,
-  brainstorms, then the Main Orchestrator dispatches Project Orchestrators and teams
-  for execution.
-- **Autonomous:** Human gives the Main Orchestrator a starting intent with defined
-  outcomes. The enforcer-led team runs the full cycle (the specialists do the
-  lifecycle, the enforcer reviews Insights and gates), then the orchestrator spawns
-  next intents and dispatches again.
+- **Human-driven:** Human chats with the Main Orchestrator, creates intents, thinks them
+  through, then the Main Orchestrator dispatches Project Orchestrators and teams for execution.
+- **Autonomous:** Human gives the Main Orchestrator a starting intent with defined outcomes.
+  The auto team runs the full cycle, then the orchestrator spawns next intents and dispatches
+  again.
 
 ## Autonomous Delivery
 
-Human owns What and Why for human-initiated intents. The team assists (research,
-exploration) but the human drives until handoff. When Why is complete, or the human
-triggers `plastic-auto`, the enforcer-led team takes over How and Exec autonomously.
-
-- **Safe-by-default:** the executor always prefers non-destructive routes (rename vs
-  delete, additive migrations, backups before changes). Destructive actions on
-  existing projects require human approval unless `--skip-permissions` is set.
-- **Notification only on:** finish or hard stop (blocked on destructive action,
-  unresolvable error). No progress reports, `## Insights` tracks everything.
-- **Greenfield autonomy:** during initial project creation, all decisions are
-  non-destructive (nothing to destroy), so the team has full autonomy for greenfield
-  choices.
+Human owns What and Why for human-initiated intents. The team assists (research, exploration)
+but the human drives until handoff. When Why is complete, or the human triggers `plastic-auto`,
+the auto team takes over How and Exec autonomously.
+
+- **Safe-by-default:** the executor always prefers non-destructive routes (rename vs delete,
+  additive migrations, backups before changes). Destructive actions on existing projects
+  require human approval unless `--skip-permissions` is set.
+- **Notification only on:** the How briefing, finish, or hard stop (blocked on destructive
+  action, unresolvable error). No progress reports, `## Insights` tracks everything.
+- **Greenfield autonomy:** during initial project creation, all decisions are non-destructive
+  (nothing to destroy), so the team has full autonomy for greenfield choices.
 - **Autonomous decisions** are logged in `## Insights` with the `(autonomous)` marker.
 
 ## Coordinator Loop
@@ -162,4 +165,13 @@ When "work on Project X":
 3. Load project config (overrides)
 4. Load global INDEX.md, find hub intents tagged `project-<name>`
 5. Load project INDEX.md, find tactical intents
-6. The coordinator has the full picture, spins up an enforcer-led team per intent
+6. The coordinator has the full picture, leads an auto team per intent
+
+## Spawn preamble (intent 152)
+
+`scripts/spawn-preamble` emits a live-state block purely from filesystem state: the active
+intent, stage, role/cycle-step, the honor instruction, and the report contract. When the
+intent's code worktree is resolvable and exists on disk, it also appends the worktree's
+absolute path plus a verbatim instruction to `cd` there directly, for harnesses whose
+`EnterWorktree` cannot discover a nested repo from a non-repo launch directory. Output is
+byte-identical when no worktree resolves.

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

@@ -29,7 +29,7 @@ fields stay exactly as below); it does not remove any required field.
 
 Every role report, whatever the stage, carries these fields:
 
-- **Role**: which specialist produced this (brainstorming, spec, planner, executor, reviewer).
+- **Role**: which agent produced this (executor, plan reviewer, post-execution reviewer).
 - **Intent id and stage**: the active intent id and the cycle stage just completed.
 - **Status**: `delivered` or `blocked`.
 - **Artifacts written**: the files produced or changed (store paths, and project paths for the
@@ -53,26 +53,9 @@ Multi-item payload fields (ordered actions, insights, checklist deltas) default
 Each role appends a payload that fulfils its place in the What, Why, How, Exec cycle (decision
 D2). The payload is what makes the report useful to the orchestrator beyond the envelope.
 
-### brainstorming (Why exploration)
-- Decisions recorded in `### Decisions`, each with its one-line rationale.
-- Context enriched: what was researched and the key findings.
-- Open questions resolved, and any deliberately left for the spec.
-- Insights: durable discoveries from the Why exploration, reported in the `insights:` field.
-
-### spec-specialist (Why to How boundary)
-- Spec sections produced (Problem, Goals, Non-Goals, Approach, Decisions, Acceptance Criteria).
-- How the recorded decisions resolved into the chosen approach.
-- Acceptance-criteria count, so the planner knows the surface to cover.
-- Insights: durable discoveries from consolidating the spec, reported in the `insights:` field.
-
-### planner (How): worked exemplar
-The planner report EXPLAINS THE PLAN BACK TO THE ORCHESTRATOR. It carries:
-- The ordered actions, one line each: what the action does and how it is verified.
-- Decomposition rationale: why this order, and why the actions are independent.
-- Checklist coverage: item count and that every action plus suite-green is covered.
-This is the exemplar because the plan is an argument, and the orchestrator gates on whether that
-argument is sound before any code is written.
-- Insights: durable discoveries from planning, reported in the `insights:` field.
+The stage-agent role sections (brainstorming, spec-specialist, planner) were removed in 2.0
+(intent 304): the orchestrator writes the Why and How artifacts itself and reports nothing to
+itself. Two dispatched roles remain.
 
 ### executor (Exec)
 - Actions implemented this turn, mapped to checklist items checked off (checked / total).

package/skills/auto/references/end-tail.md

@@ -1,72 +1,66 @@
-# End-Tail Mechanics: resolve_session and Disarm Ordering
+# End-Tail Mechanics: Arm.disarm and the Ordering
 
-Deep WHY/mechanics detail behind two spots in `SKILL.md`: how `arm_auto` resolves a
-session id when arming the gate, and why the End-tail steps in Completion (release
-worktrees, clear the lock, purge the bridge, reindex) run in that exact order.
+Deep mechanics behind two spots in `SKILL.md`: how `plastic-lock arm` resolves a session id
+when it takes an intent, and why the End-tail steps in Completion (release the worktree, clear
+the lock, reset the pointer, reindex) run in that exact order. The `/tmp` bridge JSON these
+steps once also purged was removed in 2.0 (intent 307); `scripts/lib/arm.rb` is what remains.
 
 ## Table of Contents
 
-- [resolve_session fallback internals](#resolve_session-fallback-internals)
+- [Session resolution](#session-resolution)
 - [Disarm ordering and worktree cleanup rationale](#disarm-ordering-and-worktree-cleanup-rationale)
 - [QMD reindex ordering rationale](#qmd-reindex-ordering-rationale)
 
-## resolve_session fallback internals
+## Session resolution
 
-`arm_auto` calls `resolve_session`, which picks the first non-empty of: the explicit
-id you pass -> `CLAUDE_CODE_SESSION_ID` -> a deterministic derived key (a hash of the
-store and intent id). It never returns nil, so the gate engages even when every
-session env var is empty; the call never needs a non-empty session env var to
-function. Arming prints a one-line notice to stderr when it falls through to the
-derived key.
+`Arm.resolve_session` picks the first non-empty of: the explicit id (`--session`, or the hook
+stdin `session_id` when a caller has it), the `CLAUDE_CODE_SESSION_ID` the CLI read, then a
+deterministic derived key (a hash of the store and the intent id). It never returns nil, so
+the arm verb works even when every session variable is empty; a session-less arm and a later
+session-less close resolve to the same key.
 
-Arming acquires the durable `delivery.lock` in the intent dir, keyed by that resolved
-session. Ownership is session-keyed, not process-keyed, so the arm one-liner exiting
-immediately is fine by construction: the lock stays yours for every later tool call in
-this session. A failed arm raises with a message naming the resolving `plastic-lock`
-verb.
+Arming acquires the durable `delivery.lock` in the intent dir, keyed by that resolved session
+and stamped with `run_mode`. Ownership is session-keyed, not process-keyed, so the arm command
+exiting is fine by construction: the lock stays yours for every later tool call in this
+session, and the record hook refreshes its lease on every write you make. The same call writes
+the intent id into the session pointer (`~/.plastic/store/.tmp/<session>/current`), which is
+why the capture and record hooks stop treating your prompts as day-ledger items for the rest
+of the delivery.
 
 ## Disarm ordering and worktree cleanup rationale
 
-Disarm runs the ordered End tail: it releases the worktrees first, then clears the
-intent's `delivery.lock` (and the bridge's lock cache), and only then is the bridge
-purge-eligible. Disarming also purges stale bridge files from the temp directory
-automatically (it keeps the current bridge, any live run, and any bridge whose intent
-still holds a delivery lock), so no manual `/tmp` cleanup is needed.
+`Arm.disarm` runs the ordered End tail: it releases the worktree first, then clears the
+intent's `delivery.lock` as its recorded owner, and only then resets the session pointer to
+today's day id (when it still names this intent). The worktree goes first so a released lock
+never points at a checkout another session could claim; the pointer goes last so the record
+hook keeps heartbeating the lock until the lock is gone.
 
-**Mechanized since intent 188.** `scripts/end-intent` performs this disarm itself, as its
-own step 5, after steps 1-4 (outcome/INDEX/savepoint/commit) commit. No agent needs to run
-a separate `Bridge.disarm_auto` one-liner any more on the auto mode / curator path: the
-single `end-intent` call in `SKILL.md`'s Completion section already does it. A pre-flight
-lock guard (before anything is written) refuses on a live foreign session (exit 4) and
-reclaims a stale foreign lock automatically (audited to savepoint.md); a dirty code
-worktree refuses before removal (exit 5, `--discard-worktree-changes` overrides
-deliberately); and the durable lock file is checked again after disarm, never merely
-trusted (exit 3 if it is somehow still present).
+**Mechanized since intent 188.** `scripts/end-intent` performs this disarm itself, as its own
+step 5, after steps 1-4 (outcome/INDEX/savepoint/commit) commit. A pre-flight lock guard
+refuses on a live foreign session (exit 4) and reclaims a stale foreign lock automatically
+(audited to savepoint.md); a dirty code worktree refuses before removal (exit 5,
+`--discard-worktree-changes` overrides deliberately); and the durable lock file is checked
+again after disarm, never merely trusted (exit 3 if it is somehow still present).
 
-**Worktree cleanup (mandatory, intent 73c3).** `end-intent`'s step 5 calls
-`Bridge.disarm_auto` by default, which calls `Worktree.release`, which removes the
-intent's code worktree under `<repo>/.claude/worktrees/{id}--{slug}`, prunes the repo, and
-clears the worktree block from the bridge. (Plastic used to also provision a paired store
-worktree under `<plastic_home>/.worktrees/{id}--{slug}`; intent 178 retired it, since
-lifecycle-doc writes go straight to the main store checkout, and intent 197's
-branch-from-main plus scoped commit already gives them their own write safety.) This is the
-plain remove path: the disarm route does NOT merge, so use it only when no release merges
-the branch (the branch survives and can be reclaimed).
+**Worktree cleanup (mandatory, intent 73c3).** `end-intent`'s step 5 calls `Arm.disarm` by
+default, which calls `Worktree.release` on the block `Arm.worktree_block` derives from
+`projects.yml` and the intent id, removing the intent's code worktree under
+`<repo>/.claude/worktrees/{id}--{slug}` and pruning the repo. This is the plain remove path:
+the disarm route does NOT merge, so use it only when no release merges the branch (the branch
+survives and can be reclaimed).
 
 When the work is being shipped through a release, do NOT rely on this plain remove.
-`skills/releasing/SKILL.md` reorders its own two steps for exactly this reason (intent 188,
-D7): its worktree-merge step now runs BEFORE its `end-intent` call, merging the intent's
-code branch (`plastic/{id}--{slug}`) back to the repo's default branch BEFORE the worktree
-is removed, via `Worktree.finish(bridge_data, merge: true)` (merge-then-remove), so the
-integrated work is not lost. By the time `end-intent`'s own step 5 runs afterward, the
-worktree is already gone (a harmless no-op) and only the delivery lock is left to clear,
-correctly, for the first time on that path. Never leave an orphaned worktree, and run
-`git worktree prune` if you hit a stale reference.
+`skills/releasing/SKILL.md` runs its worktree-merge step BEFORE its `end-intent` call, merging
+the intent's code branch (`plastic/{id}--{slug}`) back to the repo's default branch BEFORE
+the worktree is removed, via `Worktree.finish(Arm.bridge_hash(intent_dir: ...), merge: true)`
+(merge-then-remove), so the integrated work is not lost. By the time `end-intent`'s own step 5
+runs afterward, the worktree is already gone (a harmless no-op) and only the delivery lock and
+the pointer are left to clear. Never leave an orphaned worktree, and run `git worktree prune`
+if you hit a stale reference.
 
 ## QMD reindex ordering rationale
 
-Completion is the lifecycle event that keeps the search index fresh. `<store-root>` is
-the store that holds this intent (the global store or the project store). The reindex is
-the LAST End-tail step, run after purge, so the index never references a bridge or lock
-that is about to disappear (see PLASTIC.md `## Delivery Isolation and the Single-Owner
-Lock`).
+Completion is the lifecycle event that keeps the search index fresh. `<store-root>` is the
+store that holds this intent (the global store or the project store). The reindex is the LAST
+End-tail step, run after the disarm, so the index never references a lock that is about to
+disappear.

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

@@ -1,8 +1,8 @@
 # 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
+(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.
 
@@ -30,12 +30,12 @@ short. The words can flex to fit the stage.
 - **Done**: State = the delivered impact. Risk = residual risk. Call = the decision left to you
   (merge, release, accept).
 
-## Depth at Tier S
+## Depth for small work
 
-At Tier S in auto mode the mid-flight briefings collapse to one. Only the How briefing fires, and
+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. M and L
-send all four. The shape does not change: still State, then Risk, then Call, and the per-stage
+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.
 
@@ -66,7 +66,7 @@ Apply the `writing-style` skill for the wording.
 In guided mode, the briefing lands at each stage boundary and the human acts on the Call line
 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
+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).

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