diff --git a/workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md b/workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md index ed401d0..dd6d433 100644 --- a/workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md +++ b/workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md @@ -44,8 +44,8 @@ consumer workplan `FT-WP-0002` (`f2373858-c932-5a4d-81b6-db9a3595135a`). ```task id: MASON-WP-0005-T01 status: wait -blocked_on: message-from:railiance-platform -blocking_reason: "railiance-platform must confirm the tenant/path segment and the KeyCape group claim." +blocked_on: message-from:key-cape +blocking_reason: "KeyCape/NetKingdom must confirm the OIDC group claim, assurance level and callbacks for the attended provisioner role; railiance-platform (2026-09-09) declines to decide these. Tenant/path acceptance moves to the plan approval (T03)." priority: high state_hub_task_id: "18c9099f-882f-575c-93b9-cc68d7fbc2af" ``` @@ -62,14 +62,21 @@ Re-run the live policy/auth/mount survey with a scoped ops-mason session before moving the construction plan from `draft` to `reviewed`. Do not infer absence from the current disk-only survey. +2026-10-03 (CUST-WP-0075 inbox sweep): the two unread railiance-platform +replies of 2026-10-02 concern MASON-WP-0007 only and say nothing about this +lane. The applicable answer is railiance-platform's earlier reply of 2026-09-09 +(read, never recorded here): the OIDC group, assurance level and callbacks +belong to KeyCape/NetKingdom; the tenant/path and per-entry field/capability +matrix are not accepted by a draft and need acceptance (now carried by the T03 +plan approval); the construction contract and writer authority are ops-mason's +side. Re-qualified from `message-from:railiance-platform` to +`message-from:key-cape`; asked key-cape for the claim the same day. + ## Extend the construction and credential-change contracts ```task id: MASON-WP-0005-T02 -status: wait -depends_on: [MASON-WP-0005-T01] -blocked_on: message-from:railiance-platform -blocking_reason: "Needs the confirmed claim (T01) and the matching railiance-platform CCR schema/validator extension." +status: todo priority: high state_hub_task_id: "69c558d9-664f-5ce0-80b2-d2e7544353a3" ``` @@ -86,6 +93,16 @@ claim, and emit metadata-only audit records. It must never read or write KV values. Add unit tests for approval refusal, exact capabilities, no sibling or parent access, and the create-only salt shape. +2026-10-03 (CUST-WP-0075 inbox sweep): no new railiance-platform reply bears +on this task; its 2026-09-09 reply says the per-path capability schema, +validator and exact policy are already drafted on its side (RPF-WP-0035-T03, +`docs/credential-lane-designs/fluid-telegram-operator-kv.md`) and it will +review the field/capability matrix against the validator whenever ops-mason +has one. The platform-side wait is gone, so the task moves from `wait` to +`todo`: build the engine shape and tests with the OIDC claim as a parameter, +then send the matrix to railiance-platform for review. Binding the confirmed +claim still needs T01. Not built in this sweep. + ## Review the plan and obtain the decision ```task diff --git a/workplans/MASON-WP-0006-readiness-tier-check.md b/workplans/MASON-WP-0006-readiness-tier-check.md index fca8acd..7e2c4a1 100644 --- a/workplans/MASON-WP-0006-readiness-tier-check.md +++ b/workplans/MASON-WP-0006-readiness-tier-check.md @@ -232,6 +232,11 @@ date either way. 2026-10-03: human gate routed to hub decision 89f1058f-33bc-47a8-8a49-0b44d426c67e (D2: ArgoCD owns production: go-ahead sequence for railiance-apps-root, issue-core, policy-nexus and activity-core automation) by CUST-WP-0075; resolving that decision raises C-40 here. +2026-10-03 (CUST-WP-0075 inbox sweep): the 2026-10-02 railiance-platform +replies concern the tenant-engine audit-core sender (MASON-WP-0007) and say +nothing about policy-nexus ArgoCD onboarding. Gate unchanged: still the dated +2026-12-21 review, platform confirmation plus founder decision 89f1058f. + ## Loose-end review — 2026-09-28 T01–T05 are done: the founder resolved the whitehat placement and the guarded readiness implementation, tests, emergency evidence and docs are complete. T06 remains wait until the 2026-12-21 platform/exception review; this workplan is blocked on that dated review. diff --git a/workplans/MASON-WP-0007-tenant-engine-audit-core-sender-projection.md b/workplans/MASON-WP-0007-tenant-engine-audit-core-sender-projection.md index b181331..c8899eb 100644 --- a/workplans/MASON-WP-0007-tenant-engine-audit-core-sender-projection.md +++ b/workplans/MASON-WP-0007-tenant-engine-audit-core-sender-projection.md @@ -4,7 +4,7 @@ type: workplan title: "Project the tenant-engine audit-core sender token into its namespace" domain: infotech repo: ops-mason -status: active +status: blocked flavor: planning owner: claude topic_slug: netkingdom @@ -72,13 +72,24 @@ state_hub_task_id: "18151439-0d9c-536f-93c8-2b113bf80c27" ```task id: MASON-WP-0007-T03 -status: wait -blocked_on: message-from:railiance-platform -blocking_reason: "railiance-platform declares policy workload-kv-read-tenant-engine-audit-core-sender-eso and role tenant-engine-audit-core-sender-eso (ESO Kubernetes auth lane), or confirms the ops-mason builder may write the role." +status: done priority: high state_hub_task_id: "aadb4beb-7cdd-56d1-8140-1dbe38ff5db7" ``` +2026-10-03 (CUST-WP-0075 inbox sweep): railiance-platform replied 2026-10-02 +that it declared both objects in railiance-platform commit 8c44256 (intake +RPF-IN-0002, local, not pushed): policy +`openbao/policies/workload-kv-read-tenant-engine-audit-core-sender-eso.hcl` +(exact read of `platform/data/workloads/tenant-engine/audit-core-sender` plus +token lookup-self/revoke-self) and the silent, idempotent attended script +`scripts/openbao-tenant-engine-audit-core-sender-eso-attended.sh`, which writes +the policy and Kubernetes-auth role `tenant-engine-audit-core-sender-eso` (SA +`tenant-engine/tenant-engine-eso`, audience `openbao`, 15m ttl/max, no default +policy). Surface is the attended script, not the CCR path or `lanes.json`. The +declaration this task waited for exists, so T03 is done. Nothing is applied: +running the script is an attended founder step and joins T05. + ## Manifests in the tenant-engine rApp repository ```task @@ -90,6 +101,16 @@ priority: high state_hub_task_id: "e56f0374-fede-5494-8266-a30f08896a6a" ``` +2026-10-03 (CUST-WP-0075 inbox sweep): tenant-engine replied 2026-10-02 to the +draft-plan message: the drain re-reads the token file on every delivery and +treats a missing or empty file as a retry, so no rollout is needed after the +first ESO sync and the Secret mount is optional. It will declare SA +`tenant-engine-eso`, the ClusterSecretStore and the ExternalSecret in +`rapp-tenant-engine/manifests` once the plan is approved. That reply predates +ops-mason's approval notice (2026-10-02 22:17, message 207b94ce), which already +tells it to proceed with rows 4-6 and not apply before the seed. No new +question for ops-mason; still waiting on tenant-engine's declaration. + ## Attended seed of the dedicated KV path ```task @@ -99,13 +120,22 @@ needs_human: true decision_id: 62aa95e4-3ccc-4867-8806-5e3db005b483 depends_on: [MASON-WP-0007-T03] blocked_on: founder -blocking_reason: "Wrapped platform-admin process copies the tenant-engine token from the registry document to platform/workloads/tenant-engine/audit-core-sender without printing it; ops-mason-build is denied value reads, so only an attended admin lane can do it." +blocking_reason: "Attended founder session: run railiance-platform scripts/openbao-tenant-engine-audit-core-sender-eso-attended.sh (policy + k8s-auth role) under warden openbao-platform-admin-login, then a wrapped platform-admin process copies the tenant-engine token from the registry document to platform/workloads/tenant-engine/audit-core-sender without printing it; ops-mason-build is denied value reads, so only an attended admin lane can do it." priority: high state_hub_task_id: "1bb05319-25a5-579f-8b63-897ec583bc3e" ``` 2026-10-03: human gate routed to hub decision 62aa95e4-3ccc-4867-8806-5e3db005b483 (D1: Attended OpenBao provisioning window: one session clears the pending credential lanes) by CUST-WP-0075; resolving that decision raises C-40 here. +2026-10-03 (CUST-WP-0075 inbox sweep): railiance-platform's 2026-10-02 reply +puts the policy/role apply in the same attended window: the founder runs +`BAO_ADDR=http://127.0.0.1:18200 VAULT_ADDR=http://127.0.0.1:18200 warden access openbao-platform-admin-login --exec -- sh scripts/openbao-tenant-engine-audit-core-sender-eso-attended.sh` +from railiance-platform (read warden's printed line, not its exit code; exit 3 +means an existing object differs), then reads back the role. railiance-platform +has no helper for the row-7 seed; use ops-mason's wrapped-seed technique per +the plan. Blocking reason widened to cover both steps; gate unchanged +(decision 62aa95e4). + ## Verify and hand off ```task @@ -117,3 +147,12 @@ blocking_reason: "Needs T03-T05. Verify by metadata only: KV version exists, sto priority: medium state_hub_task_id: "84576093-9133-5708-b724-2266db434407" ``` + +2026-10-03 (CUST-WP-0075 inbox sweep): railiance-platform notes that ESO's +controller SA may create `serviceaccounts/token` in activity-core and +email-connect but this is not yet checked for namespace `tenant-engine`; run +an `auth can-i` check for that subresource there before the store goes live +(a railiance-cluster matter if it fails). Separately, the existing +`openbao-tenant-engine-database` store stays on a periodic token renewed by +`eso-token-renewer` (RPF-WP-0046); confirming it was re-minted as periodic +before ~2026-10-25 is outside this workplan.