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

67 lines
4.5 KiB
Markdown
Raw Normal View History

# 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.