Restage the gemdb command whenever it differs from what we ship

[jgfoster]

The GemDB Shell still printed gcits login: … after #14 silenced it. #14 is correct — the fix was in the extension's bundle, but the terminal runs the staged copy:

$ ls -l ~/GemDB/bin/gemdb-shell.js        # Aug 24 14:49
$ ls -l out/gemdb-shell.js                # Aug 27 11:40  ← has the fix
$ grep -c 'GCI_LOGIN_QUIET\|, 16,' out/gemdb-shell.js        # 2
$ grep -c 'GCI_LOGIN_QUIET\|, 16,' ~/GemDB/bin/gemdb-shell.js # 0

Why it was never refreshed

writeCliScripts had exactly two callers:

1. stageGrail — runs only when the Grail payload stamp differs.
2. a backstop in ensureRunning, guarded by if (!fs.existsSync(cliPath())) — only when the wrapper is missing outright.

So an update carrying only code restaged nothing. Releases mostly got away with it because bundle:grail clones Grail HEAD and the payload nearly always moves too — but a developer rebuilding in an extension development host never changes it, which is exactly the case that reported this. It would also strand a shipped shell fix in any release where Grail happened not to change.

The change

The guard is gone; ensureRunning calls writeCliScripts every time. To make that cheap, the function now builds the wrapper and the driver first, fingerprints them together with out/gemdb-shell.js, and returns without touching the disk when that matches <rootPath>/bin/.gemdb-cli-stamp. The common case does no work — and in particular no rm/cpSync of koffi.

Content, not a version number, deliberately: the bundle changes on every npm run bundle, and the wrapper bakes in the editor's own process.execPath, which moves when VS Code updates. A version stamp would miss both.

The stamp is written last, so it never claims a generation that threw partway.

Tests, and what they do not cover

Four new: restage on a changed bundle, no writes when the bytes are identical, restage when the wrapper differs, and no stamp left after a failure.

Being straight about the limit — these do not reproduce the original bug. The old writeCliScripts always wrote; the bug lived entirely in its callers, and ensureRunning is not reachable from the unit suite (no editor). The call-site change is verified by inspection, and the new tests exist to keep the unconditional call affordable and correct rather than to catch what went wrong.

118 unit tests, 46 integration. Lint, format, both typechecks clean.

For the reporter

Opening a shell goes through ensureRunning (statusView → gemdb.openRepl → requireRunning), so with this merged a window reload restages before the terminal opens. Without it, rm ~/GemDB/bin/gemdb trips the old backstop and has the same effect.

🤖 Generated with Claude Code

[jgfoster]

The first commit here was in the wrong place. Pushed a second one that fixes it.

Testing the workaround I suggested — delete bin/gemdb to trip the old backstop — produced The terminal process failed to launch: Path to shell executable "/Users/…/GemDB/bin/gemdb" does not exist. The cause is in repl.ts:

async function requireRunning(extensionPath: string): Promise<boolean> {
  if (findStone() && findNetldi()) return true;   // ← returns here
  return ensureRunning(extensionPath);
}

With the database already up — the common case, and permanently so for a developer — opening a shell never reaches ensureRunning. So the restage in the first commit sat in the one place the shell path skips, and would not have fixed the stale bundle it was written for. Same reason the deletion workaround stranded the reporter with no wrapper at all.

openRepl and runFile now call ensureCliCurrent before creating a terminal. That is where the guarantee belongs: whoever hands VS Code a path as a terminal's shell program owns whether it exists and is current. It stays cheap because writeCliScripts fingerprints first, and when generation is impossible it returns false and the command explains itself instead of VS Code reporting a launch failure that names no cause.

Verified on the real install, not a fixture: regenerated ~/GemDB/bin from this checkout and drove the staged shell through a pty —

GemDB Shell — Python inside the database. This terminal is its own session.
Ctrl+C interrupts · exit() or Ctrl+D leaves
>>>
--- gcits present: False ---

One correction to the first commit's evidence. I compared the two bundles with grep -c 'GCI_LOGIN_QUIET\|, 16,' and reported 2 versus 0. out/gemdb-shell.js is minified, so that identifier appears in neither file and those counts meant nothing. The diagnosis still holds — on the mtimes (Aug 24 staged vs Aug 27 built), on the reporter seeing the line, and now on the pty run above — but the grep should not have been offered as proof.

119 unit tests, 46 integration.