mirror of
https://github.com/nexu-io/open-design.git
synced 2026-10-27 09:51:12 +01:00
lefarcenandGitHub
ae67ad41b1
* fix(amr): resolve run model catalog from the shared cache instead of a blocking per-run `vela model list`
Packaged AMR runs failed with "AMR model … is not available from Vela.
Refresh the AMR model list, choose a supported model, and retry this run"
even for a logged-in user who had a real model selected.
Root cause: the AMR run preflight ran a fresh, blocking
`vela model list` (the authoritative remote catalog) on every turn and
fail-closed the run whenever that single call timed out or errored.
That call needs network reachability to the AMR gateway AND `$HOME`
(the offline `vela model preset` / `--version` calls need neither),
has a 10s ceiling, and only retries a narrow set of network errors.
Under CorpLink/飞连 the round-trip routinely approached the timeout, so
runs died at preflight — while the model picker still showed models
(seeded from the offline preset), making AMR look selectable but unusable.
Fix (daemon):
- Preflight now resolves the catalog through the same AmrModelLoadingCache
the UI's /api/amr/models endpoint uses: a cached authoritative
`vela model list` when hot, otherwise the offline `vela model preset`
seed while a remote refresh runs in the background. The blocking remote
probe is off the per-run hot path; a transient failure degrades to
preset instead of fail-closing. vela's own `session/set_model` stays
the final gate for a genuinely unsupported model.
- The previously-silent `catch {}` around the catalog probe now logs, so
the failure is no longer invisible in logs/diagnostics.
- Backfill `$HOME` in the AMR spawn env: `execAgentFile` replaces the
child environment wholesale, and `vela model list` exits non-zero with
"$HOME is not defined" when it is missing (preset/--version do not),
which silently decapitated the catalog probe.
- Raise the cache's remote-refresh interval from 60s to 10min: the
catalog changes on the order of days, cached entries are returned
instantly, and the per-run path now reads this cache.
Diagnostics: the export bundle now also carries the coding-agent CLIs'
own logs (claude / codex / opencode / amr) plus recent per-run
events.jsonl, via shared builders in @open-design/diagnostics used by
BOTH the daemon HTTP export and the desktop IPC export (the latter,
which users actually trigger, previously shipped neither run logs nor
agent logs). Secret-bearing files (~/.amr/config.json, ~/.codex/auth.json)
are never swept; only *.log files, tail-bounded and redacted.
* fix(diagnostics): resolve AMR OpenCode log dir from the effective OPENCODE_TEST_HOME
The AMR CLI log sweep hardcoded `<dataDir>/amr/opencode-home/...`, which
misses the provider logs as soon as a user sets
`agentCliEnv.amr.OPENCODE_TEST_HOME` (a supported app-config override that
spawnEnvForAgent preserves) — the run writes logs elsewhere while the
bundle keeps looking in the default path.
- buildAgentCliLogSources now takes an explicit `amrOpenCodeHome`; it
sweeps `<amrOpenCodeHome>/.local/share/opencode/log` and falls back to
the `<dataDir>/amr/opencode-home` default when not provided.
- The daemon export resolves the effective home through the live
`spawnEnvForAgent('amr', …)` (honoring the app-config override) so the
two cannot drift.
- The desktop export reads the override from app-config directly (it may
not import daemon internals) with leading-`~` expansion, falling back to
the default otherwise.
* fix(diagnostics): honor CLAUDE_CONFIG_DIR / CODEX_HOME overrides in the agent-log sweep
Same class as the AMR OpenCode-home fix: `agentCliEnv.claude.CLAUDE_CONFIG_DIR`
and `agentCliEnv.codex.CODEX_HOME` are supported app-config overrides
(`app-config.ts`), but the collector hardcoded `~/.claude` and `~/.codex/log`,
so a user who relocates either CLI home would have those provider logs dropped
from the bundle.
- buildAgentCliLogSources now takes `claudeConfigDir` / `codexHome`,
falling back to `~/.claude` and `~/.codex` when not provided.
- The daemon export resolves all three homes (amr/claude/codex) through the
live spawnEnvForAgent so they cannot drift from the spawn path.
- The desktop export reads the overrides from app-config directly with `~`
expansion.
* fix(diagnostics): resolve OpenCode XDG_DATA_HOME from the effective spawn env
Sandbox mode (sandbox-mode.ts) rewrites XDG_DATA_HOME to a sandbox root, and
OpenCode resolves its data/log dir from XDG_DATA_HOME. The export was passing
the host process's XDG_DATA_HOME, so a sandboxed runtime would miss the
OpenCode CLI logs. Resolve it from `spawnEnvForAgent('opencode', …)` (which
reapplies sandbox env) alongside the amr/claude/codex homes; falls back to the
host value when unavailable. Sandbox is opt-in (OD_SANDBOX_MODE) and off in
packaged/dev runtimes, but this keeps the resolution consistent and correct.