M09 follow-up: administrative recording of compatibility-matrix evidence cells

kilo commented

2026-09-21 01:28:31 +00:00

Member

Goal

Allow an administrator to record OpenAI compatibility-matrix evidence cells (D-043) for configured backends through the M09 control surface, so that composed deployments can stream instead of failing closed.

Discovered by

M10 (#95) end-to-end acceptance: tests/test_scenario_06_streaming_fails_closed_without_matrix_evidence pins the current honest behavior — a worker_bridged/composed resource whose backend has no recorded matrix cells rejects streaming with compatibility_unknown (HTTP 400, provider never contacted). Fail-closed is correct per D-043 (UNKNOWN must fail closed); the gap is that no administrative path exists to record the cells that would unlock it.

Current state

M04 presets carry code-level default cells (scarcity_router/providers/openai_http_evidence.py); the generic preset records all-UNKNOWN with the note "the administrator must supply dated evidence cells (M09) before these gates pass".
M09 (#94) implemented resource/provider/worker configuration but no evidence-cell recording surface.

Acceptance criteria

Administrators can record per-(adapter, adapter version, model/backend) cells with value PASS/PARTIAL/UNSUPPORTED/UNKNOWN, dated evidence and tested version, through the control API/UI.
Cells feed the existing routing-core compatibility gates unchanged (no second validation path).
Recorded cells are visible in diagnostics/export; secret-free.
M10 acceptance docs updated once the gap closes.

References

D-043 (compatibility matrix contract), docs/execution-surface.md, docs/m10-acceptance.md (the recorded follow-up note).

## Goal Allow an administrator to record OpenAI compatibility-matrix evidence cells (D-043) for configured backends through the M09 control surface, so that composed deployments can stream instead of failing closed. ## Discovered by M10 (#95) end-to-end acceptance: `tests/test_scenario_06_streaming_fails_closed_without_matrix_evidence` pins the current honest behavior — a `worker_bridged`/composed resource whose backend has no recorded matrix cells rejects streaming with `compatibility_unknown` (HTTP 400, provider never contacted). Fail-closed is correct per D-043 (`UNKNOWN` must fail closed); the gap is that no administrative path exists to record the cells that would unlock it. ## Current state - M04 presets carry code-level default cells (`scarcity_router/providers/openai_http_evidence.py`); the `generic` preset records all-`UNKNOWN` with the note "the administrator must supply dated evidence cells (M09) before these gates pass". - M09 (#94) implemented resource/provider/worker configuration but no evidence-cell recording surface. ## Acceptance criteria - [ ] Administrators can record per-(adapter, adapter version, model/backend) cells with value `PASS`/`PARTIAL`/`UNSUPPORTED`/`UNKNOWN`, dated evidence and tested version, through the control API/UI. - [ ] Cells feed the existing routing-core compatibility gates unchanged (no second validation path). - [ ] Recorded cells are visible in diagnostics/export; secret-free. - [ ] M10 acceptance docs updated once the gap closes. ## References - D-043 (compatibility matrix contract), docs/execution-surface.md, `docs/m10-acceptance.md` (the recorded follow-up note).

adrian.tkacz referenced this issue from a commit

2026-09-21 05:34:59 +00:00

test(m10): add the M10-B Codex end-to-end acceptance suites (issue #95)

kilo referenced this issue

2026-09-21 05:35:42 +00:00

Program integration: M06 Codex execution adapter (#91) + M10 distribution and acceptance (#95) #108

kilo commented

2026-09-21 12:29:16 +00:00

Author

Member

Reconciling this issue with the actual fix (PR #108, commit 9462c30 on program/m06-m10-final-wave).

Delivered:

The actual composed M09 server now builds its production compatibility matrix from administrator configuration plus the built-in evidence modules: M04 default_cells_for(...) per configured server-direct preset resource (reusing the existing evidence tables; generic/un-evidenced presets remain all-UNKNOWN), and a new codex_worker_evidence module carrying the reviewed M06 Stage-2 cell values (conservative PARTIAL/UNSUPPORTED, dated provenance, codex-cli 0.154.0-alpha.6.2 / schemas rust-v0.155.1) for each configured Codex worker resource, keyed to its physical model.
control_api._rebuild_application passes the built cells into the real GatewayApplication, rebuilt on every configuration change — the same lifecycle as adapter composition. compatibility_cells=() no longer occurs on any configured production path (the empty tuple remains only for the honest zero-configuration deployment).
A streaming Codex request through the actual composed server now succeeds on built-in evidence with no synthetic cell injection in the E2E (the programmatic injection seams were deleted); client-tools requests are rejected from the real UNSUPPORTED cell before dispatch; UNKNOWN features remain fail-closed; configuration changes rebuild/remove cells correctly; no cross-resource cell leakage.

Authority model (preserved): built-in adapter evidence is the default ceiling; nothing in configuration can elevate above it, and no unevidenced "full compatibility" toggle exists. Administrator-supplied dated-evidence elevation above built-in evidence remains a possible future enhancement (not needed for any currently evidenced adapter) — recorded here so the closure is honest about that boundary.

Both closure conditions are met: the composed server receives the evidence-backed matrix, and the E2E no longer injects synthetic cells. Discrimination re-proved against pre-fix HEAD d5cdc17 by the adversarial review.

Reconciling this issue with the actual fix (PR #108, commit `9462c30` on `program/m06-m10-final-wave`). **Delivered:** - The actual composed M09 server now builds its production compatibility matrix from administrator configuration plus the built-in evidence modules: M04 `default_cells_for(...)` per configured server-direct preset resource (reusing the existing evidence tables; generic/un-evidenced presets remain all-`UNKNOWN`), and a new `codex_worker_evidence` module carrying the reviewed M06 Stage-2 cell values (conservative `PARTIAL`/`UNSUPPORTED`, dated provenance, `codex-cli 0.154.0-alpha.6.2` / schemas `rust-v0.155.1`) for each configured Codex worker resource, keyed to its physical model. - `control_api._rebuild_application` passes the built cells into the real `GatewayApplication`, rebuilt on every configuration change — the same lifecycle as adapter composition. `compatibility_cells=()` no longer occurs on any configured production path (the empty tuple remains only for the honest zero-configuration deployment). - A streaming Codex request through the **actual composed server** now succeeds on built-in evidence with **no synthetic cell injection in the E2E** (the programmatic injection seams were deleted); client-tools requests are rejected from the real `UNSUPPORTED` cell before dispatch; `UNKNOWN` features remain fail-closed; configuration changes rebuild/remove cells correctly; no cross-resource cell leakage. **Authority model (preserved):** built-in adapter evidence is the default ceiling; nothing in configuration can elevate above it, and no unevidenced "full compatibility" toggle exists. Administrator-supplied dated-evidence **elevation above built-in evidence** remains a possible future enhancement (not needed for any currently evidenced adapter) — recorded here so the closure is honest about that boundary. Both closure conditions are met: the composed server receives the evidence-backed matrix, and the E2E no longer injects synthetic cells. Discrimination re-proved against pre-fix HEAD `d5cdc17` by the adversarial review.

kilo closed this issue

2026-09-21 12:29:26 +00:00

adrian.tkacz referenced this issue from a commit

2026-09-21 12:29:30 +00:00

fix(program): compose the production compatibility matrix from configuration

adrian.tkacz referenced this issue from a commit

2026-09-21 12:29:30 +00:00

docs(program): record the Codex physical-model binding and composed-matrix wiring

kilo referenced this issue

2026-09-21 12:29:54 +00:00

Program integration: M06 Codex execution adapter (#91) + M10 distribution and acceptance (#95) #108

kilo referenced this issue