[MatiasFernandez]

Fixes #115
Fixes #126
Part of #134 (items 1–3; 4–6 remain, so not auto-closed)

What changes

When the stone is down, gemdb file.py / -c / -m used to start it from ~130 lines of bash that had drifted from ensureProcesses, skipped assertSafeToStart (a pin move ended in a raw 4045), and treated external databases differently from the window and the Shell. It also ran against a database Grail was never filed into.

Now the wrapper keeps only a stamp test and an ok fast path. Everything else runs gemdb-shell.js --ensure-stone, which goes through the same ensureProcesses + guards as the Shell.

Commits

1. One external-database check. assertExternalDatabaseUp replaces the two copies (window, Shell). Waits for a stone still at Startup; says "the administrator runs it" instead of "start it again"; names no GemDB log.
2. Wrapper hands starts to Node. ensureProcesses({ listener: false }): the CLI starts the stone only (file mode is a linked topaz and never uses NetLDI). withStoneLock now reports that it is waiting, so a CLI run behind a window's start isn't silent for up to 150 s. Argument checks (-c with no code, missing file) run before anything starts. Bash lock/start/wait block deleted.
3. Refuse without Python. New GRAIL_NOT_INSTALLED ("Run GemDB: Start GemDB…") for wrapper, Shell and --ensure-stone. GRAIL_MISSING is untouched: it now means "stamp present, Python gone", which only Reinstall repairs.

Review focus

• src/cli.ts template: the fast path / --ensure-stone </dev/null logic and the moved argument checks. The post-run $STATUS is renamed RUN_STATUS to keep it apart from STONE_STATUS.
• Accepted cost: a cold start needs the staged bundle and a Node (recorded execPath, else PATH). A missing one refuses with the Shell's messages; there is no bash fallback.
• Lock name/format must not change until 1.8.0-and-earlier wrappers (1.8.0 still generates the bash lock) (which still take it in bash) are gone; comments in lock.ts/processes.ts now say so.
• Integration fixtures now call recordGrailInstalled, otherwise every own-database test gets the new refusal.

Verification

• Manual testing

Known and left alone (pre-existing or minor, found in review): the fast path takes only ok, so frozen/exe deleted now go through Node; a bare gemdb -m still starts the stone before failing; external "stopped while starting" wording.

Related, not in this PR: #143 (activation doesn't start the MCP server when the stone is up and NetLDI is down).

🤖 Generated with Claude Code