ci: keep the create-sei smoke green on Version Packages branches

[alexander-sei]

Summary

The Generated apps (auto) check fails on every Version Packages release PR (run on #339). The release smoke calls changeset status --output to learn which version @sei-js/precompiles will publish as, but changeset status doubles as a lint: when a branch changes packages without adding a changeset it prints

🦋  error Some packages have been changed but no changesets were found.

and calls process.exit(1) before writing the --output file. A Version Packages branch is precisely that state — Changesets consumes every changeset while it writes the bumped manifests — so the smoke died at Compute pending release metadata and never reached the versions it exists to validate.

The script already knows how to handle a versioned branch: selectPrecompilesSource has a current-manifest basis for exactly this case. It just could not get there.

• Only treat the status report as mandatory while changesets are still waiting to be released; otherwise the consumed state resolves to an empty release plan.
• changeset status still runs unconditionally, and its output stays authoritative whenever it succeeds, so genuine failures (malformed changesets, unknown packages) remain fatal while changesets are pending.
• No changeset added: this touches only the CI harness, which is not part of the published dist (same as ci: harden package release preparation #338).

Test plan

• Reproduced the failure locally in a throwaway worktree: ran changeset version on top of main to mirror the release PR (@sei-js/precompiles 2.1.3 → 3.0.0, .changeset reduced to README.md + config.json), then confirmed changeset status --output exits 1 and writes no file.
• Ran the full smoke against that simulated release state: it now selects the current-manifest basis, packs @sei-js/precompiles@3.0.0 without retagging, and passes both variants through install, audit, Biome, the Next production build, and the runtime/brand-asset probes — create-sei local smoke passed for base and precompiles variants at @sei-js/precompiles@3.0.0.
• Confirmed the pre-release path is unchanged on main, where changeset status still succeeds and reports the pending @sei-js/precompiles@3.0.0 bump that the template pins.
• bun run check and bun test --isolate src in packages/create-sei (17 pass), including two new tests covering the .changeset scan.

Made with Cursor

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.17%. Comparing base (d91053b) to head (0543f05).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #346   +/-   ##
=======================================
  Coverage   97.17%   97.17%           
=======================================
  Files          80       80           
  Lines        5410     5410           
=======================================
  Hits         5257     5257           
  Misses        153      153           

Flag	Coverage Δ
mcp-server	96.13% <ø> (ø)
precompiles	100.00% <ø> (ø)
registry	100.00% <ø> (ø)
sei-global-wallet	100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[seidroid]

A well-scoped CI-only fix that correctly unblocks the create-sei smoke on Version Packages branches while leaving the pre-release path fatal and unchanged. One non-blocking robustness gap: once changesets are consumed, any changeset status failure — not just the expected lint error — is swallowed and replaced with an empty release plan.

Findings: 0 blocking | 4 non-blocking | 1 posted inline

Blockers

• None at the file/PR level.

Non-blocking

• The Cursor second-opinion pass produced no output (cursor-review.md is empty), so this review merges only my findings with Codex's.
• No test covers computePendingReleasePlan itself — only the hasPendingChangesets predicate. The interesting behaviour (fatal vs. tolerated exit, and the empty-plan fallback) is untested. Not worth spawning a real changeset process for, but injecting the run/readdir dependencies would make the tolerated-failure branch assertable.
• Omitting a changeset is correct here per guideline §3 — this touches only the CI harness and nothing in the published dist.
• 1 suggestion(s)/nit(s) flagged inline on specific lines.

[seidroid]

[suggestion] Once .changeset is consumed, this treats every nonzero exit as the expected Version Packages condition. A malformed config.json, an unknown package reference, a missing changeset binary, or any runtime crash all produce the same message and an invented { releases: [] } — which then routes selectPrecompilesSource to the current-manifest basis and lets the smoke pass. Since this is exactly the branch state the fix exists to make green, a genuine regression here would stay invisible.

Consider narrowing the suppression to the specific failure. capture() is already available above, so you could match the known lint error rather than the exit code:

const { exitCode, stderr } = await capture([...], repositoryRoot);
if (exitCode !== 0) {
	if (changesetsPending || !/no changesets were found/i.test(stderr)) {
		throw new Error(`Compute pending release metadata failed with exit code ${exitCode}`);
	}
	console.log('Every changeset has already been consumed, so the error above is expected and no release is pending.');
	return { releases: [] };
}

That keeps fatal semantics honest while still tolerating the one state you intend to tolerate. (Also raised by Codex as P2.)