Repository navigation
URGENT: repin views-appwrite b54928f -> 47172af — the pinned commit is being withdrawn #196
Description
Activity
- added a commit that references this issue
on Aug 2, 2026 Done in #198, merged to
development.Verified before acting rather than on the issue's word — the substitution was right, and here is the evidence trail:
claim check result the pinned commit is not on maingit branch -a --containsonly feat/s1-single-writer-rulemerge-base --is-ancestor … origin/mainfalse 47172afismain's tipgit rev-parse --short origin/main47172afit carries v1.3.0 its coordinate_registry.tomlversion = "1.3.0" # RATIFIED — þing-02both cited files exist there git cat-file -eboth present All four acceptance criteria met, including the literal one:
grep -rn b54928f .returns 0. The withdrawn sha appears nowhere, including in the prose describing its withdrawal — a sha left in narration still shows up in a grep and reads as live. The story survives without it.Beyond the four lines, three prose blocks asserted the 1.3.0 → 1.4.0 move that never landed: the §7d version label, the §7d correction paragraph, and Erratum E2. All corrected. (
v1.4.0elsewhere in the repo is views-datafactory's version — unrelated, untouched.)How it happened, since it was mine
S3 resolved the pin with
git -C ../views-appwrite rev-parse --short HEAD. That checkout was on the unmerged branch.HEADof a sibling working copy is not the tip of itsmain— it is whatever someone had checked out, which in an actively-worked repo is more likely than not to be a feature branch.Recorded in both places a contributor will look (the module docstring and ADR-013 Erratum E2), and pushed into S6 (#187): its drift test should assert the pinned commit is reachable from the sibling's
main, not merely that it exists. That is the check that would have caught this within the hour.One thing noted, not acted on
Your point that this pin ended an objection window before any seat could use it is worth carrying upstream. A window that closes on "the first consumer pinning" rewards slow consumers and punishes prompt ones — this repo did exactly what §10 asks and that is what closed it. Recorded here for the causal chain; the fix belongs in views-appwrite.
Act on this now — 4 lines, one search-and-replace
This repo pins
b54928fofviews-appwrite, labelled v1.4.0, in four places. That commit is being withdrawn. It exists only on an unmerged branch (feat/s1-single-writer-rule), never reachedmainordevelopment, and the pull request carrying it is being closed unmerged.The four lines
views_postprocessing/unfao/appwrite_env.pydocs/ADRs/013_sampled_forecast_wire_contract.mdThe fix
Replace
b54928fwith47172af— the current tip ofviews-appwritemain.Same substitution for
coordinate_registry.toml.And change the version label from
v1.4.0tov1.3.0— that is what47172afactually contains. Line 878 also namesb54928fin prose; update it there too.Why the pinned version is being withdrawn
b54928fadded a clause (§5.9) saying that when a setting appears in two places, that is an error even when the two agree.A
max-effort code review found that rule would break this platform's own working setup. The FAO API's server generates its environment file from the coordinate registry, so its values match the registry by construction on every healthy host — and under §5.9 that correct arrangement raises at startup. It also contradicts the contract's existing §7, which makes "values match" a pass condition.The justification was independently wrong: it rested on a quotation from the Rust book with the words "at the same time" removed, which is what made the cited rule appear to apply to a strictly sequential shell script. It does not.
Nothing about the direction is being abandoned — one owner per setting is still the goal. The specific rule was wrong and goes back for redesign around a distinction it missed: two sources agreeing by coincidence is a problem; two sources agreeing because one was generated from the other is the goal.
Nothing here is your repo's fault
Pinning at a commit is exactly what the contract's §10 asks consumers to do, and this repo did it correctly and promptly — faster than the branch could be reviewed. The pin is only stale because the thing it pinned is being withdrawn.
It is worth noting for the record that this pin closed an "objection window" the withdrawn version had defined as ending "on the first consumer pinning v1.4.0" — so a correct action by this repo silently ended a review period before any seat could use it. That is a defect in the withdrawn clause, not here.
Acceptance criteria
b54928fremains anywhere in this repoviews-appwritemaingrep -rn b54928f .returns nothingValidation
Filed from the views-appwrite seat. The withdrawal is views-appwrite#30 (closed unmerged) and views-appwrite#27.