# Ticket: Implement web-started persistent SD qualification campaign coordinator

Status: complete
Type: ticket
Updated: 2026-08-12
Next Action: completed; continue from the reviewed live-authorization and Controller B coordinated-cycle gates recorded in work/evidence/sd-qualifier-web-campaign-coordinator-deployment-20260812.md
Parent: work/wp/active/wp-build-standalone-pi-sd-qualification-operator-application.md

## Problem

The deployed SD Qualifier projects an immutable execution tree and accurate
durable status, but does not execute that tree. Live HPT2 cases are selected
and launched by an agent through transient host scripts and services. A
completed ordinary case therefore becomes an artificial operator-review
handoff even when its governing campaign envelope remains valid.

The product is not complete until a reviewer can start the bounded campaign
from the website and a persistent appliance-owned coordinator advances it to
completion or the next genuine failure, safety, authorization, or physical
intervention gate without SSH-driven case selection.

## Expected Behavior

The website starts, safely pauses, and resumes one durable campaign execution.
A persistent coordinator claims the active immutable plan leaf, derives exact
machine intents from the existing campaign envelopes, executes only packaged
allowlisted actions, reconciles uncertain publications without replay, and
continues after passing, cross-credited, or clean no-credit observations.

The same execution advances through the HPT2 matrix, controlled recovery,
representative regression, post-campaign scrub/CID closeout, and final
disposition readiness. The website reports queued, running, pausing, paused,
blocked, waiting-operator, or complete from durable coordinator state rather
than inferring automation from the presence of one open run.

## Acceptance Criteria

- [x] A web action starts one durable execution bound to the campaign's active
  immutable execution-plan revision and exact A/B authorization envelopes.
- [x] A persistent leased worker resumes after process/container restart and
  never creates duplicate leaf work or replays a published controller command.
- [x] Automatic HPT2 selection advances incomplete base/extended rows under
  bounded attempt budgets and preserves the Controller B continuity policy.
- [x] Passing, valid cross-credit, and clean no-credit results continue without
  operator review; identity drift, evidence invalidity, unsafe/unknown command
  outcome, bounded-stop failure, supervisor failure, lost B gate, no-progress
  budget, expiry/revocation, and physical action stop durably with one reason.
- [x] Recovery, regression, post-campaign scrub/CID capture, and final
  disposition readiness are plan actions owned by the coordinator; disposition
  remains a reviewer decision rather than an inferred automatic pass.
- [x] The UI provides Start, safe Pause, and Resume controls and displays the
  coordinator's actual queue/current leaf/stop reason and envelope lifetime.
- [x] Fixture end-to-end tests start from the web and reach the final reviewer
  gate without shell-selected cases, including worker restart and no-replay.
- [x] The exact ARM64 release passes focused and complete tests, has verified
  rollback, and is deployed with a healthy persistent coordinator service.
- [x] Production verification uses a fixture/dry-run execution first and leaves
  live cards untouched until the deployed coordinator and envelopes pass all
  readiness gates.

## Verification

Use model/service/view tests, database concurrency and lease tests, restart and
ambiguous-publication tests, a full fixture campaign driven only by HTTP and
the persistent worker, the complete application suite, exact-image ARM64
tests, migration backup/restore, deployed health/heartbeat checks, and
authenticated Playwright verification of controls and state transitions.
