01
Start with output
Define what the initial HTML must contain and what must never be exposed. Treat progressive enhancement, canonical routes, and public metadata as testable contracts.
02
Keep state and behavior explicit
Prefer derived data, keep Signals owned, keep captures serializable, and treat each Action as a public server endpoint with its own validation and authorization policy.
03
Release reproducibly
Version configuration and lockfiles, document local-versus-production claims, test accessibility and URLs, and run the complete release matrix before publishing.
PRACTICAL LABS
Run this capability.
Each example states the observable output, the boundary that remains your responsibility, and the check that proves the result.
01
Write an output-first review
Text1. What must the raw HTML contain?
2. What must never reach the browser?
3. Which smallest boundary needs JavaScript?
4. Which request validates and authorizes the mutation?
5. Which artifact proves the release?- OUTPUT
- The design review begins with observable contracts instead of framework buzzwords.
- BOUNDARY
- Do not convert every shared value into global state or every navigation event into a client router.
- PROVE IT
- Review the five questions in pull requests and release notes.
VERIFICATION
Prove the contract.
Use the review checklist before merge: output, boundaries, data validation, security, metadata, media, accessibility, budgets, and operational readiness.