lane-end's close-out gate: should a lane-owned branch whose open PR is fully published hold the lane's end? (Copilot round 2 on #175, after the cap)

[brettheap]

Filed from Copilot's second (last, under the two-round cap) review of #175, thread on lane-end at 41b5a6a:

This filter drops a lane-owned branch with an open PR. branch_items emits open-PR branches as keep with retire=False even when their Lane: trailer matches this lane, so a lane with that local branch and no other leftovers can end. That contradicts the close-out contract and the stated rule that keep rows left by --yes still block; preserve branch ownership in the porcelain contract and count lane-owned protected rows here.

What #175 does today

lane-end's close-out gate counts the rows whose second porcelain field is retire, plus every cache row and the gate's own residue. It defers to the sweep's retire flag, so the gate and lane-worktrees sweep never disagree about what is the lane's to retire.

On #169's base (45fa45d), branch_items emits a branch named by an OPEN pull request as keep with retire=False, whoever owns it. So a lane whose only leftover is a local branch of its own with an open PR ends cleanly.

Why it was not taken in #175

1. It is a policy question about the sweep's contract, and that contract is moving in lane-worktrees: close #170's --yes data-loss and gate holes, self-check every removal, switch --yes back on #174. lane-worktrees: close #170's --yes data-loss and gate holes, self-check every removal, switch --yes back on #174 (stacked on the same base) already changes the open-PR row to retire = ours and published is not True (lane-worktrees: review findings deferred from #168/#169 (incl. five --yes data-loss paths found after the two-round cap) #170 G2): a lane-owned open-PR branch whose tip origin LACKS now counts. Once lane-worktrees: close #170's --yes data-loss and gate holes, self-check every removal, switch --yes back on #174 lands, the gate inherits that through the flag with no change to lane-end. What it still would not count is a lane-owned open-PR branch whose work is all on origin, under review. Whether that should hold a lane's end is the question.
2. Counting it would be a second, parsed reading of ownership. The porcelain carries ownership only inside the branch row's free-text detail (owner <lane>). Adding a column is a change to lane-worktrees sweep: retire a lane's abandoned worktrees, rescue first, never a live writer (#162, part 1 of 2) #168's porcelain contract, and lane-worktrees: close #170's --yes data-loss and gate holes, self-check every removal, switch --yes back on #174 also edits it.
3. The in-flight guard already holds a lane whose log has an open OPENED. A lane that posted its PR through lanes-edit.sh log OPENED cannot end until LANDED/CLOSED (or --force).

The question for the lane owner

Should a lane-owned branch whose open PR has every commit on origin hold lane-end?

• If yes, the porcelain wants an owner field, or a retire value for it, and lane-end needs no parsing of its own.
• If no, lane-worktrees: close #170's --yes data-loss and gate holes, self-check every removal, switch --yes back on #174's rule stands as the contract, and this issue closes.

Refs #163 #168 #170 #174 #175

Lane: openRepoTools-1