debug-symphony

# Debug ## Goals - Find why a run is stuck, retrying, or failing. - Correlate tracker issue identity to a Pi or Codex session quickly. - Read the right logs in the right order to isolate root cause across the primary Pi path and the explicit Codex app-server continuity path. ## Log Sources - Primary runtime log file: `<logs-root>/log/symphony.log` - When Symphony runs with `--logs-root` or `SYMPHONY_LOG_ROOT`, it writes rotating JSON logs under this path (see `apps/symphony/README.md`). - Includes orchestrator, agent runner, Pi RPC bridge, and Codex app-server lifecycle logs. - Rotated runtime logs: `<logs-root>/log/symphony.log*` - Check these when the relevant run is older than the active file. - Stdout fallback: structured JSON log stream - Without `--logs-root`/`SYMPHONY_LOG_ROOT`, TUI mode suppresses stdout logs; use `--no-tui` to stream structured logs to stdout. ## Correlation Keys - `issue_identifier`: human ticket key (example: `MT-625`) - `issue_id`: tracker internal ID (stable backend identifier) - `session_id`: agent session identifier. For the Pi runner this is the stable session ID returned by pi RPC. For the Codex backend this is the Codex thread-turn pair (`<thread_id>-<turn_id>`). - `agent.backend` / config backend: `kata-cli` (aliases: `kata`, `pi`) is the primary/default Pi path; `codex` is the explicit Codex app-server path. These fields are emitted by Symphony runtime lifecycle logs (notably in `apps/symphony/src/orchest...