ops-warden/workplans/WARDEN-WP-0044-security-case-follow-through.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	depends_on	related_repos	state_hub_workstream_id
WARDEN-WP-0044	workplan	Follow through on KnownSecurityCases along their type's route	infotech	ops-warden	active	implementation	claude-code	netkingdom	2026-10-08	2026-10-09		net-kingdom ops-mason key-cape railiance-platform	f7e81013-6868-5d99-8528-ba75a442eca9

WARDEN-WP-0044 — Follow through on KnownSecurityCases along their type's route

Why

NetKingdom is introducing SecurityCaseTypes (net-kingdom NK-WP-0048, canon security-case-types_v0.1, proposed). Once a case of an implemented type is accepted and ops-mason has materialized its structure (MASON-WP-0010), ops-warden carries out the remaining steps. These are the owners' declared entry points, run on the authentication path the type defines, followed by the type's verification.

Today ops-warden routes needs and, for exec_capable lanes, proxies fetches as the caller. It does not yet know about cases, and each new integration ends with a founder running a hand-written script (for example the proposed KEY-WP-0038-T02 rollout). This plan gives ops-warden the follow-through role, without widening what it may do: each step still runs under its owner's entry point and the caller's identity.

Tasks

id: WARDEN-WP-0044-T01
status: progress
depends_on: [NK-WP-0048-T03]
priority: high
state_hub_task_id: "ef0920fc-418e-52cb-acff-9a5c0c728bf5"

T01 — Define the type's follow-through section

Propose the follow_through part of the SecurityCaseType schema together with net-kingdom. For each step it names the owner entry point, warden_executes, the auth method and lane, whether an attended human login is unavoidable (with the type's justification), and the verification command. Write it for the first type, oidc-browser-relying-party, covering key-cape client registration, custody minting and LLDAP group membership.

2026-10-08: NK-WP-0048-T03/T04 landed with a drafted section. Review is in history/2026-10-08-oidc-rp-follow-through-review.md. It requires three changes before T02: a per-step lane, a narrow warden_executes, and value_handling. It also lists four refinements. This task is done when net-kingdom acknowledges the review (NK-WP-0048-T05).

2026-10-09: R4 was withdrawn in favour of ops-mason's per-case {consuming_service}-keycape-client, with the entry body templated in the type (R4′, see the addendum in the review).

2026-10-09: the revised 1.0 type and canon now carry R1–R3, R4′, R5–R7. warden case check-type <type.yaml> (src/warden/case_type.py, tests in tests/test_case_type.py) checks a type's follow-through mechanically: the live type is schema-conformant, with one attended session (key-cape-oidc-login). It is not yet plannable, because two lanes are not in the catalog: identity-provisioner-groups (net-kingdom) and keycape-client-secret-generate (railiance-platform). These gate T02, not T01. T01 still closes on net-kingdom's acknowledgement (NK-WP-0048-T05).

2026-10-09: ops-warden cannot add identity-provisioner-groups as the type declares it. The provisioner accepts only user-engine's runtime token and admits only user-engine pods, so no caller-identity path exists. R8 (review addendum) asks net-kingdom either to move ensure-groups into the existing attended session (recommended) or to give the provisioner an operator credential. keycape-client-secret-generate needs a generate-in-custody entry point from railiance-platform, and the broker does not have one yet. Both were sent to their owners.

id: WARDEN-WP-0044-T02
status: wait
depends_on: [WARDEN-WP-0044-T01]
blocking_reason: "Planning a run needs the agreed follow-through section."
priority: high
state_hub_task_id: "5f68c991-f490-58f8-a121-92f74073d272"

T02 — Plan a case run

warden case plan <case.yaml> checks that the case is accepted and materialized, resolves each step to its catalog entry and entry point, and prints the run: which steps warden executes, which run as the attended caller, what the verification is. No secret values; no execution.

Tests: refuse an unaccepted or unmaterialized case; refuse a step whose catalog entry is missing or not reviewed; show attended steps explicitly.

id: WARDEN-WP-0044-T03
status: wait
depends_on: [WARDEN-WP-0044-T02]
blocking_reason: "Executing follows a reviewed plan."
priority: high
state_hub_task_id: "bcbf6c91-2c04-5c16-ae8c-5d6c06fd6b89"

T03 — Run and verify a case

warden case run <case.yaml> executes the plan. Owner entry points run through the existing proxy as the caller; steps that need an attended login use the existing contained login envelope (silent command, session revoked afterwards), grouped into as few attended sessions as possible. Then it runs the type's verification and writes a receipt without values. warden case rollback reverses exactly this case's steps.

Acceptance: the Forgejo reference case (NK-WP-0048-T06) reaches live through this path, with no case-specific script.

id: WARDEN-WP-0044-T04
status: wait
depends_on: [WARDEN-WP-0044-T03]
blocking_reason: "Catalog integration follows a proven run."
priority: medium
state_hub_task_id: "4a0fa4a7-5ca9-518a-ab92-a79a5e2cf93e"

T04 — Catalog entries from types

Let a type contribute reviewed catalog entries once, so that every case of that type routes without a new catalog edit. Cases add parameter values, not routes. warden route find should be able to answer "which SecurityCaseType covers this need?" before anyone builds by hand.