docs(modules): record the cutover, and retire what it makes untrue
The module system reached `main` on 2026-08-12 (website#150) and `edge` was deleted. Several present-tense claims across two plans became false at that merge; this is the pass that closes them. MODULE_SYSTEM.md's status banner was the loudest: it still announced "in implementation - Phase 2's core scaffolding is landing, PRs 1-7 of 9 done", three phases stale. It now says SHIPPED and gives the shape of what landed. The substantive addition is 2.9's "as landed" section: the four decisions that settled the cutover (none of them a code question), and what the merge does to a LIVE deployment - no DROP TABLE anywhere, one guarded and already-verified column drop in 228 changed files, no newly-required env var, and a declared module starting on the same first boot rather than waiting for an operator click. That paragraph is the one a future cutover will want, and none of it was written down anywhere before. Phase 5 is marked COMPLETE in the phase list (2.11.1 already recorded slice 3 closing it), decision 11 carries its landing date, and 2.11.1's "the pin is one of the things the cutover has to revisit" is resolved in place - the sha did not move, only the branch label, so the coreApi equality assertion stays armed. The Android note is the one that changes meaning rather than tense. It said the `gameAccountSignup` fix "must land before that cutover"; the org lead released that gate instead, so the note now records a LIVE regression - the shipped app hides game-account creation from every user - rather than a scheduling item. An accepted break and a forgotten one differ only by whether someone wrote it down. Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
@@ -110,6 +110,19 @@ spec-aligned (as recorded for M1); 17 new JVM unit tests cover the account + pla
|
||||
> Deferred rather than coordinated into the slice (org lead, 2026-08-11): the website work lands on
|
||||
> `edge` and reaches `main` as one cutover, so there is room. **It must land before that cutover** —
|
||||
> after it, a shipped app quietly loses a feature.
|
||||
>
|
||||
> **The gate was released and the cutover went first (org lead, 2026-08-12.)** The module-system
|
||||
> cutover merged as [website#150](https://gitea.whitlocktech.com/RunicGateway/website/pulls/150)
|
||||
> with this unfixed, deliberately: the app needs a broader pass than this one field, so holding a
|
||||
> finished workstream for it bought delay and nothing else.
|
||||
>
|
||||
> **So this is no longer owed-but-harmless — it is live.** Against `main`, `/public/settings` no
|
||||
> longer carries `gameAccountSignup`, `PublicDto.kt:80` reads its `false` default, and
|
||||
> `CharactersViewModel.kt:72` hides game-account creation from every user of the shipped app. Nothing
|
||||
> crashes and nothing logs; the button is simply not there. The fix is unchanged — one DTO field, one
|
||||
> ViewModel line and two tests, reading the flag from `/public/shard/features`, which the app already
|
||||
> calls — and it is now a **bug fix against a live regression** rather than a scheduling item, to be
|
||||
> picked up with whatever else that broader app pass covers.
|
||||
|
||||
✅ **M5 — design pass** (2026-07-20, `RunicGateway/Android-app#10`): the shard-website theme applied
|
||||
across every screen, restyling the working M1–M4 UI with **no architecture, data-flow, endpoint, or DTO
|
||||
|
||||
Reference in New Issue
Block a user