ElyOffice/tasks/reviews/C01.2c-r2.md

FAIL

Ran: cargo test -p ely-platform -p ely-ui (all pass, including tests/startup.rs and the harness-less tests/startup_panic.rs: "2 cases pass"), cargo clippy -p ely-platform -p ely-ui --all-targets (clean). I also ran the startup_panic "launch" child without ELY_NO_DIALOG. A system alert came up that named ElyDoc, the reason and a log path, and it blocked until the process was killed. Read gpui 1a28cff gpui_apple/src/metal_renderer.rs:190-210: graphics::check uses the same Device::all() / system_default() test that gpui uses before its process::exit(1).

Round 1:

1. Startup panic aborting on macOS: fixed. startup::guard (startup.rs:36-48) calls fail from the panic hook. That runs before the non-unwinding abort. startup_panic.rs "launch" proves it inside gpui's launch callback: exit 1, stderr text and log line.
2. Metal device missing, so gpui exits silently: fixed. graphics::check runs before run (run.rs:17-19), and its probe matches gpui's own. The failure branch is honestly listed under 未验证.
3. Late panics labelled as a failed start: fixed. The STARTED flag is set on the first frame (run.rs:48). startup_panic.rs "late" shows a later panic exits 101 with the ordinary panic text and no "could not start".
4. Unbacked claims in TASKS: fixed. The window-open branch and the probe-failure branch moved to 未验证. The panic path has a test.

New:

1. crates/ely-platform/src/startup.rs:19-22 — fail names a log file it has not checked exists. It rebuilds the path from data_dir(app) and does not ask where logging actually writes, or whether logging started at all. Scenario A: ~/Library/Application Support/ElyOffice/ely-doc is not writable. logging::init fails and run.rs:15 calls fail. The dialog and stderr then say "日志 / Log: …/ely-doc/ely.log", but that file was never created, and the log::error! on line 18 goes nowhere because no logger is set. The user is sent to a log that does not exist (rule 2: no default standing in for missing data). Scenario B, seen in this review: the startup_panic child logs to its temp dir, yet the dialog points at the real user data dir. Neither test checks the path, so this went unnoticed. Fix direction: have logging record the path it actually opened (for example init returns it or stores it), and have fail print that path. When logging did not start, say there is no log. Add an assertion on the printed log path to tests/startup.rs.