/auto-audit

Iterative audit → fix → build → verify → adversarially review → audit again, until a full pass turns up nothing. "Doesn't exist yet" is a research task, not a stopping point.

Step 0 — Enumerate The Targets

Before the first pass, write down every platform this project targets, and keep the list visible. It is the checklist every later stage runs against. Sources: build config, CI matrix, packaging scripts, README install section, the user.

Targets are whatever the project actually ships to — mobile OSes, desktop OSes, browsers (and the ones you don't develop in), server runtimes and their versions, CPU architectures, containers, embedded boards, CLI shells, plugin hosts, store/distribution channels.

Include the platform you are running on right now. It is a target too, not the neutral place you build from. The host is where verification is cheapest and therefore the one most often declared done on inspection alone — verify it like any other.

If the project targets exactly one platform, say so explicitly and move on. If you can't determine the list, ask — guessing the target set undermines every pass that follows.

The Loop

Run every stage against every target from Step 0. Never skip to the end because the last pass looked clean.

1. Audit — walk every feature the project claims. For each, name the exact runtime path that makes it work, file:line, on each target. A feature with no traceable runtime path is not implemented. Platform-conditional code (#ifdef, Platform.OS, os.name, feature detection, per-target build flavors) gets audited per branch — one branch working says nothing about its sibling.
2. Fix — implement what the audit found. Be thorough and precise; no stubs, no TODO-and-move-on.
3. Build — every target, every time. A green build on one target proves nothing about the rest.
4. Verify in the real environment — run the actual thing on each target and read the actual logs. See below.
5. Adversarially review, by team — hunt for what the fix pass missed, assuming it missed something. One reviewer wearing one hat finds one class of defect; the team colours below are how you get the other classes.
6. Go to 1. Stop only when a complete pass finds nothing new on any target.

Targets you genuinely cannot reach (no hardware, no license, no runner) get named explicitly, with what's missing and what it would take. Try the cheap substitutes first — VM, container, CI runner, cross-compile plus a smoke run, a borrowed device. An unreachable target is reported as unverified, never counted as done.

Respect the project's device policy. Where real hardware is attached, it is the target — an emulator or simulator is a fallback, not an equivalent, and some projects forbid them outright (they are heavy enough to destabilise a shared build machine, and they do not reproduce real hardware behaviour). Check the policy before starting one; absent a policy, prefer hardware and label any emulator result as such. Never silently substitute an emulator for the device.

One pass is never enough. Every pass finds real defects the previous one missed — including in code written earlier in the same session. A pass that finds nothing on its first run means the audit was too shallow, not that the project is done.

After a clean pass

• Note every change needed in project media (video, screenshots, store listings, README assets, demo captures) that the new work invalidates. Stale media is an unfinished feature.
• Push / release / submit to any platform only on explicit user approval. Report ready; do not ship.

The Team Passes

Stage 5 is not one review, it is several, each run from a different seat. The colours come from the InfoSec colour wheel (April C. Wright, 2017): red, blue and yellow are the primaries; purple, orange and green are what you get by combining them. White is the referee — NIST defines a White Team as the group refereeing an engagement between a Red Team of mock attackers and a Blue Team of defenders. Black is not a standard term; it is used here for the surface that is not the code.

The point is not ceremony. It is that each seat is blind to what the others see, and a project audited from one seat is a project whose other failure classes were never looked for.

How to run them without turning one audit into eight. Run Red first — it produces the findings the others react to. Blue, Yellow and Green can run in parallel; they share no state. Purple and Orange are derived passes: they take Red's list as input and produce work items, so running them before Red is finished produces nothing. White runs once per full loop, not per pass. Black is often a short list of "not verifiable from here" — write it down anyway, because it is the surface that gets skipped precisely because it is inconvenient.

A pass that reports nothing is a result, but a suspicious one. Red finding nothing on a feature with real inputs usually means Red was polite. Blue finding nothing usually means nothing is instrumented, which is itself the finding.

Security has its own reading of the same wheel — attack surface, access control, secrets, compliance — and that belongs to /auto-audit-security. This skill's Red pass is about correctness under hostile conditions, not exploitation. Do not do both here; hand security findings across.

What "Finished" Means

The runtime path actually works on each target. Not that it compiles. Not that the UI renders. Not that a comment says it works. Not that a test double returns the right shape. Not that it works on your machine.

Watch for the recurring shape — code that passes compile, launch, and smoke test while moving zero data:

• a class registered against an interface whose method silently returns nothing (getNextFrame returning false forever)
• a callback left null, wired nowhere
• a counter incremented on the wrong side of the failure, so metrics look healthy while nothing flows
• an error swallowed into a log line nobody reads
• a config path that silently falls back to a no-op backend
• a platform branch that compiles to an empty body on every target but the one you tested

Verification = run the real thing in the real environment for that target, read the logs, confirm bytes/frames/events/rows actually moved. Quote the log line that proves it. What "real environment" means per target:

"It Doesn't Exist" Is The Start Of The Work

Capabilities declared impossible on real projects, all wrong:

• a library that "ships binaries for one platform only" — open source, so it cross-compiled to the rest
• a standard with "no SDK for this platform" — true, so the stack was written from scratch against the spec, one shared core across every target
• device metadata that "needs the vendor's database" — false, the devices serve it over the network

Before concluding a capability is impossible:

1. Look for prior art. If any other software does it on this platform, it is a research problem, not a wall.
2. Check whether the blocking component is open source, reimplementable, reachable by another protocol, or replaceable by a native equivalent on that platform.
3. Only then report a genuine platform limit — explicitly, with evidence (the API that doesn't exist, the entitlement that isn't granted, the syscall the sandbox denies, the doc that says no).

Never degrade quietly. Silently shipping a lesser version is worse than saying it can't be done.

Rationalization Table

Red Flags — Keep Working

• About to say "complete", "done", or "ready" without a log line proving the runtime path
• About to say "impossible" or "not supported" without naming the specific missing API
• Verified one target, extrapolated to the rest
• Never wrote down the target list, so "every platform" has no definition to check against
• Counted the host platform as done because you've been building on it all session
• Ending a session on a pass that found nothing, after only one pass
• Writing "known limitation" into docs instead of into a conversation with the user
• Pushing, tagging, or submitting without explicit approval

Quick Reference