World Seed

A browser extraction game built on a signed identity, generated worlds and a permanent ledger. Saves live in a SQL database on a small local server, and private keys stay in the browser.

npm install

npm run dev

npm test

npm test runs three passes: everything in parallel, then the grid's speed bars alone (npx vitest run tests/speed), then the database's own files (npx vitest run tests/database). The speed bars time the machine when a hundred files run beside them, and the database files load it.

npm run dev brings up the game and its database with one command: Postgres in process (PGlite) on the folder data/test-claude, created on first run and never committed, so nobody installs a database to play. The first load on a browser origin that holds old saves imports them, after verifying their signatures. If the database is not answering, the game refuses to open rather than guess.

One process holds a database folder at a time. A second dev server in the same checkout is told so in the game and in its log; give it its own folder with WS_DATABASE_URL=pglite://<folder>. A killed server loses nothing it acknowledged. A folder does not survive a power cut as a served database does: PGlite never forces a write to the disk.

A save from before the move is a SQLite file, and it is never opened or changed by itself. If the game finds one with no folder, its vault offers CARRY THIS SAVE OVER, which needs no account. It takes the file with its log beside it, writes a new folder, checks every row, and leaves the old file as it is. By hand, it is:

npm run db:carry -- data/test-claude.db data/test-claude

The CARRIED line and the .carried.txt receipt beside the folder are what say it worked, because they say what was checked.

The record

Postgres runs the live game. Turso holds the record (D133): a commit lands on Postgres and never waits on the network, and at a downtime (a world's gate going down, maintenance, a clean stop) everything changed goes up as one write-down, whole, once, and read back before it counts. A new database for that game comes up from the record.

Only npm run pedro keeps a record, so npm run dev and test servers never write into it. It reads TURSO_DATABASE_URL and TURSO_AUTH_TOKEN from the root .env. With neither, or with Turso not answering, the game plays on and says so once, and what has not gone up stays marked until it can. To send an old save straight up instead of to a folder:

npm run db:carry -- data/test-pedro.db --to-record

Pedro's own game has its own database and its own port, so a test session can never touch it:

npm run pedro

That plays on data/test-pedro at http://localhost:3200. It first syncs the shared base with test-claude: the definitions, every item's history and the registry of claims, in both directions, and nothing that belongs to a character. If a server is running on either folder the sync cannot run: this says so and plays on. npm run db:sync runs the sync alone, and fails if it cannot.

The same game in a window of its own, outside any other program's browser:

npm run pedro:window

That builds the game, serves it from the runner at the same address, and opens it in a Chromium browser already on the machine (Chrome, then Edge, Chromium, Brave) as an app window: no tabs, no address bar, no extensions, and a profile folder of its own, data/window-pedro. Nothing is installed. Closing the window stops the game cleanly, with the write-down in it.

• The profile folder holds the key of any character made in that window. Deleting it deletes them, as clearing a browser's data does. A character made in another browser comes over with the game's own BACKUP, then RESTORE A BACKUP in the window.
• npm run pedro -- --window is the dev server in the same window, on the same profile, for when a change should show without a rebuild.
• WS_BROWSER names another browser. WS_WINDOW_ARGS adds flags of your own, such as --start-fullscreen.
• A window that ends in under three seconds is taken as handed over to one already open on the profile: the game stays up, and says so.

To run the built game standing alone, on a folder or on a served Postgres:

npm run build

npm run serve

npm run serve listens on port 3900, and reads WS_DATABASE_URL (pglite://<folder> or postgres://…), WS_RECORD=1 to keep a record, WS_PORT and WS_HOST. It has no authentication, so it answers this machine only. A real deploy needs a login in front of it first.

The game runs on http://localhost:3000. The proof pages are under /prototype/atoms/ (index.html, hub.html, room.html). A newcomer's first order is the tutorial world, which stays open while their own world is written.

The voice

Everything the game asks a model goes through one door on the server (server/intelligence/), never from the browser. A person picks how it answers, under SYSTEM:

• auto: the server's own key while there is one, the local model while there is none.
• local: a model on the person's own machine, through Ollama (WS_LOCAL_URL, default http://127.0.0.1:11434; WS_LOCAL_MODEL). Any served model may be picked. Gemma 4 (gemma4:e4b-it-qat, or e2b on a smaller card) is only the suggestion.
• keyed: a free option on the person's own key, read from server/intelligence/door-options.json (WS_DOOR_OPTIONS names another file). The key stays in the server's memory and is never sent back.
• off: every door still answers, and the game goes on with no voice.

Before it offers local, the game checks the machine: whether a runtime is there and running, the card and its memory, RAM, and the models served. It then says plainly RUNS HERE, CAN RUN HERE or NEEDS A KEY. TRY times one question on a chosen model. The check never blocks a choice.

This is the beginning of the README. Read the rest at the original. Read the full README ↗