mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-01 20:32:13 +03:00
0ce21232db
* fix(db): converge the install and upgrade schemas; stop ENOSPC from faking a divergence The v3.8.50 publish run failed `check:install-upgrade` with "15 tables a CLEAN install creates but an UPGRADE does not" (agentic_conversations, ccr_blocks, the whole Radar set, jobs/job_runs, exclusive_connection_leases, …). None of them was missing. Root cause, from the CI log (run 33104507735): the Phase B upgrade `npm install` hit `npm warn tar TAR_ENTRY_ERROR ENOSPC: no space left on device` 5611 times, npm still exited 0, and the resulting truncated package made `omniroute serve` "exit with code 0 before serving". No migration ever ran, so the database still held the 3.8.49 schema (115 tables) and every post-133 migration table read as a divergence. Verified against the real thing: booting the published omniroute@3.8.49 and replaying that database through the current runner applies exactly 29 migrations and lands on the same table set a clean install produces — the migration set was never at fault. What changes: - `163_model_capabilities.sql` — the one genuine convergence defect. The table was only ever created by `ensureCapabilitiesTable()` on the first models.dev sync, so whether a database has it depends on timing, not on the schema version. It is the residual the gate reported. A migration makes both install paths deterministic. - `check:install-upgrade` now fails on an ENOSPC-truncated install instead of measuring a broken tree; authenticates its health probe with a minted internal-service token, so the version assertion works against the health payload hardened by GHSA-mvf8-qc78-5mxm (an anonymous caller gets no version — the same run also failed with "health reports version undefined"); frees the ~3 GB clean-install tree before the upgrade phase; warns when the temp filesystem cannot hold the run; prints the failing server's output; and skips the convergence verdict when a phase never served, so a broken boot can no longer manufacture a schema divergence on top of the real failure. Tests: `tests/unit/db-install-upgrade-schema-parity.test.ts` pins the deterministic half of the gate in milliseconds (every migration reachable on a clean install; model_capabilities comes from the migration set; its DDL does not drift from the runtime helper), and the ENOSPC guard is covered in the existing gate test. * docs(db): record the real cause of the cache_metrics residual in the allowlist The allowlist described every residual as "a CREATE that left the migration set in some past cycle". cache_metrics never was in the migration set: it is created lazily by ensureCacheMetricsTable() (src/lib/semanticCache.ts:34) the first time the semantic cache runs, which is the same class as the model_capabilities divergence that blocked the v3.8.50 publish. Document both causes so the next residual is fixed with a migration where that is the right answer, instead of reflexively allowlisted. * docs: bump the migration count to 160 after 163_model_capabilities check:docs-counts-sync enforces the shipped migration count as a STRICT claim in README.md, AGENTS.md and llm.txt. * docs(i18n): re-sync the 42 llm.txt mirrors after the migration-count bump