From 1189d12dc327d9f2fd086b941a2f643443e15172 Mon Sep 17 00:00:00 2001 From: tegwick Date: Mon, 14 Sep 2026 15:50:43 +0200 Subject: [PATCH] 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 --- ...-0004-credential-inventory-descriptions.md | 1 + ...fluid-telegram-operator-credential-lane.md | 165 ++++++++++++++++++ 2 files changed, 166 insertions(+) create mode 100644 workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md diff --git a/workplans/MASON-WP-0004-credential-inventory-descriptions.md b/workplans/MASON-WP-0004-credential-inventory-descriptions.md index 648354a..d822823 100644 --- a/workplans/MASON-WP-0004-credential-inventory-descriptions.md +++ b/workplans/MASON-WP-0004-credential-inventory-descriptions.md @@ -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" diff --git a/workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md b/workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md new file mode 100644 index 0000000..c75ae71 --- /dev/null +++ b/workplans/MASON-WP-0005-fluid-telegram-operator-credential-lane.md @@ -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.