Write-tool approval compatibility verification

Scope corrected 2026-08-05: The former implementation plan mixed the allowed approval carrier with retired P4.7 per-turn tool dispatch. Those classifier, feature-flag, manifest, MCP status-prose, and synthetic continuation steps were removed. This file is now only a verification list for the opt-in compatibility leg defined in the sibling carrier decision.

Required checks

• Action policy derives write/approval requirements from server-owned tool metadata and authenticated runtime identity.
• A write requiring approval creates an org/OSA/run-scoped ApprovalRequest and does not call the executor.
• Stored replay parameters are encrypted; API/UI/log/ledger views are redacted.
• Approve, reject, cancel, and read endpoints enforce role and tenant scope.
• Reject and cancel never execute the write.
• Approval binds tool, action, parameters, run, and policy version so a changed request cannot reuse it.
• Approved execution is idempotent and records one terminal audit result.
• A failure is visible to the approval workflow without fabricating a Hermes transcript message or switching transcript authority to Postgres.
• Normal managed turns have no Humanwork tool allowlist, prompt block, classifier, content gate, or mandatory review behavior.

Acceptance

Unit tests are necessary but not sufficient. Run one local managed Hermes write request through the actual approval UI/API and verify the external side effect before and after the decision. This compatibility acceptance is separate from the default agent_reply browser cases.