`omniroute login antigravity` already runs the OAuth where it actually works — the
operator's own machine, the only place Google's firstparty/nativeapp loopback
resolves — but it stopped at PRINTING a credential blob to copy into the remote
dashboard by hand.
Every piece needed to close that loop was already in place:
- `omniroute connect <host>` saves an admin-scoped token in the active context;
- `apiFetch()` injects that context's baseUrl + Bearer automatically;
- `/api/oauth` requires admin scope (src/server/authz/accessScopes.ts) and stays
remote-reachable — routeGuard.ts loopback-gates only `/api/oauth/cursor/auto-import`,
with an explicit comment that the rest must remain reachable;
- `isAuthenticated()` accepts a Bearer management token;
- `/api/oauth/<provider>/paste-credentials` already decodes a blob and persists.
So the CLI now POSTs the blob itself whenever the active context points at another
machine. No paste, and no SSH tunnel.
What it deliberately does NOT do is make the push mandatory. This helper exists
because it needs no route to the VPS at all — it talks only to Google, so it works
from behind a firewall. A failed push therefore falls back to printing the blob
rather than discarding an authorization the operator just completed in a browser.
`--no-push` forces the old behaviour, `--push` forces delivery, `--context <name>`
targets a specific install.
A successful push does not echo the blob: it wraps a refresh token and it already
landed. Printing it would only widen the exposure.
Note for the follow-up: `oauth start --provider antigravity` cannot substitute for
this. `runBrowserFlow` asks the SERVER to start the flow and then polls the server,
so the callback still has to reach the server's loopback — it hangs on a remote
install exactly like the dashboard does.
* 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>
Adds GET /api/usage/cache-health and a Cache Health tab under
/dashboard/analytics, both backed by a pure summary over the cache columns
already present in call_logs.
Motivated by a production diagnosis where the aggregate ratio was actively
misleading. The window read 24.8M cached tokens and wrote 9.5M — a
write/read of 0.385, which reads as merely mediocre. The actual shape was
very different: the median call wrote 848 tokens while 18% of the calls
carried 94% of every written token, and two models in the same window sat
at 0.13 (Sonnet) and 0.51 (Opus). Averaging hid all three facts.
So the summary reports what the average cannot: the distribution
(p50/p90/p99), the concentration (how few calls carry how much of the
write), and the per-model split. The heavy-write threshold is relative to
the window (10x the median, floored at 1024) because a cutoff tuned for
130k-token conversations reports nothing at all on 2k-token ones; 1024 is
the minimum Anthropic bills for cache creation, below which a write carries
no signal.
Calls that neither read nor wrote are counted separately from thrash — a
route that does not cache is an absence of caching, not a sick cache — and
only successful calls are summarized, since a 4xx/5xx never reached the
provider cache and would dilute the ratio.
Tests cover the summary (8) and the route (6, against a real SQLite so the
WHERE clause itself is exercised), including that an internal failure
answers 500 without leaking the stack trace, the SQL text or a table name.
The handler awaited the DELETE and never looked at the response:
if (!confirm(t("removeConfirm"))) return;
await fetch(`/api/quota/pools/${id}`, { method: "DELETE" });
await mutate();
When the request failed — a 401 from an expired session, a 500, a dropped
connection — the page revalidated, the card stayed exactly where it was, and
nothing was shown. From the operator's side the click was indistinguishable
from a misclick, so the natural reaction is to click again. The page had no
error surface at all, unlike the sibling flow in the API manager which already
checked res.ok and rendered the message.
Adds a dismissible alert above the header, fed by both failure paths: a
non-ok response (appending the API's message when it sends one) and a thrown
request, which has no response to read. The alert clears on the next attempt,
so a transient failure does not leave a stale error on screen.
Reported against two boxes on 2026-07-28. The delete itself was working there
— the audit log shows the pools were removed — which is exactly what this
change makes visible either way.
Tests (vitest/jsdom, 5): non-ok response, thrown request, success path stays
quiet and still revalidates, a dismissed confirmation issues no DELETE at all,
and an earlier error clears once a later delete succeeds.
* docs: restore the Polish API_REFERENCE removed by #8823
`docs/reference/API_REFERENCE.md` lists Polish in its language index, but the
target file no longer exists: #8823 ("replace outdated Polish docs with
translation from latest English") deleted
`docs/i18n/pl/docs/reference/API_REFERENCE.md` without writing a replacement.
Every other one of the 31 linked languages still has the file.
That leaves `check:doc-links` red — and because the Docs Gates job only runs on
pull requests, the branch itself reports green while carrying the break. The
first PR opened afterwards is what surfaces it, and it blocks every PR until
fixed.
Restored from `71c5a7592^`. The content is the pre-#8823 translation, which is
by definition outdated relative to the English source — but an outdated
translation behind a working link is strictly better than a 404, and the next
translation pass will overwrite it. `check:doc-links` now passes (813 internal
links, 0 broken).
The same commit also removed four other Polish files
(`cloudflare-zero-trust-guide.md`, `features/context-relay.md`,
`reference/CLI-TOOLS.md`, `reference/ENVIRONMENT.md`). None of them is linked
from a scanned index, so none breaks the gate; they are noted here so a later
translation pass can decide whether they should come back too.
* chore(quality): freeze the pre-existing exhaustive-deps error in ProviderAccountRoutingCard
Second half of unbreaking the base. `lint:json --max-warnings 0` fails on
`ProviderAccountRoutingCard.tsx:87` — `save` calls `load()` but declares only
`[providerKey]`. Same root cause as the broken doc link in the previous commit:
the Lint job is skipped on pushes to `release/**`, so the branch reports green
while carrying the violation, and every PR inherits it.
Frozen rather than fixed: adding `load` to the dependency array changes when
the callback is recreated in a settings component, and that belongs in a change
that can verify the card's behaviour. The entry keeps the gate meaningful for
genuinely new warnings instead of leaving it red for everyone.
With this and the restored Polish file, both gates pass on the base again.
* fix(reasoning): sanitize streamed K3 think tags
* refactor(stream): move think-tag helpers into thinkTagParser leaf module
open-sse/utils/stream.ts is frozen at 2887 lines with zero headroom, and the
kimi-coding-apikey think-tag handling added here pushed it to 2951. The parsing
half of that work has no SSE dependency, so it moves to thinkTagParser.ts (an
unfrozen leaf): the open-tag lookahead predicate and the end-of-stream flush
delta assembly. stream.ts keeps only the SSE envelope - enqueue, payload
collection, logging.
Getting back under the frozen ceiling needed more than just the PR's own
added lines, since even the fully self-gating helpers still cost a handful of
call-site lines stream.ts has zero room for. Along the way this also
deduplicates a synthetic chat-completion-chunk literal that was copy-pasted
three times in stream.ts (textual tool-call flush, think-tag flush, terminal
finish_reason synthesis) into one buildSyntheticChatChunk() in
streamHelpers.ts - pure DRY, no behavior change.
Behavior is unchanged: same tests, same counts.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: rinseaid <rinseaid@rinseaid.net>
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Co-authored-by: diegosouzapw <8016841+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.
CodeQL js/polynomial-redos (alerts #765/#766).
`/\/+$/` has no left anchor, so the engine retries the match at every
start offset and each attempt re-walks the whole slash run before failing
`$` — O(n^2) on a connection baseUrl made of many slashes. Measured on
the vulnerable code: 10k slashes = 102ms, 30k = 968ms, 60k = 4028ms
(clean quadratic); through the public resolvers the same input took 22s.
providerSpecificData.baseUrl is operator-supplied config and reaches the
trim via isFamilyPresetUrl() -> normalizeEndpoint() and both resolve*Url()
helpers, so the input is reachable.
Replaces all three identical occurrences with a linear charCodeAt scan.
CodeQL only flagged two of them; the third (resolveAlibabaProviderModelsUrl)
carries the same defect and is fixed here rather than left behind.
Behavior is unchanged: every trailing slash is still removed (not a bounded
subset), interior slashes are preserved, and an all-slash string still
collapses to empty — asserted by the new behavior test.
* fix(api): enforce image generation API key auth
* fix(api): align image route auth guard with clientApiPolicy
The route-level guard added for image generation was stricter than the
authz middleware that already fronts /api/v1/* (src/proxy.ts →
clientApiPolicy), so requests the pipeline admits were 401'd by the
handler:
- A cookie-authenticated dashboard session was rejected under
REQUIRE_API_KEY=true. The dashboard Media page
(dashboard/cache/media) and the Playground call these routes with a
session and no Bearer — the same mismatch already fixed for
/api/playground/presets.
- A presented invalid key was rejected even with REQUIRE_API_KEY=false,
where clientApiPolicy (#2257) and the sibling /v1/embeddings and
/v1/web/fetch routes degrade a stale CLI key to anonymous instead.
Extract the shared guard into shared/utils/clientApiRouteAuth so both
image routes (and future /v1 handlers) mirror the middleware contract
instead of re-deriving it, and drop the now-dead auth imports.
Also switch the call-log attribution fallback back to `||`: with `??`,
an empty-string apiKeyId/apiKeyName would be persisted verbatim and
would block the request-scoped context, which the previous
`entry.apiKeyId || null` never did.
Tests: cover the dashboard-session and keyless-mode-invalid-key
branches, and split the auth/attribution cases into
image-generation-route-auth.test.ts to stay under the 800-line
new-test-file cap.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: alexey.nazarov@softmg.ru <alexey.nazarov@softmg.ru>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
removeNativeModules() was called with a hardcoded ".next" path while the actual
distDir is NEXT_DIST_DIR (".build/next" by default). Because the function
early-returns when the directory does not exist, the cleanup silently no-opped
and the plain-Node-ABI better-sqlite3 copy produced by `next build` survived
into the packaged app.
At runtime the standalone server runs under ELECTRON_RUN_AS_NODE, so it needs
the Electron ABI (148 for electron 43). Loading the ABI-137 copy fails with
ERR_DLOPEN_FAILED, the app falls back to the sql.js WASM driver, the connection
is closed and retried in a loop, WASM memory is never reclaimed and the process
OOMs -> HTTP 500 on every route.
Also adds assertNoStaleHashedNatives() so a wrong baseDir fails the build
instead of silently shipping a broken installer. This has regressed at least
twice (#1497 with ABI 127 vs 145, #7082/#7681 with 137 vs 148).
Refs #7082, #7681, #1497, #8792. Supersedes the abandoned #7123.
Plugins always received a hard-coded {status:200} stub, so hooks like
request-logger never saw response bodies. Forward translated JSON for
non-streaming completions and a streamed flag for SSE without reading
the body twice.
Closes#8711
Dashboard Codex restrictions use the public cx/ alias while /v1/responses
normalizes bare Codex IDs to codex/, so allow/block checks falsely 403'd.
Expand permission candidates via the provider registry alias map.
Closes#8803
Extract ModelTable from the charts god-file and drive header clicks through a
single sort state object plus a pure sorter so column toggles reliably reorder
rows. Compute missing share pct from summary totals when the analytics API
omits it.
Api-key 403 bodies with Cloudflare error 1010 / browser_signature_banned /
retryable:false were treated as short AUTH_ERROR cooldowns, so the chat loop
waited ~21–33s before falling through. Return cooldownMs:0 so the tier fails
fast without permanently banning the account.
Strict contextFilterMode excluded every target whose context limit was missing
from the capability catalog, so otherwise-executable combos returned 404
no_executable_targets. Restore unknown-context targets when no known-good
survivor remains, surface context_requirements_exhausted from targetResolution,
and keep the empty-pool payload in pinRecovery after the #8592 split.
#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>
* fix(hyperagent): sticky thread for agentic tool loops (Claude Code)
Follow-up to #7994. When a reverse-conversion proxy rewrites assistant
text between turns (Intent+JSON -> native tool_calls -> re-serialized tool
text), conversationFingerprint(prefix) no longer matches the key stored
after turn 1, so HyperAgent created a new thread and multi-turn tool
results appeared as a cold start.
- Key sticky sessions by root user task (normalize pin wrappers)
- Flatten Anthropic tool_use / tool_result for lastUserText + fingerprints
- Regression tests for mutated-assistant tool loops
Tests: tests/unit/executor-hyperagent.test.ts (19/19)
* chore(quality): rebaseline for PR #8470 own-growth (hyperagent sticky thread)
open-sse/executors/hyperagent.ts grows 937->1026 lines and gains one new
cognitive/cyclomatic-complexity violation (extractMessageText, from the
new Anthropic tool_use/tool_result flattening branches) on top of
inherited base-tip drift already present on origin/release/v3.8.49
(file-size was already at cap; cognitive-complexity 951->956 and
cyclomatic-complexity 2130->2169 drift predates this PR). Rebaselined
file-size to 1026, cognitiveComplexity to 957, complexity count to 2170,
matching measured values on the merged tree.
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
---------
Co-authored-by: ikelvingo <im.kelvinwong@gmail.com>
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
Fixes#8788.
- Added 'UND_ERR_SOCKET' to PROXY_UNREACHABLE_ERROR_CODES so socket disconnects and mid-stream closes are properly tagged with code PROXY_UNREACHABLE and errorCode proxy_unreachable.
- Ensured tagProxyUnreachable normalizes error code to PROXY_UNREACHABLE and errorCode to proxy_unreachable when catching socket-level disconnects.
- Added test in proxyfetch-undici-retry.test.ts verifying UND_ERR_SOCKET classification.
* fix(sse): compact Responses multi-turn images before context hard-reject (#8560)
Codex Desktop sessions near the 372k input cap were rejected on the second
inline image because compressContext no-op'd on Responses input[] and never
pruned older vision turns. Adapt via bodyAdapter, prune older images while
keeping the latest, and run last-resort compaction before the budget check.
* docs(env): document CONTEXT_KEEP_LATEST_IMAGES for #8560
Keep check:env-doc-sync green after the context image-pruning override.
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Co-authored-by: diegosouzapw <8016841+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
Check if model_capabilities table exists in SQLite before running SELECT query in loadModelCapabilities to prevent SQL error when the table has not been created yet.
Co-authored-by: Austin Liu <austinliu@Austins-MacBook-Air-3.local>
`handleChatCore` returns a union that includes a bare `Response` alongside the
`{ success, response, … }` envelopes — early returns that never build one.
responsesHandler read `result.success` / `result.response` straight off it, so
three diagnostics fired on the `Response` arm, which has neither.
Added an `instanceof Response` guard before the envelope checks. The outcome is
unchanged: a bare Response already fell through `!result.success` (undefined,
so truthy under `!`) and was returned as-is; it is now returned one branch
earlier, explicitly.
208 -> 205, zero new, on a line-number-agnostic diff of the full tsc error set.
The other two diagnostics in this file are left alone on purpose. Declaring
convertResponsesApiFormat's return type fixes them, but immediately surfaces the
next masked error at the handleChatCore call — `onStreamFailure` is declared
required in that parameter object while responsesHandler has always omitted it
in production. Fixing that means touching chatCore's signature, which belongs
with the chatCore work rather than a three-line guard. Measured 5 fixed / 1 new
and reverted, keeping the zero-new invariant.
No new tests: the guard adds a branch that returns the same value the fall-
through already returned, and the bare-Response path is exercised by the 400
tests in the responses suites, all passing.
Co-authored-by: backryun <busan011@ormbiz.co.kr>
All five diagnostics in src/lib/batches/dispatch.ts are the same:
Type '(request: any, context: any) => Promise<any>' is not assignable to
type 'BatchRouteHandler'.
Target signature provides too few arguments. Expected 2 or more, but got 1.
`withInjectionGuard()` returns `guardedHandler(request, context: any)` with the
second parameter required, so every route it wraps advertises arity 2. The batch
dispatcher's `BatchRouteHandler` is `(request: Request) => …`, and TS rejects
assigning a function that needs an argument the caller will never supply.
The declaration was wrong about its own runtime. `dispatch.ts:48` already calls
`handler(request)` with one argument, and has been doing so in production;
`context` is only forwarded to the inner handler, where routes that do not read
it get `undefined`. Marking it `context?: any` states what was already true.
208 -> 203, zero new, on a line-number-agnostic diff of the full tsc error set.
One character; nothing executable changed.
No test added: the one-argument call path is the existing behaviour and is
already covered — embeddings-auth.test.ts and embeddings-route-apikeymeta-6929
call `POST(req)` directly through withInjectionGuard, which is exactly the arity
this now permits. 370/370 across the 43 injection-guard / batch / embeddings /
moderation suites; typecheck:core, eslint and check:file-size clean.
Co-authored-by: backryun <busan011@ormbiz.co.kr>
* fix(windows): request shell when spawning bare qoder binary name on Windows (fixes#8590)
Post Node CVE-2024-27980, spawn('qodercli', [], { shell: false }) fails with ENOENT on Windows when command is a bare binary name without extension. Enabling shell mode for bare command names allows cmd.exe to resolve .cmd / .bat wrappers from PATH.
* fix(windows): ensure windowsHide: true on open-sse qoder/devin child spawns
---------
Co-authored-by: Austin Liu <austinliu@Austins-MacBook-Air-3.local>
* 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
The `compat-build-26` job in nightly-compat.yml is the only place in the CI
matrix that runs `npm run build` on Node 26 (ci.yml pins CI_NODE_VERSION=24).
It failed every nightly with the runner-reclaimed signature ("The runner has
received a shutdown signal" / "The operation was canceled", no exit code),
always at the same Turbopack compile phase — the classic OOM-kill pattern on
the memory-constrained ubuntu-latest runner.
Root cause: Turbopack's native (Rust, off-V8-heap) allocation is not bounded by
--max-old-space-size and peaks far higher than webpack on OmniRoute's large
module graph (#6409), heavier still under Node 26. Raising the heap does not
help — the codebase's own documented escape hatch for RAM-constrained
environments is the webpack fallback (OMNIROUTE_USE_TURBOPACK=0; see
docs/reference/ENVIRONMENT.md and scripts/build/build-next-isolated.mjs).
Wire that fallback into the Node 26 compat build: it still validates the app
builds on Node 26 (the point of the job) at a much lower memory peak.
Turbopack-on-Node-24 stays covered by ci.yml's build job.
Adds a regression guard (tests/unit/nightly-compat-node26-webpack-8090.test.ts)
asserting the job keeps the webpack fallback so it cannot silently regress.
Class 1 of the triage (shard test failures) was already resolved by #8390,
#8386, #8381, #8383.
Closes#8090
Refs #6949#6409
