[maxmad64bis]

Summary

• Creating a routing combo without any model is now refused at the boundary: createComboSchema requires a non-empty models list, so POST /api/combos returns 400 for a missing or empty list.
• omniroute combo create requires --models <provider/model,...> and/or repeated --model, instead of silently writing models: [].
• docs/openapi.yaml: ComboCreate aligned with the actual request contract (required: [name, models], union string | structured entry, phantom properties model/nodes removed).

Related Issues

• Closes fix(cli): combo create cannot accept models and always creates an empty combo #10954
• Related to fix(cli): combo create cannot accept models — add --models option (#10954) #11011, fix(backend): fail closed when capability filters empty the combo pool #8494, fix(providers): fail fast on empty auto-combo pool instead of 15s timeout (#6458) #6546

Validation

• Change type: routing / CLI
• Focused tests: node --import tsx/esm --test tests/unit/combo-empty-models.test.ts tests/unit/combo-context-length.test.ts tests/unit/combo-bracket-names.test.ts tests/unit/cli-combo-create-models-10954.test.ts (and the full tests/unit/combo-* / combos-* set) — all green
• npm run lint — no new findings from this PR's files (pre-existing failures elsewhere are unchanged; see Reviewer Notes)
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include updated automated tests in this PR

Manual loop on a live server: POST /api/combos without models → 400; with one model → 201; combo create without --models → stderr message naming the flags, exit code 1.

Tests Added Or Updated

• tests/unit/combo-empty-models.test.ts — invariant inverted: creating without a model is refused at the boundary (was: asserted allowed).
• tests/unit/cli-combo-create-models-10954.test.ts — new regression: the guard fires before reaching either transport (HTTP body or local-db fallback).
• tests/unit/combo-context-length.test.ts, tests/unit/combo-bracket-names.test.ts — fixtures updated for the now-required models (8 call sites total).

Coverage Notes

Production change is confined to src/shared/validation/schemas/combo.ts (one line + comment) and bin/cli/commands/combo.mjs (guard). Covered by tests/unit/combo-empty-models.test.ts and tests/unit/cli-combo-create-models-10954.test.ts respectively. No coverage moved down in touched files.

Reviewer Notes

• Consistency, not new policy: the dashboard already rejected empty combos client-side ("Add at least one model."), /api/combos/duplicate already returns 400 for an empty list (fix(cli): combo create cannot accept models — add --models option (#10954) #11011 made populated creation the normal CLI path), six downstream consumers reject the empty object, and fail-closed is the established behavior for empty pools (fix(backend): fail closed when capability filters empty the combo pool #8494, fix(providers): fail fast on empty auto-combo pool instead of 15s timeout (#6458) #6546). Since fix(cli): combo create cannot accept models and always creates an empty combo #10954 framed always-empty creation as a bug and fix(cli): combo create cannot accept models — add --models option (#10954) #11011 removed the last legitimate use of an empty draft, this closes the remaining hole. Intended consequence: a legacy combo stored empty in the database can no longer be duplicated from the dashboard (duplicate re-posts through POST /api/combos) — consistent with the duplicate route already refusing empties.
• OpenAPI breaking-change gate: rebaseline entry _rebaseline_2026_08_22_combo_create_min1 documents 3 own findings (removed model, removed nodes, added required models on POST /api/combos — spec-vs-server drift, not client-facing breakage) + 1 inherited finding (PATCH /api/combos/{id} request-body-added-required), which is pre-existing drift already present at this PR's base commit — that route declares its own inline requestBody schema and does not reference ComboCreate. A dedicated tracking issue can be filed if preferred; happy to reference it here.
• Pre-existing CI failures (reproduced identically at the base commit, untouched by this PR): one quota-classifier unit test, lint failures tracked by test(db): assert resetDbInstance swaps the singleton, WAL mode, and schema_version seed #10906, dashboard typecheck errors TS2554 ×188.