Landing the Plane

When someone asks you to "land the plane", they want you to wrap up the current body of work cleanly—no loose ends, no hidden surprises. Use this checklist any time that phrase shows up.

Non-negotiable: landing the plane always ends with a pushed branch and an open (non-draft) pull request. Even if the work started on main, cut a feature branch, push it, create the PR, and flip it out of draft before you check this box.

1. Quality Gates

• Run the full automated test suite plus linters/formatters that the project relies on in the feature branch you’ll merge.
• Confirm that the code you wrote is covered by automated tests; add or expand tests if any path would otherwise go unverified.
• When a review uncovers a bug/regression, follow this micro-loop before touching the fix:
  1. Write (or extend) a failing test that reproduces the issue. Default to a generative proptest! so the failing input can shrink and be re-run later.
  2. Run the pre-commit suite, commit that red test by itself, and push so the failing state is visible on the PR/branch.
  3. Implement the fix in a separate commit, push it, and reply to the original feedback thread with the fixing commit hash/summary.
  4. Comment @codex review (or ping the human reviewer) to kick off the next review once the fix is in place.

Transactional upgrades check (sticky failure prevention)

If the work touches any multi-item “apply/upgrade” loop, add property/integration tests that prove these invariants: