Validated on a 4-PR combined board: @omniroute/opencode-plugin provider.test.ts 13/13, full plugin suite 343/343, YAML validated, typecheck:core clean, gates within baseline. CI branch trigger was pinned to release/v3.8.2 since creation (never fired mid-cycle) — now tracks [main, release/**] matching every other workflow's pattern; combo-id fixture aligned to the real #10821 unprefixed-lookup contract (RED 11/13 → GREEN 13/13).
Cherry-picked onto the current tip (authorship preserved, Dockerfile.bun conflict with the just-merged #11163 resolved additively — runner-web stage after the new entrypoint). Three pre-merge fixes on the branch: (1) generated-count noise stripped; (2) runner-web stage now returns to the non-root bun user after the apt install (mirrors the Node Dockerfile runner-web re-asserting USER node — the stage previously ended as root); (3) the 6 new build/manifest steps SHA-pinned so the zizmor ratchet stays at 191<=192 findings instead of regressing to 197 (actionlint clean). Workflow YAML parses; runner-base/runner-web targets cross-checked against the Dockerfile stages. Thank you @rqzbeh!
⭐4 — Suporte de backend nativo Bun + Dockerfile.bun multi-stage + fallback dinâmico de driver SQLite (better-sqlite3 prioritário sob Bun, bun:sqlite fallback; Node preservado) + correção de estabilidade do DAST CI smoke.
Validado a fundo (worktree board sobre tip): bun-support 4/4, typecheck:core limpo, dashboard-typecheck OK (220 dentro do baseline), open-sse-typecheck OK (5 pré-existentes), gate de runtime OK sob Node, changelog-integrity OK, file-size/complexity/cognitive/dead-code OK. Verificado que o driver preserva a cadeia Node/falback conforme AGENTS.md; teste bun-support presente. Baselines de typecheck removidos são ratchet honesto (erros não existem mais).
OBS: destravei 2 base-reds do tip neste turno (push direto 7ffa3ef): movi o changelog fragment da #11050 da seção inválida breaking/ para fixes/, e rebaselinei AddApiKeyModal 1067->1073 (crescimento da #11056). Sem isso a #11039 e o resto da fila ficariam vermelhos.
Validado no worktree combinado: typecheck:core, changelog-integrity, file-size, lint e 7/7 testes focados passando. Investigação completa com verificação de ancestralidade via merge-base antes de fechar a issue original. CI vermelho é o base-red já rastreado em #9985.
Bump mecânico e verificado: `github/codeql-action/init` v4.37.6 → v4.37.7, 1 linha (SHA pinado) em `codeql.yml` — sequencial após #10929 no mesmo arquivo, sem conflito real. Diff conferido linha a linha. CI vermelho neste PR é o base-red já rastreado em #9985 (correção em andamento via PR #10778, outra sessão) — não é defeito deste bump. Obrigado, dependabot!
Bump mecânico e verificado: `github/codeql-action/analyze` v4.37.6 → v4.37.7, 1 linha (SHA pinado) em `codeql.yml`. Diff conferido linha a linha. CI vermelho neste PR é o base-red já rastreado em #9985 (correção em andamento via PR #10778, outra sessão) — não é defeito deste bump. Obrigado, dependabot!
Bump mecânico e verificado: `github/codeql-action/upload-sarif` v4.37.6 → v4.37.7, 1 linha em `docker-publish.yml`. Diff conferido linha a linha. CI vermelho neste PR é o base-red já rastreado em #9985 (correção em andamento via PR #10778, outra sessão) — não é defeito deste bump. Obrigado, dependabot!
Passo 10 of the Radar go-live: publish the OmniRoute catalog export the Radar
server consumes to a stable URL, so the 1 GB-RAM private server pulls it via
RADAR_EXPORT_URL instead of depending on the deploy-time snapshot.
- scripts/release/radar-export.mjs: emits {geradoEm, budgets, totais, registry,
provenance} from the catalog config modules. Provenance (sourceCommit,
sourceRef, runUrl, generatedBy) is never fabricated — unknown fields stay null.
- .github/workflows/radar-export.yml: on main catalog changes / manual dispatch /
weekly, generates the export and clobbers the stable 'radar-export-latest'
release asset (gh release, GH_TOKEN — checkout persist-credentials:false).
- tests/unit/radar-export.test.mjs: consumer contract (budgets[] non-empty) +
provenance null-when-unknown + GitHub-env reflection.
Stable URL for RADAR_EXPORT_URL:
https://github.com/diegosouzapw/OmniRoute/releases/download/radar-export-latest/export-omniroute.json
Re-baselines zizmorFindings 190->192 (+2 unpinned-uses @vN, the repo-wide
deliberate convention; artipacked auto-fixed).
Co-authored-by: Xiangzhe <bakryun0718@proton.me>
better-sqlite3 v13 ships Node-API prebuilds for every packaged platform
(darwin/linux/linuxmusl/win32 x x64/arm64) inside the npm tarball, so the
Electron-ABI node-gyp source rebuild in prepare-electron-standalone.mjs is
obsolete. Replace it with a fail-fast prebuild verification that mirrors
better-sqlite3 lib/binding.js selection, and strip build/deps/src so the
packaged loader can only resolve the prebuild.
Verified locally on darwin-arm64: the same darwin-arm64.node prebuild loads
under both Node 24 (NODE_MODULE_VERSION 137) and Electron 43.3.0 under
ELECTRON_RUN_AS_NODE (148); DB create/migrate/read/write/close/reopen pass
in both runtimes and cross-runtime on each other's database files.
Issue #10321 Stage 6.
The desktop release matrix ran the full Next.js standalone build on all four legs (windows, macos-intel, macos-arm64, linux), duplicating the platform-neutral majority of that work four times and re-exposing every leg to the hosted-runner RAM class of failure that took the linux leg out of v3.8.49.
- scripts/build/standaloneTarball.mjs: deterministic, dependency-free tar.gz writer/reader (uid/gid/mtime pinned, sorted entries, symlink + exec-bit preservation; GNU-tar interop covered by tests).
- scripts/build/standaloneManifest.mjs: byte-level manifest of .build/next (sha256 + size + symlink target per entry, plus the archive's own digest) catching artifact-transfer corruption before extraction and re-verifying the restored tree byte-for-byte, smuggling included.
- scripts/build/standaloneBundle.mjs: pack / restore / hydrate CLI over the two modules above.
- scripts/build/hydrateNativeDeps.mjs: swaps install-machine-forked native optionals (@img/sharp-*, @ngrok/ngrok-*, fsevents) from the leg's own npm ci into the restored tree, then verifies the bundled-native closure (koffi triplets, better-sqlite3 prebuilds, wreq-js, onnxruntime with its documented darwin-x64 exemption) services the leg's platform/arch before packaging starts.
- .github/workflows/electron-release.yml: new web-build job builds the standalone once on ubuntu with webpack and uploads the bundle; legs download, restore, and hydrate it, skipping the per-leg build. The legacy per-leg build remains as a rollback path via the ELECTRON_SHARED_STANDALONE workflow_dispatch input, and legs fail closed if web-build ran and failed.
Regression tests cover archive roundtrip, byte determinism, manifest tamper/smuggle detection, forked-native swaps, and native-closure serviceability.
* fix(guardrails): reroute zero-vision combos through the vision bridge
Named combos whose model targets all lack vision support are never
reroute-eligible: the bridge only attempts the describe path, and when
describing cannot run or fails the raw images stay in the payload and the
request dies in the combo capability filter with capability_mismatch.
getComboVisionBridgeDecision now returns a "no-vision" verdict for combos
with zero vision-capable targets, and preCall treats it as reroute-eligible
with the same credential guards as single text-only models, falling back to
describe only when no usable reroute target exists.
* chore(changelog): fragment for #10415 vision bridge combo reroute
* fix(guardrails): extend allNull stub fallback to no-vision combos
Reviewer follow-up (#10415): the allNull stub-text fallback at the end of
preCall only fired for comboVisionBridgeDecision === 'process'. In the
compound-failure case for a zero-vision combo — reroute target without
usable credentials AND every describe call failing — raw images were
preserved and the original capability_mismatch recurred, because a
no-vision combo has no target that can consume images.
Include 'no-vision' in the guard: stub text is strictly better than raw
bytes no combo target can consume. Adds a double-failure unit test.
* ci: re-run dast-smoke (Build CLI bundle runner timeout flake)
* fix(build): bound and retry the opencode-plugin npm install in prepublish
The plugin's node_modules is gitignored, so every fresh CI checkout runs a
full npm install inside @omniroute/opencode-plugin during build:cli. npm's
unbounded fetch retries turn a stalled registry CDN connection (the recurring
onnxruntime-class ETIMEDOUT flake) into a 20-30 minute hang — the DAST
'Build CLI bundle' step has been cancelled at the 30m cap repeatedly.
- Bound npm fetch: --fetch-timeout 60s, 2 retries with capped backoff — a
stalled connection now fails fast instead of hanging the job.
- Retry the install up to 3 times with a 10s pause between attempts, so
transient CDN failures recover in-build.
Net effect: the step either completes (network OK) or fails quickly with a
clear error (network down) — it can no longer eat the whole job budget.
* ci(dast): use existing npm-ci-retry action instead of bare npm ci
dast-smoke died at 'Run npm ci' with connect ETIMEDOUT to the
onnxruntime-node binary CDN (Microsoft 150.171.x.x) — the same
transient CDN flake class that has hit Vitest/Quality Gates before.
quality.yml already wraps npm ci in ./.github/actions/npm-ci-retry
(3 attempts, exponential backoff); dast-smoke was the one workflow
still using a bare install. Use the existing action for consistency.
* ci(quality): use the npm-ci-retry action on every install step
Fast Quality Gates failed on the recurring onnxruntime-node postinstall
ETIMEDOUT (Microsoft CDN 150.171.x.x) - the same transient flake that has
hit Vitest and dast-smoke today. Only the Build job used the retry action;
the other five jobs (Docs, Fast Quality Gates, Vitest, Unit Tests,
changelog) still ran a bare install and die on any CDN hiccup. Use the
existing retry action (3 attempts, exponential backoff) on every install
step for consistency.
---------
Co-authored-by: Rouzbeh <rqzbeh@users.noreply.github.com>
* fix(ci): pin Build (advisory) to a hosted runner with memory provisioning
`Build (advisory)` has been reporting a permanent red on every PR while
producing no usable signal at all.
Measured over the last 25 quality.yml runs (2026-08-14): not one instance of
the job reached a conclusion. Every sample was either queued on the
self-hosted pool — 2 runners, omniroute-113-6/7, both permanently busy; one
job sat queued for over 2 hours and was still unclaimed — or, when it did land
on a runner, killed mid-build by this workflow's own cancel-in-progress
concurrency. All 6 sampled "failures" are exit 143 / "The runner has received
a shutdown signal" at ~3.5 min into `npm run build`. Zero OOM, zero build
errors. The job was consuming a runner the real gates compete for while
telling every PR author it was broken.
Gap 19 deliberately left USE_VPS_RUNNER governing build-like jobs, on the
premise that the build needs the .113's RAM. That premise no longer holds:
`Fast Production Build` (build.yml) runs `build:release` — a superset of this
job's `npm run build`, plus the CLI bundle — on plain ubuntu-latest and passed
24 of its last 25 runs in ~15 min. The difference is memory PROVISIONING, not
the machine: a 10 GB swapfile plus a 12 GB V8 heap. Swap is the part that
matters, because --max-old-space-size bounds only V8's JS heap and never
Turbopack's native Rust allocation (#6409).
Pins the job to ubuntu-latest and mirrors both settings from build.yml.
USE_VPS_RUNNER keeps its other consumers (ci.yml Build, nightly-release-green,
npm-publish), so the variable stays meaningful. Fork safety is strictly
improved: no PR can reach the LAN runner through this job any more.
check:workflows --ratchet: 186 zizmor findings, baseline 190, no regression.
prettier + YAML parse: clean.
* fix(ci): scope Build (advisory) to fork PRs
Follow-up to the hosted-runner pin in this same PR, after measuring what the
job is actually for.
build.yml's `Fast Production Build` triggers on `push: branches: ["**"]` and
runs `build:release` — a superset of this job's `npm run build`, plus the CLI
bundle. For an own-origin branch that push fires here, so the tree was being
built twice per PR. A fork contributor pushes to THEIR repo, so build.yml
never runs in this repo and this job is their only pre-merge build signal.
That could have argued for deleting the job, except the traffic says
otherwise: 72 of the last 100 PRs into release/** come from forks. The fork
case is the majority, not the exception. So the job earns its place — it just
should not duplicate build.yml for the own-origin 28%. Added the fork filter
to the existing `if`.
Also corrects the reliability claim in the previous commit message. Over a
wider window the job is not literally never-green: across 2026-08-13/14 it
reached `success` on roughly 10-15% of runs (13/138 on 08-14, 7/53 sampled on
08-13). Chronically unreliable, not permanently dead — the conclusion and the
fix are unchanged.
The #7307 guard in tests/unit/build/check-workflows.test.ts pinned the old
self-hosted expression, so it is realigned here: it now asserts the hosted
pin, the absence of self-hosted/USE_VPS_RUNNER in the job's DIRECTIVES (the
comment legitimately explains why the pool was abandoned, so the scan strips
comments), both memory settings, and the fork filter. Mutation-validated —
restoring self-hosted, dropping the swapfile, or flipping the fork filter each
turns it red.
check-workflows.test.ts: 32 pass, 0 fail.
check:workflows --ratchet: 186 findings, baseline 190, no regression.
---------
Co-authored-by: Xiangzhe <bakryun0718@proton.me>
tests/e2e/ecosystem.test.ts and tests/e2e/protocol-clients.test.ts appear in the
AGENTS.md test matrix but ran in no workflow, and could not run at all: both are
listed in vitest.config.ts include AND exclude, and their runners invoked Vitest
without --config, so the default config's exclusion discarded the very file each
passed as a positional filter.
No test files found, exiting with code 1
filter: tests/e2e/ecosystem.test.ts
Add vitest.e2e-live.config.ts covering only these two suites, point both runners
at it, and drop the contradictory include entries. The exclusions stay: these
drive a real server and must never run in the jsdom UI job.
Wire both into CI. test-ecosystem is blocking (20/20 green). test-protocols-e2e
is advisory pending #10049 — restoring it surfaced a pre-existing discrepancy
where GET /api/mcp/audit answers 403 over loopback against an expected 200|401.
* fix(ci): clear base-reds on release/v3.8.50 (round 3)
- CHANGELOG.md: restore the top [Unreleased] section dropped by the #10189
reconcile (docs-sync gate: first section must be Unreleased)
- env-doc-sync: document CONDUCTOR_ORCHESTRATOR_TOKEN + CONDUCTOR_SPOKESPERSON_URL
in .env.example/ENVIRONMENT.md; allowlist the CI-only GITHUB_STEP_SUMMARY and
TS7_BASE_REF (ts7 ratchet signals); drop a stray merge artifact line
- providers: restore the audited chatanywhere metadata entry that base-reds
round 2 dropped together with its duplicate — the provider was half-wired
(registry+endpoint without APIKEY metadata), which is what the wave3 test
catches; re-pin providers-constants-split at the measured 228
- docs counts: 338 -> 339 (today's +2 void-ai/helixmind, -1 Puter) via
gen:provider-reference + README/AGENTS/llm.txt/package.json/diagrams/i18n mirrors
- file-size ratchet: annotated rebaseline for the two pre-existing drifts
(ModelSelectModal 1138, gateways 1250) following the 2026-08-11 precedent
Refs #9985
* fix(ci): base-reds round 3b — stale sibling tests + mode-pack weight contract
- check-docs-counts-sync.test.ts: drop the imports/subtests of the four helpers
#10196 removed from the gate script (readMcpFactsFromSource, listLocalizedDocs,
makeRequiredCountsValidator, checkFreeTierInventory) — the new-API tests that
#10196 added stay; the file now loads again under the node runner
- quota-connection-recovery.test.ts: convert from vitest APIs to node:test —
the file lives in tests/unit/*.test.ts (node-runner glob) and the vitest
runtime crashes when imported outside vitest, killing the whole shard entry
- modePacks.ts: re-normalize all six mode packs to sum 1.0 — #8940 added
sessionAvailability: 0.05 to every pack without rebalancing (1.05 total);
ratios preserved exactly (÷1.05), so post-normalizeScoringWeights behavior
is unchanged; restores the declared sum-to-1.0 contract the 4235 test pins
Refs #9985
* fix(ci): base-reds round 3c — vitest siblings, weights default, secrets FP, mutation tap
- DistributeProxiesButton.test.tsx: wrap renders in NextIntlClientProvider —
#9245 localized the component (useTranslations) and left the test without
the intl context, failing all 14 cases
- scoring.ts: re-normalize DEFAULT_WEIGHTS to sum 1.0 (same #8940 class as the
mode packs — sessionAvailability added without rebalancing; ratios preserved)
- .gitleaks.toml: generalize the kimi sponsor-banner localStorage-key allowlist
to -v\d+ — #10200 bumped v1→v2 and the stale regex regressed the secrets
ratchet with a false positive
- stryker.conf.json: register 6 covering unit tests in tap.testFiles (4 modules)
so their mutant kills count — unblocks check:mutation-test-coverage --strict
Refs #9985
* fix(ci): base-reds round 3d — inspector factor gap, stale registry/gap tests, i18n key sync
- comboScoringInspector: add cacheAffinity/sessionAvailability/connectionDensity
to FACTOR_KEYS + the factor-key type — calculateScore() weighs them but the
breakdown omitted them, so the explained contributions never summed to the
reported score (inspector bug, red on the pure tip)
- combo-scoring-inspector.test: make the explicit-weights override sum-neutral
(±0.05 shift) so it stays valid for any DEFAULT_WEIGHTS values — the hardcoded
override only summed to 1.0 against the pre-#8940 defaults, which is also why
explicit weights silently fell back to 'default' on the tip
- unorouter-registry.test: align to the canonical .com host (api.unorouter.ai
301-redirects there, verified live) and to wave4's live model discovery
(passthrough, no static seed) — the .ai/auto-model expectations were stale
- check-migration-numbering.test: 147 left KNOWN_GAPS when
147_api_keys_model_access_mode.sql landed — assert absent (same as 143)
- i18n: sync-ui pass — 35,914 missing UI keys stamped as __MISSING__ placeholders
across 42 locales (mechanical; greens the pt-BR key-presence integrity test;
coverage pct unchanged by design — translation is a separate workstream)
Refs #9985
* fix(ci): base-reds round 3e — 2 real defects + 14 stale sibling tests (waves A-E)
Real defects fixed:
- src/lib/db/apiKeys.ts: #9313's empty-allowlist early return bypassed the group
permission check, silently disabling group deny rules (#8817) for every key
without a per-key allowlist; fall-through restored, restricted+[] deny-all kept
- open-sse/utils/proxyFetch.ts: #10032 re-appended the raw transport error to the
propagated message, reintroducing the proxy user:password leak #9837 closed;
new redactProxyDetailsInMessage() keeps the reason, redacts URL/credentials
- .github/workflows/quality.yml: #10134 added the TS7 ratchet as a separate
blocking step AFTER the aggregated gates — the exact #8542 masking mechanism;
folded into the non-fail-fast loop (still blocking, still PR-only) ⚠️ CI edit,
gate-strengthening — explicit owner sign-off requested on the PR
- src/i18n/messages/ko.json: 3 machine-mistranslation regressions caught by the
#8244 glossary checker (장애인→비활성화됨, 양말5://→socks5://, 비클로드→Claude가 아닌)
Stale sibling tests aligned to deliberately-moved contracts (each cites its mover):
request-log-detail-layout + -stream (#9245 intl provider), repro-8542 pin update,
quality-rail-gate-membership (#10134 shape), agentSkills-routes 45→46 (#9058),
cloudflare-ai-catalog-8717 (#8804 supersedes #8808), executor-xai (#9994),
vision-bridge-claude-wire (#9463 minimax→openai), sse-auth forced-pin (#8893),
tls-proxy-context (strengthened leak guards), rate-limit-local-error-classification
(#9164/#9342), minimax-thinking-signature (#9463), codebuddy-cn (#9723 +1 test),
github-copilot-custom-model (#9050), providers-g4f-batch3 (#9584),
synced-capability-warmup (#9199, stricter), sidebar-tools-group (#8221),
oauth-modal-grok-cli-paste (#9245); agentSkills/catalog.ts comment 45→46;
file-size rebaseline for proxyFetch (+19, annotated)
Refs #9985
* fix(ci): base-reds round 3f — waves F-J: 9 more real defects + stale sibling sweep
Real production defects fixed (all red on the pure tip, each with its origin):
- routeGuard.ts: #8949 accidentally DELETED the /api/providers/[id]/login
local-only pattern — the route spawns a browser, so the loopback gate for a
process-spawning route was gone (Hard Rules #15/#17); restored (314 guard
tests green)
- agentSkills generator: #9058's category dispatch gave the config category an
empty body, wiping skills/config-codex-cli/SKILL.md at the #10131 sync;
fixed + SKILL.md regenerated via the official generator
- imageRegistry: #9982 broke same-provider bare aliasing (antigravity preview
id sent upstream unresolved); new resolveSameProviderBareAlias() keeps the
fal cross-provider fix intact
- imageRegistry: #9982's prefix strip handed the bare nano-banana ids to fal-ai,
violating the pinned 2026-07-31 operator decision (adobe-firefly owns them);
fal entries made prefix-only (dispatch already re-prefixes)
- mediaGeneration/fal.ts: the missing-credential 401 guard was lost when #10198
deleted the superseded falHandler — tests were hitting the live network
- bottleneckPatch/rateLimitManager: #9041's merge clobbered #9604, resurrecting
the Bottleneck v2.19.5 heartbeat bug (reservoir never refills); patched the
library defect at the root and re-aligned chat-rate-limit-body-lock to the
working reservoir contract
- processSupervisor.mjs: #9761 regressed the Node spawn to bare "node" (the
#9156 launchd bug) and dropped #9209's ipv4first args; both restored
- openai-responses/pureHelpers: #9423's Agent null-sentinel was unreachable on
the schemaless JSON-string path; gate extended
- i18n en.json: #8222's regen reverted the #9976 unclosed-tag fix and #8559's
combo-cooldown copy; #9038 shipped 40 t() calls with no messages (runtime
MISSING_MESSAGE); all restored/added + official sync-ui stamps, and vi's
zero-marker policy re-established via the sanctioned translation backend
Stale sibling tests aligned (movers cited inline): chat-helpers (#9447),
executor-antigravity (#9351), video-fal-grok (#9982), visionBridge (#9759),
web-session-credentials (#8974), production-build-module-integrity (positive
anchor added), agentSkills-generator/skillManifestsLint/skills-injection/
agentSkillTools-mcp/listCapabilities-a2a (#9058), memory-settings (#10010),
model-catalog-policy-invalidation (#8906), model-alias-seed (#9485),
reactive-context-compaction (#8949), combo-provider-wildcard (broken upsert
helper), oauth-google-loopback (43-locale resurrected-key removal)
Validation: 501/501 across the 47 touched test files; typecheck:core, lint,
file-size, docs-sync all green.
Refs #9985
* fix(ci): base-reds round 3g — wave K/L: 4 more real defects + stale alignments
Real defects:
- base/reasoningEffort.ts: the stale duplicate cherry-pick #9612 re-added the
codex minimal→low rewrite that #9883 had deliberately removed (OMP minimal
passthrough); block removed again
- cursorImages.ts: #9840 wired prepareCursorImageForWire (sharp re-encode,
fail-closed) into the SHARED resolveCursorImages, breaking zai-web and
conol-web image uploads (HTTP 400 'undecodable'); new prepareForWire opt-out,
Cursor default path unchanged (8 cursor suites green)
- modelCapabilities/snapshot: catalog prepare still issued 323 per-model reads
of model_context_overrides + max_input_tokens overrides, violating #9199's
bulk-load contract; both now resolve from the snapshot single pass
- v1-models-discovery-conformance: re-pinned to the bounded 30s SWR window
(#9199/#10198) — the old 'stale-first regardless of age' contract is gone
Stale tests aligned (movers cited inline): codex-tools-strict-default (#9828
redundant-oneOf strip), devin-providers (#9245 i18n), db-migrationrunner-
constants-split (147→151 renumber #8228), gitlab-duo-oauth-setup (#9245),
chatcore-extracted-modules (#9161 outbound-protocol keying)
compression-api CI failures were cascade artifacts of codex-tools-strict-default
failing in the same force-exit shard process — no own defect (171/171 local).
Refs #9985
* fix(test): compression-api — register both describes before the runner starts
The DATA_DIR setup + route/db top-level awaits sat BETWEEN the two describes;
under --test-force-exit (the CI unit-runner flag) the process exits once the
already-registered tests finish, so on slow CI machines the whole second
describe died as 'Promise resolution is still pending' — the recurring
CI-only shard-2 failure that never reproduced locally without the flag.
Moved to the top of the file; 10/10 under --test-force-exit locally.
Refs #9985
* fix(quality): freeze modelCapabilities.ts at 1006 (annotated) — snapshot routing growth
Refs #9985
* fix(quality): move the modelCapabilities freeze into the frozen map (nested schema)
Refs #9985
* fix(i18n): translate all 39,718 pending UI keys across 42 locales (owner-approved)
Mass-translated every __MISSING__ placeholder via the official i18n:sync-ui
--translate-markers pipeline (operator backend), restoring i18nUiCoverage to the
100 baseline (was 89.9 after the merge-storm UI landings + the 42 keys #9038
never shipped).
Post-pass repairs, all caught by the existing gates:
- glossary: retired renderings the machine reintroduced normalized again
(提供商→提供者 zh-CN/zh-TW, 鏈接→連結, 文檔→文件, 調用→呼叫, 供應商→提供者,
響應→回應, 不活躍→未啟用 zh-TW; 클로드→Claude, 옴니루트→OmniRoute ko);
DATA_DIR forbidden rendering avoided via 数据文件夹 rephrase
- ICU integrity: 120 values with renamed/dropped {params} repaired (39
positional renames, 81 reset to the en source — functional over fluent)
Validation: glossary/pt-BR/vi/deno-relay/settings-keys/value-drift/google-
loopback suites 76/76; placeholder diff en×42 locales = 0; worst-locale
coverage = 100.0%.
Refs #9985
---------
Co-authored-by: backryun <bakryun0718@proton.me>
* fix(dashboard): correct machine-translated Korean UI strings in ko.json
Fix 527 mistranslated values in the Korean locale, all verified against
the en.json source:
- Restore protected product/protocol names garbled by machine translation
(응록→ngrok, 인류/인류학→Anthropic, 쌍둥이자리→Gemini, 반중력→Antigravity,
꼬리비늘 깔때기→Tailscale Funnel, 진공→VACUUM, 우편번호→ZIP)
- Fix wrong-sense homonym translations (달리기→실행 중 for Running,
장애인→비활성화됨 for Disabled, 열쇠→키 for Key, 안타→적중 for Hits,
유물→아티팩트 for Artifacts, 건강검진→상태 확인 for Healthcheck)
- Repair translated identifiers that broke literal values (양말5→socks5,
볼록-세션-id→convex-session-id, 채팅/완료→chat/completions,
메시지/보내기→message/send JSON-RPC methods)
- Replace key-name dumps shipped as values ("Table Name", "Overview
Title", "Cli Tools Redirect Title" etc.) with real Korean translations
- Unify ngrok casing (Ngrok→ngrok) and trailing punctuation with the
English source; align terminology across fixes (공급자, 폴백, 사용자 정의)
All {placeholder} tokens, markdown, and protected terms preserved
verbatim; i18n UI coverage and ko validation gates pass.
* feat(ci): extend i18n glossary-consistency gate to ko
Follow-up to #8224 (ko.json mistranslation cleanup): the glossary gate
only checked zh-CN, leaving the Korean catalog unguarded against the
next machine-translation run reintroducing the garbage it fixed.
- Add scripts/i18n/glossary/ko.json: 9 canonical concepts (provider,
fallback, running/disabled states, key, export, healthcheck, port,
artifacts) plus protectedTermMistranslations for 10 verified garbled
renderings (응록→ngrok, 인류→Anthropic, 쌍둥이자리→Gemini,
반중력→Antigravity, 꼬리비늘→Tailscale, 진공→VACUUM, 양말5→socks5,
우편번호→ZIP, 클로드→Claude, 옴니루트→OmniRoute)
- Extend check-glossary-consistency.mjs to merge per-locale
protectedTermMistranslations from the glossary file with the legacy
zh-CN KNOWN_MISTRANSLATIONS map (behavior for zh-CN unchanged)
- Add ngrok/Anthropic/Claude/Gemini/Antigravity/Tailscale/VACUUM/
socks5/ZIP to protected-terms.json
- Wire --locale=ko into the i18n-glossary CI job and add the
i18n:check-glossary:ko npm script
- Tests: merge semantics (3 new unit tests), #8224 regression guards
for src + bin/cli ko catalogs, and real-file pass assertions for ko
Every enforced synonym/mistranslation was verified to have zero
occurrences in both real ko catalogs; collision-prone candidates
(안타 ⊂ 안타깝게도, 배우 ⊂ 배우기) were deliberately excluded.
* docs: centralize agent instructions in AGENTS.md; CLAUDE/GEMINI point to it
- AGENTS.md becomes the single source of truth: full CLAUDE.md content (main
data) merged with the AGENTS.md-only sections (documentation accuracy,
repository map, review focus, upstream contributions) and the GEMINI.md-only
file-placement/root-hygiene and local-access rules. Adds the base-green
check section (PRs must not be born red) and fixes the stale
_tasks/release-flow path in Hard Rule 21.
- CLAUDE.md: @AGENTS.md pointer + Claude-Code-only operational deltas
(EnterWorktree, subagent stash-ban replication, superpowers path overrides,
base-green/sweep-reds pointers).
- GEMINI.md: pointer + Gemini-only notes; the stale 10-item hard-rule mirror
is removed (source is the 22-rule list in AGENTS.md).
- ci(release-green): label the not-green tracking issue with base-red.
* docs: retarget docs-sync provider/MCP claims to AGENTS.md and fix test placeholder
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Add a windows-latest matrix leg to the test-bun-sqlite CI job with
continue-on-error: true for advisory Windows+Bun coverage.
Update CLAUDE.md Bun section to note the advisory Windows leg.
* chore(ci): stop dependabot from grouping ioredis majors with routine bumps
ioredis is loaded through a dynamic import in the distributed quota store, so a
breaking major passes build, typecheck and both test suites and only surfaces at
runtime for operators running Redis-backed quota. #9310 grouped ioredis 5.10.1 to
6.0.0 with 9 unrelated production bumps; majors get their own PR from now on.
* docs(changelog): add fragment for #9425
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* feat(ci): G0 — quality rail (PR→release/**) ganha ratchets+segurança do trilho A
O refactor de god-files do trilho 3.8.50→3.9.0 acontece em PRs→release/**, e esse
trilho pulava o motor de ratchet, o CodeQL ratchet e todos os scanners de segurança
— exatamente onde a rede era necessária (5 das 13 causas da reconciliação de 07-24
eram regressões reais shipadas por CI verde por-PR).
Modo enxuto, jobs EXISTENTES (a .51 consolida lanes; nenhum job novo):
- lint-guard: quality:collect + ratchet --allow-missing + require-tighten +
check:codeql-ratchet. O job já escreve .artifacts/eslint-results.json, então o
motor entra a custo ZERO de ESLint (um inventário, dois consumidores). Coverage
ausente degrada gracioso (--allow-missing); autoridade de coverage segue no
trilho A. + permissions security-events:read para o CodeQL ratchet.
- fast-gates: check:cycles, check:lockfile, duplication, dead-code, type-coverage,
compression-budget + install endurecido dos scanners (gh release download,
zizmor PINADO 1.25.2 = mesmo auditor do ci.yml) + secrets/vuln/workflows/
openapi-breaking com --ratchet (self-skip sem binário; só regressão medida bloqueia).
- Fora de propósito: bundle-size (self-skip sem build → configuração morta) e o
run de coverage (fast-unit já roda a suíte cheia).
Runners intocados: guard tests/unit/vps-runner-variable-scope.test.ts verde;
teste novo tests/unit/quality-rail-gate-membership.test.ts pina a MEMBERSHIP dos
gates no trilho B (red antes da edição, green depois).
Validação no tip puro (nenhum base-red fabricado para a fila de PRs abertos):
cycles OK · lockfile OK · duplication 4.26% (base 5.72%) · dead-code 226 (base
227) · type-coverage 94.13% (base 92.17%) · compression OK · secrets 0 (base 0) ·
vuln 5 (base 10) · codeql 0 (base 0) · oasdiff 0 (base 0) · zizmor 178 (base 190)
· actionlint exit 0 no arquivo editado · quality-ratchet 56 métricas OK +
require-tighten OK com --allow-missing.
Refs #8084
* feat(.50): G13 golden-set, G14 import boundaries, gap34 deterministic, docs sync, R0.2 dead hooks
Integra os itens restantes da 3.8.50:
- G13: golden-set determinístico para combo.ts e chatCore.ts via seams públicas
- G14: no-restricted-imports para localDb barrel fora de src/lib/db/ e executors em src/app/
- Gap34: teste determinístico de timeout DuckDuckGo sem rede real
- Docs: golden path de contribuição + sincronização de números canônicos
- R0.2: remoção dos 7 hooks mortos do BUILTIN_EVENTS + UI marketplace ajustada
* fix(r0.2): remove marketplace tab remnants from plugins page — fixes dashboard typecheck regression
* chore(r0.2): remove pluginWorker.ts, signing.ts, sandbox.ts — zero importers confirmed
* fix(docs): remove OMNIROUTE_PLUGINS_ALLOW_EXEC reference — env var removed with pluginWorker.ts in R0.2
* fix(env): remove dead OMNIROUTE_PLUGINS_ALLOW_EXEC from .env.example — consumer removed in R0.2
* fix(test): update sidebar-visibility assertion for R0.2 marketplace removal
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
O refactor de god-files do trilho 3.8.50→3.9.0 acontece em PRs→release/**, e esse
trilho pulava o motor de ratchet, o CodeQL ratchet e todos os scanners de segurança
— exatamente onde a rede era necessária (5 das 13 causas da reconciliação de 07-24
eram regressões reais shipadas por CI verde por-PR).
Modo enxuto, jobs EXISTENTES (a .51 consolida lanes; nenhum job novo):
- lint-guard: quality:collect + ratchet --allow-missing + require-tighten +
check:codeql-ratchet. O job já escreve .artifacts/eslint-results.json, então o
motor entra a custo ZERO de ESLint (um inventário, dois consumidores). Coverage
ausente degrada gracioso (--allow-missing); autoridade de coverage segue no
trilho A. + permissions security-events:read para o CodeQL ratchet.
- fast-gates: check:cycles, check:lockfile, duplication, dead-code, type-coverage,
compression-budget + install endurecido dos scanners (gh release download,
zizmor PINADO 1.25.2 = mesmo auditor do ci.yml) + secrets/vuln/workflows/
openapi-breaking com --ratchet (self-skip sem binário; só regressão medida bloqueia).
- Fora de propósito: bundle-size (self-skip sem build → configuração morta) e o
run de coverage (fast-unit já roda a suíte cheia).
Runners intocados: guard tests/unit/vps-runner-variable-scope.test.ts verde;
teste novo tests/unit/quality-rail-gate-membership.test.ts pina a MEMBERSHIP dos
gates no trilho B (red antes da edição, green depois).
Validação no tip puro (nenhum base-red fabricado para a fila de PRs abertos):
cycles OK · lockfile OK · duplication 4.26% (base 5.72%) · dead-code 226 (base
227) · type-coverage 94.13% (base 92.17%) · compression OK · secrets 0 (base 0) ·
vuln 5 (base 10) · codeql 0 (base 0) · oasdiff 0 (base 0) · zizmor 178 (base 190)
· actionlint exit 0 no arquivo editado · quality-ratchet 56 métricas OK +
require-tighten OK com --allow-missing.
Refs #8084
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* fix(ci): five workflow defects, one of them shipping the wrong dmg to Intel Macs
Gaps 31, 19, 16, 30 and 12 of the v3.8.49 process dossier.
## 31 — LIVE BUG: an Intel Mac downloads the ARM dmg
electron-builder runs once per macOS job and each run emits its own
`latest-mac.yml` listing only its own dmg — measured at 338 and 350 bytes,
different content, identical filename. `download-artifact` with
`merge-multiple: true` resolves that collision by ARRIVAL ORDER, so one silently
overwrites the other. arm64 won in the published v3.8.48.
Why that breaks Intel, from electron-updater's own selection code
(out/providers/Provider.js):
files.find(it => [...].some(n => n.includes(process.arch))) ?? files.shift()
The Intel dmg is `OmniRoute-X.Y.Z.dmg` — no arch suffix. On Intel `process.arch`
is "x64", nothing matches, and the fallback takes the FIRST entry. With an
arm64-only manifest that is the ARM build.
So ORDER is the fix, not tidiness: the un-suffixed entry must be first, because
it is the only one reachable through that fallback. `merge-multiple` is now off
(per-artifact subdirectories) and a new
`scripts/release/merge-mac-update-manifest.mjs` merges them deliberately. It
refuses to write when the inputs disagree on version — a manifest stitched from
two builds points at files that were never published together, which is worse
than no manifest.
Validated against the REAL v3.8.49 manifests, not just fixtures: the script
reproduces byte-for-byte the manifest I hand-merged and published, including
both sha512 values and the newer releaseDate.
## 19 — one variable, two opposite machines
`USE_VPS_RUNNER` governed the build and the test jobs together. The build needs
the .113's RAM; the tests need the hosted runner's link. Measured 2026-07-29:
`actions/setup-node` took 20m06s on .113 with 4 concurrent runners versus 16s
hosted (npm cache restore saturating the link), while the tests themselves tied
— 2m54 vs 2m31.
Self-hosted is therefore strictly worse for tests, so rather than add a second
variable to configure, `test-unit`, `test-vitest`, `fast-unit` and `fast-vitest`
are pinned to `ubuntu-latest`. `quality.yml`'s `fast-gates` deliberately keeps
the variable — I have no measurement for it, and guessing is what produced this
gap.
## 16 — a flaky shard sent the publish into the 40-minute build
The artifact reuse filter required `conclusion == "success"` on the whole run, so
any unrelated red shard discarded a perfectly good tree. The artifact is only
uploaded if the Build job succeeded, so its PRESENCE is the accurate signal. Now
it takes the 5 most recent candidate runs and tries each download until one
works. `head_repository.full_name == env.REPO` stays — that clause is the
artifact-poisoning guard, not a filter refinement.
## 30 — the gate that could be bypassed at merge
`check:agent-skills-sync` lived only in quality.yml's PR-only Merge-integrity
job, because the CHANGELOG half of that job needs a base to diff against. This
half does not. Keeping it PR-only left a real hole: this cycle's merge trains
landed with `--admin`, which bypasses required checks, so three SKILL.md files
drifted, rode the release squash into `main`, and the sync-back turned them into
a base-red blocking EVERY PR into release/v3.8.50 until #8954. It now also runs
in ci.yml's lint job, which runs on push to `main`.
## 12 — a cancelled gate reads like a passing one
The dashboard already renders `⚫ CANCELLED` per job, so my dossier entry was
imprecise: they do not vanish, they sit buried mid-table. A cancelled job
reported no verdict at all, and this cycle the Vitest job was cancelled in rounds
1, 2 and 3 — it finished only in round 4, revealing a suite broken the whole
cycle plus two production bugs. The summary now opens with a banner naming every
cancelled job and saying plainly that nothing was checked.
node --import tsx/esm --test tests/unit/mac-update-manifest-merge.test.ts # 11 pass
merge against the real v3.8.49 manifests → both dmgs, Intel first
all four workflows parse; check:workflows --ratchet → 178, baseline 190
* docs(changelog): fragment for #8988
* test(ci): align the artifact-provenance guard with the gap-16 criterion
My own assertion from #8953 encoded the criterion this PR deliberately removes:
it required `.conclusion == "success"` on the whole CI run, which discarded a
perfectly good build tree whenever any unrelated shard went red — pushing the
publish into the 40-minute build the fast path exists to avoid.
Inverted rather than deleted, and the replacement is strictly stronger. It now
pins three things where the old one pinned one: that the loose criterion is gone,
that the step actually probes for the artifact (the accurate signal, since it is
only uploaded when the Build job succeeded), and that it probes MORE THAN ONE
candidate run — without which a single miss still falls back to a full build.
The provenance clause it was originally written to protect
(head_repository.full_name == env.REPO) is untouched and still asserted above.
* fix(ci): finish gap 19 — pin fast-gates and give USE_VPS_RUNNER one meaning
This was left deliberately partial because `fast-gates` had never been measured,
and guessing is what produced gap 19 in the first place. Measured now, and the
evidence is cleaner than expected:
fast-gates, 160 quality.yml runs .... ZERO self-hosted samples
every non-skipped one is "GitHub Actions NNNN"
median duration, 72 successful runs .. 5.6 min hosted
The classifier is not at fault — in the same window ci.yml's Build demonstrably
ran on omniroute-113-7 and omniroute-113-6, so self-hosted runs are visible when
they happen. The USE_VPS_RUNNER expression on this job was dead configuration.
And had it ever fired it would have inherited the measured penalty, because this
job's first two steps are exactly the bottleneck:
actions/setup-node on .113 with 4 concurrent runners .... 20m06s
actions/setup-node hosted .............................. 16s
So it is pinned rather than switched, and the second variable the gap proposed
(USE_VPS_RUNNER_BUILD / _TESTS) turns out to be unnecessary. After this the
variable governs exactly five jobs, all of them build-like:
ci.yml:build · quality.yml:build · npm-publish:publish
nightly-release-green: release-green, main-green
One variable, one meaning: "this job needs the .113's memory". A guard test pins
that — it fails if the variable is ever attached to a test-like job again, and it
also asserts the build KEEPS it, so nobody closes this gap by removing the
variable outright.
node --import tsx/esm --test tests/unit/vps-runner-variable-scope.test.ts # 3 pass
check:workflows --ratchet → 178, baseline 190
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* fix(ci): stop the reconciliation range and the fragment sweep from hiding work
Two release-tooling defects found during the v3.8.49 run (gaps 4 and 7 of the
process dossier). Both fail by hiding work rather than announcing themselves,
which is why each one had already cost a real mistake.
## The reconciliation range was 62× too wide
`list-uncovered-commits.mjs` bounded its scan with `git describe --tags`. Releases
reach `main` by SQUASH, so no commit on a release branch is ever an ancestor of the
tag, and `vPREV..HEAD` re-lists the un-squashed history of every earlier cycle.
Measured on release/v3.8.50 @ 7eca04fd12:
v3.8.49..HEAD ....... 1361 commits
cycle open..HEAD ..... 22 commits
The report drowns in noise, and that is how a previous reconciliation let ~200 PRs
through with no CHANGELOG bullet.
The base is now resolved by CONTENT — the oldest commit that introduced this
version string into package.json — deliberately NOT by commit subject, because the
subject has already changed format once:
chore(release): bump v3.8.49 (development cycle version) older
chore(release): open v3.8.50 development cycle current
A message-matching resolver would have silently reverted to the broken tag base the
first time someone reworded the bump. The fallback now writes a WARNING to stderr
explaining that a tag range re-lists previous cycles, so a shallow clone degrades
loudly instead of quietly reproducing the bug. One of the five tests asserts
exactly that the warning says "squash" and "noise".
## The back-merge resurrects fragments that already shipped
The release lands on `main` as one squash commit, so `main` still carries every
`changelog.d/` fragment the reconciliation folded in and deleted. Back-merging
`main` restores all of them — 191 in the v3.8.49 run. Nothing breaks at that
instant; the next aggregation folds them in a SECOND time and the section grows
duplicates that have to be hand-unpicked.
New `scripts/release/sweep-stale-fragments.mjs` (`npm run sweep:stale-fragments`)
reports them, and `--apply` removes them. Report mode exits 1 so the back-merge
step can gate on it.
The identity rule took two attempts, and the second one exists because running the
script against the live repo refuted the first. Matching on any `#N` in the bullet
flagged `changelog.d/features/8980-deprecate-gemini-cli-provider.md` as stale,
because that bullet cites issue **#7034** for context and #7034 shipped in an
earlier cycle — it would have deleted an unreleased fragment and dropped its
credit. A bullet routinely cites issues it merely references; only the
`<PR-number>-<slug>.md` filename says which PR the fragment *is*. That case is now
a regression test.
Every ambiguous case resolves toward KEEPING: no number in the filename falls back
to normalized text, text shorter than 12 chars is never matched, and anything
matching neither is kept. A surviving duplicate is a nuisance someone notices; a
deleted fragment silently costs a contributor their credit.
node --import tsx/esm --test tests/unit/release-cycle-base-resolver.test.ts # 5 pass
node --import tsx/esm --test tests/unit/sweep-stale-fragments.test.ts # 11 pass
node scripts/release/list-uncovered-commits.mjs --json
→ base ed2db6cb19, baseSource "cycle-open", total 22 (was 1361)
node scripts/release/sweep-stale-fragments.mjs
→ 4 fragments, 0 stale, exit 0
* docs(changelog): fragment for #8985
* fix(ci): four quality gates that punished the wrong thing
Gaps 6, 9, 10 and 23 of the v3.8.49 process dossier. Each one either blocked
work it should have waved through, or reported a number that was never the
code's.
## 6 — test-masking is unusable at release scale
My own dossier entry for this was WRONG and the measurement says so:
tracked test files ............ 3977 (I had written 1277)
absolute tautology scan ....... ~1 s (I had written >30 min)
the diff uses base...HEAD three dots — already merge-base
diff vs release branch ........ 0 files, 0 s
diff vs main (today) .......... 3 files, 0 s
The base choice was never the problem, and it cannot be reproduced today at
all: `main` has since received the v3.8.49 squash, so the merge-base is recent.
The pathology only exists DURING a release, in the window before `main` gets the
squash — then the merge-base is the PREVIOUS cycle's fork point and the diff
legitimately spans the whole cycle (~1277 changed test files, each costing a
`git show` process plus a full regex pass). That is the same squash-merge
topology as gap 4, and it is why the check ran twice without finishing.
Fix: above 300 changed test files the per-file diff subchecks are skipped, since
every one of those files was already gated by this check on its own PR. The
absolute tautology scan still runs unconditionally over all 3977 files, so the
floor is untouched. The skip is deliberately loud — a silent skip is gap 12,
which cost two production bugs this cycle. `shouldSkipDiffSubchecks` never skips
on unparseable input, so a broken count cannot disable the gate.
## 9 — a capital letter invalidated 41 translations
`"Reset Defaults"` → `"Reset defaults"` marked the key stale in 41 locales. Every
translation was still correct, and in locales with no letter case the "fix" is
not expressible. Worse, the escape hatch (`__MISSING__:`) is BANNED in `vi` by
tests/unit/i18n-vi-completeness.test.ts, so `vi` had no legitimate way out.
`isCosmeticRewrite` folds case, whitespace runs and trailing punctuation — and
nothing else. Most of the nine tests exist to pin what is NOT cosmetic: a changed
word, an added word, and any edit inside an interpolation like `{count}` all
still flag. Two end-to-end tests hold both directions: a cosmetic edit leaves
every locale alone, a real rewrite still flags all of them.
## 10 — the ratchet compared numbers from two different auditors
`pipx install zizmor` was unpinned, so the runner installed whatever PyPI served
that day and measured 1 finding MORE than the devbox on the identical commit
(190 vs 189) — a second rebaseline push per release, chasing a number that was
never the code's. Pinned to 1.25.2 (what the devbox runs), and
check-workflows.mjs now prints `zizmorVersion=` next to the count so any future
rebaseline is traceable to the tool that produced it.
## 23 — a PR pointed at its own branch
#8912 has head == base == release/v3.8.50: no diff, can never merge, and it sits
in the queue with a full check board on every push to that branch. It survived
because nothing looks wrong — the checks pass, since there is nothing to check.
New guard in the `changes` job (one field comparison, before anything is spent).
The distinction that makes it safe to block on: an equal head/base BRANCH is
conclusive, an equal head/base SHA is NOT — a branch cut moments ago has an
identical tip and is legitimate, so that case warns instead of failing. Half a
signal never fails either.
node --import tsx/esm --test tests/unit/test-masking-release-scale.test.ts # 6 pass
node --import tsx/esm --test tests/unit/ui-value-drift-cosmetic.test.ts # 9 pass
node --import tsx/esm --test tests/unit/pr-self-target-guard.test.ts # 7 pass
check:workflows --ratchet → 178 findings, zizmorVersion=zizmor 1.25.2, baseline 190
the i18n suite is unaffected (5 files re-run, all green)
* fix(ci): allowlist the four CI-only env vars the new gates read
The env-doc-sync gate failed three unit shards plus Docs Gates on this PR, and it
was right to: it requires every `process.env.X` read in code to be documented in
`.env.example`, and this PR introduced four new reads.
They do not belong in `.env.example`. That file is OmniRoute's runtime
configuration; these are CI signals with no meaning in a user's `.env`:
HEAD_REF / HEAD_SHA / BASE_SHA the `changes` job passes github.head_ref,
github.base_ref and the PR head/base SHAs to
the self-targeting-PR guard
TEST_MASKING_MAX_CHANGED_TESTS the escape hatch that raises the test-masking
gate's release-scale skip threshold
So they go in IGNORE_FROM_CODE, which exists for exactly this and already carries
the precedent one line above: `BASE_REF`, allowlisted because CI passes it to the
OpenAPI breaking-change gate. `BASE_REF` being already listed is also why only
four of my five reads failed.
Each entry carries its justification and the script that reads it, per the
allowlist policy.
node --import tsx/esm --test tests/unit/issue-7793-env-doc-sync-repro.test.ts # 1 pass
npm run check:env-doc-sync → all three directions in sync
* fix(i18n): narrow the cosmetic-rewrite exemption to the scope actually reported
The gap-9 fix folded whitespace in addition to case, and that collided with a
pre-existing test which pins the opposite — tests/unit/i18n-ui-value-drift.test.ts,
"a value that only changes whitespace still counts as an edit". Its comment states
the reasoning:
Conservative on purpose: trailing-space churn is rare, and treating it as a
no-op would let a real reword slip through behind an innocuous-looking diff.
That is a documented decision by whoever wrote it. The problem actually reported
was CASE — `"Reset Defaults"` → `"Reset defaults"` invalidating 41 correct
translations — and whitespace was scope I added on my own. Reversing someone
else's reasoned call, silently, to fix something nobody reported is not this
change's job, so the exemption is narrowed to case + trailing terminal
punctuation. No test pins either of those.
The reported case is still fixed, verified end to end: that rewrite invalidates 0
locales. And whitespace is now asserted NON-cosmetic in my own test file too, so a
later tidy-up cannot quietly fold it back in.
node --import tsx/esm --test tests/unit/i18n-ui-value-drift.test.ts # 11 pass (pre-existing)
node --import tsx/esm --test tests/unit/ui-value-drift-cosmetic.test.ts # 10 pass
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* feat(ci): gate the publish on clean-install AND upgrade-over-previous
`check:pack-boot` proves a fresh install boots. It does not prove the path that actually
broke us: installing over an existing version, where ~110 SQLite migrations run against a
populated database. v3.8.48 shipped as a hotfix because the published 3.8.47 crashed on
boot, and the v3.8.49 upgrade path was only ever exercised end-to-end by hand — on VPS .16,
against a real 3.8.48 install with a 165 MB database, AFTER publishing. That is backwards.
New gate (`scripts/check/check-install-upgrade.mjs`), wired into npm-publish.yml as step 12,
BEFORE `npm stage publish` — so a broken upgrade never reaches the registry and a staged
package that is never approved simply expires, with no `npm deprecate` needed:
- Phase A: fresh prefix + fresh DATA_DIR, install the packed tarball, boot, health.
- Phase B: fresh prefix + fresh DATA_DIR, install the PREVIOUS published version, boot it
(creates + migrates the DB), stop, install the tarball over the SAME prefix, boot against
the SAME DATA_DIR. Asserts no table present before the upgrade was dropped.
- Schema convergence, and its DIRECTION is the whole point:
fresh − upgraded ≠ ∅ → FAIL. Structure a clean install creates but an upgrade does not
means every existing user is missing it. Not allowlistable.
upgraded − fresh ≠ ∅ → residue; fails only when NEW (allowlist carries the known ones).
A naive symmetric check would either block every release on harmless residue or, if relaxed,
let the dangerous direction through. Measured on VPS .16 (2026-07-30): a real 3.8.48 install
upgraded to 3.8.49 ended with 117 tables against 116 for a clean 3.8.49 install — the extra
being `cache_metrics`, recorded in config/quality/install-upgrade-allowlist.json with the
measurement. Both installs healthy, zero `no such table` in 150 log lines.
`evaluateConvergence` is exported and pure so the asymmetry is testable without packing,
installing or booting anything (same reason check-test-masking exports its helpers):
tests/unit/check-install-upgrade-convergence.test.ts, 8 cases, ~6ms.
A previous version that fails to boot degrades to a warning — a historically bad publish
must not block the current one. Uses node:sqlite (Node 24, already the publish job's
runtime): no new dependency.
* fix(ci): require the reused next-build artifact to come from this repository
CodeQL raised actions/artifact-poisoning/critical on the `next-build` fast path
this PR builds on (#8941). The finding is real and it sits on the path that
produces the published npm tarball.
The step picks a CI run by querying the runs API for `head_sha` and filtering on
`name == "CI" and conclusion == "success"`. That query also returns
`pull_request` runs from FORKS: they execute in this repository's context and
upload their own `next-build`, built from fork-controlled source. Measured
today, 57 runs in this repo have a `head_repository` other than the repo itself.
So the selection trusted bytes by coincidence of commit SHA — anything that made
a fork's head commit coincide with the publish commit could put attacker-built
bytes on npm.
Adds `and .head_repository.full_name == env.REPO` to the selection. Provenance
is now explicit; `head_sha` still carries tree-equality. Verified against the
live API using the expression extracted from the workflow itself — the same
single run (30518663668) is selected either way for the current tip, so the fast
path keeps working while every fork run is excluded.
Not a dismissal (hard rule #14) — the clause removes the flagged trust.
node --import tsx/esm --test tests/unit/npm-publish-artifact-provenance.test.ts
# 3 pass, 0 fail (base: 2 pass, 1 fail)
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
v3.8.49 shipped with ZERO release assets. v3.8.48 had 16. Every gate was green.
Measured from run 30503231362, not inferred:
Build Electron (windows) ....... success
Build Electron (macos-intel) ... success
Build Electron (macos-arm64) ... success
Build Electron (linux) ......... failure
Create Release ................. skipped
Publish to npm ................. skipped
The linux leg died 8 min into "Creating an optimized production build" with
"The runner has received a shutdown signal" and no exit code, on runner
`GitHub Actions 1000378558` — github-hosted, so this was the VM being
reclaimed, not a Node heap error. Reproduced on a 32 GB machine from the exact
tag commit: the same build succeeds and peaks past 18 GB.
Three independent defects compounded, one fix each:
1. Turbopack allocates natively (Rust, off the V8 heap), so the existing
--max_old_space_size=6144 does not bound it. The project already documents
the webpack fallback as the escape hatch for RAM-constrained machines
(docs/reference/ENVIRONMENT.md, #6409), and nightly-compat already applies
it for the same reason on Node 26 (#8090). The linux leg now selects it;
Windows/macOS keep Turbopack since they build fine and it is faster.
2. `release` gated on `needs: [validate, build]` with no `if:`, so ONE failing
leg skipped it and discarded the three artifacts that DID build — 1.7 GB,
still retained — plus the source archives, which depend on no build at all.
Fail-closed made a partial failure look total. It is now fail-partial:
attach what exists, still requiring `validate` to have passed.
3. Nothing asserted the release HAS assets, so 16 binaries and 0 binaries were
indistinguishable to CI. New `verify-desktop-assets` job asserts one asset
per platform and fails loudly.
The check is a separate job on purpose: failing inside `release` would cascade
into `publish-npm` (`needs: [validate, release]`) and block the npm channel
over a desktop-only gap. Now the assets attach, npm still publishes, and an
incomplete desktop channel is a red job instead of silence.
TDD: 3 of the 4 new assertions fail on the tip of release/v3.8.50 and pass
with this change. The 4th asserts a negative (publish-npm must not gain a
dependency on the asset check) and guards against future regression rather
than reproducing the bug.
node --import tsx/esm --test tests/unit/electron-release-desktop-channel-8949.test.ts
# 4 pass, 0 fail (base: 1 pass, 3 fail)
check:workflows --ratchet → 189 findings, baseline 190, no regression
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
* chore(ci): remove two fork-owned publish workflows that rode in by accident
Both files publish to a DIFFERENT owner's GHCR namespace, and both arrived as an
unrelated extra file inside an otherwise on-topic PR:
build-fork.yml added by #1528 (scope: SSE translator, Qiwen Chen)
env IMAGE_NAME: ghcr.io/kang-heewon/omniroute
if: github.repository == 'kang-heewon/OmniRoute'
100+ runs instantiated here
build-rinseaid-image.yml added by #8729 (scope: SSE reasoning)
tags: ghcr.io/rinseaid/omniroute:...
no repository guard at all — 0 runs
Neither can ever succeed: this repository's GITHUB_TOKEN cannot write to another
owner's namespace. The cost is not a breach, it is noise. build-fork.yml's guard
sits on the JOB, not the workflow, so GitHub instantiates a run on every push to
main and every v* tag and then skips the job — which is why every release check
board has carried a permanently skipped "Publish Fork Image to GHCR" entry.
build-rinseaid-image.yml never fires because its trigger branch
(`build-k3-reasoning-image`) does not exist in this repo.
Only build-fork.yml was pre-approved (2026-07-30). The second was found while
executing: grepping the workflow directory for registry namespaces turned up
ghcr.io/rinseaid alongside ghcr.io/kang-heewon. Same defect, same remedy, so both
go — easy to split if that is preferred.
Nothing else is touched. Specifically NOT touched: the 14 `kang-heewon` credit
links in CHANGELOG.md (real contributions), their 42 i18n mirrors, and the
historical `- **ci:** update build-fork workflow…` entry from #2055. Measured: 0
of the 14 credit mentions concern build-fork, so no credit line is involved
either way. `git status` shows exactly two deletions and one new test.
TDD — the guard names both offenders before the removal and passes after:
node --import tsx/esm --test tests/unit/workflows-no-foreign-fork-publishers.test.ts
# before: 0 pass, 2 fail → build-fork.yml → ghcr.io/kang-heewon
# build-rinseaid-image.yml → ghcr.io/rinseaid
# after: 2 pass, 0 fail
Zizmor findings drop 190 → 178 (both files use unpinned docker/* and checkout
actions). The baseline is deliberately NOT rebaselined here: the metric direction
is `down` so a drop cannot break the ratchet, tightening it to exactly 178 would
leave zero headroom and self-break on drift, and validate-release-green states
the convention outright — "Any drift above is rebaselined at release, not a
contributor concern."
* docs(changelog): fragment for #8967
---------
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
The v3.8.49 publish failed: `Build CLI bundle` runs `npm run build:cli`, which shells
out to a full `next build` when `.build/next/standalone/server.js` is missing. That
build's working set outgrew the 16 GB GitHub-hosted runner during this cycle, so the
job died at 6m20s with
Creating an optimized production build ...
##[error]The runner has received a shutdown signal.
and every step after it — artifact validation, SBOM, tarball boot-smoke, the staged
publish — was skipped. The same job had passed in 16 minutes for v3.8.48, so this is
the build growing past the runner, not the runner degrading. ci.yml already routes its
heavy jobs around this via the USE_VPS_RUNNER expression; npm-publish.yml had
`runs-on: ubuntu-latest` hardcoded and no way out.
Two changes, one for the fast path and one for the fallback:
- `runs-on` now uses the SAME expression as ci.yml's build/test-unit, so the operator
can send the publish to the 32-core self-hosted runner. Kept verbatim (including the
fork-safety clause that is always true here, since this workflow never runs on
pull_request) so the expression stays greppable across workflows.
- A best-effort step restores the `next-build` artifact that CI already produced for
the SAME commit, matching on `head_sha` — same commit, same tree, so no equality gate
is needed beyond the match itself. `build:cli` then finds the standalone tree and
skips the build entirely, turning the heaviest step into a download. Retention is one
day, so every miss (no successful CI run, expired artifact, bad extract) logs a notice
and falls through to the build — which is exactly why the dynamic runner above is the
necessary backstop rather than a nice-to-have.
Needs `actions: read` to look up the run and download the artifact. All inputs reach the
script through `env:`, never interpolated into the shell body. No new zizmor findings:
the step uses the `gh` CLI rather than a new `uses:`, so the unpinned-uses count is
unchanged (189 measured locally == the devbox side of the 190 baseline).
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
