Advance dependency roots with guarded source implementations

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a10391-6355-7b41-b0fa-3e14e874f091

docs/construction-plan-format.md

@@ -98,7 +98,7 @@ one, per `MASON-WP-0001`'s own scoping.
 
 ## Binding OpenBao approval to execution inputs
 
-The AppRole and Kubernetes-auth builders additionally require two frontmatter
+The AppRole, Kubernetes-auth and attended OIDC matrix builders require two frontmatter
 fields: `build_spec` and `approved_spec_sha256`. `build_spec` is the complete
 value-free output of `ops_mason.executor.build_spec_document(spec)`. It includes
 the engine, exact policy/role/path and identity bindings, token bounds, policy
@@ -148,8 +148,8 @@ by this format migration.
 
 The existing AppRole engine creates only exact KV-v2 read lanes: one literal
 entry path, `read` on data and metadata, no wildcard, empty/parent path segment,
-HCL injection, or write capability. OIDC matrix writers remain a separate,
-blocked contract under MASON-WP-0005. Role and policy names must be single
+HCL injection, or write capability. The separate attended OIDC matrix engine is implemented under MASON-WP-0005;
+its live construction remains blocked on identity, platform review and plan approval. Role and policy names must be single
 literal names; Kubernetes service-account names/namespaces must be explicit,
 nonempty, unique DNS labels. Token use counts must be explicit nonnegative
 integers (zero is deliberately unlimited when approved); TTLs are positive
@@ -185,3 +185,37 @@ Do not blindly retry or delete them: inspect structure and audit metadata,
 resolve/revoke any partial issuance through the scoped custody procedure, and
 review a fresh delivery destination before retrying. The executor does not
 claim transactional rollback or automatically widen its revocation authority.
+
+
+### Attended OIDC operator matrix
+
+`OIDCKVSpec` and `build_oidc_kv_lane` implement the ops-mason side of the
+fluid-telegram four-entry matrix. Draft and review `build_spec_document(spec)`
+and its digest through the same exact-spec approval process. The spec requires
+campaign coordinates, one owner-confirmed group, identity-confirmation and
+platform-matrix-review references, explicit loopback CLI callbacks, policy/role
+names and token bounds. These references are review inputs, not authorization
+tokens or proof that an owner accepted a draft.
+
+The renderer emits four literal KV-v2 data stanzas: operator-app read;
+operator-session and bot-token create/read/update; redaction-salt create/read.
+It adds only the exact token revoke-self update endpoint. There are no metadata,
+parent, sibling, wildcard, deletion or salt-update grants. The engine writes
+policy/auth-role structure only; it never reads/writes KV values or issues a
+login token. The approved role has one bound group, no default policy, explicit
+15-minute initial / 30-minute maximum lifetime caps and non-periodic tokens.
+
+Initial callback support is deliberately limited to owner-reviewed
+`http://localhost:8250/oidc/callback` and
+`http://127.0.0.1:8250/oidc/callback`. A private UI callback or additional MFA
+claim shape requires matching owner-confirmed contract work before extending
+this engine. A group parameter or a local test does not establish installed
+issuer/MFA assurance. MASON-WP-0005-T01/T03/T05 keep those live obligations.
+
+On failure the engine suppresses Bao output and does not claim a successful
+audit receipt. It can leave a written policy if the auth-role write fails;
+inspect object/audit metadata and use the approved rollback procedure before a
+retry. Metadata-only local tests do not prove installed KV create/update/CAS
+behavior or agent-policy effective denial. Those remain native owner checks.
+Platform CCR request-type support and review remain a separate T02 dependency;
+the generic read-lane CCR renderer still must refuse this write matrix.