As built at T1.12, each claim with its mechanism: 22 cases in `contract/cases/s0/` beside T1.10's two (three added in fix round 1), all on the shop base, which `case.schema.json` validates through both loaders (`tests/test_contract_cases.py`, `sdm-testkit`'s `tests/s0_cases.rs`). Accepted: binary and multiclass classification (regression is `s0.accept.sum-window`). Refused, each at `materialize` with `INVALID_REQUEST`, one per validator family (parse, target, task, time, type, join, model, value; schema is `s0.refuse.unknown-column`) and a date that does not exist (D9); the PQL code each reaches was checked on the reference's `predictive_query.validate` and the core's `validate_query` alike when the case was written, and is named in its `why`, since an observation records the public code only. Boundaries: integer literals of 4,300 digits (accepted) and 4,301 (refused), all but one leading zeros; escapes read (`\u00e9`, `\t`, `\'`, `\\` and `\/`) and a truncated `\u` refused; an escaped surrogate pair and a lone one, diagnostic under register PQL-1 (proposed), which the reference's old materializer refuses and the core accepts, joining the pair and reading a lone one as U+FFFD; D8's packed date and DT-9's long field, diagnostic, naming register DT-9, the core answering `UNSUPPORTED_REQUEST` until T1.6b; 400 nested parentheses; 999, diagnostic under register PQL-2 (proposed); a query of 72,082 bytes; `test_the_s0_boundary_cases_sit_on_their_boundaries` holds each to that shape, the DT-9 cases to diagnostic and every other diagnostic case to a proposed entry, and `sdm-testkit`'s `tests/s0_cases.rs` holds each diagnostic case to the core answer its entry records (`UNSUPPORTED_REQUEST` for DT-9, acceptance for PQL-1 and PQL-2). Every runner's outcome is its case's expectation and the reference's, and python-core's and rust-host's answers agree (`compare.py` in CI's `rust-test` and `engine` jobs); the five diagnostic cases differ only as diagnostic notes. Their `python-ref` observations are committed in `contract/reference/b413e9a….jsonl`, because `compare.py` fails an acceptance case without one, recorded under T1.13's rules, the four earlier lines kept byte for byte. Not covered, since the public call cannot reach them as one validation: profiles other than RELATIONAL and the capability refusals (an in-place schema is always relational, `query.py`'s `materialize`; the other profiles are refused before validation; L1's corpus and `pql_adapter.rs` cover them); an accepted ranking (on the shop base none validates: `LIST_DISTINCT` of `orders.order_id` is refused as a primary key and of `orders.user_id` as a loop back to the entity table; over a further table the public call then asks for `candidates=`, which the case format does not carry) and an accepted forecast (it validates once per timeframe as well as whole, four `validate_query` starts against the case's one). The deepest valid query is 400, not the core's 999: the reference has no limit of its own and raises `RecursionError` past about 461 levels in the runner (on Python 3.12, as T1.12's last review measured it; "about 455" until T1.12b), where the core answers to 999 and refuses 1,000 (register PQL-2, proposed, recommending the core's bounded behavior)
0 commit comments