[shockalotti]

The bug (mine)

The append-only guard I added in #161 compares the pull request's ledger against the tip of the base branch. Signatures are committed to main by the CLA bot, so a signature added after a PR was opened is absent from its head by construction. Comparing with today's main calls that "removed".

That is what hit four PRs at once:

#176, #179, #158, #159 → check=fail
##[error]Process completed with exit code 1     (CLA ledger is append-only)

MohammadHadi2031 signed, main grew from 11 to 12 ledger entries, and every PR forked before that point was reported as revoking his signature. Nothing was removed from any of them.

Fix

Compare against git merge-base HEAD origin/<base> instead, which only sees entries the PR's own branch actually had.

• Checkout fetches full history for this job so the merge base is computable. The repository is 8MB.
• A shallow clone that still cannot compute a merge base now warns and skips rather than failing closed on an infrastructure limitation.

Verified against the real case

base compared	result
main tip (old)	reports MohammadHadi2031 (id 17288524) removed, exit 1
merge-base (new)	nothing removed, exit 0
merge-base, one signature genuinely deleted	fails, naming tgrahammer (id 3223680)

So the guard still catches a real removal; it just no longer mistakes a later signature for one.

YAML parses and the shell block passes bash -n.

[pullfrog]

✅ No new issues found.

Reviewed changes

Reviewed the single-file CI change that re-anchors the CLA append-only guard to the PR's merge base.

• Full-history checkout — fetch-depth: 0 added so git merge-base can be computed in the job.
• Merge-base comparison — the guard now diffs the PR head against git merge-base HEAD origin/<base> instead of today's main tip, so a signature added to main after the PR's merge ref was generated is no longer misreported as revoked.
• Skip when no merge base — a missing merge base now logs a warning and exits 0 rather than failing closed.
• Bootstrap case preserved — a missing ledger at the merge base still exits 0 with the same message.

I verified the premise locally: for pull/176/merge, git merge-base FETCH_HEAD origin/main resolves to the merge commit's first parent (the base tip at merge-ref generation), and the ledger at that base, at the merge commit, and at today's origin/main all carry the same 12 ids, including MohammadHadi2031. The merge-commit working tree also reflects head-branch deletions, so a genuine removal is still caught against a base that still holds the id. bash -n on the extracted step passes and the YAML parses.

  ^{｜ View workflow run ｜ Using deepseek-v4.1-flash ｜ 𝕏}