lefarcenandGitHub 935034cc20 fix(diagnostics): desktop export delegates to daemon so run/AMR logs are captured (#4405) ...

The desktop "Export diagnostics" path rebuilt the support bundle in the
Electron main process and had to GUESS the daemon data dir from the sidecar
namespace layout (`<namespaceRoot>/data`). That guess is wrong whenever the
daemon's real RUNTIME_DATA_DIR differs: in tools-dev it is `<projectRoot>/.od`
(OD_DATA_DIR unset), and under any OD_DATA_DIR override it is elsewhere. The
exporter then swept the wrong `runs/` and `amr/opencode-home` trees and
silently dropped the per-run `events.jsonl` (which already records every agent
stderr chunk, tool call, and error) and the AMR OpenCode logs — the exact data
needed to explain a stuck/looping run that produced nothing.

The daemon already exposes a complete, correctly-pathed bundle at
`GET /api/diagnostics/export` (it knows its own RUNTIME_DATA_DIR and collects
run events, agent CLI logs, sidecar daemon/web/desktop logs incl. renderer.log,
and host crash reports). So delegate to it instead of duplicating the assembly:

- desktop: new electron-free `diagnostics-fetch.ts` fetches the daemon bundle;
  `diagnostics.ts` keeps only the save dialog + reveal and saves those bytes.
  Removes the data-dir guessing entirely (net -141 lines in diagnostics.ts).
- index.ts: share one `resolveDaemonBaseUrl(runtime, options)` (daemon URL →
  web URL → sidecar web discovery) across app-config menu actions and the
  diagnostics IPC, so the export targets the same daemon as everything else.
- daemon: emit a manifest warning when `runsDir` is set but no per-run event
  logs were found, so an empty bundle reads as "collection gap / persistence
  off" rather than "clean run with nothing to report".

Tests: desktop `fetchDiagnosticsBundle` hits the daemon export endpoint and
surfaces non-200 as an error; daemon export warns on an empty runs dir. Both
red before the change.

2026-06-16 09:26:50 +00:00

..

main

fix(diagnostics): desktop export delegates to daemon so run/AMR logs are captured (#4405)

2026-06-16 09:26:50 +00:00