Dusk compatibility inventory

The engine is Dusk. Darkwind is the reference game built with it. This record lists the places where the old name intentionally survives, and the ownership targets for the rename. The plan is DUSK_IDENTITY_AND_REFERENCE_GAME_PLAN.

The rule is correct ownership, not zero search matches. Each old-name occurrence falls into one class:

1. Engine branding: changes to Dusk.
2. Darkwind game identity or content: stays Darkwind.
3. Compatibility or persistent identity: kept, because changing it would break saves, sessions, wire negotiation or retained builds.
4. Historical evidence, fixture or credit: kept with its factual meaning.
5. Incidental internal label: renamed only when a touched file makes it relevant.

#Retained compatibility identifiers (class 3)

#Operator settings

Every public setting has a canonical DUSK_ name and its legacy DW_ alias. The policy is implemented once, in deploy/dusk-env.mjs, and used by every service and launcher entry point (deploy/dusk-env-bootstrap.mjs), the container entrypoint, the health check, the Vite config and npm run compose:

1. Only one name present: use it. Presence counts, not truthiness, so empty and 0 are real values.
2. Both present with the same value: accepted.
3. Both present with different values: the process stops with an error naming both settings. Values are never printed.
4. Neither present: DUSK_DEFAULT_<NAME> applies. Images and the local Compose file use this for their defaults, so supplying either name overrides an image default without a false conflict.
5. After resolution, each process keeps only the DW_ name. Existing code, children and retained older engines read that name, and a launcher's own DW_ override never looks like a conflict.

Settings (each DUSK_X ↔ DW_X): ALLOWED_ORIGINS, ROOM_PASSWORD, ROOM_PASSWORD_REQUIRED, RELAY_PORT, HTTP_PORT, DATA_DIR, STATIC_DIR, ENGINE_BUNDLE, GAME_FILE, GAME_SOURCE, PLAYTEST, PHYSICS_BACKEND, EDITOR_TOKEN, PLAYER_ACCOUNTS, AUTHORING_WORKSPACE, DATABASE_URL, PERSISTENT_ROOM, HOST_PORT, WORLD_DOCUMENT, ROOM_TEMPLATE, ROOM_AUTHORITY, ROOM_PROGRAM, SPAWNED_PLACES, ROOM_ROUTES, ROOM_RSS_LIMIT_MIB, REGION, ROUTER_PORT, OPERATIONS_TOKEN, PLAYER_TRANSFERS, REMOTE_ROOM_HOSTS, ROOM_HOST_PORT, ROOM_HOST_CAP, ROOM_HOST_TOKEN, ROOM_SOCKET, ROOM_CAP, CONTROL_PORT, CONTROL_BIND, CONTROL_TOKEN, POSTGRES_PASSWORD, PHYSICS_TOKEN, PHYSICS_ENDPOINTS, PHYSICS_OWNERS, PHYSICS_CAPACITY, PHYSICS_ALLOW_INSECURE, BUILD_DATABASE_URL, BUILD_POSTGRES_PASSWORD, the BACKUP_* settings, ASSET_PROVIDER_KEY, ASSISTANT_PROVIDER_KEY, CROSSING_VEHICLES, CROSSINGS_DATA_DIR and the HOST_TOKEN_* family. Browser builds accept only VITE_DUSK_PLAYTEST ↔ VITE_DW_PLAYTEST. Test and fixture switches (DW_TEST_*, DW_*_CLIENT_DIR, DW_GPU_PROFILE, DW_BENCH_SECONDS, DW_TERRAIN_*) are not operator settings and keep only their DW_ names. PORT, PG*, NODE_ENV and Playwright options are unchanged.

Build arguments (Dockerfile): DUSK_PLAYTEST/DW_PLAYTEST and DUSK_GAME_SOURCE/DW_GAME_SOURCE. An empty build argument counts as unset; two different non-empty values fail the build.

Compose. The single-container profiles (compose.coolify.yaml, compose.beta.yaml, compose.ferry.yaml, compose.meridian.yaml, compose.yaml) pass both names through unset-preserving. The container resolves them, so DUSK_ names work in Coolify. Values these files fix (port 8787, /data, the static directory and the beta's required passphrase) stay fixed. A different DUSK_ value for one of them is reported as a conflict. The PostgreSQL multi-service profiles (compose.persistent.yaml, compose.rooms.yaml, compose.room-hosts.yaml, compose.cargo.yaml, compose.control.yaml, compose.builds.yaml) interpolate values into non-Dusk images (database passwords, URLs, host tokens), which YAML cannot conflict-check. In Coolify they keep their DW_ names. Locally, npm run compose -- -f <file> … resolves DUSK_ names first. The local host port follows the same rule: DUSK_HOST_PORT through npm run compose, DW_HOST_PORT with plain docker compose.

#Deployment and storage map

#Darkwind game identity (class 2)

Darkwind's world ID (darkwind), releases such as lantern-house.1.arrival-10, place, entity and interaction IDs, Elowen's story, the darkwind source import name in npm run author -- import darkwind, fixture names such as garden-ferry, and all of games/darkwind/ stay Darkwind.

#Ownership targets

#Explicit game-import exceptions

npm run check enforces these boundaries (HOST_GAME_BOUNDARIES in tools/cli/check-boundaries.ts), including type and dynamic imports:

• Reusable player (apps/player/): no module imports games/, except the trusted presentation registry apps/player/installed-games.ts.
• Services (services/): no module imports games/darkwind/, except the operator composition files services/relay/reference-worlds.ts, services/persistent/world.ts and services/routing/main.ts. The reusable createRelay factory requires an explicit world.

Not covered by that check, by design:

• Diagnostics fixtures that load named demo content: apps/probe/*, apps/physics-lab/main.ts.
• Tools, benchmarks and migrations about Darkwind content: tools/cli/*, tools/bench/*.
• Tests.

#Acceptance record

#R2 — Dusk tooling and engine UI (2/5)

The editor wordmark and title read Dusk World Atelier. Diagnostics read Dusk Observatory, and the physics page reads Dusk Physics Lab, with a "Dusk · owned solver" engine label. The player's F2 panel is headed Dusk Observatory, and the relay and control services print Dusk startup lines. Draft and capability downloads are named dusk-draft-N.json and dusk-capabilities.json; their contents are unchanged. Darkwind keeps its title, wordmark and approved traveler. Editor key, name and history storage keys are unchanged.

Checks (Node 22.23.4, /usr/bin/chromium): tsc --noEmit; owned-physics.spec.ts:2, editor.spec.ts:7 (draft export name) and editor-panels.spec.ts:29 (saved editor identity) pass. editor-panels.spec.ts:10 fails identically on the unchanged baseline under software rendering (#enter stays disabled), so it is pre-existing and is not a rename regression.

Captures (physical GPU, isolated data directory): editor · Observatory · Physics Lab · Darkwind.

#R3 — Explicit game presentation and host boundary (3/5)

The reusable player now hosts a game through GamePresentation (apps/player/presentation.ts), chosen by the trusted registry apps/player/installed-games.ts from the admitted world ID. Darkwind's story, welcome, objectives, journal, satchel text, sound, controls and approved traveler moved into games/darkwind/presentation.ts. Keeper-story detection was removed. Other games get the neutral Dusk presentation. The traveler profile reaches the main-thread renderer, the render worker (per created generation, so device recovery reuses it) and graphics revisions and portals. Shared default controls live in packages/input/defaults.ts. They keep the darkwind.player.1 map ID, because saved rebinding profiles are keyed by it. createRelay requires an explicit world. The relay picks reference worlds in services/relay/reference-worlds.ts.

Checks (Node 22.23.4): npm run check (types, boundaries including the new host rule, generated wire); native boundaries, player-graphics-revision, net, net-interest, relay-shutdown, static-notices, engine-pinning, playtest-release, game-sdk and development-room tests pass (35). Browser audio, gamepad and most of player.spec pass under software rendering. V7: tests/meridian-browser.test.ts (two-player puzzle, travel, reload and editor publication) passes on the physical GPU.

Pre-existing failures, identical on the R2 baseline af9087f under software rendering and not caused by the rename: 8 in player.spec.ts (including the 53 / 4 GPU allocation that predates the Vita traveler), 2 in simulation-recovery.spec.ts, 1 in portal-rendering.spec.ts, the jump hint in controls.spec.ts, and meridian-browser.test.ts with SwiftShader (#enter stays disabled). Recorded for follow-up, not fixed in this pass.

Captures (physical GPU): Darkwind welcome · Darkwind journal · Meridian world · Meridian journal.

Known bound: the static index.html is neutral ("Dusk") until the admitted game's presentation applies, so link previews of a Darkwind deployment say "Dusk".

#R4 — Commands, compatible configuration and deployment readiness (4/5)

npm run dev:darkwind starts Darkwind's polished arrival (same as dev:art, which remains). dev, dev:editor, dev:meridian and the other commands are unchanged. Launchers print "Dusk World Atelier (private)". npm run compose resolves DUSK_ settings before Compose interpolation. Every service and launcher entry point, the container entrypoint and health check, the Dockerfiles' build arguments and defaults, and the Vite config follow the policy in Operator settings.

Checks (Node 22.23.4): npm run build (check, player, workers, editor, server, author, accounts, retained engine) passes. tests/dusk-env.test.ts (10) covers canonical-only, legacy-only, equal, unequal (no values in errors), empty and 0, image-default provenance, HOST_TOKEN_*, the Vite pair, the entrypoint locking the resolved directory, the independent health probe following a canonical-only port, and a bootstrapped launcher's child reading the legacy name. deployment, editor, persistent-world-source and room-routing pass (24 PostgreSQL cases skipped). Builds with VITE_DUSK_PLAYTEST and VITE_DW_PLAYTEST produce the same ferry selection, and a conflicting pair fails the build.

Host smoke of the built production server through deploy/entrypoint.sh: canonical-only and legacy-only settings both start, lock the resolved directory, ignore the image-default directory and pass deploy/healthcheck.mjs. A conflicting passphrase pair exits 78 before locking, with no values printed. A copy of the existing .data/hearth room (revision 1) loads under DUSK_DATA_DIR, admits a traveler and keeps its signing key. The isolated arrival dev stack starts with DUSK_-only settings. Effective Compose configuration was inspected for legacy-only and canonical-only Coolify settings: the volumes are still darkwind-room and darkwind-arrival-v10 at /data. This is static configuration, not hosted restart evidence; Docker image builds were not run here.

Found and fixed during this milestone: the resolver's command-line guard matched inside bundled server entry points and exited the server. It now also requires its own filename.