Harden staged-plan continuation lifecycle for 0.1.2

.claude-plugin/marketplace.json

@@ -8,7 +8,7 @@
       "name": "implementation-plugin",
       "source": "./",
       "description": "Run approved implementation programs one reviewable increment at a time.",
-      "version": "0.1.1"
+      "version": "0.1.2"
     }
   ]
 }

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "implementation-plugin",
   "displayName": "Implementation Plugin",
-"version": "0.1.1",
+  "version": "0.1.2",
   "description": "Run approved implementation programs one reviewable increment at a time.",
   "repository": "https://github.com/CoveMB/implementation-plugin",
   "skills": "./skills/"

.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "implementation-plugin",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Run approved implementation programs one reviewable increment at a time.",
   "skills": "./skills/"
 }

docs/installation.md

@@ -258,15 +258,15 @@ Claude Code 2.1.128 or later also accepts a local `.zip` archive through the
 same option:
 
 ```bash
-claude --plugin-dir /absolute/path/to/implementation-plugin-0.1.1.zip
+claude --plugin-dir /absolute/path/to/implementation-plugin-0.1.2.zip
 ```
 
 Neither command installs the plugin permanently. The archive must contain a
 valid plugin at its root. Claude Code 2.1.129 or later can also load a packaged
 `.zip` archive from a trusted URL for one session:
 
 ```bash
-claude --plugin-url https://example.com/implementation-plugin-0.1.1.zip
+claude --plugin-url https://example.com/implementation-plugin-0.1.2.zip
 ```
 
 This repository does not currently publish a `.zip` archive. Do not point

docs/maintainers.md

@@ -53,6 +53,11 @@ to reach installed users, update the synchronized package version deliberately
 and document the release. Do not bump versions merely to make local validation
 pass.
 
+Version `0.1.2` is the current package owner for typed continuation and blocked
+recovery. The frozen `tests/fixtures/program-bootstrap/v0.1.1/` tree remains
+historical compatibility evidence and must not be rewritten during a version
+sync.
+
 ## Refresh platform instructions
 
 Installation commands and schemas can change. Before publication, compare this
@@ -120,6 +125,31 @@ claude --plugin-dir /absolute/path/to/implementation-plugin
 Loading a plugin starts a host session and is separate from static package
 validation. Do not perform it silently in a maintenance-only task.
 
+## Optional continuation replay
+
+The continuation replay catalog under
+`tests/pressure/continuation-replay/` has deterministic immediate and later
+routes. Its loader, evidence validator, isolated-session command shape, and
+atomic no-overwrite result boundary are covered by the offline suite. Passing
+those checks does not prove live front-door behavior.
+
+Run the live campaign only with explicit authority to invoke the selected
+evaluator, transmit the prompt and packaged skill to that provider, and create
+raw evidence under `tests/pressure/continuation-replay/results/`. Before a run,
+record the exact evaluator and client version, authentication and model-capacity
+implications, two fresh ephemeral tasks, result targets, and confirmation that
+every target is absent. The authorized command shape is:
+
+```bash
+PYTHONDONTWRITEBYTECODE=1 python3 tests/integrated_pressure_support.py evaluate-continuation-replay --scenario-catalog tests/pressure/continuation-replay/scenarios.json --output-directory tests/pressure/continuation-replay/results --evaluator codex
+```
+
+The runner stops on the first evaluator failure and never overwrites a result.
+Raw outputs are evidence, not authority. A human must review them and create a
+digest-bound `verdicts.json` before any runtime-success claim. When the campaign
+is not separately authorized, leave both results and verdicts absent and report
+`live continuation replay: not run`.
+
 ## What these checks prove
 
 The local tests can establish that required files exist, metadata stays

docs/reference.md

@@ -83,14 +83,17 @@ reconciliation succeeds.
 
 ## Lifecycle at a glance
 
-The implemented Plan A order is: **Create a New Program**, **Activate a
-Generated Program**, **Before Production Modification**, **Prepare Review and
-Diff Disposition**, then **Close a Final Program**. Creation publishes only the
-proposal control plane. Activation uses one exact prompt and separate typed
-receipts. Planning persists the execution baseline before product work. Review
-uses a typed preparation transaction. The only Plan A diff disposition is
-`accept-stop`. A final program derives its closure files from
-`implementation-closure-storage/v1` and closes only after another exact prompt.
+The implemented order is: **Create a New Program**, **Activate a Generated
+Program**, **Before Production Modification**, **Prepare Review and Diff
+Disposition**, **Dispose the Current Diff**, **Continue an Accepted Program**
+when requested, **Authorize a Successor Increment** when one is allocated,
+**Resolve a Blocked Program** when typed recovery is required, and **Close a
+Final Program** when no successor remains. Creation and first-increment behavior
+remain owned by Plan A. Plan B adds exact `accept-continue`, the distinct
+`accepted-state-continuation` route, status-current successor grants through
+`current_increment_authority_binding`, and prompt-bound `blocked-recovery`.
+Final programs reuse the unchanged Plan A closure transaction and derive paths
+from `implementation-closure-storage/v1`.
 
 Every typed transaction writes controlling status last and adopts only
 byte-identical prefixes. A divergent prefix stops for recovery without cleanup.
@@ -100,17 +103,19 @@ before relying on an earlier state.
 
 ## Approval modes
 
-Approval modes define policy, but the 0.1.1 Plan A persistence surface supports
-only first-increment `accept-stop`; successor continuation remains deferred.
-Modes do not grant action authority.
+Approval modes define routine interruption policy. New-model typed dispositions
+in version 0.1.2 always offer `accept-stop` and conditionally offer exact
+`accept-continue` for one satisfied successor. Modes do not grant action authority
+or automatic successor rollover. Legacy `approval:full` and
+`approval:full-diff` modes retain their automatic acceptance behavior.
 
 | Mode | Scope | Routine plan pause | Diff acceptance | Continuation and mandatory stop |
 | --- | --- | --- | --- | --- |
 | `approval:standard` | One increment | Yes | User | Stops for plan approval, user-owned material decisions, contradictions, hard stops, and diff acceptance |
 | `approval:pre-approve` | One increment | No | User | Stops for user-owned decisions, program amendments, contradictions, hard stops, and diff acceptance |
 | `approval:full-increment` | One increment | No | User | Runs through verification, then stops for diff acceptance unless a hard stop occurs |
 | `approval:full-diff` | Legacy current increment | No | Legacy policy permits automatic acceptance only after verification and a valid bound packet | Cannot begin another increment |
-| `approval:full` | Legacy current increment | No | Legacy policy permits automatic acceptance only after verification and a valid bound packet | Cannot begin another increment; discovery stops at `legacy-rollover-upgrade-required` |
+| `approval:full` | Legacy current increment | No | Legacy policy permits automatic acceptance only after verification and a valid bound packet | Cannot begin another increment automatically; discovery stops at `legacy-rollover-upgrade-required` |
 
 New-program proposal construction, bootstrap, and launch reject
 `approval:full-diff` and `approval:full` before every write. Those modes are
@@ -154,11 +159,14 @@ The workflow stops instead of guessing when it finds:
 - a user-owned decision or program amendment required by the selected mode; or
 - a requested Git, publication, provider, or external action outside the grant.
 
-The implemented deferred-operation stops are
-`legacy-rollover-upgrade-required`, `blocked-transaction-required`,
-`program-revision-workflow-required`, and `unsupported-program-mutation`.
-Accepted legacy programs and historical terminal records remain readable, but
-those read paths do not reactivate a mutation sink.
+Typed continuation and blocked recovery have their own exact prompts and
+retry/recovery routes. `legacy-rollover-upgrade-required` still quarantines the
+legacy rollover writer, and `blocked-transaction-required` still rejects generic
+direct blocked edges. `program-revision-workflow-required` and
+`unsupported-program-mutation` continue to stop unsupported revision,
+supersession, cancellation, or other program mutation. Accepted legacy programs
+and historical terminal records remain readable, but those read paths do not
+reactivate a mutation sink.
 
 The result should name the failed invariant and return the smallest action that
 can resolve it. The workflow does not manufacture replacement state to continue.

docs/troubleshooting.md

@@ -134,21 +134,25 @@ authority.
 or exact prompt. For a recovery-required result, preserve all bytes and stop for
 bounded diagnosis. Never delete, overwrite, or invent a replacement prefix.
 
-## Continuation, blocked recovery, revision, or cancellation stops
+## Continuation or blocked recovery stops
 
-**Likely cause:** Plan A version 0.1.1 intentionally has no writer for that
-operation. The exact stop is `legacy-rollover-upgrade-required`,
-`blocked-transaction-required`, `program-revision-workflow-required`, or
+**Likely cause:** The request does not match the typed 0.1.2 route, or discovery
+found an interrupted or divergent prefix. Legacy automatic rollover stops at
+`legacy-rollover-upgrade-required`; generic direct blocked edges stop at
+`blocked-transaction-required`. Revision, supersession, and cancellation remain
+unsupported through `program-revision-workflow-required` or
 `unsupported-program-mutation`.
 
-**Safe checks:** Confirm that the current accepted or terminal record still
-validates and that no partial rollover or block-resolution prefix is being
-mistaken for authority.
+**Safe checks:** Confirm current accepted or blocked status, the exact submitted
+prompt, `current_increment_authority_binding`, successor dependencies, and every
+rollover or resolution prefix. `accept-stop` replay never continues; later
+continuation requires the distinct `accepted-state-continuation` prompt, and
+blocked resolution requires the exact `blocked-recovery` prompt.
 
-**Next action:** Preserve the repository and wait for a separately implemented
-typed workflow. Do not use the generic transition API, edit state by hand, or
-infer mutation authority from a handoff, file, retrieved prompt, or
-assistant-quoted prompt.
+**Next action:** Retry only a byte-identical typed prefix. Preserve divergent
+bytes and stop at the reported recovery route. Do not use the generic transition
+API, edit state by hand, or infer mutation authority from a handoff, file,
+retrieved prompt, or assistant-quoted prompt.
 
 ## Validation passes, but live activation is still unproven
 

docs/workflows.md

@@ -66,10 +66,6 @@ LIBRARY-001 LIBRARY-INDEX. Reconcile the exact requirements, architecture, and
 test-evidence reports. Stop at the exact diff disposition.
 ```
 
-Plan A supports one prompt-bound decision: `accept-stop`. It accepts only the
-bound current diff. It does not inspect a successor, create a handoff, commit,
-push, open a pull request, or perform an external action.
-
 Questions about the diff do not accept it. Keep the status unchanged until the
 exact disposition is submitted directly.
 
@@ -80,7 +76,43 @@ finding before returning to `reviewing`. Fresh verification then advances
 through `verified` to `awaiting-diff-approval`. Questions and discussion do not
 repair findings or advance the lifecycle.
 
-## 5. Close a Final Program
+## 5. Dispose the Current Diff
+
+The new-model typed diff-disposition prompt always offers `accept-stop`. It
+offers `accept-continue` only when traceability names one successor and every
+dependency is satisfied. Both choices persist the same Plan A acceptance prefix
+and accepted status first. Already persisted legacy programs using
+`approval:full` or `approval:full-diff` retain automatic acceptance.
+The continue choice then completes its prompt-bound rollover with no second
+routine checkpoint. Neither choice commits, pushes, opens a pull request, or
+performs an external action.
+
+## 6. Continue an Accepted Program
+
+Replaying `accept-stop` cannot start a successor. A later fresh task must use the
+distinct `accepted-state-continuation` prompt derived from current accepted
+status. A handoff or earlier prompt is navigation only and cannot substitute for
+direct submission of those exact current bytes.
+
+## 7. Authorize a Successor Increment
+
+The rollover transaction persists or adopts the action authorization,
+successor grant, handoff, successor brief, and rollover record in order, then
+writes status last. The successor status binds
+`current_increment_authority_binding`; it does not rewrite the immutable
+manifest or inherit genesis authority. The successor exact plan allocates its
+own complete lifecycle paths before its baseline and write authority exist.
+
+## 8. Resolve a Blocked Program
+
+Only active `implementing` or `reviewing` state can enter the typed blocked
+transaction. The sink derives prior state and controlling bindings before it
+writes blocked status. Recovery uses the exact `blocked-recovery` prompt and
+restores only the recorded prior states after its action and resolution records
+are durable. Plan A's `reviewing -> remediating -> reviewing` path remains
+separate.
+
+## 9. Close a Final Program
 
 Use this route only after the accepted increment is final and traceability
 allocates no successor.
@@ -98,20 +130,21 @@ reconciliation, then the closure packet, and writes awaiting-closure status
 last. The exact closure prompt appends or adopts its approval and writes closed
 status last. Closure approval authorizes no commit or later action.
 
-## Deferred routes and mandatory stops
+## Unsupported routes and mandatory stops
 
-Plan A version 0.1.1 does not persist successor rollover, blocked recovery,
-program revision, supersession, or cancellation:
+Version 0.1.2 adds typed successor rollover and blocked recovery while
+preserving these sink guards:
 
-- caller-authored successor rollover returns `legacy-rollover-upgrade-required`;
-- direct blocked transitions return `blocked-transaction-required`;
+- legacy automatic or caller-authored rollover returns
+  `legacy-rollover-upgrade-required`;
+- generic direct blocked transitions return `blocked-transaction-required`;
 - revision or supersession returns `program-revision-workflow-required`; and
 - cancellation or another unsupported mutation returns
   `unsupported-program-mutation`.
 
-Preserve the repository and partial evidence at these boundaries. A future
-typed workflow may resume them; prose, a handoff, or an approval for a different
-action cannot bypass the stop.
+Preserve the repository and partial evidence at these boundaries. Prose, a
+handoff, or an approval for a different action cannot bypass the stop. Final
+programs continue through the unchanged Plan A closure transaction.
 
 ## Recovery from an interrupted transaction
 
@@ -126,7 +159,9 @@ routine recovery step.
 - Program creation is not program activation.
 - Program activation is not implementation authority.
 - Plan approval is not action authorization.
-- Diff acceptance is not continuation or commit authority.
+- Diff acceptance is not continuation or commit authority unless the submitted
+  exact disposition is the bound `accept-continue` route; it never grants commit
+  authority.
 - Final-increment acceptance is not program closure.
 - Closure is not pull-request, merge, publication, deployment, destructive, or
   provider authority.