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

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	state_hub_workstream_id
MASON-WP-0005	workplan	Construct the fluid-telegram operator credential lane	infotech	ops-mason	blocked	planning	codex	helix-forge	2026-09-04	2026-10-05	483e56d6-6601-5377-9066-66225214c046

MASON-WP-0005 — Construct the fluid-telegram operator credential lane

Goal

Plan, approve, construct, and verify a high-risk attended OpenBao OIDC lane for the fluid-telegram provisioner without handling Telegram credential values. The lane must keep each campaign isolated and must not collapse the later adapter's narrower read need into the operator role.

Demand source: State Hub message 287cf897-7f47-4bcc-87d6-085f43d5f03e, originating from fluid-telegram/docs/requests/ops-warden-telegram-operator-lane.md and consumer workplan FT-WP-0002 (f2373858-c932-5a4d-81b6-db9a3595135a).

Boundaries

• ops-mason owns the construction plan, review gate, OpenBao policy/auth-role structure, capability verification, and pointer-only routing proposal.
• railiance-platform owns the OpenBao engine/source configuration and must approve the tenant segment and the extension of its read-only CCR contract.
• ops-warden owns review and activation of the routing entry.
• fluid-telegram and an attended operator own all value generation and entry. No secret value enters Git, State Hub, an ops-mason log, or agent context.
• Real Telegram apply remains blocked by FT-WP-0002-T08 even after the credential lane exists.

Confirm the path and OIDC identity binding

id: MASON-WP-0005-T01
status: done
priority: high
state_hub_task_id: "18c9099f-882f-575c-93b9-cc68d7fbc2af"

Obtain railiance-platform's explicit confirmation of the tenant/path segment and KeyCape group claim. The current recommendation is platform/workloads/coulomb/fluid-telegram/hall-of-helix; it follows the owner's established tenant/org shape and deliberately replaces the consumer's unconfirmed infotech assumption. The proposed OIDC group is fluid-telegram-operators, but no role may be built until the actual claim is confirmed.

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.

2026-10-08: key-cape answered (message b2ed890f, source key-cape e0b5fae): groups_claim=groups, bound groups=[fluid-telegram-operators]; bound /assurance/level=aal2 with bound_claims_type=string (as CCR-2026-0034); callbacks are the two loopback CLI URIs on 8250 plus the operator-tunnel UI callback on 18200. Recorded in the plan's OIDC role shape. The executor now always pins aal2 and accepts that exact UI callback, refusing the retired public one (tests/test_oidc_matrix.py, 153 passed). Two inputs remain, both human: the founder go for net-kingdom to create the LLDAP group with its members, and a scoped grant for the live survey (no operator session today).

2026-10-08: founder go given in this session: create LLDAP group fluid-telegram-operators with the single initial member tegwick. Sent to net-kingdom (message 259ec26d), which owns directory acts; ops-mason does not write LLDAP. Waiting for net-kingdom's metadata-only evidence.

2026-10-08: live survey run under grant claude-MASON-WP-0005-T01 (ops-mason-survey), recorded in the plan's section 2: path unused, proposed policy and OIDC role names free, all 81 policy bodies scanned and only platform-admin covers the path, no catalog route. The live keycape-secrets-engine-openbao-operator role confirms the binding shape. Only the group evidence remains for T01; the plan can then move to reviewed.

2026-10-09: net-kingdom (reply a2693a9d, earlier 62e1b721): no agent path today. identity-provisioner POST /v1/groups/ensure exists only from net-kingdom 630ebfd, the live image is the older main-6c4fcaf, and the identity-provisioner-groups lane waits on WARDEN-WP-0044. The founder creates 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

id: MASON-WP-0005-T02
status: done
priority: high
state_hub_task_id: "69c558d9-664f-5ce0-80b2-d2e7544353a3"

Add an approved openbao-oidc-kv-read-write engine shape to ops-mason rather than forcing this demand through the AppRole/Kubernetes read-lane executor. Coordinate the matching railiance-platform CCR schema/validator extension; its current request_type enum and name checks accept only workload-kv-read.

The extension must render four exact KV-v2 data-path stanzas, preserve the phase-4 approval gate, refuse wildcard/parent scopes, bind one confirmed OIDC 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.

2026-10-05 done: source contract checked against this task, not against the prior progress note. python3 -m pytest tests/test_oidc_matrix.py — 20 passed. Named tests: test_draft_and_changed_approval_never_execute (approval refusal, no bao call); test_matrix_has_exact_data_scope_and_write_once_salt (four exact KV-v2 data-path capabilities, no sibling or parent path, create-only salt); test_refuses_unsafe_matrix_before_bao (wildcard and parent scopes refused); test_exact_role_binding_and_value_free_build (one groups claim parameter, policy/auth writes only, metadata-only audit); test_failure_suppresses_output_and_never_claims_success (no value in the failure). No OpenBao run and no plan approval. The confirmed claim value remains T01. Matrix paths sent to railiance-platform for RPF-WP-0035-T03 review (message 79570eb8-2107-4f75-b463-a45c2a70b7bf): src/ops_mason/executor.py and tests/test_oidc_matrix.py.

Review the plan and obtain the decision

id: MASON-WP-0005-T03
status: done
decision_id: e9f44beb-ad15-4285-8996-1e66d312fe59
priority: high
state_hub_task_id: "48a2b4ec-8e66-5b98-b039-c17fd8d820ab"

Complete the live existing-structure survey and review plans/fluid-telegram-operator-credential-lane.md. Present the exact path, policy, OIDC role, confirmed claim, callbacks, capability matrix, TTL/default-policy posture, write-once recovery consequence, agent boundary, reversal procedure, and adapter separation for explicit human approval. Only the plan's status: approved plus approved_by and approved_at authorizes a build.

2026-10-03: human gate routed to hub decision e9f44beb-ad15-4285-8996-1e66d312fe59 (D8: ops-mason plan approvals: unclear metadata paths and the live-survey plan) by CUST-WP-0075; resolving that decision raises C-40 here.

2026-10-09 done: founder approved in this session ("APPROVE fluid-telegram-operator-credential-lane"). The plan carries status: approved, approved_by: "Bernd Worsch", approved_at: "2026-10-09", the full build_spec and approved_spec_sha256 41a0ca27...; the executor's approval gate accepts it (checked by loading the plan, no bao call). Hub decision e9f44beb also gates WP-0004-T01 and stays open until that half is answered.

Build the approved operator lane

id: MASON-WP-0005-T04
status: done
depends_on: [MASON-WP-0005-T03]
priority: high
state_hub_task_id: "0e3d1333-ffc3-5f67-8528-50a9551c4949"

After T03, create the exact policy and auth/netkingdom OIDC role through the approved engine surface. Add each high-risk data and metadata path to the agent read boundary. Do not create a wildcard campaign prefix and do not enter, request, fetch, or display any Telegram value.

The redaction-salt path grants create,read only. It does not grant update, patch, delete, metadata mutation, destroy, or undelete. Recovery from a bad first write is therefore an attended, separately approved platform action, not a provisioner capability.

2026-10-09: four values already sit at platform/workloads/infotech/fluid-telegram/hall-of-helix/ (written 2026-10-07, operator-session v4). Founder ruling: keep coulomb as approved and move them. The move is part of this build: one attended, output-free platform-admin step that writes each entry at the coulomb path with CAS 0, verifies versions, then deletes the infotech metadata, so redaction-salt keeps its value and stays write-once. fluid-telegram repoints its refs.

2026-10-09 done (railiance-platform ce1c1a6, message af873813, evidence docs/evidence/2026-10-09-fluid-telegram-t03-founder-session.json): the founder applied CCR-2026-0039 at 10:30Z (policy, OIDC role, 8 agent denies appended to agent-high-risk-boundary; readback matched) and ran the custody move: all four entries now at the coulomb path, version 1 each, infotech metadata deleted. fluid-telegram must set FLUID_BAO_PREFIX=workloads/coulomb/fluid-telegram/hall-of-helix.

Verify capabilities and record metadata-only evidence

id: MASON-WP-0005-T05
status: progress
depends_on: [MASON-WP-0005-T04]
blocked_on: human
blocking_reason: "ops-mason checks and the non-member refusal pass (2026-10-09). tegwick has no MFA factor: it enrolls through user-engine self-service MFA (message ab89a591, USER-WP-0028-T03), then the founder runs scripts/verify-fluid-telegram-lane.sh member; fluid-telegram runs the salt create-once probe (FT-WP-0002)."
priority: high
state_hub_task_id: "4c205be7-4f1f-5dd1-aafa-fc112fdd640e"

Use a short-lived token for the confirmed operator identity to prove:

• reads on all four exact data paths;
• create/update on operator-session and bot-token;
• no provisioner write on operator-app;
• create but no update/patch/delete on redaction-salt;
• deny on the parent, another campaign, a sibling workload, and unrelated high-risk paths;
• deny for a non-member identity; and
• agent-bound identities remain denied on all four paths.

Revoke the test token immediately. Record only path names, reported capabilities, audit request ids/timestamps, versions/timestamps, and pass/fail. Any value-side create/update test must be performed by the sanctioned operator/platform flow and return metadata-only evidence to ops-mason.

2026-10-09 (grant claude-MASON-WP-0005-T05, revoked after): live policy workload-kv-fluid-telegram-hall-of-helix-operator equals the approved matrix exactly (so parent, sibling campaign and sibling workload are not granted); the OIDC role equals the approved role document (groups + aal2, 15m/30m, no default policy, three callbacks); agent-high-risk-boundary holds the 8 deny stanzas (data + metadata for the four entries); all four entries at the coulomb path v1, the infotech ones gone. Owner-run remainder: a member login and a non-member login with scripts/verify-fluid-telegram-lane.sh (capabilities only, receipt under ~/.local/state/railiance/receipts/), and the salt create-once probe by fluid-telegram (message f966db1c).

2026-10-09: non-member check passed. A login on the role as platform-root (not in fluid-telegram-operators) was refused by OpenBao with "claim groups does not match any associated bound claim values" (receipt fluid-telegram-lane-non-member.txt, 18:11Z). Member run as tegwick pending.

2026-10-10: the member run cannot pass yet: tegwick has no enrolled factor, so KeyCape asks for an OTP it cannot satisfy, and the role requires aal2 anyway. tegwick enrolls TOTP through privacyIDEA self-service (net-kingdom platform-root-custody.md steps 6-7, same procedure), then the member run.

2026-10-10: founder direction: MFA setup becomes a convenient self-service journey for all users, not a one-off. Asked user-engine (message ab89a591) to deliver it (USER-WP-0028-T03 / USER-WP-0027-T04, decision cef97ccd), with tegwick as the first attended real-user acceptance, and to reply when tegwick has an active factor.

Hand off routing and keep the adapter lane separate

id: MASON-WP-0005-T06
status: wait
depends_on: [MASON-WP-0005-T05]
blocking_reason: "After T05 verification; only ops-warden activates the entry."
priority: medium
state_hub_task_id: "09eae088-808d-5342-b100-292e13958ee3"

Propose fluid-telegram-operator to ops-warden as a pointer-only entry with owner_repo: ops-mason, warden_executes: false, and resolvable: false. It may move from draft to applied-pending-verify after construction, and only ops-warden may activate it after T05.

The adapter lane is tracked separately as MASON-IN-0003, tied to FT-WP-0002-T06. Its future policy may read only bot-token and redaction-salt; it must be denied operator-app and operator-session and must use the adapter's own runtime identity rather than this attended OIDC role.

2026-10-09: entry proposed to ops-warden as pointer-only, resolvable: false, applied-pending-verify (message 856bd6ba); activation stays with ops-warden after T05.

2026-10-10: ops-warden catalogued it (23ba584, message b73aa5f0) as fluid-telegram-operator, pointer-only, status draft (its catalog has no applied-pending-verify), with playbook wiki/playbooks/fluid-telegram-operator.md. It activates on the member receipt and the FT-WP-0002 salt probe.

Loose-end review — 2026-09-28

T01–T06 remain wait: accepted tenant/matrix, confirmed identity/MFA/callbacks, approved matching writer contracts, live survey, explicit construction approval and verification are outstanding. The platform design remains proposed. No lane was built or activated.

Evidence and precise resumption conditions: review. Existing tasks retain all remaining obligations; no new task or workplan was opened.

Operator-matrix source delivery — 2026-10-04

T02 advances to progress. The ops-mason engine now renders the exact four-entry OIDC matrix, writes only policy/auth structure, checks confirmed identity and platform-review reference parameters, enforces narrow loopback callbacks and bounded tokens, and reuses the existing fresh exact-spec construction approval check before any Bao command. Value output is suppressed; audit records hold only coordinates and approval digest. Actual source tests cover no-approval, changed scope, unsafe paths/claims/callbacks, salt create-only capabilities, role payload, no KV-value calls, and failure redaction.

Platform's design is still a proposal: no matching operator-matrix request type exists in its current CCR schema/validator. The old September note saying the schema/validator are already drafted does not establish implementation or acceptance. Platform contract support/review remains in T02; confirmed claim, issuer/MFA assurance and callbacks remain T01, then live survey and explicit exact-plan approval T03. No production role, policy, login or credential was created. The construction plan stays draft; local synthetic identity references in tests do not count as owner returns. This source wave also preserves all unrelated dirty owner files and the existing untracked construction plan.

2026-10-04 normal receiving initially refused an identical duplicate T01 fence in the closed MASON-0001 bootstrap source. Removed only the repeated identical fence, preserving the single logical task, label, existing UUID, title, status and every prose section; no record migration or task deletion. Retry normal Forge receiving after this source-level duplicate repair.

2026-10-05: T02 is done on the source contract and the unit tests named in that task. Platform review of the matrix is the RPF-WP-0035-T03 handoff, not an open ops-mason code gap. T01 and T03–T06 stay wait. This workplan stays blocked. The construction plan stays draft.