2 Commits

Author	SHA1	Message	Date
wtclaude	baffaa46c9	feat(rust): identity — a link code from the game, and the Steam id inside core's user page ... R1's identity link, site-side, and R13's first extension slot. A player types /link in game, the plugin hands them a six-character code privately, and they enter it here; the site records who owns which Steam account, and an operator sees that on core's own `/admin/users/:id` page. **The site is the author of record and the game holds nothing.** There is no per-account store in Rust that survives a wipe, and phase 7 needs the site authoritative anyway — it pushes permissions INTO the game keyed by Steam id. A copy in the game would be a second thing to reconcile every wipe, for no question it could answer better. ## D24 — a code is minted by ONE server, so every server is asked Nothing in six characters says where it came from. The fleet is asked in turn and the first `link.ok` wins; the others answer `unknown` and nothing happens there, because a code is only spent at the server that actually holds it. Asking the player to pick was rejected: a wrong pick would come back indistinguishable from a wrong code, and that is the one refusal which must not be ambiguous. **"Every reachable server refused" is not the same answer as "a server was unreachable."** Collapsing them tells a player whose server is down that their code is wrong — so they run /link again on that same server and are told the same thing for as long as it stays down. `unsure` is that case, and it says to try again rather than to fetch a new code. ## D23 — a Steam id another account holds is refused, never moved The primary key is `steam_id`, and it is load-bearing rather than tidy: phase 7 grants permissions against a link and phase 13 hangs entitlements off it, so a silent move is an account takeover performed by typing six characters. The refusal names the holder, because the advice is unusable without it. The INSERT is a plain INSERT for the same reason — `ON DUPLICATE KEY UPDATE` here would BE that move — and the duplicate-key error is the refusal for the race the check above cannot close. The way out is `/unlink` in game, which reaches the site off the ingest feed rather than through a route (the plugin has no link to delete). D25 adds the other way out: staff can sever a link from the admin panel, for a player who cannot reach that Steam account in game. ## The slot, and the hole it found in this repo's own generator `admin.users.detail` is declared in `module.json` AND registered in `index.js` AND filled by the chunk — three places, because the server half and the client half are different registrations that share one name. `swaggerFragment.js` knew only about tier routers, so the two routes under `/admin/users/:id` were generated by nothing: a fragment that was internally consistent and described two routes fewer than the module serves. A slot's mount is core's and cannot be derived here, so it is a fourth constant beside `TIER_BASE` — held to account by the frozen-manifest job, which was verified to catch exactly this by removing the two paths and watching it fail. ## Smaller things worth knowing - **Core's `useAsync` has no `refresh`.** A counter in the deps is how a page re-reads after its own write; it blanks while it re-reads, which is right here and is exactly what made it wrong for a poll. - **Every player-portal nav row needs an `icon`** — core draws one on every row, and the client suite says so. This module had no icons file until now, because the public header is text buttons. - The two new frame kinds are STAFF-only. Neither carries a code, but both name a Steam id beside a website account's activity, and that join is not a public fact about what happened on a server. - The link code route carries its own rate limiter rather than core's `accountChangeLimiter`: this is guessing somebody else's secret, not changing your own password, and a shared counter would let one policy set the other. Protocol 3 on all three declaration sites; 17 new tests, 136 green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMH6bw1jXMgbyF3ZWGEzSM	2026-09-21 08:18:48 -05:00
wtclaude	862c328176	feat: the module skeleton and every bundle seam ... module-rust, id 'rust', built from the Integration Kit's template. Phase 1's job is the kit's own argument: get every seam working at once with almost nothing in them, so that afterwards you break exactly one at a time. What is here: * /rust on all three tiers, because the loader holds module.json's mounts against what is registered in BOTH directions -- so the declaration and the registration land together or not at all. The player tier is honestly thin: it answers the server list on the authenticated tier, delegating to the same model the public tier uses so the two cannot drift while they are meant to be the same. It is the address the app will call, registered now rather than moved later. * Two tables. rust_servers is configuration an operator writes; rust_server_state is what a sidecar reported. Separate tables because they have different writers, lifetimes and audiences -- and because purging observed state while keeping the configuration is a thing an operator will want. * Per-server sidecar tokens through ctx.secretBox, write-only in the API. The admin list reports hasToken and never the credential, and an empty token on a save leaves the stored one alone -- a form that posts its own blank field would otherwise erase a credential every time somebody renamed a server. * A real sidecar client. It never throws: every call answers {ok, status, data}, and the status is what tells a wrong URL from a wrong token from a mismatched protocol -- all three present as 'the site says my server is offline' and each has a different fix. * The five guards, green: check:imports, check:swagger, check:externals, and both suites. What is deliberately NOT registered: the Team provider, triggers, audiences, engagement seeds, notification streams, the four event catalogues, and the two extension slots. Each arrives with the phase that has something real to put in it, and a test asserts their absence so that removing it is deliberate. A declared trigger nothing emits and a declared slot nothing fills are both surfaces an operator can configure and then wait on, which is worse than an absent one because the absence is visible. Two corrections to the kit's template, both feedback for a later phase: * registration.test.js read one page BY NAME to check declared slots are rendered, so a module declaring none dies on ENOENT before reaching the loop that would have been empty. It now scans every file under src/routes. * test/_fakes.js supplied validator: {}. An admin router that builds validation chains at file scope cannot be required with that, so the fake holds the real express-validator -- for the same reason it holds a real express Router. The kit was right about noGameConnection.test.js: its header predicts that a module adding a sidecar client will see the check go red, names sidecarClient.js as the file to allow, and says narrow it rather than delete it. That is exactly what happened on the first run, and the fix was the one line the header names. Installed into a real core and verified: the module reaches 'started', publishes its capability, serves its chunk, and renders a server whose server.hello originated in a live Rust server. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4	2026-09-15 19:54:08 -05:00