Task: Build Your Deploy-Readiness Audit Rubric

You now understand the twelve failure modes and how to triage them. Your job is to build the actual rubric your team will use before launching JARVIS at the Expo.

Your deliverable:

A deploy-readiness checklist (markdown table or bulleted list) with these columns:

1. Failure Mode — The specific thing that could break (e.g., "Leaked API key").
2. How to Test It — The concrete step(s) a teammate would take to verify this doesn't happen (e.g., "Run git log -S OPENAI_KEY to search git history for the key; result must be empty.").
3. Severity — Your verdict: Blocks Launch / Degrades It / Cosmetic.
4. Pass/Fail — A checkbox for launch-day signoff (☐ PASS / ☐ FAIL).
5. Owner — Who is responsible for testing this before launch (e.g., "Backend team" / "Ops" / "Entire team").

Key requirements:

• Start with the 12 modes from the exercise. Do not invent new ones.
• Make the test concrete and executable. "Check the code" is not a test; "Run this command" is.
• Tie severity back to Day 14's countdown sequence. If a step in the countdown (set secret → build → test → deploy → open URL) would fail because of this mode, mark it Blocks Launch.
• Assign ownership. Who owns each test? Your team can argue about this; the rubric is your negotiation space.

Why this matters:

Day 14 is launch day. The Expo is on Day 15. You have one shot to ship something that works in front of strangers. This rubric is the gate between "works on my machine" and "works for a real user."

Use Claude / ChatGPT to draft the rubric, but your team votes and signs off on it before your first deploy attempt. The rubric is only real when everyone commits to it.