Extract UI println! calls from command.rs into ProgressReporter

[codesoda]

Summary

command.rs contains 14 println! calls for live progress output (SKIP, START, WAIT, READY, FAIL) embedded directly in the process-management layer. This couples I/O side effects to what should be a pure command execution module, making it untestable without stdout capture.

Severity: S2 (Medium) | Confidence: 0.90 | Blast radius: Low (structural)

Technical Details

The following lines in src/command.rs contain direct println! calls for user-facing progress:

Lines: 146, 151, 168, 230, 232, 371, 376, 380, 382, 391, 398, 440, 443, 452

These print messages like:

• " SKIP {name}" — when a command is skipped
• " START {name}" — when a command starts
• " WAIT {name} → {url}" — waiting for readiness
• " READY {name}" — readiness check passed
• " FAIL {name}" — command failed

This means:

• run_short_lived_commands() and spawn_long_lived_commands() cannot be called without producing stdout output
• Unit tests must capture stdout to verify behavior (currently they don't — progress output is untested)
• No way to swap in a different output format (JSON, TUI, quiet mode)

Proposed Fix

1. Define a ProgressReporter trait (same one proposed for executor.rs in F5):

   pub trait ProgressReporter {
       fn command_skipped(&self, name: &str);
       fn command_started(&self, name: &str, cmd: &str);
       fn readiness_waiting(&self, name: &str, url: &str);
       fn readiness_ready(&self, name: &str);
       fn command_failed(&self, name: &str, reason: &str);
   }

2. Replace all 14 println! calls with reporter.method(...) calls
3. Pass &dyn ProgressReporter into run_short_lived_commands and spawn_long_lived_commands
4. Provide a TerminalReporter default implementation that does the current println! behavior

Estimated effort: ~4 hours

Related

• Related to F5: same ProgressReporter pattern for executor.rs
• Part of refactor Bundle 6: Split executor.rs

---

🔍 Found by vibe-code-audit — automated codebase audit skill for Claude Code.