ops-warden/workplans/WARDEN-WP-0040-unknown-zone-fail-closed-adoption.md
tegwick 9c01a8a212
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 2s
chore: record hub ids for WARDEN-WP-0040
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013EPuTc18FjU5WFqoSEKH3C

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1276224@bnt-lap001
Assistant-Session: 426ec497-e1c4-4dd3-b417-dfce1ca1dbc3
2026-09-09 16:42:01 +02:00

127 lines
5 KiB
Markdown

---
id: WARDEN-WP-0040
type: workplan
title: "Adopt unknown -> fail_closed behind signing-target classification coverage"
domain: infotech
repo: ops-warden
status: proposed
owner: ops-warden
topic_slug: netkingdom
planning_priority: P1
depends_on_workplans:
- WARDEN-WP-0032
- WARDEN-WP-0034
created: "2026-09-09"
updated: "2026-09-09"
state_hub_workstream_id: "c8ee441e-1be1-5219-910c-e79ff23cc9ec"
---
# WARDEN-WP-0040 — `unknown` → `fail_closed`, in the right order
security-layer-model v0.8 §6.4 obligation 3 (proposed, 2026-09-06) rules that
`unknown` is not a zone and must resolve to `fail_closed`. ops-warden's
`pep-stance.yaml` declares `unknown: fail_open` under `ADR-0009`.
**We agree with the rule.** `history/2026-09-09-layer-model-v08-review.md` records
the assent and why our falsifier check failed: the cell governs certificate
issuance, not a §5.1 read-only diagnostic, so nothing rescues it.
**We disagree with adopting it first.** Measured 2026-09-09: of four signing
targets, zero resolve to a zone, three are `unknown`, one is `not-applicable`.
Flipping the cell today makes flex-auth a hard dependency of essentially every
certificate — `ADR-0006`'s rejected configuration, reached by a different route,
including the continuity path needed to repair flex-auth itself.
So: coverage first, then the cell. That ordering is the whole holding of
`ADR-0006` and the reason `ADR-0009` replaced a global switch with a zone map.
## Tasks
```task
id: WARDEN-WP-0040-T01
status: todo
priority: high
state_hub_task_id: "611f0901-9fb5-5954-8dd0-a860c5f0cbec"
```
**Classify the continuity path before anything else changes.**
The deadlock is specific and worth naming before it is designed around: flex-auth
unreachable → operator needs an SSH certificate to reach the host → target is
`unknown` because nobody classified the repair path → `fail_closed` denies it.
`z2-continuity` exists for this and its stance is `fail_open`, so the fix is
classification, not an exception. Determine which actor(s) constitute the
repair path, establish whether the declaration is ops-warden's to make (our own
`tenancy.yaml` covers ops-warden as a workload; the actors' target workloads may
not be ours), and route what is not.
Blocks T03. Converting the cell with the repair path unclassified is the one
outcome this workplan exists to prevent.
```task
id: WARDEN-WP-0040-T02
status: todo
priority: high
state_hub_task_id: "54ad4864-7bcf-592e-a187-9239a81a0b11"
```
**Raise signing-target coverage, by asking owners — never by inferring.**
Three actor resources report `workload_resolution_absent`:
`agt-codex-interhub-bootstrap`, `agt-state-hub-bridge`, `atm-backup-daily`.
Their owners (ops-bridge and the backup execution unit among them) have not
published an authoritative workload identity declaration.
`ADR-0009` rule 3 forbids closing this with path or repository-name inference,
and that prohibition holds under pressure from this workplan specifically —
adopting a stricter stance is not a licence to manufacture the membership that
makes it survivable.
Route to each owner with the concrete consequence: while the declaration is
absent their actor cannot be issued a certificate during a flex-auth outage once
the cell converts. That is a better ask than a generic request to publish a
declaration, and it is true.
Report coverage with `scripts/report_workload_join.py`; this task is done when
coverage is stated, not when it reaches a threshold — the threshold is T03's
gate, and owners may legitimately decline.
```task
id: WARDEN-WP-0040-T03
status: wait
priority: high
state_hub_task_id: "93eaf1f2-daaa-5e22-8804-85ca9433571c"
```
**Convert the cell and supersede `ADR-0009`'s unknown row.**
Gated on T01, and on v0.8 (or its successor) reaching `accepted`. Do not convert
against a `proposed` standard.
`ADR-0009` is `owner: ops-warden`, so changing it means a superseding ADR, never
an in-place edit (`.claude/rules/architecture.md`). The superseding record should
carry the v0.8 argument rather than restate it: unknown is not a zone, so a §9.3
per-zone trade was never made for that request.
`pep-stance.yaml` is asserted equal to `PolicyConfig.failure_modes` by
`tests/test_layer_conformance.py`, so the map and the code convert in one commit
or the test fails — which is the property that makes the map worth publishing.
```task
id: WARDEN-WP-0040-T04
status: todo
priority: medium
state_hub_task_id: "222a8c5d-0c0f-5a1d-98d8-02be7dca3358"
```
**Return findings to gate-house and track the transition ask.**
Sent 2026-09-09 with the review. Two asks, in preference order: obligation 3
names a dated transitional state gated on coverage; or failing that, §13.1
records classification coverage alongside stance, so a register row cannot read
`unknown: fail_closed` while every target is unknown.
If both are declined, that is an answer and this workplan proceeds unchanged —
the cell stays a **declared gap** under §11 with this workplan as its route,
which is what the `declared-gap` mark (our own v0.6 finding) exists to express.