Rust migration of a desktop app and build toolchain, tracked as a long-running issue with per-checkpoint evidence

What they did

The author is migrating a shipped desktop application and its build toolchain from project-owned JavaScript and Python to Rust, while preserving behavior, low-resource native desktop operation, and cross-platform support. Work is tracked in a single GitHub issue (#9) with a requirements trace (R-151 → BG-106 → SF-138 → UC-141 → FR-136 → QAS-147 → DD-160) spread across docs/01–docs/07. Each checkpoint pushes a commit to a long-lived draft PR (#22) on branch codex/issue-9-native-ui-parity and records: the exact source commit, focused test counts, rustfmt and warning-denied Clippy results, a 300-line source/test layout guard, and a JSON evidence file under docs/evidence/. They build exact-commit macOS arm64 packages locally with a locked/offline command, then run validate-package, ZIP integrity checks, and packaged smoke cases across shared/worktree × Git/folder combinations with parallel tasks and tests, verifying approved merges pass and unapproved merges are refused. They track packaged UI acceptance as a running fraction (e.g. 15/25, 18/25, 19/25) separately from shipped/default Rust UI (0/25), and keep the issue open and PR draft until release gates pass. Windows verification is attempted through a UTM VM, which repeatedly fails to boot or expose a display, and guest shared-folder access is blocked by macOS permissions. They also refresh Graphify node/edge counts and record AgentMemory entries per checkpoint.

How it went

Substantial progress: the Rust implementation builds, passes large focused and full native UI suites (hundreds to ~967 tests), and produces validated macOS arm64 packages with passing smoke cases. Packaged UI acceptance reached roughly 19/25 (76%) at the latest checkpoint, but shipped/default Rust UI replacement remains 0/25, Windows runtime and package execution are unverified, and CI runs on the PR are queued or pending with no claimed remote pass. The PR remains open, draft, and at times conflicting with main.

Worth knowing

This is an in-progress migration, not a finished port: the default shipped UI is still not the Rust one, and release gates, license checks, Windows UI/accessibility/Korean IME checks, and main reconciliation are open. Windows verification depends on a UTM VM that does not boot and a shared folder macOS denies shell access to, so those results are stale or absent. CI status is unconfirmed. Several checkpoints are documentation-only and explicitly claim no new full-suite result.

Wiring

Work happens on branch codex/issue-9-native-ui-parity against a long-lived draft PR (#22) targeting main. The Rust workspace is built and tested with cargo using --locked --offline; verification order is rustfmt, git diff --check, warning-denied Clippy, focused test suites, then the source_layout guard (300-line max, source/test separation). Packaging uses a local locked/offline command to produce a macOS arm64 archive from an exact commit, followed by validate-package, ZIP integrity, and packaged smoke cases that exercise shared/worktree × Git/folder with parallel tasks and tests. Evidence JSON files are committed under docs/evidence/ alongside plan and LLM Wiki updates; Graphify is refreshed for node/edge counts and AgentMemory stores a memory id per checkpoint. Windows checks route through a UTM VM with a guest Z: share mapped to a host folder, which is currently blocked.

Try it yourself

Read issue #9 and docs/01–docs/07 in this repo to understand the Rust migration trace (R-151 → BG-106 → SF-138 → UC-141 → FR-136 → QAS-147 → DD-160). Then: 1) run cargo fmt --check, git diff --check, and cargo clippy --all-targets with warnings denied; 2) run the focused suites for the area you are changing plus the source_layout test that enforces the 300-line source/test limit; 3) build an exact-commit macOS arm64 package with the locked/offline package command and run validate-package, ZIP integrity, and the four shared/worktree × Git/folder smoke cases (three parallel tasks and tests each, approved merge passes, unapproved merge refused); 4) write a JSON evidence file under docs/evidence/ named for the commit and date, recording test counts, hashes, and what was and was not verified; 5) update the acceptance fractions (packaged UI vs shipped/default Rust UI) honestly and push to the draft PR without claiming any unverified remote or Windows result.