Refined the Bilateral Coordination Test. The focus of this session was on how to plan the test's "breaking" scenario — what happens when the test is pushed to its limits. The key decision: the breaking plan should stress the bilateral aspect of the test, not just the hand tracking mechanics.
Breaking scenario design: Asked Claude how to design the test's edge cases and stress conditions. Claude focused on camera-based stress scenarios — poor lighting, multiple people in frame, occlusion.
Claude's suggestions were about technical edge cases: what happens if MediaPipe loses tracking, what happens if the camera is low-resolution. These are real concerns, but they're not what the breaking plan should prioritize. The test measures bilateral coordination. The breaking plan should stress bilateral coordination: what happens when users try to use only one hand? What happens at very high dot spawn rates where both hands are fully occupied? What happens when users are fatigued? The test should break on the thing it measures, not on the infrastructure that delivers it.
Breaking a test means understanding what the test measures well enough to push that specific thing. Generic technical stress testing (camera edge cases) is different from domain-specific stress testing (bilateral coordination edge cases). The latter requires knowing the measurement, not just the implementation.
Understanding what a test measures well enough to break it intentionally is a form of ownership over the measurement. If I can only describe what the test does technically (tracks hands, counts dots) and not what it measures clinically (bilateral motor coordination), I don't fully own the assessment.
Session 15: Rhythm Synchronization Test — fix the audio detection algorithm. The zero-tap problem (frequency-domain analysis returning zero for short taps) needs to be solved before the test is usable.