Request condition	Read	Result
Any frontend source change	Applicable sections of checklist	Reuse-first implementation
Toolchain, dependencies, routing, stack migration, or render/effect semantics change	Relevant section of stack guidelines	Stack-specific constraints
Framework state, lifecycle, routing, or component API semantics change	Selected framework profile	Framework-compatible change
No-op or accepted-baseline confirmation	checklist	Exact owner-symbol and baseline-check evidence
Behavior/public seam, ownership, or quality concern applies	behavior first, codebase design, and/or code quality	Scoped design/validation
A touched file, component, or function mixes independent UI, state, data, side-effect, or business responsibilities	decomposition	Cohesive owners and readable orchestration
Styling system or CSS ownership changes	styling systems or CSS governance for the changed concern	Scoped styling
Shared components/tokens or layout ownership changes	components/tokens or layout	Applicable visual contract
Animation or visual direction changes	motion or visual direction	Applicable interaction/visual contract
Selected-source visual closure applies	specification authorities and visual evidence	Runtime comparison boundary
API/protocol or cross-boundary signal applies	OpenAPI governance, protocol contracts, and/or project grounding	Qualified integration work

Invariants

Reuse the nearest maintained owner before creating; preserve routing, state/data, component, and styling ownership.
Treat size as a review signal, not a line-count rule; split only at a stable ownership, behavior, lifecycle, side-effect, or verification boundary.
A no-op confirmation still reads and reports the exact owner path and symbol plus its matching contract before running the current-baseline focused check.
Use the lowest-cost evidence closest to the changed behavior: source/diff checks, an already-running development surface with hot reload, focused tests, then a full production build only when its boundary or the delivery stage requires it.
Keep Product behavior and UI visual readiness independent; source/build evidence does not prove browser/client/runtime acceptance.
Do not generate visual assets, operate browser/client state, review, or mutate Git.
Return this phase's evidence to the coordinator, who continues already-authorized runtime acceptance, fixes, and delivery through their owners. An owner switch alone requires neither a new task/subagent nor renewed approval.

Output Map

Report scope, authorities, reuse decision, selected profiles, changed files/contracts, focused validation, development-surface evidence and production-build status independently when applicable, exclusions, and gaps.

Reference Map

Read only applicable checklist sections for baseline implementation; use the Route Map for stack and framework detail.
Load each condition-specific reference named in the Route Map only when its condition applies.
Read frontend visual gate example only when constructing visual evidence.
Read usage for triggers and boundaries.
Maintainers only: read eval cases; do not load it during ordinary runtime.

dev-frontend

Frontend Implementation

Entry Gate

Route Map