mirror of https://github.com/diegosouzapw/OmniRoute.git synced 2026-08-20 22:22:57 +03:00

Files

Diego Rodrigues de Sa e Souza 4d92dfe0a2 fix: distinguish CLI-probe timeouts from not_found, resolve Hermes Agent keyId server-side (#10710+10711) (#10746 )

#10710: locateCommand() in cliRuntime.ts collapsed a genuine probe timeout
(runProcess's timedOut flag) into the same reason:"not_found" as a truly
absent binary, on both the where.exe and `command -v` branches. Give
timeouts a distinct "timeout" reason, keep trying remaining command
candidates in locateCommandCandidate instead of treating a timeout as
terminal, and extend the settings-file fallback (cliInstallFallback.ts) to
also cover the new "timeout" reason, matching the scenario it already
existed for.

#10711: the Hermes Agent dashboard "Apply" flow only ever sends `keyId`
(never a raw `apiKey`), but the hermes-agent-settings POST handler never
resolved it, so generateHermesAgentConfig() always fell through to the
literal placeholder "YOUR_OMNIROUTE_API_KEY_HERE" for
providers.omniroute.api_key, delegation.api_key, and every
auxiliary.*.api_key. Resolve keyId server-side via getApiKeyById(), the
same precedented pattern already used by claude-settings/route.ts and
codex-settings/route.ts.

Bug 2 from #10710 (hermes tool-detector configPath) was already fixed by
commit 0a74bfbdea -- confirmed still intact,
no action needed.

Co-authored-by: Markus Hartung <mail@hartmark.se>

2026-08-19 11:08:34 -03:00

features

docs(guides): DASHBOARD_ALLOW_EMBED is a build-time flag, not a runtime one (#10697 )

2026-08-18 20:35:52 -03:00

fixes

fix: distinguish CLI-probe timeouts from not_found, resolve Hermes Agent keyId server-side (#10710+10711) (#10746 )

2026-08-19 11:08:34 -03:00

maintenance

docs: add embeddings client runbook for Gemini 2 and Jina omni (#10569 )

2026-08-18 10:52:29 -03:00

README.md

feat(release): changelog.d/ fragments — eliminate the CHANGELOG merge-storm cascade (#6783 )

2026-07-10 07:22:49 -03:00

README.md

changelog.d/ — changelog fragments

A PR never edits CHANGELOG.md directly during the cycle. Instead it adds ONE new file here — its changelog entry as a fragment. Two PRs never touch the same file, so changelog merge conflicts (the "CHANGELOG-eat" cascade that forced a re-sync push + full CI re-run after every sibling merge) are structurally impossible.

Convention

Directory	Aggregates under
`features/`	`### ✨ New Features`
`fixes/`	`### 🐛 Bug Fixes`
`maintenance/`	`### 📝 Maintenance`

Filename: <PR-number>-<short-slug>.md (e.g. fixes/6700-dockerfile-better-sqlite3.md). The PR number prefix keeps aggregation order deterministic.
Content: the exact bullet line(s) that should land in CHANGELOG.md, starting with - . Multi-line (continuation) bullets are fine. Keep the repo's credit format: (#PR — thanks @user).
One fragment per PR (rarely more, e.g. a PR that both fixes and adds).

Example

changelog.d/fixes/6496-cloudflare-relay-worker-syntax.md:

- **fix(providers):** Cloudflare relay Worker deploys use Service Worker syntax with `body_part` metadata ([#6496](https://github.com/diegosouzapw/OmniRoute/pull/6496)) — thanks @SeaXen

Aggregation

The release captain (or /generate-release) folds all fragments into CHANGELOG.md and deletes them:

node scripts/release/aggregate-changelog.mjs            # write + delete fragments
node scripts/release/aggregate-changelog.mjs --dry-run  # preview only

Fragment well-formedness is enforced by npm run check:changelog-integrity (the same gate that guards against CHANGELOG-eat for legacy direct edits).