`npm run build` deletes the SQLite integration and the site stops booting

Running the project's own build inside a site the toolkit created leaves that site unable to reach its database. The next start fails and does not recover on its own.

This is on the path the app itself recommends. The hint under the Terminal panel says:

Edited files in src/? Run npm run build so the site picks them up.

Which is correct advice, and following it breaks the site.

What happens

Error: Error connecting to the SQLite database.
    at Module.K [as bootWordPress] (@wp-playground/wordpress/index.cjs)
    at w.bootWordPress (@wp-playground/cli/worker-thread-v1.cjs)
Caused by: Error: Comlink method call failed

The server never reports a URL. Starting it again produces the same error. Nothing on screen explains what is missing, and the error names SQLite rather than the build that caused it, so there is no obvious thread to pull.

Why

Playground mounts build/ as /wordpress, and it installs its SQLite integration into that mounted tree:

• build/wp-content/plugins/sqlite-database-integration/
• build/wp-content/db.php

WordPress's build replaces build/wp-content from src/wp-content. src/wp-content contains only index.php, plugins/ and themes/, so after a build:

• build/wp-content/db.php is gone
• build/wp-content/plugins/ holds only hello.php and index.php

The database file itself survives. build/wp-content/database/.ht.sqlite was still 1.2 MB here, so no data is lost. What is lost is the code that lets WordPress reach it, and Playground does not reinstall it on the next boot.

Steps to reproduce

1. Create a site through the toolkit and let it finish installing and building.
2. Start the dev server once and confirm it works.
3. Change any PHP file under src/, or change nothing at all.
4. Run npm run build in the site directory. It completes successfully: Done., exit code 0.
5. Start the dev server again.

Observed: the server never reports a URL, and the log carries the SQLite boot error above.

Expected: the site starts, serving the newly built tree.

Reproduced twice, on two different sites

The second was created from scratch minutes before, through the app, and had booted successfully once before the build. So this is not a property of one damaged checkout.

Confirming the mechanism directly, on the fresh site:

$ ls build/wp-content/db.php
db.php GONE
$ ls build/wp-content/plugins/
hello.php
index.php

Why it matters more than it looks

PHP changes in src/ only reach the served site through a build, so "edit PHP, build, look" is the normal loop for anything outside JavaScript. That loop currently ends with a dead site.

For a Contributor Day newcomer it ends the session. The failure arrives later, at the next start, in a stack trace about Comlink and SQLite, with nothing connecting it to the command they were told to run.

Possible fixes, roughly by how contained they are

1. Re-prepare SQLite on every start rather than only on install. src/server-runner.js passes wordpressInstallMode: 'install-from-existing-files-if-needed', and the comment there says that mode "skips the download and still prepares SQLite". It appears to do so only when it decides WordPress is not installed, and after a build it decides it is. Keying the check on "is the drop-in present" rather than "is WordPress installed" would fix it wherever the files went.

2. Restore the two paths after a build. The app knows when it has run one. It could put them back the way Playground does: unpack sqlite-database-integration.zip from @wp-playground/cli, then write db.php from the plugin's own db.copy, substituting {SQLITE_IMPLEMENTATION_FOLDER_PATH} and {SQLITE_PLUGIN}. Worth knowing that {SQLITE_PLUGIN} appears three times and is used as a plugin basename against WP_PLUGIN_DIR, not as an absolute path.

3. Recognise it and say so. Even without a fix, a site that will not boot because its drop-in is missing could be named as that, rather than surfacing as a Comlink error. That alone is the difference between a five-minute recovery and a lost afternoon.

I tried (2) by hand and did not get the site booting again, so there is more to it than replacing those two paths. I am reporting what I have rather than a finished diagnosis, because I did not want to keep experimenting on a site somebody else has to use.

Environment

• WordPress Contributor Toolkit, a local build of trunk
• Windows 11
• WordPress 7.2-alpha, PHP 8.3.32
• @wp-playground/cli 3.1.47

Start with src/server-runner.js and the build path that replaces build/wp-content, then inspect how the existing SQLite integration is prepared or restored during startup. Reproduce the reported sequence with npm run build and a restart, tracing the missing db.php and plugin directory. Done means the rebuilt site starts normally and still reaches its SQLite database.