Asked for a plan to 100%. Four things had to be established first,
because each one changes the plan's shape, and three of them contradict
what I would have assumed.
**There are already 148 widget tests and they have never run.**
tests/ui.rs is 1,889 lines of #[makepad_test] tests driving the real app
through TestApp/Selector. Line 1 imports a crate that is not a
dependency, so the file has never compiled, and no CI job names it. Same
defect the spreadsheet-ui suite documents about itself; same class as the
nigig-email binary that had never been built.
**They compile with a one-line manifest change, and they run.** Adding
makepad-test as a dev-dependency produces a binary; under xvfb-run all
148 execute in 59 seconds without hanging.
**All 148 fail at a known point.** The harness's child build of the app
exits non-zero before startup: code 127 with no cargo on the child PATH,
code 101 after fixing that — while `cargo check -p nigig-build --bins`
passes. So the blocker is in how the harness invokes the child, not in
the app, and spreadsheet-ui already documents the workaround.
**#[coverage(off)] is unstable on 1.97.1.** There is no way to annotate
a line as legitimately unreachable, so anything genuinely uncoverable
has to be covered, moved to an excluded file, or subtracted openly.
The plan puts unblocking those 148 tests first, because it is the
cheapest large prize and because its outcome resizes everything after
it. Engine cleanup runs in parallel since it is independent. Extraction
work is explicitly held until Phase 0 reports, so nobody extracts logic
the app-level tests already cover.
It also argues against 100% as a target for the widget half. The 148
tests are mostly wait_visible(); they will move the number a long way
while proving that widgets exist. Of the four real defects this work has
found, three came from reading uncovered regions and asking why they
were unreachable, not from driving a percentage. The plan targets 100%
of what is worth executing and names the ~48 subtracted lines.
