fix(series): Stop counting a buffer commit stage 5 would drop as empty

[krlmlr]

series-check.sh counts every commit in the buffer range. series-advance.sh replays them with cherry-pick --empty=drop, so a commit whose every path -dev already carries at that commit's post-image produces nothing and is dropped. The two disagree, and the disagreement does not settle: the firing reads ADVANCE, runs the advance, is told dev -> … (+0), and reads ADVANCE again next firing. Only a new vendor commit on the buffer clears it, by moving the anchor past the whole run.

The commit that has been doing this

v1.4-andium has read ADVANCE since 2026-08-06, on f52ed130b:

=== v1.4-andium: 0 in flight, 1 buffered, green=9aabbe331 dev=9aabbe331
  ADVANCE

and the advance that verdict asks for says

green unchanged at 9aabbe331
dropping f52ed130b0955dc140c46476156d52744635ebd7 chore: Auto-update from GitHub Actions -- patch contents already upstream
dev -> 9aabbe331 (+0)

Upstream v1.4-andium last moved on 2026-07-07, so nothing was going to clear it on its own.

Where the commit came from is worth recording, because it is not a one-off. A buffer takes no ports by design, so v1.4-andium-build's .github/ still carries the v*.*-* push filter that main's R-CMD-check.yaml has since dropped. That pattern matches every v1.4-andium-* series ref, so a ref move triggers rcc from the buffer's own tree, and its auto-update step commits a Config/roxygen2/version bump back onto the ref. It happened again on 2026-09-04, on v1.4-andium-build-base this time — run 33918111854, head branch v1.4-andium-build-base — producing 842165b3c, a second sibling of f52ed130b with an identical tree. That is the sibling pair .claude/skills/series-loop.md records under stage 3 as having happened once; it has now happened twice, and this is what wrote it. Nothing on main can reach those buffers, so the loop has to read the situation correctly rather than be spared it.

The fix

consumable_count <range> <dev> counts only the commits stage 5 would actually mint, and the buffer count uses it on both of its branches.

The comparison is by content and not by patch-id: git cherry reports f52ed130b as unmerged (+ f52ed130b…), because -dev reached the same post-image by a different diff. So a patch-id test would not have caught it.

Checked

Against the six live series, main's copy of the script:

• v1.4-andium goes from 1 buffered / ADVANCE to 0 buffered / IDLE.
• The other five series' counts and verdicts are unchanged, as are all three CUTOVER lines.
• Run time goes from 1.5 s to 2.4 s over all six.
• A five-commit range of real vendor commits still counts 5.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01FqjecFkTtJTy8FoMbtXH26

---

Generated by Claude Code