fix(release): stop the desktop version silently blocking every release by pitimon · Pull Request #96 · pitimon/TokenTracker

pitimon · 2026-07-25T02:28:37Z

Closes the second half of the two governance gaps found after 0.39.42 shipped.

The tags weren't forgotten — they were impossible

Tags stopped at v0.39.38 while npm reached 0.39.42. The cause isn't a missed step:

release-dmg.yml is the only thing in this repo that creates a tag. Its first job runs gh release create "v<version>" --draft --generate-notes, it dispatches the Windows build in parallel, and its final job flips the release out of draft with --latest. One dispatch produces the tag, the .dmg and the .exe.
That workflow refuses to build when TokenTrackerBar/project.yml's MARKETING_VERSION disagrees with package.json — and release-windows.yml does the same for TokenTrackerWin.csproj's <Version>.
Both sat at 0.39.38. So every desktop release from 0.39.39 on would have failed at that gate. "Forgot to tag" and "couldn't build the apps" were one omission, not two.

Three files carry the version, all three hand-edited, and npm version touches only one.

Why nothing caught it

The check already existed — in the release workflows. A gate in a workflow nobody dispatches reports nothing. It went unnoticed for four releases.

scripts/validate-version-lockstep.cjs runs the same check in ci:local, where every PR shows it. That is the reasoning ci.yml already records for itself: the #18 dashboard redesign merged with failing tests because the gate ran only post-merge, so the gate moved in front of the merge. Same fix, different gate.

It collects each version literal separately, so the case release-dmg.yml documents in its own comment — one of the two project.yml targets bumped, shipping a DMG whose Info.plist advertised the previous version — also fails. A checkout without the desktop projects passes; the CLI is publishable alone.

scripts/sync-desktop-version.cjs rewrites them and is wired to npm's version lifecycle. Deliberately not described as automatic: this repo bumps with npm version --no-git-tag-version, which makes no commit, so npm never stages what a version hook edited — the files remain working-tree changes you must git add. The validator is the guarantee; the hook only saves typing. The checklist says so in those words.

Also in this change set (already pushed, not in this diff)

Tags v0.39.39, v0.39.40, v0.39.41 backfilled as annotated tags at their real release commits (7c105cb, 96479cc, 0ea200e), each recording why it was late. Deliberately git tags and not GitHub Releases: an assetless Release would take over /releases/latest, which the README now points at for desktop downloads.
enforce_admins enabled on main. Protection required ci:local but exempted admins, so the two direct release pushes reported Bypassed rule violations. Verified that ci.yml's job is literally name: ci:local and runs on: pull_request, so PRs still produce the required context and merges are unaffected — this PR is that test. Direct pushes to main can no longer satisfy it, which is the intent.

After this merges, release-dmg.yml can be dispatched for 0.39.42 to produce the tag and both desktop builds.

Test plan

npm run ci:local — exit 0, 833/833 (was 827; +6 here)
Validator proven against the real defect: on main as it stood it printed all three mismatches and exited 1; after sync-desktop-version.cjs, exit 0
Six tests over a temp-directory fixture, so the validator never edits the tree it validates: the historical 0.39.38-vs-0.39.42 drift, the one-target-missed case, a sparse checkout, sync idempotence, and that sync rewrites only the version and leaves the rest of each file intact
enforce_admins blocking a direct push is verified by config read-back and mechanism, not by an attempted push — I was not willing to land an unreviewed commit on main to prove it. The first real attempt will confirm.

The repo's tags stopped at v0.39.38 while npm went to 0.39.42. That looked like four forgotten tags. It wasn't: `release-dmg.yml` is the only thing that tags, and it refuses to build when `TokenTrackerBar/project.yml`'s MARKETING_VERSION disagrees with package.json. That file — and `TokenTrackerWin.csproj` — sat at 0.39.38, so a desktop release was impossible from 0.39.39 onward. Forgetting to tag and being unable to build the apps were the same omission. Three files carry the release version and all three were hand-edited; `npm version` touched only one. The existing gates live in the release workflows, which report nothing when nobody dispatches them — so the drift was invisible for four releases. - validate-version-lockstep.cjs runs the same check in `ci:local`, where a PR shows it. Same reasoning ci.yml already records for moving the test gate in front of the merge rather than after it. It collects each version literal separately, so the "only one of the two project.yml targets got bumped" case — which once shipped a DMG advertising the previous version — fails too. A checkout without the desktop projects is not a failure. - sync-desktop-version.cjs rewrites them, wired to npm's `version` lifecycle. Deliberately NOT described as automatic: this repo bumps with `npm version --no-git-tag-version`, which makes no commit, so npm never stages what the hook edited. The files still need `git add`. The validator is the guarantee; the hook just saves typing. - Both desktop projects moved to 0.39.42, so the apps can be cut again. This does not claim a desktop build ships with every npm release — the README is explicit that they are cut less often. It keeps the version recorded in *source* in step, which is what makes a release possible at any time instead of a version bump away.

Ships #98 (issue #97): GitHub Copilot quota now reports the premium-request count — "158/300", or "142/300" in Remaining mode — instead of a percentage the reader has to convert. The numbers were already being fetched from api.github.com and discarded after one division. The independent Codex QA gate returned SHIP: NO on the first cut and all three findings were real: the bar and its caption could be drawn from different fields and disagree (70% beside 228/300, which is 76%); a null `remaining` coerced to zero and reported the whole allowance consumed; and the dashboard clamped only one end, so an unclamped payload could render "312/300" in either mode. Fixed, each with a regression test built from the exact reproduction. First release where the `version` lifecycle hook from #96 did its job: the bump synced TokenTrackerBar/project.yml and TokenTrackerWin.csproj, which is what made 0.39.39–0.39.42 unable to cut a desktop build. prepublishOnly re-vendored the LiteLLM seed: 2,522 models, no rate changes, only _meta.generated_at moved. Co-authored-by: itarun.p <itarun.p@somapait.com>

pitimon · 2026-07-25T02:28:37Z

Closes the second half of the two governance gaps found after 0.39.42 shipped.

The tags weren't forgotten — they were impossible

Tags stopped at v0.39.38 while npm reached 0.39.42. The cause isn't a missed step:

release-dmg.yml is the only thing in this repo that creates a tag. Its first job runs gh release create "v<version>" --draft --generate-notes, it dispatches the Windows build in parallel, and its final job flips the release out of draft with --latest. One dispatch produces the tag, the .dmg and the .exe.
That workflow refuses to build when TokenTrackerBar/project.yml's MARKETING_VERSION disagrees with package.json — and release-windows.yml does the same for TokenTrackerWin.csproj's <Version>.
Both sat at 0.39.38. So every desktop release from 0.39.39 on would have failed at that gate. "Forgot to tag" and "couldn't build the apps" were one omission, not two.

Three files carry the version, all three hand-edited, and npm version touches only one.

Why nothing caught it

The check already existed — in the release workflows. A gate in a workflow nobody dispatches reports nothing. It went unnoticed for four releases.

scripts/validate-version-lockstep.cjs runs the same check in ci:local, where every PR shows it. That is the reasoning ci.yml already records for itself: the #18 dashboard redesign merged with failing tests because the gate ran only post-merge, so the gate moved in front of the merge. Same fix, different gate.

It collects each version literal separately, so the case release-dmg.yml documents in its own comment — one of the two project.yml targets bumped, shipping a DMG whose Info.plist advertised the previous version — also fails. A checkout without the desktop projects passes; the CLI is publishable alone.

scripts/sync-desktop-version.cjs rewrites them and is wired to npm's version lifecycle. Deliberately not described as automatic: this repo bumps with npm version --no-git-tag-version, which makes no commit, so npm never stages what a version hook edited — the files remain working-tree changes you must git add. The validator is the guarantee; the hook only saves typing. The checklist says so in those words.

Also in this change set (already pushed, not in this diff)

Tags v0.39.39, v0.39.40, v0.39.41 backfilled as annotated tags at their real release commits (7c105cb, 96479cc, 0ea200e), each recording why it was late. Deliberately git tags and not GitHub Releases: an assetless Release would take over /releases/latest, which the README now points at for desktop downloads.
enforce_admins enabled on main. Protection required ci:local but exempted admins, so the two direct release pushes reported Bypassed rule violations. Verified that ci.yml's job is literally name: ci:local and runs on: pull_request, so PRs still produce the required context and merges are unaffected — this PR is that test. Direct pushes to main can no longer satisfy it, which is the intent.

After this merges, release-dmg.yml can be dispatched for 0.39.42 to produce the tag and both desktop builds.

Test plan

npm run ci:local — exit 0, 833/833 (was 827; +6 here)
Validator proven against the real defect: on main as it stood it printed all three mismatches and exited 1; after sync-desktop-version.cjs, exit 0
Six tests over a temp-directory fixture, so the validator never edits the tree it validates: the historical 0.39.38-vs-0.39.42 drift, the one-target-missed case, a sparse checkout, sync idempotence, and that sync rewrites only the version and leaves the rest of each file intact
enforce_admins blocking a direct push is verified by config read-back and mechanism, not by an attempted push — I was not willing to land an unreviewed commit on main to prove it. The first real attempt will confirm.

The repo's tags stopped at v0.39.38 while npm went to 0.39.42. That looked like four forgotten tags. It wasn't: `release-dmg.yml` is the only thing that tags, and it refuses to build when `TokenTrackerBar/project.yml`'s MARKETING_VERSION disagrees with package.json. That file — and `TokenTrackerWin.csproj` — sat at 0.39.38, so a desktop release was impossible from 0.39.39 onward. Forgetting to tag and being unable to build the apps were the same omission. Three files carry the release version and all three were hand-edited; `npm version` touched only one. The existing gates live in the release workflows, which report nothing when nobody dispatches them — so the drift was invisible for four releases. - validate-version-lockstep.cjs runs the same check in `ci:local`, where a PR shows it. Same reasoning ci.yml already records for moving the test gate in front of the merge rather than after it. It collects each version literal separately, so the "only one of the two project.yml targets got bumped" case — which once shipped a DMG advertising the previous version — fails too. A checkout without the desktop projects is not a failure. - sync-desktop-version.cjs rewrites them, wired to npm's `version` lifecycle. Deliberately NOT described as automatic: this repo bumps with `npm version --no-git-tag-version`, which makes no commit, so npm never stages what the hook edited. The files still need `git add`. The validator is the guarantee; the hook just saves typing. - Both desktop projects moved to 0.39.42, so the apps can be cut again. This does not claim a desktop build ships with every npm release — the README is explicit that they are cut less often. It keeps the version recorded in *source* in step, which is what makes a release possible at any time instead of a version bump away.

Ships #98 (issue #97): GitHub Copilot quota now reports the premium-request count — "158/300", or "142/300" in Remaining mode — instead of a percentage the reader has to convert. The numbers were already being fetched from api.github.com and discarded after one division. The independent Codex QA gate returned SHIP: NO on the first cut and all three findings were real: the bar and its caption could be drawn from different fields and disagree (70% beside 228/300, which is 76%); a null `remaining` coerced to zero and reported the whole allowance consumed; and the dashboard clamped only one end, so an unclamped payload could render "312/300" in either mode. Fixed, each with a regression test built from the exact reproduction. First release where the `version` lifecycle hook from #96 did its job: the bump synced TokenTrackerBar/project.yml and TokenTrackerWin.csproj, which is what made 0.39.39–0.39.42 unable to cut a desktop build. prepublishOnly re-vendored the LiteLLM seed: 2,522 models, no rate changes, only _meta.generated_at moved. Co-authored-by: itarun.p <itarun.p@somapait.com>

pitimon · 2026-07-25T02:28:37Z

Closes the second half of the two governance gaps found after 0.39.42 shipped.

The tags weren't forgotten — they were impossible

Tags stopped at v0.39.38 while npm reached 0.39.42. The cause isn't a missed step:

release-dmg.yml is the only thing in this repo that creates a tag. Its first job runs gh release create "v<version>" --draft --generate-notes, it dispatches the Windows build in parallel, and its final job flips the release out of draft with --latest. One dispatch produces the tag, the .dmg and the .exe.
That workflow refuses to build when TokenTrackerBar/project.yml's MARKETING_VERSION disagrees with package.json — and release-windows.yml does the same for TokenTrackerWin.csproj's <Version>.
Both sat at 0.39.38. So every desktop release from 0.39.39 on would have failed at that gate. "Forgot to tag" and "couldn't build the apps" were one omission, not two.

Three files carry the version, all three hand-edited, and npm version touches only one.

Why nothing caught it

The check already existed — in the release workflows. A gate in a workflow nobody dispatches reports nothing. It went unnoticed for four releases.

scripts/validate-version-lockstep.cjs runs the same check in ci:local, where every PR shows it. That is the reasoning ci.yml already records for itself: the #18 dashboard redesign merged with failing tests because the gate ran only post-merge, so the gate moved in front of the merge. Same fix, different gate.

It collects each version literal separately, so the case release-dmg.yml documents in its own comment — one of the two project.yml targets bumped, shipping a DMG whose Info.plist advertised the previous version — also fails. A checkout without the desktop projects passes; the CLI is publishable alone.

scripts/sync-desktop-version.cjs rewrites them and is wired to npm's version lifecycle. Deliberately not described as automatic: this repo bumps with npm version --no-git-tag-version, which makes no commit, so npm never stages what a version hook edited — the files remain working-tree changes you must git add. The validator is the guarantee; the hook only saves typing. The checklist says so in those words.

Also in this change set (already pushed, not in this diff)

Tags v0.39.39, v0.39.40, v0.39.41 backfilled as annotated tags at their real release commits (7c105cb, 96479cc, 0ea200e), each recording why it was late. Deliberately git tags and not GitHub Releases: an assetless Release would take over /releases/latest, which the README now points at for desktop downloads.
enforce_admins enabled on main. Protection required ci:local but exempted admins, so the two direct release pushes reported Bypassed rule violations. Verified that ci.yml's job is literally name: ci:local and runs on: pull_request, so PRs still produce the required context and merges are unaffected — this PR is that test. Direct pushes to main can no longer satisfy it, which is the intent.

After this merges, release-dmg.yml can be dispatched for 0.39.42 to produce the tag and both desktop builds.

Test plan

npm run ci:local — exit 0, 833/833 (was 827; +6 here)
Validator proven against the real defect: on main as it stood it printed all three mismatches and exited 1; after sync-desktop-version.cjs, exit 0
Six tests over a temp-directory fixture, so the validator never edits the tree it validates: the historical 0.39.38-vs-0.39.42 drift, the one-target-missed case, a sparse checkout, sync idempotence, and that sync rewrites only the version and leaves the rest of each file intact
enforce_admins blocking a direct push is verified by config read-back and mechanism, not by an attempted push — I was not willing to land an unreviewed commit on main to prove it. The first real attempt will confirm.

The repo's tags stopped at v0.39.38 while npm went to 0.39.42. That looked like four forgotten tags. It wasn't: `release-dmg.yml` is the only thing that tags, and it refuses to build when `TokenTrackerBar/project.yml`'s MARKETING_VERSION disagrees with package.json. That file — and `TokenTrackerWin.csproj` — sat at 0.39.38, so a desktop release was impossible from 0.39.39 onward. Forgetting to tag and being unable to build the apps were the same omission. Three files carry the release version and all three were hand-edited; `npm version` touched only one. The existing gates live in the release workflows, which report nothing when nobody dispatches them — so the drift was invisible for four releases. - validate-version-lockstep.cjs runs the same check in `ci:local`, where a PR shows it. Same reasoning ci.yml already records for moving the test gate in front of the merge rather than after it. It collects each version literal separately, so the "only one of the two project.yml targets got bumped" case — which once shipped a DMG advertising the previous version — fails too. A checkout without the desktop projects is not a failure. - sync-desktop-version.cjs rewrites them, wired to npm's `version` lifecycle. Deliberately NOT described as automatic: this repo bumps with `npm version --no-git-tag-version`, which makes no commit, so npm never stages what the hook edited. The files still need `git add`. The validator is the guarantee; the hook just saves typing. - Both desktop projects moved to 0.39.42, so the apps can be cut again. This does not claim a desktop build ships with every npm release — the README is explicit that they are cut less often. It keeps the version recorded in *source* in step, which is what makes a release possible at any time instead of a version bump away.

Ships #98 (issue #97): GitHub Copilot quota now reports the premium-request count — "158/300", or "142/300" in Remaining mode — instead of a percentage the reader has to convert. The numbers were already being fetched from api.github.com and discarded after one division. The independent Codex QA gate returned SHIP: NO on the first cut and all three findings were real: the bar and its caption could be drawn from different fields and disagree (70% beside 228/300, which is 76%); a null `remaining` coerced to zero and reported the whole allowance consumed; and the dashboard clamped only one end, so an unclamped payload could render "312/300" in either mode. Fixed, each with a regression test built from the exact reproduction. First release where the `version` lifecycle hook from #96 did its job: the bump synced TokenTrackerBar/project.yml and TokenTrackerWin.csproj, which is what made 0.39.39–0.39.42 unable to cut a desktop build. prepublishOnly re-vendored the LiteLLM seed: 2,522 models, no rate changes, only _meta.generated_at moved. Co-authored-by: itarun.p <itarun.p@somapait.com>

pitimon · 2026-07-25T02:28:37Z

Closes the second half of the two governance gaps found after 0.39.42 shipped.

The tags weren't forgotten — they were impossible

Tags stopped at v0.39.38 while npm reached 0.39.42. The cause isn't a missed step:

release-dmg.yml is the only thing in this repo that creates a tag. Its first job runs gh release create "v<version>" --draft --generate-notes, it dispatches the Windows build in parallel, and its final job flips the release out of draft with --latest. One dispatch produces the tag, the .dmg and the .exe.
That workflow refuses to build when TokenTrackerBar/project.yml's MARKETING_VERSION disagrees with package.json — and release-windows.yml does the same for TokenTrackerWin.csproj's <Version>.
Both sat at 0.39.38. So every desktop release from 0.39.39 on would have failed at that gate. "Forgot to tag" and "couldn't build the apps" were one omission, not two.

Three files carry the version, all three hand-edited, and npm version touches only one.

Why nothing caught it

The check already existed — in the release workflows. A gate in a workflow nobody dispatches reports nothing. It went unnoticed for four releases.

scripts/validate-version-lockstep.cjs runs the same check in ci:local, where every PR shows it. That is the reasoning ci.yml already records for itself: the #18 dashboard redesign merged with failing tests because the gate ran only post-merge, so the gate moved in front of the merge. Same fix, different gate.

It collects each version literal separately, so the case release-dmg.yml documents in its own comment — one of the two project.yml targets bumped, shipping a DMG whose Info.plist advertised the previous version — also fails. A checkout without the desktop projects passes; the CLI is publishable alone.

scripts/sync-desktop-version.cjs rewrites them and is wired to npm's version lifecycle. Deliberately not described as automatic: this repo bumps with npm version --no-git-tag-version, which makes no commit, so npm never stages what a version hook edited — the files remain working-tree changes you must git add. The validator is the guarantee; the hook only saves typing. The checklist says so in those words.

Also in this change set (already pushed, not in this diff)

Tags v0.39.39, v0.39.40, v0.39.41 backfilled as annotated tags at their real release commits (7c105cb, 96479cc, 0ea200e), each recording why it was late. Deliberately git tags and not GitHub Releases: an assetless Release would take over /releases/latest, which the README now points at for desktop downloads.
enforce_admins enabled on main. Protection required ci:local but exempted admins, so the two direct release pushes reported Bypassed rule violations. Verified that ci.yml's job is literally name: ci:local and runs on: pull_request, so PRs still produce the required context and merges are unaffected — this PR is that test. Direct pushes to main can no longer satisfy it, which is the intent.

After this merges, release-dmg.yml can be dispatched for 0.39.42 to produce the tag and both desktop builds.

Test plan

npm run ci:local — exit 0, 833/833 (was 827; +6 here)
Validator proven against the real defect: on main as it stood it printed all three mismatches and exited 1; after sync-desktop-version.cjs, exit 0
Six tests over a temp-directory fixture, so the validator never edits the tree it validates: the historical 0.39.38-vs-0.39.42 drift, the one-target-missed case, a sparse checkout, sync idempotence, and that sync rewrites only the version and leaves the rest of each file intact
enforce_admins blocking a direct push is verified by config read-back and mechanism, not by an attempted push — I was not willing to land an unreviewed commit on main to prove it. The first real attempt will confirm.

The repo's tags stopped at v0.39.38 while npm went to 0.39.42. That looked like four forgotten tags. It wasn't: `release-dmg.yml` is the only thing that tags, and it refuses to build when `TokenTrackerBar/project.yml`'s MARKETING_VERSION disagrees with package.json. That file — and `TokenTrackerWin.csproj` — sat at 0.39.38, so a desktop release was impossible from 0.39.39 onward. Forgetting to tag and being unable to build the apps were the same omission. Three files carry the release version and all three were hand-edited; `npm version` touched only one. The existing gates live in the release workflows, which report nothing when nobody dispatches them — so the drift was invisible for four releases. - validate-version-lockstep.cjs runs the same check in `ci:local`, where a PR shows it. Same reasoning ci.yml already records for moving the test gate in front of the merge rather than after it. It collects each version literal separately, so the "only one of the two project.yml targets got bumped" case — which once shipped a DMG advertising the previous version — fails too. A checkout without the desktop projects is not a failure. - sync-desktop-version.cjs rewrites them, wired to npm's `version` lifecycle. Deliberately NOT described as automatic: this repo bumps with `npm version --no-git-tag-version`, which makes no commit, so npm never stages what the hook edited. The files still need `git add`. The validator is the guarantee; the hook just saves typing. - Both desktop projects moved to 0.39.42, so the apps can be cut again. This does not claim a desktop build ships with every npm release — the README is explicit that they are cut less often. It keeps the version recorded in *source* in step, which is what makes a release possible at any time instead of a version bump away.

Ships #98 (issue #97): GitHub Copilot quota now reports the premium-request count — "158/300", or "142/300" in Remaining mode — instead of a percentage the reader has to convert. The numbers were already being fetched from api.github.com and discarded after one division. The independent Codex QA gate returned SHIP: NO on the first cut and all three findings were real: the bar and its caption could be drawn from different fields and disagree (70% beside 228/300, which is 76%); a null `remaining` coerced to zero and reported the whole allowance consumed; and the dashboard clamped only one end, so an unclamped payload could render "312/300" in either mode. Fixed, each with a regression test built from the exact reproduction. First release where the `version` lifecycle hook from #96 did its job: the bump synced TokenTrackerBar/project.yml and TokenTrackerWin.csproj, which is what made 0.39.39–0.39.42 unable to cut a desktop build. prepublishOnly re-vendored the LiteLLM seed: 2,522 models, no rate changes, only _meta.generated_at moved. Co-authored-by: itarun.p <itarun.p@somapait.com>

pitimon · 2026-07-25T02:28:37Z

Closes the second half of the two governance gaps found after 0.39.42 shipped.

The tags weren't forgotten — they were impossible

Tags stopped at v0.39.38 while npm reached 0.39.42. The cause isn't a missed step:

release-dmg.yml is the only thing in this repo that creates a tag. Its first job runs gh release create "v<version>" --draft --generate-notes, it dispatches the Windows build in parallel, and its final job flips the release out of draft with --latest. One dispatch produces the tag, the .dmg and the .exe.
That workflow refuses to build when TokenTrackerBar/project.yml's MARKETING_VERSION disagrees with package.json — and release-windows.yml does the same for TokenTrackerWin.csproj's <Version>.
Both sat at 0.39.38. So every desktop release from 0.39.39 on would have failed at that gate. "Forgot to tag" and "couldn't build the apps" were one omission, not two.

Three files carry the version, all three hand-edited, and npm version touches only one.

Why nothing caught it

The check already existed — in the release workflows. A gate in a workflow nobody dispatches reports nothing. It went unnoticed for four releases.

scripts/validate-version-lockstep.cjs runs the same check in ci:local, where every PR shows it. That is the reasoning ci.yml already records for itself: the #18 dashboard redesign merged with failing tests because the gate ran only post-merge, so the gate moved in front of the merge. Same fix, different gate.

It collects each version literal separately, so the case release-dmg.yml documents in its own comment — one of the two project.yml targets bumped, shipping a DMG whose Info.plist advertised the previous version — also fails. A checkout without the desktop projects passes; the CLI is publishable alone.

scripts/sync-desktop-version.cjs rewrites them and is wired to npm's version lifecycle. Deliberately not described as automatic: this repo bumps with npm version --no-git-tag-version, which makes no commit, so npm never stages what a version hook edited — the files remain working-tree changes you must git add. The validator is the guarantee; the hook only saves typing. The checklist says so in those words.

Also in this change set (already pushed, not in this diff)

Tags v0.39.39, v0.39.40, v0.39.41 backfilled as annotated tags at their real release commits (7c105cb, 96479cc, 0ea200e), each recording why it was late. Deliberately git tags and not GitHub Releases: an assetless Release would take over /releases/latest, which the README now points at for desktop downloads.
enforce_admins enabled on main. Protection required ci:local but exempted admins, so the two direct release pushes reported Bypassed rule violations. Verified that ci.yml's job is literally name: ci:local and runs on: pull_request, so PRs still produce the required context and merges are unaffected — this PR is that test. Direct pushes to main can no longer satisfy it, which is the intent.

After this merges, release-dmg.yml can be dispatched for 0.39.42 to produce the tag and both desktop builds.

Test plan

npm run ci:local — exit 0, 833/833 (was 827; +6 here)
Validator proven against the real defect: on main as it stood it printed all three mismatches and exited 1; after sync-desktop-version.cjs, exit 0
Six tests over a temp-directory fixture, so the validator never edits the tree it validates: the historical 0.39.38-vs-0.39.42 drift, the one-target-missed case, a sparse checkout, sync idempotence, and that sync rewrites only the version and leaves the rest of each file intact
enforce_admins blocking a direct push is verified by config read-back and mechanism, not by an attempted push — I was not willing to land an unreviewed commit on main to prove it. The first real attempt will confirm.

The repo's tags stopped at v0.39.38 while npm went to 0.39.42. That looked like four forgotten tags. It wasn't: `release-dmg.yml` is the only thing that tags, and it refuses to build when `TokenTrackerBar/project.yml`'s MARKETING_VERSION disagrees with package.json. That file — and `TokenTrackerWin.csproj` — sat at 0.39.38, so a desktop release was impossible from 0.39.39 onward. Forgetting to tag and being unable to build the apps were the same omission. Three files carry the release version and all three were hand-edited; `npm version` touched only one. The existing gates live in the release workflows, which report nothing when nobody dispatches them — so the drift was invisible for four releases. - validate-version-lockstep.cjs runs the same check in `ci:local`, where a PR shows it. Same reasoning ci.yml already records for moving the test gate in front of the merge rather than after it. It collects each version literal separately, so the "only one of the two project.yml targets got bumped" case — which once shipped a DMG advertising the previous version — fails too. A checkout without the desktop projects is not a failure. - sync-desktop-version.cjs rewrites them, wired to npm's `version` lifecycle. Deliberately NOT described as automatic: this repo bumps with `npm version --no-git-tag-version`, which makes no commit, so npm never stages what the hook edited. The files still need `git add`. The validator is the guarantee; the hook just saves typing. - Both desktop projects moved to 0.39.42, so the apps can be cut again. This does not claim a desktop build ships with every npm release — the README is explicit that they are cut less often. It keeps the version recorded in *source* in step, which is what makes a release possible at any time instead of a version bump away.

Ships #98 (issue #97): GitHub Copilot quota now reports the premium-request count — "158/300", or "142/300" in Remaining mode — instead of a percentage the reader has to convert. The numbers were already being fetched from api.github.com and discarded after one division. The independent Codex QA gate returned SHIP: NO on the first cut and all three findings were real: the bar and its caption could be drawn from different fields and disagree (70% beside 228/300, which is 76%); a null `remaining` coerced to zero and reported the whole allowance consumed; and the dashboard clamped only one end, so an unclamped payload could render "312/300" in either mode. Fixed, each with a regression test built from the exact reproduction. First release where the `version` lifecycle hook from #96 did its job: the bump synced TokenTrackerBar/project.yml and TokenTrackerWin.csproj, which is what made 0.39.39–0.39.42 unable to cut a desktop build. prepublishOnly re-vendored the LiteLLM seed: 2,522 models, no rate changes, only _meta.generated_at moved. Co-authored-by: itarun.p <itarun.p@somapait.com>

pitimon · 2026-07-25T02:28:37Z

Closes the second half of the two governance gaps found after 0.39.42 shipped.

The tags weren't forgotten — they were impossible

Tags stopped at v0.39.38 while npm reached 0.39.42. The cause isn't a missed step:

release-dmg.yml is the only thing in this repo that creates a tag. Its first job runs gh release create "v<version>" --draft --generate-notes, it dispatches the Windows build in parallel, and its final job flips the release out of draft with --latest. One dispatch produces the tag, the .dmg and the .exe.
That workflow refuses to build when TokenTrackerBar/project.yml's MARKETING_VERSION disagrees with package.json — and release-windows.yml does the same for TokenTrackerWin.csproj's <Version>.
Both sat at 0.39.38. So every desktop release from 0.39.39 on would have failed at that gate. "Forgot to tag" and "couldn't build the apps" were one omission, not two.

Three files carry the version, all three hand-edited, and npm version touches only one.

Why nothing caught it

The check already existed — in the release workflows. A gate in a workflow nobody dispatches reports nothing. It went unnoticed for four releases.

scripts/validate-version-lockstep.cjs runs the same check in ci:local, where every PR shows it. That is the reasoning ci.yml already records for itself: the #18 dashboard redesign merged with failing tests because the gate ran only post-merge, so the gate moved in front of the merge. Same fix, different gate.

It collects each version literal separately, so the case release-dmg.yml documents in its own comment — one of the two project.yml targets bumped, shipping a DMG whose Info.plist advertised the previous version — also fails. A checkout without the desktop projects passes; the CLI is publishable alone.

scripts/sync-desktop-version.cjs rewrites them and is wired to npm's version lifecycle. Deliberately not described as automatic: this repo bumps with npm version --no-git-tag-version, which makes no commit, so npm never stages what a version hook edited — the files remain working-tree changes you must git add. The validator is the guarantee; the hook only saves typing. The checklist says so in those words.

Also in this change set (already pushed, not in this diff)

Tags v0.39.39, v0.39.40, v0.39.41 backfilled as annotated tags at their real release commits (7c105cb, 96479cc, 0ea200e), each recording why it was late. Deliberately git tags and not GitHub Releases: an assetless Release would take over /releases/latest, which the README now points at for desktop downloads.
enforce_admins enabled on main. Protection required ci:local but exempted admins, so the two direct release pushes reported Bypassed rule violations. Verified that ci.yml's job is literally name: ci:local and runs on: pull_request, so PRs still produce the required context and merges are unaffected — this PR is that test. Direct pushes to main can no longer satisfy it, which is the intent.

After this merges, release-dmg.yml can be dispatched for 0.39.42 to produce the tag and both desktop builds.

Test plan

npm run ci:local — exit 0, 833/833 (was 827; +6 here)
Validator proven against the real defect: on main as it stood it printed all three mismatches and exited 1; after sync-desktop-version.cjs, exit 0
Six tests over a temp-directory fixture, so the validator never edits the tree it validates: the historical 0.39.38-vs-0.39.42 drift, the one-target-missed case, a sparse checkout, sync idempotence, and that sync rewrites only the version and leaves the rest of each file intact
enforce_admins blocking a direct push is verified by config read-back and mechanism, not by an attempted push — I was not willing to land an unreviewed commit on main to prove it. The first real attempt will confirm.

The repo's tags stopped at v0.39.38 while npm went to 0.39.42. That looked like four forgotten tags. It wasn't: `release-dmg.yml` is the only thing that tags, and it refuses to build when `TokenTrackerBar/project.yml`'s MARKETING_VERSION disagrees with package.json. That file — and `TokenTrackerWin.csproj` — sat at 0.39.38, so a desktop release was impossible from 0.39.39 onward. Forgetting to tag and being unable to build the apps were the same omission. Three files carry the release version and all three were hand-edited; `npm version` touched only one. The existing gates live in the release workflows, which report nothing when nobody dispatches them — so the drift was invisible for four releases. - validate-version-lockstep.cjs runs the same check in `ci:local`, where a PR shows it. Same reasoning ci.yml already records for moving the test gate in front of the merge rather than after it. It collects each version literal separately, so the "only one of the two project.yml targets got bumped" case — which once shipped a DMG advertising the previous version — fails too. A checkout without the desktop projects is not a failure. - sync-desktop-version.cjs rewrites them, wired to npm's `version` lifecycle. Deliberately NOT described as automatic: this repo bumps with `npm version --no-git-tag-version`, which makes no commit, so npm never stages what the hook edited. The files still need `git add`. The validator is the guarantee; the hook just saves typing. - Both desktop projects moved to 0.39.42, so the apps can be cut again. This does not claim a desktop build ships with every npm release — the README is explicit that they are cut less often. It keeps the version recorded in *source* in step, which is what makes a release possible at any time instead of a version bump away.

Ships #98 (issue #97): GitHub Copilot quota now reports the premium-request count — "158/300", or "142/300" in Remaining mode — instead of a percentage the reader has to convert. The numbers were already being fetched from api.github.com and discarded after one division. The independent Codex QA gate returned SHIP: NO on the first cut and all three findings were real: the bar and its caption could be drawn from different fields and disagree (70% beside 228/300, which is 76%); a null `remaining` coerced to zero and reported the whole allowance consumed; and the dashboard clamped only one end, so an unclamped payload could render "312/300" in either mode. Fixed, each with a regression test built from the exact reproduction. First release where the `version` lifecycle hook from #96 did its job: the bump synced TokenTrackerBar/project.yml and TokenTrackerWin.csproj, which is what made 0.39.39–0.39.42 unable to cut a desktop build. prepublishOnly re-vendored the LiteLLM seed: 2,522 models, no rate changes, only _meta.generated_at moved. Co-authored-by: itarun.p <itarun.p@somapait.com>

pitimon · 2026-07-25T02:28:37Z

Closes the second half of the two governance gaps found after 0.39.42 shipped.

The tags weren't forgotten — they were impossible

Tags stopped at v0.39.38 while npm reached 0.39.42. The cause isn't a missed step:

release-dmg.yml is the only thing in this repo that creates a tag. Its first job runs gh release create "v<version>" --draft --generate-notes, it dispatches the Windows build in parallel, and its final job flips the release out of draft with --latest. One dispatch produces the tag, the .dmg and the .exe.
That workflow refuses to build when TokenTrackerBar/project.yml's MARKETING_VERSION disagrees with package.json — and release-windows.yml does the same for TokenTrackerWin.csproj's <Version>.
Both sat at 0.39.38. So every desktop release from 0.39.39 on would have failed at that gate. "Forgot to tag" and "couldn't build the apps" were one omission, not two.

Three files carry the version, all three hand-edited, and npm version touches only one.

Why nothing caught it

The check already existed — in the release workflows. A gate in a workflow nobody dispatches reports nothing. It went unnoticed for four releases.

scripts/validate-version-lockstep.cjs runs the same check in ci:local, where every PR shows it. That is the reasoning ci.yml already records for itself: the #18 dashboard redesign merged with failing tests because the gate ran only post-merge, so the gate moved in front of the merge. Same fix, different gate.

It collects each version literal separately, so the case release-dmg.yml documents in its own comment — one of the two project.yml targets bumped, shipping a DMG whose Info.plist advertised the previous version — also fails. A checkout without the desktop projects passes; the CLI is publishable alone.

scripts/sync-desktop-version.cjs rewrites them and is wired to npm's version lifecycle. Deliberately not described as automatic: this repo bumps with npm version --no-git-tag-version, which makes no commit, so npm never stages what a version hook edited — the files remain working-tree changes you must git add. The validator is the guarantee; the hook only saves typing. The checklist says so in those words.

Also in this change set (already pushed, not in this diff)

Tags v0.39.39, v0.39.40, v0.39.41 backfilled as annotated tags at their real release commits (7c105cb, 96479cc, 0ea200e), each recording why it was late. Deliberately git tags and not GitHub Releases: an assetless Release would take over /releases/latest, which the README now points at for desktop downloads.
enforce_admins enabled on main. Protection required ci:local but exempted admins, so the two direct release pushes reported Bypassed rule violations. Verified that ci.yml's job is literally name: ci:local and runs on: pull_request, so PRs still produce the required context and merges are unaffected — this PR is that test. Direct pushes to main can no longer satisfy it, which is the intent.

After this merges, release-dmg.yml can be dispatched for 0.39.42 to produce the tag and both desktop builds.

Test plan

npm run ci:local — exit 0, 833/833 (was 827; +6 here)
Validator proven against the real defect: on main as it stood it printed all three mismatches and exited 1; after sync-desktop-version.cjs, exit 0
Six tests over a temp-directory fixture, so the validator never edits the tree it validates: the historical 0.39.38-vs-0.39.42 drift, the one-target-missed case, a sparse checkout, sync idempotence, and that sync rewrites only the version and leaves the rest of each file intact
enforce_admins blocking a direct push is verified by config read-back and mechanism, not by an attempted push — I was not willing to land an unreviewed commit on main to prove it. The first real attempt will confirm.

The repo's tags stopped at v0.39.38 while npm went to 0.39.42. That looked like four forgotten tags. It wasn't: `release-dmg.yml` is the only thing that tags, and it refuses to build when `TokenTrackerBar/project.yml`'s MARKETING_VERSION disagrees with package.json. That file — and `TokenTrackerWin.csproj` — sat at 0.39.38, so a desktop release was impossible from 0.39.39 onward. Forgetting to tag and being unable to build the apps were the same omission. Three files carry the release version and all three were hand-edited; `npm version` touched only one. The existing gates live in the release workflows, which report nothing when nobody dispatches them — so the drift was invisible for four releases. - validate-version-lockstep.cjs runs the same check in `ci:local`, where a PR shows it. Same reasoning ci.yml already records for moving the test gate in front of the merge rather than after it. It collects each version literal separately, so the "only one of the two project.yml targets got bumped" case — which once shipped a DMG advertising the previous version — fails too. A checkout without the desktop projects is not a failure. - sync-desktop-version.cjs rewrites them, wired to npm's `version` lifecycle. Deliberately NOT described as automatic: this repo bumps with `npm version --no-git-tag-version`, which makes no commit, so npm never stages what the hook edited. The files still need `git add`. The validator is the guarantee; the hook just saves typing. - Both desktop projects moved to 0.39.42, so the apps can be cut again. This does not claim a desktop build ships with every npm release — the README is explicit that they are cut less often. It keeps the version recorded in *source* in step, which is what makes a release possible at any time instead of a version bump away.

Ships #98 (issue #97): GitHub Copilot quota now reports the premium-request count — "158/300", or "142/300" in Remaining mode — instead of a percentage the reader has to convert. The numbers were already being fetched from api.github.com and discarded after one division. The independent Codex QA gate returned SHIP: NO on the first cut and all three findings were real: the bar and its caption could be drawn from different fields and disagree (70% beside 228/300, which is 76%); a null `remaining` coerced to zero and reported the whole allowance consumed; and the dashboard clamped only one end, so an unclamped payload could render "312/300" in either mode. Fixed, each with a regression test built from the exact reproduction. First release where the `version` lifecycle hook from #96 did its job: the bump synced TokenTrackerBar/project.yml and TokenTrackerWin.csproj, which is what made 0.39.39–0.39.42 unable to cut a desktop build. prepublishOnly re-vendored the LiteLLM seed: 2,522 models, no rate changes, only _meta.generated_at moved. Co-authored-by: itarun.p <itarun.p@somapait.com>

pitimon · 2026-07-25T02:28:37Z

Closes the second half of the two governance gaps found after 0.39.42 shipped.

The tags weren't forgotten — they were impossible

Tags stopped at v0.39.38 while npm reached 0.39.42. The cause isn't a missed step:

release-dmg.yml is the only thing in this repo that creates a tag. Its first job runs gh release create "v<version>" --draft --generate-notes, it dispatches the Windows build in parallel, and its final job flips the release out of draft with --latest. One dispatch produces the tag, the .dmg and the .exe.
That workflow refuses to build when TokenTrackerBar/project.yml's MARKETING_VERSION disagrees with package.json — and release-windows.yml does the same for TokenTrackerWin.csproj's <Version>.
Both sat at 0.39.38. So every desktop release from 0.39.39 on would have failed at that gate. "Forgot to tag" and "couldn't build the apps" were one omission, not two.

Three files carry the version, all three hand-edited, and npm version touches only one.

Why nothing caught it

The check already existed — in the release workflows. A gate in a workflow nobody dispatches reports nothing. It went unnoticed for four releases.

scripts/validate-version-lockstep.cjs runs the same check in ci:local, where every PR shows it. That is the reasoning ci.yml already records for itself: the #18 dashboard redesign merged with failing tests because the gate ran only post-merge, so the gate moved in front of the merge. Same fix, different gate.

It collects each version literal separately, so the case release-dmg.yml documents in its own comment — one of the two project.yml targets bumped, shipping a DMG whose Info.plist advertised the previous version — also fails. A checkout without the desktop projects passes; the CLI is publishable alone.

scripts/sync-desktop-version.cjs rewrites them and is wired to npm's version lifecycle. Deliberately not described as automatic: this repo bumps with npm version --no-git-tag-version, which makes no commit, so npm never stages what a version hook edited — the files remain working-tree changes you must git add. The validator is the guarantee; the hook only saves typing. The checklist says so in those words.

Also in this change set (already pushed, not in this diff)

Tags v0.39.39, v0.39.40, v0.39.41 backfilled as annotated tags at their real release commits (7c105cb, 96479cc, 0ea200e), each recording why it was late. Deliberately git tags and not GitHub Releases: an assetless Release would take over /releases/latest, which the README now points at for desktop downloads.
enforce_admins enabled on main. Protection required ci:local but exempted admins, so the two direct release pushes reported Bypassed rule violations. Verified that ci.yml's job is literally name: ci:local and runs on: pull_request, so PRs still produce the required context and merges are unaffected — this PR is that test. Direct pushes to main can no longer satisfy it, which is the intent.

After this merges, release-dmg.yml can be dispatched for 0.39.42 to produce the tag and both desktop builds.

Test plan

npm run ci:local — exit 0, 833/833 (was 827; +6 here)
Validator proven against the real defect: on main as it stood it printed all three mismatches and exited 1; after sync-desktop-version.cjs, exit 0
Six tests over a temp-directory fixture, so the validator never edits the tree it validates: the historical 0.39.38-vs-0.39.42 drift, the one-target-missed case, a sparse checkout, sync idempotence, and that sync rewrites only the version and leaves the rest of each file intact
enforce_admins blocking a direct push is verified by config read-back and mechanism, not by an attempted push — I was not willing to land an unreviewed commit on main to prove it. The first real attempt will confirm.

The repo's tags stopped at v0.39.38 while npm went to 0.39.42. That looked like four forgotten tags. It wasn't: `release-dmg.yml` is the only thing that tags, and it refuses to build when `TokenTrackerBar/project.yml`'s MARKETING_VERSION disagrees with package.json. That file — and `TokenTrackerWin.csproj` — sat at 0.39.38, so a desktop release was impossible from 0.39.39 onward. Forgetting to tag and being unable to build the apps were the same omission. Three files carry the release version and all three were hand-edited; `npm version` touched only one. The existing gates live in the release workflows, which report nothing when nobody dispatches them — so the drift was invisible for four releases. - validate-version-lockstep.cjs runs the same check in `ci:local`, where a PR shows it. Same reasoning ci.yml already records for moving the test gate in front of the merge rather than after it. It collects each version literal separately, so the "only one of the two project.yml targets got bumped" case — which once shipped a DMG advertising the previous version — fails too. A checkout without the desktop projects is not a failure. - sync-desktop-version.cjs rewrites them, wired to npm's `version` lifecycle. Deliberately NOT described as automatic: this repo bumps with `npm version --no-git-tag-version`, which makes no commit, so npm never stages what the hook edited. The files still need `git add`. The validator is the guarantee; the hook just saves typing. - Both desktop projects moved to 0.39.42, so the apps can be cut again. This does not claim a desktop build ships with every npm release — the README is explicit that they are cut less often. It keeps the version recorded in *source* in step, which is what makes a release possible at any time instead of a version bump away.

Ships #98 (issue #97): GitHub Copilot quota now reports the premium-request count — "158/300", or "142/300" in Remaining mode — instead of a percentage the reader has to convert. The numbers were already being fetched from api.github.com and discarded after one division. The independent Codex QA gate returned SHIP: NO on the first cut and all three findings were real: the bar and its caption could be drawn from different fields and disagree (70% beside 228/300, which is 76%); a null `remaining` coerced to zero and reported the whole allowance consumed; and the dashboard clamped only one end, so an unclamped payload could render "312/300" in either mode. Fixed, each with a regression test built from the exact reproduction. First release where the `version` lifecycle hook from #96 did its job: the bump synced TokenTrackerBar/project.yml and TokenTrackerWin.csproj, which is what made 0.39.39–0.39.42 unable to cut a desktop build. prepublishOnly re-vendored the LiteLLM seed: 2,522 models, no rate changes, only _meta.generated_at moved. Co-authored-by: itarun.p <itarun.p@somapait.com>

pitimon merged commit 58b8f92 into mainJul 25, 2026
1 check passed

pitimon deleted the fix/version-lockstep-and-release-tags branch July 25, 2026 02:30

pitimon mentioned this pull request Jul 25, 2026
chore(release): 0.39.43 #99
Merged
6 tasks

This was referenced Jul 25, 2026
ci: make the outbound-call inventory machine-checked #101
Closed
queue: compact the append-only store and enforce the row invariant #103
Closed