# Rush Linux — Repo Analysis & Path to 1.0 I cloned the rep...

Prompt

# Rush Linux — Repo Analysis & Path to 1.0 I cloned the repo, read the canon docs (SPEC-northstar, AGENTS.md, D2 amendment, OPTID-COMPLETION-PLAN, the package ledger, milestones.toml), and verified the build myself. Here's the full picture. --- ## 1. What the project is **Rush Linux** is an Arch-based, mkosi-built distro whose core product is **`optid`** — an adaptive power/performance daemon with one canonical objective (from `docs/SPEC-northstar.md`): > *Minimize avoidable platform energy subject to a per-workload-class responsiveness floor, holding each domain in the deepest power state its latency contract permits.* Components: `optid` (daemon, ~26k LoC Rust), `optctl` (CLI), `rushbench`, `rush_collect`, `testos` (boot/test backend), plus mkosi image profiles (desktop, laptop, livedev, realtime-audio, server, testos), UKI/systemd-boot with signed updates and rollback, and a LiveDev USB/VM bootstrap flow. Notably, it's an **agent-built project with unusually strong governance**: an "Agent Constitution" (AGENTS.md), a machine-readable package ledger with CI validators, an Evidence Rule (nothing is "complete" without a committed transcript), cold-verification receipts separate from builder claims, and periodic "Dragnet" self-audits that have honestly reset overstated claims. 995 commits, essentially all since May 2026, solo maintainer, very high velocity (~30–70 commits/day recently). ## 2. Health check (verified locally) - `cargo check --workspace` — **clean** ✅ - `cargo test --workspace` — **517 tests, all pass, 0 failures** ✅ (422 in optid alone) - `rush_telemetry` is deliberately excluded from the workspace (doesn't compile — known, documented, tracked as package R1). - Docs, ledger, and README status are mutually consistent (they run validators for this in CI). ## 3. The plan structure (three layers) 1. **Release roadmap** (`ROADMAP.md` / `release/milestones.toml`): v0.1 → v1.0 milestones with per-criterion evidence flags. 2. **optid construction plan** (`OPTID-COMPLETION-PLAN.md`, 100KB): 30 packages across lanes — foundation (F1–F4), safety (D0, S1D–S5D per the accepted **D2 fail-passive amendment**), contracts (C1), events (E1), observability (O1–O2), context (X1–X2), depth domains (D1–D5), thermal (T1–T3), research (R1–R3), integration (I1–I3). 3. **Work selector** (`docs/plans/current-work.md` + `optid-package-status.toml`): the live pointer for what's active. ## 4. Progress snapshot (as of today, v0.7.0-beta.4) **Milestones:** | Version | Status | |---|---| | v0.1–v0.5 | ✅ Complete, with committed evidence transcripts (v0.3–v0.5 all 4/4 criteria verified) | | v0.6 (Hardware-Aware optid) | Code-complete; **certification blocked on Phase D** — two quantitative criteria (mixed-load responsiveness on 2 machines, battery vs. mainstream defaults) need **physical reference hardware, and both slots are still unnominated** | | v0.7 (Editions) | In progress; laptop/realtime-audio mkosi profiles exist only as placeholders | | v0.8 (Benchmark Lab), v0.9 (RC hardening), v1.0 | Planned | **optid package ledger (30 packages):** - ✅ **Completed (6):** F1–F4 (foundation: domain gating, injectable kernel I/O, versioned decision envelopes, full-state reconciler) + D0, S1D (capability sealing prototype, lever safety contracts). - 🔧 **Active:** **S2D** (persistent verified write-ahead transactions — safety lane) and **T1** (thermal sensing/budget model — merged but incomplete, needs cold hardware verification). - ⏳ **Planned (19):** the entire safety tail (S3D–S5D), contracts (C1), event reactor (E1), observability (O1/O2), session context (X1/X2), all five depth domains (D1–D5), thermal actuation (T2/T3), integration (I1–I3). - ▶️ Ready in parallel: R1–R3 (research/feasibility). **Honest reading: roughly 25–30% of the optid completion plan is done.** The foundation is genuinely solid and verified; everything that actually *writes to hardware safely* (the safety lane + depth domains) is still ahead. Apply mode is correctly labeled experimental; dry-run is the default. ## 5. Key risks I see 1. **Phase D hardware gate is the single biggest schedule risk.** It's a human/logistics blocker (nominate 2 physical machines), not an engineering one, and it transitively blocks v0.6 closure → v0.7 validation → v0.8 benchmarks. It's been flagged since the July audit and is still open. 2. **Long serialized safety chain:** D1–D5 and T3 all depend on S2D→S3D→S4D→S5D completing in order. One package per PR + cold verification means this lane sets the critical path. 3. **Bus factor of one** — one maintainer merges everything; evidence discipline mitigates quality risk but not continuity risk. 4. **Evidence transcript reuse** (one boot session certifying 4 criteria) is acknowledged but weakens v0.3–v0.5 certification slightly; fine for now, should be re-run fresh at v0.9. 5. **Placeholder editions** (laptop, realtime-audio) — v0.7 is nominally "in progress" but its real work hasn't started; the PREEMPT_RT kernel path is untested. 6. **`rush_telemetry`** is a dangling stub; v0.8's Benchmark Lab will want it (or an explicit decision to kill it — that's package R1's job). ## 6. Way forward to a finished product (v1.0) The plan itself is sound — the way forward is mostly *sequencing and unblocking*, not re-planning. Here's the concrete path: ### Phase A — Unblock the hardware gate (now, ~1 week of human action) - **Nominate the two Phase D reference machines** (desktop + battery laptop) in `docs/strategy/reference-hardware.md` and run the existing `rush-host-bench.sh` baseline/optid captures. Everything is scripted; only the hardware decision is missing. - In parallel (agent lane): finish **T1** (it's `merged_incomplete`; cold verification can partially ride on the newly nominated hardware) and land **S2D** (active safety package). ### Phase B — Complete the safety spine (critical path, ~S3D → S4D → S5D) - S3D (independent `optid-recover` + watchdog + boot ordering), S4D (sealed typed capability table + Landlock), S5D (circuit breakers + canary re-entry). - Interleave the **parallel-safe packages** that don't touch the write path so the lane never idles: **C1** (measured latency contracts), **E1** (real event reactor replacing the fixed sleep), **O1/O2** (truthful observability + cgroup resource pull), **I1** (diagnostics/doctor), and close out **R1–R3** dispositions (including a kill-or-fix decision on `rush_telemetry`). - Exit: apply mode survives a kill -9 mid-write with verified journal recovery — that's the moment "experimental" can come off the label. ### Phase C — Depth domains + context (D1–D5, X1–X2) - With S2D–S5D done, the five depth domains all unlock simultaneously — this is the widest parallelizable stretch (D1 runtime-PM, D2 storage/NVMe APST, D3 backlight/display, D4 dGPU, D5 memory), plus X1/X2 session-context bridge and T2/T3 thermal actuation. - **Close v0.6 certification** here using Phase A's hardware transcripts (4/4 criteria verified → status `complete`), then unfreeze the version pointer. ### Phase D — Real editions (v0.7 closure) - Turn the laptop and realtime-audio placeholder mkosi profiles into real ones; build/boot/verify each edition (the PREEMPT_RT kernel is the riskiest item — start it early); ship signed sysexts on the single base image as planned. ### Phase E — Benchmark Lab (v0.8) - Stand up the Phoronix-backed lab on the two reference machines; automate the public benchmark artifact per release; wire regression gates into CI so a perf/battery regression blocks an RC. Also completes I2/I3 (full-system simulation + fault matrix, promotion without hardware as a build gate). ### Phase F — RC hardening & 1.0 (v0.9 → v1.0) - Freeze recipe schema, policy schema, D-Bus API, edition names. Security review of the privileged write path (Landlock + capability table make this reviewable). Re-run install/upgrade/rollback evidence **fresh** (fixing the transcript-reuse debt). Real signing keys replacing test Ed25519 keys. Docs pass; release notes; stable update channel. - 1.0 ships when the five exit criteria in milestones.toml hold: installable on mainstream x86_64, optid active/explainable/reversible, stable update channel, working rollback, benchmark-proven mixed-load + battery wins. ### Cross-cutting recommendations - **Don't add scope.** sched_ext default-on, render scaling, ALS, MUX control are all correctly kept off the critical path — keep them there until R2/R3 gates pass. - **Add a second cold verifier** (even an independent agent context with a distinct receipt trail) to reduce the solo-maintainer bottleneck on package promotion. - **Consider a v0.6.1 "certified" tag** immediately after Phase D closes, so the first externally credible claim ("measurably better than PPD balanced on real hardware") ships as early as possible — that's the project's proof-of-value moment. **Bottom line:** this is one of the most rigorously self-governed hobby-OS repos I've seen — build green, 517 tests passing, honest ledgers. Foundation and safety-prototype work (~30%) is done and verified; the finished product is gated first by a *human* decision (nominate two reference machines) and then by a well-defined serial safety lane (S2D→S5D) that unlocks everything else. Execute the phases above in order and v1.0 is a matter of grinding through the existing ledger, not of new planning. judge this as a reviewer of repo reviewers...