Operator fault panel: separate a unit fault from a station fault

[PaulSalaun]

Why

An ordinary DUT rejection ends a test with OpenHTF's own bare STOP detail — "Phase X stopped the test run" — which names no measurement and carries no remediation. The operator panel therefore showed it as an unexpected error with a Notify Halter button, which is the only thing it could do with a detail it had no text for.

Operators pressed it. Over 2026-08-31, 27 of the 40 fault reports reaching #htf-error-unbind (68%) were yield loss, and that volume buried the two reports that mattered: a plug-init ValueError and a collar with no battery bound.

The panel had two states — has remediation, or does not. It needed a third: has remediation, and nobody should be notified.

What

Two GUI-only fields on OutcomeDetails, both stripped from shipped JSON reports by the framework's output callback so the Manufacturing Service / Athena payload keeps its shape:

• notifiable — False means show the message and offer no button.
• catalogue_code — the catalogue entry a detail's text came from, when it differs from the detail's own code. Rendered under the code so an engineer can find the entry to edit.

For a non-notifiable detail the panel:

• renders the spec list above the remediation instead of de-emphasised below it (the operator's decision is about the part in hand, not about the steps);
• suppresses both the notify and the escalate button;
• reads TEST FAILED — UNIT DID NOT MEET SPEC in the header;
• keeps only the code in the de-emphasised Issue block.

A station fault renders exactly as before.

The serial and each failing measurement name are bolded. Both are found structurally — the DUT id by string match, the name as whatever precedes ' = ' on a ' - ' line — rather than by parsing prose: the panel text is bilingual, and no markup may go into the description, which reaches the JSON report and Athena.

Decisions worth recording

Every panel stays red. An orange variant for the unit case was built and then removed. The panel means the test failed either way; what actually differs is whether the operator is being asked to alert anyone, and the header wording plus the absent button already carry that. A second colour would need to encode something those two do not.

<pre> became one div per line so the emphasis can be applied — and white-space: pre-wrap moved onto the line, not the container. On the container it also preserves the template's own indentation between the block elements, which renders as a blank line between every entry.

The bullet shape is a cross-repo contract. ' - NAME = value' is produced by fault_catalog._failing_measurements in hardware-test-framework and matched by specLines here. Changing either side stops the emphasis silently rather than breaking — the intended failure mode, but worth knowing. Nothing tests the two halves against each other yet; the repo has no front-end test tier in use.

dist/

web_gui_server.py:30 serves web_gui/dist, and stations have neither node nor npm — no build step exists in the framework's ansible roles or tarball script. So the built bundle is committed, as it always has been: 8 deletions, 8 additions, one index.html change, a single bundle (app.484afc41…).

Verification

Driven through the real run_test_loop on hq-1500 — a measurement fail, a mapped phase timeout and an unmapped one. Checked the panel payload over the station's own websocket, the FAULT_OCCURRENCE lines, and the shipped JSON report keeping its pre-change key set.

The fork's own test suite was not run: the framework's CI only runs hardware_test_framework/unittests. Existing tests constructing OutcomeDetails positionally are unaffected — both new fields default.

Paired with the hardware-test-framework PR that consumes these fields.

[coveralls]

Coverage Report for CI Build 33558513976

Coverage increased (+0.01%) to 60.622%

Details

• Coverage increased (+0.01%) from the base build.
• Patch coverage: 3 of 3 lines across 1 file are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	7743
Covered Lines:	4694
Line Coverage:	60.62%
Coverage Strength:	3.03 hits per line

---

💛 - Coveralls