ops-mason/workplans/MASON-WP-0010-security-case-materialization.md

id	type	title	domain	repo	status	flavor	owner	topic_slug	created	updated	depends_on	related_repos	state_hub_workstream_id
MASON-WP-0010	workplan	Materialize SecurityCases from their type, with acceptance as the only gate	infotech	ops-mason	ready	implementation	claude-code	netkingdom	2026-10-08	2026-10-08		net-kingdom ops-warden railiance-platform	eabf2c39-94bd-5a11-8f2e-76d7a95d1583

MASON-WP-0010 — Materialize SecurityCases from their type, with acceptance as the only gate

Why

NetKingdom is introducing SecurityCaseTypes (net-kingdom NK-WP-0048, canon security-case-types_v0.1, proposed). A type is designed once, with documentation, tests and an informed-decision. Each case of an implemented type is then light: it is accepted, ops-mason arranges it, and ops-warden follows through.

ops-mason's four phases (construction plan, review, executive summary, build) stay exactly as they are for new types and for structure that no type covers. For a KnownSecurityCase, the construction plan is rendered from the type's materialization templates, and the executive-summary gate collapses to the case acceptance, because the shape was decided when the type was acknowledged.

MASON-WP-0009 (a hand-built placement of a key-cape client secret) is the kind of work this replaces. It becomes a reference instance for the first type.

Tasks

id: MASON-WP-0010-T01
status: wait
depends_on: [NK-WP-0048-T03]
blocking_reason: "The materialization section follows the type schema and template."
priority: high
state_hub_task_id: "3382ea7b-65ca-59a9-97ae-273455af44c2"

T01 — Define the type's materialization section

Propose the materialization part of the SecurityCaseType schema together with net-kingdom: policy, role, KV path structure and catalog-entry templates over case parameters, with naming rules. These must respect ops-mason's existing "respect, extend or compact before adding" review, so that a type cannot template sprawl. Write it for the first type, oidc-browser-relying-party, from MASON-WP-0009 and the existing key-cape client custody paths.

id: MASON-WP-0010-T02
status: wait
depends_on: [MASON-WP-0010-T01]
blocking_reason: "Rendering needs the agreed materialization section."
priority: high
state_hub_task_id: "fd385537-7378-5539-8a6e-f45851296f42"

T02 — Render a construction plan from a case

mason plan --case <case.yaml> validates the case against its implemented type, renders the construction plan from the type's templates, and runs the existing consistency review against current OpenBao structure (read-only, no values). The output is the usual plan, marked derived-from-type, plus the case-acceptance reference in place of a fresh executive summary.

Tests: render the reference case; refuse a case whose type is not implemented; refuse parameter values outside the type's validation; flag a collision with existing structure.

id: MASON-WP-0010-T03
status: wait
depends_on: [MASON-WP-0010-T02]
blocking_reason: "Building from an accepted case follows the rendering."
priority: high
state_hub_task_id: "56cea6be-c613-586c-80cd-125340b374da"

T03 — Build from an accepted case

mason build --case <case.yaml> builds a rendered plan when the case's acceptance record is present, with no separate executive-summary approval. Its audit trail names the case, the type version and the acceptance. It proposes the pointer-only ops-warden catalog entries the type defines, as today. Rollback removes exactly what this case created.

Acceptance: the Forgejo reference case (NK-WP-0048-T06) materializes through this path.

id: MASON-WP-0010-T04
status: wait
depends_on: [MASON-WP-0010-T03]
blocking_reason: "Adoption follows a working light path."
priority: medium
state_hub_task_id: "f6ad0d3c-8f47-5fdf-8115-6ca9d8a1fead"

T04 — Adopt MASON-WP-0009 as a case

Once oidc-browser-relying-party (or the confidential service client type) is implemented, express MASON-WP-0009's placement as a case of that type without changing the live structure, and close the hand-built path.