https://gitlab.synchro.net/main/sbbs/-/commit/bf13f8b7ef20527e27b1868f
Modified Files:
docs/superpowers/specs/2026-08-02-syncretro-save-restore-design.md exec/load/door_deploy.js syncretro_lib.js syncretro_lobby.js src/doors/syncretro/LAUNCHER.md M3_MULTICORE.md
Log Message:
syncretro: stop stating one BBS's storage topology as a general fact

Several files asserted that the install and data_dir are an SMB mount shared with a second host. That is true of one system and of no other by default,
and it was being used as the premise for design decisions in documents and comments a sysop reads to understand their own install.

The decisions were right; the reasoning was overstated. A Synchronet install CAN be shared by more than one host and CAN sit on a network filesystem, and that possibility is enough to justify an append-only activity log, a derived cache that tolerates a lost update, and a deploy that refuses to rename over
a running binary. Each now rests on that rather than on one site's layout.

The measurements stay, framed as what they are: a remote Windows node paying
a round trip per cartridge, CIFS reporting an mtime a second off from the
local view, a rename onto an executing file deleting the target and then failing. Those are observations worth keeping, and worth not generalizing
into claims about every BBS.

Also drops the same premise from the suspend/resume design, where it was load-bearing for a claim that did not need it: an arcade cabinet's high-score table is already lost to a concurrent player on any install, with no network filesystem involved, because two nodes on one machine are enough.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/bebebc90a9cbfc35002b3079
Modified Files:
docs/superpowers/specs/2026-08-02-syncretro-save-restore-design.md exec/load/syncretro_lobby.js exec/tests/syncretro_config_test.js src/doors/syncretro/DESIGN.md README.md syncretro_door.c xtrn/syncarcade/README.md xtrn/syncivision/README.md xtrn/syncnes/README.md
Log Message:
syncretro: document suspend/resume and fix its test data-dir leak

Task 6 of the save/restore plan: player-facing docs for all three
console packages, -state documented beside -home in the door's own
README and DESIGN.md, and four corrections earlier tasks surfaced.

- Drop the "-state auto derives the key" promise from the door's
usage text and the design spec's permission table. It cannot be
derived where -state is parsed: sr_door_state_key() is populated
during argv parsing, before sr_config_apply(), rc_core_open() and
option resolution give it anything to hash. A bare "-state auto"
still works exactly like any other key -- it just names the file
literally "auto" rather than deriving anything.

- Give syncretro_lobby_init() a spec.data_dir override (default
system.data_dir), and route every data_dir-derived path in
syncretro_lobby.js (the core-hash cache, the shared/private -home,
the plays log) through it. exec/tests/syncretro_config_test.js now
points it at system.temp_dir, so a test run -- pass or fail -- can
no longer write into the live install's data/. This replaces
cleanup calls that only ran on the success path, which is exactly
the run a regression test needs to survive.

- Fix the cabinet toggle's documented hotkey: the design spec's
mockup still said "(P to switch)", but P is the lobby's existing
Prev-page hotkey, so the shipped code correctly binds C instead.

- Reword the cabinet lines so both read as a rule rather than a
status: "No saved games." parses on a fast read as "none saved
yet" rather than "you cannot save here", which costs a player the
game they believed was saved.

Verified: all 11 ctest suites pass; all five JS suites (syncretro_state_test.js, syncretro_config_test.js, and the three test_shipped_ini.js files) report 0 failures. Confirmed by directory
listing that a full test run leaves /sbbs/data/syncretro/ unchanged.
Confirmed by grep that every -home/save_dir use in main.c and
syncretro_state.c is a destination (NULL-checked, formatted into a
path) and never a comparison or pattern match against the path
itself.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net