Web Planning Frameworks

Quick Guide: A UI spec is a contract about what the user sees in every state, and a state nobody specified still renders — as whatever the developer improvised. For each data-driven surface, specify loading, error, empty and success; for each UI piece, decide reuse, extend or create against a named component; for each form field, the rule, when it fires and the exact message; for each piece of state, one owner; and for each success criterion, what a reviewer will see. Apply a framework only where the feature touches its artifact — a feature with no form carries no form contract.

Detailed Resources:

• examples/core.md — bad and good spec fragments for each pattern; read in order, the good ones are the web sections of a worked profile-editing spec

<critical_requirements>

Before writing a frontend spec

Specify loading, error, empty and success for every data-driven surface, or rule a state out in writing. An unspecified state still renders — as a blank region, a spinner that never resolves, or whatever the developer guessed.

Decide reuse, extend or create for each UI piece, naming by file and lines the existing component each decision was measured against. A spec that says "a modal" gets a new modal; one that names the existing modal gets its focus handling and dismissal for nothing.

Give each form field its rule, when the rule fires, and the exact message. Timing and wording left open are decided form by form, so two forms in one product validate differently.