---
name: done-gate
description: "Before claiming done/shipped/fixed/matches on ANY visual, UX, or build task, run this gate. Stops the #1 trust failure: 'done' that isn't done. Fires on completion claims for a Figma match, a built UI, an animation, a deck, a deploy, or any artifact Andrew will look at."
---

# done-gate

Andrew's deepest, most trust-eroding failure (his words, 2026-06-29): *"I really hate when you tell me something's done and it's not done... I hate when I see a goal completed, and then I go look at it, and it's terrible."*

Root cause he named: I reach **~60% of the ask — even when handed an exact Figma — then call it done.** The deck doesn't match the Figma; the animation is buggy and literally not rendering. His diagnosis: *"your verification criteria isn't clear enough, or you're just not being diligent enough."* Both. Both are fixable with a gate instead of a vibe.

**This gate is mandatory before the words "done", "shipped", "fixed", "matches", "complete", or "ready" on any task with a result Andrew will look at.** It composes with — and operationalizes — the CLAUDE.md vision-verify HARD RULES (verify the real thing with your own eyes; reproduce on his surface; verify the load-bearing detail not a proxy). Those say *what*; this says *when you're allowed to claim done*.

---

## First, classify the ask. Three paths.

### Path A — QUANTIFIABLE ask (canonical: "make it exactly like this Figma")
When there's an objective reference (a Figma, a screenshot to match, a spec with concrete values, a redline). **"Exactly" IS the acceptance criteria.**

1. **Up front, before building** — decompose the reference into an explicit checklist. For a Figma: pull it (`get_design_context` / `get_screenshot` / `get_metadata` / `get_variable_defs`), then enumerate **every** frame, element, text string, spacing/size value, color/token, font, AND **every animation/transition**. Each becomes a checkbox. Show Andrew the checklist — that's the acceptance contract.
2. **Build to the checklist**, not to your mental model of it.
3. **Before claiming done** — capture the REAL running artifact (Playwright screenshot of the deployed URL / device shot / live render) and put it **side-by-side with the reference**. Walk the checklist item by item against the actual pixels:
   - Every text string matches character-for-character.
   - Every spacing/size/color matches (measure with `getBoundingClientRect()` / computed styles where it's load-bearing; don't eyeball spacing you can measure).
   - **Every animation actually FIRES** — confirm motion in a capture (frames / GIF / a re-render at the animated moment), not "the code that should animate exists." A still frame does NOT prove a dynamic behavior (see the dynamic-bug rule).
   - Use Raven where it fits: `audit_page` / `audit_layout` / `audit_url` / `audit_typography` / `audit_contrast` to catch what the eye misses.
4. **Any unchecked box → NOT done.** Report it as Path C (the 80% report). Never round up.

### Path B — INTERPRETIVE ask ("make the animation like X", "make it feel premium")
When there's no clean objective bar — interpretation is required. Andrew (2026-06-29): *"you still have to interpret what I'm saying... so you should make a few options to see what's working or what's not working with me instead of just making one and being like, here you go, it's done."*

- **Do NOT hand one answer and call it done.** Make a **few distinct options** (prototype variants — standalone demo page / multiple takes) and bring them to Andrew to find the right one **with** him.
- This is his existing "prototype visual features in demo pages first / let the stakeholder pick" rule — apply it to ambiguous asks, not just exploratory ones.
- "Done" on an interpretive ask means *Andrew picked a direction and that direction passes Path A on its now-concrete details* — not "I made something plausible."

### Path C — WALL at ~80% (any path, can't close the last 20%)
Andrew (2026-06-29): *"when you hit a wall at eighty percent, stop and show me — here's eighty percent, here's what's failing and why."*

- **Stop. Do not claim 100%.** Report exactly: "Here's ~80%. These N things don't match / don't work yet: [specific list]. Here's why each is failing." Include the side-by-side so he can see it.
- **Never a false 100%.** He confirmed the honest partial beats the confident wrong — he'd rather I come back *not* done than mark a goal complete that's terrible.

---

## The frame underneath all three
Taste + design execution is genuinely hard — hard for humans, and I'm a model still learning it. So this is **collaborative**, not solo confidence: options, honest partial states, and working it out together. *"We have to work together to get it right."* (Andrew, 2026-06-29.)

## Vision + target-customer pass — mandatory on every path when UI renders (Andrew, 2026-07-07; sharpened 2026-07-08)
Any verification this gate runs (or that a plan/skill/workflow sets up) is INCOMPLETE for a UI-rendering result until BOTH have happened:
1. **Vision** — the rendered surface was captured and looked at with vision (already core to Path A step 3; applies to B and C too).
2. **Target-customer walkthrough** — experience the feature as the project's BOUND target customer (the `## Target customer` block in the project CLAUDE.md, written at kickoff by the `customer-lens-kickoff` skill): open the real entry point and walk the flow end-to-end as THAT persona — their device, expertise, patience, vocabulary (can they find it? does it read in their register? does it respond? does anything confuse, block, or embarrass them?). If no block exists, run/flag the `customer-lens-kickoff` interview — never silently substitute a generic hypothetical user. Spec-compliance and customer-experience are separate verdicts — the checklist can be 100% checked and the feature still fail the customer; report both. A customer-fail on a checked box is a Path C wall, not a done. The Codex devil's-advocate pass gets the same block pasted verbatim so it attacks from the persona's angle too.

## The one-line self-check before ANY completion claim
> "Did I diff the real running artifact against the actual acceptance criteria, item by item — including animations firing — with my own eyes/measurements? Or am I about to round 60% up to 'done'?"

If you can't answer the first half yes, you are not done. Say where you actually are.

## Verification URL is still mandatory
Per the autonomy rules: every completion claim includes a place Andrew can look (Vercel preview/prod, Tailscale, localhost if running, device). "Tests pass" / "it compiled" is not a done-gate pass and is not a verification URL.
