[PurpleSentinel]

Refs #204. Does not close it — see the last section.

#204 was wired in #205

#205 made capture reachable (SETUP → CAPTURE GATES, operating on the loaded circuit) and said so honestly: "Not verified: an actual capture on hardware." Checking the acceptance criteria against the code now, the wiring is all there — open, six actions routed, update_fix fed every tick, catalogue rebuilt and the circuit re-applied after a save, outcome logged.

Two things were still between that and a capture succeeding at a circuit, and both are about what the screen tells you.

It asked for eight endpoints that no longer exist

Removing pit entry and exit (#227) took a circuit from four gates to two. The controller followed — kGateNames{"START","FINISH"}, captured_ of 4, save unlocking at 4. The text it hands the screen did not:

shown	actual
ENDPOINT CAPTURED - CONTINUE UNTIL ALL 8 ARE COMPLETE	4
SAVE BLOCKED - CAPTURE BOTH ENDS OF ALL FOUR GATES	2
SAVED AND RELOADED - FOUR-GATE DEFINITION IS READY	2
START | LEFT | 2/8	/4
capture: ... %u of 8 endpoints (log)	4

So a driver following the screen captures four endpoints, is told to continue to eight, and never reaches a state the screen calls finished — while SAVE has been enabled since the fourth. That is the acceptance criterion "all gates and both endpoints of each can be captured and saved" failing on instructions rather than on logic.

Counts now come from kGateCaptureEndpointCount, or the gates are named rather than counted — CAPTURE BOTH ENDS OF THE START AND FINISH LINES is both un-staleable and the clearer instruction at the line. The host test asserts the text against that stated shape, so the next change to the shape of a circuit cannot pass with stale instructions:

assert(std::strstr(after_one.status.data(), "1 OF 4 DONE") != nullptr);
assert(std::strstr(after_one.status.data(), "8") == nullptr);

A refused save named none of its three causes

SAVE BLOCKED - GATE GEOMETRY FAILED SAFETY VALIDATION, to somebody parked at a circuit with the engine off. The three ways a captured line is refused have three different remedies:

cause	now reads
ends under 1 m apart	LINE TOO SHORT: THE TWO ENDS MUST BE AT LEAST 1 M APART
outside the geofence	AN ENDPOINT IS OUTSIDE THIS CIRCUIT'S GEOFENCE
too long / too shallow / unprojectable	gates.start REFUSED. CHECK ITS LENGTH, ITS ANGLE TO THE DIRECTION OF TRAVEL, AND THAT IT IS AT THIS CIRCUIT

serialize_track_definition already round-trips its candidate through load_track_definition — that round trip is what keeps invalid geometry off the card — and was discarding the report. It now takes an optional TrackLoadReport*, so no existing caller changes, and both the panel and a new ESP_LOGW name the reason.

Three causes share invalid_value for a gate — projection failure, over a kilometre long, within ten degrees of the direction of travel — and from the controller there is no telling which. All three are listed rather than one being picked and presented as the cause.

Verification

• make check → CHECK_RC=0; simulator 78/78; firmware builds, 32% of the app partition free
• Bench-checkable, which is the point of the geofence case. A line captured in the garden is a valid line in the wrong place, so the whole path short of a valid save can be exercised at home: open capture against any loaded circuit, capture four endpoints, press SAVE → refused with AN ENDPOINT IS OUTSIDE THIS CIRCUIT'S GEOFENCE, nothing written. The new host test pins exactly that, shifting both lines 5.5 km north and asserting geometry_outside_geofence rather than a degenerate line
• Not flashed

Why this does not close #204

Its criteria are "all gates captured and saved" and "after saving, the circuit reads device_captured and timing arms". Those can only be met at a circuit, parked at the physical ends of a line with a fix. Nothing in this PR or #205 can prove them from a desk — the geofence check means a successful save is impossible anywhere but the circuit itself, by design.

Two things worth deciding separately, both left alone:

• Capture and persist four circuit gates safely on device #108 was closed in August on the criterion "a user can capture, validate, save, reload and select all four lines without rebuilding firmware", which was never true on the device. My read: leave it closed and let Gate capture cannot be opened on the device, so no circuit can be promoted out of provisional #204 carry the remainder, since reopening it would split the same work across two issues.
• The start and finish gates of a real circuit are usually the same physical line. The screen gives no hint of that, so capturing a circuit means driving to the same two points twice. A COPY START TO FINISH action would fix it and is a new feature, not wiring.
• GateCaptureScreen::update() rewrites all six labels unconditionally at the display cadence — the same unconditional repaint fix(ui): make Race's running-screen rule testable and drop the delta it never drew #231 just gated on the Race screen. Untouched here: it is A single LVGL repaint costs 40 ms against a 25 ms service period, on the task that also polls the receiver #213's territory and this screen is used parked.

🤖 Generated with Claude Code