MASON-WP-0005-T01 done; fluid-telegram operator plan reviewed with executive summary

Founder confirmed LLDAP group fluid-telegram-operators exists with member
tegwick. Plan moves draft -> reviewed: platform matrix checked against the
executor, section 5 written for the T03 approval.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 327203@bnt-lap001
Assistant-Session: 55028ae3-4914-4bd1-8f5c-815f3527aef0

plans/fluid-telegram-operator-credential-lane.md

@@ -3,11 +3,11 @@ id: fluid-telegram-operator-credential-lane
 demand_source: fluid-telegram/workplans/FT-WP-0002 and State Hub message 287cf897-7f47-4bcc-87d6-085f43d5f03e
 consumer_repo: fluid-telegram
 credential_type: openbao-oidc-kv-read-write
-status: draft
+status: reviewed
 approved_by: null
 approved_at: null
 created: "2026-09-04"
-updated: "2026-09-04"
+updated: "2026-10-09"
 ---
 
 # Construction plan: fluid-telegram operator credential lane
@@ -162,9 +162,9 @@ covering workload policy, no catalog route.
   `b2ed890f-a05a-4b96-95eb-2cd9d8b32caa`, key-cape `e0b5fae`). Human ID tokens
   always carry `groups` (LLDAP group names); `aal2` is set only after a
   verified privacyIDEA factor, the same pin as CCR-2026-0034.
-- precondition: LLDAP group `fluid-telegram-operators`, initial member
-  `tegwick` only. Founder go given 2026-10-08; net-kingdom creates it (message
-  `259ec26d`). KeyCape does not create groups.
+- precondition met: LLDAP group `fluid-telegram-operators` exists with the
+  single member `tegwick` (founder report 2026-10-09, created in the LLDAP admin
+  UI; names only).
 - callbacks (subset of the `openbao-admin` client registration):
   `http://localhost:8250/oidc/callback`, `http://127.0.0.1:8250/oidc/callback`,
   `http://127.0.0.1:18200/ui/vault/auth/netkingdom/oidc/callback`. Never the
@@ -185,8 +185,7 @@ not added below this prefix.
 
 ## 4. Review notes (phase 2)
 
-This section is incomplete while T01 and T02 are open; the plan must remain
-`draft`.
+Complete as of 2026-10-09 (T01 and T02 done); plan moved to `reviewed`.
 
 - **Reuse:** reuse the existing `netkingdom` auth mount, callback set, group
   claim pattern, 15-minute TTL, and KV-v2 mount. Create only the policy and
@@ -196,8 +195,9 @@ This section is incomplete while T01 and T02 are open; the plan must remain
   access to KV metadata because the provisioner uses data GETs to detect
   absence; metadata evidence comes from the separately scoped builder/operator
   verification path.
-- **Identity binding:** the group and assurance claims are confirmed; the
-  group's existence in LLDAP is a hard blocker, not a warning.
+- **Identity binding:** group and assurance claims confirmed by key-cape; the
+  group exists with one member. Membership is the whole access decision, so
+  adding a member later is a change to this lane's reach.
   The role must not be readable by every OIDC user.
 - **Write-once semantics:** KV-v2 create/update distinction is documented, but
   activation also requires an owner-run non-secret probe proving the installed
@@ -210,6 +210,10 @@ This section is incomplete while T01 and T02 are open; the plan must remain
 - **Reversal:** disable/delete the OIDC role first, then retire the policy. KV
   entries remain in operator custody for an explicit retention/recovery
   decision; teardown does not silently delete values.
+- **Platform matrix:** railiance-platform's
+  `docs/credential-lane-designs/fluid-telegram-operator-kv.md` carries the same
+  four paths and capabilities as `_OPERATOR_MATRIX` in
+  `src/ops_mason/executor.py` (checked 2026-10-09).
 - **Implementation gates:** both ops-mason and railiance-platform must extend
   their current read-lane tooling before construction. Direct `bao policy
   write`/`bao write auth/netkingdom/role/...` commands outside those approved
@@ -231,7 +235,38 @@ This section is incomplete while T01 and T02 are open; the plan must remain
 
 ## 5. Executive summary (phase 3)
 
-Not yet renderable. The owner-approved tenant segment, the LLDAP group's
-creation, the live structure survey, CCR/executor extension, and installed-engine create/update
-probe are open inputs. When those close, this section must ask for one explicit
-approval covering the exact objects and capability matrix above.
+**What this creates.** One OpenBao policy and one sign-in role, nothing else:
+
+- policy `workload-kv-fluid-telegram-hall-of-helix-operator`: on
+  `platform/data/workloads/coulomb/fluid-telegram/hall-of-helix/`
+  `operator-app` read; `operator-session` and `bot-token` create, read, update;
+  `redaction-salt` create, read (write-once); plus revoke-self. No metadata,
+  list, parent or sibling access.
+- OIDC role `fluid-telegram-hall-of-helix-workload-kv` on the existing
+  `auth/netkingdom` mount: only members of `fluid-telegram-operators`
+  (today: `tegwick`) with a verified second factor (`aal2`); 15-minute token,
+  30 minutes at most; no default policy; the two loopback CLI callbacks and the
+  operator-tunnel UI callback.
+
+**Why it is safe.** The MTProto session is a full-account Telegram credential,
+so the lane is attended only: a person with MFA, never an agent or the future
+adapter. The path is unused and no workload policy reaches it today (live
+survey 2026-10-08). ops-mason writes only the policy and role; no value passes
+through it, and the salt cannot be overwritten.
+
+**What approval also accepts.** The tenant segment `coulomb` (replacing the
+consumer's `infotech` assumption), and the exact matrix above, which
+railiance-platform's lane design already matches.
+
+**What happens after approval.** The structure is applied through the approved
+surfaces only (railiance-platform's per-path applier, RPF-WP-0035-T03, under the
+attended provisioning decision `62aa95e4`; ops-mason's
+`build_oidc_kv_lane`), never by direct `bao` writes. ops-warden's
+`fluid-telegram-operator` entry stays non-resolvable until the seven checks
+above pass, including the owner-run write-once probe.
+
+**Undo.** Delete the role, then the policy. Stored values stay in operator
+custody until someone decides their retention explicitly.
+
+To approve, the founder says "APPROVE fluid-telegram-operator-credential-lane";
+ops-mason then sets `status: approved`, `approved_by` and `approved_at`.

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

@@ -43,9 +43,7 @@ consumer workplan `FT-WP-0002` (`f2373858-c932-5a4d-81b6-db9a3595135a`).
 
 ```task
 id: MASON-WP-0005-T01
-status: wait
-blocked_on: human
-blocking_reason: "Founder creates LLDAP group fluid-telegram-operators (member tegwick) in the LLDAP admin UI and reports names only; no agent path exists yet (net-kingdom reply a2693a9d). Live survey done 2026-10-08."
+status: done
 priority: high
 state_hub_task_id: "18c9099f-882f-575c-93b9-cc68d7fbc2af"
 ```
@@ -101,6 +99,10 @@ net-kingdom `630ebfd`, the live image is the older `main-6c4fcaf`, and the
 the group in the LLDAP admin UI (Groups, Create group, add `tegwick` only) and
 reports names only; `tegwick` may need to sign in again before the claim shows.
 
+2026-10-09 done: founder reports "group exists, members [tegwick]". Every T01
+input is closed (claims, callbacks, group, live survey); the plan is now
+`reviewed` and its section 5 executive summary is written for T03.
+
 ## Extend the construction and credential-change contracts
 
 ```task