Add MASON-WP-0010: materialize SecurityCases from their type
Companion to net-kingdom NK-WP-0048; acceptance replaces the executive-summary gate for known cases only. 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
This commit is contained in:
parent
01f347b2e1
commit
22db39bfd8
1 changed files with 110 additions and 0 deletions
110
workplans/MASON-WP-0010-security-case-materialization.md
Normal file
110
workplans/MASON-WP-0010-security-case-materialization.md
Normal file
|
|
@ -0,0 +1,110 @@
|
|||
---
|
||||
id: MASON-WP-0010
|
||||
type: workplan
|
||||
title: "Materialize SecurityCases from their type, with acceptance as the only gate"
|
||||
domain: infotech
|
||||
repo: ops-mason
|
||||
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-warden
|
||||
- railiance-platform
|
||||
---
|
||||
|
||||
# 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
|
||||
|
||||
```task
|
||||
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
|
||||
```
|
||||
|
||||
### 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.
|
||||
|
||||
```task
|
||||
id: MASON-WP-0010-T02
|
||||
status: wait
|
||||
depends_on: [MASON-WP-0010-T01]
|
||||
blocking_reason: "Rendering needs the agreed materialization section."
|
||||
priority: high
|
||||
```
|
||||
|
||||
### 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.
|
||||
|
||||
```task
|
||||
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
|
||||
```
|
||||
|
||||
### 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.
|
||||
|
||||
```task
|
||||
id: MASON-WP-0010-T04
|
||||
status: wait
|
||||
depends_on: [MASON-WP-0010-T03]
|
||||
blocking_reason: "Adoption follows a working light path."
|
||||
priority: medium
|
||||
```
|
||||
|
||||
### 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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue