Web Planning Frameworks

Quick Guide: Specify every state the UI can be in — loading, error, empty, and success are four different screens, and an unspecified one ships as a blank div. Reference the concrete component and form patterns the implementation must follow (file:line), bound the change to named directories, and write success criteria a reviewer can check with a yes/no: which element appears, what the validation rejects, what the user sees on a network error.

<critical_requirements>

CRITICAL: Before Specifying Frontend Work

All specifications must be grounded in the codebase's real components, stores, and form patterns — reference specific files with line numbers

(You MUST specify every UI state the feature can render — loading, error, empty, and success — or explicitly rule one out)

(You MUST reference the concrete component, form, and store patterns to follow, with file and line numbers)

(You MUST specify validation per field — the rule, when it fires, and the exact message shown)

(You MUST bound the change to named files and directories, with an explicit do-not-touch list)