#196 — repin views-appwrite to main's tip; the first pin was an unmerged branch

[Polichinel]

Closes #196. Corrects S3 (#184/#195), merged three hours earlier.

What went wrong, and it was mine

S3 pinned the Appwrite Seam Contract with:

git -C ../views-appwrite rev-parse --short HEAD

That checkout was sitting on the unmerged feat/s1-single-writer-rule branch. So the pin captured a commit that never reached main and has since been withdrawn unmerged (views-appwrite #30, #27). It declared registry v1.4.0; main carries the ratified v1.3.0.

HEAD of a sibling working copy is not the tip of its main. It is whatever someone happened to have checked out — which, in a repo being actively worked on, is more likely than not to be a feature branch.

Verified, not taken on trust

The issue arrived labelled URGENT and asked for a specific substitution. Every claim was checked against the views-appwrite repo before acting:

claim	result
the pinned commit is not on main	git branch -a --contains → only feat/s1-single-writer-rule; merge-base --is-ancestor origin/main → false
47172af is main's tip	git rev-parse --short origin/main → 47172af
it carries v1.3.0	version = "1.3.0" # RATIFIED — þing-02
the withdrawn one carried v1.4.0	version = "1.4.0" # AMENDED, NOT re-ratified
both cited files exist there	appwrite_seam_contract.md and coordinate_registry.toml both present

What changed

Four pin references — appwrite_env.py's docstring and ADR-013 §7d's two links — plus three prose blocks that asserted a 1.3.0 → 1.4.0 move that never landed: the §7d version label, the §7d correction paragraph, and Erratum E2.

v1.4.0 mentions elsewhere in the repo are views-datafactory's version, unrelated, and untouched.

The withdrawn sha appears nowhere

Including in the prose describing its withdrawal. #196's acceptance criterion is grep -rn b54928f . returning nothing, and a sha left in narration would still show up there and read as live. The story survives without it:

"its sha is deliberately not repeated here, so that grepping for it finds nothing."

The lesson, recorded in both places a contributor will look

Resolve a cross-repo pin from the tip of the other repo's main, never from its working copy's HEAD. A pin is a claim about what the contract says; HEAD answers a different question.

Worth adding to S6 (#187)'s scope: 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 in the same hour rather than requiring another seat to notice.

Noted from #196, not acted on here

The withdrawn clause defined its objection window as ending "on the first consumer pinning v1.4.0" — so this repo pinning promptly and correctly ended a review period before any seat could use it. That is a defect in the withdrawn clause and belongs upstream; recording it here only so the causal chain is legible.

Verification

grep -rn "b54928f" . --include=*.md --include=*.py         # 0
grep -rno "views-appwrite/blob/[0-9a-f]*" … | sort -u      # 47172af only
git -C ../views-appwrite merge-base --is-ancestor 47172af origin/main   # yes
ruff check .                                               # clean
pytest -q                                                  # 313 passed, 44 xfailed, 5 known pyarrow (C-72)

🤖 Generated with Claude Code