finishinglisted

# Finishing ## Overview **Core principle:** Landing work is a sequence with a human decision in the middle: **prove it's green → figure out where you are → let the human choose how it integrates → execute that → clean up.** How work integrates — and especially whether it's ever discarded — is the human's call, not yours. ## Step 1 — Prove It's Green (on the tree you'll integrate) Run the **full** test/build suite on the actual code about to land, right now. A green run from before your last change does not count (**evidence-before-claims**). Red suite → stop and fix, or surface it; don't land red. **Green includes warning-clean.** A build that passes while emitting compiler warnings is not green — warnings are the compiler reporting probable bugs at the cheapest possible moment, and a warning tolerated today is invisible tomorrow (it scrolls by in every future build until nobody reads any of them). Before landing: - Read the build output, don't just check the exit code. `unused`, `dead_code`, deprecation, and type-lint warnings all get fixed or explicitly gated (`#[cfg(...)]`, `#[allow(...)]` **with a comment saying why**), never ignored. - "It's pre-existing" is not an exemption — file it as a bead if it's out of scope, so it stays visible. "It's only in release/debug profile" is not an exemption — check the profile you don't normally build. ## Step 2 — Detect Where You Are You can't present the right options until you know the git situation: ```bash [ "$(gi