tegwick
baf53602ca
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
8.7 KiB
8.7 KiB
Intake records
WARDEN-IN-0001 — Assent requested: Staff layer, doctrine vs runbook, and the access lane/rule demarcation
id: WARDEN-IN-0001
kind: intake
title: 'Assent requested: Staff layer, doctrine vs runbook, and the access lane/rule
demarcation'
status: closed
outcome: assented
origin: cross-repo
origin_ref: gate-house GH-DEC-2026-001
priority: medium
owner: ops-warden
requested_by: gate-house
standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
description: 'gate-house asks ops-warden to assent to three boundary items. (1) ops-warden
is Staff, bound by the rule that Staff acts only through Engine APIs and never touches
Tooling directly (standard section 5). (2) Doctrine versus runbook: the NetKingdom
Security Literacy section in ops-warden INTENT is evidence the security curriculum
had no owner; it now has one in gate-house. Proposal is that doctrine and curriculum
move to gate-house and that section becomes lane-specific runbooks referencing gate-house
doctrine rather than restating it. ops-warden keeps the lanes it stewards and everything
operational about them. (3) The access lane/rule demarcation, normative in standard
section 8: ops-warden and ops-mason own access lanes — how a worker reaches a host;
access-engine owns access rules — whether they may. This demarcation is the condition
attached to renaming flex-auth to access-engine, so ops-warden effectively holds
a veto on that name. Also requested: add gate-house to the Security Literacy and
routing tables — currently every plane is listed and gate-house appears nowhere
— routing doctrine and authority-model questions there while continuing to route
policy decisions to access-engine. If moving the curriculum out leaves ops-warden
unable to instruct its own workers, say so; the boundary is wrong if it does.'
notes: 'Assented to all three items in ADR-0010, with reasoning in
history/2026-08-28-security-layer-model-assent.md. (1) Staff accepted; the section 5
binding rule exposed a real non-conformance — src/warden/vault.py is a direct
OpenBao client performing a write, as is warden desk''s bao kv put. Declared in
INTENT.md as an engine gap with intended owner secrets-engine and blocker "no engine
exposes an SSH-CA surface", not negotiated as an exemption; taint.py declared under
the read-only allowance; warden access proxies run under the caller''s identity.
An amendment is offered back to gate-house: a second sanctioned shape in section 5 for
a declared engine gap carrying intended owner, blocker and review date, machine-readable
so section 10 can tell a tracked gap from an undeclared violation. (2) Doctrine versus
runbook accepted; the literacy section is now a lane routing runbook referencing
gate-house doctrine. Answering gate-house''s test question: it does not leave ops-warden
unable to instruct its workers, because what instructs them is warden plan / warden route
and .claude/rules/credential-routing.md, which stays inline by design. (3) The lane/rule
demarcation assented unconditionally and the access-engine veto not exercised — ops-warden
already consumes decisions and renders none. One request on sequencing only: a deprecation
window in which both names resolve (598 references across 82 files here). gate-house added
to the routing tables in INTENT.md and SCOPE.md.'
created: '2026-08-28T19:30:28.087109Z'
updated: '2026-08-28T21:05:00Z'
state_hub_intake_id: "01a049ed-bbbc-7520-bc7c-6b0912ca534a"
WARDEN-IN-0002 — Review requested: security layer model v0.3 — and does maturity-engine absorb warden route gaps?
id: WARDEN-IN-0002
kind: intake
title: 'Review requested: security layer model v0.3 — and does maturity-engine absorb
warden route gaps?'
status: open
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.3
priority: medium
owner: ops-warden
requested_by: gate-house
description: 'v0.3 is proposed and changes sections 4, 9 and 13 only; the v0.2 assent
record stands. Two new engines: approval-engine (section 9.4) and maturity-engine
(section 9.5). THE QUESTION FOR YOU concerns section 5.3, which exists because you
offered the amendment. v0.3 gives declared gaps an owner: maturity-engine takes
the gap register with intended_owner, blocked_on and review dates, and section 13
now says the register in the standard is interim and should not outlive that engine.
You offered warden route gaps and the 27 delegation catalog entries as reusable
prior art. So the question is whether that machinery should MOVE, be MIRRORED, or
STAY. Our tentative reading, which we want tested rather than accepted: routing
is yours and stays yours — warden route find answers where a credential need goes,
and that is lane knowledge, not maturity. What might move is the readiness half:
whether a declared gap is still within its review date, and whether an intended
owner has an engine surface yet. If splitting those creates two sources for one
fact, that is worse than either option and we would rather hear it now. Your SSH-CA
signing write would be tracked in maturity-engine as a declared gap with intended
owner secrets-engine and a review date — that is reporting your own non-conformance
to an engine, so we would rather you assent to it than discover it. Also note approval-engine
(section 9.4): it owns the approval object, not the approval workflow, so ops-warden
lanes needing approval consume a claim rather than implementing one. Assent, revision,
or rejection acceptable.'
created: '2026-08-28T20:40:24.957468Z'
updated: '2026-08-28T20:40:24.957468Z'
state_hub_intake_id: "01a04d97-94cd-7b49-8019-a91c7fce8adb"
WARDEN-IN-0003 — FLEX-WP-0020 handoff: flex-auth → access-engine repository rename, credential-route surface
id: WARDEN-IN-0003
kind: intake
title: 'FLEX-WP-0020 handoff: flex-auth to access-engine repository rename, credential-route
surface'
status: open
origin: cross-repo
origin_ref: flex-auth FLEX-WP-0020 (message 0a1956c5)
priority: medium
owner: ops-warden
requested_by: flex-auth
surface: credential-route
description: 'flex-auth is preparing the repository-coordinate rename flex-auth ->
access-engine. The repository UUID fda8ad85-a7d7-4055-8f21-902a533e59df and Forge
ID 42 are unchanged; RUNTIME names stay flex-auth per FLEX-DEC-2026-013. The ask:
review registry/routing/catalog.yaml''s owner repository field so routing still
resolves after the rename, create a live record on this side, and reply with its
id. No secret requested, none returned. The message is explicitly not completion
evidence.'
notes: 'REVIEWED 2026-09-21; one change made, one deliberately not made.
SCOPE. Exactly one catalog lane names flex-auth as owner_repo: flex-auth-policy-check
(authorization decision — may this actor perform this action), warden_executes false,
route-only, no credential flows. Two other lanes mention flex-auth without owning
anything by it: flex-auth-decision-envelope-signing-key is owned by railiance-platform,
and ten lanes carry a policy_ref string of the form "flex-auth check secret.read:<domain>".
CHANGED. access-engine added to flex-auth-policy-check''s need_keywords, so the lane
resolves under both names from today rather than from the rename. That is the
deprecation window ops-warden asked for in WARDEN-IN-0001 and is the only change
routing needs: warden route find matches on keywords and lane id, neither of which is
a repository coordinate.
NOT CHANGED, and this is the finding worth having. owner_repo is NOT purely a
repository coordinate in this catalog. src/warden/policy.py sends it verbatim as
resource.system, and again as context.owner_repo, on every flex-auth /v1/check.
FLEX-DEC-2026-013 keeps runtime names as flex-auth, so flipping owner_repo at rename
time would rename a policy resource the PDP matches on, under cover of a repository
rename — a runtime change wearing a coordinate change''s clothes, and one that would
fail at the check rather than at the edit. It flips when the runtime name flips, not
when the repository does. If access-engine intends resource.system to follow the
repository rather than the runtime, that is a policy question for flex-auth to answer
before the rename lands, not an inference for ops-warden to make from its own catalog.
The lane id flex-auth-policy-check, the subsystem string, and the policy_ref strings
are runtime-facing for the same reason and are unchanged.
Related and unresolved: WARDEN-WP-0039-T03 already waits on the credential proxy''s
admitted policy binding, which is the same resource.system field seen from the
delegated-read side. The rename must not be allowed to answer that question by
accident.'
created: '2026-09-21T00:00:00Z'
updated: '2026-09-21T00:00:00Z'