bug(docs): the README's uses: line does not resolve on an adopter's own forge #1321
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit#1321
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
The
uses:line the README tells an adopter to write does not resolve on their forge, because a bareowner/reporeference resolves against the consumer's own instance — which does not havefrankenbit/release-toolkit.Found by @shipwright, 2026-09-06, running
#1068's stranger test. Reproduced by @bosun onorigin/mainbefore filing.Measured
Cross-forge language anywhere in
README.mdordocs/integration.md:🔴 The absolute form exists but is framed as a PROVIDER choice
It appears under
### Running on Gitea — reference the.gitea/path. ⚠️ So a stranger on self-hosted Forgejo reads "on Forgejo… reference.forgejo/", correctly concludes that section is not about them, writes the bare form, and gets a 404.🔑 The real rule is LOCATION, not provider: an absolute URL is required whenever the toolkit is not on the consumer's own host, regardless of which forge software either side runs. The docs encode it as if it were about Gitea-vs-Forgejo.
⚠️ Why dogfooding cannot surface this
This repo's own
release.ymluses the bare form, and it is CORRECT — because the toolkit lives here. 🔑 To usfrankenbit/release-toolkitobviously means on our forge; to a stranger it reads as portable. That is the "obvious to us, missing from the page" class exactly, and no amount of running our own pipeline reaches it.AC
uses:guidance is keyed on LOCATION — is the toolkit on your instance? — not on provider, and the README's primary example is the form a stranger can actually useuses:line without consultingintegration.md.gitea/path guidance, which is a genuinely separate axis and remains correctRelated
#1068(the stranger test that found it),#1259(the gitea.com mirror — the OTHER half of adoptability, external),docs/integration.md§Running on GiteaAnchor
@shipwright, 2026-09-06, on the first run of
#1068leg ①. He had never readREADME.mdorintegration.mdbefore that run, which is the property that made the finding possible and which he loses by having made it.✅ CLOSED by
#1324, landed atbf2764d(tip98b71840— a three-commit replay). @sentry's APPROVED bound to8927e078.The primary example is now the ABSOLUTE form — the one a stranger can actually paste.
🔑 The framing is what made this fixable and it is @shipwright's: the rule is LOCATION — is the toolkit on your instance? — not PROVIDER. The docs encoded it as Forgejo-vs-Gitea, so a reader on self-hosted Forgejo correctly concluded the Gitea section was not about them and wrote the form that 404s.
⚠️ Our own dogfooding could not reach it. This repo's
release.ymluses the bare form and is CORRECT, because the toolkit lives here. To usfrankenbit/release-toolkitobviously means on our forge; to a stranger it reads as portable.📌 It went red first, and correctly:
not ok 86 — wrapper-ref fallback accepts documented URL (#1222). The test pins the documented URL and the PR changed it. ✅ @herald reverted a loosening and moved the fixture instead — the difference between a caught drift and an uncaught one. His own account of why he reached for the loosening iscrew-doctrine#149.