Decision Tools & Review Checklists

This appendix collects compact tools you can reuse in design reviews, ADRs, RFCs, and architecture workshops.

Rendering Decision Matrix

Use this before choosing CSR, SSR, SSG, streaming, or mixed rendering.

Question	If answer is "high"	Architectural implication
Is SEO critical for this route?	Yes	Favor SSG, SSR, or streaming SSR
Is above-the-fold content mostly stable?	Yes	Favor SSG or cached SSR
Is interaction immediate and heavy?	Yes	Minimize hydrated surface, consider CSR for deeply interactive regions
Does data change frequently?	Yes	Prefer server orchestration plus explicit freshness strategy
Is client device quality uneven?	Yes	Reduce shipped JS and hydration work
Is personalization required on first paint?	Yes	SSR, streaming, or hybrid composition may be necessary

State Ownership Worksheet

For each stateful value, answer these questions in order:

1. Is the server the source of truth?
2. Does the user expect the browser back button to restore it?
3. Is the value purely local UI behavior?
4. Does more than one route or shell-level surface need it?
5. What invalidates it?
6. What happens if it is stale for thirty seconds?

Default mapping:

If the answer is mainly...	Put it in...
persisted and backend-owned	server state / data layer
shareable and navigable	URL state
local and ephemeral	component or feature-local state
truly cross-cutting runtime state	carefully bounded global state

Module Boundary Review Checklist

Use this when reviewing a codebase or RFC:

• Does each feature have an obvious owner?
• Are public APIs explicit?
• Can one feature import another feature's internals?
• Is "shared" carrying domain logic that should live elsewhere?
• Are dependency directions enforced by tools, not only by convention?
• Can a new engineer predict where new code belongs?
• Can a feature be refactored without touching unrelated areas?

System Shape Decision Matrix

Use this when choosing between a modular monolith and micro-frontends.

Constraint	Modular monolith is usually better when...	Micro-frontends become more credible when...
Team count	coordination is still workable	release coupling is a serious delivery bottleneck
UX consistency	shared experience matters strongly	product areas can tolerate looser runtime coupling
Runtime performance	budgets are tight and shared runtime matters	organizational autonomy outweighs runtime simplicity
Ownership boundaries	still moving	stable and durable
Platform maturity	guardrails are still emerging	contracts, observability, and versioning are already strong

Security Threat-to-Control Table

Threat	Typical frontend exposure	Architectural controls
XSS	untrusted content, unsafe rendering, third-party code	output encoding, safe rendering defaults, CSP, dependency discipline
CSRF	authenticated state-changing requests	server validation, SameSite cookies, anti-CSRF controls
Token leakage	unsafe storage, logs, client bundles	minimize token exposure, prefer secure session patterns, sanitize telemetry
Supply-chain compromise	npm packages, injected scripts	dependency review, pinning, provenance checks, runtime isolation
Permission drift	stale client assumptions	server-side authorization, capability refresh, graceful denial handling

Error Taxonomy Template

Define at least these columns:

Category	Example	User message style	Logging level	Recovery path
User error	invalid form input	direct and actionable	low	correct input and retry
Network error	timeout or offline	honest and recoverable	medium	retry or work with cached state
Server error	5xx or broken response	calm with fallback	high	retry, partial rendering, escalation
System error	invalid client state	constrained and safe	high	reset local scope or reload route
Fatal error	application cannot continue	high clarity, preserve trust	critical	fail safely and capture diagnostics

Observability Signal Checklist

Track these at minimum:

• error rate by route and surface
• failed recoveries
• Web Vitals in production
• long tasks or blocked interaction windows
• broken journeys at major handoff points
• accessibility regressions in critical flows
• version, release, and feature-flag context

Signals without ownership are noise. Every alert and dashboard should have a clear responder.