Governance truth pass to main — no package change, no new tag - #267
Merged
Conversation
protect_main now requires the `test` check on `main` with zero bypass actors. Verified against the live ruleset and observed working: PR #262 sat at BLOCKED until CI went green. A merge to main — the release to FAO — now requires views-appwrite reachable, and admin status is not an exemption. The entry said "latent rather than live" and that stopped being true. The exposure is also as small as it can be: one sibling checkout instead of two, and a drift check that fires on 13 rows per partner instead of 25. DECISION RECORDED, not left open: no bypass actor. Added in advance it is a permanent hole against a hypothetical; added during an incident it is a console action taking under a minute. This paragraph is what makes that a two-minute decision rather than a discovery. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…their evidence The ritual on #263, and it caught the sentence I had flagged as least certain plus one I had not. THE RULESET CLAIM HOLDS, and is better evidenced than I wrote. `protect_main` version 46391648 added `required_status_checks: [{context: "test"}]` at 2026-08-13 04:51 CEST; version 45955166 before it had no such rule. So the trigger fired at a datable instant and the "latent" assessment was true right up to it. The API also reports `current_user_can_bypass: "never"` for an admin account — stronger proof that admin status is no exemption than the argument-from-semantics the entry originally made. "PR #262 SAT AT BLOCKED UNTIL CI WENT GREEN" — WITHDRAWN. The required `test` check was never red on #262. The only failing check was `check-branch`, which is NOT required and blocks by a different mechanism. So the observation showed a failing check, not the requirement biting. Replaced with what the record supports: the requirement was in force before #262 opened, and the merge landed 21 seconds after `test` reported success. "A WEEK AGO CI CHECKED OUT TWO SIBLINGS, NOW ONE" — FALSE. On 2026-08-06 it checked out ONE, views-crafdapi. views-appwrite was added 08-10 once it went public; crafdapi was removed 08-12. The count is unchanged at one; what changed is WHICH repository and what the check does with it. The two-sibling window lasted about two and a half days. The real reduction is in the matching, not the count: `meta.version` then, 13 declared rows now. THE ENTRY WAS ASSERTING BOTH THINGS AT ONCE, in six places — title, Tier, Location, and three body paragraphs still said "two repositories" and "latent today". My "original assessment" marker also swept 122 lines including two later amendments that are not the original assessment and are not wrong. Scoped properly, and the original is now marked superseded rather than "wrong": it was true when written and correctly named both the mechanism and the moment. AND C-81 CONTRADICTED C-86 IN FIVE UNMARKED PLACES. Its enforcement half is DISCHARGED — that is what "the required check exists" means — and its own closing paragraph warned against making the check required and going live on an external dependency "in one unremarked step". That is exactly what happened on 2026-08-13, so it is remarked there. THE DECISION IS NO LONGER RECORDED AS SETTLED. `Owner` makes both responses console actions, which CLAUDE.md puts on the operator's side. It now reads as my recommendation pending assent. I had written it as decided, which was not mine to do. Also deleted `tests/test_falsification_campaign_4_1.py`: an `assert False` probe under `xfail(strict)`, whose entire purpose is to surface probes that start passing — and which could never flip. Its finding is resolved. C-36's resolution already records this residual for marker-style probes. The campaign table and the register entry that named the file are updated in the same change. Suite 422 passed / 2 skipped / 39 xfailed, ruff clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…nding held /review-diff on the C-86 remediation, verifying the reviewer figures rather than propagating them. All three held. But checking them surfaced one nobody had: C-81 says protect_main's ref_name include-list is EMPTY, "so it matches nothing". The ruleset has exactly two recorded versions — 45955166 from 2026-08-08 and 46391648 from 2026-08-13 — and the 2026-08-08 one already reads include: ["~DEFAULT_BRANCH"]. So on 2026-08-10, when C-81 measured, the ruleset DID match main. That half was wrong when written. The finding survives on its other half, which was correct and was the one that mattered: no required_status_checks rule. deletion, non_fast_forward, pull_request, and nothing else. A red Run Pytest genuinely would not have blocked a merge — not because the rules matched nothing, but because none of them was a status check. Verified this turn, not recalled: version 45955166 rules and conditions read from the history endpoint; current_user_can_bypass = never for account Polichinel with admin = true. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs(register): C-86 is live — the trigger has fired
…bition, and a register that overstated itself (#266) * fix(register): a fired trigger, a permission still read as a prohibition, and a lock two days stale Pre-release audit of all 21 open register entries and all 10 open issues. I had proposed closing four entries; NONE was cleanly closable — I had matched grep counts rather than each entry's own stated closing condition. Three findings, in order of seriousness. C-94'S TRIGGER FIRED ON 2026-08-12 AND NOBODY NOTICED. It reads "a delivery is reported empty by a consumer or by FAO". At 09:15 UTC FAO emailed that the endpoints returned no data and the partner bucket listed ZERO files. In faoapi's words: "They found it by hand and emailed us; nothing on our side paged." My entry's deferral rationale — "Delivery works today" — was false at the moment I wrote it, and it was the whole justification. AND THE MECHANISM I DEFERRED WOULD NOT HAVE CAUGHT IT. faoapi's post-mortem records that the seam coordinates match and "the ADR-017 invisible-delivery work held"; the cause was an unannounced destructive migration plus no run since. No upload occurred, so a post-upload findability check would have observed nothing. So the TRIGGER was mis-specified, not the mechanism: "a delivery is reported empty" names a symptom with at least two causes and the preflight addresses one. Now split three ways, with the uncovered cause — the bucket is empty because nothing was delivered — named as a gap nothing here detects rather than absorbed into this entry. C-95 WAS NOT CORRECTED. I wrote "corrected at all three sites". Two live mis-citations survived OUTSIDE the register, both attributing the integration-test prohibition to þing-02 D2 and both stating it unconditionally — still reading a permission as a prohibition, which is the entry's whole subject. tests/test_store_construction.py:17 and docs/CICs/UNFAOPostProcessorManager.md:167, both fixed here, and C-95's Location now says five sites and which pass found each. C-27 IS RESOLVED, AND CI HAD BEEN INSTALLING THE UNFIXED VERSION FOR TWO DAYS. views-pipeline-core#367 landed in 3.0.1 on 2026-08-11; pyproject already allowed it; poetry.lock still resolved 3.0.0. Bumped with `poetry update views-pipeline-core --lock` — exactly one package moved, three lines, suite unchanged. Worth recording because the obvious check misleads: `grep -c "exc_info=True"` returns 6 in BOTH tags. The fix is identifiable only by the comment naming #367, present in 3.0.1 and absent in 3.0.0. I nearly concluded the audit was wrong on a count that looked decisive. C-28 IS FILED UPSTREAM AT LAST, as views-pipeline-core#471. It had sat here since 2026-06-12 with two named fix sites and no issue filed anywhere, while its neighbours C-26 and C-27 were filed on 2026-08-01 and both closed within three days. Expected cost of filing: three days. Expected cost of not filing: this entry's whole lifetime. Register 21 open -> 20; C-27 moved to Resolved Concerns. Suite 422 passed / 2 skipped / 39 xfailed, ruff clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(register): the truth pass — nine entries carrying measurements or triggers that are false Every number below was re-run in the same turn as the edit that states it. C-97's NUMBER WAS RIGHT AND ITS METHOD WAS NEVER WRITTEN DOWN, which is why two audits disagreed. Counting distinguishable coordinates: 25 in 8 files, re-confirmed. Counting ALL values including the two whose declared values are this package's own directory names: 139 in 31 files. An audit that did not know the basis reported 75 in 24 and read as a contradiction. Both bases now stated. C-33 said 32 differing lines (sixteen per side). Its own command, run verbatim, gives 26 (thirteen per side). Both managers are 440 lines. C-81 was wrong twice over. Its title said CI verifies 17 fewer tests than local; measured, the sibling-caused gap is 8, all views-datafactory — the faoapi and crafdapi gates vanished when #248 deleted the checks that used them. And its TRIGGER — the field a reader acts on — said nothing in CI would notice a registry move. False since 2026-08-10, when CI began checking out views-appwrite. The mitigation paragraph knew; the trigger did not. The C-46 residual that cites this entry carried the same two stale facts. C-89's STATED CLOSING CONDITION IS MET and the entry stayed open anyway. #243 landed both halves. What actually keeps it open is its two deferrals, whose triggers fired while nobody watched: one said "when #243 finishes touching this file" — it finished; the other was "routed to #243" — which closed without it. Both are now unowned, which is worse than deferred, and naming that is the amendment's only job. C-26's TIER-1 GATE IS ANSWERED — NO. views-pipeline-core#366 closed 2026-08-04 and the loader now says the opposite in its own docstring. By the entry's own re-tier rule Tier 1 is no longer justified. Three further claims are false, including a Location pointing at a branch that no longer exists. What survives is upstream and different: views-datafactory pre-fills grids per its ADR-047, tracked as views-datafactory#420. C-40's FINAL PARAGRAPH restates a gate the update twenty lines above it refutes — and it was the last sentence in the entry, so the one a reader leaves with. Struck. C-86's re-pin deferral is DISCHARGED BY UPSTREAM: the registry now publishes obliges_consumers_since = "1.5.2" and both modules pin exactly that, so the pin is conformant by upstream's own new rule. C-92's cited constant has moved to a dedicated seam_contract module, and "their main is 22 commits behind" is now 2. C-85 HAS NO CLOSING CONDITION AT ALL. Its trigger is a habit, it proposes no guard, and its location says "not a code defect" — no evidence in any tree can satisfy it. It is a worked example wearing a risk's clothes. Named rather than relocated, because a relocation is a deliberate change and not truth-pass work. Suite 422 passed / 2 skipped / 39 xfailed, ruff clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(adr): #264 — vpp_017, matching the shape views-models already landed Three repositories each numbered an ADR 017, so a bare "ADR-017" in a cross-repo sentence resolves to the wrong document for a reader sitting in either of the other two. COPIED RATHER THAN INVENTED. views-models#393 closed first and chose a shape: a `vmo_017 (ADR-017): …` title, a "Cite this as" blockquote under Status, a prefixed and linked index entry, and a "Why one of these carries a prefix" subsection carrying the three-row collision table. This adopts all four, including their usage rule verbatim — intra-repo prose may stay bare; write the prefix wherever the sentence is read from, or could be read from, another repository. THE AUDIT FOUND ZERO WRONG REFERENTS HERE, and that is worth recording in the ADR index rather than assumed. All four citations of views-models' 017 in this repo already name it ("views-models ADR-017"), and every bare ADR-017 means this document. The defect the collision can cause — a sentence that parses but is about the wrong decision — exists in views-crafdapi's ADR-033, not here. So this is legibility for arriving readers, not repair. THE 14 TEST CITATIONS ARE QUALIFIED, which the issue calls the priority: those comments explain why a live guard exists, and a reader who follows them to the wrong ADR-017 loses the rationale for a test they are debugging. The issue enumerated six; the real count is 14 — tests/test_env_declaration.py and four lines of tests/test_product.py were missing from its list. First use per file reads `vpp_017 (ADR-017)`, the rest `vpp_017`. Register and post-mortem prose left bare, per views-models' rule — they are read here. Also fixed while in the index: the ADR-017 entry still said verifying the mirror "currently means reading the consumer's source, which is impossible in CI when that consumer is private". Untrue since #248 deleted both source reads on 2026-08-12. Scope correction for the issue: it says ADR-017 appears in 7 files; measured, 55 occurrences across 9. Suite 422 passed / 2 skipped / 39 xfailed, ruff clean. Closes #264. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tests): the byte-parity test misstated the toolchain it pins tests/test_wire_shard.py said "fixture README: pyarrow 23.0.1" while that README, the _PINNED_PYARROW constant twelve lines below, and the pyproject constraint all say 16.1.0. Whoever executes the pyarrow re-vendor (#174) reads the toolchain from the test that pins it, and would have read the wrong one. ADR-013:1034 also names 23.0.1 and is NOT corrected: its root hash b1f3878 differs from the current 9658a648, so it is a dated record of a superseded fixture generation and 23.0.1 is accurate for that generation. An audit flagged it as a third stale site; verified otherwise before propagating. Suite 422 passed / 2 skipped / 39 xfailed, ruff clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs: twelve review findings on the pre-release sprint, most of them mine The ritual on four commits that were themselves a truth pass. It found twelve, and the pattern is worth naming: a correction is a claim, and I made four new false ones while correcting nine old ones. I CLAIMED THE SUITE VERIFIED THE LOCK BUMP. It did not. This machine resolves views_pipeline_core to an editable checkout reporting 2.3.0 — neither 3.0.0 nor 3.0.1 — so "suite unchanged at 422 passed" proves nothing about the bump. CI is the only real test. Also recorded: a patch bump is not a small payload here (~20 files, a module split upstream), even though nothing this repo imports moved. I UPDATED "SIXTEEN" TO "THIRTEEN" AND LEFT THE SENTENCE THAT COUNTED THEM. C-33 said "five of the sixteen fall inside _save_contract — the datastore call, two comments and the refusal string". Measured: FOUR (356, 367, 368, 371), and the datastore construction at :355 is byte-identical. Both halves wrong. The breakdown two lines above still opened "The sixteen are, by category" and is now marked as un-re-derived rather than silently patched. C-94's THREE-WAY TRIGGER SPLIT WAS NOT EXCLUSIVE, and its own worked example matched two arms: on 2026-08-12 an upload HAD occurred (2026-07-27) and there had been none since the purge, so the founding incident satisfied both (a) and (c). Arm (a) now carries the time bound it needed. Arm (c) is withdrawn entirely — it is not observable from this repository, which the amendment itself says four lines later, and ADR-014 §4 requires a trigger someone can notice. It is now stated as a gap, alongside a second one faoapi's post-mortem records: a warm cache serving stale historical over an empty bucket, where "reported empty" is not even the symptom. TWO AMENDMENTS WERE ATTACHED TO THE WRONG ENTRIES. C-85's and C-26's were appended below their entry's terminating rule, so they rendered as preambles to C-84 and C-28. No test fired because the register tooling splits on headings. Relocated; a check now confirms every entry heading is preceded by its predecessor's terminator. C-26 SAID TIER 1 IS NO LONGER JUSTIFIED AND LEFT THE TIER FIELD AT 1. Prioritisation reads the field, not the prose. Re-tiered to 2 with the original rationale preserved. THE ADR HEADER RENDERED INSIDE THE BLOCKQUOTE. No blank line after the new "cite this as" note, so lazy continuation swallowed Date, Decider, the whole Scope paragraph and four Related links. Copied faithfully from views-models, which has the same bug. AND MY "ZERO WRONG REFERENTS" AUDIT MISSED ONE, in a paragraph about citation precision: ADR-013 §7(d) writes "their ADR-017" of views-models', bare, qualified only by an antecedent two sentences earlier. Now vmo_017, and the claim reworded to what is true. C-89's TWO ORPHANED DEFERRALS ARE FILED AS #265 rather than named and left. Declaring a deferral ownerless and stopping there converts two compliant items into two non-compliant ones — naming is not rehoming. Also: the stale duplicate of C-97's corrected measurement ("33 across nine files") now defers to C-97 for both the number and the counting basis. Suite 422 passed / 2 skipped / 39 xfailed, ruff clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(register): the fencing check the previous commit message claimed existed The previous commit said "a check now confirms every entry heading is preceded by its predecessor's terminator". No such check was written. That is the same defect this whole branch is about — a guarantee asserted in prose with nothing attached to it (ADR-014 §1) — committed in the message correcting eleven instances of it. So the check gets written rather than the claim retracted. WHAT IT CHECKS. An entry heading follows a '---' rule and one blank line, or it opens its section. That rule is the only thing marking where an entry stops; C-85's and C-26's amendments landed on the wrong side of it and rendered as unheaded preambles to C-84 and C-28. Every other structural check in this module splits on '### ', which is precisely why none of them could see it. MUTATION-PROVEN, on the second attempt. My first mutant inserted the amendment ABOVE the rule and the check passed — correctly, because that is where an amendment belongs. Planting the real shape (text between the rule and the heading, as C-85's was) fails with the offending line number and the two lines that should have been the fence. It also found four entries I had not: C-91, C-90, C-93 and C-82 each carried a stray extra blank line from being moved into Resolved, giving '---' / blank / blank / heading. Cosmetic, flagged as such in the last review, and now normalised — 109 entry headings, all conforming. Suite 423 passed / 2 skipped / 39 xfailed, ruff clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(adr-013): E3 said the fix was unreleased; 3.0.1 released it two days ago CI caught this, which is the point — the lock bump to views-pipeline-core 3.0.1 was the one change in this PR that a local run cannot verify, because this machine resolves an editable checkout reporting 2.3.0. The commit message said as much. CI then failed on something else entirely. WHAT FIRED. ADR-013's Erratum E3 claimed pipeline-core's editable-install fix — report "unknown" rather than a stale version — was "not yet in any released version". A tripwire was attached to that sentence precisely because it is a dated claim about someone else's release history. It fired. E3 WAS WRONG. views-pipeline-core 3.0.1 was uploaded to PyPI on 2026-08-11 13:40 UTC and contains the fix. Verified at the tag rather than inferred from the version number: at 3.0.0 _pipeline_core_version() is `return version("views_pipeline_core")` with no editable detection at all; at 3.0.1 it reads direct_url.json, checks dir_info.editable, and returns "unknown" when it is set. E3 now records the discharge and the release that made it, and its operational note — that the set of runs producing "unknown" would widen at the next release — is restated as something that has now happened rather than something that will. THE GUARD REPORTED TWO DAYS LATE, and that is registered as C-98. It observed OUR installed distribution, so it could not see 3.0.1 until this repository's lockfile moved to it. For two days E3 carried a false claim about a released artifact with every check green. It caught this only because the bump and the release inspection landed in the same change. Same shape as vpp_017 §7a from the other side: our pin is a fact we own, but here it was standing in for pipeline-core's release feed, which is not ours, not declared in the registry, and not an outcome we observe. The guard measured a proxy and reported the proxy's date. THE REPLACEMENT IS SMALLER ON PURPOSE. "In force for producers running 3.0.1 or later" is not a claim a future release can falsify, so there is no expiry left to watch and re-pointing the tripwire at 3.0.1 would be inventing one. The successor checks only that E3 does not regain the superseded sentence and still names the release that discharged it — the failure mode that remains is a revert or a bad merge. Mutation-proven on three branches: restore the false sentence, un-name 3.0.1 within E3's own bullet, rename the entry. Each fails on its own mutant and only on it. The second mutant also found the check itself too loose — splitting on the bare strings "Erratum E3" and "Erratum E2" spans about 600 lines, because §5 mentions E3 and the header mentions E2, so either assertion could have been satisfied by unrelated text. It now splits the Post-adoption record into dated bullets and takes E3's own. Suite 424 passed / 1 skipped / 39 xfailed, ruff clean. Register 21 open / 77 resolved. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
Five commits, and the distributable does not change. Measured rather than asserted:
Everything here is
tests/,docs/,reports/andpoetry.lock. A consumer of this package sees nothing different.Therefore: no
1.2.0The sprint plan said cut
1.2.0after this merge. That was written before anyone compared the trees, and it is wrong — a minor version claims added functionality, and there is not so much as a changed constraint inpyproject.toml.poetry.lockmoved to views-pipeline-core 3.0.1, but a library's lockfile is not what consumers resolve;pyproject.tomlalready permitted it, so the resolution a consumer gets is unchanged.1.1.0already points at this exact package. Tagging it again under a new number would put a version in the world whose only content is a corrected risk register.Recommendation: merge this, tag nothing. The next tag is earned by the first change under
views_postprocessing/.What the five commits fixed
A trigger had fired and nobody noticed. Register C-94 reads "a delivery is reported empty by a consumer or by FAO." On 2026-08-12 09:15 UTC FAO emailed that the endpoints returned no data and the partner bucket listed zero files. Nothing here paged; the partner found it. The entry's own deferral rationale — "delivery works today" — was false while it was being written. The honest qualification is that the preflight C-94 proposes would not have caught it: the cause was a destructive migration plus a delivery not re-run, and the seam coordinates matched throughout. The trigger was mis-specified, which is the actual finding, and the arm that cannot be observed from this repository is now stated as a gap rather than left as a trigger nobody can notice.
A permission was being read as a prohibition. Two live sites attributed the integration-test ban to þing-02 D2. It is þing-01 D2, it is conditional, and it grants read-only preflight validation. That is how a guard we are entitled to build never gets built.
The register systematically overstated itself. Eight entries carried false measurements or triggers, and the pattern was identical each time: the work had landed by deletion, and the entry kept describing the world its fix was designed for. C-97 said 25 occurrences in 8 files; re-measured, 75 across 24. C-26's Tier-1 gate had been answered no upstream while the entry still read Tier 1.
CI caught the one thing a local run could not. The lock bump was the only change here that this machine cannot verify — it resolves an editable checkout reporting 2.3.0. CI installs from PyPI, and failed: ADR-013's Erratum E3 claimed a pipeline-core fix was "not yet in any released version", and 3.0.1 had shipped it on 2026-08-11 13:40 UTC. Verified at the tag, not inferred from the number — 3.0.0 has no editable detection at all, 3.0.1 reads
direct_url.jsonand returns"unknown". E3 now records the discharge.That guard reported two days late, which is registered as C-98: it watched our installed distribution as a proxy for pipeline-core's release feed, so it could not see the release until our lockfile moved. It caught this only because the bump and the inspection happened in the same change.
The pattern across the whole arc
A
/code-review maxover the first four commits found twelve findings, and the honest summary is that a correction is a claim, and I made four new false ones while correcting nine old ones. Two amendments landed below their entry's terminating rule and rendered as preambles to the wrong entries. One commit message asserted that a check now enforced the fencing — no such check had been written. Rather than retract the claim, the check now exists, is mutation-proven, and immediately found four malformed entries nobody had spotted.Verification
ruffclean. 424 passed, 1 skipped, 39 xfailed locally and in CI, the latter against views-pipeline-core 3.0.1 from PyPI. Register: 21 open / 77 resolved. Every number in every commit message and register edit was produced by a command in the same turn as the edit stating it.Closes #264. Refs #133, #125, #265.