T04 was the last open task, waiting on key-cape to accept or refuse ownership of
the coding-agent OpenBao issuance identity. They accepted, in KEY-WP-0009-T03,
on 2026-08-23: codex-railiance-platform is published in their
config/service-clients.example.yaml with subject service:codex:railiance-platform,
role coding-agent, scope openbao:login, 15m lifetime, and the service-auth
semantics in docs/openbao-service-auth-contract.md. The split is the one we
routed for — KeyCape issues, railiance-platform binds the OpenBao role, OpenBao
enforces, no secret value in either repo.
We found it by reading their repository. KEY-WP-0009-T04 records replying to
ops-warden; the inbox has zero messages from key-cape, read or unread. The task
sat `wait` on an answer that already existed.
That is T05's own lesson arriving on T04: a blocker is a claim about the world at
a date. So the same pass re-verified the two lanes pointing at key-cape against
their source instead of bumping dates:
- rapp-qonto-keycape-client -> verified: source-read. KEY-WP-0009-T02 did add
bounded service-auth, but that is client_credentials JWT issuance for OpenBao
machine login and does not front this client_secret_basic exchange or its
rotation. Blocker stands, now with evidence rather than memory.
- key-cape-oidc-login -> asked of key-cape today, which the entry had recorded
as still outstanding since 2026-08-21.
Also cleared the inbox that hid this: 9 stale unread, all superseded by shipped
work, with late closes sent to secrets-engine and llm-connect on the two threads
that had asked ops-warden something and never got an answer.
391 tests pass, ruff clean, boundary coverage 0 uncovered.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YWBMovyFoy9RRrfL7zKvPJ
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014535@bnt-lap001
Assistant-Session: d0036016-73e8-4da1-8e47-563e3ab39a3c
The 90-day --stale-days default on `warden route gaps` was not a loose threshold,
it was an inert one: the delegation register was created 2026-08-15, so it could
not have fired before November. It was inherited from the catalog pointer cadence
and applied to a claim with a completely different half-life.
Two changes. DEFAULT_BLOCKER_STALE_DAYS = 14 now governs interim blockers, while
DEFAULT_STALE_DAYS = 90 keeps governing pointer freshness -- "is this the right
owner and page" is quarterly, "has the owner answered" is not. 14 is calibrated
on blockers that actually cost something: ten days for the secrets-engine lanes,
one for RISK-F-0001, roughly fifty for FLEX-WP-0007.
The second change matters more. `reviewed` records when someone touched an entry,
which is indistinguishable from re-checking it -- six lanes read as freshly
reviewed today because I typed in them. `verified:` now says how the claim was
established, and asked-and-waiting explicitly does NOT count: that is the state
the secrets-engine blocker sat in for ten days while looking current. A lane in
that state is stale at zero days old, and key-cape-oidc-login proves it works.
8 of 14 interim lanes are honestly marked unverified rather than given a fresh
date they did not earn.
--fail-on-stale exits 3 for a cron or gate. No CI test on age: a date-triggered
failure breaks the build for whoever commits next instead of whoever owns the
blocker. The CI test is structural -- every interim lane must record how it was
verified -- so it fails on the commit that introduces the omission.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three fixes, the first of which is my own botched edit from an hour ago.
1. The "six delivery modes" claim was never actually removed. I ran a str.replace
with no assertion on the result, it matched nothing, and the print said "ok".
The wrong claim sat in all seven lanes while I told secrets-engine it was
fixed. This edit asserts 5/1/1 and fails loudly otherwise.
2. Five lanes ACCEPTED (SECRETS-WP-0006, decision ae676382). The blocker now
records that secrets-engine holds the entry and that the interim proxy retires
on approved native verification in T05 -- not on acceptance. Retiring early
would drop the cover before the replacement is proven.
3. Two lanes REFUSED, and both refusals are right:
- key-cape-oidc-login: intended_owner corrected secrets-engine -> key-cape.
Login and identity-token issuance were never secrets-engine's. Not yet asked
of key-cape, and the record says so.
- openbao-api-key: not a delegable lane at all -- a <domain>/<workload>/<bundle>
routing template, not one secret lane, so there is no front door to own.
interim -> native with railiance-platform named: OpenBao is itself the front
door and this entry is a pointer to it, never an interim cover. It should
not have been inflating the interim count.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
secrets-engine reviewed our catalog metadata while drafting their five entries
and graded issue-core-ingestion-api-key and reuse-surface-hub-write-token high.
We had both as standard, and had deliberately regraded them DOWN on 2026-08-19.
They are right. Both paths carry a second credential our grade never looked at --
GITEA_BACKEND_TOKEN (CCR-2026-0002, a deliberate field-set decision) and a
dual-consumer webhook HMAC (CCR-2026-0005). Neither is recovered by rotating the
credential the lane is named after.
The defect is structural: we graded the lane by its headline field, but a read
returns every field at the path. Worse, the evidence was already in the CCRs we
cite as authoritative -- not missing, unread -- and a test asserted the wrong
answer, so a correct first-pass grade got overruled by it.
ADR-0008 records the rule: a grade covers every field its path discloses.
ADR-0007 is unchanged and still governs; this says what the grade is of.
Six of the remaining standard lanes have no KV path. Two have paths and no field
evidence; per ADR-0008 they are stated as unknown rather than assumed, and left
for operator-sanctioned grading.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The blocker asked whether `secrets-engine exec --catalog` generalizes over
arbitrary OpenBao lanes. Asked 2026-08-11, chased 08-15, never answered. Rather
than chase a third time, read their code.
It generalizes by construction: catalog.py takes mount and path as plain fields,
`kv` is a general kind, and six delivery modes are supported. What exists is two
catalog entries -- warden-sign and whynot-design-npm-publish -- which are exactly
the two lanes this register already marks native.
So the blocker was misframed for ten days. Not "can the engine do this" but "who
authors the entries and who operates them", which is smaller and had never been
put to them. Register now says that, and ops-warden has offered to author all
seven entries against their schema for them to accept or reject.
Applying the rule this repo already had and missed twice this week: re-read a
blocker before trusting it. A blocker is a claim about the world at a date.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
issue-core asked us to drop a CoulombCore/port-18765 bridge topology from
activity-core-issue-sink. That topology was never in this repo — the only address
the playbook carried was a local-dev 127.0.0.1:8765 example. What was actually
stale was step 5, which still told workers to coordinate with railiance-platform
"when the canonical path ships"; it shipped 2026-07-02 and the lane is active.
So: point at issue-core's SCOPE.md for the production address rather than
restating it here (ADR-0001), state plainly that no bridge or forwarded port is
involved so the next reader does not re-derive the retired topology, and route
step 5 through warden route / warden rotate-guide instead of a read.
WP-0032-T01 closes as done. What was owed was inputs, not a design, and
ZONE-WP-0001-T02 is done carrying all of them — including the two that were
corrections to ops-warden's own claims (organization_posture, refused by
net-kingdom; and the workload join key, which this repo wrongly said did not
exist anywhere).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes the RISK-F-0003 exposure. All 14 ungraded lanes now carry an explicit
risk grade with its justification in the entry: 17 high, 10 standard, 0
ungraded. The agent read-boundary now fires (exit 7) on lanes that were silently
outside it.
Graded on merit rather than defensively. A first pass marked two ordinary
internal workload secrets high; test_high_risk_lanes_classified asserted the
opposite and was right, so both were regraded down. high means disclosure into a
logged context is damaging beyond what rotation recovers. inter-hub-bootstrap-ssh
is high conservatively, with the reason in the entry so it is regraded with
evidence rather than assumed down.
ADR-0007 records the rule the grading rests on: build-stage permissiveness
applies to controls that gate work, not to controls that prevent credential
disclosure. The test is friction, not severity — the read-boundary blocks nobody,
since --out/--exec/--wrap remain available, so relaxing it buys nothing. A
blocked operation is recovered by retrying; a credential in a logged transcript
is not recovered by rotation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Five rules that governed this repo lived in wiki prose, a workplan, and a
comment at the top of catalog.yaml. All were followed; none was addressable.
A reader outside ops-warden could not cite one, could not tell whether it was
current, and — the point of this change — could not tell whether it was ours
to change or someone else's that we merely obey.
ADR-0001 The routing catalog is a pointer layer, never a second copy
ADR-0002 ops-warden is a transparent conduit, never a secret broker
ADR-0003 Cover gaps, but never silently own them
ADR-0004 High-risk lanes refuse raw value streaming to agent sessions
ADR-0005 Implement one lane narrowly, route everything else
Each carries owner: ops-warden, which is the load-bearing field. It says we
follow the rule AND we are responsible for changing it — by superseding ADR,
never an in-place edit. The failure this prevents runs both ways: a rule we own
mistaken for inherited canon never gets fixed, because we wait for an owner who
does not exist; inherited canon mistaken for ours gets quietly bent, and the
drift is invisible until it breaks a repo that trusted the canonical version.
Rules we follow but do not own — NetKingdom canon, the IAM profile, the
credential-management standard, the-custodian's ADR-001 workplan convention —
are cited, never copied into docs/adr/. Copying them would recreate exactly the
second-source-of-truth failure ADR-0001 exists to prevent. architecture.md also
now flags the three-digit/four-digit ADR-001 vs ADR-0001 collision, which is
itself an ours-versus-inherited confusion waiting to happen.
Publication verified rather than assumed: all five render through policy-nexus
tools/render.py, and owner reaches the reader in three places — the page eyebrow
(render.py:346), the index Owner column (build_site.py:123,137), and the
publication manifest. build_site.py:179 makes title/status/owner required, so
ownership cannot be dropped on the way out. policy-nexus publishes and never
writes back; docs/adr/ stays the source of truth.
Documentation adapted: SCOPE.md gains a Governing rules section and an orientation
entry; .claude/rules/architecture.md replaced its stub with the ADR index, the
owned-versus-inherited rule, and ADR-over-wiki precedence; finding-routing.md's
ADR-gap section closed; catalog.yaml's no-double-source header now cites ADR-0001
rather than the originating workplan.
uv run pytest -q → 338 passed, 4 deselected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Inbox triage (ADHOC-2026-08-17), three messages, all answered and marked read.
flex-auth (FLEX-WP-0015 T02) reported that /v1/check and /v1/batch_check
authenticate no caller — any workload with cluster reach can assert any subject
and get an authoritative allow. It lands here because ops-warden owns workload
identity in this estate and its pre-sign gate is a flex-auth PEP.
Recommendation recorded in wiki/NetKingdomSecurityMap.md: Kubernetes
ServiceAccount TokenReview with a projected, audience-scoped token. Rejected the
shared-secret header — it manufactures a risk: high lane with a rotation owner
per caller on the authorization path, the exact interim-proxy debt WP-0030
exists to stop growing. Deferred mTLS pending an owner for a workload X.509 CA.
Bind `system` to the authenticated SA at auth time, but keep the resource-type
allowlist in the policy package rather than the admission layer. Warn-only
rollout; policy.enabled must not flip while /v1/check answers unauthenticated
callers. Recorded as a pattern, not a catalog entry.
Catalog delegation refreshes:
- coulomb-social-runtime-env: USER_ENGINE_PROXY_SECRET ownership settled
(decision 8fe22037, USER-WP-0021) — intended_owner stays railiance-apps,
answered clause dropped from blocked_on, consumers: [user-engine] recorded.
- rapp-qonto-keycape-client: blocked_on no longer implies an in-flight
KEY-WP-0008 dependency; the key-cape-native exchange command is unopened work.
uv run pytest -q → 338 passed, 4 deselected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every execution position is now explicit. Catalog entries carry
delegation.mode (permanent / native / interim) with intended owner and
blocker. warden route gaps lists the interim set. Promotion requires
the ownership question. Doctrine lives in AccessRouting.md; the
register was published to the named owner repos.
The catalog pointed at wiki/CredentialRouting.md#credential-routing-catalog,
which does not exist; the live heading is "Routing catalog index". Restores
tests/test_routing.py to 61/61.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Founder completed paste-once-provision; glas-harness/GLAS-WP-0002-T02's
live verification succeeded for real (AppRole login, KV v2 read, real
OpenRouter call, real commit, OPENROUTER_API_KEY unset throughout).
Two real fixes recorded along the way: platform-admin's policy needed
a new reins/* entry (every other KV mount was already listed there),
and the consumer policy itself needed the KV v2 data/+metadata/ path
shape instead of the bare KV v1 path it was originally written against.
Full account in ops-mason/plans/rein-openweights-openrouter-approle.md
section 7.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Proposed by ops-mason (MASON-WP-0001-T05), built and approved 2026-07-27
(Bernd Worsch). New pointer-only entry mirroring
agent-harness-binky-mail-approle's shape: AppRole login, no operator
present, scoped to exactly one KV path (reins/rein-openweights/openrouter,
new reins/ KV v2 mount -- no existing mount fit without widening scope
beyond what was approved). status: draft until the founder completes
paste-once-provision and glas-harness/GLAS-WP-0002-T02's live
verification succeeds.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ship posture-aware access planning: organization_posture=build (axis C),
catalog freshness warnings, warden plan verdicts, localhost founder desk,
and playbook/agent guidance that retire /tmp file-drop patterns.
Compose route catalog + handoff rather than a second routing layer.
PAT attended-minted and stored at platform/workloads/forgejo/forgejo-admin
under field API_TOKEN (re-stored from initial Token field to match
CCR/catalog/playbook fetch_command). Positive fetch verified: PAT valid
against forgejo.coulomb.social (/api/v1/user -> login=tegwick, is_admin=true).
- catalog: draft -> active, resolvable: true, verification evidence, reviewed 2026-07-13
- playbook: header active/resolvable, drop post-promotion caveat
- workplan: T04 done
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Draft routing entry and worker playbook for Forgejo site-admin PAT custody
in OpenBao. Workplan WARDEN-WP-0025 tracks approval, apply, and verification.
RAILIANCE-WP-0011-T03: point reuse-surface-hub-write-token catalog,
playbook, and tests at bao kv get on platform/workloads/reuse/reuse-surface/runtime-secrets;
kubectl documented as break-glass only.
REUSE_SURFACE_TOKEN is custody of the Railiance01 K8s secret reuse-surface-env,
not OpenBao. Workers blocked on hub register can now discover the lane via
warden route find and obtain it through the documented kubectl handoff.
RAILIANCE-WP-0009 T06 / RAILIANCE-WP-0010 T06 (CCR-2026-0002, CCR-2026-0003):
both OpenBao KV paths are live, ESO delivers the Secrets in cluster, and
positive/negative access verification is audit-logged. Catalog entries gain
concrete zero-placeholder handoffs (exec_capable, resolvable); draft tables
and playbook gates updated; routing tests repointed to still-draft lanes.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Document the railiance-platform credential broker as the owner-native path
for scoped VAULT_TOKEN needs. Add catalog entry, playbook, and doc updates
so warden route find ranks the broker lane first; manual export remains a
documented fallback only.
secrets-engine (SECRETS-WP-0003) shipped a native secret-exec front door
(`secrets-engine route/exec`, decision e6381a56) and asked ops-warden to route to it.
Bernd's call: route-primary, proxy-fallback — surface the secrets-engine exec as the
primary path for owned lanes, keep `warden access --exec` as a transparent fallback.
T1 — RouteEntry gains exec_owner/exec_command/pointer_command (+ has_native_exec),
screened for secret material like the other handoff fields. whynot-design-npm-publish
points its native exec at secrets-engine. `warden access` renders Primary (secrets-engine
exec) + Fallback (warden proxy); route/access JSON gain the fields and a native-exec-aware
next_action. Tests added; 217 pass, lint clean.
T2 — credential-routing.md adds secrets-engine as the secret-exec owner (route primary,
proxy fallback); SCOPE adds secrets-engine to Related Repos and records the npm lane as
production-exercised (@whynot/design@0.4.0); playbook leads with secrets-engine exec and
fixes the fallback one-liner (--field NPM_AUTH_TOKEN, --no-policy) per whynot-design.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
railiance-platform finished provisioning the whynot-design npm publish lane
(CCR-2026-0001, commit 8f617fc: active, readiness=ready, resolvable=true, positive
fetch + negative denial verified). First concrete warden access --fetch-resolvable
non-SSH lane — end-to-end proof of the WP-0014 conduit + WP-0017 discoverability.
T1 — catalog entry whynot-design-npm-publish (active, exec_capable) with the
owner-confirmed zero-placeholder handoff: path platform/workloads/coulomb/whynot-design/
npm-publish (the superseded whynot-design/whynot-design/... form is not used), field
NPM_AUTH_TOKEN, OIDC role whynot-design-workload-kv-read, policy + flex-auth ref. Added
wiki/playbooks/whynot-design-npm-publish.md.
T2 — RouteEntry.resolvable (active + exec_capable + no <…> placeholder), surfaced in
route/access --json; Catalog.find resolves an exact catalog-id first so
`warden access whynot-design-npm-publish` is deterministic. Tests added; fixed a
no-match test query that substring-collided (no ⊂ whynot). 213 pass, lint clean.
T3 — notified whynot-design (zero-placeholder command + resolvable gate + path
correction) and confirmed activation to railiance-platform. Sibling lanes stay draft
per their deferral.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds a lane: secret|login field to RouteEntry. The login lane is an
interactive auth bootstrap: it skips the caller-auth precheck (no token
yet — that's the point) and the secret-read gate (it establishes the
identity the gate needs), runs the owner's login command interactively
as the caller via inherited stdio, and rejects --exec. The token stays
in the caller's own store; warden never captures it (G2 holds). Audited
as action: login. key-cape-oidc-login populated as the reference login
entry. Advisory proxy hint updated now that T3 has shipped.
172 passed, lint clean.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds optional assist-layer fields (auth_method, path_template,
fetch_command, exec_capable, policy_ref) to RouteEntry, parsed and
secret-screened in catalog.py. Handoff fields are templates/pointers
only — _assert_no_secret_material rejects known token prefixes and
high-entropy runs, and exec_capable requires a fetch_command. The
openbao-api-key entry is populated as the reference example (covers the
coulomb_social npm shape).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add platform-secret playbooks for issue-core ingestion, OpenRouter llm-connect,
object-storage STS, and database dynamic credentials. Extend the routing catalog
with draft entries and implement `warden route list --stale` for quarterly drift
review. Document the review cadence in AccessRouting and mark the workplan finished.
Promote Inter-Hub bootstrap lane to active catalog with worker checklist,
attended/unattended branches, and flex-auth/OpenBao pointers. Mark WP-0012
T2/T3 done; ops-bridge tunnel playbook shipped in prior WP-0013 commit.
Agents can discover the activity-core → issue-core emission contract via
`warden route show activity-core-issue-sink` instead of messaging ops-warden
for ISSUE_CORE_API_KEY. The playbook points at owner-repo docs per the
no-double-source rule.
Implements WARDEN-WP-0010 (charter + pointer catalog). ops-warden issues
short-lived SSH certificates and routes every other credential need to the
subsystem that owns it — no desk metaphor, one execution lane.
- wiki/AccessRouting.md: role/boundary, issue-vs-route matrix, anti-patterns
- registry/routing/catalog.yaml: machine-readable pointer layer (6 active + 1
draft). No-double-source rule enforced structurally — authored steps/cert_command
only on the warden_executes:true SSH entry; every wiki_ref anchor resolves
- wiki/CredentialRouting.md: catalog-keyed index + no-duplicate-interfaces note
- INTENT/SCOPE/AGENTS/repo-boundary/capability: aligned to the new framing;
SCOPE notes A3 -> A4 lands with WP-0011 warden route CLI
- WP-0011/0012 + WP-0010: state_hub id writeback; WP-0010 marked done
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
