Port order, milestone slicing, and cutover criteria #255

Activity

1. blooop

   added

   wayfinder:grilling

   on Aug 18, 2026
2. blooop

   added a parent issue on Aug 18, 2026

   • Rust rewrite: implementation plan #248
3. blooop

   marked this as blocked by 4 issues on Aug 18, 2026

   • devlaunch-core module architecture and data model #251
   • Acceptance harness: which tests gate cutover, run against both binaries #252
   • Porting a moving target: freeze, checkpoint, or continuous tracking #253
   • Distribution and CI plan: every channel, per-platform #254
4. blooop commented on Aug 18, 2026

   

   blooop

   on Aug 18, 2026

   OwnerAuthor

   More actions

   cut over in 1 big bang
5. blooop commented on Aug 20, 2026

   

   blooop

   on Aug 20, 2026

   OwnerAuthor

   More actions

   Resolution: answered by the owner's steer plus the committed plan, and the port it sequenced has since shipped. This ticket got its answer; what never happened was coming back to close it — Rust rewrite: implementation plan was closed around it on 2026-08-19, leaving it as the map's one open child.

   The steer. Asked on this ticket, answered on this ticket (2026-08-18): "cut over in 1 big bang" — so no parallel shipping, no period where users choose an implementation. The same steer is recorded in the map's Notes and in #253's answer.

   Milestone slicing — eleven, M0 through M10, each sized to one focused agent session, each leaving the tree green (cargo test + rust-parity under the then-current manifest + its claimed ledger rows out of pending), later ones depending only on earlier ones:

   • M0 harness and scaffold — the judge before any defendant: the DEVLAUNCH_DL_CMD seam, the implementation-blind fake-devpod shim, the cargo workspace compiling, the seeded spec ledger, the empty parity manifest, the rust-parity job required from day one.
   • M1 the Runner trait and its single fake. M2 (∥) domain, M3 (∥) tool clients. M4 storage flows. M5 read-side + the first binary — the point the manifest starts shrinking, and where timing landed. M6 lifecycle. M7 launch. M8 provisioning + aid. M9 parity burn-down to an empty manifest and zero pending. M10 distribution and the 0.1.0 cutover release, sequenced last and gated on the checklist.

   Which answers the ticket's own sub-question — early or last — with last. wf's consumption surface is designed early (M2/M3, from #250) but core's public API freezes only at the end of M6, and wf's switch to linking devlaunch-core was put out of scope entirely, bounded to at-or-after cutover. The reuse payoff was not pulled forward to buy churn.

   Cutover criteria — six boxes, all of which M10 waits on: empty parity manifest green on both tiers against the Rust binary; zero pending ledger rows; coexistence verified against one real cache (v2 metadata.json byte-compatible under the same flocks, identical completion caches, v1→v2 migration exercised); both channels shipping from one tag; README regenerated against dl --help with the divergence table final; rollback documented as pin <0.1.

   The spec landed as docs/rust-rewrite-plan.md, written 2026-08-18 against main at 0.0.29, which names this ticket as the source of its port order and cutover checklist.

   And it was executed. PR #260 merged and 0.1.0 shipped on both channels 2026-08-19 (#261) — one big bang, as asked. The Python tree and the parity apparatus half the checklist gates on were retired afterwards (#267, PR #287), which is why the plan doc now opens "done, and partly historical": the milestones and the checklist are a record of how the port was run, and the divergence table is the one part still live — the only written record of every deliberate behavioural difference from the Python build, cited by row number from tests and comments throughout rust/.

   Closing as resolved. Indexed on the map's Decisions-so-far.
6. blooop

   closed this as completedon Aug 20, 2026