[PurpleSentinel]

Closes #226. 53 files, −761 lines.

What went

The two timing gates, the settings behind them, the automation's stop path, the capture steps, the gate fields in a track definition, and their documentation.

• TimingGate is start and finish; kTimingGateCount is 2
• CircuitGateDefinitions loses both pit gates → track schema version 4
• Gate capture walks two gates rather than four
• SessionController::stop_from_pit_entry and CompletionReason::pit_entry
• pit_entry_auto_stop_enabled, with no start-line equivalent: stopping there would end a session after one lap, so stopping stays the driver's

Schema 3 still loads. Its pit gates are parsed and discarded, because the 26 circuits already written to cards are otherwise correct and rejecting them would cost a device its whole track list for gates nothing reads.

The GPS trigger survives, on the start line

Per the amendment on the issue. It is also simply the better gate: the start line is crossed every lap, where pit exit on a road loop was a line somebody picked, and on a circuit whose start and finish are one line the session and lap 1 begin on the same crossing.

A crossing starts a session only while armed. Without that, driving out of the paddock would begin one — pit exit was obscure enough that a crossing implied intent, and the start line is not. GateAutomationResult::ignored_unarmed reports it, because the remedy differs from every other refusal.

Two departures from the issue, both for the same reason

The issue called for settings v9 with a migration. No version bump was needed, and avoiding one is strictly better for anyone holding a v8 device:

• pit_exit_auto_start_enabled → gps_start_line_enabled. The stored byte and its meaning are unchanged, so this is a rename in C++ and nothing in the format.
• Byte 65, which held pit-entry auto-stop, is kept as reserved and written as zero. Reclaiming it would change a fixed-width record's length for a setting nothing uses.

The log format is treated the same way: SessionSettingsV1 keeps a reserved field, and SessionCompletionReason::pit_entry becomes reserved_pit_entry — kept, never produced — so the sessions already on cards still decode to a reason the reader knows.

Two faults found on the way

A segfault I introduced and the tests caught. std::array<DirectedGateDefinition*, 4> kept its length after losing two initialisers, so it held two null pointers and load_track_definition crashed dereferencing them. The two arrays parallel to it had the same fault. Worth noting because the compiler is silent about it — a short initialiser list is legal.

A latent out-of-bounds read, pre-existing. SettingsField had gained acceleration_target without kSettingsFieldCount or the name array following it, so naming that field read past the end of a 14-element array. Found only because the two pit entries were in the same list. Fixed, with a static_assert so the array and the enum cannot drift again.

Also: SETUP now names the rest period REST rather than PIT REST — it is time between sessions, spent wherever the driver likes.

Verification

• make check → CHECK_RC=0
• firmware builds clean
• make test → 38 Python tests, OK
• Both track packs rebuild: test 1/1 timing-ready, UK 24 definitions
• tools/validate_tracks.py passes against the schema
• Three pinned simulator pass-message regexes updated; that has broken twice before

The automation's new behaviour is covered by a rewritten test_gate_session_automation.cpp — each refusal asserted distinctly, including unarmed, plus a second crossing not restarting a running session and the configured duration surviving an automated start. test_track_definition.cpp gains a case asserting a schema-3 document with pit gates still loads.

Not yet flashed.

🤖 Generated with Claude Code