mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-26 00:52:18 +03:00
5eccbfac19
All four predate this session — each reproduces identically on f95b03d70 (2026-08-24),
so none is a cycle regression. Draining them here because the release pre-flight is
where inherited reds get resolved.
1. Package Artifact: the job runs `build:cli`, which assembles dist/ but never writes
dist/BUILD_SHA — only `build:release` does, via write-build-sha.mjs. The #10427
provenance guard inside check:pack-artifact then rejects the artifact as
untraceable, and rejects it even under OMNIROUTE_ALLOW_CANARY_BUILD. The job's
build+validate pair was structurally incompatible and failed 100% of the time.
Stamps the SHA between the two steps.
2. Electron Package Smoke: electron/package.json's build.files allowlist enumerates
each lib/*.js by hand and never got lib/loginHeaderCapture.js, added alongside its
require() in #9984. The file therefore stayed out of app.asar and the packaged app
died at startup on 'Cannot find module ./lib/loginHeaderCapture'.
3. proxy-pipeline: the breaker assertion grepped chat.ts for executeChatWithBreaker(,
but that call moved behind the chatDispatch.ts seam. Rather than drop the check,
it now pins both hops — chat.ts dispatches through the seam and the seam calls the
breaker — so the extraction cannot silently take the breaker off the path.
4. skills-pipeline: #9058 began encoding skill tool names as omr_skill_<base64url>
because providers require ^[a-zA-Z0-9_-]+$, and these assertions still expected the
raw name@version. They now derive the expected name from encodeSkillToolName(), the
same helper production uses, so the test tracks the contract instead of duplicating
it. Only the assertions about names on the wire were converted; the identifiers
passed straight to skillExecutor.execute() stay raw, because those are not encoded.
Integration suite for these two files: 54/55. The one still red —
'web_search fallback preserves Responses API output' — is a separate pre-existing
defect, deliberately left failing rather than papered over: on the /v1/responses path
resolveSearchCredentials() returns null for the seeded serper-search connection, so
executeWebSearch.ts:185-200 falls through to the cheapest fallbackOnly provider
(duckduckgo-free) and the results come back empty. The sibling chat-path test seeds
identically and does resolve serper-search. Needs its own investigation.
Refs #10692