Files
ElyOffice/tasks/reviews/C05.1-r2.md
T

4.4 KiB
Raw Blame History

FAIL

Checked: cargo test -p ely-ui -p ely-platform passes (ely-ui 10 omarchy tests plus startup_panic, ely-platform 12 + 10 + 2 + 1). cargo clippy -p ely-ui -p ely-platform --all-targets is clean. tests/scripts/theme.sh passes on macOS, including the live swap, the empty theme and the return. tests/scripts/references.sh, agents_md.py and comments.py pass. All 22 fixtures are byte-identical to reference/omarchy/themes/*/colors.toml at f45461a. accessibility.rs and env.rs, built alone in a scratch crate, cargo check cleanly for x86_64-unknown-linux-gnu and x86_64-pc-windows-msvc. That backs the cross-compile claim; cargo check -p ely-platform --target … itself cannot run here because ring has no C cross compiler. Contrast figures below are WCAG ratios worked out from the fixture hex values, where danger, warning, success and info equal the raw red, yellow, green and blue.

Round 1:

  1. Fixed. palette.rs:28-48 lifts against bg, surface, overlay, sunken, hover and active. tests.rs:65 checks every listed token on all six for all 22 themes.
  2. Fixed. colors.rs:11-27,111-133 follows Omarchy's alias cascade, the colorN fixture checks it, and hues that are still missing are logged in watch.rs:38.
  3. Fixed. env::flag warns on any value other than 0 or 1, and theme.sh:64 covers ELY_OMARCHY_SYNC=false.
  4. Fixed. watch.rs:47-51 clears the state, re-applies and logs at info. theme.sh:99-100 checks this live.
  5. Fixed. dirs.rs:21-27 builds the path from home and ignores XDG_STATE_HOME.

New defects:

  1. crates/ely-ui/src/theme/omarchy/palette.rs:102 (and tests.rs:42) What is wrong: success, warning, danger and info are the theme's raw hues and are never lifted. The component library draws text in them: overlays::PromptDialog's validation reason (dialogs.rs:299), the required-field star (forms/structure.rs:156), git badges, the merge marker and others. Ely's own palettes keep all four at or above 4.5 on bg (light 4.82–5.33, dark 6.37–9.97). The test's "every text token" list leaves them out. So the TASKS line ("全部正文色在六种表面上达 4.5:1") and agents.md ("每个正文色…都拉到 4.5:1") claim more than the code does. Failing scenario: 11 of the 22 bundled themes put a status hue under 4.5:1 on bg alone. Some examples: nord red 3.05, solitude red 2.78, miasma red 2.30, catppuccin-latte yellow 2.31 and green 2.96, rose-pine yellow 2.05, matte-black yellow 2.90. Under nord, a PromptDialog error reads at 3.05:1 on the plain background and lower on the dialog's surface. Fix direction: lift each status color for text the way the syntax colors are lifted, or keep the hue for fills and add a lifted text variant if the component library allows it. Add the four tokens to text_on_surfaces. If that is not done, narrow the claim in TASKS.md and agents.md.

  2. crates/ely-ui/src/run.rs:33-37 What is wrong: ELY_SMOKE treats every value except hold as one-frame smoke and treats an unset or non-UTF-8 value as off. Neither case gives a warning. That is the same silent fallback round 1 flagged for ELY_OMARCHY_SYNC. The new hold mode is also missing from agents.md:111, which documents only ELY_SMOKE=1. Failing scenario: ELY_SMOKE=0 cargo run -p ely-doc opens a window, draws one frame and quits, and the log does not say why. Fix direction: match "1", "hold" and unset explicitly, warn on anything else (through env::value), and document hold in agents.md.

  3. crates/ely-platform/src/accessibility.rs:11-13 What is wrong: when the OS gives no answer, it logs "using full motion" before it looks at ELY_REDUCE_MOTION. The log then contradicts the decision that follows. Failing scenario: on Linux without gsettings, with ELY_REDUCE_MOTION=1, the log reads "the OS gives no reduce-motion answer, using full motion" and then "theme: reduced motion on". Fix direction: log the fallback only when both the environment variable and the OS give no answer, or log the source the decision came from.

  4. crates/ely-platform/src/accessibility.rs:4-6 What is wrong: pub fn system_reduce_motion only forwards to os_reduce_motion. Its sole caller is reduce_motion in the same file, so it is a public layer with one user (rule 8). Failing scenario: no behavior breaks. It is an extra public entry point with no caller outside the file. Fix direction: call os_reduce_motion from reduce_motion and delete the wrapper.