ui-proof-looplisted

# UI Proof Loop Turn a UI claim into a bounded, reviewable observation. A passing unit test or a source inspection is useful context, but it is not proof that a screen behaves as expected. ## Make the proof matrix 1. Name the route or surface, user role, environment, and one observable goal. 2. Inventory each screen or entry point with its relevant states: loading, empty, success, error, disabled, and permission-limited where applicable. 3. Pair each state with the action to perform, expected visible signal, and evidence needed. Mark states that are intentionally out of scope. 4. Identify actions that could send data, change records, or reach a protected boundary. Use a safe fixture or a dry run for those actions. ## Run short rounds 1. Start from a known reset and execute one action at a time. Keep each round small enough that a reviewer can reproduce it. 2. When tools support it, record console, network, and DOM evidence alongside a screenshot or other visual artifact. Capture only the lines needed to explain the result and include a timestamp or request identifier when it is safe. 3. Label every observation as live UI evidence, local test evidence, source evidence, or unverified. Do not turn a missing browser/tool capability into a pass. 4. On failure, preserve the first useful trace, classify the failure, and stop before repeated attempts change the evidence. ## Protect people and data - Redact credentials, tokens, cookies, private URLs,