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	state_hub_workstream_id
MASON-WP-0005	workplan	Construct the fluid-telegram operator credential lane	infotech	ops-mason	proposed	planning	codex	helix-forge	2026-09-04	2026-09-04	483e56d6-6601-5377-9066-66225214c046	483e56d6-6601-5377-9066-66225214c046

---

id: MASON-WP-0005 type: workplan title: "Construct the fluid-telegram operator credential lane" domain: infotech repo: ops-mason status: proposed flavor: planning owner: codex topic_slug: helix-forge created: "2026-09-04" updated: "2026-09-04" state_hub_workstream_id: "483e56d6-6601-5377-9066-66225214c046" 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

id: MASON-WP-0005-T01
status: wait
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.

Extend the construction and credential-change contracts

id: MASON-WP-0005-T02
status: todo
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.

Review the plan and obtain the decision

id: MASON-WP-0005-T03
status: todo
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.

Build the approved operator lane

id: MASON-WP-0005-T04
status: todo
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.

Verify capabilities and record metadata-only evidence

id: MASON-WP-0005-T05
status: todo
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.

Hand off routing and keep the adapter lane separate

id: MASON-WP-0005-T06
status: todo
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.