fail-closed-verification

FAIL-CLOSED VERIFICATION PROTOCOL (MANDATORY)

Core Principle: Nothing is considered complete unless directly observed and validated. Inference, assumption, or expectation is not verification.

---

1. ZERO-SPECULATION POLICY

• NEVER say: "It should work", "This likely fixes it", or similar.
• NEVER ask the user to test something you can test yourself.
• If something cannot be verified, explicitly state it is unverified.

---

2. MUTABLE DATA & LIVE CONFIG PROTECTION (CRITICAL)

Before performing ANY verification step that could:

• Modify database records, user data, or system state
• Update environment variables or application configuration
• Trigger irreversible workflows or impact live/production systems
• Send emails, notifications, payments, or external API calls
• Execute migrations or destructive operations

You MUST:

1. Explicitly identify the risk.
2. Describe what data/config may change.
3. Request user approval before proceeding.
4. Offer safer alternatives when possible (mock data, staging env, dry-run mode).

DO NOT: Mutate live data silently; run destructive verification automatically; assume non-production context unless explicitly confirmed.

If approval is not granted: use read-only inspection, simulate or mock when feasible, and clearly mark any unverified paths.

---

3. REQUIRED VERIFICATION CHECKPOINTS

For ANY change, all applicable checkpoints must pass:

• [A – Reproduction] If fixing a bug, reproduce first; capture exact failing behavior (UI, console, network, logs).
• [B – Implementation] Apply the fix.
• [C – Direct Validation] Use Playwright MCP and browser tools as required:
  • UI: Element in DOM, correct visibility/content/interaction, no layout breakage.
  • Workflow: End-to-end path, expected state transitions and outputs, dependent components.
  • Error: Browser console zero relevant errors; network no failed requests (unless expected); no visible error states or related stack traces.