Files
OmniRoute/docs
Diego Rodrigues de Sa e Souza 0ce21232db fix(db): converge the install and upgrade schemas; stop ENOSPC from faking a divergence (#11845)
* 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
2026-08-27 19:38:01 -03:00
..
2026-08-26 14:25:01 -03:00
2026-08-26 14:25:01 -03:00
2026-08-26 14:25:01 -03:00
2026-08-26 14:25:01 -03:00
2026-08-26 14:25:01 -03:00
2026-08-26 14:25:01 -03:00
2026-08-26 14:25:01 -03:00
2026-08-26 14:25:01 -03:00
2026-08-26 14:25:01 -03:00
2026-06-29 08:40:06 -03:00
2026-08-26 14:25:01 -03:00

title, version, lastUpdated
title version lastUpdated
OmniRoute Documentation 3.8.40 2026-06-28

OmniRoute Documentation

Navigable index of the OmniRoute documentation set. Topics are grouped by intent so you can find what you need quickly.

Looking for the project overview, install steps, or release notes? See the root README.md, ROADMAP.md, CHANGELOG.md, and CONTRIBUTING.md.


For Non-Tech Users

Simple guides for using OmniRoute — no technical background needed.

getting-started/

guides/


For Tech Users

Technical documentation for developers and contributors.

architecture/

How the system is put together — read these to understand the runtime, code layout, and resilience model.

reference/

Lookup material — API surface, environment variables, CLI flags, provider catalog.

frameworks/

Pluggable subsystems exposed to clients, agents, and operators.

routing/

Combo routing, scoring, and replay.

security/

Guardrails, compliance, stealth, and the mandatory patterns for handling public credentials and error messages.

compression/

Prompt compression engines, rules, and language packs.

providers/

Provider-specific integration guides.

comparison/

ops/

Release, deployment, proxies, tunnels, coverage, database, monitoring.

diagrams/

Mermaid sources and exported SVG/PNG diagrams referenced from the docs above. See diagrams/README.md.

i18n/

Translated mirrors of the documentation in 43 locales. See i18n/README.md for the supported language list.

screenshots/

Static screenshots used by the dashboard and the README. Not part of the doc body.


Auto-generated artifacts

  • reference/PROVIDER_REFERENCE.md is generated by scripts/docs/gen-provider-reference.ts from src/shared/constants/providers.ts. Do not edit by hand.
  • The /docs UI is backed by Fumadocs MDX source generation from the subfolders above.