fix(release): unblock the v0.6.0 release and bind public version copy - #341
Merged
Conversation
… hand Codex on #337, P1: `SECURITY.md` declared the `0.5.x` series while that PR sets package.json to 0.6.0, and `tests/docs/public-scope-copy.test.ts` derives the allowed series from package.json. `release.yml` runs the suite *before* `Run Release Please`, so merging #337 as-is fails the suite on master and the workflow stops before creating the tag or any release asset. Reproduced by setting the version to 0.6.0 locally: AssertionError: SECURITY.md names a version series the package is not on (package.json is 0.6.0): expected [ '0.5' ] to deeply equal [] The release PR would have been unmergeable in the only sense that matters: it could not have produced a release. Root cause is the shape this repository keeps hitting -- a hand-maintained duplicate of a fact with a canonical source. `release-please-config.json` already bumps `src/extension/version.ts`, `README.md` and `docs/PUBLICATION_READINESS.md` through `extra-files`; SECURITY.md restated the version and was not on that list, so it could only stay current by someone remembering, and the guard fired during the release rather than before it. SECURITY.md now names the exact release with the same `<!-- x-release-please-version -->` annotation the other three use, and joins `extra-files`. The exact form is also more accurate than the series it replaces: `0.5.x` reads as covering 0.5.0, which the row below it ("Previous releases | Not supported; upgrade to the current one") denies. Verified by simulating the release: bumping package.json and SECURITY.md together passes, and bumping package.json alone still fails with the drift message, so the guard keeps its purpose without blocking the release.
Codex on #337: both files said the GSTR-2B workbook builder "postdates v0.5.1", is not in a released binary, and that a user "cannot produce it yet". That is false for one of the two distributions Pack ships. Verified before changing the copy: - `src/entrypoints/offscreen/main.ts` imports `buildFiledReturnsGstr2bWorkbook` and branches on `gstr2bWorkbookApplicable` in the production offscreen entrypoint, so the builder is reachable in a built extension. - #337's generated changelog lists "add GSTR-2B invoice workbook (#196)" and the ITC summary sheet (#199) under 0.6.0, so the GitHub release binary carries it. - The Chrome Web Store publication is v0.5.0 and predates it, so a Store user genuinely cannot produce one. Both statements were true of different distributions and the copy collapsed them into one. It now says which is which, and keeps the Store restriction explicit rather than softening it. Both files also hard-coded `v0.5.1` on unannotated lines, two lines away from ones release-please bumps automatically -- the same duplicate that broke SECURITY.md. The corrected text names the Store publication instead, which moves only when a submission is recorded rather than with every release. This adds a positive claim about the GitHub release binary, so it is called out here for review rather than buried: it is evidenced by the entrypoint import above, not inferred from the changelog alone.
Three files named `v0.5.1` by hand beside lines release-please already bumps, and each was wrong the moment a release landed -- SECURITY.md blocked the 0.6.0 release outright, README and PUBLICATION_READINESS told readers a shipped feature was in no binary. Nothing caught the class; the security guard caught one instance, and only during the release it then blocked. Adds a guard that fails when any of the three names the *current* package version without the release annotation. It fires when the hard-coding is written rather than one release later when it has become false. An older version stays legal on purpose -- the Store publication record is one, and it does not move when this package does. The security assertion now binds the exact version rather than a `0.N.x` series, and a second assertion states that SECURITY.md is an `extra-files` entry carrying the annotation, so the binding is automatic rather than remembered. Mutation-tested, each caught with the offending file and line: - current version hard-coded in README -> "README.md hard-codes v0.5.1 ... ['README.md:503']" - annotation stripped from SECURITY.md -> "SECURITY.md hard-codes v0.5.1 ... ['SECURITY.md:10']" - SECURITY.md removed from extra-files -> 1 of 10 fails
lamemustafa
marked this pull request as ready for review
September 8, 2026 19:28
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c52821eae2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Codex on #341, P1: the previous commit overcorrected. The current published release is `v0.5.1`, and `ceb6ada` introduced the builder after it -- the v0.5.1 tree contains zero occurrences of `buildFiledReturnsGstr2bWorkbook`. So the copy saying the GitHub release binary carries it was false for anyone downloading the current release. The entrypoint import proves source availability, not release availability, and I read one as the other. This is the second time this paragraph has been wrong, in opposite directions: first denying every distribution while the source already carried the builder, then asserting the release binary carried it before any release did. A sentence that names which release has a feature is wrong on one side of the release that changes the answer, and this file merges before that release. So it no longer restates the answer. It states the Store restriction, which is fixed and does not move with this package, and directs the reader to compare `CHANGELOG.md` against the release recorded above for the GitHub side. README points at this document rather than carrying a second copy of the status. Worth recording that the previous commit flagged this exact risk in its own message -- "this adds a positive claim ... called out here for review" -- and made the error anyway. Flagging a claim is not the same as verifying it against the artifact it describes.
…n records Codex on #341: the guard flagged every occurrence of the current version, including ones that legitimately record another distribution. When the Chrome Web Store catches up to the source version, the Store publication record in `docs/PUBLICATION_READINESS.md` names the same number, and the guard's advice -- add the release annotation -- would make release-please rewrite that record on the next source release even though no new submission happened. The guard would have instructed the maintainer to corrupt a historical fact, and it would have contradicted the distribution policy the same PR introduced. A line naming the current version now declares which kind it is: the release annotation when it tracks this package's release, or `<!-- pack-fixed-distribution-version -->` when it records a version that must not be rewritten. The marker is an escape hatch and no file needs one today, so it is exercised directly rather than left as untested affordance -- tested-but-never-reached is how a guard rots. The scan is now a pure function over text so both paths can be driven from synthetic input. The guard also caught the prose added in the previous commit, which named the current version while explaining why not to name it. That line was rewritten rather than marked. Mutation-tested: - fixed-distribution line without its marker -> flagged with file and line - marker no longer honoured in the helper -> "expected [ 1, 3 ] to deeply equal [ 1 ]"
lamemustafa
added a commit
that referenced
this pull request
Sep 8, 2026
Codex on #337: the Features entry "add all-supported fiscal-year runner (#243)" reads as a capability this release ships. It is not one. The panel enables the flow only under `MODE === "source-surfaces"`: panel-surface.tsx:60 fullYearFlowAvailable = isPackSourceSurfaceBuildMode(import.meta.env.MODE) panel-guided-scope.tsx:91 sourceSurfacesEnabled = import.meta.env.MODE === "source-surfaces" and the comment above the second records that the literal comparison is deliberate so Vite constant-folds it and dead-code-eliminates the JSX from a packaged build. `README.md:68` already says the flow will not be available in the next production build. Release notes advertising it contradict the README and the standing prohibition on claiming durable full-year support. Ten entries in this section describe that flow, not one, so qualifying only the line Codex cited would leave nine reading the same way. A single note under the release heading states it once and covers the class; ten inline qualifications would be nine more copies of a fact to drift. Kept as a qualification rather than a removal. The work happened and the entries are accurate about source builds -- what was missing is which build they describe, which is the same distinction #341 drew for the GSTR-2B workbook.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Unblock the v0.6.0 release. #337 as generated cannot produce a release: it fails the suite on
master, and
release.ymlruns the suite beforeRun Release Please, so the workflow stopsbefore creating the tag or any release asset.
Fixes the three findings Codex raised on #337. All three share one root cause — public copy
hard-coding a version that
release-pleasealready bumps elsewhere — so this also adds a guard forthe class rather than the instances.
Blocks #337. Related: #336.
Root Cause / Decision Record
The P1, reproduced rather than taken on trust.
SECURITY.mddeclared the0.5.xseries;tests/docs/public-scope-copy.test.tsderives the allowed series frompackage.json. Setting theversion to 0.6.0 locally:
Merging #337 would therefore have re-broken the release pipeline hours after #338 unbroke it, by a
completely different mechanism.
Why it was a bump waiting to fail, not a one-off.
release-please-config.jsonalready updatessrc/extension/version.ts,README.mdanddocs/PUBLICATION_READINESS.mdthroughextra-files.SECURITY.mdrestated the version and was not on that list, so it stayed current only ifsomeone remembered, and the guard fired during the release it then blocked. That is the
hand-maintained-duplicate shape this repository keeps hitting.
So SECURITY.md now carries the same
<!-- x-release-please-version -->annotation as the otherthree and joins
extra-files. Verified by simulating the release both ways:package.jsonandSECURITY.mdbumped togetherpackage.jsonbumped aloneThe exact-version form is also more accurate than the series it replaces:
0.5.xreads as covering0.5.0, which the row directly below it ("Previous releases | Not supported; upgrade to the current
one") denies.
The GSTR-2B status, and the overcorrection that followed. Both files said the workbook builder
"postdates
v0.5.1", is not in a released binary, and that a user "cannot produce it yet". That waswrong once v0.6.0 releases, because
src/entrypoints/offscreen/main.tsimportsbuildFiledReturnsGstr2bWorkbookand #337's changelog lists it under 0.6.0.My first correction then asserted the GitHub release binary carries it, and review round 2 showed
that was wrong too, in the opposite direction:
The entrypoint import proves source availability; I read it as release availability — the exact
distinction the commit claimed to be drawing. The published release is still v0.5.1 and its tree has
no such import.
The paragraph has therefore been wrong in both directions, which is the real finding: a sentence
naming which release carries a feature is wrong on one side of the release that changes the answer,
and this PR merges before that release. It no longer restates the answer. It states the Store
restriction, which is fixed and does not move with this package, and directs the reader to compare
CHANGELOG.mdagainst the release recorded above. README points here rather than carrying a secondcopy.
Recorded because it is the more useful lesson than the fix: the first correction flagged this
exact risk in its own commit message and was wrong anyway. Flagging a claim is not verifying it
against the artifact it describes; the four commands above take under a minute.
The class, not the instances. All three files hard-coded
v0.5.1on unannotated lines,sometimes two lines from a line release-please bumps automatically. Nothing caught that class; the
security guard caught one instance and only during the release it blocked. The new guard fails when
any of the three names the current package version without the annotation, so it fires when the
hard-coding is written rather than one release later when it has quietly become false. An older
version stays legal on purpose — the Store publication record is one, and it does not move when
this package does.
Round 2 also narrowed that guard. As first written it flagged every occurrence of the current
version. Once the Chrome Web Store catches up to the source version, that would flag the fixed Store
publication record and advise adding the release annotation — which would make release-please
rewrite a historical fact on the next source release, contradicting the distribution policy this
same PR introduces. A guard that gives confident wrong advice in a state it will certainly reach is
worse than none.
Lines naming the current version now declare which kind they are:
<!-- x-release-please-version -->when they track this package's release,
<!-- pack-fixed-distribution-version -->when they record aversion that must not be rewritten. No file needs the second marker today, so the scan was extracted
to a pure function and both paths are driven from synthetic input — an escape hatch nothing reaches
is how a guard rots.
The narrowed guard immediately flagged prose added in the previous commit, which named the current
version while explaining why not to. That line was rewritten rather than marked.
Scope
src/is touched.release-please-config.jsongainsSECURITY.mdas anextra-filesentry.SECURITY.md,README.md,docs/PUBLICATION_READINESS.md.tests/docs/public-scope-copy.test.ts.CHANGELOG.mdcredits fix(filed-returns): simplify selection and completion paths #304's"simplify selection and completion paths" which
11cc788reverted. The changelog is generated byrelease-please and the 0.6.0 section exists only inside chore(master): release 0.6.0 #337 — there is nothing on master to
edit. It has to be corrected on the release branch after regeneration and before the next master
push regenerates it again. Tracked as the remaining step for chore(master): release 0.6.0 #337, not silently dropped.
Pack Workflow Preflight
pnpm workflow:preflightwas run before editing/push, or the skip reason is documented.Sanchika Adoption Gate
@sanchika/*packages or copied Sanchika guidance, Iread
sanchika/docs/adoption-pack.mdin the coordinated parent worktree.and records the Sanchika commit or copied guidance used.
../sanchika,sanchika/packages/*/src, or parentsource paths.
Privacy And Data-Flow Impact
match behaviour that already shipped; no behaviour changes here.
Sensitive Surface Review
Chrome Web Store Impact
docs/PUBLICATION_READINESS.mdis checked. It narrows what is claimed of the Store package by stating the restriction explicitly.Verification
pnpm install --frozen-lockfilepnpm audit --audit-level highpnpm exec wxt preparepnpm exec prettier --check .pnpm exec eslint . --max-warnings 0pnpm exec tsc --noEmitpnpm exec vitest runpnpm exec wxt buildnode scripts/verify-extension-package.mjs .output/chrome-mv3pnpm exec wxt zipnode scripts/verify-extension-zip.mjsnode scripts/write-release-provenance.mjsnode scripts/verify-github-release-assets.mjs --tag <tag> --zip <zip> --checksum <sha256> --provenance <json>when release assets existnode scripts/publish-chrome-web-store.mjs --zip .output/<zip> --provenance .output/pack-release-provenance.v1.json --publisher-id <id> --dry-run truegit diff --checkpnpm review:gate -- --strict-head-review --wait-head-review-ms 180000before merge/readiness claim; a missing Codex review blocks readiness:Unchecked boxes are release-only steps; this PR ships no artifact and touches no runtime source.
Every guard here was mutation-tested, since a guard that has not been made to fail proves
nothing — and this PR exists because an existing guard fired at the wrong moment:
Artifact Evidence
720099c.PR Review Follow-Up
4d11025— annotation +extra-files; reproduced the failure and both simulationsbe7e997— distributions distinguished; entrypoint import verified62de8ed— verified v0.5.1's tree lacks the import; copy no longer names a release720099c— two markers, pure-function scan, escape hatch exercised; 2 mutations caughtScreenshots
None — documentation, release configuration, and tests.