From 1172750ae6d7260d745cf1d97c126ec7d18a0831 Mon Sep 17 00:00:00 2001 From: RobVanProd Date: Tue, 11 Aug 2026 20:30:20 -0400 Subject: [PATCH] Record the F1 and F2 physical observations against their exact image MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The work list still described F1 and F2 as awaiting evidence that has since been collected, so anyone picking it up would re-run work already done or, worse, assume nothing had been tried. F1: ten completed turns on installed firmware d631da56 each ran the full response_started → response_end_deferred → reply_pending → response_end_after_playback_complete sequence, with the end gated on real playback_complete rather than estimated duration. Recorded as favourable evidence and explicitly not as closure: the stated gate is a qualification reporting host-response-wire-clean across cancellation, model/TTS failure, and owner-loss, and those error paths were not exercised. F2: bridge_uplink_errors stayed at 0 across twelve captures and ten completed turns over 66 minutes, with queue failures, submit failures, capture discontinuities, and capture timeouts all zero. The counter was never reset and has read zero since the OTA. Ten of ten utterances matched their declared byte and chunk totals exactly, longest 217 chunks (10.85 s). That is the zero-delta evidence F2 asks for, bound to this SHA-256 and transferring to no other. Both notes name the image explicitly, because evidence here is only ever about one binary. Co-Authored-By: Claude Opus 5 --- docs/BRIDGE_AI_HANDOFF.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/docs/BRIDGE_AI_HANDOFF.md b/docs/BRIDGE_AI_HANDOFF.md index 96005e7..a5778dd 100644 --- a/docs/BRIDGE_AI_HANDOFF.md +++ b/docs/BRIDGE_AI_HANDOFF.md @@ -202,6 +202,17 @@ during TTS, so the error path is the likely culprit. failure, owner-loss, and long-running physical conversation cases; the qualification must report `host-response-wire-clean` with no unrecovered events. +**Live observation 2026-08-11** on installed firmware +`d631da56c004cc9c2263cbc8c01cf7a27fd0dfca5861c5461f2292681386d129`: ten completed turns each ran the +full `response_started` → `response_end_deferred` → `reply_pending` → +`response_end_after_playback_complete` sequence, with the end gated on real `playback_complete` +rather than estimated speech duration. Ten replies played; `bridge_downlink_playback_starts` reached +10 with no response left open and no 90-second stall observed. + +This is favourable evidence, **not** F1 closure. The stated gate is a qualification reporting +`host-response-wire-clean` across cancellation, model/TTS failure, and owner-loss paths; those error +paths were not exercised here, and no such report was produced. F1 stays open. + ## F2. Long-capture wake-gate race (source fixed, physical validation pending) **Observed after PR #216:** two captures produced 118 and 113 accepted chunks. The host received @@ -224,6 +235,21 @@ closed. Do not hide or reset the error counter; exact-image physical evidence is The supervised run must show zero `bridge_uplink_errors` delta across completed turns; do not reset the counter to manufacture that result. A nonzero robot counter remains a firmware-owner finding. +**Live observation 2026-08-11** on installed firmware `d631da56...`: `bridge_uplink_errors` stayed at +**0** across twelve captures and ten completed turns over 66 minutes, alongside +`bridge_uplink_queue_failures: 0`, `mww_uplink_submit_failed: 0`, `wake_capture_discontinuities: 0`, +and `wake_capture_timeouts: 0`. The counter was never reset; it has read zero since the OTA +(`boot_count: 1`, `reset_reason: software`). + +Ten of ten utterances matched their declared byte and chunk totals exactly, longest 217 chunks +(10.85 s), with zero `audio_count_mismatch` and zero orphaned `audio_without_utterance`. That last +part matters because this image also carries the fix for a separate ordering defect found while +qualifying it: `utterance_end` could be queued ahead of a PCM chunk it had already counted, because +the socket writer drains queued text before queued binary. + +Treat this as the zero-delta evidence F2 asks for on this specific image. It does not transfer to any +other SHA-256. + ## F3. Vision delivers nothing at all **Observed:** `camera_frames` climbing normally, but `camera_face_batches: 0`,