Decide: Rust rewrite — go or no-go

[blooop]

Question

Rust rewrite: go or no-go?

Given the research ticket's facts (ecosystem fit, distribution win, port effort), decide whether devlaunch's future is a Rust rewrite or continued Python evolution. The answer gates the dl.py structural-refactor plan: splitting a Python module we're about to rewrite is wasted motion.

• No-go → the refactor plan proceeds.
• Go → the refactor ticket is ruled out of scope here, and charting the rewrite becomes its own effort (this map's destination stays: targeted fixes still land for current users).

[blooop]

breadcrumb: Real driver surfaced, and it is not CLI perf: devlaunch is to become the base layer of blooop/wayfinder (wf, Rust, v0.5.1), consumed as a linked crate — devlaunch-core lib + dl bin, with Workspace/metadata as shared structs rather than parsed stdout. Subprocess-on-PATH was considered and rejected. Linking a typed core into a Rust binary is not reachable from Python, so this trends go.

breadcrumb: Perf is not an argument for Rust here. Measured on this machine: devpod list --output json = 0.44/0.47/0.44s; dl --help = 0.09s. One devpod round-trip costs 5x the entire Python interpreter startup, and dl.py has 19 subprocess call sites. The rewrite buys ~85ms once; cutting one redundant devpod call buys ~450ms — and that is architectural, available in either language (map ticket #60).

[blooop]

breadcrumb: Crate-vs-subprocess stress-tested rather than assumed. wf deleted its poll loop (refresh.rs: one-shot load per map), so there is no repeated-query hot path — and even linked, devlaunch-core still shells out to devpod (Go binary, ~450ms). Linking saves only the dl spawn (~85ms, once). Perf carries neither the Rust decision nor the crate decision; the typed shared model carries the crate alone.

breadcrumb: Drift risk raised against the crate (CLI rots once wf consumes the library instead). Resolved rather than accepted: the subprocess alternative would require inventing a dl JSON contract that nothing type-checks, so the real choice is which second surface the compiler watches — crate breakage fails wf's build, stdout-schema drift is silent until runtime. Mitigated by two binding invariants: (1) dl holds no logic beyond arg parsing + rendering, all capability in devlaunch-core; (2) the 61 mock-free acceptance tests target the CLI binary, keeping it a CI-enforced consumer regardless of wf.

breadcrumb: Falsifier named and checked: the crate would be over-engineering if wf only launched fire-and-forget. Confirmed it does not — wf will read and render per-ticket workspace state (live/stopped/none) beside its stage glyphs, which is what the typed model is for.

breadcrumb: Migration settled — parallel implementation, cut over at acceptance parity. Python dl keeps shipping while the Rust core+bin is built; the 61 mock-free tests (e2e 8, integration 10, storage 20, models 7, config 7, spec-parsing 7, helpers 2) become the shared CLI-boundary harness. The 376 mock-based tests (test_dl.py alone = 234) are read as a behavior spec, not ported; test/fixtures/devpod_mock.py's design (call recorder + workspace state machine + injectable failures) maps onto a Rust command-runner trait even though its unittest.mock wiring does not.

[blooop]

Answer: GO — rewrite in Rust as a shared crate

Not for the reasons the research ticket surfaced. The driver is reuse: devlaunch becomes the base layer of blooop/wayfinder (wf, Rust, v0.5.1), consumed as a linked crate. That is not reachable from Python, so the decision follows from the integration, not from perf.

Shape

A cargo workspace in this repo: devlaunch-core (library) + dl (binary). wf takes devlaunch-core as a pinned git dependency and calls typed functions — Workspace, WorktreeInfo, and the metadata model are shared structs, not parsed stdout.

Subprocess-on-PATH was the alternative and was rejected, but only after the drift objection below.

Perf is not an argument for this — measured, not assumed

	measured (this machine)
devpod list --output json	0.44 / 0.47 / 0.44 s
dl --help (full Python startup)	0.09 s

One devpod round-trip costs 5x the entire Python interpreter startup, and dl.py has 19 subprocess call sites. Even in Rust, devlaunch-core still shells out to devpod — it is a Go binary; that 450ms is unavoidable in either language. So:

• The rewrite buys ~85ms of startup, once.
• Cutting one redundant devpod call buys ~450ms — and dl --purge currently makes the same devpod list call twice (dl.py:1075 then :240, ~900ms burned), while a single dl <ws> attach chains list + status + context options + up + ssh --command sudo hostname + ssh ≈ ~2.7s of round-trips.

Architecture beats language by 5x per call. Where the perf win lives is the devpod call graph (#60), not the language — and that design transfers to Rust verbatim. Perf carries neither the Rust decision nor the crate decision; the typed shared model carries the crate alone.

The drift objection, and why the crate still wins

Raised against the crate: once wf consumes the library, the dl CLI stops being the dogfooded surface and rots out of sync. Also real, and unnamed at the time: semver across repos — devlaunch's internal refactors become breaking changes for a downstream repo. That tax is permanent.

It does not flip the decision, because the subprocess alternative is not the one-surface option it appears to be. dl has no machine-readable interface today — 19 subprocess sites and human-shaped stdout. Subprocess coupling means inventing a JSON contract, which is a public surface that rots exactly like an API does, except nothing type-checks it. The real choice is which second surface the compiler watches:

• Crate → a breaking change fails wf's build.
• Subprocess → drift is silent until a user hits it at runtime.

The concern is about drift, and the crate is the option where drift is caught. (wf's "declares no run dependencies" property survives linking — that is a runtime claim; a linked crate is compile-time.)

Falsifier, named and checked: the crate would be over-engineering if wf only launched fire-and-forget. It does not — wf will read and render per-ticket workspace state (live / stopped / none) beside its stage glyphs. Reading state back is what the typed model is for. Had the answer been launch-only, subprocess would have won on every axis.

Two binding invariants (constraints on every downstream build ticket, not intentions)

These are what make the drift concern structurally unrepresentable — the constructive-modeling move applied to the architecture rather than to a type:

1. dl holds no logic beyond argument parsing and rendering. Every capability lives in devlaunch-core. The CLI then cannot semantically diverge, because there is no second implementation to drift; it can only fail to expose a core capability, which is visible and cheap to fix.
2. The acceptance harness targets the CLI binary, not the library — so the CLI keeps a permanent, CI-enforced consumer regardless of what wf does. Dogfooding supplied by tests instead of by wf.

Plus: devlaunch-core and dl live in one cargo workspace in one repo and version together. Only wf crosses a repo boundary, via a pinned git dependency — no crates.io publish until it earns one.

Migration: parallel implementation, cut over at acceptance parity

Python dl keeps shipping while the Rust core + binary is built; cut over when the shared harness is green. PyO3-strangler and big-bang were both rejected — the bridge is pure waste at 2.6K LOC, and big-bang has no safety net and no shipping story during the port.

The test split is what makes this work:

	tests	ports?
mock-free — e2e 8, integration 10, storage 20, models 7, config 7, spec-parsing 7, helpers 2	61	yes — CLI/filesystem boundary, language-agnostic
mock-based (test/test_dl.py alone = 234)	376	no — unittest.mock on Python seams

The 61 mock-free tests are a ready-made acceptance harness that does not care what language dl is written in — and per invariant (2), they stay pointed at the binary. The 376 mock-based tests are read as a behavior spec, not ported: their durable value is the invariants they pin (exact devpod argument sequences, ID sanitization rules, cache formats). test/fixtures/devpod_mock.py is a unittest.mock.patch over run_devpod — the wiring is lost, but its design (call recorder + workspace state machine + injectable per-command failures) maps 1:1 onto a Rust command-runner trait, so that design work is already done.

Consequences for this map

The destination stands — it already admits "landed as merged fix PRs or explicitly deferred" — but the five build tickets now target Python code with a known expiry date, so they are split by durability:

• Land in Python now — #57 (devpod-missing error: cheap, real user value, ports free) and the root-file half of #59 (PROMPT.md, ralph.yml, @fix_plan.md, @AGENT.md, WORKTREE_BACKEND_*.md, coverage.xml — repo-level, outlives the rewrite).
• Stays a decision, now feeding the core's data model — #55 (workspace-id collision). Under a go this matters more, not less: it is a parse-boundary decision that must be settled before devlaunch-core's model is designed, and its /constructive-modeling framing is exactly the type-safety motive that justified the crate.
• Deferred as requirements on devlaunch-core — #56, #58, #60. Their value is the design, which carries to Rust intact; implementing them twice is waste. (Build: harden metadata storage (guarded load, atomic save) #56 largely dissolves in Rust — serde plus atomic rename is structural there. The metadata.json schema-version fog rides along with it, since the format is shared across the parallel period.)
• Out of scope — #54 (dl.py structural refactor plan), per this ticket's own stated terms; and the dead-Python-code half of Build: repo hygiene sweep (template leftovers, dead code) #59. Splitting a module we are replacing is the definition of wasted motion.
• Charting the rewrite is its own effort — a separate map, not chartable here: it would redraw this map's destination.

[blooop]

Amendment to the resolution above (same session, at the map owner's direction).

The resolution deferred #56, #58 and #60 to the rewrite effort on the grounds that implementing them twice is waste. That reasoning was too strong and is reversed — all three land in Python, in a final Python release (#62, blocked by all five builds).

Why the original argument was wrong: the port ports whatever is in the tree at cut-over. Fixing first means the Rust core is ported from fixed code — strictly better than porting the defect and re-fixing it there — so the incremental cost of carrying a fix through the port is near zero, not a second implementation. Current users also get the ~900ms / ~2.7s devpod wins now rather than at cut-over. The one place real rework survives is #56, where guarded load and atomic save genuinely simplify in Rust (serde at the parse boundary, std::fs::rename); it lands anyway, because a corrupt metadata.json crashing every dl command is a live bug and this is the last Python release that can fix it for them.

#59 keeps both halves rather than the narrowed root-file scope: the dead-code deletions now do double duty, since deleting a function is an unambiguous "do not port this" where leaving it in makes that a judgment call during the port.

Unchanged: go, the linked-crate shape, the two binding invariants, parallel migration with the 61 mock-free tests as the shared CLI-boundary harness, #54 out of scope, and charting the rewrite as its own effort. The map's destination now names the final Python release as its terminus.

[blooop]

Reversed 2026-08-08: the Rust rewrite is deferred. Python remains the implementation.

This ticket closed as a go, which ruled the dl.py structural refactor out of scope as wasted motion in front of a rewrite, and led 0.0.11 to announce itself as the last release of the Python implementation. Neither holds now:

• 0.0.12 (devpod_ssh exit-status recovery) and 0.0.13 (terminal for interactive workspace commands) have both shipped from the Python codebase.
• The refactor this ticket was gating is a candidate again, to be judged on its own merits rather than against a rewrite that is not being worked toward.

The 0.0.11 changelog entry keeps what it shipped with and carries a superseded note; the current position is under Unreleased. See #113.

Leaving this closed — the decision was made and is now superseded, which the record should show rather than hide. Reopen if the rewrite is picked back up.

[blooop]

The rewrite is picked back up (2026-08-18) — not by reopening this ticket: the go/no-go stands as decided, and per the map's own ruling ("charting the rewrite is its own effort"), the revival is charted as its own map: Rust rewrite: implementation plan. That map inherits this ticket's decided shape (linked crate, binding invariants, parallel migration) as standing input and re-litigates none of it; what it does redo is every quantitative fact underneath, which 375 commits and sixteen releases have made stale.