railiance-platform/docs/task-execution-cleanup.md

Durable cleanup obligations for the metadata execution pilot

RPF-WP-0035-T12 source preparation, 2026-10-16. This source is not an installed mediator, native execution entitlement, founder approval or owner-native proof.

Platform's existing admission journal made unknown and failed terminal and blocked all further calls. Its single business-state cleanup transition could not express a timed-out write with confirmed token revocation, or a verified write with unconfirmed cleanup. A future mediator using that interface could suppress cleanup precisely when needed. The journal now retains the original business outcome and records cleanup in a separate durable table.

At fresh reservation the trusted owner supplies at most one commitment each for task-token-revoke, identity-token-revoke, and grant-policy-delete. Each is a kind and exact native-call digest; no token/accessor, payload, path override or shell command is accepted. Obligations and admission are inserted in one SQLite transaction with FULL synchronous commits and directory fsync. Existing journal files gain the separate table; old admissions gain no obligations or authority. Empty cleanup evidence cannot produce a confirmed result or legacy success state.

Only the same live exclusive invocation that transitioned this binding through consume-confirmed can record cleanup intent. Neither a caller string nor journal observation establishes consume authority: the trusted mediator must independently validate the real served approval/PDP/consume before that transition. Cleanup can proceed when the business call is pending or state is unknown/failed. Starting it permanently closes business dispatch for that admission. An exact obligation moves owed -> pending -> confirmed|unconfirmed; no retry transition exists. A crash leaves pending, and reopening never restores admission. Pending business-call uncertainty remains even if every cleanup succeeds.

task_execution_cleanup.run_cleanup is the fixed caller of those journal methods. It is intended for the owner mediator's finally block inside the original Journal.locked() context. It dispatches only the three named owner cleanup methods, passing their admitted digest for independent native-call comparison. Ordinary exceptions/malformed evidence become closed unconfirmed reason evidence without logging or hashing raw backend text. Remaining independent obligations continue. A process death or BaseException leaves pending intent and requires owner reconciliation. A journal write failure prevents the corresponding effect. The component has no HTTP client, CLI command execution or native credential opener.

The owner adapter must retain the exact handles in private memory, implement bounded native calls, compare each reconstructed cleanup call against the admitted commitment, and return confirmed only after the appropriate native revoke/absence verification. A timeout, policy deletion alone, or eventual TTL expiry cannot prove issued-token revocation. Cleanup has the original separate obligation rather than the expired business deadline; this component does not extend any business grant. No automatic postcrash recovery is implemented: owner-private recovery requires fresh scoped authority and must never retry a business effect.

The current Compiler Plan does not yet contain these cleanup commitments. A production mediator must bind them into the exact reviewed grant/full canonical request/owner plan before reservation. The journal's digest parameter does not verify that correspondence. It must also integrate authenticated initiating actor, served claim/PDP and independently verified atomic consume, exact source/body and baseline/readback validation, ephemeral owner-held token materialization, per-call trusted-time/use enforcement, and native audit/recovery. There is no production executor in this repository to wire to this driver today; existing production readiness remains refused. Approval CAS alone cannot provide exactly-once target effects across process/network failure. T12 and SECRETS-WP-0013 remain open.

Validation uses actual SQLite/process locks and abrupt os._exit before and after a separately fsynced synthetic fixture effect. Reopened processes cannot resume cleanup or business work; a four-process race admits one driver. Other tests cover pending business calls, revoke timeout without suppressing later cleanup, changed commitments and bindings, malformed confirmations and empty-evidence refusal. These are disposable local fixtures, not OpenBao or production acceptance.