release: v3.10.0 GitHub release exists but never published to npm — clean up phantom release

[carlos-alm]

Summary

The v3.10.0 release flow ended in an inconsistent state:

• ✅ GitHub release v3.10.0 is published
• ✅ Git tag `v3.10.0` exists on `main`
• ❌ npm package `@optave/codegraph@3.10.0` was never published (`npm view @optave/codegraph versions` ends at 3.9.6)
• ❌ `package.json` on `main` is still `3.9.6`

What happened

The new pre-publish benchmark gate (#1040) correctly caught the native-engine regressions (#1054, #1055) and blocked the npm publish job — but only after the release event had already created the GitHub release. The publish workflow's `Pre-publish benchmark gate` job is upstream of `publish` (good), but downstream of `actions/checkout@v6` against the already-tagged release ref (the tag is what the workflow checks out).

Failed run: the `publish` and `publish-dev` jobs were skipped because the gate failed; the GH release remained.

User-visible consequence

Anyone consulting the GitHub releases page sees v3.10.0 as the latest stable, but `npm install @optave/codegraph@latest` still resolves to 3.9.6. This is a confusing inconsistency — the changelog/release notes describe shipped changes that aren't actually shipped.

Decisions needed

1. Release retraction: delete the v3.10.0 GitHub release + tag, or convert it to a draft until the regressions are fixed?
2. Next stable version: if v3.10.0 ships with perf(native): ~2 second flat overhead added to rebuild operations in v3.10.0 #1054/perf(native): fnDeps query 52% slower in v3.10.0 (likely shares root cause with #1054) #1055 fixed, do we re-tag (force) v3.10.0, or bump to v3.10.1 to keep history monotonic?
3. Workflow guard: should the pre-publish benchmark gate run before the GitHub release is created (e.g., on the release-prep PR / push-to-main rather than the release event), so a regression aborts the release earlier?

Suggested workflow improvement

Run the regression guard on the `docs: prepare release notes for vX.Y.Z` PR (it's the last commit before the release tag). If it fails there, the release simply isn't cut. Today the gate runs after the tag exists, which is too late to prevent partial-release state.

[kecsap]

And the release 3.9.6 does not contain the disabledTools feature for the MCP server somehow.

[carlos-alm]

Quick status update — the v3.10.0 publish-blocking regression has been root-caused.

Two distinct issues, not one.

1. HCL files dropped on every native build. tree-sitter-hcl 1.1.0 ships parser code built for tree-sitter ABI 15 while crates/codegraph-core was pinned at tree-sitter = "0.24" (ABI 14). Parser::set_language rejects the grammar at runtime, every .tf file is filtered out, the JS engine-parity layer reports a "drop" and falls back to WASM. Fix in fix(native): bump tree-sitter to 0.25 + ABI regression test (#1054) #1060: bump tree-sitter to 0.25 + add a cargo test regression check (all_grammars_have_compatible_abi) so the next ABI drift is caught at PR-time instead of after release.

2. A separate ~2-second-per-call native overhead in CI that doesn't reproduce locally — even Docker Linux runs no-op rebuilds in 7 ms. This isn't the HCL drop (the drop's WASM backfill is cheap; fix(perf): scope WASM grammar load in engine-parity backfill (#1054) #1058 made it cheaper still as defense-in-depth). chore(bench): per-iteration phase trace for #1054 diagnosis [DO NOT MERGE] #1062 is a throwaway diagnostic branch that adds per-iteration phase breakdown to the bench scripts; dispatching the gate against it will reveal which pipeline stage eats the 2 s, after which the actual fix will land as a separate focused PR.

Resolution path for this issue (phantom v3.10.0 release):

• Merge fix(native): bump tree-sitter to 0.25 + ABI regression test (#1054) #1060 → eliminates the HCL drops.
• Run chore(bench): per-iteration phase trace for #1054 diagnosis [DO NOT MERGE] #1062 against the gate, read the trace, open the targeted fix for the per-call overhead.
• Once the gate clears, re-dispatch publish.yml with version=3.10.0. If it succeeds, this issue resolves itself (the v3.10.0 GitHub tag finally has a matching npm artifact). If we'd rather skip 3.10.0 entirely and ship the next stable as 3.10.1, the GitHub tag can be deleted manually instead.

Side note: #1059 (force CC=clang) was merged earlier on a wrong premise — clang and gcc both produce binaries that drop .tf files because the cause is the ABI mismatch, not the C compiler. Revert in #1061.

[carlos-alm]

Resolved — @optave/codegraph@3.10.0 is now published to npm (verified via npm view @optave/codegraph versions), so the GitHub release and npm registry are back in sync. The HCL ABI drop (#1060) and CI bench overhead were fixed and the gate cleared on the re-dispatched publish.yml run.