Thunderous
Learning

The dev overrides nobody read

On 29 August we added two small files to the harness folder. .watchdog/hubprogress.json and .watchdog/itemvault.json replaced the Editor's save with a fixed one: 120 coin, eight items in the vault, no upgrades bought. Th…

On 29 August we added two small files to the harness folder. .watchdog/hubprogress.json and .watchdog/itemvault.json replaced the Editor's save with a fixed one: 120 coin, eight items in the vault, no upgrades bought. There was a good reason. The Editor and the headset keep separate saves, so over Link I couldn't see the progress I had made on the device, and the salvage flow couldn't be reached at all. The note written that day said to delete them when they stopped being wanted.

Nobody deleted them. For almost four weeks, every Play session over Link started from that fake save.

They did announce themselves

This is the part that stings. The overrides were built to be loud, on purpose, because fake progress that arrives quietly costs you a session wondering why a gate is open. Every session wrote these lines to the log:

[HubProgress] using the dev override in .watchdog/hubprogress.json: 8 rooms cleared, opened []. Delete that file to play the real save.
[ItemVault] using the dev override at .watchdog/itemvault.json, so this is not your real inventory.

That's clear, and it names the file and says how to get out. Nobody read it. The Editor log is long, and after every pass we read it for the lines we were looking for.

What it cost

Pass 14 on 25 September ran as two Play sessions, because the first hit the watchdog's timeout. That made the problem visible:

  • Salvage kept disappearing. I bought the salvage upgrade in the first session ("bought Salvage for 40 - bank 80"). In the second it was locked again, and I bought it again ("bank 98"). The override has no upgrades, so every session started without it. This is probably why, on 24 September, I complained that salvage "has not let me in any area". Probably: it was never proven for that day.
  • A wrong belief in the notes. The handoff had said my save owned salvage, so a fix to buying it could never be seen in a wearing. That came from a brief and was never checked. Reading the save afterwards showed an empty upgrade list and a bank of 138.
  • The real save was being overwritten. Whenever the game saved, it wrote progress that had started from the override. By the end of pass 14 the save read 492 coin, 17 rooms, salvage owned. The backup from before the pass held 138 coin, 14 rooms, no upgrades.
  • Four nameless salvages. Pass 14 logged four lines like salvaged from Vault for 50 coin, with a blank where the item name should be. Those were four longswords from the override's vault. The catalogue no longer has a longsword, and an unknown item has an empty label by design. That was stale data, not a code defect, and it had been sitting in my inventory all along.

What we did

With my go-ahead, both files were renamed to *.json.disabled (rename them back to use them). The pre-pass backup was restored: 138 coin, 14 rooms, no salvage. The four longswords were stripped from the vault save. Each was removed from the stored list and the cell map together, so every other item kept its square, and eight items were left. Every step has a registry backup in .watchdog/. The next pass started from my real save, with salvage locked until I bought it again.

What I take from it

A warning that goes to a log nobody reads isn't loud, and it didn't matter that the words were good. The override did exactly what its design asked of it, and it still ran for four weeks, because being loud depended on a reader and there wasn't one. The note that said "delete them when they stop being wanted" had no owner and no date, so it didn't really have an end.

The second lesson is smaller. The notes said my save owned salvage because a brief said so, and nobody opened the save to check until after the fix had merged. The save was the one thing that could answer the question, and it was the last thing anyone looked at.