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

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

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

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

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

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

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