adopt-project.py execute refuses only plan-unresolved and plan-stale, so a plan check rejects as uncovered or with a bad leg creates and pushes both legs before it fails verification #168

(lane openRepoShape-1, 2026-10-08T21:51:14Z)

What is wrong. _refuse_an_unrunnable_plan refuses only plan-unresolved and plan-stale. A plan that check rejects for any other reason (plan-uncovered, plan-bad-leg, plan-covered-twice, plan-duplicate-path, plan-empty-entry) reaches execute, which creates and pushes BOTH legs and only then fails verification. A re-run with the corrected plan then meets REFUSED leg-remote-exists.

Reproduced on main (7f84ca4) and on the #166 branch alike, with a 1-commit source carrying one submodule:

upstream/ entry deleted     check: FINDING plan-uncovered: upstream/dependency ...
                            execute rc=1: FINDING adopt-lost: upstream/dependency
                            remotes afterwards: Northwind-code.git, Northwind-spec.git
upstream/: Spec             check: FINDING plan-bad-leg
                            execute rc=1: adopt-lost: upstream/dependency, legs created
.gitmodules: Code           check: FINDING plan-bad-leg
                            execute rc=1: adopt-lost: .gitmodules, legs created

It is the same shape #166 fixes for split submodules (the plan's defect is discovered after the legs exist) from a different cause. AGENTS.md step 4 has a human say yes after check, but execute is the only gate that cannot be skipped.

Found by the adversarial review of the #166 branch (head aaa9099).

What would fix it. execute refuses every finding class check reports, from the same functions, before _create_leg_remotes: _coverage_findings and _leg_findings (and #166's submodule_plan_problems) become one list both commands read, so a plan check rejects can never create a leg. A test per class asserting no leg repository exists afterwards.

What must not break. A plan check passes executes exactly as today; --allow-empty-leg seeding is unaffected.