Analyzed the code for multiple prototype versions: Dot Destroyer V1 (single-hand), Dot Destroyer V2 (two-hand), and the Hand Shape Reaction Test. Focused on understanding what every tool and library actually does and why it was chosen. Also evaluated platform options for where to build the project going forward — comparing AI Studio, Cursor, Replit, and Claude/Cowork.
Code Analysis: Asked Claude to break down every tool in both prototypes. Got a detailed breakdown of the shared tech stack (React, TypeScript, Vite, Tailwind, Motion, Lucide) and the critical difference between the two MediaPipe approaches.
@mediapipe/hands (Dot Destroyer) returns raw 21-point coordinates — the code decides what the hand is doing. @mediapipe/tasks-vision (Reaction Test) returns named gesture labels — the model decides. This isn't a preference; it's a fundamental difference in what's measurable. For custom gestures like pinch-to-grab, you need raw coordinates. For recognizing standard hand shapes, you use the recognizer. The right tool depends entirely on what the interaction needs to detect.
Platform Evaluation: Asked Claude to compare AI Studio, Cursor, Replit, and Claude/Cowork. Key finding: Cowork can write and edit code but has no built-in browser preview. Replit is browser-based with real file structure, handles React + Vite natively, and pairs with Cowork for live preview.
Claude suggested Cursor as the most powerful environment for serious development. I chose Replit instead — not because it was better in absolute terms but because I needed live browser preview in the same session, and the learning curve for a local dev setup would have cost time I didn't have. Tool choices should be made on actual project constraints, not general best practices.
The most important distinction of the session: understanding what a tool does versus knowing that it works. The @google/genai package appears in both prototypes' package.json files but is unused — a leftover from earlier Gemini-based versions. I wouldn't have caught that without reading the dependency list myself. AI-generated code inherits AI's previous context; you have to check what's actually in it.
I also learned that "owning" a prototype means being able to explain every tool choice. Not just what it does — why that one, why not the alternative.
Understanding tool rationale is directly tied to building assessments that actually work. If I don't know why a MediaPipe approach was chosen, I can't make intentional decisions when the measurement needs to change. The V1 vs V2 comparison also confirmed the quarter question direction: adding cognitive load (color-matched hands) on top of physical input is what moves a game toward an assessment.
Research into practitioners in the cognitive assessment space: ACE-X, NIH Toolbox, José Azuara. Understand what already exists and what gap Baseline fills. Then write the Position Statement.