Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013EPuTc18FjU5WFqoSEKH3C
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1276224@bnt-lap001
Assistant-Session: 426ec497-e1c4-4dd3-b417-dfce1ca1dbc3
key-cape corrected two blockers that had stopped being true after our
2026-08-28 source-read:
- rapp-qonto-keycape-client: `keycape service-token` (2026-09-05) is the
native exchange the blocker recorded as absent, and `keycape verify-client`
(2026-09-08) is rotation step 3 as one command. Narrowed to steps 1-2 --
successor generation and the CAS write -- rather than cleared, as they
asked. rotation.automatable -> false so a future executable driver is not
told a lane with no admitted custody transport is drivable; the per-step
truth moves into the steps.
- key-cape-oidc-login: ownership ACCEPTED by key-cape, so verified moves from
asked-and-waiting to owner-confirmed. Lane stays interim -- acceptance
covers the identity half, while the fetch_command yields an OpenBao token
whose mount, role mapping and enforcement are not key-cape's.
Two tests pinned `key-cape-oidc-login` to sitting `asked-and-waiting`, so
answering the question broke them -- they failed on good news. Both now
assert the property instead: an unverified blocker is stale regardless of
date, over whatever lanes are in that state.
Verifying the routing answer against our own front door turned up a defect:
`warden plan` returns `autonomous` for a custody *write* and answers it with
read transports, because it has no read-versus-mutate intent. Recorded as
WARDEN-WP-0038 (proposed) -- the WP-0033-T06 shape, as a class this time.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013EPuTc18FjU5WFqoSEKH3C
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1276224@bnt-lap001
Assistant-Session: 426ec497-e1c4-4dd3-b417-dfce1ca1dbc3
The standard is accepted at v0.7, with SECURITY-COMPANION.md v0.2 as its
operative form. Four ops-warden findings were adopted between v0.4 and v0.7 —
§9.1's two marks, §5's Tooling scope rule, §6.4 obligation 1's second limb, and
§13.1's existence — and both ops-warden declaration artifacts are now cited in
the text as the estate's reference forms.
INTENT.md gains frontmatter (layer: Staff, pep_shaped: true) because §11 requires
a machine-readable declaration and prose cannot distinguish a declaration from a
transcribed review. The note now covers the agent principal (§3.4), the PEP
shape, the attributive evidence position, and the role the companion assigns:
the estate is told to ask ops-warden which lane, which credential, which route.
SCOPE.md records what is actually shipped against v0.7 and the honest conformance
state — declared gap, which is tracked non-conformance, not conformance.
The assessment checked every obligation against shipped code rather than intent.
Three gaps survive:
- §9.7.2 requires a PEP to state one revocation visibility deadline. Ours is
unstated, and the honest value is uncomfortable: the cert TTL, up to 48h. A
cert outlives revocation of the decision that authorized it — no CRL, no KRL
distribution. That is a design property never written down, which is exactly
what §9.7.2 exists to force into the open.
- §3.4 rule 1 forbids standing credentials and requires issued, attributable
authority. ADR-0004's boundary keys on WARDEN_AGENT_ID, which an agent sets
about itself. key-cape now issues a real coding-agent identity, so the
ops-warden half can stop being advisory.
- §9.6 cadence remains undeclared. Attributive, so SHOULD not MUST, but silence
through two reviews is the one outcome that is not defensible.
WARDEN-WP-0034 addresses all three, plus the discoverability gap the companion
creates and two items to route rather than absorb.
402 tests pass, ruff clean.
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
railiance-platform accepted ops-warden revision 0fae0904 on 2026-08-23, in
RPF-WP-0017 (status: finished), together with railiance-infra approval at
186b030 and all five acceptance criteria met. T02 has been sitting `progress`
on a gate that was already open.
Verified rather than trusted: the receipt at bc1966da hashes to
d2ba444ed16989590325697e69d25283dc75a9432c29a72e627e80bf9fd987e4, matching
their record exactly.
One reason it went unnoticed is an identifier mismatch — T02 cites the
remediation interface as RAILIANCE-WP-0026-T01, but it is RPF-WP-0017-T01 in
the owner repo, and the cited id resolves to an unrelated workplan there.
Their acceptance is source acceptance only and authorizes no live drill, so
T02 stays progress: what unblocks is preparing a NEW scenario, which needs a
fresh human GO and is the platform owner s to execute. Surfaced, not taken.
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
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 live-file pass missed these: archived ad-hocs carry a YYMMDD- filename
prefix, so the ADHOC-* glob did not match them. They still derive from the
forge, so they are live records rather than dead files.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
`ADHOC-YYYY-MM-DD` is unique per date but not per repository, so any two repos
opening an ad-hoc on the same day collide. The 2026-08-26 fleet projection
reset refused 9 records for exactly this reason.
Canon (work-record-types_v0.1, CUST-WP-0066) settled the form as
`{PREFIX}-WP-ADHOC-YYYY-MM-DD`, filename unchanged, and grandfathered existing
ids on the condition they are never *silently* re-derived. This is the explicit
migration that clause allows for.
The hub id is derived from the record id, so a changed id is a different
record: stale state_hub_*_id fields are dropped and fix-consistency re-derives.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
These workplans exist only in the retired local hub. Their random pre-ADR-007
identifiers are refused by C-06 as stale references, so they cannot be
registered. Deriving from the canonical record id takes no identity from
anything: central does not hold them and the old ids die with the cache.
Records central already holds were deliberately left untouched.
Refs CUST-WP-0068-T06
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
The file carried an identifier minted by the retired local hub while central
held a different record for the same file — ADR-010's same-filename,
different-UUID duplicate-registration class.
Central is authoritative (ADR-010 decision 1) and decision 6 says to mitigate
by changing the repository file rather than editing central, so the file adopts
central's id. The cache-side id dies with the cache.
Refs CUST-WP-0068
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
risk-nexus accepted the offer to match their convention rather than grow a second
one, and published it: 14d critical/high, 30d medium, 60d low, nothing auto-closing
on staleness alone. Their preference — point warden route gaps at those windows and
the two registers agree without a shared mechanism — is better than a joint tool.
blocker_stale_days() now maps lane risk onto those windows. A flat 14 would have
been wrong in both directions: too aggressive for a low-risk pointer, and it treated
an admin PAT lane the same as one.
ungraded takes the shortest window, not the longest. ADR-0007 makes an absent grade
a defect and ADR-0008 makes a grade cover the whole path, so a lane nobody graded is
the one whose blocker deserves least trust. Encoding that as 60 days would have been
the fail-open default this repo already fixed once.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Routed, not absorbed. It is an identity and issuance question about a principal
authenticating to OpenBao, which is key-cape's. secrets-engine drew the same
boundary at us an hour ago over key-cape-oidc-login and we agreed with them.
Named zone-engine as interested and user-engine as explicitly not involved, so
neither is concluded by inference. Asked for accept or refuse; a refusal with a
pointer is an equally good answer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
railiance-platform asked for a generated list to consume instead of hand-
maintaining agent-high-risk-boundary. Hand-maintaining it is what let the two
lists drift for four lanes in RISK-F-0009.
19 high-risk lanes, 14 concrete data paths, 5 without a single KV address listed
separately so absence does not read as omission. Carries catalog_revision and a
dirty flag. fields is null where unestablished, never a one-element guess.
The header states plainly that this is an input and not a policy: railiance-
platform owns the deny set and may deny more, less, or dispute a grade. ADR-0002
survives the handoff.
Two CI tests guard staleness, because a consumer applies this to a live control.
Note the immediate consequence of T02: 2 uncovered against a policy they closed
to 0 yesterday.
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>
secrets-engine accepted five interim lanes and drafted the entries itself rather
than wait for our contribution. Reviewing them turned up a defect in our own
grading model, which is now T02 and the most consequential item in the plan.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The token was never expired and the verification script was never written. Both
were recorded here as fact for a day. Noting it as an instance of the re-read-
your-blockers rule rather than quietly correcting it.
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>
agent-high-risk-boundary denies 5 data paths, covering 6 of ops-warden's 17
high-risk lanes. Eight high-risk lanes with concrete KV paths are not denied,
four of which were already graded high before the 2026-08-19 regrade — the
divergence is pre-existing and the regrade only made the lists comparable.
This is the layer that matters most: warden access exits 7 for all 17, but that
protects only the ops-warden path. The policy protects a direct bao kv get,
which is the 2026-07-16 vector.
Routed to risk-nexus as RISK-F-0004 with fix_owner railiance-platform, since the
policy is theirs. Live confirmation outstanding — ops-warden's OpenBao token is
expired, so this is a static file-vs-catalog comparison and the finding says so
rather than implying it was verified against the server.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The mechanism behind RISK-F-0003 was sharper than the finding described.
is_high_risk was risk == "high", but risk was never absent at the model layer:
RouteEntry.risk carried a dataclass default of "standard". An omitted grade was
not unhandled, it was actively resolved to the permissive value — fail-open by
construction, which is why nothing ever warned.
The default is now "ungraded" and is_high_risk returns true for anything outside
an explicit low-risk vocabulary (standard / low / accepted). An omitted grade and
an unrecognised grade from a newer catalog both resolve to high, so the boundary
fails safe in both directions rather than reading an unknown value as permission.
test_every_repo_catalog_lane_is_explicitly_graded is the CI gate that stops an
ungraded lane being committed, per ADR-0007: absence is not a grade.
"accepted" is in the low-risk vocabulary deliberately, ready for the
maturity-derived default — an experimental-context lane may be explicitly
accepted, which is a graded decision rather than an omission.
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>
Splits RISK-F-0003's response in two. T05 grades the five exec_capable ungraded
lanes explicitly — a live gap in a shipped ADR should not wait months for the
zone model. T06 makes absence impossible once the model says what absence means,
per the operator's maturity-derived default.
Grading is flagged as judgement requiring operator sanction, not backfill.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Amended by net-kingdom as canon owner of tenancy-posture_v0.1, answering
ZONE-WP-0001-T01.
T01: organization_posture does not fold into zones and does not belong in a
per-repo declaration — it is a fleet-wide time-varying scalar. Hand it over as an
input.
T03: zone membership is declared in tenancy.yaml under a reserved zones: key
(canon Decision 5.6). ops-warden has no tenancy.yaml, so this now implies
declaring the six-axis posture vector too. Also records why this declaration may
not set stance: a declarer that sets its own stance makes exempt conformant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
flex-auth reviewed ZONE-WP-0001 as the consuming PDP and two findings
land on the ops-warden consumer side:
T02 - fail_closed is not expressible by a PDP. Fail-open describes what
warden sign does when flex-auth is unreachable, so no decision exists to
carry it. The replacement for policy.enabled is two things: stance,
which arrives in the decision, and failure mode, which stays local and
is declared per zone.
T02 - build_flex_auth_registry.py:77 already emits a hardcoded
trust_zone: platform that no policy reads. Resolve that before
compiling zone membership rather than adding security_zone beside it.
T03 - the declaration must say whether a zone rides the actor (subject)
or the lane (resource); in the compiled registry an actor is both.
No flex-auth registry schema change is needed - metadata, labels and
attributes already flatten into the rego input.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
zone-engine is seeded and owns the security zone model as ZONE-WP-0001. Under
ADR-0005 ops-warden implements one lane narrowly and routes the rest, and an
estate-wide enforcement model is not a lane to absorb — it was ops-warden's
deferred flip that exposed the gap, not ops-warden's model to define.
WARDEN-WP-0032 is rewritten as the consumer side: hand the estate inputs to
ZONE-WP-0001-T02 (27 catalog lanes, the actor inventory, the three posture axes,
the three controls the model must express, and the compiled-registry path),
then replace policy.enabled with a zone-aware control and amend ADR-0006 to say
ops-warden follows the model rather than owning it.
ADR-0006 and SCOPE updated to point at zone-engine, which joins the related
repositories table.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Expands the placeholder into a real plan, grounded in what the estate already
has rather than first principles:
- tenancy-posture_v0.1 is the structural model to follow (canon standard +
per-repo declaration + "accuracy, not altitude"), and its §14 adoption stance
is "structure, not tooling" — a precedent about sequencing.
- Reefs are substrate placement zones with real risk statements. A security
zone is not a reef; repo-manager's own "topology is not readiness" applies
here as "placement is not posture".
- flex-auth is latency-critical and already consumes a compiled registry
snapshot, so zone membership should reach the PDP by compilation rather than
a synchronous lookup in the decision path.
- warden plan already returns verdicts with reasons; zone-aware enforcement
extends that machinery instead of growing a parallel one.
T01 settles ownership before any modelling, because it decides which repo the
rest lives in: canon standard, a zone-engine runtime authority, or flex-auth
policy data. The recommendation is canon-first with zone-engine named as an
explicit promotion — but the time-boxed refactor exception is the case that
could justify an engine immediately, since an expiring grant is state and state
wants an owner.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
