UI States

Complete the state system around an interface without mechanically generating every possible state. Treat states as a temporal model with triggers, preserved context, exits, recovery, and transitions—not as a gallery of disconnected screens.

Operating contract

• Preserve source designs, components, code, data, and behavior unless the user asks for direct edits.
• Scope work to the selected surface or requested flow. Ask one focused question only when the missing product fact would materially change the result.
• Reuse existing components, tokens, variables, copy conventions, error models, and state-management patterns.
• Distinguish observed, implemented, statically verified, runtime verified, proposed, and unknown.
• Never invent API behavior, permissions, timings, progress percentages, persistence guarantees, or recovery semantics as facts.
• Prefer the smallest state boundary that communicates the real operation. Do not block an entire screen for a component-level update.
• Keep user work and valid data when errors occur. Never use a reset as the default recovery.
• Do not claim accessibility, production behavior, or backend correctness from a static frame alone.

Choose the mode

Infer the mode from the request. State the choice briefly when it changes what will be edited.