feat: journal strict task consumption before native fixture effects

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a140c4-354a-7823-8f0d-8f717397f786

docs/task-execution-mediator-seam.md

@@ -0,0 +1,107 @@
+# Strict task handoff to independent consumption confirmation
+
+RPF-WP-0035-T12 source preparation, 2026-10-16. This seam calls only the existing
+fixed disposable native adapter. It installs no production origin, identity,
+permission, real grant, generic broker or backend default.
+
+## Actual starting gaps and reused owner interfaces
+
+At Platform source base d042d468 and Secrets c80a944 the native fixture used a
+synthetic direct `consume-confirmed` journal transition. No actual strict Secrets
+task handoff existed. Generic Secrets consume accepted a substituted approval ID,
+coerced idempotent values and did not require the original exact decision. Those
+are Secrets-owned defects; Platform did not copy its authorization policy or edit
+that repository. The Secrets owner prepared a separate strict module under
+SECRETS-WP-0013, referenced by exact hashes in this package's manifest.
+
+Approval Engine already provides `ExecutionConfirmationClient.consume_exact` and
+`confirm_consumption`. The latter performs an independently authenticated GET of
+the durable original approval object and filters it to the original consumption
+triplet/time. It is historical PIP evidence, not authorization. It neither validates
+an Access decision nor makes a supplied receipt authoritative. Platform's adapter
+previously assumed its first native call was journal ordinal zero, conflicting
+with a preceding durable CAS/confirmation sequence.
+
+`scripts/task_execution_mediator.py` now performs the narrow owner join:
+
+1. Require the actual `secrets_engine.task_execution_handoff` dependency; absence
+   refuses before provider credentials, journal reservation or native effects.
+   The mediator itself calls `authorize_task_execution`. It accepts neither an
+   inbound authorization object nor a caller-selected authorizer/transport callback.
+2. Independently compile the exact local catalogue/descriptor/grant and compare the
+   strict owner's detached handoff descriptor byte-for-byte. Only authorization_id
+   may be added to approval reference metadata; purpose and source semantics cannot
+   be substituted through an inbound catalogue object. Secrets owns signed Check,
+   claim/native-act/full and approval-free digest joins, caller/subject correspondence
+   and the strict prepared object. Platform does not render or duplicate that decision.
+3. Bind the actual returned full canonical digest into the owner Plan. Reserve the
+   approval/request/operation/Plan tuple and the precommitted cleanup obligations
+   once while holding the same invocation lock through cleanup.
+4. Commit a CAS call intent, invoke Secrets `consume_task_execution` once and require
+   its actual typed result with exact original approval/request/decision/time and
+   `idempotent is False`. A historical idempotent response cannot open native work.
+5. Commit a separate read intent and invoke the actual Approval owner's default
+   isolated transport, with independently installed read credential and exact same
+   owner-admitted origin. Require `confirm_consumption` to match the native act,
+   approval-free digest and original exact triplet/time. Raw approval entries and
+   provider credentials never enter journal evidence or receipts.
+6. Recheck original approval/decision/operation bounds using the existing Secrets
+   time adapter, then persist `consume-confirmed`. Any CAS/read failure, timeout,
+   denied read or mismatch records unknown and causes zero native execution. A
+   subsequent invocation cannot retry the consumed approval or persisted admission.
+7. Only then enter the fixed native grant/metadata adapter. Its next business-call
+   ordinal comes from the same live journal, so CAS and GET occupy ordinals0/1 and
+   native calls continue at2. Pending/unknown/cleanup-closed state cannot supply a
+   next ordinal. Each native request retains its own durable intent and outcome.
+8. Cleanup stays under the original distinct obligations even if business work
+   fails. Returned evidence explicitly says native apply is unverified: six successful
+   native calls do not establish total approved baseline/readback normalization,
+   atomic CAS, service-login provenance or native production owner acceptance.
+
+The owner configuration selects provider route/read credential and the existing
+Secrets configuration. These are independently installed runtime inputs, never
+part of an HTTP body or authority derived from a caller string. Both providers use
+real existing transports. Python import/file checks do not establish runtime
+credential isolation; production custody/enforcement remains an external gate.
+
+## Whole disposable source-server proof
+
+Tests run the actual Access `serve` binary built from the owner source, with its
+real Ed25519 signing implementation and enforce-mode TokenReview client. A local
+synthetic reviewer independently admits only the explicitly fixed service token,
+principal/audience and expiry. This is not actual Kubernetes identity proof.
+Signing keys are generated in private temporary files; the public key and real
+policy digest are independently installed in the Secrets trust file. The policy
+digest comes from an owner-local actual source CLI before any network response.
+
+The positive policy is a separately named local synthetic exact-descriptor Rego
+fixture with a real deny fixture and Rego test. It never edits or enables the
+actual task policy. The actual proposed service task package is exercised unchanged
+and returns genuine signed DENY. There is no fabricated DecisionEnvelope or
+model-only approval. Real Approval WSGI/SQLite plus distinct independently admitted
+synthetic service/human identities create, approve, consume and serve the object.
+The strict Secrets module uses its actual mandatory producer-type signature verifier,
+retained request/claim/envelope and one-shot strict CAS, followed by the independent
+Approval GET and real disposable OpenBao grant/token/metadata/cleanup requests.
+
+Tests also prove actual independent read-scope denial after successful consume:
+the durable approval is consumed, Platform remains unknown with pending read intent,
+no target native objects exist and reinvocation cannot consume again. The native
+journal is checked for known synthetic token leakage. A source purpose substitution
+refuses before authorization/CAS, and a missing strict module refuses before any
+credentials. Actual-policy denial leaves the approval approved and journal empty.
+All identity, policy/registry admission, source-bundle/baseline digests and grant
+approval in these tests are synthetic fixture inputs. These tests do not admit an
+estate caller, real grant, production transport or actual protected custody.
+
+## Remaining production work
+
+Adopt/publish the exact strict Secrets dependency and this owner seam together;
+admit the existing task-execution-grant source projection and actual identity,
+policy package, provider origin/custody and complete source revisions. The current
+actual policy remains hard-closed. Finish target CCR immutable semantics, total
+native expected-state normalization/conflict control, CCR38 provenance, actual
+per-call served-time/use enforcement, audit/outbox and protected uncertain/crash
+recovery. Then obtain and execute the exact founder-scoped attended trial.
+Approval replay prevention and uncertain native-effect reconciliation remain
+separate guarantees. T12, Secrets WP13 and native adoption stay open.