RuView: Trust the Data, Not the Log Line
Today's merges share one thread — knowing what you're actually looking at, whether it's a sensor modality, a phantom detection, or a training run that quietly used the wrong data. All three ship structural guardrails instead of runtime warnings.
Duration: PT2M15S
Episode overview
This episode is a short developer briefing from RuView.
It explains recent repository work in plain language.
- Show: RuView
- Published: 2026-08-26T06:04:28Z
- Audio duration: PT2M15S
Transcript excerpt
This excerpt keeps the crawler page concise. Listen to the episode or use the RSS feed for the full update.
This is RuView for August 26th, 2026.
The pattern across today's activity: don't let the system tell you something is fine when it isn't. Three separate fixes, three separate layers of the stack, same underlying discipline.
Start with PR 1716, ultrasonic sensing joining RuField as a second modality alongside WiFi-CSI. The interesting decision isn't the adapter itself — it's that the module refuses to offer a choice between full-resolution and coarse data. Full-resolution readings would get silently dropped at the export gate anyway, so…
Second theme: false confidence from hardware and pipelines. PR 1717, from davidwajch, tunes live WiFi-CSI sensing on display-less ESP32 nodes. The boot process was falsely detecting a display panel that wasn't there, which cascaded into "teleporting" phantom motion readings. The fix disables that probe outright for…
Third: PR 1718 tackles a training pipeline that would silently fall back to live buffer data when requested recordings failed to resolve — same dashboard, same charts, no visible difference from a real run. The fix adds an explicit data source field to training status, so a run backed by the wrong data is now…
What's next: the ultrasonic…