Repository navigation
#245: delete the arrival check — it subscribed us to another repo's changelog - #253
Merged
Merged
Conversation
…her repo's changelog C-86 is that this repository's release path can be blocked by another repository's routine work. PR #239 was written to reduce that and shipped a check that reproduced it. MEASURED, ON THE LIVE REGISTRY. The drift check had two halves. `changed` is filtered to the names each partner declares. `arrived` was not — it ran over every row of every table this package depends on. Each partner reads 13 of those 25 rows. Eight belong to no repository here: three platform key slots, three caller keys for other repos, and two contract rows. So views-appwrite issuing one key for someone else turned both partner parametrizations red and blocked a merge to main, which is the release to FAO. The same test's docstring, seven lines above, said "Silent through: prose edits, [meta] bumps, and rows belonging to anyone else." The prose described the check that was designed; the code implemented a wider one. ITS SELF-DEFENCE WAS FALSE. The failure message claimed `[contract.*]` "arrived exactly this way, and nothing else here would have seen it". `[contract]` is a top-level TABLE, and `test_every_table_in_the_registry_is_classified_here` — thirty lines above, in the same file — catches exactly that. The case it cited as its reason to exist was already covered by its neighbour. MUTATION-PROVEN IN BOTH DIRECTIONS against the real registry: upstream issues an API key for another repo -> silent (was: red build) a third partner's contract row lands -> silent (was: red build) a value this partner reads rotates -> fires a name this partner reads is removed -> fires The second one is not hypothetical: views-productionapi is a forthcoming consumer, and its contract row landing would have reddened both existing partners. AND THE STOPPING RULE IS NOW IN THE FILE, above the check, because this check has been widened once already: it fires on exactly one condition — a row this partner declares differs between the pinned edition and the sibling's main — and any proposal to add a condition must name the delivery failure it prevents and show that failure is not already prevented by assert_env_declared at run time. Deliberately NOT done: adopting `[edition].obliges_consumers` (views-appwrite#76, shipped as registry v1.6.0). Deleting `arrived` fixes the shipping problem; adopting the flag is an addition, and it would move a safety property onto another repository's labelling discipline. `changed` compares bytes and depends on nobody's self-description. Deferred with a trigger in C-86. Register: C-86's "⚠ CORRECTED" note becomes CORRECTED-and-RESOLVED, with the measurement; its rate claim is now accurate, which it was not before. C-90 gets a partial mitigation — the tautological proof and the untested `registry_current` are #246's and it stays open. Suite 410 passed / 1 skipped / 40 xfailed, ruff clean. The one failure is #248's. Closes #245. Epic #241. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…rule that read backwards
Two independent reviews of the deletion. The deletion itself is sound; three of my own
claims about it were not, and one of them is the defect this whole epic is about.
I WROTE A MUTATION RESULT IN THE PAST TENSE. The docstring, the commit message and C-86
all said an upstream key "reddened this repository and blocked a release". Measured:
ZERO rows have arrived in the depended-on tables since the pin — the arrival half was
green on every real edition it ever saw, from its introduction on 2026-08-11 to its
deletion a day later. And `protect_main` carries `deletion, non_fast_forward,
pull_request` and no required status check, so a red build blocks nothing today anyway.
What is true: a mutation shows it WOULD fire, and it WOULD block once C-81 lands. Writing
the counterfactual as history, in a change whose subject is prose outrunning code, is the
thing itself.
THE STOPPING RULE READ BACKWARDS. It said a proposed widening must show its failure is
"not already prevented by assert_env_declared at run time". Applied literally that
ADMITS the arrival half — an unadopted upstream coordinate is not prevented by it — and
REJECTS the removal detection this check performs, because a removed coordinate IS caught
at run time when the launcher cannot supply the name. The rule now asks the question that
actually discriminates: state the delivery failure prevented, AND the false-alarm surface
measured against the live registry; if that surface includes rows this package does not
read, it is refused.
"8 BELONG TO NO REPOSITORY HERE" IS SIX. The other two are this package's own delivery
labels — both rows declare `producer = "views-postprocessing"` — and they are covered by
tests/test_product.py, not by this check. C-90's pre-existing text had this right; I
upgraded a careful claim into a false one and propagated it to four places.
AND THE DELETION'S REAL COST WAS RECORDED NOWHERE. A coordinate views-appwrite issues FOR
this package, or a second `[contract.*]` row for a future partner, is now silent until a
human reads the registry — no test, no runtime assert. C-90 had posed exactly this
question ("they cannot both stand") and my mitigation answered only the half that
flattered the change. Now stated in the docstring and decided in C-90.
THE SILENCE DIRECTION NOW HAS A CHECK. The proofs either side of this one are positive —
rotation fires, a rename fires — so a third widening would have met no objection and the
rule forbidding it would have been prose with a guard on the other half only. Mutation-
proven by re-adding an arrival half and watching it fail.
C-86: two of three, not one. "Every top-level table must be classified" still fires
regardless of obligation, and HAS — `[edition]` at v1.6.0, an edition the registry itself
calls "additive and opt-in; obliges nobody", reddened this repo. Recorded as the entry's
remaining rate risk with the `obliges_consumers` deferral as its fix.
ADR-014 §5: ADR-016 §1 and §7b both asserted the deleted behaviour as current, and §7b is
the section C-86 cross-references. Both corrected with an erratum naming the cost.
C-90's Trigger, Location, title and present-tense body all repointed at the two defects
that remain.
Suite 412 passed / 1 skipped / 40 xfailed, ruff clean. The one failure is #248's.
Epic #241.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…he check it named /review-diff on the remediation, and it found the remediation's own defect. Same class, one level up, in the change that was fixing it. THE SILENCE GUARD DID NOT GUARD THE CHECK. Its docstring said "the stopping rule above, as a check rather than a paragraph" and claimed a third widening "would have met no objection" — implying it now would. It would not. The test called `_describe_changes` directly, the helper UNDERNEATH the check, and the deleted arrival half never lived in that helper. Proven: re-adding `arrived` to the real check, exactly as it was before #245, left the whole suite green at 41 passed. AND THE MUTATION PROOF I OFFERED FOR IT WAS INVALID. I mutated the TEST — adding arrival logic inside the test body — and watched it fail. That proves the assertion works on input I hand it. It proves nothing about the code the test is supposed to be watching. A proof has to mutate the subject, not the instrument. It now drives the real check through monkeypatched registry readers, the pattern #242 arrived at for the same reason. Re-proven properly: re-widening the real check fails it, naming the offending row. Also fixed while in there: `mine = next(iter(names))` picked an arbitrary set element, so the fixture varied per process. `sorted(...)[0]` instead — declared, not incidental. And one near-miss worth recording: my first attempt to drop an unused local used a `sed` pattern that matched three OTHER tests and silently deleted their `module = ...` binding. Ruff caught it as seven F821s, restored from a `cp` backup. The lesson is the standing one — anchor edits on unique text, not on a pattern that happens to be unique in the region you are looking at. Register: C-89's sibling lesson recorded on C-86's mitigation — a guard must be pointed at the thing it claims to guard, which is the sentence this arc keeps re-learning. Suite 412 passed / 1 skipped / 40 xfailed, ruff clean. The one failure is #248's. Epic #241. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Iteration 2's review, and it found the sharpest thing on this branch. THE DRIFT CHECK'S ENTIRE ASSERTION COULD BE DELETED WITH A GREEN SUITE. Measured: neuter `assert not changed` and the suite stays at 412 passed. My silence guard was the only test driving the real check, and it is purely negative — it asserts the check does NOT raise. Nothing asserted it does. AND MY DOCSTRING VOUCHED FOR THE NEIGHBOURS. It said "the proofs either side of this one are positive — rotation fires, a rename fires". Neither is about this check. The rotation proof calls `_describe_changes`, the helper underneath it — which is precisely the defect I diagnosed and fixed for the silence guard one commit earlier. The rename proof calls `_declared_classes` and re-types the CLASS check's comparison inline; it belongs to a different check entirely, under this one's name. So I applied "a guard must be pointed at the thing it claims to guard" to one of the three tests in the cluster, then used that fix as a docstring warrant for the other two. C-90's rewritten Trigger says "Both remaining halves are proof defects" and enumerates two; this was a third of the same class, in the same file, which made the word "Both" falsifiable by a one-line mutation. Fixed by using the harness I had already built for only the direction that cannot fail: `test_the_drift_check_fires_when_a_row_this_partner_reads_rotates` drives the same real check with a rotated row and `pytest.raises`. Both directions now mutation-proven THROUGH THE CHECK: neuter the assertion -> the twin fails; re-add the arrival half -> the silence guard fails. The vouching for the neighbours is deleted rather than repaired; they are still worth having, they are simply not about this. TWO REGISTER CORRECTIONS, one of which is the same mistake inside its own correction. "6 belong to OTHER REPOSITORIES ENTIRELY" — no. Three are caller keys for other consumers; three are platform slots still marked status="planned" that belong to no repository at all, and one of those names "un_fao delivery" among the identities it would be issued for. C-90's original "belong to no repository here" was the careful wording. I had upgraded it, corrected the upgrade, and upgraded it again two sentences from the correction. And a quotation that was never written: the text pointed "further down this entry" for the partition "earning its keep". That phrase appears nowhere in the repository. The real record is 81 lines ABOVE, and says something narrower. Now quoted verbatim, direction fixed. Also: the silence fixture filed a `secret`-class name under `[target]` — harmless, since both sides carry the identical row, but its two neighbours each assert fixture honesty and this one did not. It now picks a genuinely `target`-class name and asserts it. Suite 414 passed / 1 skipped / 40 xfailed, ruff clean. The one failure is #248's. Epic #241. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…d a tautology
Two findings, both mine, both classes I had just finished correcting elsewhere in the
same commit.
THE FIXTURE-HONESTY ASSERTION COULD NOT FAIL. I wrote:
mine = sorted(n for n, cls in expected_class.items() if cls == "target")[0]
assert expected_class[mine] == "target", ...
`mine` is SELECTED by the condition it is then asserted to satisfy. True by construction,
for every possible input. That is C-90's own first defect — `base = {name: {} for name in
_TABLE_ROLE}` then `assert not _unclassified_tables(base)` — reproduced by me in the
commit whose whole subject was "nothing proves this check fires".
Replaced with the thing that can actually go wrong: assert the selection found anything.
If a partner stops declaring a `target` coordinate the fixture has nothing to file and
would prove nothing, and now it says so. Proven by pointing the selection at a class that
does not exist and watching it fail.
AND "THE ROTATION PROOF BELOW" IS ABOVE. It is at :929; the twin is at :1022 — 93 lines
below it, not above. Same directional error as the "recorded further down this entry"
pointer I fixed in the same commit, which pointed 81 lines the wrong way. Two in one
change is a pattern rather than a slip: I describe a file's layout from memory instead of
reading it.
Suite 414 passed / 1 skipped / 40 xfailed, ruff clean. The one failure is #248's.
Epic #241.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Aug 12, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #245. Gate 1 of epic #241.
The deletion
The drift check had two halves.
changedis filtered to the names each partner declares.arrivedwas not — it ran over every row of every depended-on table.Measured on the live registry: each partner reads 13 of 25 rows, and 6 belong to no repository here. So views-appwrite issuing one key for someone else turned both partners red and blocked a merge to
main— C-86's own failure class, arriving through the guard written to reduce it.Its self-defence was false: it claimed
[contract.*]"arrived exactly this way and nothing else here would have seen it".[contract]is a top-level table, andtest_every_table_in_the_registry_is_classified_here— in the same file — catches exactly that.Both directions now proven through the real check
Two new guards drive the real check through monkeypatched readers, not the helpers underneath it. Mutation-proven both ways: neuter the assertion → the positive twin fails; re-add the arrival half → the silence guard fails.
What three review rounds found in my own work
protect_mainhas no required status check. It was a mutation result in the past tense.assert_env_declared" — which admits the arrival half and rejects the removal detection I kept. It now asks for the false-alarm surface measured against the live registry.The cost, recorded rather than implied
A coordinate views-appwrite issues for this package is now silent until a human reads the registry. So is a second
[contract.*]row for a future partner. C-90 had posed exactly this question — "they cannot both stand" — and it is now decided there rather than left in prose.Records
C-86 corrected (two of three, not one — the partition still fires regardless of obligation, and already did on
[edition]). C-90 title, Trigger, Location and body repointed. ADR-016 §1 and §7b both asserted the deleted behaviour as current; both carry errata.The one failure is #248's.
🤖 Generated with Claude Code