OMARS generator: n_runs means the returned run count, and selection criteria search the design class (#496-#499)

[kgdunn]

Summary

The OMARS generator cluster from the 2026-08-14 audit batch. Version bumped to 1.72.0 (MINOR: the n_runs semantics change plus the exact-search behaviour).

• Fixes generate_omars(n_runs=n, center_runs=c) returns n + c - 1 runs, not n #496: n_runs is now the total run count of the returned design, centre runs included: generate_omars(n_runs=17, center_runs=3) returns 17 rows, 3 of them centre runs. n_runs - center_runs must be a positive even number, and all reported metrics are computed on the full returned design.
• Fixes selection_criterion="a_optimal" does not find the A-optimal design (up to 40% above optimum) #497, fixes selection_criterion="d_efficiency" does not find the D-optimal design (up to 5.5%); dominance shares it #498, fixes selection_criterion="min_second_order_correlation" misses the optimum by up to 51% at larger sizes #499: the root cause of all three optimality gaps was representational, not just weak search: the exhaustive optima require designs that repeat a half-run, and the binary ILP multistart cannot represent repetition at all (the library's reported values in the issue tables match the binary-class optima exactly). The search now enumerates every feasible half-design multiset (counts per sign class, replication allowed) up to four factors at moderate sizes (_ENUM_MAX_HALF = {3: 18, 4: 12}), scores count vectors in vectorised batches (eigvalsh on the count-weighted Gram, no design materialisation), and selects exactly. Beyond the caps the multistart remains, and both the docstring and metadata["search_mode"] say which regime produced the design.
• Per selection_criterion="min_second_order_correlation" misses the optimum by up to 51% at larger sizes #499's convention: a design containing a constant (non-estimable) second-order column scores inf on the selection correlation metric instead of having the column skipped. The descriptive statistic in omars_properties is unchanged.

Every cell of all three issue tables was verified to reproduce the exhaustive optimum exactly (A: 13 cells, D: 14 cells, max|r|: 14 cells), including the former worst cases (A gap 39.7% at k=3 N=21; max|r| gap 51.2% at k=4 N=25). Wall-clock for the largest cell (k=4, N=25, h=12: 2.42M feasible designs) is about 90 s; the k=3 cells and k=4 up to N=17 are sub-5 s.

Test plan

• New tests/test_omars_ilp_optima.py pins the tractable issue-table cells to their exhaustive optima (k=4 N=19/21 marked slow); the N=23/25 cells were verified in-session and left out of CI for runtime
• New parity/sizing tests: returned row count equals n_runs for several (n_runs, center_runs) combinations, including an even total
• uv run pytest tests/test_omars_ilp.py tests/test_omars_ilp_optima.py --no-cov: 63 passed
• uv run pytest tests/test_omars*.py tests/test_experiments_omars.py tests/test_design_generation.py tests/test_audit_regressions_experiments.py --no-cov: 361 passed, 1 skipped (pre-existing skip)
• ruff check ., ruff format --check . clean; mypy src/process_improve shows only the pre-existing mcp_server.py FastMCP attr error unrelated to this diff

Checklist

• Version bumped in pyproject.toml (PATCH for fixes/docs/config, MINOR for new features)
• Tests added or updated where relevant
• ruff check . passes
• CHANGELOG.md updated

[codecov]

Codecov Report

❌ Patch coverage is 89.85507% with 21 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...c/process_improve/experiments/designs_omars_ilp.py	89.85%	12 Missing and 9 partials ⚠️

📢 Thoughts on this report? Let us know!

[kgdunn]

The typecheck failure here is not this PR's: it is red on main's own latest runs. The unpinned mcp extra now resolves to mcp 2.x, where FastMCP was renamed MCPServer, so mypy fails on src/process_improve/mcp_server.py everywhere. The fix is PR #528; its migrated mcp_server.py and mcp>=2.0 floor are ported verbatim into this branch so CI can go green in any merge order. The ported files disappear from this diff once #528 merges.

---

Generated by Claude Code