Repository navigation
docs: the release status said the opposite of the registry, in ten files - #159
Conversation
Every load-bearing claim about publication was stale, and one was stale in a way that hid a live gap. What the docs said, and what `npm view` / `git ls-remote` / the release script actually answer: - "the tag and the publish are not done" -> v2.0.0 is tagged AND pushed - "nothing at 2.0.0 is on npm, latest is still 1.2.0" -> npm's latest IS 2.0.0 - "bunx create-ultimate installs 1.2.0" -> it installs 2.0.0 - "@ultimat3/flags has never reached npm at any version (#84)" -> flags IS on npm, and 2.0.0 is its ONLY version, so the bootstrap happened exactly at 2.0.0 - "29 workspaces publish; 28 are on the registry" -> 30 publishable, 29 on it The hidden gap: @ultimat3/scraping is 404. It landed after the 2.0.0 run, so it is now exactly the hole flags used to be — same publishConfig, in the derived publish list, never bootstrapped. It is 27th of 30, so the next release run reaches it and aborts with 26 packages already published irreversibly. Every document was still warning about flags while the registry had moved on. Two releases, invisible. Two more claims were false and are corrected here rather than repeated: PUBLISHING.md said all four human steps were done at 2.0.0. Steps 3 and 4 are not: `trust-publishers.ts --check` answers 0 of 30 packages trust the workflow. And that is WHY 2.0.0 has no provenance — with no trusted publisher attached the OIDC exchange has nothing to verify against, so the workflow cannot publish and 2.0.0 went out by hand: `_npmUser: sebyx07`, no dist.attestations, where 1.1.0 and 1.2.0 carry both. CLAUDE.md, README.md and llms.txt all implied otherwise. llms.txt is the machine-readable repo map and the first thing an agent reads; it carried all four stale claims in one sentence. One doc bug found on the way, unrelated to the release: wiki/Deployment.md said no role declares a metrics container port and the chart ships no scrape target. Both are false — values.yaml declares metricsPort, _helpers.tpl emits the containerPort, service.yaml publishes it and servicemonitor.yaml exists. It contradicted wiki/Known-Gaps.md, which was right. Filed rather than fixed: nothing compares the documented publish state to the registry (#155), which is exactly why this drifted; and @ultimat3/scraping ships 40 source files and 24 error codes with no wiki page (#156). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 21 minutes Limit details: You’ve used the included review currently available. Your 71 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (13)
Comment |
|
This doc-only PR corrects the release status across ten files — 2.0.0 is published, the never-published package is now 🤖 Posted by developerz.ai — the maintainer agent, not a human. |
…n it (#160) * release: 3.0.0 — and the first release with a trusted publisher to run it All 30 workspaces move to 3.0.0 in lockstep: one version, one commit, one tag. A major because a five-agent bug sweep landed breaking changes to documented APIs — ten entries marked BREAKING, each naming the manual edit it costs. mfa.required is refused at boot and narrowed to the literal false; enrolTotp takes the auth it reads its issuer from; appErrorStatus is gone; sweepIdle became idle(); lastSeenAt became lastSeenMonotonicMs because it now holds a monotonic reading; two SQL_OUTBOX_* constants each gained the claimant they must be fenced on; DESCRIPTION_MIN_LENGTH is deleted rather than left unenforced. Two release-infrastructure holes closed in the same commit, both of which the docs asserted were already closed: @ultimat3/scraping had never been published at any version. It landed after the 2.0.0 run, so no run had ever seen it, and it sat 27th of 30 in the derived publish order — the next release would have died there with 26 packages already on the registry irreversibly. Bootstrapped by hand at 2.0.0. And NO package had an OIDC trusted publisher attached. That is why 2.0.0 has no provenance: with nothing for the exchange to verify against, the workflow could not publish and 2.0.0 went out by hand (_npmUser: sebyx07, no attestations, where 1.1.0 and 1.2.0 carry both). All 30 are attached now, so 3.0.0 is the first release since 1.2.0 that can run through the workflow. The docs said the opposite of the registry in ten files and are corrected here and in #159 — including PUBLISHING.md, which contradicted itself in one file after a partial update, and told the reader to pass a --otp flag the script does not parse. Two traps are now written down where an operator will hit them: npm trust list itself needs an OTP, so a --check without one reports every package missing and a 0/30 means nothing; and one OTP cannot cover 30 packages, because npm rate-limits verification. Closes #84. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs: say the release can publish, not that it did Review round on #160. Four applied, one declined. The important one: CHANGELOG and PUBLISHING both wrote 3.0.0 as though the workflow had already run it. It has not — the tag and the publish follow this commit, and the npm-publish environment holds the job for a reviewer. Both now say the release CAN go through the workflow, and point at `npm view @ultimat3/core@3.0.0 dist.attestations` for whether it did. Writing a completed event before it completes is how this doc set drifted in the first place. The .npmrc guidance was also wrong in a way worth correcting rather than softening. It said NODE_AUTH_TOKEN cannot reach npm publish and implied writing a literal token into a file. What is true: npm reads the credential from an .npmrc, and the safe form points that file at the environment — `//registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}`, interpolated at read time — so the secret never lands on disk. Documenting a literal token was a credential leak waiting for a `git add`. And two "read it yourself" commands proved one package where the claim was about thirty: the registry row now says to walk the derived list, and the trusted-publisher row names the all-package check with its OTP requirement. Declined: making X_NOT_IMPLEMENTED's fix an "exact runnable shell command". It is a config-file edit — the row already names the exact key, file and value, and notes it is already the default. A fabricated shell command would be less true, and axiom 4 asks for an instruction that works, not one shaped like a command. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Every load-bearing claim about publication was stale, across ten files — and one was stale in a way that hid a live gap.
bun run verifygreen.What the docs said vs what the registry answers
Measured with
npm view,git ls-remote --tags origin, andbun run scripts/release-workflow.ts --json:v2.0.0is tagged and pushedlatestis 2.0.0bunx create-ultimate myappinstalls 1.2.0"@ultimat3/flagshas never reached npm at any version" (#84)2.0.0is its only version, so the one-time bootstrap happened exactly at 2.0.0The gap this was hiding
@ultimat3/scrapingis 404. It landed in #140, after the 2.0.0 publish, so it is now exactly the holeflagsused to be — tier 5, samepublishConfig, in the derived publish list, never bootstrapped.It is 27th of 30 in the derived publish order, so the next release run reaches it and aborts with 26 packages already published irreversibly. Every document was still warning about
flagswhile the registry had moved on. Two releases running, invisible.Two more claims that were false
PUBLISHING.mdsaid all four human steps were done at 2.0.0. Steps 3 and 4 are not —bun run scripts/trust-publishers.ts --checkanswers0/30 packages trust developerz-ai/ultimate/release.yml, every one reportingX_TRUST_PUBLISHER_MISSING.And that is why 2.0.0 has no provenance. With no trusted publisher attached, the OIDC exchange has nothing to verify against, so the workflow cannot publish — and 2.0.0 went out by hand instead:
dist.attestations_npmUsersebyx07CLAUDE.md,README.mdandllms.txtall said or implied that releases go over OIDC with provenance, without recording that the most recent one did not. Each now names the exception and points at the command that answers it, so the next reader checks the state rather than the sentence.Files
CLAUDE.md,PUBLISHING.md,README.md,llms.txt,docs/idea/README.md, andwiki/{Home,FAQ,Getting-Started,Upgrading,Known-Gaps,Migrations-And-Backfills,Deployment,_Footer}.md.llms.txtmatters disproportionately: it is the machine-readable repo map and the first thing an agent reads, and it carried all four stale claims in one sentence.docs/plans/**is deliberately untouched — those are historical audit records, a true statement of what was known then. The one survivingflags-was-never-published sentence is inCHANGELOG.md, describing the release where that was true.One doc bug found on the way
Unrelated to the release:
wiki/Deployment.md:190said "no role declares a metrics container port and the chart ships no scrape target." Both false —values.yaml:17declaresmetricsPort: 9090,_helpers.tpl:75-76emits thecontainerPort,service.yaml:35-37publishes it by name, andservicemonitor.yamlexists. It directly contradictedwiki/Known-Gaps.md:15, which was right. Corrected, including the "do not hand-add a duplicate port" warning.Also reconciled: a
_Footer.mdcount that said 40 where the line above it said 46, and aPUBLISHING.mdLICENSE count of 29 (re-derived: 30).Filed rather than fixed
@ultimat3/scrapingships 40 source files and 24 owned error codes with no wiki page, so the one package a reader is about to install first is undocumented.Not verified, left alone
PUBLISHING.md:276cites "393 files" swept into tarballs. That does not re-derive today (find packages/*/src -name '*.test.ts'is 855), and the tarball sizes beside it cannot be re-measured without publishing. It is out of this PR's scope and guessing a replacement would be the same failure this PR is fixing.🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.