ElyOffice/tasks/reviews/C05.1-r1.md

FAIL

Checked: cargo test -p ely-ui -p ely-platform passes (ely-ui 6 unit tests, ely-platform 10 + 12 + startup_panic). tests/scripts/theme.sh passes on macOS. cargo clippy --all-targets on both crates is clean. The three fixtures match themes/{tokyo-night,catppuccin-latte,white}/colors.toml in basecamp/omarchy at f45461a, so the "real palettes" claim holds. Contrast numbers below come from a probe crate outside the repo that #[path]-includes omarchy.rs and calls parse on the fixtures.

1. crates/ely-ui/src/theme/omarchy.rs:73 (and the test at :244) What is wrong: readable and toward_bg lift text only against bg. The test also checks only against p.bg. The components put this text on surface, sunken, hover, active and selection, which are mixed toward fg, so the lifted colors drop below 4.5 there. Ely's own palettes stay at or above 4.5 on every one of those surfaces except selection. The TASKS line ("全部正文色达 4.5:1") and agents.md ("每个正文色拉到 4.5:1") claim more than the code does. Failing scenario: catppuccin-latte gives fg_muted on surface 4.35, fg_subtle on surface 4.30 and on active 3.70. tokyo-night gives fg_subtle on surface 4.20 and on active 3.44. white gives fg_subtle on sunken 3.98. shell::OfflineIndicator (status.rs:128,133) draws fg_muted on surface, so under catppuccin-latte its label reads 4.35:1. Fix direction: lift each text token against the darkest or lightest surface it is drawn on (bg, surface, sunken, hover, active), not just bg. Extend the test to assert every text token against each of those surfaces.

2. crates/ely-ui/src/theme/omarchy.rs:75-84 What is wrong: only the named keys (red, green, blue, …, selection) are read. Omarchy v4's own colors.toml format also carries color0..color15, purple/bright_purple and selection_background. Omarchy's resolver (bin/omarchy-theme-color) aliases red→color1, green→color2, yellow→color3, blue→color4, magenta→color5/purple, cyan→color6, and selection→selection_background. omarchy-theme-colors-from-alacritty writes only accent, selection, background, foreground and color0..color15. Every theme without its own colors.toml (for example a user or git-installed theme that ships alacritty.toml) therefore reaches Ely in that form. Each missing hue then silently becomes Ely's default through unwrap_or(p.danger) and the like, with no log line. That is a default value hiding missing data (rule 2), and the theme is not synced. Failing scenario: parse a generated file (accent, selection, background, foreground, color0..color7 from Tokyo Night). The probe shows palette.danger == Palette::dark(false).danger and success equal to Ely's default. Syntax keyword comes from Ely's chart, not the theme's color5. Danger, success, warning, info, chart, ANSI and syntax colors all show Ely's palette under an Omarchy theme. Fix direction: resolve keys with Omarchy's alias cascade (named key, then colorN, then purple/selection_background). Where a key is still missing, log it rather than substituting silently, and add a fixture in the generated colorN form.

3. crates/ely-ui/src/theme/mod.rs:37 What is wrong: ELY_OMARCHY_SYNC treats every value except "0" as on, without a warning. ELY_APPEARANCE (:32) and ELY_REDUCE_MOTION (accessibility.rs:20) both warn on an invalid value. This is a silent fallback on a documented 0/1 switch. Failing scenario: ELY_OMARCHY_SYNC=false or off leaves Omarchy sync on, and the log does not say the value was ignored. Fix direction: match "0", "1" and unset explicitly, and warn on anything else, as the other two switches do.

4. crates/ely-ui/src/theme/watch.rs:40 What is wrong: when the live theme directory has no colors.toml, reload logs at debug and keeps the previous OmarchyState. The app keeps showing the theme the user just left. Failing scenario: the app runs under tokyo-night, and the user runs omarchy-theme-set with a user theme that has no colors.toml and no alacritty.toml, so Omarchy writes none. theme/ is swapped and theme.name changes, but Ely stays on the tokyo-night palette. Nothing above debug level records this. Fix direction: on Ok(None) after a change, clear OmarchyState, re-apply (Ely's palette or the chosen appearance), and log at info.

5. crates/ely-platform/src/dirs.rs:19-21 What is wrong: the default Omarchy directory comes from BaseDirs::state_dir(), which honours $XDG_STATE_HOME. Omarchy hardcodes $HOME/.local/state/omarchy/current (bin/omarchy-theme-set: CURRENT_THEME_PATH="$HOME/.local/state/omarchy/current/theme"). Failing scenario: on an Omarchy machine with XDG_STATE_HOME=$HOME/.state, Ely looks in ~/.state/omarchy/current, logs "no Omarchy on this machine", and never syncs. Fix direction: build the path from the home directory as .local/state/omarchy/current to match Omarchy, with ELY_OMARCHY_DIR still taking precedence.