/preflight

description: "Executed pre-completion checklist — third sibling of /prospect (before execution) and /retrospect (after shipping). Six checks, three outcomes each (PASS/FAIL/INVALID); an unrun check blocks the verdict. Catches failures that emit no error: a check whose FORM bounds what it finds, and a decision correct in isolation but wrong in context. Use BEFORE claiming done/fixed/shipped/verified/'none found', before a PR, or before posting a result on a ticket. Triggers: '/preflight', '/preflight ticket <id>', '/preflight file <path>'."

/preflight — the checklist you run before you report

`/prospect` looks forward at a plan. `/retrospect` looks back at shipped work. **This runs at the moment in between: you believe you are done, and you are about to say so.**

What this is NOT

**It is not `superpowers:verification-before-completion`,** which owns the principle — *no completion claim without fresh verification evidence* — and owns it well. That skill answers **whether** to verify. This one answers **what to verify**, and specifically: the checks whose *absence produces no signal at all*.

If you have not internalised the Iron Law, read that skill first. This one assumes it and adds the cases where you ran a verification, it passed, and the thing was still broken.

The two failure families this exists for

Every check below descends from one of these. Neither produces an error, a failing test, or a warning.

1. **The check's FORM bounds what it can find.** A search whose pattern bounds its result; a review whose scope bounds its result; a probe whose anchor bounds its result. The instrument reports truthfully about the thing it measured — and you asked it the wrong question. 2. **A decision correct in isolation, wrong in context**, where nothing you looked at was measuring the part that broke. A green build measures compilation, not reachability. A docstring records a decision without disclosing it. A model's name states one job, not both.

> **The consequence they share: the absence of a problem signal is not evidence there is no problem.** > Family 1 because your check couldn't see it. Family 2 because nothing was checking.

How to run it

Work through the checks that apply to your change. **Every applicable check gets a recorded result.** An unrun check is not a pass — it blocks the verdict.

Each check has **three** outcomes, never two:

| | | |---|---| | **PASS** | the check ran and the property holds | | **FAIL** | the check ran and the property does not hold | | **INVALID** | the check could not distinguish absence from a broken probe — **report no verdict, fix the probe** |

The third outcome is the whole point. A probe that returns "nothing found" because it was pointed at a path that does not exist reads exactly like a clean result.

---

P1 — Requirements diff · *does what shipped match what was asked?*

**A rationalisation in code is not a disclosure.** Nobody diffs docstrings against requirements at review, so an omission explained in the source is invisible in exactly the place it needed a second opinion.

1. List every field, endpoint, behaviour and response shape the request named. Mark each **shipped / not shipped**. Mechanical; it takes a minute. 2. Every "not shipped" goes in a **ticket comment** — not a docstring, not a commit message, not a PR body. 3. **"There is nowhere to store this" is a question, not a decision.** Say so and stop. Do not narrow the deliverable to fit the schema you found — that is the signal the request and the schema disagree, and that is the owner's call. 4. Check what the **UI promises** against what you returned. A surface labelled with a word the data cannot support is a defect even when every line is correct. 5. Where you substituted something, **name the substitution.** "Returned the resolved email instead of the requested username" is reviewable; silence is not. 6. **Enumerate the paths, don't re-read the diff.** A fix can close a disclosure on two code paths and leave it open on a third — re-reading the change will not show you the path you never touched.

---

P2 — Consumer census · *does this symbol have a second job?*

**A model's name and fields do not tell you its jobs.** A row can be a record *and* a permission at the same time; a delete that is obviously right for the first is a silent privilege change for the second, and nothing in the model, the migration or your endpoint will mention it.

# every consumer, minus vendored code and migrations
grep -rn "<SYMBOL>" --include='*.<ext>' . | grep -v "/<vendor_dir>/\|/migrations/"

# of those, which sit inside an authorization decision?
grep -rn "<SYMBOL>" --include='*.<ext>' . | grep -viE "test|migration" \
  | grep -iE "allow|permission|access|authoriz|can_view|visibility|entitle"

1. Run it **before** writing the endpoint, not after. 2. **Write out what each consumer uses it for.** The census is worthless unread; writing it is what surfaces the surprise. 3. If any consumer is an authorization or access check, **a delete on that model is a permission change** — say so explicitly and get it ruled on rather than shipping it inside a feature. 4. Ask what the **absence** of a row means, not just its presence. Where presence grants something, deletion revokes it — and "cancel" is then the wrong word for the button. 5. **Beware the inverted fix.** On discovering a row doubles as a grant, do not "clean up" by deleting it at some lifecycle point. That revokes access. The fix is usually a new column or a derived flag. 6. **Aliasing:** can two rows point at the same underlying resource? If so, deleting A's "old" resource may destroy B's live one.

---

P3 — Reachability · *is it actually wired in?*

**A green build measures compilation, not reachability.** A component nothing imports is tree-shaken out: it compiles, it deploys, and it is not in the product.

**Frontend**

# does anything impo