Classify open workplans with flavor (CUST-WP-0072).

Set flavor on open workplans from origin/prose/status. Copy existing
depends_on aliases only. Do not promote residuals.

Assistant: grok
Assistant-Session: 01a09dc1-b21e-77e1-919e-fcad2f82b267
This commit is contained in:
tegwick 2026-09-14 15:50:43 +02:00
parent f47c7dbfe8
commit 1189d12dc3
2 changed files with 166 additions and 0 deletions

View file

@ -5,6 +5,7 @@ title: "Describe every stored credential so the store is navigable"
domain: infotech
repo: ops-mason
status: proposed
flavor: planning
owner: codex
topic_slug: custodian
created: "2026-08-28"

View file

@ -0,0 +1,165 @@
---
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.