Repository source: docs/plans/ui_redesign/implementation_checklist.md
UI redesign: implementation checklist
A backlog of cycles for building the redesign and its theme from the mockups. It is a planning input, not a Railspike artifact. Each cycle is marked with the process it uses (see below); Railspike cycles still go through Railspike's steps with an explicit approval at each gate, and may be reshaped during their own Step 1 or Step 2. Context and decisions are in next_steps.md.
Process per cycle
Decided by the user on 2026-10-26. The mockups and this checklist already
cover much of Railspike's problem framing and requirements, so Railspike is
kept where there are real unknowns or high stakes. Marking a cycle Direct
is the user's explicit Railspike opt-out for that cycle under AGENTS.md.
| Process | Cycles | Reason |
|---|---|---|
| Railspike (start with Step 1, solution assessment) | 1, 5, T1 | Open design choices: a new navigation surface across every theme (1), key generation and signing (5), registering a day/night theme (T1). |
| Railspike, no Step 1 (start with Step 2) | 3, 4, 8, T2, D1, D2, D3 | Clear direction but risky behavior: the docked reply box on phones, backups, encrypted message failures, hooks into decryption and verification, read-model schema changes, security UX. |
| Direct (no Railspike) | 2, 6, 7, 9, T4 | Rearranging markup and wording on screens whose behavior already exists, or a small settings change (T4). |
| Decide when scheduled | T3, D4 | Optional or deferred. |
For a Direct cycle:
Work on its own branch (no direct merges to
main).Use this checklist's items for the cycle as the spec; record any change of scope here rather than silently expanding it.
Apply every check in Checks that apply to every cycle, and record UI verification in
docs/plans/ui_copy_audit_checklist.mdor a short note in this folder.Commit when the cycle's "Done when" is met. Direct cycles are not part of the
railspike-effortstudy, which only collects Railspike cycles.
Sizing follows Railspike's rules for every cycle, Direct ones included: each is a releasable vertical slice (normal entry, end-to-end outcome, required recovery) that fits within a day or eight Step 3 stages. The item lists below are suggestions for Step 3 (or the spec, for Direct cycles), not approved plans.
Mockup references are relative to mockups/. Template paths are from plan_prompt.md.
Before the first cycle
Checks that apply to every cycle
Copy these into each Railspike cycle's Step 3 verification and Step 4 summary; Direct cycles apply them before committing.
Phase 1: Base structure
Wording, arrangement and flow from round 1, theme-independent. Each cycle also adds its screen's theme hooks.
Cycle 1: ui_shell_navigation
Process: Railspike. Step 1 compares options: the phone tab bar is a new navigation surface, and moving rare destinations into the account menu has alternatives.
App shell and navigation. Mockup: shell.html. Templates: templates/layout.php,
templates/partials/nav.php, templates/partials/theme_menu.php.
Done when: every page uses the new shell in every theme, with no lost destination.
Cycle 2: ui_board_list
Process: Direct.
Mockup: board.html. Templates: pages/board.php, partials/thread_card.php.
Depends on cycle 1.
Done when: browsing, filtering, sorting and paging work in all themes.
Cycle 3: ui_thread_reply_dock
Process: Railspike, no Step 1.
Mockup: thread.html. Templates: pages/thread.php, partials/thread_root_card.php,
partials/post_card.php, partials/reply_form.php. Depends on cycle 1.
Done when: reading, liking, replying and the agent states work on phone without the keyboard hiding the reply box.
Cycle 4: ui_account_states
Process: Railspike, no Step 1.
Mockup: account.html. Template: pages/account_key.php.
Done when: a member can see their state, back up, restore and reach advanced controls in all themes.
Cycle 5: ui_first_post_identity
Process: Railspike. Step 1 compares options for when and where keys are generated.
Mockups: compose-thread.html, account.html. Templates: pages/compose_thread.php,
partials/thread_compose_form.php, pages/account_key.php, plus the browser
signing scripts. Depends on cycle 4.
Done when: a new visitor can write and publish a first post with no browser dialogs and no long wait after pressing Post.
Cycle 6: ui_composers
Process: Direct.
Mockups: compose-thread.html, compose-reply.html. Templates:
pages/compose_thread.php, pages/compose_reply.php. Depends on cycle 5.
Done when: new threads and replies post from both pages, with and without JavaScript.
Cycle 7: ui_profile_users
Process: Direct.
Mockups: profile.html, users.html. Templates: pages/profile.php,
pages/username.php, pages/users.php.
Done when: finding a member, opening their profile and messaging or approving them works in all themes.
Cycle 8: ui_messages
Process: Railspike, no Step 1.
Mockups: messages.html, conversation.html. Templates: pages/private_messages.php,
partials/private_message_list.php, pages/private_message_conversation.php,
partials/private_message_composer.php.
Done when: reading, sending and recovering from each failure work on phone and desktop.
Cycle 9: ui_tools_launcher
Process: Direct.
Mockup: tools.html. Templates: pages/tools.php, partials/tools_nav.php.
Done when: every tool is reachable once, in all themes.
Phase 2: Theme hooks
There is no separate cycle. Hooks ship with the base cycle for their screen (listed above). Before Phase 3, confirm the full set exists:
Phase 3: The theme
Ma was chosen (2026-10-26) and ships opt-in. Living Sky (T3) is optional and unscheduled.
Cycle T1: ma_theme_day
Process: Railspike.
Ma in light mode. Step 1 decides how a theme with a day and a night look
is registered (one auto theme that follows the system, or separate "Ma" and
"Ma Night" entries), given ThemeRegistry's one-mode-per-theme entries.
Done when: Ma can be chosen from the theme menu and every redesigned screen renders correctly in it on phone and desktop.
Cycle T2: ma_theme_night
Process: Railspike, no Step 1.
Ma's cyberpunk dark mode. Depends on T1.
Done when: night mode renders every redesigned screen with the night contrast values met (cyan 12.6:1, neon 5.4:1, muted text 5.7:1 or better).
Cycle T3 (optional, unscheduled): living_sky_theme
Process: decide when scheduled.
Done when: Living Sky is selectable and scrolls smoothly on the test phone.
Cycle T4: ma_theme_default
Process: Direct.
Only when we decide Ma is ready to become the default (decision 2: opt-in until then).
Done when: new visitors get the new theme and existing choices are preserved.
Phase 4: Features that need data
Each needs its own product decision before its cycle starts.
Cycle D1: community_pulse
Process: Railspike, no Step 1.
Cycle D2: profile_constellation
Process: Railspike, no Step 1.
Cycle D3: post_seals
Process: Railspike, no Step 1. Step 2 must state the security rule: a seal appears only after verification succeeds.
Cycle D4 (deferred): fingerprint_colors
Process: decide when scheduled.
Not yet planned
Decided against or deferred on 2026-10-26: Unlike (not implemented), Undo after Approve (skipped), offline message queue (deferred), hiding Tools groups the viewer cannot use (deferred), fingerprint colors (cycle D4, deferred).
From the graded idea list in visual_direction_notes.md, still unbuilt even as mockups: time-of-day sky (A4), planet flight between screens (A5), kintsugi for edits and resends (B3), the closing ensō for reply progress (B1), riso meme thumbnails (B6, risky), and bolder titles for busy threads (B7, needs font approval). Add a cycle here if any is chosen.