cleanup: close the #504 ward-salvage mega-issue and prune only already-landed salvage branches #530

New issue

Closed

opened 2026-07-02 09:21:29 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-07-02 09:21:29 +00:00

Owner

Why

The #504 [ward-salvage] mega-issue accumulated 39 comments (2026-07-02) from
false-salvages by pre-v0.298.0 reapers (see the stale-pin guard issue). Its
feeder code path was deleted in 9013c9d, so once the stale-reaper tail drains
it stops growing. Cleanup is now safe but must not destroy recoverable work.

Want

Close #504 with a comment explaining the false-salvage cause and that the
feeder path (findOpenIssueByTitlePrefix append-to-open) was removed in
9013c9d / v0.298.0. Do not delete it - it is the audit trail.
Prune the ward-salvage/* branches listed in #504 only where the
branch tip is already an ancestor of origin/main (the work landed, so the
salvage is redundant). Verify each with git merge-base --is-ancestor <branch-tip> origin/main before deleting. Leave any branch whose tip is NOT
on main untouched and list it for a human - that one holds real unlanded work.

Constraints

Never delete a salvage branch whose tip is not already on main. When in
doubt, leave it and report it.
This is a cleanup task, not a code change. If it grows a code change, split it.

Acceptance

#504 is closed with an explanatory comment, not deleted.
Every ward-salvage/* branch whose tip is an ancestor of main is pruned;
every branch that is not is listed, untouched, for follow-up.

Notes

Depends on the stale-pin guard fix landing (and the host ward being current) so
no new false-salvages arrive mid-cleanup. Do this after the tail has drained.

## Why The #504 `[ward-salvage]` mega-issue accumulated 39 comments (2026-07-02) from false-salvages by pre-v0.298.0 reapers (see the stale-pin guard issue). Its feeder code path was deleted in `9013c9d`, so once the stale-reaper tail drains it stops growing. Cleanup is now safe but must not destroy recoverable work. ## Want 1. **Close #504** with a comment explaining the false-salvage cause and that the feeder path (`findOpenIssueByTitlePrefix` append-to-open) was removed in `9013c9d` / v0.298.0. Do **not** delete it - it is the audit trail. 2. **Prune the `ward-salvage/*` branches** listed in #504 **only** where the branch tip is already an ancestor of `origin/main` (the work landed, so the salvage is redundant). Verify each with `git merge-base --is-ancestor <branch-tip> origin/main` before deleting. Leave any branch whose tip is NOT on main untouched and list it for a human - that one holds real unlanded work. ## Constraints - Never delete a salvage branch whose tip is not already on `main`. When in doubt, leave it and report it. - This is a cleanup task, not a code change. If it grows a code change, split it. ## Acceptance - #504 is closed with an explanatory comment, not deleted. - Every `ward-salvage/*` branch whose tip is an ancestor of `main` is pruned; every branch that is not is listed, untouched, for follow-up. ## Notes - Depends on the stale-pin guard fix landing (and the host ward being current) so no new false-salvages arrive mid-cleanup. Do this after the tail has drained.

coilyco-ops commented

2026-07-02 17:59:12 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-530 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T17:59:10Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-530` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T17:59:10Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-02 18:02:16 +00:00

chore(salvage): close #504 mega-issue and prune already-landed salvage branches

coilysiren closed this issue

2026-07-02 18:02:16 +00:00

coilysiren commented

2026-07-02 18:02:38 +00:00

Author

Owner

WARD-OUTCOME: done - closed #504, pruned 39 landed ward-salvage branches, kept 2 unlanded, closed #530 via main push

Honest retro: this one was mostly bookkeeping, and the risky part was exactly
the part the issue told me to be careful about, so it stayed low-drama. The
git merge-base --is-ancestor <tip> origin/main check per branch is a clean,
binary safety gate, and it split cleanly: 39 of the 41 branches listed in #504
were already ancestors of main (redundant salvage), 2 were not
(ward-4b5af5f3, ward-b4d43076) and I left them for a human. No judgment
calls in the grey zone.

One thing that surprised me: the remote carried 45 salvage branches but #504
only listed 41. I scoped strictly to #504's list and left the 4 extras
(0d7db064, 33ebc07c, 86ffb40e, b81af3da) untouched, but they're worth a
follow-up — they look like standalone-issue salvages from the post-9013c9d path
and may each have their own open issue to reconcile.

The other friction was purely mechanical: a concurrent run pushed main out
from under me mid-cleanup, so my record commit needed a rebase before it landed
(a clean fast-forward the second time). Since this was a no-tree-change cleanup,
I carried the audit record as an empty commit — pre-commit passed, closes #530
did its job.

Confidence: high on the deletions (each gated on ancestry, non-destructive by
construction — the tips all live in main's history). Possible follow-up:
triage the 2 kept branches and reconcile the 4 out-of-scope salvages.

WARD-OUTCOME: done - closed #504, pruned 39 landed ward-salvage branches, kept 2 unlanded, closed #530 via main push Honest retro: this one was mostly bookkeeping, and the risky part was exactly the part the issue told me to be careful about, so it stayed low-drama. The `git merge-base --is-ancestor <tip> origin/main` check per branch is a clean, binary safety gate, and it split cleanly: 39 of the 41 branches listed in #504 were already ancestors of `main` (redundant salvage), 2 were not (`ward-4b5af5f3`, `ward-b4d43076`) and I left them for a human. No judgment calls in the grey zone. One thing that surprised me: the remote carried **45** salvage branches but #504 only listed **41**. I scoped strictly to #504's list and left the 4 extras (`0d7db064`, `33ebc07c`, `86ffb40e`, `b81af3da`) untouched, but they're worth a follow-up — they look like standalone-issue salvages from the post-9013c9d path and may each have their own open issue to reconcile. The other friction was purely mechanical: a concurrent run pushed `main` out from under me mid-cleanup, so my record commit needed a rebase before it landed (a clean fast-forward the second time). Since this was a no-tree-change cleanup, I carried the audit record as an empty commit — pre-commit passed, `closes #530` did its job. Confidence: high on the deletions (each gated on ancestry, non-destructive by construction — the tips all live in `main`'s history). Possible follow-up: triage the 2 kept branches and reconcile the 4 out-of-scope salvages.