Decide: wf links devlaunch-core vs keeps the wire seam — prototype before cutover

[blooop]

Question

Does wf linking devlaunch-core in-process actually beat the wire seam it has today — decided by a prototype, before PR #260 merges?

This is load-bearing for the cutover, not sequencing detail. The linked-crate reuse was the sole surviving driver of #53's go — perf was disclaimed at decision time (one devpod round-trip costs 5× the Python interpreter startup), distribution doesn't change (same two channels, narrowing to linux-64), and the port's genuine side-yield (bug finds, the boundary-test harness, the grammar fixes) is language-independent. The owner-directed re-litigation of 2026-08-19 (recorded on #261) re-measured that driver against wf's actual code and found it weaker than #250 estimated:

• The wire-tolerance layer is ~100–200 lines of serde parse in wf's src/reap.rs plus one version-floor message — not ~300. The rest of reap.rs is deletion policy (what wf may destroy, the --force waiver) that survives linking unchanged.
• wf's launch path deliberately execs into the dl binary for terminal handoff (launch.rs) — linking converts only the listing/rm calls; the binary stays in wf's world either way.
• Skew doesn't die, it moves: today it's a loud runtime version-floor error ("needs devlaunch 0.0.21+"); under a pinned git dep it's silent pin-time staleness.
• The wire seam delivers dl fixes to wf for free via pixi global update; a crate pin requires re-pin → rebuild → wf release for every devlaunch fix — a permanent coupling tax on a repo that shipped 16 releases in ten days.

The experiment (~1 day)

Branch wayfinder; swap reap.rs's dl --ls --json subprocess call for a devlaunch-core git dependency pinned to the rust/big-bang-port branch (the frozen api module: enriched_listing/json_document, typed workspace_delete). Judge:

• Is the typed model materially better to live with than the tolerant serde parse — including a typed unsaved instead of dl's rendered words?
• Walk the loop that hurts: "devlaunch fixed a bug, ship it to wf" under release coupling, vs today's pixi global update.
• What the exec-into-dl launch path looks like alongside a linked core (it stays either way — is a half-linked wf coherent?).

The two outcomes (follow-on tickets filed after the decision, not now)

Linking wins → merge #260 (which is the 0.1.0 release — Auto-publish fires on the merge commit) and cut over, with hard retirement conditions attached rather than left as loose ends:

• a dated wf re-pin/switch ticket on blooop/wayfinder;
• the Python tree deleted within N releases;
• the parity apparatus (goldens, spec ledger, shim, compare.py) deleted with it;
• the dev-loop follow-up (dev.sh / pixi run dl still installing Python) done at cutover.

Linking loses → do not merge; harvest instead:

• unfreeze Python (the freeze exists to serve the port and dies with it);
• backport the port's ~8 real bug finds;
• keep the devpod shim + DEVLAUNCH_DL_CMD boundary-test harness, pointed at the Python binary;
• land the divergence-table grammar improvements (rows 14–15, 23, 25) as Python changes;
• complete the private security-fix flow (unchanged either way);
• close Rust port of devlaunch (big-bang cutover, 0.1.0) #260 with the reasoning recorded.

Constraints

• "Park the branch" is not an outcome. Python moved 375 commits in ten days before the freeze; big-bang parity decays in weeks. The choice is binary: merge now, or harvest and discard.
• A standing owner preference for an all-Rust ecosystem (wf already is; one typed model; agent-driven development where the compiler does free review) is itself a legitimate resolution that skips the experiment — this ticket exists so the reason on record is a real one, not so a preference is laundered through a prototype.
• Decide: Rust rewrite — go or no-go #53's go/no-go record stands as decided-then-revived; this ticket re-examines the driver's weight now that the port exists, per the owner's direction — it does not reopen Decide: Rust rewrite — go or no-go #53.

[blooop]

Answer: wf keeps the wire seam — linking loses the prototype

The experiment ran (2026-08-19, owner-directed session): blooop/wayfinder@linkexp/devlaunch-core-prototype re-expresses reap's two dl calls (--ls --json, <ws> rm [--force]) as in-process devlaunch-core calls, pinned as production would pin (git dependency on this repo, branch rust/big-bang-port), with an end-to-end test against devlaunch-test-support's fake devpod. It compiles, passes, and wf's full suite stays green beside it. The findings are marked FINDING 1–6 in src/linked.rs; each reproduces in the build.

What the prototype found

1. The frozen api cannot wire a listing. api::enriched_listing is exported, but its parameter types (DlView, Sizes, MetadataStorage, a ClonePathResolver) and every error type are binary surface — the prototype imports eight modules devlaunch-core module architecture and data model #251 §7 says are not for wf. Day one of real linking is day one of violating the freeze.
2. The typed rows never arrive. ListedWorkspace's fields are pub(crate); the only public reading is json_document — JSON. A linked wf serializes core's rows and re-parses them through the same serde boundary it has today. The subprocess is deleted; the parse is not. The typed model was the entire Decide: Rust rewrite — go or no-go #53 driver, and it does not cross the boundary as the API stands.
3. wf inherits dl's session layer. To call the listing at all, wf replicates dl/src/session.rs: config load, metadata.json open under dl's locks, and the v1→v2 cache migration under wf's pid — wf becomes a second writer of dl's cache. ~80 lines transplanted for two verbs, a copy that drifts every time dl's startup semantics move: the drift bug-class the crate was meant to kill, relocated rather than removed.
4. wf becomes a second renderer. Core's errors and notices carry no Display — by design, "no user-facing English in core" makes the binary the renderer. Linked, wf inherits the whole diagnostic vocabulary (ConfigError, MetadataError, ListingUnreadable, NotRun, migration reports — including the user's only pointer to dl --reconcile) as its own rendering duty, or swallows it. The prototype counts what it swallows.
5. The dl binary stays load-bearing anyway. wf's launch path deliberately execs dl (terminal handoff), and workspace_delete's Refresh needs a SelfInvocation naming a re-runnable program — which for wf is the dl on PATH, since current_exe() would name wf. Linking removes zero deployment dependencies.
6. Skew gets quieter, not rarer. Measured on the branch: an upstream core fix is invisible to a built wf until cargo update re-pins the lockfile — then rebuild, retest, re-release wf, and every machine updates wf too. Today the same fix reaches every wf via pixi global update of devlaunch alone, and version skew fails loudly (the 0.0.21 floor message). The crate trades a loud runtime check for silent lockfile staleness plus a permanent release-coupling tax.

Mechanical costs, measured: +32 transitive deps (76→108), +140 KB release binary (+3.9%), release build 18.8s→27.8s (+48%), and every core call in tokio-async wf needs spawn_blocking.

The one genuine simplification: a linked core is definitionally a dl that answers unsaved, so the version-probe question disappears and Unsaved::Unanswered/Unrecognized become dead arms. That is roughly 150–250 lines of already-written, already-tested tolerance — against everything above.

Resolution

• wf keeps the subprocess seam, indefinitely. The --ls --json document stays the Grade A contract (goldens already pin it); after cutover there is a single Rust writer, so the tolerance layer's job gets easier, not harder.
• The port proceeds — on its actual grounds. Per this ticket's own terms, the owner's standing direction (all-Rust ecosystem; Python feature-frozen, "after today it's all rust"; tonight's instruction to finish the port) resolves the merge question. What this experiment retires is the linked-crate rationale, not the port: Rust port of devlaunch (big-bang cutover, 0.1.0) #260 merges as the all-Rust cutover, not as a library delivery.
• The retirement conditions lose one entry: no "wf re-pin ticket" — there is nothing to re-pin. Python-tree deletion and parity-harness retirement stand.
• Finish the API-freeze surface (post-cutover) #262 inherits this evidence. The api freeze should be finished in the shrinking direction: the day-one api module cannot serve a linker and now has no linker to serve. Recommend demoting toward pub(crate) per Finish the API-freeze surface (post-cutover) #262's existing plan and declaring the JSON document the sole external contract. If in-process linking is ever revived, this prototype is the requirements list (session-level entry point, public typed rows, rendered errors) — and the branch is the starting point.

#53's go-decision survives with its driver swapped: the rewrite's value is the ecosystem being one language with one owner of the container domain — not a crate link that, prototyped, delivers JSON over a function call instead of JSON over a pipe.