M4 begins. Connected the homepage to Supabase — first backend integration. Added "Coming Soon" state for tests not yet built. Stabilized the development environment for multi-file work. This session was about infrastructure: getting the foundation in place before building the remaining tests.
Supabase connection: Claude provided integration code for the Supabase client. Pasted it and ran it.
This session I made the connection — but discovered later (Session 11) that I had accepted working backend code without fully understanding the data model underneath it. The type mismatch that would cause the Session 19 security vulnerability was baked into the initial integration. Not a failure of this session specifically, but evidence that "working" and "correct" are different things when you're not yet reading the schema.
"Coming Soon" state: Added placeholder overlay on test cards for tests not yet built. This was a small UX decision that let the homepage communicate a platform (with more to come) rather than a single-test site.
Getting a backend connection working is not the same as understanding what it's doing. Code that runs is not the same as code that's correct. The gap between these two is where bugs live — not dramatic errors but silent failures like storing data to the wrong type, or policies that evaluate to false without raising an exception.
The backend connection is the foundation for the "track" part of the quarter question. Without persistent storage, Baseline can test but not track. Every subsequent session builds on the Supabase connection established here.
Actually understand the backend before relying on it further. Ask "what IS a backend?" before writing another line of integration code. This was the intention going into Session 11.