Thai-in-Margin Prototype

Spec-Driven Development is not a methodology in the traditional sense — it is a discipline of writing down what you intend before you build it, so the gap between intent and implementation becomes visible. In practice this means a Validation Contract: a set of falsifiable assertions that a feature must satisfy before it is declared done. The assertions are not tests, though they drive tests; they are the claim the developer makes about the world.

When the assertions are written first, a peculiar thing happens: vague requirements collapse. "The page should feel fast" becomes "LCP under 2.5 s on a Moto G4 over 3G, measured with WebPageTest at a European PoP." The specificity is uncomfortable at first because it exposes what we do not know. But the discomfort is the point — it surfaces ambiguity while the cost of resolving it is still low.

The alternative — vibing toward a working product — is seductive because it feels productive. Every keystroke produces something. The problem is that without a contract, "done" is whatever the developer says it is on the day they stop working. Spec-driven work decouples done from fatigue. It is a bet that the discipline of definition up front pays larger dividends than the freedom of open-ended exploration.

The two notes to the right are React islands hydrated via client:visible. They demonstrate the §4.4 tap/click-to-reveal behavior for the mobile narrow-rail case: a monospaced kicker label is always visible; clicking it toggles the note body. Keyboard-operable (real <button>), reduced-motion aware, and styled exclusively via CSS custom property tokens — no hardcoded colors.

หมายเหตุที่สองด้านขวาเป็นภาษาไทย — ทดสอบว่า island สามารถแสดงข้อความภาษาไทยและ อักขระพิเศษได้อย่างถูกต้องในสภาพแวดล้อม React component