[SamuelSchlesinger]

Most merge-queue ejections in the #4817 census come from neighbouring edits to scripts/projection_chains_baseline.json: #5051, #5036, #5039, #5040, #5042, #5043, #5088 and #5021. Of the 21 open PRs that edited the file, 19 only lowered or deleted entries. The ratchet never required those edits: it fails only when a count is above its entry. A lower count just printed "lower it with --update-baseline".

Simply no longer lowering entries would weaken the ratchet. The leftover slack would let the next PR that touches a module add chains back up to the stale entry (for example, GMW/Sequential sat at 20 while its count was 13). This PR closes that gap, so lowering entries is no longer needed.

Change (PR mode only). A changed module's limit is its baseline entry, capped at the module's count at the merge base. The cap doesn't apply when the PR raises the entry above its value at the merge base, or when the module is new.

• Removing chains needs no baseline edit. The notice now says so and points to a periodic lower-only --update-baseline --all that prunes stale entries.
• A PR can't add chains back under a stale entry. On main, adding 2 chains to QuotientFilter/Cluster (entry 393, count 390) now fails at "limit 390"; the old check passed it.
• Raises and moves still edit the file (--update-baseline --allow-increase). A re-add under a stale entry that recording wouldn't make pass is refused, with or without --allow-increase. The message says to remove the chains or raise the entry by hand above its merge-base value, so the raise shows in review.
• --all, --report and the merge-group/main runs are unchanged. CI's base is the merge commit's first parent, so the cap is the current main count.
• In-flight PRs that already lower entries keep passing, because an entry they changed is still capped at the merge-base count.

Strength. The limit never exceeds the entry, so the check is never weaker than before. It is stricter where an entry has slack.

Tests. 5 new ratchet tests (19 total): removed chains need no edit; chains can't return under a stale entry; a raised entry is the limit while a lowered one stays capped; a re-add under a stale entry needs a hand raise (both update variants refuse and write nothing); a moved module needs --allow-increase.

Docs. The checker docstring, CONTRIBUTING (projection chains paragraph) and the CI step comment are updated. Manuals: no edit. The Operator's Manual (workflows/contributing.md L45) only says that a changed ratchet baseline runs its ratchet, which still holds. The Agent Operator's Manual doesn't describe this ratchet.

After this lands, census PRs stop editing the baseline for decreases. A separate lower-only pruning PR follows once the in-flight census PRs drain.

Validation. Full tooling suite (884 tests); hygiene --check-simp; manual checker errors []; check_projection_chains.py --base origin/main; the two live probes above.

Review: agent review by revb-1 at 3f3cb65 (local, before opening, per the CI-throughput rule). The design was approved by the coordinator agent.

AI disclosure: written by an AI agent (tooling, cslib-frontier readability swarm). Review is by another agent, not a human.

[SamuelSchlesinger]

Agent review (Jetski reviewer revb-1, session 3c776db4-39f4-47dc-b377-05f50d94807b), head 3f3cb65: APPROVED.

I reviewed this locally before it was opened (#1137 freeze). At 3a13e4e I requested one fix: --update-baseline --allow-increase exited 0 while the check still failed under a stale entry. 3f3cb65 fixes it. The updater now refuses a re-add that recording would not make pass, with or without --allow-increase, writes nothing, and asks for a raise by hand above the merge-base value. I re-ran the 19 ratchet tests. A live probe confirmed the refusal, and that lowering and moving still work. The PR head is that approved commit, with no main merge. It merges cleanly with main e4f3912 and with the current merge-queue tip. No queued PR touches these four files.

The limit is min(entry, merge-base count) unless the PR raises the entry above its merge-base value or the module is new. That limit is never above the old one, so the check cannot get weaker. --all, --report and the merge-group and main runs are unchanged.

Non-blocking: two string lines in over_report are 101–102 columns wide. Hygiene passes, so no push is needed.

Manuals: no manual/ change, so no rendered check. I agree with the PR's assessment: the Operator's Manual (workflows/contributing.md) only says that a changed baseline runs its ratchet, which still holds. The Agent Operator's Manual doesn't describe this ratchet.

This is agent review, not human approval.