* fix(ci): five workflow defects, one of them shipping the wrong dmg to Intel Macs
Gaps 31, 19, 16, 30 and 12 of the v3.8.49 process dossier.
## 31 — LIVE BUG: an Intel Mac downloads the ARM dmg
electron-builder runs once per macOS job and each run emits its own
`latest-mac.yml` listing only its own dmg — measured at 338 and 350 bytes,
different content, identical filename. `download-artifact` with
`merge-multiple: true` resolves that collision by ARRIVAL ORDER, so one silently
overwrites the other. arm64 won in the published v3.8.48.
Why that breaks Intel, from electron-updater's own selection code
(out/providers/Provider.js):
files.find(it => [...].some(n => n.includes(process.arch))) ?? files.shift()
The Intel dmg is `OmniRoute-X.Y.Z.dmg` — no arch suffix. On Intel `process.arch`
is "x64", nothing matches, and the fallback takes the FIRST entry. With an
arm64-only manifest that is the ARM build.
So ORDER is the fix, not tidiness: the un-suffixed entry must be first, because
it is the only one reachable through that fallback. `merge-multiple` is now off
(per-artifact subdirectories) and a new
`scripts/release/merge-mac-update-manifest.mjs` merges them deliberately. It
refuses to write when the inputs disagree on version — a manifest stitched from
two builds points at files that were never published together, which is worse
than no manifest.
Validated against the REAL v3.8.49 manifests, not just fixtures: the script
reproduces byte-for-byte the manifest I hand-merged and published, including
both sha512 values and the newer releaseDate.
## 19 — one variable, two opposite machines
`USE_VPS_RUNNER` governed the build and the test jobs together. The build needs
the .113's RAM; the tests need the hosted runner's link. Measured 2026-07-29:
`actions/setup-node` took 20m06s on .113 with 4 concurrent runners versus 16s
hosted (npm cache restore saturating the link), while the tests themselves tied
— 2m54 vs 2m31.
Self-hosted is therefore strictly worse for tests, so rather than add a second
variable to configure, `test-unit`, `test-vitest`, `fast-unit` and `fast-vitest`
are pinned to `ubuntu-latest`. `quality.yml`'s `fast-gates` deliberately keeps
the variable — I have no measurement for it, and guessing is what produced this
gap.
## 16 — a flaky shard sent the publish into the 40-minute build
The artifact reuse filter required `conclusion == "success"` on the whole run, so
any unrelated red shard discarded a perfectly good tree. The artifact is only
uploaded if the Build job succeeded, so its PRESENCE is the accurate signal. Now
it takes the 5 most recent candidate runs and tries each download until one
works. `head_repository.full_name == env.REPO` stays — that clause is the
artifact-poisoning guard, not a filter refinement.
## 30 — the gate that could be bypassed at merge
`check:agent-skills-sync` lived only in quality.yml's PR-only Merge-integrity
job, because the CHANGELOG half of that job needs a base to diff against. This
half does not. Keeping it PR-only left a real hole: this cycle's merge trains
landed with `--admin`, which bypasses required checks, so three SKILL.md files
drifted, rode the release squash into `main`, and the sync-back turned them into
a base-red blocking EVERY PR into release/v3.8.50 until #8954. It now also runs
in ci.yml's lint job, which runs on push to `main`.
## 12 — a cancelled gate reads like a passing one
The dashboard already renders `⚫ CANCELLED` per job, so my dossier entry was
imprecise: they do not vanish, they sit buried mid-table. A cancelled job
reported no verdict at all, and this cycle the Vitest job was cancelled in rounds
1, 2 and 3 — it finished only in round 4, revealing a suite broken the whole
cycle plus two production bugs. The summary now opens with a banner naming every
cancelled job and saying plainly that nothing was checked.
node --import tsx/esm --test tests/unit/mac-update-manifest-merge.test.ts # 11 pass
merge against the real v3.8.49 manifests → both dmgs, Intel first
all four workflows parse; check:workflows --ratchet → 178, baseline 190
* docs(changelog): fragment for #8988
* test(ci): align the artifact-provenance guard with the gap-16 criterion
My own assertion from #8953 encoded the criterion this PR deliberately removes:
it required `.conclusion == "success"` on the whole CI run, which discarded a
perfectly good build tree whenever any unrelated shard went red — pushing the
publish into the 40-minute build the fast path exists to avoid.
Inverted rather than deleted, and the replacement is strictly stronger. It now
pins three things where the old one pinned one: that the loose criterion is gone,
that the step actually probes for the artifact (the accurate signal, since it is
only uploaded when the Build job succeeded), and that it probes MORE THAN ONE
candidate run — without which a single miss still falls back to a full build.
The provenance clause it was originally written to protect
(head_repository.full_name == env.REPO) is untouched and still asserted above.
* fix(ci): finish gap 19 — pin fast-gates and give USE_VPS_RUNNER one meaning
This was left deliberately partial because `fast-gates` had never been measured,
and guessing is what produced gap 19 in the first place. Measured now, and the
evidence is cleaner than expected:
fast-gates, 160 quality.yml runs .... ZERO self-hosted samples
every non-skipped one is "GitHub Actions NNNN"
median duration, 72 successful runs .. 5.6 min hosted
The classifier is not at fault — in the same window ci.yml's Build demonstrably
ran on omniroute-113-7 and omniroute-113-6, so self-hosted runs are visible when
they happen. The USE_VPS_RUNNER expression on this job was dead configuration.
And had it ever fired it would have inherited the measured penalty, because this
job's first two steps are exactly the bottleneck:
actions/setup-node on .113 with 4 concurrent runners .... 20m06s
actions/setup-node hosted .............................. 16s
So it is pinned rather than switched, and the second variable the gap proposed
(USE_VPS_RUNNER_BUILD / _TESTS) turns out to be unnecessary. After this the
variable governs exactly five jobs, all of them build-like:
ci.yml:build · quality.yml:build · npm-publish:publish
nightly-release-green: release-green, main-green
One variable, one meaning: "this job needs the .113's memory". A guard test pins
that — it fails if the variable is ever attached to a test-like job again, and it
also asserts the build KEEPS it, so nobody closes this gap by removing the
variable outright.
node --import tsx/esm --test tests/unit/vps-runner-variable-scope.test.ts # 3 pass
check:workflows --ratchet → 178, baseline 190
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* fix(ci): stop the reconciliation range and the fragment sweep from hiding work
Two release-tooling defects found during the v3.8.49 run (gaps 4 and 7 of the
process dossier). Both fail by hiding work rather than announcing themselves,
which is why each one had already cost a real mistake.
## The reconciliation range was 62× too wide
`list-uncovered-commits.mjs` bounded its scan with `git describe --tags`. Releases
reach `main` by SQUASH, so no commit on a release branch is ever an ancestor of the
tag, and `vPREV..HEAD` re-lists the un-squashed history of every earlier cycle.
Measured on release/v3.8.50 @ 7eca04fd12:
v3.8.49..HEAD ....... 1361 commits
cycle open..HEAD ..... 22 commits
The report drowns in noise, and that is how a previous reconciliation let ~200 PRs
through with no CHANGELOG bullet.
The base is now resolved by CONTENT — the oldest commit that introduced this
version string into package.json — deliberately NOT by commit subject, because the
subject has already changed format once:
chore(release): bump v3.8.49 (development cycle version) older
chore(release): open v3.8.50 development cycle current
A message-matching resolver would have silently reverted to the broken tag base the
first time someone reworded the bump. The fallback now writes a WARNING to stderr
explaining that a tag range re-lists previous cycles, so a shallow clone degrades
loudly instead of quietly reproducing the bug. One of the five tests asserts
exactly that the warning says "squash" and "noise".
## The back-merge resurrects fragments that already shipped
The release lands on `main` as one squash commit, so `main` still carries every
`changelog.d/` fragment the reconciliation folded in and deleted. Back-merging
`main` restores all of them — 191 in the v3.8.49 run. Nothing breaks at that
instant; the next aggregation folds them in a SECOND time and the section grows
duplicates that have to be hand-unpicked.
New `scripts/release/sweep-stale-fragments.mjs` (`npm run sweep:stale-fragments`)
reports them, and `--apply` removes them. Report mode exits 1 so the back-merge
step can gate on it.
The identity rule took two attempts, and the second one exists because running the
script against the live repo refuted the first. Matching on any `#N` in the bullet
flagged `changelog.d/features/8980-deprecate-gemini-cli-provider.md` as stale,
because that bullet cites issue **#7034** for context and #7034 shipped in an
earlier cycle — it would have deleted an unreleased fragment and dropped its
credit. A bullet routinely cites issues it merely references; only the
`<PR-number>-<slug>.md` filename says which PR the fragment *is*. That case is now
a regression test.
Every ambiguous case resolves toward KEEPING: no number in the filename falls back
to normalized text, text shorter than 12 chars is never matched, and anything
matching neither is kept. A surviving duplicate is a nuisance someone notices; a
deleted fragment silently costs a contributor their credit.
node --import tsx/esm --test tests/unit/release-cycle-base-resolver.test.ts # 5 pass
node --import tsx/esm --test tests/unit/sweep-stale-fragments.test.ts # 11 pass
node scripts/release/list-uncovered-commits.mjs --json
→ base ed2db6cb19, baseSource "cycle-open", total 22 (was 1361)
node scripts/release/sweep-stale-fragments.mjs
→ 4 fragments, 0 stale, exit 0
* docs(changelog): fragment for #8985
* fix(ci): four quality gates that punished the wrong thing
Gaps 6, 9, 10 and 23 of the v3.8.49 process dossier. Each one either blocked
work it should have waved through, or reported a number that was never the
code's.
## 6 — test-masking is unusable at release scale
My own dossier entry for this was WRONG and the measurement says so:
tracked test files ............ 3977 (I had written 1277)
absolute tautology scan ....... ~1 s (I had written >30 min)
the diff uses base...HEAD three dots — already merge-base
diff vs release branch ........ 0 files, 0 s
diff vs main (today) .......... 3 files, 0 s
The base choice was never the problem, and it cannot be reproduced today at
all: `main` has since received the v3.8.49 squash, so the merge-base is recent.
The pathology only exists DURING a release, in the window before `main` gets the
squash — then the merge-base is the PREVIOUS cycle's fork point and the diff
legitimately spans the whole cycle (~1277 changed test files, each costing a
`git show` process plus a full regex pass). That is the same squash-merge
topology as gap 4, and it is why the check ran twice without finishing.
Fix: above 300 changed test files the per-file diff subchecks are skipped, since
every one of those files was already gated by this check on its own PR. The
absolute tautology scan still runs unconditionally over all 3977 files, so the
floor is untouched. The skip is deliberately loud — a silent skip is gap 12,
which cost two production bugs this cycle. `shouldSkipDiffSubchecks` never skips
on unparseable input, so a broken count cannot disable the gate.
## 9 — a capital letter invalidated 41 translations
`"Reset Defaults"` → `"Reset defaults"` marked the key stale in 41 locales. Every
translation was still correct, and in locales with no letter case the "fix" is
not expressible. Worse, the escape hatch (`__MISSING__:`) is BANNED in `vi` by
tests/unit/i18n-vi-completeness.test.ts, so `vi` had no legitimate way out.
`isCosmeticRewrite` folds case, whitespace runs and trailing punctuation — and
nothing else. Most of the nine tests exist to pin what is NOT cosmetic: a changed
word, an added word, and any edit inside an interpolation like `{count}` all
still flag. Two end-to-end tests hold both directions: a cosmetic edit leaves
every locale alone, a real rewrite still flags all of them.
## 10 — the ratchet compared numbers from two different auditors
`pipx install zizmor` was unpinned, so the runner installed whatever PyPI served
that day and measured 1 finding MORE than the devbox on the identical commit
(190 vs 189) — a second rebaseline push per release, chasing a number that was
never the code's. Pinned to 1.25.2 (what the devbox runs), and
check-workflows.mjs now prints `zizmorVersion=` next to the count so any future
rebaseline is traceable to the tool that produced it.
## 23 — a PR pointed at its own branch
#8912 has head == base == release/v3.8.50: no diff, can never merge, and it sits
in the queue with a full check board on every push to that branch. It survived
because nothing looks wrong — the checks pass, since there is nothing to check.
New guard in the `changes` job (one field comparison, before anything is spent).
The distinction that makes it safe to block on: an equal head/base BRANCH is
conclusive, an equal head/base SHA is NOT — a branch cut moments ago has an
identical tip and is legitimate, so that case warns instead of failing. Half a
signal never fails either.
node --import tsx/esm --test tests/unit/test-masking-release-scale.test.ts # 6 pass
node --import tsx/esm --test tests/unit/ui-value-drift-cosmetic.test.ts # 9 pass
node --import tsx/esm --test tests/unit/pr-self-target-guard.test.ts # 7 pass
check:workflows --ratchet → 178 findings, zizmorVersion=zizmor 1.25.2, baseline 190
the i18n suite is unaffected (5 files re-run, all green)
* fix(ci): allowlist the four CI-only env vars the new gates read
The env-doc-sync gate failed three unit shards plus Docs Gates on this PR, and it
was right to: it requires every `process.env.X` read in code to be documented in
`.env.example`, and this PR introduced four new reads.
They do not belong in `.env.example`. That file is OmniRoute's runtime
configuration; these are CI signals with no meaning in a user's `.env`:
HEAD_REF / HEAD_SHA / BASE_SHA the `changes` job passes github.head_ref,
github.base_ref and the PR head/base SHAs to
the self-targeting-PR guard
TEST_MASKING_MAX_CHANGED_TESTS the escape hatch that raises the test-masking
gate's release-scale skip threshold
So they go in IGNORE_FROM_CODE, which exists for exactly this and already carries
the precedent one line above: `BASE_REF`, allowlisted because CI passes it to the
OpenAPI breaking-change gate. `BASE_REF` being already listed is also why only
four of my five reads failed.
Each entry carries its justification and the script that reads it, per the
allowlist policy.
node --import tsx/esm --test tests/unit/issue-7793-env-doc-sync-repro.test.ts # 1 pass
npm run check:env-doc-sync → all three directions in sync
* fix(i18n): narrow the cosmetic-rewrite exemption to the scope actually reported
The gap-9 fix folded whitespace in addition to case, and that collided with a
pre-existing test which pins the opposite — tests/unit/i18n-ui-value-drift.test.ts,
"a value that only changes whitespace still counts as an edit". Its comment states
the reasoning:
Conservative on purpose: trailing-space churn is rare, and treating it as a
no-op would let a real reword slip through behind an innocuous-looking diff.
That is a documented decision by whoever wrote it. The problem actually reported
was CASE — `"Reset Defaults"` → `"Reset defaults"` invalidating 41 correct
translations — and whitespace was scope I added on my own. Reversing someone
else's reasoned call, silently, to fix something nobody reported is not this
change's job, so the exemption is narrowed to case + trailing terminal
punctuation. No test pins either of those.
The reported case is still fixed, verified end to end: that rewrite invalidates 0
locales. And whitespace is now asserted NON-cosmetic in my own test file too, so a
later tidy-up cannot quietly fold it back in.
node --import tsx/esm --test tests/unit/i18n-ui-value-drift.test.ts # 11 pass (pre-existing)
node --import tsx/esm --test tests/unit/ui-value-drift-cosmetic.test.ts # 10 pass
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* feat(sse): deprecate the gemini-cli upstream provider with a real migration path
Stored `gemini-cli` connections were being kept alive for nothing. Measured before
touching anything:
routable? absent from PROVIDERS, from REGISTRY, from OAUTH_PROVIDERS, and no
executor references it → the connection can NEVER serve a request
refreshing? yes, and successfully — it redeemed against PROVIDERS.gemini's client
(681255809395-oo8ft2o…), the same public Gemini CLI / Code Assist OAuth
client
So the scheduler made periodic upstream calls to Google to keep a credential fresh
that had nowhere to go. That is the waste this removes.
This is a deprecation, not a deletion, and the difference is deliberate. The path was
not dead code: #8232 added it after a user report (the UI advertises automatic OAuth
rotation and these rows never rotated), and #8275 narrowed it to exactly the legacy
refresh. Simply dropping it from `supportsTokenRefresh` would have produced a SILENT
skip — `Skipping … (refresh unsupported)` — leaving the row at "active" forever, doing
nothing. Worse than before.
Instead:
DEPRECATED_PROVIDERS + isDeprecatedProvider/getDeprecationNotice in tokenRefresh
one place naming the provider and where to migrate. A test asserts the migration
target is itself routable, so the notice can never point somewhere useless.
_getAccessTokenInternal returns the ESTABLISHED unrecoverable envelope
{ error: "unrecoverable_refresh_error", code: "provider_deprecated", migrateTo }
Reusing `error` means isUnrecoverableRefreshError and the manual-refresh route
already stop retrying — no new contract for callers to learn. The distinct `code`
is what makes it legible. A bare `null` would read as transient and retry forever.
tokenHealthCheck marks the connection terminal with the reason
Placed after the existing terminal-status guard, which makes it idempotent for
free: once "expired", later sweeps skip the row, so it writes once instead of
rewriting the same reason every cycle.
the manual-refresh route stops lying
It said "Refresh token expired. Please re-authenticate this account." — false
here: the token is fine, the provider is gone. Re-authenticating would loop
against something that no longer exists. It now reports the deprecation and the
migration target.
`gemini` uses the same OAuth client, so re-adding the account there is a working path,
not advice to start over.
Deliberately NOT touched:
Category A — the gemini-cli CLIENT identity (#7034): clientIdentityProfiles.ts,
clientApi.ts, googApiKeyAuth.ts. Same string, opposite direction — requests
ARRIVING from the Gemini CLI, where OmniRoute is the server. Deleting these is the
failure this change must never cause, so a test now asserts the profile survives.
Audited: `git diff --name-only` touches none of those files.
errorClassifier.ts's isCloudCodeProvider list still names gemini-cli. It is a
defensive 403→PROJECT_ROUTE_ERROR list shared with cloudcode/cloud-code; the entry
is unreachable for a non-routable provider, and editing a shared classification
path for a dead string is risk without upside.
Tests — 42 across the six files that mention the identifier, all green:
gemini-cli-legacy-refresh.test.ts 5 (3 assertions REWRITTEN, see below)
gemini-cli-deprecation.test.ts 5 (new)
client-identity-profiles.test.ts 9 (category A, untouched)
service-token-refresh.test.ts 14
errorclassifier-antigravity-403.test.ts 4
gemini-cli-ansi-sanitization.test.ts 5 (category C, untouched)
The three rewritten assertions in the legacy file are alignment, not weakening, and the
gate is right to ask: each is now STRONGER. "refresh succeeds against Google's token
endpoint" became "zero upstream calls happen at all"; "a 400 surfaces invalid_grant"
became "the envelope is unchanged but the code says provider_deprecated" plus a control
asserting `gemini` still reports invalid_grant, proving the real path was not blunted.
The file's header keeps the whole #8232 → #8275 → deprecation arc, because each step is
why the next made sense. Count unchanged; no test deleted, so no allowlist entry needed.
* docs(changelog): fragment for #8980
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* chore(sse): drop the iflow entry from the token-refresh TTL map
The `iflow` provider was removed from the product, but its 24-hour refresh-lead
entry outlived it in REFRESH_LEAD_MS. Surfaced during v3.8.49 homologation on the
production VPS, where startup logs carry:
[CREDENTIALS] Warning: unknown provider "iflow" in credentials file, skipping.
Measured across src/, open-sse/, tests/ and docs/ — the identifier had exactly two
occurrences repo-wide: the map entry and one test assertion. Nothing dispatches on
it, so `getRefreshLeadMs("iflow")` now falls through to TOKEN_EXPIRY_BUFFER_MS like
any other unknown provider.
The test assertion was not deleted, it was MOVED: from "returns explicit lead time
for known providers" to "falls back to TOKEN_EXPIRY_BUFFER_MS for unknown
providers". That is alignment to the new behavior and strictly more coverage than
before — a silent reintroduction of the entry now turns the fallback case red
instead of passing unnoticed. Flagged explicitly because the test-masking gate
rightly treats a removed assertion as suspicious.
Also removes the now-redundant "Non-rotating providers" section header: every
remaining entry under it is Google-backed and the following comment already says
"permanent (non-rotating)".
node --import tsx/esm --test tests/unit/service-token-refresh.test.ts
# 14 pass, 0 fail
* docs(changelog): fragment for #8966
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* chore(ci): remove two fork-owned publish workflows that rode in by accident
Both files publish to a DIFFERENT owner's GHCR namespace, and both arrived as an
unrelated extra file inside an otherwise on-topic PR:
build-fork.yml added by #1528 (scope: SSE translator, Qiwen Chen)
env IMAGE_NAME: ghcr.io/kang-heewon/omniroute
if: github.repository == 'kang-heewon/OmniRoute'
100+ runs instantiated here
build-rinseaid-image.yml added by #8729 (scope: SSE reasoning)
tags: ghcr.io/rinseaid/omniroute:...
no repository guard at all — 0 runs
Neither can ever succeed: this repository's GITHUB_TOKEN cannot write to another
owner's namespace. The cost is not a breach, it is noise. build-fork.yml's guard
sits on the JOB, not the workflow, so GitHub instantiates a run on every push to
main and every v* tag and then skips the job — which is why every release check
board has carried a permanently skipped "Publish Fork Image to GHCR" entry.
build-rinseaid-image.yml never fires because its trigger branch
(`build-k3-reasoning-image`) does not exist in this repo.
Only build-fork.yml was pre-approved (2026-07-30). The second was found while
executing: grepping the workflow directory for registry namespaces turned up
ghcr.io/rinseaid alongside ghcr.io/kang-heewon. Same defect, same remedy, so both
go — easy to split if that is preferred.
Nothing else is touched. Specifically NOT touched: the 14 `kang-heewon` credit
links in CHANGELOG.md (real contributions), their 42 i18n mirrors, and the
historical `- **ci:** update build-fork workflow…` entry from #2055. Measured: 0
of the 14 credit mentions concern build-fork, so no credit line is involved
either way. `git status` shows exactly two deletions and one new test.
TDD — the guard names both offenders before the removal and passes after:
node --import tsx/esm --test tests/unit/workflows-no-foreign-fork-publishers.test.ts
# before: 0 pass, 2 fail → build-fork.yml → ghcr.io/kang-heewon
# build-rinseaid-image.yml → ghcr.io/rinseaid
# after: 2 pass, 0 fail
Zizmor findings drop 190 → 178 (both files use unpinned docker/* and checkout
actions). The baseline is deliberately NOT rebaselined here: the metric direction
is `down` so a drop cannot break the ratchet, tightening it to exactly 178 would
leave zero headroom and self-break on drift, and validate-release-green states
the convention outright — "Any drift above is rebaselined at release, not a
contributor concern."
* docs(changelog): fragment for #8967
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* test(ci): stop the promote-latest guard from racing the script's early exit
`Unit Tests fast-path (2/4)` went red on two unrelated PRs today (#8953, #8966),
always on the same case, always with `Error: spawnSync bash EPIPE` — never an
assertion. The file passes locally in 1.8s, so it read as load-related noise. It
is not: it is a race with a precise, reproducible mechanism.
should-promote-latest.sh decides a pre-release VERSION and exits BEFORE reading
stdin at all:
case "$VERSION" in
*-*) echo "false"; exit 0 ;;
esac
The test harness passed the candidate tags via execFileSync's `input:`, i.e. a
pipe. The child exits, its read end closes, and the parent's write raises EPIPE —
so the test throws before asserting anything. Whether the write lands first
depends on the 64 KB pipe buffer and the scheduler, which is exactly why it
failed intermittently under four concurrent shards while passing in isolation.
Measured, not inferred — same version, growing payload:
2 tags ( 11 bytes) → ok
100 tags ( 689 bytes) → ok
5 000 tags ( 43 889 bytes) → ok
20 000 tags (188 889 bytes) → EPIPE, every time
Fix: back stdin with a real FILE instead of a pipe. A file has no reader to lose,
so the child may exit whenever it likes. The script's interface is untouched — it
still reads candidate tags from stdin, exactly as docker-publish.yml pipes them.
Production is NOT affected, and that was checked rather than assumed:
docker-publish.yml short-circuits pre-releases before the helper is ever called
(`elif printf '%s' "$VERSION" | grep -qE -- '-(rc|alpha|beta|pre|next)'`), so the
early-exit branch is unreachable there. Only the test exercised it. No production
file changes here.
TDD — the new case is the guard for the harness itself, run against both helpers:
node --import tsx/esm --test tests/unit/build/should-promote-latest-5301.test.ts
# new helper (file-backed stdin): 9 pass, 0 fail
# old helper (input: pipe): 8 pass, 1 fail → Error: spawnSync bash EPIPE
* docs(changelog): fragment for #8977
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* fix(logs): avoid giant provider pills for failed auto family requests
* refactor(logs): extract resolveRejectedComboProvider + cover it
The provider label was decided inline in handleChat, which has no test harness —
the change shipped untested and pushed chat.ts over its frozen size (1848 > 1845).
Moved to rejectedRequestUsage.ts next to summarizeComboAttemptedModels, the helper
it replaces on this path. chat.ts shrinks back under its baseline (no rebaseline
needed) and the logic gets three cases in the suite that already covers its sibling:
auto/* collapses to "auto", a named combo keeps its name, and bare "auto" (no
slash) is NOT collapsed — that one is a combo request, not a family request.
Also rebased on the current release tip and added the changelog fragment.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Co-authored-by: rafaeldrincon <rafaeldrincon@users.noreply.github.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
Second aggregation pass, for the PRs merged after the main reconciliation:
#8860, #8861, #8862, #8863, #8865, #8866.
The `### 📝 Maintenance` heading added to the living section in 26a7783521 held —
[3.8.47] stays at its 234 bullets instead of absorbing this cycle's maintenance
entries. Credits attached where the fragment carried the number only in its
filename: @HouMinXi (#8860, #8865), @artickc (#8863), @rafaeldrincon (#8866).
#8862 already carried its own link and credit.
[3.8.49]: 1172 -> 1178 bullets · contributors 155 -> 156 · 42 i18n mirrors synced.
* fix(adobe-firefly): default gpt-image detailLevel to maximal (5)
GPT Image 2 quality is dominated by generationSettings.detailLevel (1-5).
The SPA often defaults to 3 (medium); missing/auto quality previously mapped
to 3 as well. Default now to 5 (high/max) so API clients and Media without
an explicit quality still get maximal detail. Explicit low/medium still honored.
* chore(quality): rebaseline adobeFireflyClient + changelog fragment
adobeFireflyClient.ts 2317->2322 (+5) — this PR's own growth at the existing
payload-build site. Covered by tests/unit/adobe-firefly.test.ts.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* fix(autoRouting): recognize auto/\<family\> combos in classifyAutoModel
classifyAutoModel() checks VALID_AUTO_VARIANTS and parseAutoSuffix but
never isValidModelFamily, so auto/glm, auto/minimax, auto/llama etc. are
rejected as "Unknown built-in auto combo" before chatHelpers.ts or
builtinCatalog.ts can handle them.
Fix: import isValidModelFamily and ModelFamily, add family to spec type,
check family suffixes before returning unrecognized. Mirrors the pattern
already in builtinCatalog.ts createBuiltinAutoCombo.
Closes: auto/\<family\> combos listed in /api/combos/auto but unusable
at /v1/chat/completions.
* test(autoRouting): cover auto/<family> classification + changelog fragment
The PR changed production code with no test — nothing in tests/ referenced
classifyAutoModel. Since it is module-private, the new suite exercises it through
the public resolveAutoRoutingState().
Verified it guards something real: against the release tip without this fix the
family case fails ("auto/glm should be a recognized built-in auto model"), and
passes with it. Also pins that a category suffix does not pick up spec.family and
that an unknown suffix stays unrecognized.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: rafaeldrincon <rafaeldrincon@users.noreply.github.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(combo): clean up stale connectionId refs after provider delete
Deleting a provider connection left stale connectionId references in
combo route models, causing the dashboard to show deleted providers.
Add cleanupComboConnectionRefs to scan combos and null out any
connectionId or allowedConnectionIds entry matching the deleted connection.
Call it from the DELETE handler alongside the existing synced-model cleanup.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
* fix(types): widen the combo-step cast + changelog fragment
typecheck:core rejected `combo.models as Record<string, unknown>[]` with TS2352
— ComboStep[] and Record<string, unknown>[] do not overlap enough for a direct
assertion. Goes through `unknown`, as the compiler suggests.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(oauth): support Test Connection for xAI OAuth
Wire xai-oauth / xao into OAUTH_TEST_CONFIG with the shared api.x.ai
chat probe so dashboard Test Connection no longer returns
"Provider test not supported" on healthy accounts.
* chore(changelog): add changelog for xai-oauth test connection support
---------
Co-authored-by: allanvb <allanvb@users.noreply.github.com>
* feat(sse): add alternateFormats registry field and resolver
* feat(sse): honor per-connection targetFormat in getTargetFormat
Registry-driven format lookup now resolves an alternate protocol
declared for the provider when the connection's providerSpecificData
carries a matching targetFormat, falling back to the entry's default
format otherwise.
* feat(sse): resolve base URL from selected alternate format
resolveBaseUrl now falls back to the connection's selected alternate
protocol (providerSpecificData.targetFormat) before the provider's
default base URL, while a manual providerSpecificData.baseUrl override
still wins over both.
* feat(sse): apply alternate format auth header and extra headers
DefaultExecutor's registry authHeader lookup and BaseExecutor's shared
header preamble now both honor a connection's selected alternate
protocol: the alternate's authHeader wins over the registry default,
and its extra headers (e.g. Anthropic-Version) are merged in.
* refactor(sse): extract resolveAlternate helper into BaseExecutor
Centralizes the getRegistryEntry() + resolveAlternateFormat() pair
that resolveBaseUrl, buildHeadersPreamble, and DefaultExecutor's
authHeader lookup each duplicated, so a future call-site can't diverge
from the shared precedence. Also translates the PT-BR comments added
in the previous three commits to match the surrounding English. Pure
refactor — no behavior change.
* feat(sse): declare Anthropic-compatible variant for xiaomi-mimo
The provider publishes the same catalog over /anthropic/v1/messages on the same
host. Selecting it also required bypassing the per-provider URL normalizers in
DefaultExecutor.buildUrl(): normalizeXiaomiMimoChatUrl() appends /chat/completions
unconditionally, which mangled the alternate's already-complete endpoint into
.../anthropic/v1/messages/chat/completions.
* feat(sse): add xiaomi-mimo-token-plan provider with monthly quota
Token Plan is a separate product: tp- keys authenticate only on the regional
token-plan-sgp host and return 401 on api.xiaomimimo.com, where the existing
xiaomi-mimo provider points. Same pattern as qwen-cloud-token-plan.
Registers the monthly token allowance (no balance API upstream) and declares
the Anthropic-compatible variant on the token-plan host.
* feat(dashboard): add API protocol selector to connection modal
Providers that declare alternateFormats in the registry now expose an opt-in
protocol dropdown on the connection modal. The choice persists to
providerSpecificData.targetFormat as an explicit null when set back to the
default, since the PUT route merges { ...existing, ...incoming } and an omitted
key would keep the previous override.
* fix(i18n,quality): vi parity for the protocol selector + own-growth rebaselines
The three new provider keys landed only in en/pt-BR, so the vi parity test failed
(tests/unit/i18n-vi-completeness.test.ts asserts key parity AND no __MISSING__
markers — running i18n:sync-ui would have satisfied the first and broken the
second). Added translated values instead. Scoped to vi: it and pt-BR are the only
locales with a parity test.
Rebaselines are this PR's own growth: EditConnectionModal.tsx 1283->1316 (the
selector field) and open-sse/executors/base.ts 1540->1562 (alternate-format
resolution at the existing buildUrl/headers chokepoint).
Adds the changelog fragment.
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* fix(token-refresh): discover projectId during token refresh
The token refresh path (tokenRefresh.ts) did not discover projectId
for antigravity/agy accounts. Dashboard and health check refresh use
this path, not the executor path.
Add ensureAntigravityProjectAssigned call after refreshGoogleToken
for antigravity/agy providers when projectId is empty.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
* chore(quality): rebaseline the token-refresh test file + changelog fragment
tests/unit/token-refresh-service.test.ts 1311->1378 (+67) — the four cases
covering projectId discovery on the tokenRefresh.ts path. Growth is the tests
this PR adds, nothing else.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
Aggregates every pending changelog.d fragment into the [3.8.49] section and
regenerates the contributors table from the reconciled bullets.
Three fixes this surfaced:
- The [3.8.49] section had no `### 📝 Maintenance` heading, so the aggregator's
findIndex matched the first one in the file — inside [3.8.47] — and would have
filed 92 maintenance bullets under the wrong release. Added the heading to the
living section; [3.8.47] stays at its original 234 bullets.
- 46 bullets carried no PR/issue reference. Fragments may keep the number only in
the filename (`<N>-slug.md`), which the aggregator does not copy into the bullet,
so the link and the credit were dropped on aggregation. Restored, scoped strictly
to the [3.8.49] range.
- 9 external contributors lost their attribution that way and are credited again:
@MisileLab (#8566), @MumuTW (#8619), @epsilonode (#8724), @hppsc1215 (#8835),
@sumanxg (#8837, #8856), @TitoTFP (#8838), @HouMinXi (#8842, #8845).
Contributors table: 84 → 155 entries, no one removed. 42 i18n mirrors synced.
check:changelog-integrity green — no base bullet lost.
* fix(cli): escape codex args and stop aborting on exit in launch-codex
`launch-codex` spawns `codex.cmd` with `shell: true` on Windows, so Node joins
argv with plain spaces and no escaping (DEP0190). This mangles every Windows
invocation, not only the ones with a multi-word user argument, because the
injected `-c` provider flags carry quoted TOML values:
["-c","model_provider=omniroute", ...,
"model_providers.omniroute.base_url=http://localhost:20128/v1",
"fix","the","bug"]
cmd.exe strips the TOML quotes (`model_provider=omniroute` no longer parses as
a TOML string), splits multi-word arguments, and swallows everything after an
unquoted `&`. The same defect was fixed for `launch` in #8837; this ports it to
`launch-codex`, which that PR disclosed but left unfixed.
- extract the escaping into `bin/cli/utils/winShellArgs.mjs` and reuse it from
both launchers instead of keeping a private copy in `launch.mjs`
- quote the codex argv (provider flags + profile + pass-through args) on the
win32 shell path; argv is untouched off Windows, where no shell is involved
- replace `process.exit()` in the command action with `process.exitCode`: on any
non-zero child exit it aborted with the libuv `!(handle->flags &
UV_HANDLE_CLOSING)` assertion while the inherited stdio handles were closing
Test: `tests/unit/cli/launch-codex-windows-spawn-args.test.ts` pins the exact
encoding with golden strings (the cmd.exe round-trip is Windows-only and skips
on Linux CI, so without goldens CI would guard nothing) and round-trips the real
provider flags through a probe `.cmd` shim that forwards `%*`.
* docs(changelog): add fragment for #8856
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(executors): route current Claude generations through Vertex partner endpoint
PARTNER_MODELS pinned three Claude 3.x prefixes (claude-3-5-sonnet,
claude-3-opus, claude-3-haiku). Every newer Claude generation on Vertex
(claude-sonnet-4-6, claude-haiku-4-5, etc.) fell through to the
Google-publisher branch instead, producing an invalid
publishers/google/models/claude-... path.
Replace the pinned prefixes with a single generic "claude-" prefix:
any Claude model on Vertex is always an Anthropic partner model, never
a Google one, so this can't go stale again the way pinned version
strings did.
Fixes#1985
* docs: add changelog fragment for #8852
* fix(ci): raise the git ls-files buffer in check:tracked-artifacts
`execFileSync` defaults to a 1 MiB stdout buffer and throws ENOBUFS past it.
`git ls-files -s` on this repo is already at 1,042,494 bytes across 11,091
tracked files — 6,082 bytes from the ceiling. Any PR adding roughly sixty files
crosses it.
That matters more than a failing script: the check runs on pre-commit, so once
the listing crosses 1 MiB, committing breaks for everyone working the repo, not
just for the change that happened to cross it. It is not a hypothetical — the
private EE fork hit it this week when a sync landed ~214 translation files and
pushed the listing 504 bytes over; every commit there failed the hook until
this same fix landed.
Both call sites now share a GIT_LS_OPTS with a 64 MiB ceiling — far above any
plausible tree, rather than just above today's, since the listing only grows.
* docs(changelog): add fragment for #8844
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* feat(oauth): support web client type for remote Google OAuth
Google Desktop app OAuth clients require loopback redirect URIs per
policy, which breaks remote deployments where the browser cannot reach
127.0.0.1 on the server. Add ANTIGRAVITY_OAUTH_CLIENT_TYPE env var:
when set to 'web' and OMNIROUTE_PUBLIC_BASE_URL is configured, the
loopback redirect URI is upgraded to the public base URL. Default
behavior (desktop) is unchanged.
Enables remote deployments without SSH tunneling by registering a Web
application OAuth client in Google Cloud Console.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
* docs(changelog): add fragment for #8845
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(antigravity): discover projectId during token refresh
The initial OAuth exchange can fail to populate projectId via
loadCodeAssist (network timeout, account not yet onboarded). The
runtime transformRequest path already recovers via
ensureAntigravityProjectAssigned, but refreshCredentials did not --
after a token refresh the per-token memoization cache is invalidated
(new access token = new cache key), so every subsequent request
triggers a fresh loadCodeAssist round-trip that may fail again.
Add a best-effort ensureAntigravityProjectAssigned call in
refreshCredentials when projectId is empty, mirroring the pattern in
transformRequest. Persist the discovered id so it survives the next
refresh or restart.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
* chore(quality): rebaseline antigravity.ts and test file-size
antigravity.ts grew from 1493 to 1528 lines (+35) with projectId
discovery in refreshCredentials. executor-antigravity.test.ts is a new
test file at 1098 lines (above cap 1000) with 4 new test cases.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
* fix(antigravity): match ExecutorLog arity in the refresh discovery log
`ExecutorLog.info` (open-sse/executors/base.ts) is `(tag, message) => void` —
two parameters. The discovery log passed a third metadata object, which failed
typecheck:core with TS2554 on antigravity.ts:777. Bind the message to a local
and pass two arguments, matching the sibling warn on the catch branch. Kept to
two lines so the file stays at its frozen size; ran Prettier, which also wrapped
the pre-existing over-width `const msg` line below.
Also adds the changelog fragment for the fix.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(cli): escape claude args and stop aborting on exit in omniroute launch
Windows launches go through spawn(..., { shell: true }), which joins argv
with plain spaces and no escaping (Node DEP0190). Any argument containing a
space was split, so `omniroute launch -p "two words"` reached claude as
`-p two` plus stray positionals, and the prompt was silently truncated.
Escape each argument for cmd.exe instead: CRT argv rules first (double the
backslashes preceding a quote, escape embedded quotes, wrap in quotes), then
cmd metacharacters caret-escaped twice. The second pass is required because
claude.cmd is an npm shim that re-parses %* on the way to node; with a single
pass arguments still truncated at the first `&` or `|`.
The command action also called process.exit() on any non-zero exit. That tore
the loop down while the exited child's inherited stdio handles were still
closing and aborted the process with a libuv assertion
(!(handle->flags & UV_HANDLE_CLOSING), src/win/async.c:94, exit 0xC0000409)
instead of returning claude's exit code. Set process.exitCode and let the
loop drain.
Extracts resolveClaudeSpawn() alongside the existing resolveCodexSpawn()
precedent so both the platform choice and the escaping are unit-testable.
Tests: tests/unit/cli/launch-windows-spawn-args.test.ts (new, 7 tests).
Four pure-function tests plus golden strings pin the exact encoding on every
platform; a Windows-only test round-trips argv through a real npm-style .cmd
shim and asserts embedded quotes, `&`, `|`, `%PATH%`, `^`, `!`, a trailing
backslash and an empty string all arrive byte-identical.
Note: bin/cli/commands/launch-codex.mjs carries the identical defect (same
shell:true concatenation, same process.exit) and is left unchanged here.
* docs(changelog): add fragment for #8837
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(ghe-copilot): route OpenAI-native models via Responses API
- Add targetFormat: 'openai-responses' to gpt-5.4-mini, gpt-5.3-codex, gpt-5-mini,
mai-code-1-flash, and oswe-vscode-prime in ghe-copilot registry.
- Register gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna with openai-responses targetFormat.
- Update GheCopilotExecutor.buildUrl() to route openai-responses and codex models to
<gheUrl>/responses while keeping Claude and Gemini on /chat/completions.
- Add unit tests verifying targetFormat parity and buildUrl endpoint routing.
* docs(changelog): add fragment for #8835
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: Alex <sefias_methue@hotmail.de>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(providers): correct Codex GPT-5.6 context window (#7702)
* docs(changelog): add fragment for #8838
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* test(providers): align the remaining GPT-5.6 context-window assertions
Three suites assert the pinned GPT_5_6_CODEX_CAPABILITIES contract through the
VS Code and provider-models routes, and still expected 372000. They only surface
in a full run, so the focused loop on this PR stayed green while `npm run test:unit`
failed with five `272000 !== 372000`.
The two conservative-merge cases in provider-models-route-codex keep testing what
they tested: live 999999 still exceeds the pinned value (pinned wins) and live
100000 is still below it (live wins). Only the pinned number and the comments
naming it move.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(api): stop /v1/models rebuilding the catalog on almost every request
The response cache added by #6408 memoized the serialized body for
`modelCatalogCacheTtlMs`, defaulted to 1500 ms. On a real install the builder
takes far longer than that: measured on the production VPS, ~49 s for a 1.3 MB /
2645-model catalog. Any two requests more than 1.5 s apart therefore both missed
the fresh window, and the second fell into stale-while-revalidate — which
rebuilds via `setTimeout(…, 0)` and, because the builder is overwhelmingly
synchronous under the single-threaded App Router, pins the event loop, so even
the "served immediately" stale body only reaches the client once the rebuild
finishes. Net effect: ~50 s on essentially every call.
Measured on the VPS (1 cold build + 5 sequential requests):
cold = 48.93s
req1 = 3.19s ← the only hit
req2 = 50.51s req3 = 50.93s req4 = 47.43s req5 = 52.28s
Raise the default to 60 s. A short TTL is redundant with the invalidation this
cache already has: `invalidateDbCache()` bumps `modelCatalogCacheVersion` on
every settings/connections/combos/pricing write and
`dropCatalogCacheIfStateChanged()` drops the whole cache the moment it moves, so
post-write freshness never depended on the TTL. What the TTL governs is the
"nothing was written" case, where replaying a body built seconds ago is the
point of the cache. 60 s matches the ceiling the settings schema already allows
for the override, so the default can never exceed what an operator may configure.
The value that actually takes effect is the settings default, not the constant:
`catalog.ts` resolves `dbSettings.cache?.modelCatalogCacheTtlMs ??
CATALOG_CACHE_TTL_MS_DEFAULT`, and the `??` never falls through while a settings
default is declared. Raising only the constant is a silent no-op — which is how
the first attempt at this fix measured identical to no fix at all. All three
declarations are aligned and a test pins them together.
* docs(changelog): add fragment for #8833
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* test(quality): fail loudly when a source-scanning guard is negative-only
A negative guard — assert.doesNotMatch(src, /x/) or src.includes(x) === false —
passes against an empty string. Once the code it guards is extracted into another
file the parent no longer contains the string, so the assertion keeps passing while
protecting nothing. The regression coverage is deleted with no test turning red,
which is exactly the failure mode the god-file decomposition campaign (#8617) is
about to trigger 90-odd times.
Adds tests/unit/source-scanner-guards.test.ts: a hard gate (no baseline, no
allowlist) requiring every test variable bound to project source to carry at least
one positive anchor. Classification runs on logical statements with strings, regexes
and comments blanked out, so a guard wrapped across lines cannot slip past — that
folding is what exposed 3 of the 7 violations.
Fixes all 7 violations across 6 files with one stable top-level export anchor each.
Two were security scope guards held only by multi-line negative assertions: the SSRF
guards on /api/sync/initialize (#323) and the proxy-bypass guards on chatHelpers.ts
and chatCore.ts (#3226) — the latter anchored on handleChatCore precisely because
that file is a decomposition target.
Adds tests/_helpers/readSrc.ts, a repo-root-relative reader that throws on a missing
or empty file instead of returning "".
Refs #8617
* docs(changelog): number the fragment for #8619
* chore(skills): sync cli-backup-sync SKILL.md with catalog
Same tip fix as #8657 so Merge integrity is green without waiting for
that PR to land. Regenerated via generate-agent-skills --apply.
file-size: apiKeys.ts 1518 -> 1529 (#8805, treating cx/* and codex/* as
equivalent provider prefixes in API-key model permissions) and chatCore.ts
5006 -> 5020 (#8806, passing the real response payload into plugin onResponse
hooks instead of a hardcoded {status:200}). Both extend existing call sites
rather than adding a branch.
stryker: account-fallback-cf1010-no-retry-8775.test.ts covers
accountFallback.ts but was missing from tap.testFiles, which would redden
Fast Quality Gates on every subsequent PR.
#8595 (compact Responses multi-turn images before the context hard-reject)
grows open-sse/handlers/chatCore.ts 4955 -> 5006. The growth is irreducible at
the existing compaction chokepoint: a last-resort retry against the concrete
token budget plus the estimateFinalInputTokens helper, both wired into the
pre-existing call site rather than a new branch. Covered by
tests/unit/8560-responses-image-compaction.test.ts.
* fix(client): rewrite absolute fetch/EventSource paths under basePath
Absolute browser calls like fetch("/api/...") and new EventSource("/api/...")
do not honor Next.js basePath, so subpath deploys (OMNIROUTE_BASE_PATH) break
dashboard health checks, settings APIs, and SSE unless a reverse proxy rewrites
the domain root.
- Add withBasePath / getDeployBasePath helpers
- Install ref-counted fetch + EventSource rewrite when basePath is set
(same pattern as installDashboardCsrfFetch)
- Mount BasePathNetworkProvider at the root so login works too
- Mirror OMNIROUTE_BASE_PATH to NEXT_PUBLIC_OMNIROUTE_BASE_PATH for the client
- Document in .env.example; unit tests for rewrite rules
* docs(changelog): add fragment for #8515 basePath client fetch
* test(client): move basePath tests into a scanned dir and fix no-op call-shape asserts
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(client-sweep-8515): restore CHANGELOG #8471 bullet and fix basePath TS2322
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: rqzbeh <rqzbeh@users.noreply.github.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
#8593 registered bin/cli/utils/ensureAndroidCacheDir.mjs in
PACK_ARTIFACT_REQUIRED_PATHS so the Android/Termux cache module cannot silently
drop out of the npm tarball. Three test files read that list; only
pack-artifact-entrypoint-closures.test.ts derives it dynamically. This one
hardcodes the expected set, so it went red on a correct change.
Adding the entry here, not relaxing the assertion — a hardcoded fixture is what
makes an accidental REMOVAL from the required-paths list loud, which is the
whole point of the guard.
* refactor(sse): extract combo dispatch prelude into combo/dispatchPrelude.ts
Pure move, no behaviour change. First of ~7 PRs decomposing the combo.ts
god-file (#3501).
handleComboChat evaluates a series of dispatch branches before it ever
reaches target resolution or the sequential attempt loop. None of them
iterate targets in priority order or need the failover/retry/credential
gate machinery that follows, so they move to a leaf:
- context-cache pin routing (Fix#679), including the
pinIsDurablyUnhealthy / isPinnedModelDurablyUnhealthy health gate
- fusion panel dispatch + the #6455 misconfiguration warn
- pipeline chaining
- nested combo-ref execute-mode runtime-unit dispatch
Only the chaos and round-robin hand-offs stay inline (11 and 13 lines);
extracting those would be pure indirection.
open-sse/services/combo.ts 3642 -> 3341 (-301)
open-sse/services/combo/dispatchPrelude.ts: 619 (under the 800 cap)
Each helper keeps the fall-through protocol the inline blocks had: return
a Response to OWN the request, return null to fall through. A flipped
null/Response would silently bypass the whole combo strategy, so the new
tests pin both directions for every branch.
combo.ts re-exports pinIsDurablyUnhealthy so combo-pin-health-gate.test.ts
keeps resolving. The leaf takes handleComboChat as a `runCombo` parameter
instead of importing it, so combo/ keeps zero back-edges into combo.ts.
Complexity-neutral: the first cut added +3 violations (two
max-lines-per-function, one complexity) inside the new leaf, so
evaluatePinnedResponse, orderRuntimeUnits, recordRuntimeUnitStickySuccess
and buildBaseOptions were split out. check:complexity now measures 2169
and check:cognitive-complexity 956 — identical to the pristine base.
* test(sse): close the dispatch-prelude coverage holes found by mutation testing
An adversarial mutation audit of the suite added in the previous commit
found it guarded the fall-through protocol well but asserted almost
nothing about what the helpers do once they OWN the request. 5 of 12
seeded mutations survived. Worst case: deleting the pinned-model
dispatch call outright left all 12 tests green.
Three holes, now closed (8 tests -> 20):
Hole A — the honored-pin path had zero coverage. Both existing pin tests
DROP the pin, so the dispatch, the 200-but-empty quality gate, the
[408, 429, 500, 502, 503, 504] failover list and the catch(pinErr)
branch were unguarded — exactly the logic the 2026-06-21 / 2026-06-22
incident comments call load-bearing. Adds five tests over a seeded
healthy provider connection so the pin is actually honored.
Hole B — orderRuntimeUnits was only ever driven with `priority`, which
is a no-op through it. Four of five strategy branches could be deleted
with nothing failing. Adds round-robin rotation and weighted sticky
ordering tests.
Hole C — recordRuntimeUnitStickySuccess never did anything under test:
both its guards need weighted/round-robin, so an early return changed
nothing. Covered by the new sticky-batch test.
Verified by re-running the mutations rather than assuming: all 7 that
previously survived (delete-pin-dispatch, serve-despite-failed-quality,
never-fail-over-on-transient, rr-counter-not-advanced, rotation-removed,
weighted-sticky-skipped, sticky-recording-no-op) are now killed.
The first sticky-batch test I wrote was itself vacuous — asserting "same
unit twice" holds equally when the recording helper is stubbed out, since
nothing advances the counter either. It now asserts the batch runs out
and rotation resumes on the third dispatch, which is what actually
distinguishes the two.
Also restores API_KEY_SECRET in test.after; it was set at module load and
never put back, inconsistent with the DATA_DIR handling beside it.
* fix(ci): teach known-symbols gate the relocated fusion/pipeline dispatch
The combo sub-check of check:known-symbols asserts every canonical routing
strategy has a real dispatch branch. It scanned a hardcoded file list and
matched only `strategy === "..."`, so the prelude extraction tripped it twice:
[combo] 2 estratégia(s) canônica(s) sem branch de despacho em combo.ts:
✗ fusion
✗ pipeline
Both branches are still wired — they just moved to combo/dispatchPrelude.ts and
took the early-return guard form `if (strategy !== "fusion") return null;` that
extracting a branch into a `tryXDispatch()` leaf naturally produces.
Two changes, both extending existing precedent (the list already carries the
Block J leaves for the same reason):
- register combo/dispatchPrelude.ts in comboDispatchFiles
- widen the extractor to `strategy [!=]== "..."` so the inverted guard counts
Loose `==`/`!=` stay rejected, and no `handledNotCanonical` fallout: the gate
now reports 20 canonical strategies, all 20 via despacho.
* chore(ci): register combo-dispatch-prelude test in stryker tap.testFiles
check:mutation-test-coverage --strict failed once the known-symbols fix let
Fast Quality Gates advance to it:
✗ 2 covering unit test(s) across 2 module(s) are missing from
stryker.conf.json tap.testFiles
open-sse/services/combo/comboStructure.ts
open-sse/services/combo/rrState.ts
The new tests/unit/combo-dispatch-prelude.test.ts exercises both modules, and
both are already in stryker's mutate list, so without the registration its
mutant kills would not have counted toward the nightly mutation gate.
Note (unchanged, still out of scope): combo/dispatchPrelude.ts itself is not in
stryker's `mutate` list. Adding it would widen the nightly mutation surface,
which is a separate call from fixing this drift.
* docs(changelog): add fragment for #8582 combo dispatch prelude
* refactor(sse): extract combo target resolution into combo/targetResolution.ts
Pure move, no behaviour change. Lifts the target-resolution stage of
handleComboChat — everything between the dispatch prelude and the attempt
loop — into a new leaf, open-sse/services/combo/targetResolution.ts.
Moved verbatim: provider-wildcard expansion, weighted step-group resolution
+ sticky-weighted eligibility, request-tag routing, the known-context-overflow
early return, the smart/pipeline-enabled auto dispatch, auto-strategy
ordering, per-strategy ordering, cache-strategy affinity, session stickiness,
eval scores, request-compatibility + context-requirement filters, task-aware
reordering, prompt-cache affinity, and the priority-strategy pre-screen.
The three early exits become an { earlyResponse } result so the host decides
to return them (same pattern as resolveAutoStrategyOrder). The values the
attempt loop still reads — orderedTargets, stickyWeightedLimit,
getWeightedStepKeyForTarget, the session-stickiness result and preScreenMap —
are returned instead of closed over. Loop config (maxRetries, retryDelayMs,
fallbackDelayMs, maxSetRetries, setRetryDelayMs) stays in combo.ts.
buildAutoCandidates is dependency-injected because it lives in combo.ts, so
the leaf keeps zero back-edges into its host.
combo.ts 3640 -> 3321 lines; new leaf 484 lines (under the 800 cap).
Part of the #3501 god-file decomposition campaign.
* refactor(sse): split targetResolution into stage helpers, ratchet combo.ts file-size baseline
Follow-up to the target-resolution extraction: the moved region landed as one
311-line function, which converted inline code inside the (already-violating)
handleComboChat into a NEW separately-counted violating function — check:complexity
2169 -> 2171 and check:cognitive-complexity 956 -> 957.
Split resolveComboTargetPipeline along its natural stage boundaries into 14
helpers (wildcard expansion, weighted eviction/eligibility/sticky-key/selection,
step-key mapper, context-overflow response, pool-size log, smart-pipeline dispatch
and its fall-through logger, strategy ordering, continuity filters, task-aware
ordering, prompt-cache enablement/first-target protection/affinity stage). Each
stage takes the previous stage's output and returns the next; still a pure move.
The leaf now contributes ZERO complexity, max-lines-per-function and
cognitive-complexity violations. Both ratchets are back at base 4053e2314 values:
check:complexity 2169, check:cognitive-complexity 956. (Both still print RED
against their frozen ceilings 2130/951 — pre-existing base-red per #8580.)
Also ratchets ONLY the open-sse/services/combo.ts entry in
config/quality/file-size-baseline.json from 3642 to 3322, with a justification
note in the file's existing style. No sweep of unrelated entries.
* chore: stack targetResolution on dispatchPrelude tip, rebank + skills
Rebased onto refactor/combo-dispatch-prelude. Keep both leaves in
check-known-symbols. Regenerate file-size baseline; sync agent skills.
* fix(sse): restore #8494 capability fail-closed after targetResolution extract
Stacking targetResolution onto the dispatchPrelude tip dropped the #8488/#8494
compatFilterFailOpen wiring: hard capability filters emptied the pool into a
generic 404 no_executable_targets, and fail-open never re-admitted the pool.
Restore describeCapabilityFilterExhaustion earlyResponse in
applyContinuityFilters and the matching round-robin path, then rebank the
file-size baseline for tip growth the incomplete prior rebank missed.
* fix(sse): realign model-lockout cooldown options with the post-#8254 type
This branch predates #8254, which renamed the recordModelLockoutFailure option
`exactCooldownVerified` -> `exactCooldownIsUpstreamReset` and changed combo.ts's
predicate from `lockoutHintVerified` (#8393's `lockoutHintMs > 0`) to
`lockoutHintMs > mlSettings.baseCooldownMs`. Rebasing onto the current tip brought
the renamed type without updating these two call sites, so typecheck:core failed
with TS2353 at both.
Restores the base expression verbatim rather than re-wiring `lockoutHintVerified`
under the new name. The base predicate is the correct one: selectLockoutCooldownMs
returns the parsed hint ONLY when `lockoutHintMs > baseCooldownMs`, and otherwise
returns 0 or a synthetic baseCooldownMs — so `lockoutHintMs > 0` would mark a
synthetic cooldown as an upstream reset and let it bypass the #7940 maxCooldownMs
cap, which is the bug #8254 fixed.
---------
Co-authored-by: MumuTW <johnsxn.us@gmail.com>
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
file-size: nine frozen entries could not absorb the combined result of the
31-PR train. Two distinct causes, kept apart in the baseline note on purpose:
(1) GENUINE irreducible growth at existing chokepoints —
providerLimits/auth (#8632), rateLimitManager (#8616),
models-catalog-route.test (#8610).
(2) COLLISION with #8585, which banked shrinks measured on the pre-train
release tip while 30 sibling PRs in the SAME train grew those files
again — chat/accountFallback (#8628), chatCore (#8613),
videoGeneration (#8581), imageGeneration.
Ceilings re-pinned to the post-merge tip. #8612 (also in this train) automates
shrink-banking so this self-inflicted drift stops recurring.
stryker: three covering unit tests were missing from tap.testFiles —
isLocalStreamLifecycleError-abort-shape (circuitBreaker.ts, a shared base-red
that was reddening Fast Quality Gates on every open PR),
noauth-autocombo-lockout-7623 (accountFallback.ts) and
kimi-quota-reset-recovery (auth.ts), the latter two landed with this train.
* chore(skills): regenerate cli-backup-sync SKILL.md to match catalog
check:agent-skills-sync was failing on release/v3.8.49 tip because the
generated SKILL.md still documented backup-status flags the catalog no
longer exposes. Re-run generate-agent-skills --apply (9-line delete only).
* docs(changelog): add fragment for #8657 agent-skills sync
* fix(docker): honor OMNIROUTE_BASE_PATH behind reverse-proxy subpaths
Next.js basePath is compile-time state; Docker now records the baked value,
forwards the env var as a build-arg, patches root-path images at container
start when needed, and probes health under the active subpath.
Hard Rule #13: scripts/docker/patch-basepath.sh and the entrypoint invoke Node
with a fixed argv; OMNIROUTE_BASE_PATH is read from process.env only — never
interpolated into sed/awk.
Closes#8600
* fix(docs): unblock CI for Docker basePath guide
Describe the build-time basePath marker as a sentinel file instead of a
fabricated env var, and replace the unsupported ```env fence with bash so
fumadocs/Shiki can compile DOCKER_GUIDE.md during DAST smoke.
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(docker): add changelog fragment for #8615 basePath bundle patch
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* feat(ci): automate ratchet shrink-banking on the release branch (#8584)
The quality ratchet is only half automatic, and it is the wrong half. Raising a
cap is a manual JSON edit that takes ten seconds and is the fastest way to unblock
a red PR. Lowering one requires someone to run `--update` and commit the result —
and no workflow does: grepping `.github/workflows/` for `--update` finds only
wiki-sync.yml (unrelated) and ci.yml's check-quality-ratchet.mjs --require-tighten
(a different script against a different metric).
Measured on release/v3.8.49 at 4053e2314: 18 frozen files already at or under the
800-line new-file cap, the worst at 132x (src/shared/validation/schemas.ts, 19
lines carrying a 2,523 cap); the complexity ceiling walked 1794 -> 2169 across ~37
rebaseline notes with exactly one decrease (-1); "tighten via --update next cycle"
written 31 times and honoured once in six weeks. A cap that outlives the code that
earned it converts every completed decomposition into a growth allowance for
whoever edits that file next.
New job `bank-ratchet-shrinks` in nightly-release-green.yml measures the active
release branch, runs the two shrink-only `--update` paths, and opens ONE
always-current PR with the result. Schedule/dispatch only, deliberately not on
push: banking has no latency requirement, while a per-merge run would rebuild the
PR branch during merge campaigns and pay for a full ESLint walk each time.
Detection stays on push (release-green); only banking is batched. The job never
pushes to release/* — a human merges, so a bad measurement cannot land unreviewed.
scripts/quality/verify-ratchet-bank.mjs is the hard guarantee that the automation
can only ever write downward. It diffs the post-`--update` tree against HEAD and
aborts the job before a commit exists — opening no PR — unless every change is a
frozen/testFrozen entry lowered or removed, `count` lowered, or
cognitiveComplexity.value lowered. Raising a number, adding an entry, changing
cap/testCap, or deleting/rewriting a `_rebaseline_*` note all fail. A bot that
could raise a cap would be strictly worse than the status quo.
Verified both directions against the real baselines: --update + verifier reports
77 lowered / 14 removed / nothing raised, exit 0; hand-raising chatCore.ts to 9999
and cap to 1200 is rejected with exit 1. 22 unit tests cover each way the
automation could go wrong.
No product code changes.
* chore(skills): sync cli-backup-sync SKILL.md after rebase onto tip
* fix(sse): restore task-aware routing config on restart (#8601)
The T05 Task-Aware Smart Routing config was persisted to settings.taskRouting
by PUT /api/settings/task-routing but never read back, so it silently reverted
to enabled:false + the hardcoded default model map on every restart.
Two root causes, both fixed:
- No boot hydration existed. Adds hydrateTaskRoutingConfig(settings), wired into
src/instrumentation-node.ts next to the Thinking-Budget restore (#5312). It
accepts either the JSON string the route persists or an already-parsed object,
and fails open on malformed values. applyRuntimeSettings does not cover this
key, same as the Global System Prompt (#2470).
- The config lived in a plain module-level `let`, which is duplicated per module
graph — a boot hydration would have landed on the instrumentation graph's copy
and never reached the one src/sse/handlers/chat.ts reads. This is the exact
break #5312 fix-A hit on the VPS. Moves the store to the globalThis pattern
already used by thinkingBudget.ts and systemPrompt.ts.
Runtime stats are never restored from the persisted blob.
Note the hydration is wired into instrumentation-node.ts, not the unused
src/server-init.ts.
* docs(changelog): add fragment for #8604 task-routing boot restore
* fix(sse): route task-aware defaults by intent, guard fitness pattern order (#8602, #8603)
Two related defects in the hand-maintained model-quality tables.
#8602 — DEFAULT_TASK_MODEL_MAP hardcoded literal provider/model ids
(openai/gpt-4o, gemini/gemini-2.5-flash-lite, deepseek/deepseek-chat, ...).
Wrong twice over: the ids rotted by a generation or two, and applyTaskAwareRouting
overwrites body.model directly, so a literal target skipped auto-combo's 13-factor
scoring (quota, circuit-breaker health, cost, latency, stability), connection
cooldown and model lockout — hard-failing for any operator with no connection for
that provider. Refreshing the strings would only reset the rot clock, so the
defaults now name auto/* INTENTS that resolve against the operator's actually
connected backends:
coding -> auto/coding
analysis -> auto/reasoning
vision -> auto/vision
summarization -> auto/chat:fast
background -> auto/chat:cheap
creative and chat stay pass-through. Operators can still pin a specific model via
PUT /api/settings/task-routing; only the shipped defaults change. No provider/model
literal remains in the module.
#8603 — the pattern-shadowing fix LANDED UPSTREAM while this PR was open
(9f5be229b, Train 1D). lookupStaticFitnessTable now ranks patterns longest-first,
so gpt-4o-mini no longer inherits gpt-4o's 0.9 and deepseek-v3.2 no longer inherits
deepseek-v3's 0.85. This PR therefore no longer changes that behaviour — the
upstream scan is kept verbatim.
What remains for #8603 is the regression guard. The resolution chain hits the DB
(user_override / arena_elo / models.dev tier) before reaching layer 4, so asserting
the ordering through getTaskFitness would depend on DB fixture state. The layer is
exposed as getStaticFitnessTableScore and pinned directly by
taskFitness-pattern-order-8603.test.ts (7 cases), so the guarantee survives future
edits to FITNESS_TABLE. Those 7 cases were written against this PR's original
implementation and pass unchanged against the upstream one — independent
confirmation that the two are behaviourally equivalent.
* docs(changelog): add fragment for #8605 task-routing intent + fitness order
Pin the unit suite to a temp data directory before imports so getTokenLimit
resolves against the registry fallback instead of a developer models.dev sync.
