cli: netscript db leaves an ephemeral db-operation AppHost running that masks the resident one (aspire describe reports the wrong host)

[rickylabs]

A netscript db command materialises a separate AppHost project at aspire/db-operation/ and leaves it running. It then becomes the AppHost that aspire reports, so aspire describe names the ephemeral db-operation host while the project's real, resident AppHost appears not to be running at all.

Found by the wave-4 DeepSeek attribution-control run on published 0.0.4. It was part of the run's third-ranked drift entry (~40 min, with a stale Vite snapshot).

Relationship to #1011

#1011 (a read-only netscript db command terminates the resident AppHost) shipped in 0.0.4. The command no longer kills the resident AppHost — it now stands up its own isolated one instead. The isolated host is never torn down, so the failure moved rather than closed: before, the resident AppHost died; now it is masked.

Evidence

The generated project is left on disk in the run's workspace:

product/deploy-queue/aspire/db-operation/
├── apphost.mts              # "GENERATED BY @netscript/cli. DO NOT EDIT."
├── aspire.config.json
├── tsconfig.apphost.json
└── .aspire/

// apphost.mts
const dbOperationEnv = JSON.parse(readFileSync(new URL('./.netscript-db-operation.json', import.meta.url), 'utf8'));
Object.assign(process.env, dbOperationEnv);

It also leaves an untracked .netscript-db-operation.json in the workspace, which shows up in git status as project noise.

In the run's own words:

A leaked db-operation/apphost.mts (started by a netscript db command) was the only "running" AppHost until I stopped it.

a netscript db command leaked a db-operation AppHost that made aspire describe lie about what was running

Why this is expensive

The failure is not an error — it is a diagnostic tool reporting the wrong answer. The agent was mid-debug on an unrelated problem, asked the environment what was running, and was told something false. Detecting it requires already suspecting it.

It is also live outside this run: at the time of filing, an aspire run --apphost .../aspire/db-operation/apphost.mts process from a separate 0.0.5 plugin-smoke e2e was running on this machine, so the pattern is in active use elsewhere in the toolchain.

Acceptance

• A netscript db command tears down any AppHost it starts, on success and on failure — PR #1301 runner regressions assert exact-path stop on both outcomes.
• After any netscript db command, aspire describe reports the project's resident AppHost, not an ephemeral db-operation one — PR #1301 live gate asserts stable resident identity and exact operation-path absence.
• No db-operation AppHost project or .netscript-db-operation.json is left in the workspace after the command returns — PR #1301 command lifecycle tests and the live gate assert both artifacts are absent.
• If an ephemeral host must persist for a long-running command (e.g. db studio), it is named and reported as such rather than shadowing the resident host — PR #1301 studio regressions prove Studio uses the named resident AppHost and creates no persistent shadow host.
• A test that fails without the fix asserts resident-AppHost visibility after a read-only netscript db command — the exact gap fix(cli): a read-only netscript db command terminates the resident AppHost #1011's fix left open — PR #1301 read-only runtime gate passed in the 71/71 scaffold runtime run.

Verification

aspire stop exits 0 before its child tree is down, so re-probe /proc/<pid> rather than trusting the exit code. Verify the artefact — the absence of the process and the directory — not the command's status.

[rickylabs]

Scheduled by the milestone orchestrator: wave-3 slice, 0.0.5-canary.2 train (Sol·medium). The ephemeral aspire/db-operation/ AppHost must be torn down (verified process-tree death, not exit code) or the resident host reused; aspire describe must report the project's real resident AppHost afterwards — RED captured first on today's build, per the standing verification bar. The live instance you observed under ns005-sagas/.llm/tmp/ is noted: the in-flight #1193 slice's leak-check obligation covers it at its gate, and the #1190 slice has been briefed to report (not adopt) stray ephemeral hosts.