Revision r3 — ready
Shared design contract: bytefolk/design-system#29 (revision r1).
The user refined this ongoing appearance task: all clients must share the existing design language and align content by its role, rather than center all short text. Totoro (@Bindy-lbb) is the requested final reviewer.
Current acceptance (supersedes earlier alignment wording)
- AC-ALIGN: Start-align page/card/dialog headings, navigation, menus, form labels/values, filenames and prose. End-align comparable numbers and trailing metadata/actions. Center button content, compact badges/tabs and deliberate empty-state compositions. Remove blanket overrides that defeat component intent.
- AC-EMPTY: One clear empty-state title, concise explanation and an available next step; no duplicated instructions or unsupported actions. RoleWeave specifically improves the unselected local-conversation state.
- AC-THEME: Preserve previous theme/contrast fixes and consume existing shared tokens/provider/profile APIs. Follow the shared spacing, typography, radius and hierarchy contract.
- AC-VERIFY: Build and inspect light/dark, desktop/narrow, empty/populated, normal/hover/focus states. Use isolated test data. Keep reproducible evidence, independent preflight and latest-head CI separate from formal human approval.
- AC-DELIVER: Update the existing unmerged PR with scoped source, changelog and evidence. Show the final local client; request Totoro review once stable. No merge, release or installed-client replacement.
Revision history
r3: semantic alignment and coherent empty states requested by user; append-only requirement decision recorded at 2026-09-16T01:18:12.677003+00:00.
Previous revision retained for scope and evidence history
Revision r2 — ready
The user requested a complete client appearance walkthrough, successful local build, and a pull request. Theme state is not consistently bridged to shared components; link buttons can lack button styling, and some admin/published surfaces retain hard-coded light colors.
Scope and acceptance criteria
- AC1: Shared components follow the resolved light/dark theme across public, authenticated and admin layouts.
- AC2: Anchor buttons and normal/hover/disabled controls retain readable semantic foreground/background combinations; use existing shared design tokens.
- AC3: Controls and short UI titles align centrally at narrow/desktop widths, without changing editor/document reading alignment.
- AC4: Walk through public/authentication pages and controlled populated admin/published/editor component states; do not mutate real documents.
- AC5: Lint, focused regressions, browser appearance checks and the actual production build pass. Fix narrowly scoped test typing obstacles needed for the build without weakening checks.
Delivery
One appearance PR with an Unreleased changelog entry, reproducible evidence ledger and independent preflight review. Temporary fixture routes, private paths, private walkthrough screenshots and build outputs must not be committed. Existing synthetic Linux sign-in screenshot baselines may be updated when required by the intended appearance change, after comparison on Linux and a successful run without snapshot updates; assertions and thresholds must remain unchanged. API/schema/authentication semantics and release operations are outside this visual correction.
Revision r3 — ready
Shared design contract: bytefolk/design-system#29 (revision r1).
The user refined this ongoing appearance task: all clients must share the existing design language and align content by its role, rather than center all short text. Totoro (@Bindy-lbb) is the requested final reviewer.
Current acceptance (supersedes earlier alignment wording)
Revision history
r3: semantic alignment and coherent empty states requested by user; append-only requirement decision recorded at 2026-09-16T01:18:12.677003+00:00.
Previous revision retained for scope and evidence history
Revision r2 — ready
The user requested a complete client appearance walkthrough, successful local build, and a pull request. Theme state is not consistently bridged to shared components; link buttons can lack button styling, and some admin/published surfaces retain hard-coded light colors.
Scope and acceptance criteria
Delivery
One appearance PR with an Unreleased changelog entry, reproducible evidence ledger and independent preflight review. Temporary fixture routes, private paths, private walkthrough screenshots and build outputs must not be committed. Existing synthetic Linux sign-in screenshot baselines may be updated when required by the intended appearance change, after comparison on Linux and a successful run without snapshot updates; assertions and thresholds must remain unchanged. API/schema/authentication semantics and release operations are outside this visual correction.