docs: restamp the status table to 5.0.0, verified against the registry - #234
Conversation
…n from intent
Written AFTER the publish, not with it, so no row here is a guess. `CLAUDE.md`'s own header says
never to read a number in it as the installable one — that only holds if the numbers were true when
written.
Every row verified with the command beside it:
- `bun run scripts/registry-audit.ts --json` → 30/30 on npm at 5.0.0, every one attested
- `npm view @ultimat3/core version` → 5.0.0
- `git ls-remote --tags origin 'refs/tags/v5.0.0*'` → both the ref and its peeled `^{}` line, which
is what proves the tag is annotated and on the remote
- `bun run scripts/release.ts --check 5.0.0` → 30 packages stamped
Also corrected: the file still said 4.0.0 throughout, having missed the 4.1.0 release entirely, and
three sentences claimed "3.0.0 and 4.0.0 both went out through the workflow" — 4.1.0 and 5.0.0 did
too, which is the claim that matters for "every release since the publishers were attached".
The major paragraph now describes 5.0.0's four breaking changes and states the migration, which is
one line and only if you wrote it.
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: 26 minutes Limit details: You’ve used the included review currently available. Your 76 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. You’re in a promotional period — use the checkbox below to run this review for free:
On-demand reviews are free for the next 31 days. After that, they cost $0.25 per reviewed file. How can I continue?Run this review now using the option above, or comment You can also wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. 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 (1)
Comment |
Written AFTER the publish, the rule #234 established: `CLAUDE.md`'s own header says never to read a number in it as the installable one, and that only holds if the numbers were true when written. Verified with the command beside each row: - `bun run scripts/registry-audit.ts --json` → 30/30 on npm at 5.0.1, every one attested - `npm view @ultimat3/core version` → 5.0.1 - `git ls-remote --tags origin 'refs/tags/v5.0.1*'` → both the ref and its peeled `^{}` line - `bun run scripts/release.ts --check 5.0.1` → 30 packages stamped `wiki/Known-Gaps.md`'s #230 row moves from **main** to **5.0.1**, which is what it is now installable in — the Closed table's third column exists for readers pinned below it, and "main" is not a version anybody can install. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ings are gone (#268) `scripts/release.ts` generates a `## <version>` section from commit subjects and APPENDS it, leaving the hand-written `## [Unreleased]` untouched above. So the tagged tree read: ## [Unreleased] the 7 BREAKING entries and every migration ## 6.0.0 commit subjects, including #238/#237/#234 from 5.0.1 while `wiki/Upgrading.md` told the reader to read the `6.0.0` section. For a major whose whole value is its upgrade guide, that is the failure the guide exists to prevent. It had happened twice before and nobody noticed: `CHANGELOG.md` carried two `## 5.0.1` headings and two `## 5.0.0` headings, an auto-generated commit dump above each hand-written section. Both removed. The generated section also reached past the previous tag, which is why three commits that shipped in 5.0.1 appeared under 6.0.0. Why it stayed invisible is the part worth keeping: the count in `wiki/Upgrading.md` IS derived from `CHANGELOG.md`, and a migration filed under the wrong heading is invisible to a derived count — it only makes the number smaller. A derived number protects against a stale claim, never a misplaced one. Corrected by hand; #267 tracks promoting instead of appending, and the gate rules that would have caught all three. Claude-Session: https://claude.ai/code/session_01KgsU1WBJMAjnLaazvfuJmD Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Written after the publish, not with it, so no row is a guess.
CLAUDE.md's own header says never to read a number in it as the installable one — that only holds if the numbers were true when written.Verified, each with the command the table names
bun run scripts/registry-audit.ts --json30/30 publishable packages are on npm at 5.0.0, every one attestednpm view @ultimat3/core version5.0.0git ls-remote --tags origin 'refs/tags/v5.0.0*'^{}line — which is what proves the tag is annotated and on the remotebun run scripts/release.ts --check 5.0.0npm view @ultimat3/core@5.0.0 _npmUserGitHub Actions,oidc:…Two things that were already stale
npm latest, still named 4.0.0 while npm served 4.1.0.The major paragraph
Replaced with 5.0.0's four breaking changes and the migration, which is one line and only if you wrote it. 4.0.0's 25 entries are kept as what came before, since
wiki/Upgrading.mdstill walks every major.bun run verify— 14 of 18, 4 skipped at the framework root.🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.