# Launch Progress TUI (https://jackin.tailrocks.com/roadmap/launch-progress-tui/) **Status**: Partially implemented — the launch cockpit itself has shipped; remaining work is diagnostics-tool polish, richer visual/PTY coverage, timing presentation for [Instant launch architecture](/roadmap/instant-launch-architecture/), and measured safe parallelization. ## Shipped baseline [#shipped-baseline] The launch path now uses a run-scoped rich progress cockpit instead of terminal printouts. `LaunchProgress::new` requires a rich terminal, enters the full-screen renderer, carries `JACKIN_NO_MOTION=1`, shows the diagnostics run ID/path, and exposes a `for_test` renderer for assertions. Launch emits structured `LaunchMessage` updates through `stage_started`, `stage_progress`, `stage_done`, `stage_skipped`, `stage_failed`, and `opening_hardline`; these update the shared launch view and mirror stage events into diagnostics. The public stages are `identity`, `role`, `credentials`, `construct`, `agent binaries`, `derived image`, `workspace`, `network`, `sidecar`, `capsule`, and `hardline`. Run diagnostics also shipped. `app::run` starts a `RunDiagnostics` for each command, activates it, and prunes old runs. The diagnostics layer writes JSONL under `~/.jackin/data/diagnostics/runs/.jsonl`, tracks active runs, preserves active artifacts during prune, and `jackin prune` removes diagnostics state. Launch stage events, substep timings, cache/build evidence, launch-plan decisions, prewarmed-DinD adoption, and debug lines feed the same run artifact. The launch UI displays the compact run handle and keeps detailed command output, Docker output, stack traces, and debug firehose out of the progress surface. Launch prompts and failures now live on the rich surface. The runtime progress wrapper provides forced-choice, text/select env prompts, confirm prompts, standalone launch/exit dialogs, and standalone error popups. Fatal launch failures call `stage_failed`, attach the diagnostics path and optional command-output sidecar, render the error popup, wait for the operator acknowledgement, then tear down the progress surface before exit rendering. The old compact/plain launch renderer is no longer a supported product path: unsupported terminals fail before launch through the rich-terminal gate. Console-triggered launches reuse the same path rather than maintaining a second launch renderer. The console records launch actions, carries diagnostics run state, and calls the same load pipeline; the one-terminal ownership work is documented in [TUI Design Decisions](/reference/tui/). Boundary rain is also no longer a per-launch decision: launch marks jackin❯ universe start through the runtime lifecycle helper, and app/runtime code owns first-entry/last-exit animation gating. A first diagnostics CLI exists. `jackin diagnostics summary ` resolves either a run ID or JSONL path and prints stage/timing/cache/build/launch-plan summaries. `jackin diagnostics compare ` compares multiple run artifacts with text or JSON output, labels, and baseline selection. This supersedes the original “no diagnostics command in the first implementation” note; remaining diagnostics work is now viewer and UX refinement, not initial command creation. Some safe startup overlap has already landed: pre-launch orphan cleanup and Git identity lookup run with `tokio::join!`, and diagnostics include substep timing events needed to evaluate future parallelization. Broader launch parallelism remains intentionally unfinished until dependency edges and cleanup behavior are verified from traces. ## Remaining work [#remaining-work] * Harden the rich renderer with broader PTY, terminal-size, no-motion, failure-dialog, and launch-dialog coverage. Existing unit tests cover progress view behavior and selected render surfaces, but this item still needs snapshot-style or PTY/E2E coverage that exercises the real terminal contract. * Make diagnostics easier for operators and contributors to inspect. The shipped `summary` and `compare` subcommands are enough for timing analysis, but a fuller viewer still needs run listing, stage filters, trace/span navigation, sidecar discovery, and clearer bridges from failure popups to the right artifact. * Present and aggregate timing evidence for [Instant launch architecture](/roadmap/instant-launch-architecture/). Diagnostics already record stage/substep timing, cache/build data, skipped timings, prewarmed-DinD adoption, and launch-plan decisions; the launch surface and docs still need a concise way to show which launch path is cold, warm, reused, prewarmed, or regressed. * Continue visual polish only inside the shipped console-compatible rules: footer-only hints, compact modal geometry, one focused action, no inline log output, and reduced-motion parity. Candidate refinements remain a clearer construct/derived-image layer split, stronger hardline-opening treatment, and less noisy status wording. * Add measured launch parallelism one dependency edge at a time. Prompt barriers, trust decisions, sensitive mount confirmation, credential preflights, resource claiming, cleanup, sidecar setup, workspace materialization, image selection/build, and hardline handoff must keep deterministic ordering where correctness depends on it. Any new overlap should leave diagnostics spans that prove failures still clean up claimed resources. * Keep operator docs aligned with the shipped surface. [`jackin load`](/commands/load/) and [`jackin console`](/commands/console/) should describe visible launch behavior without internal paths or Rust names; contributor docs should keep implementation detail in [TUI Design Decisions](/reference/tui/) and the codebase map. ## Acceptance criteria still open [#acceptance-criteria-still-open] * PTY/E2E or snapshot coverage proves the rich launch surface behaves across supported terminals, no-motion mode, narrow/short viewports, prompts, fatal failures, and handoff teardown. * Diagnostics UX supports listing and drilling into run artifacts by run ID, stage, trace/span, timing, failure, command-output sidecar, and Capsule/session evidence without requiring manual filesystem spelunking. * Launch and diagnostics reporting expose enough cold/warm/reuse/prewarm timing evidence to drive [Instant launch architecture](/roadmap/instant-launch-architecture/) decisions. * Any additional startup parallelism is trace-backed, race-safe, and preserves prompt/trust barriers plus cleanup invariants. * Operator-facing command docs and contributor-facing TUI/codebase references describe the shipped behavior and remaining diagnostics/timing model without stale “terminal printout” or “no diagnostics command” claims.