fix: the kit knows its own address, declared once and confronted with every copy #5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/the-kit-knows-its-own-address"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fourteen files named an owner this kit has never been published under. Every
module source, every clone command in the four adoption guides, the handoff, the consumer template, the module's own README and the getting-started block all saidcode.dataseeds.io/dataseeds/infra-conventions. The repository is atshared/.Nothing failed, and that is the point. The examples resolve the module through a relative path, so
make checknever fetched one of those URLs. The first person to find out would have been a consumer following a recipe — on the day they had least time for it.The README even said so, in a block calling the address an ASSUMPTION and asking the reader to adjust it. Writing an assumption down is not a control. It is a note that ages into a falsehood while every file copying it goes on looking authoritative.
The fix
Declared once, in
registry/conventions.yaml:make addressconfronts every copy with that declaration, in either direction — a stale copy and a stale declaration alike. A URL somebody types cannot interpolate a variable, so the only way fourteen copies stay true through a move is a test that fails when they disagree.kit.tagis the half that will actually bite. It is the tag a consumer pins, not the version of the working tree. It moves when a release is cut, and 24ref=,--branchand.naming-cache/occurrences have to move with it — exactly the edit a release forgets.decisions/andCHANGELOG.mdare exempt on purpose: they record what was true on a date, and rewriting them to match today's tag would make the account false.Two more things measured while here
200@nicoinCODEOWNERS200A CODEOWNERS entry naming an account that does not exist makes nobody a reviewer, and nothing reports it. The file looks like a control and is one only if the name resolves. It now names
@administrator— change it if you intend to create anicoaccount instead.Mutation-tested, seven ways
Verification
make checkgreen: 66 module tests, 48 policy tests, 11 reference plans,english: 0 findings,address: 16 addresses and 24 pins confronted, 0 findings.What this does NOT fix — your call
The tag
v2.1.0still carries the wrong address, because a tag is immutable and that is the point of one. A consumer who pins it gets the French kit and the old URL. Only a new release repairs that.Cutting one is a call I have not made. For what it is worth: the translation changes no name and no behaviour, and
make english/make address/decisions/are additions — so v2.2.0 would be defensible if you want the fix reachable before v3.0.0 lands.🤖 Generated with Claude Code
FOURTEEN FILES NAMED AN OWNER THIS KIT HAS NEVER BEEN PUBLISHED UNDER. Every `module source`, every clone command in the four adoption guides, the handoff, the consumer template, the module's own README and the getting-started block: all of them said `code.dataseeds.io/dataseeds/infra-conventions`, and the repository is at `shared/`. NOTHING FAILED, AND THAT IS THE POINT. The examples resolve the module through a RELATIVE path, so `make check` never fetched one of those URLs. The first person to find out would have been a consumer following a recipe - on the day they had least time for it. The README even said so, in a block calling the address an ASSUMPTION and asking the reader to adjust it. Writing an assumption down is not a control. It is a note that ages into a falsehood while every file copying it goes on looking authoritative. SO IT IS DECLARED ONCE, in registry/conventions.yaml under `kit`, and `make address` confronts every copy with the declaration - in EITHER direction, a stale copy and a stale declaration alike. The reasoning is the one that applies to any recipe meant for a human: a URL somebody types cannot interpolate a variable, so the only way fourteen copies stay true through a move is a test that fails when they disagree. `kit.tag` IS THE SECOND HALF, and the one that will actually bite. It is the tag a CONSUMER pins, not the version of the working tree. It moves when a release is cut, and 24 `ref=`, `--branch` and `.naming-cache/` occurrences have to move with it - exactly the edit a release forgets. decisions/ and CHANGELOG.md are exempt on purpose: they record what was true on a date, and rewriting them to match today's tag would make the account false. TWO MORE THINGS MEASURED WHILE HERE, neither of them assumed: - The repository is PUBLIC. An unauthenticated read answers 200, so a consumer needs no token to clone it. The README said the opposite might hold; it now says what is true, and what would change if it were made private. - `@nico` IN CODEOWNERS DOES NOT EXIST ON THE FORGE. That account returns 404 while two others on the same forge return 200, so this is a measurement and not a failed search. A CODEOWNERS entry naming an account that does not exist makes nobody a reviewer and nothing reports it: the file looks like a control and is one only if the name resolves. It now names `@administrator`. MUTATION-TESTED, seven ways: A1 one URL given a wrong owner -> caught, file and line named A2 one stale ref= pin -> caught A3 the DECLARATION moved, copies stale -> caught, the other direction A4 the declared address moved -> caught A5 the declaration removed entirely -> refused A6 a tag named inside decisions/ -> left alone, as intended A7 run where git lists almost nothing -> refuses to pass WHAT THIS DOES NOT FIX. The tag v2.1.0 still carries the wrong address, because a tag is immutable and that is the point of one. A consumer who pins it gets the French kit and the old URL. Only a new release repairs that, and cutting one is a call this change does not make. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>