mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-07-31 20:32:20 +03:00
aecf2fccef67a2ecb2884279c724cefb24ef5396
351 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
MumuTW
|
0eeb8f45c0 |
refactor(sse): extract combo target resolution into combo/targetResolution.ts (#8592)
* 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
|
||
|
AmirHossein Rezaei
|
bb5cb51f3e |
fix(docker): honor OMNIROUTE_BASE_PATH behind reverse-proxy subpaths (#8615)
* 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> |
||
|
MumuTW
|
b676c5f826 |
feat(ci): automate ratchet shrink-banking so caps stop outliving their files (#8584) (#8612)
* 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
|
||
|
AmirHossein Rezaei
|
df9550fce9 |
fix(cli): prepare Next.js cache dir on Android/Termux before serve (#8593)
* fix(cli): ensure `~/.cache` is created and `XDG_CACHE_HOME` is set before Next.js loads on Android/Termux to prevent silent HTTP 500 errors due to instrumentation hook failures (#8519) * chore(quality): ignore XDG_CACHE_HOME in the env/docs contract scanner XDG_CACHE_HOME is an XDG Base Directory spec variable set by the OS or the operator, never OmniRoute product config — the same reason XDG_CONFIG_HOME is already ignored. The Android/Termux cache-dir preparation added here reads it to honor an operator-set cache location, which made check-env-doc-sync demand an .env.example/ENVIRONMENT.md entry for a variable we do not own. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> * build(pack): require bin/cli/utils/ensureAndroidCacheDir.mjs in the tarball bin/omniroute.mjs imports this module at startup to prepare the Next.js cache dir before serve on Android/Termux. bin/cli/ is only an allowlist PREFIX, so a file missing from the tarball would not fail the unexpected-paths check — it would ship a CLI that throws ERR_MODULE_NOT_FOUND on the very platform this change targets. Registering it makes the absence loud, same guard class as storageKeyProvision.mjs and versionFastPath.mjs. Caught by tests/unit/pack-artifact-entrypoint-closures.test.ts in the v3.8.49 merge-train. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
MumuTW
|
1d44ee00f8 |
refactor(sse): extract combo dispatch prelude into combo/dispatchPrelude.ts (#8582)
* 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 |
||
|
Diego Rodrigues de Sa e Souza
|
803e7373de |
feat(ci): block stale UI translations when an English value is rewritten (#8574)
Closes the gap that let #8463 ship. `oauthModal.googleOAuthWarning`'s English value was rewritten when the Antigravity login helper landed (#5203); 39 of 43 locales kept a translation of the PREVIOUS English, which told operators to "copy the full URL and paste it below" — a flow that cannot complete for that provider family. Non-English users read confident, wrong instructions for months and no gate noticed. None of the three existing gates can see this class: - `sync-ui-keys.mjs` only backfills keys that are ABSENT, never ones that are STALE; - `check-ui-keys-coverage.mjs` counts key PRESENCE, so a stale translation scores as fully covered (all 43 locales sat at 99.6% throughout); - `check-translation-drift.mjs` tracks the `docs/i18n/<locale>/**.md` documentation mirrors — it never reads `src/i18n/messages/*.json` at all. (Its `.i18n-state.json` is also absent, so it self-skips, but bootstrapping it would not have helped: wrong surface.) New gate `scripts/i18n/check-ui-value-drift.mjs` is DIFF-AWARE rather than baseline-backed: it compares `en.json` at the merge base against the working tree, and for every key whose English value changed, reports any locale still holding an untouched translation. That choice deliberately freezes pre-existing debt — a diff cannot reveal which old English a long-standing translation came from, so the gate judges only what the current change touches, and unrelated PRs never pay for historical drift. The alternative, a per-key hash baseline over 11207 keys, would have cost a ~600 KB generated file (3x the largest existing baseline) churning on every i18n PR. Two ways to satisfy it: refresh the translations, or set them to `__MISSING__:<new english>` so the runtime serves the corrected English (#7258) while the key queues for translation. When the string's MEANING changes, renaming the key is better still — a new key cannot inherit a stale translation, which is what #8463 did. Wired blocking into the `i18n-ui-coverage` job (the `i18n` job is `continue-on-error: true`, so a gate there could not block anything). That job gains `fetch-depth: 0` because the gate needs the base ref; without it the gate self-skips with `base-unresolved`, mirroring `check-openapi-breaking`. `BASE_REF` is passed via `env:` and reaches git only through `execFileSync` argv — never a shell string. Verified against the real defect: rewriting an English value with translations left behind reports exactly 39 stale locales and exits 1; `--warn` exits 0; an unresolvable base exits 0 with `SKIP reason=base-unresolved`. Co-authored-by: ikelvingo <im.kelvinwong@gmail.com> |
||
|
Shixi Li
|
82bed08404 |
docs(podman): clarify Podman Machine deployment (#8569)
* docs(podman): clarify Podman Machine deployment * style(podman): format guidance and regression test |
||
|
MumuTW
|
1cbe8c44f5 |
Train 1D: merge via --admin on .113 validation
Squash merge from local merge-train (Hard Rule owner-approved). Tip 029cdf4215cf465f0e1716ac9f84a84692b1e881 validated on 192.168.0.113: 26631/26653 pass. |
||
|
MumuTW
|
4c9292e66e |
chore(i18n): normalize zh-TW terminology and sync stale README figures (#8554)
The zh-TW catalog was machine-translated with mainland-habit vocabulary and simplified->traditional conversions that picked the wrong homophone, and its README still advertised the v3.7-era figures. Terminology (docs/i18n/zh-TW/ + src/i18n/messages/zh-TW.json): - wrong-character conversions: 上遊->上游, 後臺->後台, 儀錶板->儀表板 - mainland habits: 默認->預設, 緩存->快取, 模塊->模組, 調用->呼叫, 字符串->字串, 全局->全域, 文檔->文件, 響應->回應 - consistency: 供應商/提供商->提供者 (提供者 was already 71% dominant), 型別->類型 for UI labels, 不活躍->未啟用 README figures synced to the English source: 231->290 providers, 17->19 routing strategies, 1.6B->1.53B free tokens, 50+->90+ free tiers, 11->40+ free forever, 87->104 MCP tools, 30->31 scopes. Root cause — the generator's post-translation pass was a hardcoded list that duplicated the glossary and was wired only into the deprecated generate-multilang.mjs, so the active run-translation.mjs pipeline applied nothing. Worse, its blanket /代碼/g -> 程式碼 rule would corrupt 控制代碼 (handle), 語系代碼 (locale code) and 錯誤代碼 (error code) on the next regeneration. Both scripts and the drift gate now share scripts/i18n/glossary-normalize.mjs, driven by scripts/i18n/glossary/<locale>.json as the single source of truth. Ambiguous terms carry blockedPrefixes so 型別->類型 can stay enforced without mangling 模型別名 (model alias) or 基本型別 (a programming data type); terms whose synonym is also a legitimate rendering elsewhere (代碼, 項目) are seeded with no synonyms and documented instead of blanket-rewritten. CI now runs the glossary gate for zh-TW alongside zh-CN. |
||
|
MumuTW
|
4bf47c9b80 |
chore(perf): add deterministic request-body heap benchmark (#7847) (#8549)
#7847 reports a 3.05 MiB request (729 messages / 86 tools) reaching ~12,282 MiB of V8 heap, and asks for "a regression benchmark that records peak heap for representative 500-800-message, tool-rich requests" before any fix lands. There is currently no memory baseline in the repo at all (bench:compression is the only benchmark), so a clone-reduction change could neither be justified nor regression-guarded. npm run bench:heap-body attributes retained heap to each copy the chat path makes: | mechanism | call site | retained | x wire | | cloneLogPayload (unbounded) | chat.ts buildClientRawRequest | 3.18 MiB | 1.04x | | cloneBoundedForLog (bounded) | requestLogger.logClientRawRequest | 0.04 MiB | 0.01x | | structuredClone x3 (combo targets) | combo.ts attemptBody | 9.53 MiB | 3.12x | | JSON.stringify (token estimate) | combo.ts estimateTokens | 3.06 MiB | 1.00x | | per request (sum) | |15.81 MiB | 5.17x | It measures the real production helpers rather than reimplementations, so a change to the log bounds or the clone strategy is reflected directly. Design notes: - Deterministic: fixed-seed LCG, no Math.random(). Verified byte-identical across three consecutive runs — without that, a before/after delta measures noise, not the change. - Corpus lives in its own side-effect-free module so the unit test can import it without booting SQLite (requestLogger transitively opens the DB at import time). - Hermetic: DATA_DIR is redirected to a temp dir before importing, so the benchmark never touches the operator's real ~/.omniroute store. - Node, not bun: --expose-gc and V8 heap accounting are the measurement; another engine's heap number would not describe the production runtime. - --max-retained-mib exits non-zero, so this can become a CI gate once a target is agreed. Reports only; wires nothing into CI and changes no production code. |
||
|
MumuTW
|
c447be4329 |
fix(db): classify compressionDetailNormalizers as db-internal in check-db-rules (#8534)
* fix(db): classify compressionDetailNormalizers as db-internal in check-db-rules check:db-rules fails on release/v3.8.49 at its own HEAD: the module added by #8404 is neither re-exported from localDb.ts nor listed in INTENTIONALLY_INTERNAL, so the gate blocks every PR->release run and tests/unit/check-db-rules.test.ts fails its live-repo case. Its only importer is its sibling src/lib/db/compression.ts, via a relative import inside src/lib/db/ — the db-internal classification the list already uses for apiKeyColumnFallbacks and caseMapping. Re-exporting it from localDb.ts would instead advertise pure normalizer helpers as part of the compat surface, which Hard Rule #2 discourages. * test(db): mirror compressionDetailNormalizers in the INTENTIONALLY_INTERNAL audit The classification guard asserts the exact audited set. Adding the module to check-db-rules.mjs without the mirror left the exact-list/exact-size assertion red; both assertions stay exact (37 entries). Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com> --------- Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com> |
||
|
backryun
|
1930b09c6a |
chore(sse): drop deprecated baseUrl from open-sse tsconfig for TS 7.0 (#8473)
TypeScript 6.x raises TS5101 on `open-sse/tsconfig.json`: `baseUrl` is deprecated and stops functioning in TypeScript 7.0. It was paired with `ignoreDeprecations: "5.0"`, which no longer silences it under TS 6 (the compiler now demands "6.0"). Remove `baseUrl: ".."` and rewrite the `paths` mappings relative to the tsconfig's own directory, which is how TypeScript resolves them with no baseUrl set: "@/*" ./src/* -> ../src/* "@omniroute/open-sse" ./open-sse -> ../open-sse "@omniroute/open-sse/*" ./open-sse/* -> ../open-sse/* `ignoreDeprecations` goes with it — baseUrl was the only deprecated option it was suppressing. Verified by diffing the full tsc error set against the previous config (the base run used `ignoreDeprecations: "6.0"` so compilation proceeds past the config error, which otherwise aborts type-checking and masks everything): zero new errors, 28 fewer. All 28 were in `electron/*.js`, which `baseUrl: ".."` had been dragging into the open-sse program via root-relative resolution. Scoping the program back to open-sse also moves `check:type-coverage` from 92.17% to 94.01%; the ratchet direction is up so the gate passes, and the baseline is deliberately left alone because the gain is a measurement-scope change rather than new typing work. The guard test asserts no tsconfig reintroduces `baseUrl` or `ignoreDeprecations`, and that every `paths` target still resolves to a real directory — the second half is the part that matters, since dropping baseUrl silently changes what those mappings point at. |
||
|
Diego Rodrigues de Sa e Souza
|
875de01de7 |
chore(quality): drop stale muse-spark-web allowlist entry + sync sidebar order snapshots (#8383)
Two independent "code is right, bookkeeping lagged" base-reds: 1. #8233 made open-sse/executors/muse-spark-web.ts import sanitizeErrorMessage from utils/error.ts (a real Rule #12 fix), but left its KNOWN_MISSING_ERROR_HELPER allowlist entry in scripts/check/check-error-helper.mjs in place. The gate's own stale-allowlist enforcement (assertNoStale) correctly flagged the now -obsolete entry: `npm run check:error-helper` failed with "1 entrada(s) obsoleta(s)", and tests/unit/check-error-helper.test.ts's "the shipped allowlist freezes exactly the known current violators" test expected an empty Set. Removed the entry (kept the assertNoStale machinery and the general scope-header comments untouched). 2. #8064 added the "compression-exclusions" sidebar item right after "compression-studio" in COMPRESSION_CONTEXT_GROUP (deliberate, complete feature) but didn't update two order-snapshot tests written before that item existed: - tests/unit/sidebar-visibility.test.ts expected the "omni-proxy" section's flattened id list to end the compression block at "compression-studio". - tests/unit/ui/sidebar-engine-items.test.ts asserted "Studio must be last" in COMPRESSION_CONTEXT_GROUP. Updated both to the real, intentional order: Settings -> Combos -> engines -> Studio -> Exclusions (Studio now second-to-last, Exclusions last). Validation (red -> green): - check:error-helper gate: red ("1 entrada(s) obsoleta(s)") -> green ("OK (898 files scanned, 0 known-missing frozen)") - tests/unit/check-error-helper.test.ts: 31/32 -> 32/32 - tests/unit/sidebar-visibility.test.ts: 6/7 -> 7/7 - tests/unit/ui/sidebar-engine-items.test.ts: 13/14 -> 14/14 Refs #8233 Refs #8064 |
||
|
backryun
|
b84f86ad4f | fix(runtime): isolate unique 8177 repairs (#8298) | ||
|
Moseyuh333
|
d43e71613e |
optimize(chaos+ponytail): i18n ponytail, dedupl dispatch, provider diversity (#8264)
* feat(chaos+ponytail): parallel chaos-mode dispatch + ponytail output style (rebased on v3.8.49)
- Chaos mode: new auto/chaos variant fans the prompt out to the top-N
stable models in parallel and returns a single merged SSE stream.
- Progressive streaming: each panel model's answer is enqueued as it
lands (omni-chaos-part event), instead of awaiting the whole panel.
- withTimeout now aborts the underlying request (modelAbortSignal) on
timeout so the connection is released, not leaked.
- concatSseText parses both OpenAI and Anthropic SSE wire formats.
- autoPrefix/modePacks add the chaos-mode weight pack; virtualFactory
materializes auto/chaos with fusion strategy + chaos config flag.
- Ponytail (lazy-senior-dev mode) integrated into the existing
OUTPUT_STYLE_CATALOG registry (id 'ponytail') so it rides the production
output-style injector, instead of a bespoke duplicate module. Dev-only
scripts and the duplicate ponytail/ module are removed.
- Tests: chaosEngine/chaosVirtualCombo cover panel dispatch, progressive
broadcast, timeout abort, and Anthropic parsing; autoCombo pack count
updated to 6.
Rebased onto release/v3.8.49 (no provider-registry or validation changes —
those are split out per review).
* optimize(chaos+ponytail): i18n ponytail, dedupl chaos dispatch, provider diversity
- Ponytail: add vi/ja/pt-BR/id i18n with lite/full/ultra levels
- chaosEngine: extract dispatchOnePanelModel (shared), add onResult for
progressive SSE streaming, fix withTimeout anti-pattern
- virtualFactory: deduplicate chaos panel by provider, add tuning overrides
- dispatchChaosFromCombo: accept ChaosTuning, enforce minPanel
- Add/port 8 node-runner tests for ponytail i18n + catalog integrity
- Add muse-spark-web.ts to KNOWN_MISSING_ERROR_HELPER (pre-existing)
* fix(8264): use HandleSingleModel type in chaosEngine dispatch (base-drift)
---------
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
|
||
|
小妍儿 ✨
|
fbb8d45757 |
docs(db): add reproducible SQLite coupling inventory (#8262)
Co-authored-by: 千乘妍 (Xiaoyaner) <xiaoyaner0201@users.noreply.github.com> |
||
|
backryun
|
18f1f667bf | fix(claude-web): align session transport and fallback (#8230) | ||
|
Markus Hartung
|
4ea08f520b |
fix(sse): Gemini malformed function-call handling + tool_choice translation (#8211)
* fix(sse): synthesize tool_calls for Gemini's malformed function-call abort reasons Live incident (dashboard log id 1784489701456-d8c0e9): Gemini terminates a stream with finishReason MALFORMED_FUNCTION_CALL/UNEXPECTED_TOOL_CALL when its own parser rejects an attempted tool call — there's no real functionCall part, only a human-readable finishMessage. gemini-to-openai.ts passed this through raw as finish_reason (9router#2462's fix, correctly keeping it off a clean "stop"/Claude end_turn), but a raw "malformed_function_call" isn't one of OpenAI's 5 documented finish_reason values, so a real OpenAI-format client (OpenClaw) has no handling for it at all and silently never notices the turn failed — confirmed live via tests/integration/live-gemini-workload.test.ts's [28] streaming case after the Gemini TPM/rebase work on this branch. Fix: synthesize a tool_calls entry (arguments carry the error code + Gemini's finishMessage, valid JSON) and finish_reason: "tool_calls" instead, routing the failure into the ordinary "tool call arguments didn't parse" path every OpenAI-compatible agent loop already handles. Defers to a real tool call if one already completed earlier in the same turn — the real call wins, no synthetic entry piles on top of it. Tests (TDD, each confirmed red-before-green): - 5 new unit tests in the existing 9router#2462 regression file, covering the synthesis itself, UNEXPECTED_TOOL_CALL, the real-tool-call-wins edge case, and no-regression on a clean STOP. - New fixture (tests/fixtures/translation/gemini-malformed-function-call-stream.json): the real 6-chunk event series from the live incident, sanitized (personal paths/URLs replaced with generic placeholders, structure preserved exactly). - New integration test chains the real translator into the real Responses API transformer using that same fixture, proving correct behavior on BOTH /v1/chat/completions and /v1/responses from one shared ground-truth event series. Co-authored-by: Markus Hartung <markus.hartung@gmail.com> * fix(sse): don't drop a malformed tool-call failure when it lands beside a real one Live incident (dashboard log id 1784589106014-2a42f8), analyzing why the prior malformed-function-call fix (3568c7259) still wasn't reaching the client in this case: Gemini can emit a REAL, valid functionCall AND finish the SAME candidate with MALFORMED_FUNCTION_CALL — the model attempted multiple tool calls in one turn (here: a real status-check call plus a malformed "exec"+"cron" multi-call attempt), one parsed cleanly and the other didn't. The first fix version skipped synthesizing a failure signal whenever a real tool call already existed (state.toolCalls.size > 0), on the assumption that meant the model was retrying a LATER, separate attempt after an earlier one already succeeded. That's indistinguishable, from the translator's state, from this same-turn case — so it silently discarded the malformed attempt's information entirely: the client saw the real call succeed and never learned the other tool calls were attempted and rejected. Fix: always synthesize the failure entry when a malformed abort reason is seen, appending it alongside any real tool call rather than skipping it. Multiple tool_calls in one response is normal, well-supported OpenAI behavior (parallel tool calls), so this adds the failure as an additional entry instead of replacing or hiding the real one. Tests (TDD, confirmed red-before-green): - Rewrote the unit test that encoded the old (wrong) assumption to assert both the real and synthesized calls are present. - New fixture (gemini-malformed-function-call-parallel-real-call-stream.json): the real event series from this incident, sanitized. - New integration tests (same file as 3568c7259's) prove both /v1/chat/completions and /v1/responses surface both tool calls correctly from this fixture. Co-authored-by: Markus Hartung <markus.hartung@gmail.com> * feat(sse): honor tool_choice when translating OpenAI requests to Gemini Investigating a live report that gemini-3.1-flash-lite frequently narrates an intended tool call in plain text instead of actually emitting one (dashboard log id 1784591483850-49c408 — 9 raw provider chunks, all plain text, zero functionCall parts, clean finishReason STOP): body.tool_choice was never read anywhere in the OpenAI->Gemini request translator. result.toolConfig was unconditionally hardcoded to { functionCallingConfig: { mode: "VALIDATED" } } whenever tools were present, regardless of what the caller sent. VALIDATED lets the model respond with plain text OR a schema-validated function call at its own discretion — it never forces a call the way OpenAI's tool_choice: "required" (Gemini's ANY mode) does, so a caller had no way to compel a tool call even when explicitly requesting one. Added convertOpenAIToolChoiceToGemini(), mirroring the existing convertOpenAIToolChoice() in openai-to-claude.ts for the same OpenAI tool_choice shapes (string "auto"/"none"/"required", or {type:"function",function:{name}} to force one specific tool): - unset/"auto" -> VALIDATED (unchanged default, no regression) - "required"/"any" -> ANY (forces a call) - "none" -> NONE (disables function calling) - {type:"function",...} -> ANY + allowedFunctionNames: [name] Wired into both Gemini request paths: the direct/base translator (openaiToGeminiBase) and the Antigravity/Cloud Code envelope (wrapInCloudCodeEnvelope), which now reuses the base translator's already- computed toolConfig instead of re-deriving its own hardcoded VALIDATED. This unblocks (but does not itself resolve) the live question — a tool_choice: "required" A/B test against gemini-3.1-flash-lite follows to confirm ANY mode actually changes the narrate-vs-act behavior in practice. Also updates the T11 any-budget allowlist for this file: the "any" string comparisons (tool_choice value "any", not a TypeScript type) are the same documented false-positive pattern already carved out for executors/base.ts. Tests (TDD, confirmed red-before-green): 9 new unit tests covering all tool_choice shapes on both the direct and Antigravity/Cloud Code paths, plus the no-tools and unset-default no-regression cases. Co-authored-by: Markus Hartung <markus.hartung@gmail.com> * chore(quality): file-size baseline for own-growth (#8211) Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: Markus Hartung <markus.hartung@gmail.com> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
Markus Hartung
|
40ee0847d9 |
feat(sre): add tcp-close-analyzer.py for debugging client-vs-server TCP close order (#8208)
Dependency-free (stdlib-only) libpcap/Ethernet/IPv4/TCP parser that answers one question: does OmniRoute or the far end (Caddy, on behalf of whichever client it's proxying) close the TCP connection first? Dashboard-level 499s only tell us OmniRoute detected a dropped connection, not which side's FIN/ RST actually landed first -- this settles it from the raw packets. Handles classic Ethernet and both "Linux cooked" linktypes (SLL/SLL2, what `tcpdump -i any` produces) since rootless Podman has no host-visible bridge interface to capture on directly -- the capture instructions in the script document the nsenter-into-container-netns workaround. Adds --find to grep every reassembled stream for a literal marker string -- in practice the reliable way to locate one specific request (the x-correlation-id header isn't echoed on every hop) is dropping a fresh UUID into an actual chat message and searching for it, then cross-referencing the matched stream's timing against data/call_logs/<date>/*.json. Co-authored-by: Markus Hartung <markus.hartream@gmail.com> |
||
|
Diego Rodrigues de Sa e Souza
|
08129cfb0c |
fix(ci): merge-train --fast mirrors test:unit subdir allowlist (#7688)
The fast bucket fed every changed tests/unit file to node:test; vitest-only
subdirs (autoCombo) always fail under that runner and redden the train. The
classifier now carries the same {api,auth,…} allowlist as package.json's
test:unit (guarded by a sync test) and stops excluding ui/*.test.ts, which
test:unit does run.
|
||
|
Diego Rodrigues de Sa e Souza
|
f23d7770ec |
feat: zh-CN terminology glossary + consistency gate + normalization pass (#8038) (#8166)
One-shot 提供商->提供者 normalization across src/i18n/messages/zh-CN.json (679 substitutions) and bin/cli/locales/zh-CN.json (54), mirroring #8024's zh-TW pass. Adds a versioned terminology glossary (scripts/i18n/glossary/zh-CN.json), a protected-names list (scripts/i18n/glossary/protected-terms.json), and a pure-function consistency check (scripts/i18n/check-glossary-consistency.mjs, npm run i18n:check-glossary) wired into CI as the i18n-glossary-zhcn job. zh-CN added to the visual-QA harness default locales. Complements the existing parity (check-ui-keys-coverage.mjs) and ICU (validate_translation.py) gates without replacing them. |
||
|
Diego Rodrigues de Sa e Souza
|
98b1aa34b5 |
fix(sse): run compression pipeline per turn in Codex Responses WS bridge (#8052) (#8154)
The Codex Responses-over-WebSocket bridge bypassed the whole prompt-compression pipeline (and its analytics writes) that the HTTP/SSE path (chatCore.ts) runs on every request, via two gaps: 1. prepare() in codex-responses-ws/route.ts never called anything from open-sse/services/compression/* — it authenticated, injected memory, applied reasoning-routing, then went straight to executor.transformRequest(). 2. scripts/dev/responses-ws-proxy.mjs memoized the upstream connection in ensureUpstream() and only called the internal "prepare" action on the FIRST response.create of a WS session — every subsequent turn on a reused connection bypassed prepare() (and therefore compression) entirely. Fix: a new compression.ts module wires the core compression pipeline (settings resolution -> selectCompressionStrategy -> applyCompressionAsync -> compression_analytics/compression_engine_breakdown writes, reusing adaptBodyForCompression's existing Responses-API input[] adapter) into prepare(); responses-ws-proxy.mjs now re-runs prepare() (via a new shared runPrepare() helper) for every logical response.create turn on a reused connection, not just the first, without recreating the upstream socket. Regression test: tests/unit/responses-ws-proxy-compression-parity.test.ts proves the reused-connection bypass by execution (RED: 1 prepare call for 2 turns; GREEN after the fix: 2 prepare calls for 2 turns). |
||
|
Diego Rodrigues de Sa e Souza
|
287802cf86 |
fix: repair pre-existing red gates on the release/v3.8.49 tip (#8055)
* fix(dashboard): resolve Kimi banner casing collision + shrink frozen test file (release tip) - Rename src/app/(dashboard)/dashboard/kimiSponsorBanner.ts to kimiSponsorBannerGate.ts so it no longer differs from KimiSponsorBanner.tsx only by the first letter's case (breaks next build on case-insensitive filesystems). Updates the sole importer (KimiSponsorBanner.tsx) and the two tests that reference it. - Extract the 8 Kimi/Moonshot featured-ordering tests out of the frozen tests/unit/providers-page-utils.test.ts (grown 3 lines past its 1294 cap by #8039's rebrand-comment update) into a new sibling file tests/unit/providers-page-utils-kimi.test.ts. No assertions dropped; both files pass in full (24 + 8 = 32 tests). * fix(sse): register PromptQlExecutor in the executor registry (release tip) getExecutor("promptql") had no entry in open-sse/executors/index.ts, so it silently fell through to DefaultExecutor's provider fallback, which issues a raw fetch() and returns the bare upstream Response instead of the executor wrapper shape {response, url, headers, transformedBody}. The real PromptQlExecutor class (open-sse/executors/promptql.ts) already honors the contract correctly — it was just never wired into the registry. Fixes tests/unit/executor-web-cookie-sweep.test.ts "promptql executor returns wrapper shape". * fix(i18n): backfill 2220 missing pt-BR keys to restore en.json parity (release tip) pt-BR.json fell behind after #7935 restored +2220 keys into en.json and vi.json but left pt-BR.json unmodified. Translated all missing entries to Brazilian Portuguese, preserving ICU/interpolation placeholders and existing terminology, and merged them mirroring en.json's key order so the diff is additions-only (the small comma-only deletions are pure JSON reformatting from new sibling keys). * fix(providers): repair 4 pre-existing catalog/registry reds on release tip - providers-constants-split.test.ts: APIKEY_PROVIDERS grew 182->187 (PR #7887 added 5 free-tier providers: ainative/aion/sealion/routeway/nara). Verified no dup/loss (6-family partition sums exactly to 187) and updated the stale expected count + comment trail to match. - cline registry: added the missing minimax/minimax-m3 free OpenRouter entry (#3321) and fixed the neighbouring nemotron-3-ultra-550b-a55b entry, which carried a stray ":free" id suffix and an imprecise 1_000_000 contextLength instead of the 1_048_576 the test (and every sibling 1M-context entry in this catalog) expects. - promptqlModels.ts / registry/promptql/index.ts: PROMPTQL_FALLBACK_MODELS's minimax-m3 entry was missing supportsVision, and the registry mapping dropped it entirely (only id/name were passed through) — it was the sole minimax-m3 entry across the whole registry not flagged multimodal, despite every other provider (minimax, minimax-cn, ollama-cloud, trae, bazaarlink, clinepass, codebuddy-cn, opencode-zen/go, synthetic, huggingchat, lmarena) agreeing MiniMax-M3 supports vision. Added the field to the PromptQlModel type and threaded it through. - tests/snapshots/provider/translate-path.json: regenerated the golden via UPDATE_GOLDEN=1. Diffed old vs new — zero providers removed, 5 added (ainative/aion/nara/routeway/sealion, matching #7887), and the only changed entry (cline) reflects the already-merged #7914 ClinePass header protocol change (Cline/<version> User-Agent + X-Task-ID) that a prior narrow golden touch-up missed capturing. * fix(docs): repair docs-sync/env-sync/repo-contract gates (release tip) Six pre-existing reds on release/v3.8.49, all "repo drifted from its own documented contract": - check-docs-counts-sync: free-tier headline was stale (~1.4B/~2.0B) vs the live catalog (~1.53B steady / ~2.15B first month, 43 pools). Updated README.md and docs/reference/FREE_TIERS.md to the live numbers and added a v3.8.49 correction note explaining the pool-count delta (39->43, #7840). Also fixed a soft executors-count drift in ARCHITECTURE.md (84->86, 268->271 providers) while touching that line. - release-green-docs-drift-7253: docs/proxy-subscriptions.md referenced a fabricated migration filename (123_proxy_subscriptions.sql); the real file is 131_proxy_subscriptions.sql. Fixed all 3 occurrences. - check-env-doc-sync + issue-7793-env-doc-sync-repro: OMNIROUTE_DATA_DIR (DATA_DIR fallback alias read by open-sse/executors/promptql/threadSticky.ts) was undocumented. Added to .env.example and docs/reference/ENVIRONMENT.md. - check-db-rules: src/lib/db/proxySubscriptions.ts (#7299) is a db-internal split of proxies.ts (kept under the frozen file-size cap) whose one export is already re-exported via proxies.ts -> localDb.ts. Added it to INTENTIONALLY_INTERNAL with the same db-internal justification used for identical split modules (apiKeyColumnFallbacks, providerNodeSelect, webSessionDedup) rather than a redundant direct re-export from localDb.ts. - mcp-server-hollow-dist-deps: the sanity test expected better-sqlite3 among the MCP bundle's static top-level external imports. That's been stale since the pre-#7878 migration to a cascading SqliteAdapter driver factory (createRequire()-based lazy require, not a static import); better-sqlite3 already has its own native-asset copy guarantee in assembleStandalone.mjs, unrelated to this test's EXTRA_MODULE_ENTRIES concern. Updated the assertion to a still-genuinely-static external (zod) with a comment explaining the change. No production runtime behavior changed — docs, .env.example, and a checker allowlist/test-expectation only. * fix(dashboard): repair stale UI component-shape test assertions (release tip) Two pre-existing reds in the dashboard UI component-contract cluster were caused by test assertions that had gone stale after intentional, correct refactors — not by real defects in the components: - quota-pool-wizard-multi.test.ts: the step-3 preview assertion required the literal single-line substring "connectionIds.map((cid)". Prettier (100-char width, project config) legitimately breaks the connectionIds.map(...).filter(...) chain across lines because of the multi-line callback body, so the literal never matches. PoolWizard.tsx still builds previewByProvider correctly by mapping over connectionIds; updated the assertion to a regex that tolerates the line break. - v388-phase1-screen-fixes.test.ts: the shared Select placeholder-guard assertion required the literal "!children && placeholder". An earlier, intentional i18n commit changed the hardcoded "Select an option" default to a translated fallback (`placeholder ?? t("selectOption")`), which requires parens around the ?? expression for operator precedence. The guard behavior is unchanged (still gated on !children); updated the assertion to match the current, correct guard shape. Both fixes are read-only test-file changes; no production behavior changed. review-reviews-v3814-fixes.test.ts still has one pre-existing, unrelated red (LEDGER-4: minimax-m3 registry entries missing supportsVision) that requires editing the promptql provider registry/catalog — out of this cluster's scope, left untouched and reported separately. * fix(providers): reconcile cline catalog contradictions + deterministic golden (release tip) The first tip-green pass introduced 3 regressions caught by CI on sibling guard tests: - clinepass-provider + cline-catalog-models-3321 encoded OPPOSITE expectations of the same cline model list (minimax presence, nvidia :free suffix). Reference upstream (OpenRouter free lineup) confirms nvidia/nemotron-3-ultra-550b-a55b:free (with :free, 1M ctx) is correct, so restore that id and fix #3321's stale no-:free assertion; add minimax/minimax-m3 (the real #3321 gap) to clinepass-provider's list. - check-db-rules-classification froze INTENTIONALLY_INTERNAL at 35; proxySubscriptions was the intentional 36th entry — add it + bump the count. - provider-translate-path golden stored a LITERAL Cline/3.8.49: clineAuth resolves the version from APP_CONFIG.version (stable), but the golden sanitizer collapsed only process.env.npm_package_version (unset under `node`, set under `npm run`) — so the golden was shard-dependent. Resolve APP_VERSION from APP_CONFIG.version like clineAuth and regenerate; now Cline/<APP> normalizes identically in every shard. * fix(services): type execFile signal/killed in classifyError + ratchet dashboard baseline (release tip) Pre-existing base-red on the tip's Fast Quality Gates (dashboard-typecheck), missed in the first inventory: - src/lib/services/installers/utils.ts TS2339 — `err.signal` was read off a value typed as NodeJS.ErrnoException, which @types/node does not declare `signal`/`killed` on (those belong to execFile's ExecFileException). Widen classifyError's param to type both, and drop the now-redundant `(err as … { killed })` cast. - Ratchet config/quality/dashboard-typecheck-baseline.json down: 5 baselined errors were fixed by already-merged PRs but never ratcheted (OAuthModal TS2769 4→3 / TS2345 4→3, CliproxyModelMappingEditor TS2339, CompressionPreviewAccordion TS4104, MonacoEditor TS2307). Baseline now 254, matching live — gate exits 0. |
||
|
Diego Rodrigues de Sa e Souza
|
25499bf94d |
fix(quality): tolerate ESLint's trailing unpruned-suppressions text in validate-release-green (#7837) (#7962)
Root cause: validate-release-green.mjs's ESLint gate runs `npx eslint . --format json --suppressions-location ...` without --pass-on-unpruned-suppressions. ESLint 9.x prints the valid JSON report to stdout first, then (if the suppressions file has any stale entries) appends 'There are suppressions left that do not occur anymore...' to stderr and exits 2. The gate concatenates stdout+stderr, so parseEslintJson() received valid JSON immediately followed by that sentence, JSON.parse() threw, and the caller reported the generic "could not parse eslint json" HARD failure instead of the real (harmless) unpruned-suppressions housekeeping condition. Fix: add --pass-on-unpruned-suppressions to the gate's eslint invocation (unpruned suppressions are release-time housekeeping, not a contributor defect), and harden parseEslintJson() with a bracket-depth scan so it recovers the JSON array even when trailing non-JSON text is glued on. Regression test: tests/unit/validate-release-green.test.ts — 'parseEslintJson tolerates ESLint's trailing unpruned-suppressions stderr sentence (#7837)', feeding parseEslintJson() the exact byte shape ESLint's own cli.js produces in this scenario. Confirmed RED before the fix (parsed === null), GREEN after. Gates run: node --import tsx/esm --test tests/unit/validate-release-green.test.ts (20/20 pass), npm run typecheck:core (clean), eslint --suppressions-location on changed files (clean), check-complexity.mjs + check-cognitive-complexity.mjs (OK, no regression), check-mutation-test-coverage.mjs --strict (no drift), check-changelog-integrity.mjs (OK), check-file-size.mjs (OK, no frozen files grown). Closes #7837 |
||
|
backryun
|
65e0aeda79 |
[Part 1/3]refactor(qwen): replace legacy Qwen Code and remove OAuth provider (#7866)
* refactor(cli): remove legacy Qwen Code integration * refactor(qwen): remove deprecated Qwen OAuth provider * feat(cli): rebuild Qwen Code integration for upstream V4 * fix(qwen): clear stale CLI auth on reset * test(qwen): align retired provider coverage * fix(db): renumber qwen-cleanup migration 129 -> 130 release/v3.8.49 tip took slot 129 via #7843 (usage_history_codex_strong_identity, itself renumbered from 128 during the #7838/#7840 base-red cleanup) after this branch forked; renumber remove_unregistered_qwen_data to 130. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com> |
||
|
Rafael Dias Zendron
|
d813bedf5c |
fix(cli): register ESM alias resolver for @/ paths under global install (#7808)
* chore(ci): add .mergify.yml to main — Mergify only reads config from the default branch (#7168) * fix(ci): add the auto-enqueue pull_request_rule to the Mergify config (queue_conditions alone are eligibility-only) (#7179) * fix(ci): migrate Mergify auto-enqueue to merge_protections_settings.auto_merge_conditions (rules-based path is EOL 2026-07-16) (#7216) * fix(ci): drop Mergify batch settings (batching is a paid-tier feature; free plan queue is serial) (#7220) * fix(ci): merge queue tolerates the advisory dast-smoke failure (its GH-hosted build hang dequeued every attempt) (#7225) * test(ci): make the #6634 selfref guard hermetic — main's copy hard-fails every PR (#7341) main's copy of this test still does git I/O inside a unit test: const baseSrc = git(['show', 'origin/main:' + FILE]); Runners check out a shallow single ref, so origin/main does not resolve and the test dies with 'fatal: invalid object name origin/main'. Every PR into main fails Unit Tests (7/8) on it — today that is #7313, #7315, #7316, #7334, #7336 and #7337, six PRs red on a defect none of them introduced. #7313 has no other red at all. release/v3.8.49 already carries a fix ( |
||
|
backryun
|
34aefcf4e2 | fix(ci): repair release regressions exposed by clean runs (#7812) | ||
|
Diego Rodrigues de Sa e Souza
|
7a0e982dff |
fix(docker): repair tls-client-node native binary after --ignore-scripts (#7802) (#7829)
The Dockerfile builder stage installs with --ignore-scripts, which blocks tls-client-node's own postinstall.js (the script that fetches the native .so/.dylib/.dll from bogdanfinn/tls-client GitHub Releases). Unlike better-sqlite3 (explicit node-gyp rebuild) and wreq-js (fixWreqJsBinary()), tls-client-node had zero compensating step, so node_modules/tls-client-node/bin/ was always empty in the official Docker image and every chatgpt-web/claude-web/ grok-web/lmarena/perplexity-web request threw TlsClientUnavailableError. - Dockerfile: explicitly invoke tls-client-node's postinstall.js after npm ci --ignore-scripts (same spot as the better-sqlite3 rebuild), and fail the build loudly if bin/ ends up empty instead of shipping a silently-broken image. - scripts/build/fixTlsClientNodeBinary.mjs (new): mirrors fixWreqJsBinary() to copy the root bin/ into the standalone dist/node_modules bundle, and retries the download with backoff when bin/ is empty (degrades gracefully against a transient GitHub API rate-limit instead of failing on the first attempt), warning with a clear manual-fix pointer if every retry still comes up empty. - Registered the new script in package.json files + pack-artifact-policy.ts allowlists so it ships in the npm tarball. Regression test: tests/unit/tls-client-node-docker-binary-7802.test.ts (RED against current release/v3.8.49 tip, GREEN after the fix). New unit coverage for the retry/copy/warn behavior in tests/unit/fix-tls-client-node-binary-7802.test.ts. Closes #7802 |
||
|
Diego Rodrigues de Sa e Souza
|
5d1ad576a1 |
feat(quality): gate the free-tier headline so it can never silently drift again (#7798)
* docs(free-tiers): correct the headline to the 1.37B the catalog actually computes
The 2026-06-17 honesty correction landed 1.54B, but v3.8.42 reclassified longcat
from a 150M/mo recurring grant to a one-time 10M signup credit and the doc was
never resynced. Verified against computeFreeModelTotals() at every release tag
from 3.8.13 to HEAD: no free provider was lost by mistake.
* feat(quality): gate the free-tier headline against the live catalog
The README headlined ~1.6B free tokens/mo for seven releases after the catalog had
already been corrected down to 1.37B. No gate watched that number, so the drift was
invisible — check:docs-counts only covered providers, locales, executors, strategies,
oauth, a2a skills and cloud agents.
Adds a STRICT check that runs computeFreeModelTotals() (the same function behind
/api/free-tier/summary) and fails the build when README.md or FREE_TIERS.md publish a
headline that no longer rounds to it. Degrades to a skip if tsx is unavailable rather
than going falsely red.
The extractor is a whitelist: the theoretical ceiling (~10B), the historical ~1.94B and
per-model rows (~1.00B) are legitimate figures that must never trip the gate.
Also adds the biweekly-audit note under the README headline, so readers know the number
moves both ways and is what the catalog computes rather than a rounded-up best case.
* feat(quality): extend the counts gate to engines, MCP tools/scopes and CLI tools
The v3.8.49 audit found four more numbers that had silently drifted, all invisible to
CI because check:docs-counts only watched providers/locales/executors/strategies/oauth/
a2a/cloud-agents: 10->11 compression engines, 94->104 MCP tools, 30->31 scopes,
26->33 CLI tools.
Adds a generic makeNumberClaimValidator that reads every fact in ONE tsx subprocess via
the same functions the app serves (ENGINE_IDS, countUniqueMcpTools, the live scope union,
CLI_TOOLS) — never a hardcoded copy — with DATA_DIR redirected to a throwaway dir so
importing the MCP tool modules can't touch the operator's SQLite. Each check declares a
skip pattern so legitimate non-aggregate figures never trip it: per-module tool counts
('Memory tool definitions (3 tools)') and the CLI catalog total sitting next to the MCP
total. Degrades to a skip when tsx is unavailable rather than a false red.
7 new unit tests (all pass) covering the exact stale values this audit found and proving
per-module counts are ignored.
* docs(diagrams): sync the animated cards and mermaid sources to the audited v3.8.49 numbers
The README text was fixed in #7795 but the SVG cards and mermaid sources kept the
old numbers baked in — exactly the drift the readers see first.
- compression-pipeline.svg: 10 -> 11 engine cells (Omniglyph added as #8, matching
the README alt text), re-spaced 51px cells, highlight cascade re-timed, the
Caveman kill-dot repositioned inside its cell, default-stack bracket recentered
- free-tier-budget.svg: bar and grid rebuilt from computeFreeModelTotals() — 21 -> 19
countable pools (LongCat-2.0 moved to one-time credit, Inclusion provider removed),
huggingchat entry is now ERNIE 4.5 VL, kiro shows Claude Sonnet 4.5, signup credits
~616M -> ~626M (+longcat 10M pill), aria said 'about 1.6 billion' -> 1.4/2.0,
lower sections shifted up 30px (viewBox 872 -> 842)
- promise-pillars.svg: 26 -> 33 coding agents
- mcp-tools-94.mmd -> mcp-tools-104.mmd: real per-collection unique contributions
(42 base + memory 3 + skill 4 + githubSkill 3 + pool 6 + gamification 8 + plugin 8
+ notion 6 + obsidian 22 + compression 2), exported SVG regenerated, zh-CN ref synced
- request-pipeline.mmd: 17 -> 18 strategies, exported SVG regenerated
- README free-tier alt + docs/diagrams/README.md synced to the same numbers
Both edited cards pass validate-svg.sh and were render-verified at 4 timestamps
(animation runs; first frame is the finished composition).
* docs(env): register the 4 env vars missing from the .env.example contract (base-red unblock)
FREE_PROXY_AUTO_SYNC_ENABLED / FREE_PROXY_AUTO_SYNC_INTERVAL_MS (scheduler.ts) and
MITM_ROOT_CA_ENABLED / MITM_CERT_MODE (mitm manager/server, #6684) landed on
release/v3.8.49 without their .env.example + ENVIRONMENT.md entries, turning the
docs-gates job red for every PR on the branch. Documented with their real defaults
and the set-by-manager caveat for MITM_CERT_MODE.
* fix(dashboard): narrow the Codex session ParseResult with an equality check (base-red unblock)
#7725 landed 'if (!result.ok)' in OAuthModal — under this repo's strict:false,
tsc 6 only narrows a discriminated union on the equality form, so the negation
raised TS2339 (Property 'error' does not exist on ParseResult) and turned the
dashboard-typecheck gate red for every PR on release/v3.8.49. Runtime semantics
are identical (ok is a strict boolean).
Also ratchets the frozen baseline down 260 -> 259: the real fix here plus 3
baselined errors that other merges already fixed (CostOverviewTab TS2304,
SidebarTab TS2322, FreePoolTab TS2304). Baseline diff is deletions-only.
* fix(dashboard): keep OAuthModal within the frozen file-size cap
The narrowing comment pushed the file to 1032 > 1030 frozen; the rationale lives
in the previous commit message and the dashboard-typecheck gate itself guards the
'=== false' form from being refactored back to '!result.ok'.
* test(providers): align the grok-web credential assertion with the #7567 hint (base-red unblock)
#7713 added hintKey/hintFallback (proactive cf_clearance/User-Agent guidance) to the
grok-web web-session metadata without touching this test's deepEqual, turning unit
shard 2/4 red for every PR on release/v3.8.49. Rewritten in the same contract-only
style the file already uses for lmarena: structural fields stay strictly asserted,
the hint asserts key + intent (cf_clearance / User-Agent) without freezing operator
copy. Net stronger than before — the old assertion never checked the hint at all.
* test(golden): regenerate translate-path snapshot for the notion-web endpoint move (base-red unblock)
#7768 switched notion-web to app.notion.com without regenerating the golden,
turning unit shard 3/4 red for every PR on release/v3.8.49. Two-line regen,
reflects the deliberate production change.
|
||
|
Diego Rodrigues de Sa e Souza
|
f3277f267a |
feat(gemini-web): emulate OpenAI tool calling via the webTools prompt shim (#7286) (#7727)
Level 2 of the staged approach in #7286: wire the existing webTools.ts prompt-emulation shim (already proven across 11 other web-cookie executors) into gemini-web.ts. The client's tools[] array is now serialized into the prompt typed into the Gemini web UI, and <tool>{...}</tool> blocks in the response are parsed back into OpenAI tool_calls -- including for streaming requests, replayed as a single terminal SSE chunk since gemini-web buffers the whole response by construction. Malformed tool JSON degrades to ordinary chat content, never an error, matching the existing behavior of the other 11 executors. The no-tools code path is unchanged (regression guard). Also Level 1: adds a "Tool calling" column (native/emulated/none) to docs/reference/PROVIDER_REFERENCE.md for providers with confirmed ground truth (the 11 already-wired web-cookie executors + gemini-web -> emulated, claude-web -> none pending its own Level 3 decision). Level 3 (claude-web) and Level 4 (supportsTools capability flag) are explicitly out of scope -- claude-web/payload.ts is untouched. |
||
|
Diego Rodrigues de Sa e Souza
|
0c6041a34e | fix(mcp): copy undici into dist/node_modules to prevent hollow-package shadowing crash (#7701) (#7756) | ||
|
Diego Rodrigues de Sa e Souza
|
a19f86b8ca | fix(authz): classify forge/jcode CLI settings routes as LOCAL_ONLY (#7263) (#7749) | ||
|
Jan Leon
|
74c006e245 |
Add reasoning-based model and effort routing (#7607)
* feat(routing): add reasoning-based model and effort routing * refactor(routing): modularize reasoning and auto-routing pipeline * fix(routing): remove redundant DB re-export and prevent SQL scan false positives * fix(routing): resolve reasoning routing review blockers * fix(i18n): keep release ranking fallbacks outside reasoning * fix(db): renumber reasoning-routing migration past release tip (124→125) 124_generic_session_affinity_ttl.sql (#7274) has since landed on release/v3.8.49 at version 124, colliding with this PR's own 124_reasoning_routing_rules.sql. Renumbers to 125 (the next free slot past the current release tip) and updates the one filename reference in docs/routing/REASONING_ROUTING.md. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> * chore(db): renumber reasoning-routing migration 125→126 (slot taken by #7360) Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> * refactor(api): compact temp-path decls in exportAll GET (complexity-ratchet lines budget) Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> * refactor(api): single-statement auth guard in exportAll GET (function under 80-line cap) Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
gogo
|
10e5dd81e0 |
fix(branding): regenerate raster favicons — white mark was shipped without its gradient tile (#7390)
* fix(branding): regenerate raster favicons — white mark was shipped without its gradient tile favicon.ico, icon-512.png and apple-touch-icon.png contained only the white network mark on a transparent background: every opaque pixel was pure #FFFFFF, with no trace of the red gradient tile that favicon.svg and apple-touch-icon.svg define. On light browser tab strips and bookmark bars the icon therefore rendered as a blank white square. Regenerate all three assets from the canonical SVG sources: - favicon.ico: same 7 frames as before (16–256), each rasterized from the vector at native size, stored as PNG frames — 141 KB → 16 KB - icon-512.png: rendered from favicon.svg with the gradient tile - apple-touch-icon.png: rendered from apple-touch-icon.svg at the 180×180 size layout.tsx declares (the shipped file was 512×512) Add scripts/ad-hoc/generate-brand-icons.mjs so the raster assets can be reproduced from the SVGs (byte-identical) instead of drifting again. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(branding): keep standalone PNGs truecolor; palette-quantize only ICO frames Review feedback (gemini-code-assist): 8-bit palette quantization measurably clips the antialiased gradient on large assets — 1242 → 253 distinct colors at 512px. Make palette opt-in per render: ICO frames keep it (16 KB container), icon-512.png and apple-touch-icon.png are now truecolor (+9 KB total). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
tianrking
|
1e29b5c44d |
fix(electron): normalize hashed standalone externals (#7353)
* fix(electron): normalize hashed standalone externals * chore(release): add #7353 changelog fragment |
||
|
KooshaPari
|
f8e56e4615 |
fix(router-eval): retained-optimization gate cleanup (#7318)
* feat(eval): add router-eval harness (AIQ scoring, regression gate, Pareto search)
Extracts a standalone router-eval evaluation tool that replays routing
decisions (from NDJSON corpora or the usage_history/call_logs SQLite
tables) into an AIQ (success/latency/cost) score, compares baseline vs.
candidate router configs with a retained-run regression gate, and ranks
Pareto-optimal candidates across a search space — a sibling to the
existing eval:compression harness.
New scripts: scripts/router-eval/{index,compare,patch-compare,search,
trends}.ts, scripts/check/check-router-eval-regression.ts, and
src/lib/routerEval/index.ts, wired via 6 new package.json entries
(eval:router, eval:router:compare, eval:router:patch-compare,
eval:router:search, eval:router:trends, check:router-eval).
Reconstructed onto current release/v3.8.49 from the original ~142-commit
stale PR branch: only the genuinely new router-eval payload (17 files)
was extracted — the other ~560 changed files in the original diff were
base-drift already present on release in newer form. The new package.json
scripts now invoke `node --import tsx` instead of `bun`, matching the
`eval:compression` precedent (Bun is reserved for a closed 5-script
allowlist). The runtime-detection shim (`"Bun" in globalThis`) already
present in the harness gracefully falls back to better-sqlite3 under
Node, so no logic changes were needed there; the retained-run manifest's
previously-hardcoded `runtime: "bun"` field and matching CLI help text
were corrected to reflect the actual invocation.
All 27 existing router-eval unit tests pass unchanged.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* refactor(router-eval): decompose toRouterObservation below complexity gate
toRouterObservation had cyclomatic complexity 18 (gate max is 15). Extract
the per-field parsing/normalization into pure helpers (sampleId, model
fields, latency, cost derivation, success) so the entry point is a plain
sequential assembly of a RouterObservation. Behavior is unchanged — same
tests pass, same fallbacks, same precedence between input aliases.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
|
||
|
Jan Leon
|
c6315f9067 |
Refresh NVIDIA free metadata and detect catalog drift (#7378)
* fix(nvidia): refresh free metadata and detect drift * fix(nvidia): handle catalog fetch and parse failures * fix(nvidia): refresh hosted model metadata snapshot |
||
|
Diego Rodrigues de Sa e Souza
|
abd01afe17 |
chore(release): merge-train box-speed suite + --fast mode (#7670)
Validated in merge-train --fast @ 7edca36 (its own new code: static gates + merge-train-plan.test.ts 5/5 + vitest, 2m07s) |
||
|
Diego Rodrigues de Sa e Souza
|
480491cb3f |
fix(build): isolate Windows HOME/AppData during next build (#7249)
* fix(build): isolate Windows HOME/AppData during next build
next build's static-generation glob scan and framework cache helpers walk
%USERPROFILE%/AppData, which on GitHub-hosted Windows runners (and some
OneDrive-backed dev profiles) contains reparse points/junctions that raise
EPERM during Next's file-system scans. .github/workflows/electron-release.yml
already patches USERPROFILE for that one CI job ("Sanitize Windows home
directory" step), but a local `npm run build` on Windows — or any other
Windows CI path that calls scripts/build/build-next-isolated.mjs directly —
hits the same EPERM unprotected, and the existing CI patch does not touch
APPDATA/LOCALAPPDATA at all.
Folds the isolation into resolveNextBuildEnv() (the existing seam every
caller of build-next-isolated.mjs already goes through), rather than adding
a second build entrypoint the way upstream's scripts/build-app.js does:
on win32, HOME/USERPROFILE/APPDATA/LOCALAPPDATA are pointed at a fresh
per-process temp profile dir, created just-in-time via the new
ensureWindowsBuildProfileDirs() before spawning `next build`. Skipped when a
caller has already sandboxed the build via NEXT_DIST_DIR (the existing
signal this file reads for isolated-build callers, e.g. CLI packaging), so
nested build invocations are never double-isolated. Non-Windows behavior is
unchanged.
Co-authored-by: KunN21 <kunn21.nv@gmail.com>
Inspired-by: https://github.com/decolua/9router/pull/2402
* chore(changelog): fragment for #7249
---------
Co-authored-by: KunN21 <kunn21.nv@gmail.com>
|
||
|
Diego Rodrigues de Sa e Souza
|
205361a850 |
fix(cli): fast-path --version to skip full CLI bootstrap (#7208)
* fix(cli): fast-path --version to skip full CLI bootstrap `omniroute --version` ran the entire CLI bootstrap before printing the version: the tsx/esm + polyfill imports, env-file loading, and Commander's ~70-command registration (importing DB, providers, OAuth, and other heavy modules). That took ~1.5s just to print a version string. Add isVersionFastPath() (bin/cli/utils/versionFastPath.mjs) and check it at the very top of bin/omniroute.mjs, before any of that work runs. It only trips for an unambiguous bare `--version`/`-V` invocation (no other args), so it never changes behavior for real commands or for `--help` (whose output is generated dynamically from every registered subcommand, so it still needs full registration and is deliberately not fast-pathed). `--version` now returns in ~0.3s instead of ~1.5s locally. Co-authored-by: Sutarto Jordan Chrisfivo <Jordannst@users.noreply.github.com> Inspired-by: https://github.com/decolua/9router/pull/2414 * chore(changelog): fragment for #7208 * fix(build): enforce bin/cli/utils/versionFastPath.mjs in the pack-artifact gate bin/omniroute.mjs now imports ./cli/utils/versionFastPath.mjs on its boot path (the --version fast-path). bin/cli/ is only an allowlist PREFIX, so the file vanishing from the npm tarball would never fail the unexpected-paths check -- only PACK_ARTIFACT_REQUIRED_PATHS makes its absence loud (#7065 class). Adds the required path and updates the hardcoded expectation in pack-artifact-policy.test.ts, matching the existing data-dir.mjs / storageKeyProvision.mjs entries. Fixes the red in tests/unit/pack-artifact-entrypoint-closures.test.ts, which derives the requirement from the entrypoint's own imports. --------- Co-authored-by: Sutarto Jordan Chrisfivo <Jordannst@users.noreply.github.com> |
||
|
Diego Rodrigues de Sa e Souza
|
de9cfcd940 |
fix(cli): log Codex Responses WebSocket history/usage per logical turn, not per connection (#7588)
ResponsesWsSession.persistHistory() guarded on a single historyLogged boolean set once for the lifetime of the WebSocket connection. When a Codex client reuses one connection for multiple sequential response.create turns, only the first terminal event was persisted to call_logs — every subsequent turn's usage/history was silently dropped. firstResponseBody had the same per-connection freeze (||=), so even a hypothetical second log entry would still carry turn 1's request body. Replace the boolean with a Set keyed by the terminal event's response.id (falling back to a session-scoped sentinel for session-ending failure paths that don't carry a response id: prepare failure, upstream error/close, connect failure), and track each turn's own request body via currentRequestBody instead of freezing on firstResponseBody. This logs exactly once per logical turn while keeping session-ending failures logged exactly once, and each logged call now carries its own terminal response id and request payload. Regression test: tests/unit/responses-ws-proxy-multi-turn-history.test.ts opens one WS connection, sends two response.create turns, and asserts two distinct call-log entries land at the internal bridge, each with its own response id and request body. Closes #7388 |
||
|
huohua-dev
|
8c94cb5977 |
[needs-vps] fix(electron): materialize Turbopack hashed-module symlinks during packaging (#6724, #6594) (#6794)
* fix(electron): materialize Turbopack hashed-module symlinks during packaging Reconstructed onto release/v3.8.47 to drop unrelated main-drift (deps/electron/proxy files belong to #6620, not this PR); keeps only the author's changes. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> * fix(electron): actually enable materializeSymlinks on the electron standalone path The option existed in assembleStandalone but no production callsite passed it, so packaged builds still shipped absolute symlinks into the build machine's worktree for Turbopack hashed externals (better-sqlite3-<hash>, sqlite-vec-<hash>) — verified by dpkg -c on a freshly built .deb. One-line enablement on the electron prepare path, which is exactly the surface #6724/#6594 report. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> --------- Co-authored-by: huohua-dev <258873123+huohua-dev@users.noreply.github.com> Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com> |
||
|
Ronaldo Davi
|
315eefcde4 |
fix(quality): read cognitiveComplexity= machine line in validate-release-green (#7009) (#7042)
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com> Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com> |
||
|
Diego Rodrigues de Sa e Souza
|
83cca4d20f |
fix(build): packed tarball boot crash — server-ws timeout import escaped the package (#7065 class) (#7308)
* fix(build): server-ws timeout helper as shipped sibling — ../../src import crashed every packed boot (#7065 class) * test(build): align pack-artifact-policy fixture with the new dist/main-server-timeouts.mjs required path |
||
|
Diego Rodrigues de Sa e Souza
|
d3a9ad557d |
chore(release): script the 0a.0b PR re-home with a verified read-back (#7312)
The parallel-cycle model hands the frozen release/vX to the captain and cuts
release/vX+1 for everyone else. Phase 0a.0b step 3 then re-homes every open PR
onto the new cycle — today as a hand-run loop of gh pr edit --base.
Three things make that loop unreliable at exactly the moment it matters:
1. gh pr edit --base FAILS SILENTLY (v3.8.42). It exits 0 and leaves the base
untouched, so every edit needs a gh pr view --json baseRefName read-back.
A human mid-release skips that.
2. gh pr list caps at 30 results by default. A loop written without --limit
re-homes the first 30 of 148 and reports success.
3. Volume: the v3.8.49 freeze had 148 open PRs — roughly 450 API calls across
edit, verify and comment.
The script does the read-back on every PR, uses --limit 300, is idempotent (a
PR already on the next base is skipped, so a resumed release re-runs safely),
refuses to start when the next branch does not exist yet, and exits non-zero
listing any PR whose retarget did not take.
It also prints the reminder that it cannot solve the other half: PRs opened
AFTER it runs. Those need the repo default_branch pointed at the live cycle —
contributors open PRs against the default branch, and while that stays on main
they never target a release branch at all (6 such PRs on 2026-07-15).
classify() is pure and unit-tested: retarget open and draft PRs on the frozen
branch; never touch main (the release PR's own lane), an older shipped release,
or a PR already re-homed.
Refs #7307
|
||
|
Diego Rodrigues de Sa e Souza
|
af0c72fba5 |
fix: raise main server keepAliveTimeout/headersTimeout above Node's 5s default (#7003) (#7191)
* fix: raise main server keepAliveTimeout/headersTimeout above Node's 5s default (#7003) JetBrains AI Assistant's pooled java.net.http.HttpClient reuses a keep-alive connection past Node's unconfigured 5_000ms keepAliveTimeout, hitting a socket the server already tore down and getting 0 response bytes back ("HTTP/1.1 header parser received no bytes"). Wire a new getMainServerTimeoutConfig() (mirroring apiBridgeServer's pattern) into run-next.mjs so the main dashboard/API server raises keepAliveTimeout to 65s and headersTimeout to 66s by default, both env-overridable. * fix: wire main-server keepAlive timeouts into standalone/production server path (#7003) getMainServerTimeoutConfig() was only wired into scripts/dev/run-next.mjs, the dev-only entry point for `npm run dev`/`npm start`. The server real end users run — `omniroute serve` (npm-installed CLI), Docker, and Electron — spawns the standalone Next build's server.js via run-standalone.mjs, which prefers server-ws.mjs (built verbatim from scripts/dev/standalone-server-ws.mjs by assembleStandalone.mjs) over the bare server.js precisely because it wraps http.createServer with production behavior the bare server lacks. That wrapper never configured keepAliveTimeout/headersTimeout, so the JetBrains AI Assistant reconnect bug this issue reports still hit the production entry point after the first pass of this fix. Wire the same helper into the wrapped server object there too. |
||
|
Diego Rodrigues de Sa e Souza
|
c859931314 |
fix: add dashboard-scoped typecheck gate covering src/app/(dashboard) TSX (#7033) (#7203)
typecheck:core (the only blocking CI typecheck gate) runs against a curated 27-file allowlist that excludes all src/app/(dashboard) TSX, and next.config.mjs sets typescript.ignoreBuildErrors: true so next build never type-checks it either. Orphaned-identifier regressions there (the exact class fixed in #6625/#6909) were invisible to CI. Adds tsconfig.typecheck-dashboard.json (extends tsconfig.json, scoped to src/app/(dashboard)/**/*.ts(x)) plus check:dashboard-typecheck, a gate script that runs tsc against it and diffs per-file/per-TS-code error counts against a frozen baseline (config/quality/dashboard-typecheck-baseline.json, 262 pre-existing errors), following the same stale-enforcement allowlist pattern as check-known-symbols. Only NEW errors beyond the baselined count fail the gate; wired as a new blocking step in ci.yml (lint job) and quality.yml (fast-gates). Regression test (tests/unit/build/check-dashboard-typecheck.test.ts, 8 tests) reproduces the #6625/#6909 orphaned-identifier bug class against the pure parseTscOutput/diffAgainstBaseline helpers. |
||
|
Diego Rodrigues de Sa e Souza
|
c97d2a6ae2 |
feat(homolog): real-environment E2E homologation suite (npm run homolog) (#7133)
* feat(homolog): scaffolding da suíte de homologação E2E (deps + npm run homolog) * feat(homolog): L0 avaliador de paridade de deploy (TDD) * feat(homolog): L1a ciclo de vida de API key efêmera (login admin -> create -> revoke) * feat(homolog): L1b suite httpYac de API (models, chat, auth de management, health) * feat(homolog): L1c checker SSE de streaming real (TDD no parser) * feat(homolog): L2 smoke de providers reais via promptfoo gerado do catálogo * feat(homolog): L4a Playwright homolog config + login storageState * feat(homolog): L4b smoke de todas as rotas do dashboard (descoberta via fs) * feat(homolog): L4c fluxo criar/revogar API key pela UI * fix(homolog): resiliencia real-environment — stream:false no smoke promptfoo, retry de socket keep-alive, key efemera com sufixo unico * feat(homolog): L5 orquestrador npm run homolog + relatorio CTRF unificado * docs(homolog): guia de operacao da suite + fragment de changelog + allowlist env-doc-sync * fix(homolog): paraleliza o sweep de rotas do dashboard (fullyParallel + 8 workers) * fix(homolog): isola outputs crus em homolog-report/raw para nao quebrar o ctrf merge * fix(homolog): outputDir absoluto do reporter CTRF da UI (path relativo escapava do worktree) * chore(quality): allowlist the 5 homolog-suite devDependencies (ctrf-io trio, httpyac, promptfoo) after registry verification * chore(quality): register the homolog Playwright suite as a test-discovery collector (run.mjs -> tests/homolog/ui) |
||
|
Diego Rodrigues de Sa e Souza
|
5ab63203aa |
feat(release): post-publish verifier — clean-container install + boot (WS1.4) (#7109)
* feat(release): post-publish verifier — clean-container install + boot (WS1.4) verify-published.mjs installs the PUBLISHED version from the public registry inside node:24-slim and boots it until /api/monitoring/health returns 200 with the expected version — validating the exact bytes users install, on a machine with no repo/devbox state. Version + knobs travel as docker env vars, never interpolated into the container script (Hard Rule #13); strict semver arg validation. Wired into the release Phase 4 monitoring playbook. Live evidence: omniroute@3.8.48 from the real registry installed and booted in a clean container — HTTP 200, version 3.8.48, exit 0. Tests: 4 pure-function guards (semver strictness incl. shell-hostile rejects, env-passing invariant, clean-image pin, health-poll source guard). * chore(quality): allowlist verify-published container env vars in env-doc-sync |
||
|
Diego Rodrigues de Sa e Souza
|
5b8d63c094 |
chore(ops): runner-box janitor + operations runbook (WS3.3) (#7115)
* chore(ops): runner-box janitor script + operations runbook (WS3.3) Codifies what was manual discipline on the .113 self-hosted pool (two live incidents on the v3.8.47 release day): 30min cron sweeping stale runner temp/work dirs (>24h), disk-pressure alert at >=85% (SQLITE_FULL killed shards mid-run), and the proven 4-runner ceiling on the 16 GB box (8-wide OOM'd jobs; stopping a busy runner cancels its job — documented). Script smoke-tested live (disk 82%, 1 active runner, exit 0); bash -n clean. * docs(ops): reword error-code/bash-env mentions the fabricated-docs env detector misreads * fix(ops): harden janitor sweep — no symlink follow, -xdev, narrowed patterns (root-cron on world-writable /tmp) |