Creator reward and Granny production rollout

Launcher 0.1.39 enables the accepted Granny purchase-tab and creator inventory-refresh code without experimental environment flags. Native SHA-256: 6f2433abebdee451edfc9060fa58eb3e2a3e73e5f7063de05386316b52d7b30b. The client, friend-kit and Windows server-kit pins agree. No test-account fixtures, quest completions, account unlocks or inventory grants are part of deployment.

Void grants 10000 ordinary Rams once per account. The permanent account receipt and inventory grant commit atomically, including across competing backend processes and character switches. The authenticated account controls the recipient; request account IDs, quantities and source strings cannot authorize grants. GET is read-only. Invalid authentication/codes, repeats, malformed inventories and unsafe native integer balances cannot consume another reward.

Granny keeps the game’s quest requirements, recipe prices, crafting handlers and native server transactions. Only initialized potion tabs are shown. The shared backend now always refuses an excessive CURRENCY_NOTES debit, even if legacy material clamping is enabled: a stale native balance cannot grant a tonic after funds run out. Other material behavior is unchanged. The isolated accepted gameplay audit recorded 18000 Rams spent, 40 purchased items and 10 crafted items with matching material removal.

Validation: 130 focused backend tests and the full 817-test backend suite pass, including simultaneous purchases with funds for exactly one, request replay, forged raw inventory mutations, creator claims from independent processes and native integer limits. The full run exposed stale Nova test assumptions: a suspended account cannot mint a fresh JWT, and its old token is rejected with401. Tests now retain the pre-ban token and use authenticated server reads to verify unchanged inventory. No production behavior was relaxed. Launcher typecheck passes; 305 launcher tests pass and 3 are skipped. Release x64 DLL, Windows installer and packaged two-start offline isolation smoke test pass. Native DualSense, console visibility, Rams protocol, locale and privileged RPC guard tests pass. Repository secret/game-file checks pass for tracked files and the pending canonical-branch history.

Deployment artifacts are staged under each host’s staging/creator-granny-20261018. Backend patch scope is routes/store.js, controllers/creator.js and controllers/inventory.js, with existing helper/rate-limit dependency hashes verified. No schema migration is needed. Deployment scripts verify old/new hashes, back up source, and roll back source on restart or health-check failure.

Existing native game images can remain mapped while [IO.File]::Replace atomically installs the new DLL and saves the old image. This was verified against a loaded isolated test DLL. Only exact Ramsgate-map processes are recycled for the vendor feature; allocator services and other game processes are not stopped. In-flight hunts retain their prior image until they exit normally.

Preflight found the live database approximately 25GB with only 24GB free on C:. An external-connection backup was stopped before activation. A subsequent writer-owned /internal/backup attempt into an NTFS-compressed directory exceeded the caller’s response-header wait while the server kept copying. It did not provide a verified fresh copy before activation. Do not treat an HTTP client timeout as proof that the copy stopped.

Deployment used the existing backups/2026-10-18_030003/undaunted.db recovery copy: SQLite schema and table reads succeed, its file length matches page_count*page_size, and it contains8209 users/7657 characters versus8275/7717 live at the check. A full quick_check scan was stopped to avoid competing with live disk I/O; this was not a full integrity verification. The source-only patch has no schema migration. The production database was not vacuumed, replaced or restored. Incomplete backup attempts were discarded only after their processes closed and files could be opened exclusively.

Launcher 0.1.39 is published for Windows and Linux, and the rolling self-update feed was updated successfully by GitHub Actions run39099038926.

Authorized disk cleanup removed129 closed, unchanged files totaling42880120765bytes: rotated logs older than48hours, the leftover installation ZIP, and obsolete source/deployment ZIPs. Three discarded incomplete backup files added744244224bytes, giving132 files/43624364989bytes removed in total. Each absolute target was constrained to C:/DauntlessRevived, checked for links and changes, and opened exclusively before deletion. No in-use files were skipped. Final sampled free space:67393503232bytes. The live database, complete recovery copy, live game files, account data, credentials and recent diagnostic logs were retained.

Activation and verification

The three checked backend modules are installed. Source rollback copies and the recovery-copy reference are in C:/DauntlessRevived/backups/creator-granny-20261018-061826. Restarted only metagame; hunt allocators and their game children were not restarted. Final checks: backend discovery200, native authenticated creator GET200, unknown creator code404, unauthenticated claim401, owner receipt unchanged. No real player’s reward was consumed by deployment verification. Public gateway TLS pin check passed; the live status reported218 players and chat listening on127.0.0.1:61099.

All four game hosts have native SHA256 6f2433abebdee451edfc9060fa58eb3e2a3e73e5f7063de05386316b52d7b30b. Atomic replacement retained existing image mappings. Recycled only exact Ramsgate processes: main EU3, US3, Germany2, EU overflow0. The88 other game worlds captured during activation were not stopped. Normal hunt completion subsequently reduces those original PID counts.

Read-only process checks found the vendor feature detour installed in20 newly launched worlds across the four hosts, including replacement Ramsgates on main EU, US and Germany. No captured old Ramsgate PID remained. Live UI purchase and reward acceptance was established earlier in the isolated game test; production verification checks deployment, native hook activation, HTTP authorization/error paths and service health rather than making purchases or granting currency to players.