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

Implement §5.3 machine-readably — layer.yaml, checker, conformance tests

Browse source 
The security layer model moved v0.1 -> v0.4 (accepted) after ops-warden's
assent. Both §5 asks from ADR-0010 were adopted: §5.2 now sanctions the conduit
shape on the supplied-authority property, and §5.3 is the declared engine gap
amendment, carrying the four fields verbatim and crediting ops-warden's
delegation machinery as prior art.

Which creates an obligation. §5.3 requires those fields MACHINE-READABLY, and
§11 makes "every direct Tooling client maps to a declared §5.1/§5.2/§5.3 entry"
a mechanical check. ops-warden's declaration was prose in INTENT.md — the repo
that proposed the shape was not implementing it.

layer.yaml is the map: 5 contacts (2 declared gaps, 1 read-only observation,
2 conduits) plus the non-Tooling clients recorded explicitly so the check is
total rather than silently selective.

scripts/check_layer_conformance.py enforces it and found three undeclared
modules on its first run — all false positives (help text, a docstring, and the
doubles library that SIMULATES bao rather than calling it), which is why the
scan now matches invocation shapes instead of the word: an httpx call built
against the configured OpenBao address, or an argv whose first element is the
bao binary.

tests/test_layer_conformance.py adds the §5.2 test the standard says SHOULD
exist: _caller_env() returns the caller's environment unchanged, and proxy.py
is asserted not to reference X-Vault-Token, approle login, or token create — a
conduit that presents its own token is not a conduit.

No assertion on review dates, deliberately: a date-triggered failure breaks the
build on a calendar day with no code change, the same reasoning WP-0033-T05
recorded for blocker staleness.

398 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
This commit is contained in:
tegwick 2026-08-29 02:45:29 +02:00
parent 57d39ede0f
commit f815bb35ca
6 changed files with 448 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

66
.repo-manager/index.json
View file

@ -1,10 +1,10 @@
{
"schema": "repo_manager.index.v1",
"slug": "layer-model-assent",
"slug": "layer-model-v03-review",
"repo_root": "/home/worsch/ops-warden",
"head_sha": "467635e84b99757336ee49d7f0dbf107607d0560",
"observed_at": "2026-08-28T19:30:29.828983Z",
"source_fingerprint": "7dfae4f3d33f6a9503a2c7326b925efb378613e772b39c4dd9b0640a35b85654",
"head_sha": "f289465b90fcdffe2c8bf4a51cc71607747126f9",
"observed_at": "2026-08-28T20:40:26.143458Z",
"source_fingerprint": "a9ae0d530804e039aae34b4902d8609723e9bba4385a501b9a4027911c3b6302",
"source_files": [
".repo-classification.yaml",
"INTENT.md",
@ -55,7 +55,7 @@
"status": "finished",
"title": "Ad Hoc Tasks \u2014 2026-06-27",
"source_path": "workplans/ADHOC-2026-06-27.md",
"uuid": null,
"uuid": "a222c91f-3bb5-58a4-b6b2-f0fb18cdd5c3",
"parent_id": null,
"extra": {}
},
@ -75,7 +75,7 @@
"status": "finished",
"title": "Ad Hoc Tasks \u2014 2026-06-29",
"source_path": "workplans/ADHOC-2026-06-29.md",
"uuid": null,
"uuid": "13fa845f-852e-55ec-a2a5-2296996e0216",
"parent_id": null,
"extra": {}
},
@ -95,7 +95,7 @@
"status": "finished",
"title": "Ad Hoc Tasks \u2014 2026-08-11",
"source_path": "workplans/ADHOC-2026-08-11.md",
"uuid": null,
"uuid": "9f99cc64-4682-5f20-b13e-89af2b6f7c70",
"parent_id": null,
"extra": {}
},
@ -135,7 +135,7 @@
"status": "finished",
"title": "Ad Hoc Tasks \u2014 2026-08-17",
"source_path": "workplans/ADHOC-2026-08-17.md",
"uuid": null,
"uuid": "5c6c2bbb-b944-5afd-b89c-20d865518849",
"parent_id": null,
"extra": {}
},
@ -1192,7 +1192,7 @@
{
"kind": "workplan",
"id": "WARDEN-WP-0033",
"status": "active",
"status": "finished",
"title": "Native lane handoff \u2014 review secrets-engine's catalog admission, and fix what it exposed",
"source_path": "workplans/WARDEN-WP-0033-native-lane-handoff.md",
"uuid": "4627d89b-4b00-562a-81e9-76e96f90fa7e",
@ -1232,7 +1232,7 @@
{
"kind": "task",
"id": "WARDEN-WP-0033-T04",
"status": "wait",
"status": "done",
"title": "Tasks",
"source_path": "workplans/WARDEN-WP-0033-native-lane-handoff.md",
"uuid": "5acac140-a586-5db3-b231-bbf236710786",
@ -2155,7 +2155,7 @@
"status": "finished",
"title": "Ad Hoc Tasks \u2014 2026-07-07",
"source_path": "workplans/archived/260707-ADHOC-2026-07-07.md",
"uuid": null,
"uuid": "90568b1e-8395-5c67-9c69-851ed08ff3d3",
"parent_id": null,
"extra": {}
},
@ -2172,17 +2172,18 @@
{
"kind": "intake",
"id": "WARDEN-IN-0001",
"status": "open",
"status": "closed",
"title": "Assent requested: Staff layer, doctrine vs runbook, and the access lane/rule demarcation",
"source_path": "intakes/intakes.md",
"uuid": null,
"uuid": "01a049ed-bbbc-7520-bc7c-6b0912ca534a",
"parent_id": null,
"extra": {
"record": {
"id": "WARDEN-IN-0001",
"kind": "intake",
"title": "Assent requested: Staff layer, doctrine vs runbook, and the access lane/rule demarcation",
"status": "open",
"status": "closed",
"outcome": "assented",
"origin": "cross-repo",
"origin_ref": "gate-house GH-DEC-2026-001",
"priority": "medium",
@ -2190,8 +2191,35 @@
"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 \u2014 how a worker reaches a host; access-engine owns access rules \u2014 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 \u2014 currently every plane is listed and gate-house appears nowhere \u2014 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 \u2014 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 \u2014 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-28T19:30:28.087109Z"
"updated": "2026-08-28T21:05:00Z",
"state_hub_intake_id": "01a049ed-bbbc-7520-bc7c-6b0912ca534a"
}
}
},
{
"kind": "intake",
"id": "WARDEN-IN-0002",
"status": "open",
"title": "Review requested: security layer model v0.3 \u2014 and does maturity-engine absorb warden route gaps?",
"source_path": "intakes/intakes.md",
"uuid": null,
"parent_id": null,
"extra": {
"record": {
"id": "WARDEN-IN-0002",
"kind": "intake",
"title": "Review requested: security layer model v0.3 \u2014 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 \u2014 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 \u2014 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"
}
}
}
@ -2201,15 +2229,15 @@
"type": "repo.command.applied",
"command": "repo.work.create_intake",
"operation": "create",
"correlation_id": "65d40cdd-5894-440e-9c95-c6bcfe259b66",
"correlation_id": "676e92a9-dc2e-4101-a31c-a584962c25df",
"kind": "intake",
"id": "WARDEN-IN-0001",
"git_sha": "467635e84b99757336ee49d7f0dbf107607d0560",
"id": "WARDEN-IN-0002",
"git_sha": "f289465b90fcdffe2c8bf4a51cc71607747126f9",
"files_touched": [
"intakes/intakes.md"
],
"source": "repo-manager",
"emitted_at": "2026-08-28T19:30:29.829125Z"
"emitted_at": "2026-08-28T20:40:26.143617Z"
}
]
}