Zareian
5003b8a852
A shared guest account was hand-seeded into the production DB on 2026-09-22 so the frontend developer could see the notification and leaderboard screens before any real traffic exists: deviceId "frontend-test-device", user 6, with 24 Notification rows and 20 LeaderboardEntry rows across both periods, ordered differently per period so the ?period= parameter is visibly doing something. None of that was recorded in the repo. db.sqlite3 is gitignored, so the account existed only in the head of whoever set it up — exactly the kind of thing that disappears at a handoff. It is now in docs/frontend/README.md, where the frontend developer looks, and in docs/operations.md, where whoever runs the server looks. Verified against production before writing it down: the account still resolves to user 6 with isNewUser false, notifications return rows, and both leaderboard periods return six entries. The notifications payload is keyed "items", not "results", which is noted because it is easy to read as an empty response. The operations entry carries the warning that matters: this is hand-written data in a production database, purge_demo_data will not catch it (it only matches [SEED]/[DEMO] prefixes on Grade/Plan/Character/User), and it has to go before real users arrive or they will see invented notifications. The Swagger description now says a deviceId can be any string and that pre-seeded ones exist on request, but deliberately does not print the specific value: /api/docs/ is reachable from the public internet, and a public API reference should not advertise a shared account that anyone can sign into. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
43 KiB
43 KiB