coulomb/ops-warden
4
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions

Revert the npm field, re-measure coverage, and hold the layer divergence

Browse source 
Five inbox items worked, none of which changed a credential value or moved a
secret.

whynot-design-npm-publish: field reverted npm_token -> NPM_AUTH_TOKEN and the
path confirmed, on railiance-platform's attended, read-only, no-value field
enumeration (their docs/evidence/2026-09-10-npm-lane-field-resolution.json).
Exactly one field is present at the governed path. The 2026-09-09 change was
adopted from a coordination message and would have failed at the WP-0037-T03
rotation. The ungoverned second location is recorded as an explicit non-lane,
not deleted and not tidied away.

pep-stance coverage: published figures were stale by eight lanes (unknown
18->20, not_applicable 12->15) while resolved stayed at 3 — the denominator
moved, the classification did not. Caught by the test that asserts the published
block equals what report_coverage.py measures. tests/test_workload_join.py held
the same stale counts; both now measure the same populations.

rapp-qonto-keycape-client: blocker character updated — authority exists and is
unexercised by owner decision ("not yet", offer open), which is not the same as
no authority existing. Reopen triggers are events, never elapsed time.

flex-auth -> access-engine rename (WARDEN-IN-0003): access-engine added to the
policy-check lane's keywords so routing resolves under both names from today.
owner_repo deliberately not flipped — policy.py sends it as resource.system on
every /v1/check, and FLEX-DEC-2026-013 keeps runtime names as flex-auth.

layer declaration: INTENT.md says Staff, layer.yaml says staff, section 11 does
not say which governs. Neither changed; gate-house holds the ruling. Position in
docs/layer-declaration-precedence.md, wait in WARDEN-WP-0034-T06, and a comment
in layer.yaml telling the next session not to "fix" it — the divergence is the
evidence the ruling is made against.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703
This commit is contained in:
tegwick 2026-09-21 02:16:33 +02:00
parent 15a4717dd1
commit baf53602ca
11 changed files with 422 additions and 32 deletions
Download patch file Download diff file Expand all files Collapse all files

6
registry/generated/high-risk-data-paths.yaml
View file

@ -10,10 +10,10 @@
# declares it, and is null where the field set has not been established --
# null means unknown, never 'one field'.
generated_at: "2026-09-15T18:38:11Z"
generated_at: "2026-09-21T00:11:00Z"
source: ops-warden/registry/routing/catalog.yaml
catalog_revision: "8a40dcb11b729115773630e449fd880c0700372e"
catalog_revision_date: "2026-09-14T09:59:11+02:00"
catalog_revision: "308409bff1fecb588e4667f7e3db335fde9cbbe6"
catalog_revision_date: "2026-09-15T20:38:47+02:00"
catalog_dirty: true
high_risk_lane_count: 29
concrete_path_count: 15

52
registry/routing/catalog.yaml
View file

@ -313,15 +313,29 @@ entries:
# form is superseded; do not reintroduce it.
auth_method: "bao login -method=oidc -path=netkingdom role=whynot-design-workload-kv-read"
path_template: "platform/workloads/coulomb/whynot-design/npm-publish"
# Field corrected 2026-09-09 on the owner's statement (secrets-engine msg
# 15f0c0ca): `npm_token` is the KV FIELD; `NPM_AUTH_TOKEN` is the environment
# variable the publication-scope policy injects, and ops-warden had copied the
# env var in as the field name. That is ADR-0001's failure mode exactly — a
# pointer layer restating an owner's procedure and getting it wrong — so it is
# corrected from the owner's doc (secrets-engine docs/whynot-design-real-publish-closeout.md),
# never re-derived here. The path is a separate question, open with
# railiance-platform; do not change it on this correction.
fetch_command: "bao kv get -field=npm_token platform/workloads/coulomb/whynot-design/npm-publish"
# Field REVERTED to NPM_AUTH_TOKEN on 2026-09-10, and the path CONFIRMED, by the
# custodian of the path (railiance-platform msgs c6841bdb, 79f3e047). An attended,
# read-only, no-value founder session enumerated the field names actually present
# at this path: exactly one, NPM_AUTH_TOKEN. Receipt: railiance-platform
# docs/evidence/2026-09-10-npm-lane-field-resolution.json (commit 9d24086); prior
# basis CCR-2026-0001's two dated receipts (2026-06-28) naming the same field.
#
# The 2026-09-09 change to `npm_token` was adopted from secrets-engine's statement
# (msg 15f0c0ca) and is wrong FOR THIS PATH. That is ADR-0001's failure mode in its
# proper form: a correction taken from a coordination message is still an unverified
# mutation, and this one would have named a field that does not exist — failing at
# the rotation (WARDEN-WP-0037-T03) rather than on a cheap day. Reverting is a
# correction back to the evidenced value, not a new lane change.
#
# OPEN, and not ops-warden's to settle: a legacy location
# secret/coulomb/whynot-design/npm/publish exists (metadata only, v1 created
# 2026-07-03, outside this lane's exact-path policy and outside any CCR).
# railiance-platform's hypothesis is that secrets-engine's lowercase field belongs
# to THAT path and that the native exec front door below may be reading the
# ungoverned duplicate. Tracked as railiance-platform RPF-WP-0035-T07; ops-warden
# has asked secrets-engine which location `secrets-engine exec` reads. Until that
# is answered, this catalog names the governed path and the field evidenced at it.
fetch_command: "bao kv get -field=NPM_AUTH_TOKEN platform/workloads/coulomb/whynot-design/npm-publish"
policy_ref: "flex-auth check secret.read:whynot-design"
exec_capable: true
lane: secret
@ -337,7 +351,7 @@ entries:
automatable: false
steps:
- "In the coulomb Forgejo registry, revoke the current @whynot/design publish token and generate a new one (scope: package read/write) for the whynot-design publish identity."
- "Write it back: `bao kv put platform/workloads/coulomb/whynot-design/npm-publish npm_token=@file` (value from a mode-0600 file). The field is `npm_token`; `NPM_AUTH_TOKEN` is the injected env var, not a KV key."
- "Write it back: `bao kv put platform/workloads/coulomb/whynot-design/npm-publish NPM_AUTH_TOKEN=@file` (value from a mode-0600 file). NPM_AUTH_TOKEN is the KV field name at this path, evidenced by an attended enumeration on 2026-09-10; it is also the env var the publication-scope policy injects, which is what made the two readings easy to confuse."
- "Verify capabilities-safe, then publish a fresh version and confirm it with Forgejo-supported `npm view <package>@<version>` through the governed execution lane (value used, not printed)."
- id: policy-nexus-forgejo-source-read
@ -383,7 +397,19 @@ entries:
workload_ref:
applicability: not-applicable
reason: "Generic authorization action; the governed resource supplies workload identity."
need_keywords: [authorization, policy, permission, allow, deny, may, flex-auth, topaz, pdp, decision]
need_keywords: [authorization, policy, permission, allow, deny, may, flex-auth, access-engine, topaz, pdp, decision]
# FLEX-WP-0020 rename review, 2026-09-21 (flex-auth msg 0a1956c5; WARDEN-IN-0003).
# `access-engine` added to the keywords so this lane resolves under BOTH names from
# today — the deprecation window ops-warden asked for in WARDEN-IN-0001 and the only
# change the rename needs here to keep routing working.
#
# `owner_repo` is deliberately NOT flipped, and the reason is not inertia. In this
# catalog `owner_repo` is not purely a repository coordinate: src/warden/policy.py
# sends it verbatim as `resource.system` (and as `context.owner_repo`) on every
# /v1/check. FLEX-DEC-2026-013 keeps runtime names as `flex-auth`, so flipping this
# string would rename a policy resource the PDP matches on, under cover of a
# repository rename — a runtime change wearing a coordinate change's clothes. It
# flips when the runtime name does, not when the repository does.
owner_repo: flex-auth
subsystem: flex-auth
warden_executes: false
@ -898,8 +924,8 @@ entries:
delegation:
mode: interim
intended_owner: key-cape
blocked_on: "Narrowed again 2026-09-09: the AUTHORITY is answered, the ARTIFACT is not. railiance-platform (msg 7c7228ac) confirmed steps 1-2 are theirs: executed by the platform operator attended, never by ops-warden, secrets-engine autonomously, or any unattended agent; transport is the governed openbao-platform-admin-login lane invoked only through `warden access openbao-platform-admin-login --exec -- <command>` with a unique metadata receipt path (RPF-WP-0017 output containment); authority is founder_required attended OIDC via netkingdom role=platform-admin. What is still missing is a reviewed rotation CCR — a two-custodian CAS rotation with a service restart is a distinct version-guarded operation, not an implementation detail of this lane, and it must name the CAS precondition and expected version on both custodians, sibling-field preservation, the restart window, bounded predecessor retention, and the reconcile-to-same-version failure step. That CCR is railiance-platform to write under RPF-WP-0035 once an owner asks for the rotation; ops-warden has asked key-cape whether to schedule it. Executable precedent for the same two-custodian shape: railiance-platform scripts/keycape_approval_custody.py, with its dated receipt under docs/evidence/ and review packet under docs/credential-lane-designs/. Prior (2026-09-08) narrowing to rotation steps 1-2 only: successor generation and the CAS write to both custodians (platform/workloads/rapp-qonto/keycape-client field client_secret, and sso/keycape-rapp-qonto-client key client-secret) remain custody/deployment acts. The key-cape-native exchange now exists (keycape service-token, 2026-09-05, KEY-WP-0014-T03) and step 3 verification exists as one command (keycape verify-client, 2026-09-08, including predecessor rejection and identical-secret detection); both are documented in key-cape/docs/native-authentication.md. The prior blocker recorded both as absent, which was accurate on 2026-08-28 and is not accurate now — corrected by key-cape (msg 08d42f47). Re-checked against key-cape source 2026-09-08."
reviewed: "2026-09-09"
blocked_on: "CHARACTER CHANGED 2026-09-10 (key-cape msgs 10cf8fca, 546f76e4), substance unchanged. This is no longer blocked on an OPEN QUESTION: the authority is named, the transport is named, and the rotation CCR is available on request. It is blocked on a DECISION TAKEN — key-cape put the question to the operator rather than answering for him, and the answer is NOT YET, with the offer standing open. ops-warden routed the ask and deliberately did not make it on key-cape's behalf (ADR-0003): a routing errand that implies an owner request manufactures a prepared CCR nobody decided to want. This schema carries no field distinguishing 'no authority exists' from 'authority exists, unexercised by owner decision' — the second is what is true here, and it is recorded in prose because inventing a delegation field to hold it would be a catalog change made to describe one lane. NOT A DEADLINE, and not remediation: key-cape checked and there is no incident behind it. KEY-WP-0011 recovered a real exposure on 2026-08-23, but the rapp-qonto client secret was not in that payload — it is an env: secretRef from a separate Kubernetes Secret, never inline in config.yaml, enforced by config validation. So this is lifecycle hygiene, which may wait for a chosen window; if anyone is carrying it as leftover incident work, it is not. WHAT REOPENS IT (events, never elapsed time): an actual or suspected exposure; the secret's age becoming a stated concern; a consumer requiring proof of rotation; or a decision to prove rotation step 4 before relying on it. Prior state, unchanged in substance: Narrowed again 2026-09-09: the AUTHORITY is answered, the ARTIFACT is not. railiance-platform (msg 7c7228ac) confirmed steps 1-2 are theirs: executed by the platform operator attended, never by ops-warden, secrets-engine autonomously, or any unattended agent; transport is the governed openbao-platform-admin-login lane invoked only through `warden access openbao-platform-admin-login --exec -- <command>` with a unique metadata receipt path (RPF-WP-0017 output containment); authority is founder_required attended OIDC via netkingdom role=platform-admin. What is still missing is a reviewed rotation CCR — a two-custodian CAS rotation with a service restart is a distinct version-guarded operation, not an implementation detail of this lane, and it must name the CAS precondition and expected version on both custodians, sibling-field preservation, the restart window, bounded predecessor retention, and the reconcile-to-same-version failure step. That CCR is railiance-platform to write under RPF-WP-0035 once an owner asks for the rotation; ops-warden has asked key-cape whether to schedule it. Executable precedent for the same two-custodian shape: railiance-platform scripts/keycape_approval_custody.py, with its dated receipt under docs/evidence/ and review packet under docs/credential-lane-designs/. Prior (2026-09-08) narrowing to rotation steps 1-2 only: successor generation and the CAS write to both custodians (platform/workloads/rapp-qonto/keycape-client field client_secret, and sso/keycape-rapp-qonto-client key client-secret) remain custody/deployment acts. The key-cape-native exchange now exists (keycape service-token, 2026-09-05, KEY-WP-0014-T03) and step 3 verification exists as one command (keycape verify-client, 2026-09-08, including predecessor rejection and identical-secret detection); both are documented in key-cape/docs/native-authentication.md. The prior blocker recorded both as absent, which was accurate on 2026-08-28 and is not accurate now — corrected by key-cape (msg 08d42f47). Re-checked against key-cape source 2026-09-08."
reviewed: "2026-09-21"
verified: owner-confirmed
risk: high
workload_ref: