railiance-platform/docs/attended-provisioning-window.md
codex e1caa378cf
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 5s
Record founder batched attended custody choice
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1046b-5629-7f52-badd-f718eadb6042
2026-10-04 03:00:33 +02:00

3.5 KiB
Raw Blame History

Attended provisioning preparation contract

Owner: railiance-platform, RPF-WP-0050. Origin: CUST-WP-0075 P2/P3.

python3 scripts/credential-change.py window-checklist --window-file <metadata.yaml> --workplan-root <owner/workplans> joins open non-residual task blocks carrying the exact decision UUID to explicit CCR, lane and owner-receipt contracts. Repeat --workplan-root for each repo in scope. Roots are the authoritative file snapshot; Hub qualifiers are independently verified before any attended window. No implicit completeness claim exists for omitted roots.

The metadata manifest has decision_id, date (YYYY-MM-DD), and entries; each entry has task_id, ccr, lane_doc, receipt_contract. The three file references are relative to this platform repo and must exist; the receipt contract names the owner’s required positive/negative/revocation/cleanup evidence, never values. Empty manifests/decisions, missing joins or any non-approved CCR produce exit 2 and NOT READY. Duplicate IDs and stale task joins are refused. Applied CCRs are never replay candidates. Arbitrary CCR content is never printed.

Each item must additionally bind the exact reviewed revision/digest, expected result, native preflight, abort owner, verification and rollback in the existing CCR/supervision receipt. REVIEW PREPARED is a source-join result, not execution permission. Upstream owner gates and live readiness must be checked again in the approved dated window. The Custodian owns cadence; this renderer schedules nothing and executes nothing. A resolved packet calls for owner re-check, not unconditional task completion.

P3 draft for founder ruling

The current rule remains attended value custody. Choose explicitly between (a) batched attended custody, (b) response-wrapped issuer delivery with one-time unwrap, and (c) a scoped MFA writer through a silent contained helper. Review exact actor/path/audience, TTL/single use, audit boundary, child-output suppression, crash cleanup, replay refusal and rollback before adopting b/c. Wrapped tokens are credentials and stay out of files, Hub, chat and logs. No option grants broad write or changes existing lanes. RPF-WP-0050-T02 is routed to D3; a generic D3 resolution still requires a specific value-path disposition, so lack of an explicit answer does not unblock it.

Founder choice — 2026-10-04

Bernd selected batched attended custody (existing approach) in this session. This completes the P3 choice for RPF-WP-0050-T02; it does not resolve the other subjects in the shared D3 decision.

The existing boundary applies: the founder performs OIDC/MFA in their own terminal through warden access openbao-platform-admin-login --exec -- <reviewed-command>. Every item retains its exact reviewed actor, path, audience, CCR revision, upstream gates and receipt contract. Batching groups preparation and attendance; it grants no additional paths, delegated writer or reusable authority. Existing lane and session TTL/revocation requirements remain in force. The reviewed child suppresses all output and errors, compares before writing, refuses differing objects and returns only the reviewed non-secret receipt. On failure or interruption, stop, establish the actual state and session cleanup, and revalidate the remaining items before retrying. Applied custody is excluded from replay; each item keeps its own abort, verification and rollback contract. Values remain outside Git, Hub, chat and logs.

The dated scope and owner mappings remain RPF-WP-0050-T03. This custody choice does not authorize a live command or activate a schedule.