The Shelf / QA & Shipping / Deep QA Audit Loop
Deep QA Audit Loop
QA that doesn't stop at N rounds. It stops at zero critical bugs — or it keeps going.
The job: audit an app until it actually works — every page, every flow, every logic path — and don't declare it clean until the exit conditions say so.
Most agent QA is a single pass that skims the happy path, reports "looks good," and self-confirms its own fixes. This skill replaces that with a loop: broad sweep across seven layers, page-by-page end-to-end trace, an adversarial pass that actively tries to refute every fix, then targeted re-audits scoped to each new diff — narrowing until a pass finds zero critical or high bugs. Ten explicit exit conditions. No "should I keep going?" pauses.
What makes it different
The bug catalog. Every class in it was found the hard way in a real shipped app, and several survived multiple standard audit passes before the pattern that catches them existed: the unset-threshold comparison that turned one stray log into a 365-day streak celebration; the "success" screen painted over a disk write that never happened; the security fix whose empty-string fallback would have deleted the app's entire data directory; the deep-link handler that read clean in three audits while the OS never called it once. Each entry ships with the grep or live-drive that catches it.
The verification discipline matters as much as the finding: silence from a shallow pass is indistinguishable from a clean app, a rate-limited verifier looks exactly like a clean bill of health, and a fix reviewed by the eyes that wrote it proves nothing. The loop codifies all three.
What's inside
SKILL.md— the loop, seven layers, exit conditions, adversarial verification, delegation and model routing, scorecardreferences/ios-simulator-audit.md— driving audits through the iOS simulator: tap-through gotchas, the SwiftUI trap catalog, persistence landmines, StoreKit sim limits, the device-test gateQUICKSTART.md— install for Claude Code, claude.ai, and Codex, with a first-run prompt
Who it's for
Anyone shipping with an agent: web apps, APIs, and iOS apps headed for App Review. The core loop is platform-neutral; the iOS material is optional depth for those who need it.
Why not a free directory download
A free directory hosts a prompt someone wrote once. This loop has been run against a live portfolio of shipped apps for months, and every incident that beat it became a permanent check. It's maintained — when a new bug class survives an audit, the file gains the pattern that would have caught it. Field-tested, documented, issued as-is.
FIELD REPORT real output, not a promise
Setup: a Layer 3 (data & display) finding from a real audit of a nutrition-tracking app in our own portfolio — the incident that put the "degenerate threshold" class into the catalog. This is the finding format the loop produces.
Finding: degenerate-threshold comparison — actual >= dailyTarget with an unset target
Severity: HIGH Class: Layer 3 — data & display / trivially-satisfiable comparison
What was found. The app compares logged intake against a user-set daily target in 13 separate call sites (>= dailyTarget). For a brand-new user the target is 0 until calibration completes — and anything >= 0 is always true. Every one of the 13 sites therefore read "goal met" for a user who had done nothing:
- Streak calculator: one stray log produced a 365-day "PERFECT" streak celebration
- Daily-summary ring: rendered 100% complete on day one
- Weekly report: all seven days marked hit
- Milestone/badge triggers: fired off the same false positives
Why prior audits missed it. An earlier audit had found this exact bug — and guarded exactly one of the 13 call sites. The other 12 shipped across two-plus releases. The lesson written into the skill: when a threshold bug is found, grep the threshold variable name across the whole codebase in one pass; fixing the first site found does not mean the rest are guarded.
The fix. A single hasCalibratedTarget guard (target > 0) applied at the shared computation layer, so all 13 consumers gate on the same signal — plus an honest "set your target to start tracking" empty state where the false celebrations used to render.
Verification (Pass 3, adversarial). Fresh-install drive with zero calibration: streak shows 0, ring shows the empty state, no badge fires. Then a refutation probe: target set, met, then reset to 0 mid-streak — confirmed the guard doesn't retroactively wipe legitimate history.
This is one finding from one layer. A full run produces the same treatment across all seven layers, a page-by-page trace, and a closing scorecard with per-pass found/fixed/remaining counts and an explicit YES/NO on every exit condition.
SERVICE RECORD living gear — updated as the factory learns
v1.0.0 — 2026-07-17
First issue. Ported from the factory's internal skill: sanitized for general use, methodology intact, field report captured from a real run.
Every update ships free to owners — your locker always serves the latest version.
QUESTIONS
Is this iOS-only?›
No. The core loop is platform-neutral and runs on web apps and APIs as-is. The iOS simulator material is a separate reference file you use only when auditing an iOS app.
How is this different from asking my agent to 'test the app'?›
A one-shot 'test it' pass skims and self-confirms. This is a loop with exit conditions, an adversarial pass that tries to refute its own fixes, and a catalog of specific bug classes — each one found the hard way in a real shipped app.
Are the bug examples real?›
Every one. Each bug class in the catalog cites the real (anonymized) incident that produced it — including bugs that survived multiple prior audit passes before the pattern that catches them was added.
Does it fix bugs or just find them?›
The loop fixes as it goes — that's the point of the verification passes. Findings come back as file:line, severity, and exact fix; the adversarial pass then checks the fixes didn't break anything else.