# Ticket: Show operator action requirements on card QA traveler

Status: complete
Type: ticket
Updated: 2026-08-11
Next Action: none
Parent: work/wp/active/wp-build-standalone-pi-sd-qualification-operator-application.md

## Problem

The fixed QA traveler answers whether the card is passing and what test is
active, but it does not say which rows are automated, require operator review,
or require a physical bench action. The existing campaign next action also
does not answer whether the human must act now. This leaves the operator unsure
whether a step such as card removal, controller power interruption, approval,
or evidence review is expected.

## Expected Behavior

Every QA row carries a compact `AUTOMATED`, `OPERATOR REVIEW`, or
`PHYSICAL ACTION` badge plus exact guidance. These labels describe operator
involvement: the RPi-controlled recovery power cycle is `AUTOMATED`, even
though controller power changes. A separate prominent `Next
operator action` decision distinguishes human work from the campaign/system
next action. It uses open card-specific intervention requests when present;
otherwise it derives the correct action from the active traveler row. Physical
guidance never instructs powered SD removal. The current F1-A1 matrix must read
that no operator action is required while automation is running.

## Acceptance Criteria

- [x] All eight fixed traveler rows show a stable action classification and
      concise operator guidance.
- [x] The page prominently shows `Next operator action` separately from the
      campaign/system next action.
- [x] An active card-specific intervention overrides derived guidance and
      displays its requested action and safe-state classification.
- [x] An automated running row reads `NONE — automated work is running`.
- [x] Review/authorization and final-disposition rows identify operator review
      without implying physical card handling.
- [x] The recovery row identifies the RPi-controlled whole-controller power
      cycle as automated, requires no operator action, and explicitly keeps the
      card installed.
- [x] Intake/replacement guidance states that card handling requires confirmed
      controller power-off.
- [x] F1-A1 shows no current operator action; F1-B1 clearly states the
      before-start card/power confirmation without claiming qualification ran.
- [x] Dashboard card links include the current operator-action decision.
- [x] Focused and full ARM tests, authenticated desktop/mobile review,
      web-only deployment, health, and Controller A/worker continuity pass.

## Verification

Exercise automated-running, not-started, invalid/blocked, operator-review,
physical-action, explicit intervention, and unrelated-card cases. Build and
test the exact ARM64 image. Deploy only the web service and inspect the live
dashboard, F1-A1, and F1-B1 at desktop/mobile widths. Confirm no horizontal
overflow, no powered-removal language, the temporary browser session is
removed, both workers retain their start times, and all four Controller A
services remain active.

Implementation, exact-image testing, authenticated production rendering,
health, and continuity pass. PR #42 corrects the recovery classification at
merge `d332449` and image
`sha256:83473ed7e97db0285571d6e2a2f6ceb2ce1a6b9593064b92e1f3c31f1a17da64`.
The original deployment evidence is
`work/evidence/sd-qualifier-card-operator-guidance-20260806.md`. The final
authenticated desktop/mobile review found and corrected one long-token mobile
overflow, retested the exact ARM64 image, deployed web-only, and verified
worker continuity. Closeout evidence:
`work/evidence/sd-qualifier-card-operator-guidance-20260811.md`.
