Fix attended login result auditing and reconcile blocked workplans
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 3s

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e6ef-4273-7fc2-8741-dc96b3e5fe0d
This commit is contained in:
tegwick 2026-09-28 09:44:49 +02:00
parent 940e164c9b
commit 4c3a0f4d3a
11 changed files with 260 additions and 32 deletions

View file

@ -4,7 +4,7 @@ type: workplan
title: "Adopt unknown -> fail_closed behind signing-target classification coverage"
domain: infotech
repo: ops-warden
status: proposed
status: blocked
flavor: planning
depends_on:
- WARDEN-WP-0032
@ -16,7 +16,7 @@ depends_on_workplans:
- WARDEN-WP-0032
- WARDEN-WP-0034
created: "2026-09-09"
updated: "2026-09-09"
updated: "2026-09-28"
state_hub_workstream_id: "c8ee441e-1be1-5219-910c-e79ff23cc9ec"
---
@ -43,7 +43,7 @@ So: coverage first, then the cell. That ordering is the whole holding of
```task
id: WARDEN-WP-0040-T01
status: todo
status: wait
priority: high
state_hub_task_id: "611f0901-9fb5-5954-8dd0-a860c5f0cbec"
```
@ -65,7 +65,7 @@ outcome this workplan exists to prevent.
```task
id: WARDEN-WP-0040-T02
status: todo
status: wait
priority: high
state_hub_task_id: "54ad4864-7bcf-592e-a187-9239a81a0b11"
```
@ -114,7 +114,7 @@ or the test fails — which is the property that makes the map worth publishing.
```task
id: WARDEN-WP-0040-T04
status: todo
status: done
priority: medium
state_hub_task_id: "222a8c5d-0c0f-5a1d-98d8-02be7dca3358"
```
@ -154,3 +154,30 @@ adopted.
T01–T03 are unchanged and still gate the conversion. Coverage is now measured
rather than asserted (`scripts/report_coverage.py`), so T02's reporting obligation
has a tool behind it and the published figure cannot drift from the register's.
### 2026-09-28 loose-end review
T04 is done: GH-DEC-2026-011 already answered both transition asks on September 9;
the accepted coverage column and declared-gap disposition are recorded above.
No additional response is required to meet that task's acceptance criterion.
T01/T02 now wait; the workplan is blocked. Re-ran both coverage reports:
signing targets = 0 resolved / 3 unknown / 1 not-applicable; routing lanes =
3 resolved / 20 unknown / 15 not-applicable. Refreshed pep-stance.yaml's measured
date. These figures describe the checked-in registry and local owner declarations,
not a live PDP query. No zone membership was inferred or changed.
The exact missing workload resolutions are `ops-bridge-tunnel` for
`agt-state-hub-bridge`, `codex-interhub-bootstrap` for
`agt-codex-interhub-bootstrap`, and `backup-daily` for `atm-backup-daily`.
The seed inventory's `adm-example` is not an admitted repair actor.
Warden's own workload declaration cannot classify those target workloads.
T01 needs an owner-declared continuity actor/target and its authoritative
z2-continuity resolution; T02 retains the owner-routing/declaration follow-up
(ops-bridge, the Inter-Hub execution owner and the backup execution owner).
Without it, changing unknown to fail_closed would deny their issuance during a
PDP outage. Coverage reporting is complete, but owner coordination is not.
T03 also remains gated on standard acceptance: the local authoritative
net-kingdom/canon/standards/security-layer-model_v0.8.md still says proposed.
No superseding ADR or runtime stance change is warranted before these gates.