Launch Progress TUI

Status: Partially implemented

Current state: the launch cockpit itself has shipped; remaining work is diagnostics-tool polish, richer visual/PTY coverage, timing presentation for Instant launch architecture, and measured safe parallelization.

Shipped baseline

The launch path now uses a 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 invocation correlation handle, 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 bounded current-invocation state and emit governed telemetry without a local artifact. The public stages are identity, role, credentials, construct, agent binaries, derived image, workspace, network, sidecar, capsule, and hardline.

Application observability also shipped. app::run mints cli.invocation.id, keeps bounded current-invocation progress in memory, and exports governed traces, events, and metrics directly over OTLP when configured. Launch stage outcomes, substep timings, cache/build decisions, and prewarm work use the shared schema. The launch UI displays the invocation correlation handle and keeps detailed operator evidence out of the progress surface. Application observability is the canonical contract.

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, keep bounded redacted detail in the active process for the popup, show cli.invocation.id for backend correlation, wait for operator acknowledgement, and tear down the progress surface before exit rendering. They do not attach telemetry or command-output files and expose no reveal/open action. 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 bounded current-invocation progress state, and calls the same load pipeline; the one-terminal ownership work is documented in TUI Design Decisions. 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.

jackin diagnostics validate emits all three signal markers and confirms a new exporter success for each signal within one bounded flush window. History and comparison are backend responsibilities; jackin❯ does not provide local telemetry readers or a backend-independent trace viewer.

Some safe startup overlap has already landed: pre-launch orphan cleanup and Git identity lookup run with tokio::join!, and governed telemetry includes 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

• 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.
• Preserve useful launch evidence after the OTLP-only cutover. The launch surface shows cli.invocation.id and current-invocation stage/timing state from an in-memory progress model, while traces and cross-invocation comparison live in the configured backend; the active failure UI may show its bounded redacted failure tail but cannot reveal a local telemetry or command-output artifact.
• Present and aggregate timing evidence for Instant launch architecture. Governed telemetry records 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 governed spans that show whether failures still clean up claimed resources.
• Keep operator docs aligned with the shipped surface. jackin load and jackin console should describe visible launch behavior without internal paths or Rust names; contributor docs should keep implementation detail in TUI Design Decisions and the codebase map.

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.
• Launch displays cli.invocation.id for application correlation and keeps current-invocation stage/timing evidence visible without depending on a local telemetry artifact; exporter-disabled/failure states are explicit without a nonexistent reveal action.
• Launch and diagnostics reporting expose enough cold/warm/reuse/prewarm timing evidence to drive 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.