Command contract: finish the FEAT-02x adoption or fold crates/command-contract

[Hmbown]

From the 0.9.14 refactor backlog.

crates/command-contract is explicitly shapes-only (FEAT-014) while tui/src/commands/contract.rs (~6.5k) plus commands/ (~61k) hold the live dispatch. FEAT-020/021/023/024 adopted shapes group by group in 0.9.13; the remaining work is the last groups plus deleting the tui-side copy. Decide honestly whether the crate earns its keep: if the tui contract file is already the shape everything uses, the crate may be the abandoned side.

Size: M. Acceptance: one contract location, the migration manifest gate (scripts/check-command-migration-manifest.py) reflects it.

[Hmbown]

Triage (v0.9.14 run, structural decision + enumerable frontier — not in #6161): the crate is not the abandoned side — at least five tui command groups already import its shapes; the adoption frontier is exactly config, core, debug, session (scripts/command-migration-topology.json:281-286), enforced fail-closed by the manifest gate. Cleanest first slice: the debug group (7 leaf files). Fallback &mut App count is worst in core — do not start there.

[aboimpinto]

Measured facts from current main about this surface, offered to make the decision easier. Whichever
way you call it, we will execute it.

The TUI contract file is the implementations, not a second copy of the shapes.
crates/tui/src/commands/contract.rs (6,849 lines) imports the shapes from
codewhale-command-contract and holds 15 impl <Trait> for <Adapter> blocks (~2,200 lines of
implementation bodies), the App dispatch entry points, and its own test scaffolding. It defines no
trait, DTO, capability or transport type of its own.

The shapes exist in exactly one place: facets.rs (1,592), handler.rs (323), types.rs (49),
metadata.rs (27), lib.rs (20) — 2,011 lines, plus that crate's own 3,060-line test file. So there
is one location for shapes and one for TUI adapters, and they are not duplicates of each other.

Question	Answer from current main
Do the shapes exist in two places?	No — the TUI imports facets/handler/types and redefines none of them
Who consumes the crate?	codewhale-tui only, today
What enforces the boundary?	check-command-crate-boundaries.py: no path to codewhale-tui, no App/ratatui/crossterm import, no composite super-context, no boxed handler storage
What carries the single-location acceptance?	the same gate — FEAT-025 (#6096) generalises it to keep codewhale-secrets TUI-free too, because the extracted commands crate has to be able to depend on both

Three options, all workable from our side.

1. Keep the crate and finish the adoption. Remaining work is the last groups plus the in-place
   adoption of the TUI dispatch. FEAT-025 is one of those slices and is green, rebased on current
   main with zero conflicts.
2. Fold the crate into codewhale-commands at FEAT-016 instead of into the TUI. One crate fewer,
   boundary preserved, single contract location satisfied, and the churn is the same either way — the
   shapes simply ship inside the crate that consumes them. This is the path I would suggest if the
   goal is fewer crates without losing the boundary.
3. Fold the shapes into the TUI. This is the right call only if the physical move is being
   cancelled. The shapes stay TUI-free today so that codewhale-commands (FEAT-016, then
   FEAT-038–046) can consume them without a path to codewhale-tui; folding them into the TUI means
   the extracted crate could only use them by depending on the TUI, and it would also rewrite the
   import surface of the nine landed slices (FEAT-018–024). If this is the decision, we will do that
   mechanical rewrite properly rather than leave it half-done.

One honest note in favour of shrinking: the crate has a single consumer today, so if the in-place
adoption is the end of the road, one fewer crate is defensible. That is the only condition under
which option 3 costs nothing.

Tell us which option you want and we will act on it. If it helps, we can also send a short summary of
this surface for the Linear plan.

Paulo Aboim Pinto

[Hmbown]

Thanks — the measurement is the right kind of answer, and it matches what the topology shows.

Decision: option 1 — keep the crate, finish the adoption. The crate isn't the abandoned side: the landed slices already consume it, check-command-crate-boundaries.py enforces the TUI-free property, and FEAT-016+ is the reason that property exists. Options 2 and 3 only make sense if the commands extraction is cancelled, and it isn't.

0.9.14 scope, measured from source this morning: debug has 8 &mut App files, config has 4, session has 1 (your export slice in #6096 already merged), core has 35. The ask for this release is debug + config + the session straggler — 13 files, reviewable as slices. core rides through the release; it's the worst &mut App surface and a big-bang attempt is how we get an unreviewable PR.

Debug first if the order doesn't matter to you — the manifest gate only cares that the frontier shrinks by whole slices. This issue stays open past 0.9.14 as the through-release tracker until the frontier is empty; it isn't on the milestone as a closable task.