Exercise 1: This Course's Core Claim and Its Real Limit — Possible Solution
====================================================================

THE CORE CLAIM, IN ONE SENTENCE
------------------------------
This course's core claim is that the same language, JavaScript, runs on both the client (React) and the server (Express/Node), removing the Python-to-JavaScript context switch that both the FastAPI and Django siblings require.

WHAT ACTUALLY BREAKS THAT CLAIM ONCE NETWORKING IS INVOLVED
------------------------------
Sharing a language does not automatically mean sharing types across the network boundary. Once the Express server sends a JSON response and the React client receives it, there is nothing built into this stack that guarantees the client's expectation of that response's shape actually matches what the server sends - if the server changes a field name, or omits a field, nothing here catches that automatically. The client still has to separately assume the shape is correct, exactly like a stack written in two different languages would.

WHAT WOULD ACTUALLY FIX THIS
------------------------------
The chapter names it honestly: extra tooling not included in this course - such as shared TypeScript interfaces imported by both the client and the server, or a runtime schema-validation library - would be needed to genuinely close this gap. Using the same language is a necessary condition for that kind of sharing to even be possible, but it is not, by itself, sufficient.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly states the core one-language claim, and correctly explains that the claim covers language identity, not automatic type-safety across the network - the same-shape guarantee still requires additional tooling this course deliberately doesn't add.