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

---
id: MASON-WP-0005
type: workplan
title: "Construct the fluid-telegram operator credential lane"
domain: infotech
repo: ops-mason
status: blocked
flavor: planning
owner: codex
topic_slug: helix-forge
created: "2026-09-04"
updated: "2026-10-05"
state_hub_workstream_id: "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

```task
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

```task
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

```task
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

```task
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

```task
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

```task
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](../docs/evidence/2026-09-28-loose-end-review.md). 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.