The warden admin wrapper refuses any output; the first founder run was refused (nothing written, all entries still drafts). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 327203@bnt-lap001 Assistant-Session: 55028ae3-4914-4bd1-8f5c-815f3527aef0
7.7 KiB
| id | type | title | domain | repo | status | flavor | owner | topic_slug | created | updated | related | state_hub_workstream_id | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MASON-WP-0004 | workplan | Describe every stored credential so the store is navigable | infotech | ops-mason | blocked | planning | codex | custodian | 2026-08-28 | 2026-10-03 |
|
e5656747-a974-581a-a3d4-4e6bb7262f4c |
Describe every stored credential so the store is navigable
Goal
Give all 21 credential paths in operators/ and platform/workloads/ the five
custom_metadata fields the custody standard requires, so an operator can find
out what a credential is without reading it.
Why this exists
custody-inventory.py reported 21 paths on 2026-08-28. Four carry descriptions
— the ones MASON-WP-0003 touched. Seventeen carry none.
An undescribed credential is one nobody can identify without reading it, which
means orientation requires the very access the store exists to control. It also
means the two failure modes of the previous week stay available: no used_by
list, so a rotation misses a consumer the way privacyIDEA's resolver was missed
for four days; and no on_loss line, so recovery gets improvised under pressure
the way the LLDAP predecessor's did.
This is not urgent the way a broken login is urgent. It is the difference between a secret store and a drawer of unmarked keys.
What "described" means
Five fields, per net-kingdom/docs/platform-root-custody.md: description,
owner, used_by, rotation, on_loss. Metadata only — no path's value is
read, and ops-mason-build cannot read one.
Establish owners before writing anything
id: MASON-WP-0004-T01
status: done
decision_id: e9f44beb-ad15-4285-8996-1e66d312fe59
priority: medium
state_hub_task_id: "5bda75f2-f780-579e-9d44-cc4011662b9a"
Most of the seventeen predate this repository and ops-mason cannot invent what they are for. Group them by mount prefix, propose an owning repo for each from the ops-warden catalog and the paths themselves, and take the founder's ruling on the ones that are genuinely unclear.
Guessing is the failure mode to avoid: a confidently wrong used_by is worse
than an empty one, because a rotation will trust it.
Acceptance: every one of the seventeen has a named owner, or is explicitly listed as unknown with the question that would settle it.
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: live inventory under grant claude-MASON-WP-0004-T01 (revoked
after): 49 paths, 45 undescribed (was 21/17 on 2026-08-28). Owner proposals in
docs/credential-owner-proposals-2026-10-09.md: 38 documented (owner from
catalog or CCR), 3 genuinely unclear (activity-core/default/llm-connect-provider-secrets,
forgejo/forgejo-mailer, target-revenue/runtime-secrets), and 4 undocumented
fluid-telegram entries under tenant infotech that conflict with the approved
MASON-WP-0005 plan (coulomb). Waiting on the founder's ruling for A and B.
2026-10-09 done: founder ruled. A: coulomb as approved, the four values move
there (MASON-WP-0005). B1: retire the duplicate activity-core/default/...
entry (founder-run delete via railiance-platform after a live no-grant check).
B2: forgejo/forgejo-mailer belongs to the new rapp-forgejo repo. B3:
target-revenue/runtime-secrets deferred as outdated. Every path now has a
proposed owner or an explicit reason, which is T01's acceptance.
Describe the paths whose purpose is already documented
id: MASON-WP-0004-T02
status: wait
needs_human: true
decision_id: 62aa95e4-3ccc-4867-8806-5e3db005b483
blocking_reason: "Drafts ready (manifests/custody-descriptions.yaml, 29/38 complete). Founder reviews and marks entries accepted, then applies with scripts/custody-describe.py apply under the admin wrapper; owners fill the 9 gaps (T03)."
priority: medium
state_hub_task_id: "a6a944d7-21c5-5043-a78d-b3809de0ee64"
Several are covered by an existing ops-warden catalog entry, playbook, or
construction plan in plans/ — railiance/backup/*, rapp-qonto/*,
user-engine/runtime, reuse-surface/runtime-secrets among them. For those the
five fields can be written from documents that already exist, with rotation
pointing at the real procedure rather than paraphrasing it.
Acceptance: custody-inventory.py reports these paths without a !, and each
rotation field names a document that exists.
2026-10-03: human gate routed to hub decision 62aa95e4-3ccc-4867-8806-5e3db005b483 (D1: Attended OpenBao provisioning window: one session clears the pending credential lanes) by CUST-WP-0075; resolving that decision raises C-40 here.
2026-10-09: drafted. scripts/custody-describe.py draft builds
manifests/custody-descriptions.yaml from the railiance-platform CCRs
(target.purpose, delivery.target, lifecycle.rotate), the ops-warden
catalog and the owner proposals, never from OpenBao; four ops-mason-sourced
entries were filled by hand from plans/. 29 of 38 have all five fields; 9
have gaps left empty on purpose (nextcloud x2, keycape-factor-issuer,
grafana-admin, smtp, and four used_by). Every entry is review: draft.
apply writes custom_metadata only, for review: accepted entries, silently
(tests/test_custody_describe.py, suite 157 passed). Founder run, after
review: warden access openbao-platform-admin-login --exec -- sh -c 'python3 /home/worsch/ops-mason/scripts/custody-describe.py apply /home/worsch/ops-mason/manifests/custody-descriptions.yaml >/dev/null 2>&1',
then read ~/.local/state/railiance/receipts/custody-describe.json.
(First attempt 2026-10-09 refused by the wrapper because apply printed status
lines; nothing written, all entries were still drafts. apply is now silent.)
Resolve the rest with their owners
id: MASON-WP-0004-T03
status: wait
depends_on: [MASON-WP-0004-T01]
blocking_reason: "Blocked on T01: owners answer what/what-breaks/what-if-lost per undescribed path."
priority: low
state_hub_task_id: "fff26914-d854-5854-b350-d7241812fb04"
Blocked on T01. What remains after T02 are paths whose purpose is not written down anywhere. Each needs its owner to answer three questions: what is this, what breaks when it changes, and what do you do when it is lost.
A path whose owner cannot answer the third question is a finding in its own right — it is a credential with no recovery story, and that is worth knowing before it is lost rather than after.
Acceptance: custody-inventory.py exits 0 across both mounts, or the remainder
is a short list with a recorded reason each.
Make an undescribed path visible before it accumulates
id: MASON-WP-0004-T04
status: wait
depends_on: [MASON-WP-0004-T03]
blocking_reason: "Blocked on T03."
priority: low
state_hub_task_id: "9a0cea06-eb63-54ad-963d-db4ea79c7c66"
Blocked on T03. Seventeen accumulated because nothing ever looked. Wire
custody-inventory.py --undescribed into whatever already runs regularly
against this repo, so a new undescribed path is noticed in days rather than
discovered in a year.
The check must not fail a build for a path someone else owns; it reports, and the report has a reader.
Acceptance: an undescribed path added today surfaces without anyone remembering to look.
Loose-end review — 2026-09-28
T01–T04 remain wait: no valid scoped metadata grant/current inventory or complete owner/recovery confirmations are available. Inventory failure handling and the private-tunnel defaults are fixed and tested; scheduled reporting still needs its reader and credential.
Evidence and precise resumption conditions: review. Existing tasks retain all remaining obligations; no new task or workplan was opened.