Skip to content

fix(bin): refuse teardown while a task's recorded PR is still open - #1

Merged
joliverMI merged 1 commit into
mainfrom
fm/fm-teardown-open-pr-guard
Aug 16, 2026
Merged

joliverMI merged 1 commit into
mainfrom
fm/fm-teardown-open-pr-guard

Conversation

@joliverMI

Copy link
Copy Markdown
Owner

Re-opened on our own fork per the Admiral's standing order (2026-08-16): fleet-tool work lands where his fleet runs, never proposed upstream. Original upstream PR withdrawn.

Tearing down a task deletes state/<id>.meta, the record bin/fm-pr-merge.sh
resolves the PR through. A branch can be fully pushed and reachable from a
remote (so the existing dirty/unpushed/landed checks find nothing to
refuse) while its own PR still sits open, stranding a mergeable PR with no
guarded path to land it - this happened twice in one night.

The new check runs after the existing dirty/unpushed/landed checks inside
validate_worktree_teardown_safety, so their refusal messages take
precedence and never contradict this one. It fires only when a pr= is
actually recorded (scout, local-only, and secondmate teardowns never
record one). A gh lookup error refuses loudly too, naming the PR firstmate
could not confirm, rather than tearing down blind. --force already skips
the dirty/landed checks and now explicitly skips this one too, since it is
the same "captain says discard" escape hatch - the usage comment spells
out what that means here (the PR needs merging or closing by hand,
outside fm-pr-merge.sh's guarded path).
@joliverMI
joliverMI merged commit 2f973eb into main Aug 16, 2026
12 of 13 checks passed
@joliverMI
joliverMI deleted the fm/fm-teardown-open-pr-guard branch August 16, 2026 23:28
joliverMI added a commit that referenced this pull request Aug 19, 2026
Tearing down a task deletes state/<id>.meta, the record bin/fm-pr-merge.sh
resolves the PR through. A branch can be fully pushed and reachable from a
remote (so the existing dirty/unpushed/landed checks find nothing to
refuse) while its own PR still sits open, stranding a mergeable PR with no
guarded path to land it - this happened twice in one night.

The new check runs after the existing dirty/unpushed/landed checks inside
validate_worktree_teardown_safety, so their refusal messages take
precedence and never contradict this one. It fires only when a pr= is
actually recorded (scout, local-only, and secondmate teardowns never
record one). A gh lookup error refuses loudly too, naming the PR firstmate
could not confirm, rather than tearing down blind. --force already skips
the dirty/landed checks and now explicitly skips this one too, since it is
the same "captain says discard" escape hatch - the usage comment spells
out what that means here (the PR needs merging or closing by hand,
outside fm-pr-merge.sh's guarded path).

Co-authored-by: joliverMI <joliver@sensibletech.biz>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants