Play a tone on every gate crossing — including holeshot and rejected (too-short) passes

[ryan-johnson2]

What

Grid must play a tone on every gate crossing, whatever becomes of it:

• the holeshot (first crossing, starts the lap)
• a counted lap
• a crossing rejected as too short (under the round's min-lap)
• any other detected-but-not-counted crossing

Distinct enough per case that an RD can tell them apart without looking at the screen.

Why

An RD watches the track, not the laptop. The tone is how they know the timer saw the pilot — and
right now "the gate detected nothing" and "the gate detected something that didn't count" are the
same silence.

That is exactly the hole hit during the 2026-08-24 field session: pilots flying, nothing appearing,
and no way to tell from Grid whether the gate was firing at all. It sent the whole session toward
the ingest path when the timer's own detection was the variable. A tone on every crossing answers
"is it seeing me?" instantly, from across the track, with no screen.

It is also the cheapest possible version of the tuning feedback #355 exists to provide — and unlike
a live RSSI graph it needs no new telemetry stream, only the crossings the Director already knows
about.

Blocker — the information does not reach the console today

LiveRaceState (crates/server/src/live_state.rs) carries current_heat, phase,
active_pilots, progress, running_order, on_deck and the race clock. It carries nothing
about a crossing that was rejected. A sub-min-lap pass is auto-suppressed in the projection
(crates/projection/src/lib.rs, VoidReason::UnderMinLap) and is only visible after the fact via
the marshaling lap list's removal record — not live.

So this cannot be built purely in the console. The Director has to surface, live:

• that a crossing happened, on which seat, at what time
• its disposition — holeshot / counted / rejected-too-short / other
• something to make it idempotent, so a re-pushed live state does not re-fire the tone

Whether that is a small live "crossing feed" alongside progress, or rejected passes surfaced in
LiveRaceState, is the design call. Additive on the wire either way.

Build on what exists

lib/raceAudio.ts, lib/callouts.ts, lib/lapCallouts.svelte.ts, lib/endTones.svelte.ts and
lib/raceDayAudio.svelte.ts already handle the audio path, the mute/enable state, and TTS
cold-start. This should extend that, not start a second audio system. Note #193 (sounds settings
panel) is open and would be where per-tone enable/volume lives.

Order this AFTER #396

#396 must be fixed first, or this makes it audible. In open practice every stream wake-up
currently re-pushes a "changed" LiveRaceState, which is why lap callouts repeat. Hang a tone off
crossings on top of that and every crossing tone repeats too — turning a visual annoyance into a
continuous noise an RD cannot work through.

Hence the idempotency requirement above: the tone must fire on crossing identity, not on
receipt of a live-state frame.

Done when

• Every crossing produces a tone, including ones that record no lap
• Holeshot / counted / too-short are audibly distinguishable
• A re-pushed live state never re-fires a tone for a crossing already announced
• It respects the existing mute / race-day audio state
• An RD can tell "the gate is seeing me" without looking at the screen

Requested 2026-08-24 after the first physical-timer session.

[ryan-johnson2]

Reframed — 2026-08-25. The justification is not diagnostic; it is awareness.

Both research passes concluded that crossing tones would not have answered the 2026-08-24
failure ("is the gate seeing me at all?" — where a tone system produces silence, the same ambiguous
silence the RD already had), and recommended #355 for that. That reasoning stands and #355 goes
first.

But it was answering the wrong question about why this feature is wanted. From the user:

I want the tones more as a racer to know that I crossed, or as an RD to audibly hear a crossing —
it makes it easier to notice false crossings.

That is three uses, and the third had not been captured anywhere:

1. Racer feedback — a pilot in goggles, mid-flight, knows the gate registered them. They cannot
   see a screen at all; audio is the only channel that reaches them.
2. RD awareness — hearing crossings without watching the screen, which is what an RD is doing
   most of the time.
3. Noticing FALSE crossings — a tone when nobody crossed is immediately obvious, where a
   phantom lap appearing in a table is not. This is arguably the strongest of the three: a
   too-sensitive gate is as broken as an insensitive one, and today nothing surfaces it live at all.

What this changes about the design

• A tone for a crossing that should not have happened is a feature, not noise. The design must
  not filter toward "only meaningful laps" — a phantom crossing on an empty gate is exactly what
  the RD needs to hear. This argues against any future temptation to suppress tones for unseated
  seats or out-of-heat crossings.
• Sound design gets harder in a useful way. Distinguishability now matters for a pilot in
  goggles under prop noise, not only for an RD beside a laptop. That is a stricter bar than the
  brief assumed.
• The layer-D-only limitation (see the disposition survey below) is less of a constraint than
  it looked: false crossings that reach the Director are layer D, and those are the ones worth
  hearing.

The diagnostic framing in the issue body is superseded by this. It remains a real secondary
benefit, just not the reason.

Unchanged and still binding

• Idempotency: the tone fires on crossing identity, never on receipt of a live-state frame.
  (Open-practice repeats lap callouts — every stream wake-up re-pushes a "changed" live state #396's cause is fixed, but the requirement is structural, not a workaround for it.)
• Order after ⭐ Required for v0.4: per-timer Tune page — live node RSSI + enter/exit calibration from the RD console #355 — user-confirmed.
• The min-lap warning (now recorded as a decision on ⭐ Required for v0.4: per-timer Tune page — live node RSSI + enter/exit calibration from the RD console #355): if the RD's RH is set to discard
  sub-minimum crossings, the rejected-lap tone can never fire and Grid cannot currently tell.

[ryan-johnson2]

Decisions — 2026-08-25. Much smaller than this issue assumed.

"The current tone that plays on the RD is fine, we just need to ensure that tone plays on all
crossings — that includes the holeshot and potentially false crossings that the lap may not count.
Most RDs will have speakers attached to the RD console for racers to hear."

No sound design. Reuse the existing tone.

The brief's whole sound-design section — pitch, duration, envelope, distinguishability under prop
noise, synthesised vs samples — is dropped. Ship the tone that already plays. That removes the
riskiest and most subjective part of the work.

Not per-seat pitches either (one of the options offered): the RD is not being asked to identify
who crossed by ear, only that a crossing happened.

Output: the RD console. That is also how racers hear it.

RDs attach speakers to the console, so one output serves both audiences. No racer-side client, no
second audio path, no new wire surface for a future PWA to subscribe to. If #14's racer PWA later
wants its own tones, that is its own issue.

Only during a heat

Idle/tuning crossings are out of scope — the live crossing highlight on #355's Tune page covers
the bench case, and it covers it better (visual, per-node, showing where the thresholds sit relative
to the pass). This avoids threading an observation path past the five silent pre-ingest filters the
disposition survey found, which was the most expensive part of the original design.

What actually has to change

The gap is precise. frontend/apps/rd-console/src/lib/lapCallouts.svelte.ts watches progress for
the current running heat and fires once per newly recorded lap. Laps are derived
(passes.windows(2)), so:

• the holeshot produces no lap → no tone today;
• a crossing rejected under min-lap produces no lap → no tone today;
• a crossing that fails any other live-path filter → no tone today.

So this is not "add a tone", it is "tone on crossings instead of on laps" — which still needs
the one thing the original brief identified: the Director must surface crossings with their
disposition in live state, since a rejected crossing is auto-voided in the projection and never
reaches the console today.

Still binding: the tone fires on crossing identity, never on receipt of a live-state frame, so a
re-pushed or re-snapshotted state cannot re-fire it.

Revised shape

	before	after
sound design	new tones, distinguishable set	existing tone, unchanged
output	console / racer PWA / per-seat	console only
when	possibly idle too	armed heat only
wire work	crossing feed + dispositions	unchanged — still required

The wire change is the whole job now. Everything else got smaller.