ops-warden/intakes/intakes.md

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'
state_hub_intake_id: "01a0c153-98e1-7705-bf82-a58c85df980f"