coulomb/ops-mason
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

CUST-WP-0075 inbox sweep: act on railiance-platform and tenant-engine replies

Browse source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3775@bnt-lap001
Assistant-Session: cfacb6a5-ad5b-4f79-ac67-053e3b0d34a3
This commit is contained in:
tegwick 2026-10-03 03:28:33 +02:00
parent 2076d5c0dd
commit 4503d1e979
3 changed files with 72 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

29
workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md
View file

@ -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

5
workplans/MASON-WP-0006-readiness-tier-check.md
View file

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

49
workplans/MASON-WP-0007-tenant-engine-audit-core-sender-projection.md
View file

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