[srbaker]

Closes #184.

Promotes [Unreleased] to 1.10.0 and bumps the version. This ships #180: engine 4.0.0.a8, the in-place a5 → a8 upgrade, and Grail main 29833cd.

Stacked on #180. Merge this after #180, never before. Its base is feat/engine-upgrade-in-place. The repository has delete_branch_on_merge on, so when #180 merges GitHub deletes that branch and retargets this PR to main by itself. Check that the base reads main before merging. If it does not, retarget it by hand.

Why 1.10.0

A minor version, not 1.9.1 or 2.0.0:

• Not a patch. The engine changes, the Python runtime moves 134 Grail PRs, and the in-place upgrade is a new user-facing feature with a new prompt.
• Not a major. Nothing a 1.9.0 user has breaks or has to be redone. Their database is kept and upgraded after they confirm, with a backup. Settings, commands and the gemdb API are unchanged. Earlier releases bumped the minor version even when users had to delete their database (1.8.0's a4 → a5, 1.9.0's Rowan image), and this change is gentler than either.

What changes

• package.json / package-lock.json: npm version 1.10.0 --no-git-tag-version, as CONTRIBUTING.md says.
• CHANGELOG.md: a dated ## [1.10.0] - 2026-10-28 section, an empty [Unreleased], and the link definitions. The section opens with a preface that tells a 1.9.0 user not to delete ~/GemDB/db. The engine entry is now written for them: what triggers the prompt, what the upgrade does (stop, copy to db/data/extent0.dbf.pre-4.0.0.a5, upgrade, reinstall Python support and the MCP server), how long it takes, the disk space it needs (about the extent's size plus 1 GB), and what happens on a decline, a failure, an unconfirmed restore, and an auto-start or agent start. It also covers who still has to recreate their database. A new "A newer Python runtime" entry summarizes Grail c8cbc92 → 29833cd (176 commits, 134 PRs).
• README.md: "GemDB Code updates and associated data" used to say you should not expect to keep access to your data after an update that changes the engine version. It now describes the in-place upgrade. The gemdb.engineVersion bullet is changed to match. These edits do not overlap README: split the notebook debugging bullets into a "Debug a notebook cell" section #175's README hunks on main.

npm run release:notes 1.10.0 renders the section.

The date: if this merges on a later day, change the heading's date to that day before merging.

Not given entries

These are on main since 1.9.0, but not on #180's branch:

• README: split the notebook debugging bullets into a "Debug a notebook cell" section #175: reorganizes the README's notebook-debugging bullets into their own section.
• Bump the dev-dependencies group with 4 updates #182 and Bump @eslint/js from 9.39.5 to 10.0.1 #156: dev-dependency bumps.

Checks

• npm test: 71 files, 1318 tests passed.
• lint, lint:toolchain, format:check, typecheck and typecheck:strict are clean.
• npm run bundle, plus CI's packaging smoke (vsce package --target darwin-arm64), succeed.
• Not run locally: scripts/package.sh / check-vsix.sh and the integration suite. Both need the Grail and MCP payloads built against the pinned engine under ~/GemDB, which I left alone. CI's integration legs build, check and upload all three .vsix.

Follow-ups this PR does not make

• The Python-update warning looks stale. confirmGrailInstall in src/lifecycle.ts, and README's "How setup runs" paragraph, still say that installing newer Python support makes committed dates, decimals, tuples and instances stop working. Grail #1791 (in this pin range) rebuilds deployed modules in place to keep them working. Grail #1867 measured the release=c8cbc92 upgrade case at 243/0. So the warning now contradicts the upgrade path, which reinstalls Python support without asking. Changing that is a code change, so it belongs in its own PR.
• Download sizes. platform.ts's download and disk figures (170 MB / 470 MB) are still a5 measurements.
• The gitleaks scan of the .vsix (Upgrade an a5 database to a8 in place instead of asking to delete it #180's open item) runs in the Release workflow's scan job.

To release, after both PRs merge

1. Merge Upgrade an a5 database to a8 in place instead of asking to delete it #180. Confirm this PR retargeted to main, fix the date if needed, and merge it.
2. Wait for the main push CI run on the merge commit to go green. It uploads vsix-darwin-arm64, vsix-linux-x64 and vsix-linux-arm64.
3. Optionally, npm run release:fetch on that commit, then install dist/gemdb-darwin-arm64-1.10.0.vsix over a 1.9.0 setup and run the upgrade once.
4. Go to Actions → Release → Run workflow on main with 1.10.0, ticking dry-run first (validate → collect → scan).
5. Run it again without dry-run and approve at the release-approval gate. It tags v1.10.0, creates the GitHub Release, publishes to the Marketplace and Open VSX, then runs verify.

🤖 Generated with Claude Code