# SD Qualifier current-intervention projection and recovery closure — 2026-08-10

Status: complete
Result: PASS; the dashboard, campaign history, email attribution, and reminder state now distinguish current blocks from recovered supervisor alerts
Type: evidence
Updated: 2026-08-10
Next Action: preserve both active S4 runners and continue the ordinary A/B matrix under the corrected current-state projection
Campaign: 006-start-clean-contract-bound-sd-qualification-campaign
Parent: work/checklists/checklist-hpt2-bounded-stop-recovery-and-regression-measurement.md
Project Map: work/maps/map-smi-firmware-stabilization-and-qualification.md

## Reported contradiction

The authenticated dashboard capture showed both cards `IN PROGRESS`,
`Operator: NONE`, and campaign state `RUNNING`, while a separate section titled
`Intervention required` listed many already-recovered watchdog notifications.
The operator correctly identified that this presentation implied present action
even though the authoritative supervisor state was healthy.

The dashboard query treated every intervention notification in `PENDING`,
`SENT`, or `FAILED` as current. Watchdog recovery intentionally preserved the
original notification for audit and acknowledgement, so recovered supervisor
alerts remained `SENT`, appeared current, and were eligible for reminders. The
dashboard already had a separate authoritative projection of nonhealthy
`QualificationSupervisorState`; the notification list was therefore the stale
surface.

## Correction

Source commits:

- `027a3b7c903a0826bf460daaf1daa043708c3cfe` separates authoritative current
  supervisor blocks from delivered notification history, labels campaign
  history explicitly, and binds future watchdog notifications to their exact
  run/controller without changing run state;
- `e4bf6e5ce2f4fb591f9f7e5f34d657bb411d6b5f` closes supervisor-only
  notifications and deliveries whenever that controller role's authoritative
  supervisor state is `HEALTHY`. Closure is durable and emits
  `qualification-supervisor.interventions-closed`; the notification remains in
  campaign history but is no longer actionable or reminder-eligible.

Current blocks still fail closed and render through the independent supervisor
warning. Non-supervisor interventions continue to use the ordinary actionable
notification section.

Focused projection/recovery tests passed, and the complete exact ARM64 suite
passed `306/306`. The final immutable release is
`qualification-current-interventions-e4bf6e5`, image
`sha256:99ff23bd60c213fa6f33bca29b6e2f654f5df63b48502777f10c52570237e2db`.
Its package and checksums are retained at
`/home/jong/releases/qualification-current-interventions-e4bf6e5`.

## Backup, deployment, and rollback

Predeployment backup `/backups/sd-qualifier-20260810T133103Z.dump` is
`1278627` bytes with SHA-256
`0885e83d106e977934d6e0122216aca5d21c99006259a65aee502bd918679333`;
its disposable PostgreSQL 17 restore passed at
`2026-08-10T13:31:06Z`. Deployment manifest
`ff7a182b686b93670b22c469e7fd28614f685576b496f52ae4f4b932bc34089f`
validated before installation. Rollback configuration is retained at
`/home/jong/.local/share/sd-qualifier/rollback-current-interventions-e4bf6e5-20260810T1331Z`.

An earlier protected cutover attempt installed configuration files with the
wrong owner. The application failed its readability gate, the deployment
rolled back to the prior image/manifest, and both observers were restored.
The parent runner invocation IDs remained unchanged and command operations
remained clear. That attempt emitted supervisor alerts `182` through `189` for
the transient deployment condition. The corrected owner-preserving cutover
then passed and the recovery closure made those alerts historical.

## Live verification

Production web, command worker, notification worker, and qualification
watchdog all run the exact final image; web health is `healthy`. Parent services
remain on invocations `496dbd96a55e45aaa6333b7fbd8f5a67` (A) and
`fa196d1f1db54a6c8a4fd9c806f48c00` (B). Both role observers are active.

New-manifest supervisor snapshots reported:

- A run `a2dbfca4-805b-4fca-bf69-b01717e0f083`, S4 `44640 / AFTER`,
  `7240/7240/7239`, `HEALTHY`;
- B run `0b7c2fe0-f096-4adf-8064-a12ad4140907`, S4 `10080 / AT`,
  `7926/7926/7925`, `HEALTHY`.

There are zero unresolved command operations and zero active supervisor
notifications. All `185` recovered supervisor notifications are `CLOSED`; the
latest delivery states are also `CLOSED`. Audit events `1118` and `1119`
record role-A and role-B closure sets.

A persistence check at `2026-08-10T13:35:21Z` found A advanced to
`7390/7390/7389` and B to `8525/8525/8524`, both still `HEALTHY`. The latest
notification remained closed notification `189` from `13:20:15Z`; no new
notification was created after the final deployment, active supervisor
notifications remained zero, and command operations remained clear.

An authenticated production render verified:

- dashboard `Intervention required`: absent;
- dashboard current supervisor-block banner: absent;
- campaign `Intervention notification history`: present;
- campaign current supervisor-block banner: absent.

The in-app browser had no connected instance, so verification used the
operator's authenticated page capture for reproduction plus the deployed
Django request/render path against the production database.

## Identity and safety

Controller/card identities are linked to the same uninterrupted runs in
`work/evidence/s4-parallel-restart-watchdog-run-boundary-deployment-20260810.md`:
A CID `05000C61736466672200001C8901A34F`, boot
`26B10B1280443248`; B CID `05000C61736466672200001C8201A379`, boot
`F54F10127F443248`. No card was removed, inserted, replaced, or reinserted;
neither controller rebooted. CID is identity evidence, not proof of
authenticity. No Start or Stop was replayed or inferred.
