railiance-platform/docs/task-execution-native-fixture.md

# Executable native metadata/grant/cleanup preparation

RPF-WP-0035-T12, 2026-10-16, second source package after the cleanup journal.

The fixed `NativeFixtureAdapter` actually dispatches to disposable loopback OpenBao.
It requires a live owner-spawned OpenBao dev-process handle with the exact loopback
port and dev/no-store-token arguments, and refuses every non-loopback origin.
Production is deliberately not implemented. This is a guard against accidental
misrouting inside the trusted fixture runtime, not a Python security sandbox.
No estate credentials, grants, approvals or policy packages are read or changed.
The tests start in-memory dev servers with synthetic root/session credentials,
synthetic owner admission, grant/state/source digests and a synthetic postconsume
journal transition. This proves native primitives, not authenticated admission.

The owner Compiler now deterministically includes the operation-specific temporary
policy name and cleanup call commitments in each serialized Plan. Commitments
include identity/task credential slots, exact native revoke/verify or delete/verify
method/path pairs, and the narrow no-issue/no-create skip branches. The full
execution descriptor can be bound into that Plan only by byte equality with an
independently installed owner descriptor, with operation/actor/CCR/catalogue/six
operations correspondence. Compiler revalidation preserves both descriptor and
cleanup content. The descriptor's SHA is preparation provenance; no opaque digest
or local file becomes approval or verified canonical request correspondence.

The adapter needs the exact compiler/Plan/binding and separately installed owner
fixture inputs. All handles stay in owner memory with hidden representations. It
requires the same live consumed journal admission and exact grant-issuing state.
It refuses an existing per-operation grant policy, creates only the two compiler
metadata endpoints plus revoke-self, verifies HCL, mints one parented service token
with only this policy, no default/identity policies, nonrenewable TTL <=120 seconds
and twelve uses, then verifies native token bounds through the owner. Six ordered
metadata calls use independently recompiled source/method/path/body. A task use is
reserved for revoke; native token limits also enforce the ceiling. Business calls
check wall and monotonic deadlines before effect, with a five-second cleanup reserve.
No retry/remint, caller HCL/JSON/path, mount/AppRole/KV/SecretID or shell API exists.
Wave 5 below adds exact sequential snapshot acceptance; native baseline CAS remains absent.

Every business/grant request records durable intent and closed status evidence.
Native cleanup has its own durable per-request intents beneath the original
committed obligation; accessor verification cannot erase an uncertain revoke.
The native adapter compares the exact committed cleanup sequence before request.
Self-revoke success must be followed by owner lookup-accessor's specific invalid
accessor response; generic HTTP400/403, timeout and policy deletion do not prove
revocation. The two explicitly accepted error encodings cover OpenBao's plain and
wrapped single-invalid-accessor forms. Native error text is never logged or hashed.
Cleanup bypasses expired business deadlines under the retained explicit obligation,
never source-driven business repair. Independent cleanup continues after failure;
retirement never overwrites the original unknown/failed business outcome.

Current actual native tests cover policy/body and K8s-role application/readback,
owner-parented TTL/use policy bounds, native sibling/KV/token/mount/SecretID capability
denial, both token accessor-invalid proofs, policy absence, deadline-expired cleanup,
source drift, no preconsume materialization, changed descriptor/cleanup commitments,
nonloopback refusal, actual write followed by simulated lost response, and actual
policy retirement with failed task revocation. The lost response is fault injection
after a successful real native write; it does not pretend to be an actual network
partition. The failed-revoke fixture independently confirms the still-existing
native token, then performs explicit synthetic owner recovery. No blind retry occurs.

## Minimal remaining decisions and integration

1. Define/admit `task-execution-grant` in the owner CCR validator. Bind the exact
   cleanup commitments, temporary policy/token bodies and source revisions into its
   immutable projection, referenced by the existing descriptor grant SHA. The
   descriptor currently has no cleanup field; no engine schema extension is needed
   if this owner grant binding is made explicit. The immutable projection/excluded
   append-only fields are not implemented in the current owner validator. This is
   the concrete owner schema/admission decision, not a need for a new service.
2. Have the existing authoritative engines supply authenticated initiating principal,
   exact canonical request + served claim/PDP/package and independent signed CAS
   consume verification to the owner mediator before its journal transition.
   The native fixture's local transition supplies none of that evidence.
3. Install exact origin/cluster/source/grant/baseline/readback inputs under the
   attended owner runtime. The current binder compares independently installed
   descriptor bytes, but does not authenticate source-bundle paths, grant digest or
   compute immutable CCR projection. The six-operation plan still comes from pinned
   actual owner source. Production origin authentication and deadline bounds against
   served approval/PDP remain separate.
4. Finish expected-state normalization and conflict handling for native K8s/OIDC
   defaults; add per-policy/role approved baseline comparison and exact readback
   verification. The fixture checks known fields, not total production equality.
   OpenBao metadata PUT has no native atomic CAS; the owner must choose exclusive
   admitted target custody or an honest conflict/recovery protocol.
5. Wire the fixed adapter to that mediator with bounded runtime isolation,
   owner-private uncertain-issuance recovery, external audit outbox and exact
   founder-scoped attended trial. No production caller or protected recovery channel
   exists here. The existing production readiness gate remains refused.

No umbrella broker, general executor, new credential catalogue or standing service
admin entitlement is introduced. Approval CAS prevents approval replay; it cannot
make uncertain native effects exactly-once. RPF T12 and Secrets WP13 remain open.

### Exact disposable metadata acceptance (2026-10-16, wave 5)

The owner-installed `FixtureAdmission` now carries canonical JSON before/after
snapshot bytes. Their SHA-256 values must equal the existing descriptor's
`expected_before` and `expected_after`, and both snapshots must name exactly the
two compiled metadata paths. Explicit JSON null means absence. Only the actual
OpenBao empty-errors 404 is accepted as absence; denied/malformed reads fail.
These inputs contain metadata, never KV values or private token handles.

Policy comparison retains name, HCL, version and cas_required. Only the
modification timestamp is excluded, after requiring an aware timestamp and the
closed observed policy field set. Role comparison retains every returned field,
including aliases, token defaults and unexpected additions, using canonical JSON
bytes (therefore false cannot equal zero). The disposable Kubernetes fixture pins
the complete OpenBao 2.5.5 response shape. Another plugin/version/default requires
an independently reviewed owner snapshot; nothing infers new accepted defaults.

Each baseline gates its corresponding write. Policy readback occurs before role
baseline/write/readback. A role conflict can therefore leave the policy applied;
that operation remains unknown. This sequence has no native CAS, aggregate
baseline gate, concurrent-writer exclusion, or simultaneous final-state proof.
After all six calls match the committed snapshots, the same-live adapter records
readback and verified with a value-free evidence digest. The mediator reports
native_apply verified; cleanup-confirmed requires all separate cleanup receipts.
Readback success with unconfirmed cleanup cannot reach cleanup-confirmed.

Reopening SQLite cannot dispatch, reconsume, restore token/accessor handles or
retry cleanup. Native effects can survive process loss. Cleanup handles remain
memory-only: no independently authorized recovery mechanism is implemented here.
This closes disposable sequential apply acceptance only, not TSA03 or native
production recovery/admission.