Add WARDEN-WP-0044: follow through on KnownSecurityCases

Companion to net-kingdom NK-WP-0048 and ops-mason MASON-WP-0010.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 5457@bnt-lap001
Assistant-Session: 792bf84a-3783-4f5d-a811-cded61dd2012

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

@@ -0,0 +1,109 @@
+---
+id: WARDEN-WP-0044
+type: workplan
+title: "Follow through on KnownSecurityCases along their type's route"
+domain: infotech
+repo: ops-warden
+status: ready
+flavor: implementation
+owner: claude-code
+topic_slug: netkingdom
+created: "2026-10-08"
+updated: "2026-10-08"
+depends_on: []
+related_repos:
+  - net-kingdom
+  - ops-mason
+  - key-cape
+  - railiance-platform
+---
+
+# 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
+
+```task
+id: WARDEN-WP-0044-T01
+status: wait
+depends_on: [NK-WP-0048-T03]
+blocking_reason: "The follow-through section follows the type schema and template."
+priority: high
+```
+
+### 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.
+
+```task
+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
+```
+
+### 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.
+
+```task
+id: WARDEN-WP-0044-T03
+status: wait
+depends_on: [WARDEN-WP-0044-T02]
+blocking_reason: "Executing follows a reviewed plan."
+priority: high
+```
+
+### 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.
+
+```task
+id: WARDEN-WP-0044-T04
+status: wait
+depends_on: [WARDEN-WP-0044-T03]
+blocking_reason: "Catalog integration follows a proven run."
+priority: medium
+```
+
+### 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.