docs: date the dead pad, so earlier flight results can be triaged instead of doubted

The uinput pad was replaced on 2026-08-13 (canary cbfad1ab3), which is when
flight_probe.Pad stopped reaching the game. flight-controls-runtime.md predates
it (2026-07-30) and is safe; flight-speed-law.md was last touched on the same
day and cannot be placed from dates alone; anything after it measured a craft
that was not being flown.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-23 22:10:21 +00:00
parent dde23cac3c
commit 70497b1606

View File

@@ -145,3 +145,21 @@ to the dead FIFO. Each now carries a comment saying so and pointing here. They
are not repaired because none of them has been re-run since, and quietly changing
the input plumbing under a tool whose results are unverified would only
manufacture new unverified results.
## Which earlier results this puts at risk — dated, so it can be checked rather than worried about
The uinput pad was replaced on **2026-08-13** (canary `cbfad1ab3`), which is the
day `flight_probe.Pad` stopped reaching the game. So:
***Safe:** anything measured before that. `flight-controls-runtime.md` was
last touched **2026-07-30**, comfortably on the working side.
* ⚠️ **Ambiguous, and worth re-checking:** `flight-speed-law.md` was last touched
**2026-08-13** — the same day — so whether its numbers were taken before or
after the FIFO went dead cannot be told from the dates alone.
* 🔴 **Anything that used `flight_probe.Pad` on or after 2026-08-13 measured a
craft that was not being flown.**
Stated as a rule for whoever picks this up: a flight result is only as good as a
demonstration that the stick moved the ship in the same session. `aim_probe.py`
is that demonstration, and it now brackets itself with a liveness check.