oacp-cli 0.4.2__tar.gz → 0.4.3__tar.gz

{oacp_cli-0.4.2 → oacp_cli-0.4.3}/.github/workflows/release.yml

@@ -102,7 +102,7 @@ jobs:
 
       - name: Publish to PyPI
         if: steps.check-pypi-version.outputs.version_exists != 'true'
-        uses: pypa/gh-action-pypi-publish@ed0c53931b1dc9bd32cbe73a98c7f6766f8a527e # v1.13.0
+        uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33 # v1.14.2
 
       - name: Skip duplicate PyPI publish
         if: steps.check-pypi-version.outputs.version_exists == 'true'

{oacp_cli-0.4.2 → oacp_cli-0.4.3}/.gitignore

@@ -4,7 +4,8 @@
 AGENTS.md
 CLAUDE.md
 GEMINI.md
-.claude/skills/
+.claude/
+.codex/
 .worktrees/
 __pycache__/
 *.pyc

{oacp_cli-0.4.2 → oacp_cli-0.4.3}/CHANGELOG.md

@@ -5,6 +5,66 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.4.3] - 2026-08-12
+
+### Added
+
+- Review-loop continuation grants: a human-approved
+  `approved_thread_continuation` may carry a `review_loop` scope (one
+  repository, PR, and sender thread; allowed lifecycle types; a round
+  ceiling; wall-clock expiry; permitted review side effects) so in-scope
+  same-thread follow-up review rounds auto-invoke the reviewer. A grant
+  authorizes running a round, never its verdict — the live PR head stays
+  authoritative, with declared heads compared by exact full-SHA equality.
+  Expiry and revocation bind at evaluation time, approvals never authorize
+  retroactively, only rounds that actually ran consume the round budget,
+  the accepted side-effect set binds the invocation, and out-of-scope
+  requests pause. Receiver config enables recognition only; authority
+  exists solely in prior human-approved grant audits. Adds the
+  `review_continuation` audit block, pinned `review_continuation_*` and
+  `review_loop_invalid` reason codes, and a conformance fixture set; full
+  semantics in `docs/protocol/autonomy.md` and
+  `docs/protocol/review_loop.md`.
+- Checkpoint re-authorization is now specified end to end: three pinned
+  answer channels — receiver-side human, signature-verified sender reply
+  bounded by the receiver's own admission policy, GitHub comments as
+  advisory-only — with rank, never arrival order, deciding conflicts. A
+  consumption rule binds each answer to the pause it clears: scope-less
+  approvals clear one checkpoint, scoped numeric budgets stand for the
+  rest of the task up to the granted value, and boundary-action grants
+  durably authorize one granular capability until task completion. The
+  audit surface separates the requested scope from the effective
+  policy-capped grant, with pinned reason codes `checkpoint_reauthorized`
+  and `checkpoint_reauthorization_stale` and a conformance fixture set.
+- `oacp session-init` now supports Codex `SessionStart` JSON, a bounded and
+  truthful ordered-read manifest, optional pull-before-verify memory sync, and
+  active-model/cwd input from the hook payload. `oacp setup codex` safely
+  merges one startup-only handler into `.codex/hooks.json`; users review and
+  trust the definition with `/hooks`.
+- Project-wide message-history retention through `oacp retention`: outbox,
+  dead-letter, and processed inbox-archive files are pruned when they exceed
+  either an age or count bound (defaults 30 days and 1,000 files per target),
+  with validated partial overrides in `workspace.json`, deterministic dry-run
+  JSON, and file-identity rechecks before deletion.
+- Processed inbound messages now have one cross-runtime destination,
+  `inbox/archive/`, preserving the original filename and bytes. Quarantine
+  evidence is excluded from automatic pruning by its durable filename format;
+  manually managed fixtures can use adjacent `.retain` markers. Protocol spec
+  version advances to 0.4.3.
+
+### Changed
+
+- Codex startup file states now say `verified` instead of `loaded`: the command
+  confirms readability and updates `status.yaml`, while its hook context tells
+  Codex which files still require ordered reads. Legacy `.agent-hub` project
+  detection has been removed from this Codex path.
+- `oacp setup claude` keeps automatic startup memory pull but no longer creates
+  or registers an automatic `SessionEnd` push. Rerunning setup removes only the
+  exact historical generated registration and leaves any existing script or
+  custom hooks untouched; explicit wrap-up remains the single push path.
+- Session lifecycle documentation now distinguishes coordinator telemetry in
+  `session_lifecycle_state.json` from runtime startup and `status.yaml`.
+
 ## [0.4.2] - 2026-08-07
 
 ### Added
@@ -702,6 +762,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Checkout step in github-release workflow job (#19)
 - Pre-release audit fixes: SHA-pinned actions, dangling doc refs (#15, #16)
 
+[0.4.3]: https://github.com/kiloloop/oacp/compare/v0.4.2...v0.4.3
 [0.4.2]: https://github.com/kiloloop/oacp/compare/v0.4.1...v0.4.2
 [0.4.1]: https://github.com/kiloloop/oacp/compare/v0.4.0...v0.4.1
 [0.4.0]: https://github.com/kiloloop/oacp/compare/v0.3.5...v0.4.0

{oacp_cli-0.4.2 → oacp_cli-0.4.3}/PKG-INFO

@@ -1,6 +1,6 @@
-Metadata-Version: 2.4
+Metadata-Version: 2.5
 Name: oacp-cli
-Version: 0.4.2
+Version: 0.4.3
 Summary: Open Agent Coordination Protocol CLI for file-based multi-agent workflows
 Project-URL: Homepage, https://github.com/kiloloop/oacp
 Project-URL: Repository, https://github.com/kiloloop/oacp
@@ -262,6 +262,7 @@ uv tool install .
 | `oacp inbox` | List pending messages across agents (table or `--json`) |
 | `oacp watch` | Emit inbox delta events for one agent across selected projects |
 | `oacp memory` | Archive, restore, or git-sync project/org memory files |
+| `oacp session-init` | Verify Codex startup inputs, optionally pull memory, and update status |
 | `oacp agent` | Manage global agent profiles (`init`, `show`, `list`) |
 | `oacp org-memory` | Initialize org-level memory at `$OACP_HOME/org-memory/` |
 | `oacp write-event` | Write an event to `org-memory/events/` |
@@ -309,6 +310,9 @@ oacp/
 └── SPEC.md             # Full protocol specification
 ```
 
+[`mcp_servers/`](mcp_servers/) contains experimental, unsupported prototypes;
+it is not part of the OACP product surface.
+
 ## Related
 
 - **[agent-estimate](https://github.com/kiloloop/agent-estimate)** — Estimate how long agent tasks take. Pairs with OACP dispatch for task sizing.

{oacp_cli-0.4.2 → oacp_cli-0.4.3}/QUICKSTART.md

@@ -90,7 +90,6 @@ This creates or updates:
 - `.claude/agents/my-first-project.md`
 - `.claude/skills/`
 - `.claude/hooks/oacp-memory-pull.sh`
-- `.claude/hooks/oacp-memory-push.sh`
 - `.claude/settings.json`
 
 For other supported runtimes, use the same shape:
@@ -101,6 +100,17 @@ oacp setup cursor --project my-first-project
 oacp setup gemini --project my-first-project
 ```
 
+Codex setup creates or merges `.codex/hooks.json` with one startup-only hook.
+Review and trust it with `/hooks`; it runs memory pull and startup verification
+sequentially. If hooks are unavailable, run the manual fallback:
+
+```bash
+oacp session-init --pull-memory --project my-first-project
+```
+
+Runtime setup does not install an automatic memory push. Publish durable memory
+explicitly during wrap-up with `oacp memory push`.
+
 Cursor support is scaffold-only until Cursor-owned rules land. Cursor sessions
 must set `OACP_RUNTIME=cursor` or pass `--from` explicitly when sending messages.
 

{oacp_cli-0.4.2 → oacp_cli-0.4.3}/README.md

@@ -234,6 +234,7 @@ uv tool install .
 | `oacp inbox` | List pending messages across agents (table or `--json`) |
 | `oacp watch` | Emit inbox delta events for one agent across selected projects |
 | `oacp memory` | Archive, restore, or git-sync project/org memory files |
+| `oacp session-init` | Verify Codex startup inputs, optionally pull memory, and update status |
 | `oacp agent` | Manage global agent profiles (`init`, `show`, `list`) |
 | `oacp org-memory` | Initialize org-level memory at `$OACP_HOME/org-memory/` |
 | `oacp write-event` | Write an event to `org-memory/events/` |
@@ -281,6 +282,9 @@ oacp/
 └── SPEC.md             # Full protocol specification
 ```
 
+[`mcp_servers/`](mcp_servers/) contains experimental, unsupported prototypes;
+it is not part of the OACP product surface.
+
 ## Related
 
 - **[agent-estimate](https://github.com/kiloloop/agent-estimate)** — Estimate how long agent tasks take. Pairs with OACP dispatch for task sizing.

{oacp_cli-0.4.2 → oacp_cli-0.4.3}/docs/guides/runtime_capability_matrix.md

@@ -1,10 +1,10 @@
 # Cross-Runtime Parity Matrix
 
-**Date**: 2026-08-03
+**Date**: 2026-08-07
 
 This is a capability comparison across the currently profiled agent runtimes (Claude Code, Codex, Gemini), compiled from each runtime's self-report and current runtime changelogs. Cursor support is scaffold-only until Cursor-owned onboarding lands, so Cursor is intentionally excluded from this comparison table; see `docs/protocol/runtime_capabilities.md` for its conservative scaffold defaults.
 
-Claude was last checked against Claude Code `v2.1.220` (verified in-session 2026-08-03 via `claude --version`) with Claude Fable 5 (`claude-fable-5`, serving model verified in-session on the 1M-context variant). Fable 5 (released 2026-06-09, first Mythos-class model) is now included in Max and Team Premium plan usage as part of the shared weekly limit pool (the launch-window free-inclusion/credit period has ended); the API rate is $10/$50 per MTok. Claude Opus 5 (`claude-opus-5`, released 2026-07-24) is the current Opus tier at $5/$25 per MTok with the same 1M context; Opus 4.8 remains available at the same price and remains the safeguard-fallback target for Fable 5's classifier fallbacks (unchanged by the Opus 5 release).
+Claude was last checked against Claude Code `v2.1.225` (verified in-session 2026-08-07 via `claude --version`) with Claude Fable 5 (`claude-fable-5`, serving model verified in-session on the 1M-context variant). Fable 5 (released 2026-06-09, first Mythos-class model) is now included in Max and Team Premium plan usage as part of the shared weekly limit pool (the launch-window free-inclusion/credit period has ended); the API rate is $10/$50 per MTok. Claude Opus 5 (`claude-opus-5`, released 2026-07-24) is the current Opus tier at $5/$25 per MTok with the same 1M context; Opus 4.8 remains available at the same price and remains the safeguard-fallback target for Fable 5's classifier fallbacks (unchanged by the Opus 5 release).
 
 Codex was last checked against app update `26.727`, stable CLI `0.146.0`, GPT-5.6, and the OpenAI Codex/API changelog entries through 2026-07-30. Runtime availability remains configuration-dependent: standard multi-agent support and memories are stable, while multi-agent V2, token budgets, current-time reminders, and remote Code Mode may still require explicit enablement or experimental configuration.
 
@@ -42,6 +42,7 @@ Codex was last checked against app update `26.727`, stable CLI `0.146.0`, GPT-5.
 | Plan mode                        | Claude, Codex | Claude has structured explore → plan → approve → implement; Codex CLI can move from planning into fresh-context implementation |
 | Auto-compaction                  | Claude        | Context auto-compresses, enabling unlimited session length                   |
 | Cross-session semantic search    | Claude        | MCP-based searchable memory (optional)                                       |
+| Cross-session messaging          | Claude        | SendMessage reaches the user's other Claude Code sessions, including across machines (macOS/Linux), with ListAgents discovery; inbound delivery is configurable (`crossSessionInbound`, `dialogExpiry`) and messages can initiate conversations with Remote Control sessions by name |
 | Browser automation              | Codex, Gemini | Codex Browser/Chrome plugins can click, type, navigate, inspect, and capture approved contexts; Gemini also supports WebP video recording |
 | GPT-5.6 model family            | Codex         | Sol, Terra, and Luna provide task-tier choices with a documented 272K context window |
 | Image generation                 | Codex, Gemini | Codex CLI image generation is enabled by default; Gemini has native `generate_image` |
@@ -51,7 +52,7 @@ Codex was last checked against app update `26.727`, stable CLI `0.146.0`, GPT-5.
 | `apply_patch` editing            | Codex         | Grammar-based file edits                                                     |
 | App-level computer use           | Codex         | macOS app, simulator, and GUI-only workflows; unavailable in EEA, UK, and Switzerland at launch |
 | Windows computer use             | Codex         | Codex app can operate Windows desktop apps in the foreground when available                    |
-| Remote host control              | Codex         | Mobile or desktop remote control can run work on connected Mac or Windows hosts with host-local files, credentials, plugins, skills, and config |
+| Remote host control              | Codex         | Mobile or desktop remote control can run work on connected Mac or Windows hosts with host-local files, credentials, plugins, skills, and config; Claude Code's cross-session messaging now also reaches its own Remote Control sessions on other machines, narrowing this distinction |
 | App-level artifact review        | Codex         | Sidebar preview for generated PDFs, spreadsheets, documents, and presentations |
 | App-level PR review              | Codex         | PR sidebar can inspect changed files, review comments, and follow-up fixes   |
 | Multi-folder projects            | Codex         | One project can span repositories; the primary folder owns Git and automatic instruction, skill, and config discovery, while secondary folders are file-access-only |
@@ -154,7 +155,7 @@ These are the highest-impact gaps where one runtime's limitation blocks effectiv
 - Codex app/CLI capability changes are reviewed through app `26.727` and stable CLI `0.146.0`; workstation-specific alpha versions are intentionally kept out of this public matrix.
 - GPT-5.6 API model and pricing changes through 2026-07-30 come from the OpenAI API changelog: <https://developers.openai.com/api/docs/changelog>.
 - Sites, Amazon Bedrock, Remote, Record & Replay, app-server, plugin, and permissions details come from the official Codex docs under <https://developers.openai.com/codex/>.
-- Claude Fable 5 release date and pricing come from Anthropic's 2026-06-09 announcement: <https://www.anthropic.com/news/claude-fable-5-mythos-5>; the current plan-inclusion posture (Max/Team Premium shared weekly pool, launch promo ended) reflects Anthropic's plan policy as of 2026-07-20. Claude Opus 5 model ID, pricing ($5/$25 per MTok), 1M context, and its release as the current Opus tier were re-verified 2026-08-03 against Anthropic's model documentation (models overview + migration guide at <https://platform.claude.com/docs/en/about-claude/models/overview.md>): Opus 5 is a drop-in at Opus 4.8's pricing, and Opus 4.8 stays available. Present-day interface fallback behavior comes from Anthropic's Help Center article "Why Claude switched models in your conversation with Fable 5" (2026-07-01, verified 2026-08-04): automatic switching to Opus 4.8 is enabled by default and user-configurable — Settings > Capabilities in the apps, Config > MODEL & OUTPUT in Claude Code ("Switch models when a message is flagged" toggle); with it off, a flagged request pauses the conversation. The Fable 5 / Mythos 5 system card §1.5 ("Novel safeguards") remains the source for the safeguard design, the observed fallback-rate/session-event facts, and the API posture: the Messages API blocks by default with a structured refusal category and offers opt-in server-side fallback — whose category-routed default likewise targets Opus 4.8 for cyber-class refusals, so the fallback target is unchanged post-Opus-5. The serving model (claude-fable-5) and Claude Code version (v2.1.220) in the header were verified in-session by the Claude runtime on 2026-08-03.
+- Claude Fable 5 release date and pricing come from Anthropic's 2026-06-09 announcement: <https://www.anthropic.com/news/claude-fable-5-mythos-5>; the current plan-inclusion posture (Max/Team Premium shared weekly pool, launch promo ended) reflects Anthropic's plan policy as of 2026-07-20. Claude Opus 5 model ID, pricing ($5/$25 per MTok), 1M context, and its release as the current Opus tier were re-verified 2026-08-03 against Anthropic's model documentation (models overview + migration guide at <https://platform.claude.com/docs/en/about-claude/models/overview.md>): Opus 5 is a drop-in at Opus 4.8's pricing, and Opus 4.8 stays available. Present-day interface fallback behavior comes from Anthropic's Help Center article "Why Claude switched models in your conversation with Fable 5" (2026-07-01, verified 2026-08-04): automatic switching to Opus 4.8 is enabled by default and user-configurable — Settings > Capabilities in the apps, Config > MODEL & OUTPUT in Claude Code ("Switch models when a message is flagged" toggle); with it off, a flagged request pauses the conversation. The Fable 5 / Mythos 5 system card §1.5 ("Novel safeguards") remains the source for the safeguard design, the observed fallback-rate/session-event facts, and the API posture: the Messages API blocks by default with a structured refusal category and offers opt-in server-side fallback — whose category-routed default likewise targets Opus 4.8 for cyber-class refusals, so the fallback target is unchanged post-Opus-5. The serving model (claude-fable-5) and Claude Code version (v2.1.225) in the header were verified in-session by the Claude runtime on 2026-08-07. Cross-session messaging capabilities (SendMessage across sessions and machines, ListAgents discovery, crossSessionInbound/dialogExpiry settings) come from the Claude Code v2.1.222–v2.1.225 release notes.
 
 ---
 

{oacp_cli-0.4.2 → oacp_cli-0.4.3}/docs/protocol/autonomy.md

@@ -263,7 +263,7 @@ Every autonomy decision writes one YAML file:
 
 ```yaml
 schema_version: 2
-spec_version: "0.4.2"
+spec_version: "0.4.3"
 created_at_utc: "2026-05-12T13:23:25Z"
 receiver: codex
 sender: iris
@@ -363,7 +363,8 @@ signer_kid, reason}` — the policy-file authorization outcome (see
 `policy_sha256` the record commits to an *authorized* policy identity,
 not just which bytes ran. An `invalid` status fails closed with reason
 code `policy_auth_invalid` before any gate consumes the config.
-`spec_version: "0.4.2"` pins everything 0.4.1 pinned — Gate 1 integrity
+`spec_version: "0.4.3"` preserves every autonomy field and rule pinned by
+0.4.2 — Gate 1 integrity
 enforcement, the recalibrated Gate 2/3 policy, full task-profile capture, the
 explicit `breached` list, the outcome block shown above, session-scoped
 envelope enforcement, the enforce-mode trust-pin completeness gate, and
@@ -372,7 +373,9 @@ plus intake verification as mechanism (`verify_mode: enforce` rejects at
 the gate), the `policy_auth` authorized-policy block, the default scope
 envelope for profileless admissions (with `scope_envelope_source` and the
 null-on-admitted writer refusal), and the recorded none-by-rule
-enforcement branch for approved public-visibility tasks. Audit
+enforcement branch for approved public-visibility tasks. The spec version
+advances because 0.4.3 adds the project-wide message-retention policy and the
+processed-inbound archive convention; autonomy semantics are unchanged. Audit
 `schema_version: 2` adds thread identity and
 the structured `result.human_outcome` block. Recorders may upgrade a v1 audit
 to v2 when the first human outcome is written; standing grants trust only v2
@@ -546,10 +549,20 @@ families are:
   `continuation_grant_missing_approval`,
   `continuation_grant_missing_scope`, `continuation_grant_missing_thread`,
   `continuation_grant_scope_exceeded`, `threshold_checkpoint_breached`,
+  `checkpoint_reauthorized`, `checkpoint_reauthorization_stale`,
   `message_valid`, `message_not_expired`, `message_hash_recorded`,
   `task_profile_present`, `task_profile_not_required`, `task_type_allowed`,
   `risk_threshold_passed`, `hard_stops_clear`, and
-  `workspace_check_required`.
+  `workspace_check_required`;
+- review-loop continuation codes (see "Review-loop continuation"):
+  `review_continuation_accepted`,
+  `review_continuation_confirmation_required`,
+  `review_continuation_context_only`, `review_continuation_expired`,
+  `review_continuation_head_mismatch`,
+  `review_continuation_ignored_disabled`,
+  `review_continuation_missing_approval`, `review_continuation_revoked`,
+  `review_continuation_round_exceeded`,
+  `review_continuation_scope_exceeded`, and `review_loop_invalid`.
 
 ## State Transition Metadata
 
@@ -688,6 +701,174 @@ explicit `breach_basis` inconsistent with the input (`realized` alongside
 intent fields, `declared_intent` without them). A mixed situation records
 the realized breach on its own, then re-evaluates the correction.
 
+### Re-authorization channels and arbitration
+
+A paused checkpoint can be answered from more than one channel. Three are
+defined, highest precedence first:
+
+| Channel | Surface | Authority |
+|---------|---------|-----------|
+| `receiver_human` | The receiver-side human decision recorded on the audit record (`oacp autonomy-outcome`) | Authoritative |
+| `sender_reply` | A signature-verified sender message threaded to the checkpoint notification | Bounded by the receiver's admission policy |
+| `gh_comment` | A comment on the related PR or issue | Advisory only — never authoritative |
+
+Consultation order follows precedence: the receiver consults its own audit
+record first, then the checkpoint thread in its inbox, then the related
+PR/issue. Provenance verification for each channel — the signature and
+thread binding of a sender reply, the recorded outcome on the audit record —
+happens at the receiver before an answer may be presented for arbitration;
+the arbitration input is a decision surface, not a trust boundary.
+
+Arbitration rules:
+
+- The **governing answer** is the one on the highest-precedence channel that
+  carries an answer. Precedence is by channel rank, never arrival order: a
+  lower-ranked answer arriving after a higher-ranked ruling is recorded as
+  advisory and never re-opens the decision — in both directions. A
+  receiver-side human approval stands against a later sender decline, and a
+  receiver-side human decline stands against any sender approval.
+- **Sender authority is bounded by the receiver's own admission policy.** A
+  sender re-authorization can never authorize more than the receiver's
+  policy would have auto-accepted at admission: numeric extensions are
+  honored only up to the receiver's caps, and a boundary action is granted
+  only when an envelope declaring that capability would itself auto-accept
+  under the receiver's external-side-effect policy — for
+  `allow_pr_artifacts`, an artifact-class anchor (`creates_or_updates_pr`,
+  `comments_on_github`, or `files_issues`) on a private target present in
+  the receiver's `private_repo_allowlist`; a standalone `commits_changes`
+  or an unlisted/public target stays paused. Merge authority is never
+  sender-grantable, whatever the policy (merge always passes the
+  receiver-side human, mirroring the admission rule), and neither is any
+  field outside the coverable boundary-action vocabulary: the legacy risk
+  fields (destructive ops, auth/config/secrets, dependency changes, public
+  visibility) are receiver-side authority only, on the scoped and
+  scope-less paths alike. The party whose under-declaration caused the
+  breach cannot self-serve unlimited scope. Without a resolvable receiver
+  policy the sender channel extends nothing (fail closed).
+- **GH comments never clear a checkpoint.** They sit outside the protocol's
+  identity and verification boundary; any decision they carry is recorded as
+  advisory, and a checkpoint answered only by a GH comment stays paused.
+- A sender withdrawal of the task is a lifecycle event (`superseded`), not a
+  checkpoint answer; it is not arbitrated here.
+
+The receiver presents the answers it has observed as checkpoint input under
+`actuals.reauthorization`, and the evaluation records the arbitration under
+`threshold_checkpoint.reauthorization`:
+
+```yaml
+actuals:
+  actual_minutes: 25
+  actual_files_touched: 1
+  paused_at_utc: "2026-05-12T12:30:00Z"
+  reauthorization:
+    receiver_human:
+      decision: approved            # approved | modified | declined
+      decided_at_utc: "2026-05-12T12:50:00Z"
+      actor: alice
+      scope:                        # optional: budget extension and/or
+        max_actual_minutes: 30      # boundary-action grants
+    sender_reply:
+      decision: approved
+      decided_at_utc: "2026-05-12T12:45:00Z"
+      source_message_id: msg-20260512124500-sender-reauth1
+    gh_comment:
+      decision: approved            # advisory only; cannot carry scope
+      author: driveby-collaborator
+```
+
+```yaml
+threshold_checkpoint:
+  action: resumed_after_reauthorization
+  reauthorization:
+    presented: true
+    channel: receiver_human         # governing channel
+    decision: approved
+    decided_at_utc: "2026-05-12T12:50:00Z"
+    actor: alice
+    requested_scope:                # the raw request, kept as provenance
+      max_actual_minutes: 30
+    scope:                          # the effective grant — policy-capped;
+      max_actual_minutes: 30        # the durable value later checkpoints
+    disposition: resumed            # and envelope recompiles consume
+    cleared_paused_at_utc: "2026-05-12T12:30:00Z"
+    advisory:
+      - channel: sender_reply
+        decision: approved
+        reason: overridden_by_receiver_human
+      - channel: gh_comment
+        decision: approved
+        reason: never_authoritative
+```
+
+`requested_scope` preserves the answer exactly as asked; `scope` records
+what was actually granted after channel bounds — sender numerics capped at
+the receiver's thresholds, sender booleans filtered to the admission
+predicate. The two diverge exactly when a sender asked past the receiver's
+policy, and only `scope` may ever be consumed downstream.
+
+`disposition` is pinned to: `resumed` (breach cleared — the accept records
+`checkpoint_reauthorized` and the action `resumed_after_reauthorization`),
+`declined` (governing channel declined — action `reauthorization_declined`),
+`stale` (the reuse rejection below — adds `checkpoint_reauthorization_stale`),
+`insufficient` (a current answer that does not cover the breach),
+`advisory_only` (only non-authoritative answers exist), `unanswered`
+(breach with no input), and `not_required` (answers presented but nothing
+breached). `modified` behaves as approved with a replacement scope and
+requires an explicit `scope`, matching the outcome recorder.
+
+### Consumption
+
+What one answer clears is pinned by its scope shape:
+
+- **A scope-less approval** authorizes exactly the extent recorded at the
+  pause it answers (`decided_at_utc` at or after that pause's
+  `paused_at_utc`) — the numeric actuals and the boundary fields of that
+  pause alike, within the answering channel's grant bounds. It creates
+  nothing durable (`scope` stays null) and is consumed by that checkpoint:
+  presented against any later pause, it clears nothing.
+- **A scoped numeric budget** authorizes up to the granted budget for the
+  remainder of the task. A later checkpoint whose actuals stay within the
+  budget is cleared by the same standing answer — nothing new is consumed —
+  while growth beyond the budget is a new breach requiring a fresh answer.
+- **A boundary-action grant** (scope boolean) is durable for the remainder
+  of the task; see below.
+- **No answer shape clears the whole task unbounded.** Nothing waives future
+  checkpoints wholesale.
+
+An answer that neither postdates the current pause nor covers the breach
+through a standing granted scope is spent. Presenting it against a new
+breach is a reuse attempt and fails with `checkpoint_reauthorization_stale`.
+
+Consumption state lives on the audit record: the
+`threshold_checkpoint.reauthorization` block binds the governing answer to
+the pause it cleared (`cleared_paused_at_utc`) and preserves the granted
+scope for later checkpoints. A new checkpoint re-stamps `paused_at_utc`;
+whether prior answers still cover it is decided by the arbitration above,
+never by implicit trust.
+
+### Boundary-action grants
+
+A re-authorization may be scoped to a specific boundary action instead of —
+or in addition to — numeric budgets: a scope boolean naming one declarable
+granular capability (`creates_or_updates_pr`, `comments_on_github`,
+`commits_changes`, `merges_pr`, `files_issues`).
+
+- A granted boundary action behaves as if declared true for the remainder of
+  the task: the same action class does not re-fire the checkpoint, and an
+  envelope recompile picks it up. It is not consumed per use; it expires at
+  task completion.
+- Numeric budgets stay per-checkpoint as above: granting an action never
+  extends time or file budgets, and vice versa.
+- Channel bounds apply. The receiver-side human may grant any action; a
+  sender re-authorization may grant only an action the receiver's admission
+  policy would itself auto-accept (the exact `allow_pr_artifacts`
+  conditions above — never a standalone `commits_changes`, never an
+  unlisted or public target), and never `merges_pr`.
+- Standing authority across tasks is out of scope for a boundary-action
+  grant — that is the continuation-grants mechanism (see Continuation
+  Grants), which resolves only from prior human-approved audits in the same
+  thread.
+
 ## Envelope Compilation (Phase 2)
 
 Phase 2 turns the declared `task_profile` from reviewed intent into enforced
@@ -746,7 +927,7 @@ The envelope is written to
 ```json
 {
   "envelope_version": 1,
-  "spec_version": "0.4.2",
+  "spec_version": "0.4.3",
   "compiler": "envelope_compiler.py",
   "compiled_at_utc": "2026-07-12T02:00:00Z",
   "project": "my-project",
@@ -1046,6 +1227,126 @@ accepted residual
 trust boundary; it does not bypass hard stops or the grant's declared/actual
 scope checks.
 
+### Review-loop continuation
+
+Review lifecycle messages (`review_request`, `review_feedback`,
+`review_addressed`, `review_lgtm`) carry no `task_profile` and do not run
+the four task gates. Without a grant, every reviewer invocation requires
+explicit human confirmation — that default is unchanged. A human may
+instead grant a bounded, revocable continuation for **one PR review
+thread**, so follow-up rounds in that thread auto-invoke the reviewer.
+
+The grant authorizes *running* a review round, never its verdict: the
+reviewer still fetches and validates the live PR head, runs the quality
+gate, and independently chooses `review_feedback` or `review_lgtm` (see
+`review_loop.md` → "Exact-Head Validation").
+
+The grant is the same `approved_thread_continuation` kind, extended with a
+`review_loop` block inside its scope. A review-only grant may omit the
+task budget keys — they default to `0`, so the grant carries no
+task-continuation authority:
+
+```yaml
+grant:
+  decision: approved
+  granted_scope:
+    review_loop:
+      repository: example-org/widget       # pinned repo slug
+      pr_number: 88                        # pinned pull request
+      allowed_types:                       # inbound types that may trigger
+        - review_request                   #   a round (review_addressed only
+      max_round: 3                         #   if listed explicitly)
+      expires_at_utc: "2026-06-30T00:00:00Z"
+      permitted_side_effects:
+        writes_findings_packet: true
+        sends_oacp_reply: true
+        comments_on_github: false
+        submits_github_review: false
+```
+
+Recognition and authority are separate: receiver config
+(`autonomy.continuation_grants.enabled: true`) only enables grant
+*recognition*. Authority exists only in a prior schema-v2 audit whose
+`human_outcome` records a task decision of `approved` or `modified` plus a
+grant decision of `approved` or `modified` with a valid
+`granted_scope.review_loop`. A sender-declared grant claim is a request,
+never proof — with no matching prior human decision it pauses with
+`review_continuation_missing_approval`.
+
+A fresh `review_request` auto-continues only when **all** of these hold,
+checked in pinned order with early-out:
+
+1. the receiver recognizes grants (`enabled: true`; else
+   `review_continuation_ignored_disabled`) and the message has same-thread
+   evidence (`conversation_id` or `parent_message_id`) matching the grant
+   audit's sender and thread — cross-sender, cross-thread, and
+   cross-receiver requests fall back to the explicit-confirmation default
+   (`review_continuation_confirmation_required`);
+2. the message type is listed in `allowed_types` — `review_addressed`
+   stays context-only unless listed (the manual-continuation shape), and
+   reviewer-output types (`review_feedback`, `review_lgtm`) are always
+   context-only (`review_continuation_context_only`);
+3. the declared `repo` and `pr` match the pinned `repository` and
+   `pr_number`, the declared fields parse, and the round's requested side
+   effects stay inside `permitted_side_effects` — any excess or
+   unverifiable declaration pauses with
+   `review_continuation_scope_exceeded` (fail closed: a request that does
+   not declare its repository cannot be confirmed in-scope);
+4. the effective round stays within `max_round`
+   (`review_continuation_round_exceeded` otherwise). The effective round
+   is `max(declared round, 1 + prior round-consuming audits in the
+   thread)`, where an audit consumes one unit only when its invocation
+   actually ran: an `auto_accepted` continuation round, or a pause whose
+   recorded human outcome authorized the manual round
+   (`approved`/`modified`). Declined, unanswered, and context-only
+   records consume nothing — a dead ask can never exhaust the budget a
+   later re-grant promises. The receiver's own audit trail is the floor,
+   so a sender cannot under-declare the round number to stay inside the
+   ceiling, and grant-listed `review_addressed` invocations cannot
+   repeat unbounded;
+5. the grant is unexpired on **both clocks**: neither the message's
+   `created_at_utc` nor the evaluation time may pass `expires_at_utc`
+   (`review_continuation_expired` otherwise). `created_at_utc` is
+   sender-controlled, so the evaluation-time check is the binding one —
+   a request queued before expiry does not run after it.
+
+Authorization and revocation arbitrate on different clocks. An approval
+governs only requests created after it — authority is never retroactive.
+A denial takes effect the moment it is recorded: a denial decided before
+*evaluation* revokes queued work even when the request predates it
+(`review_continuation_revoked`), and on a tie the denial wins. A denial
+is not a tombstone — a newer approval that still predates the request
+re-establishes standing continuation.
+
+The decision records a `review_continuation` block alongside
+`continuation_grant`: the governing scope, the declared request context,
+the `effective_round`, `exceeded_fields` on drift, the grant's
+`source_audit`/`source_message_id`, and a `head_check`
+(`declared_head`, `live_head`, `status:
+match|mismatch|undeclared|unverified`). A head mismatch — including a
+declared value that only shares a prefix with the live head, or a
+truncated declaration — is recorded with
+`review_continuation_head_mismatch` and never blocks the round: the live
+head is authoritative, and the reviewer must resolve the declared value
+against a live fetch before any terminal verdict. Head drift after
+approval still invalidates completion per the review-loop protocol.
+
+`permitted_side_effects` binds execution, not just admission: the
+dispatching runtime passes the accepted scope's permitted set to the
+reviewer invocation as its bound, and the reviewer withholds any outward
+action whose entry is `false` (recording what was withheld) — a granted
+round never performs a GitHub comment or review submission the grant did
+not permit. A round that cannot complete without a forbidden effect
+pauses instead of performing it.
+
+Lexical hard-stop scanning deliberately does not run on review lifecycle
+bodies: a granted reviewer invocation executes a pinned workflow whose
+side effects are bounded by `permitted_side_effects`, not by sender prose,
+and review bodies quote diffs and commands by design. Admission here is
+scope matching against a human-granted bound, not body classification.
+An admitted review decision carries no task `scope_envelope`; its bound is
+the accepted `review_continuation.scope`.
+
 ## Taxonomy Pin
 
 Audit `result.final_state` is limited to: