chore: require end-to-end verification before production changes

.cursor/rules/production-change-preflight.mdc

@@ -0,0 +1,29 @@
+---
+description: Mandatory end-to-end reasoning and verification before production changes
+alwaysApply: true
+---
+
+# Production Change Preflight
+
+Before editing, pushing, or declaring any change complete:
+
+1. **Define the observable result.** State exactly what the user should see or what the API should return.
+2. **Trace the full path.** Inspect every relevant layer from source data through model, service, schema, API, client mapping, markup, CSS, and runtime behavior.
+3. **Model all states.** Cover success, absent data, loading, error, fallback, stale/cache, and interaction states. For replacements, verify that old and new states are mutually exclusive.
+4. **Predict interactions.** Check whether existing CSS, defaults, fallbacks, caching, event handlers, compatibility fields, or persistence can combine with the change and create duplicate or contradictory output.
+5. **Search before adding.** Reuse existing rendering and data paths. Never add a second UI element, state, field, or fallback until confirming how the existing one behaves when new data becomes available.
+6. **Use evidence.** Verify assumptions from code and, for UI/runtime changes, exercise the real rendered path or obtain runtime evidence. Unit tests alone do not prove visual correctness.
+7. **Test the transition.** Validate both before/after conditions: with and without data, success and failure, first load and cached/repeated load.
+8. **Review the final diff as a system.** Re-read changed code with surrounding markup/CSS and callers. Ask: “What else becomes active because this value now exists?”
+9. **Do not overclaim.** Never call work complete, perfect, or production-ready without evidence for the exact user-visible outcome.
+10. **Do not push known-unverified UI behavior.** If live rendering cannot be verified, say so explicitly and request verification instead of asserting success.
+
+## Required UI checklist
+
+- Exactly one intended visual element appears.
+- Fallback is hidden when primary content succeeds and appears when it fails.
+- Empty, loading, error, selected, disabled, and responsive states remain coherent.
+- Browser-resolvable URLs are used; filesystem paths never reach the client.
+- Existing flows unrelated to the change remain unchanged.
+
+The task is complete only when implementation, rendered outcome, and fallback behavior agree.