@@ -453,7 +453,7 @@ Each readiness item (sections 1.1 to 1.14 of the planning input `A-readiness-aud
 | T1.11e | 1b | Comparator payload and result rules | The comparator's payload and result rules | `base.regression`'s observations compare field by field on all runners, its differences diagnostic until T1.29; on `python-core`, capture on and off give the same public projection; the measured statement counts confirm H9's rule; the owner check-in report is sent. As built at T1.11e, each claim with the mechanism that holds it (E48): (1) field by field on all runners: `compare.py` compares `python-ref`, `python-core`, `python-old` and `rust-host` under `contract/compare-policy.yaml`'s rules ("Observations and comparator"); for `base.regression`, diagnostic, every difference is reported and none gates but `reach`, which CI gates on `rust-host` in `rust-test` and on `python-core` and `python-old` in `engine` (`contract/tests`); run locally over all four, it reports only the raw text of the three key-set reads and the key sets bound, which H9 leaves diagnostic. (2) Capture on and off on `python-core`: `contract/tests/test_payload_and_result_rules.py` runs the case both ways and `capture_check.check` finds the same public projection, 16 statements and 3 bindings, DuckDB's query log the same. (3) H9 measured: 10, 6 and 0 statements in `Schema.from_source`, `materialize` and `predict` on all four runners, every statement's result the reference's (columns, types, Arrow schema where both read Arrow, rows in canonical form, in order for `_by_fkey`), gated in CI by `test_h9_holds_on_base_regression_on_the_python_runners` (`python-core`, `python-old`) and `sdm-testkit`'s `base_regression_s_statements_return_the_reference_s_results` (`rust-host`); so H9's rule holds as the owner wrote it and nothing goes to the owner as a design stop. (4) The owner check-in report is the orchestrator's. Each rule fails a seeded fault of its own and a diagnostic one only reports (`test_payload_and_result_rules.py`). `base.regression`'s reference observation, and the S0 cases', recorded again with the capture's values | `base.regression`, diagnostic; `reach` on `base.regression`; the comparator's rules and the policy's checks |
 | T1.11f | 1b | Checkpoint 3 corrections | The corrections of the checkpoint 3 review of 911e892..2e47233: `land.py` computing the checkpoint; the "Host-held semantics" ledger and its bridge headers; T1.23, T1.24, T1.26, T1.28 and T1.29's exits amended; T1.21b; E49; the crate graph as Cargo has it; E35's approval cited; task rows trimmed to their design, exits and as-built mechanisms, the fix-round histories moved to the tracker; cuts proposed to the owner in the tracker, not enacted. No product semantics move and the contract is unchanged | `land_selftest.py` shows `land.py` writing the computed merge base and refusing a `--checkpoint` that differs; the ledger lists every rule a core route holds outside the core, each with its file and line and an owning task or a reason it stays host; each Python file keeping one carries its F7 header, its presence and deletion phase checked by `l0_deps.py` and its owners by review; the amended rows carry their exits; T1.21b exists; E49 is recorded; the drawn graph equals `cargo metadata`'s normal edges; CI is green. As built at T1.11f, each claim with its mechanism: `land.py` always computes `git merge-base CANDIDATE BASE` against the phase head and writes it as `Checkpoint-SHA`; `--checkpoint` is optional, a cross-check refused when it resolves to another commit (`checkpoint_of`; seven cases of `land_selftest.py`, 105 in all, its two ancestor refusals failing with the comparison disabled); the ledger's lines were read at the candidate; `l0_deps.py`'s `BRIDGE_FILES` holds `_rust/schema.py`, `_rust/materialize.py`, `_rust/predict.py`, `materializers/relational.py`, `client.py` and `query.py` to a header naming a deletion phase, while only `ROUTE_READERS` (`_routing.py`, `_rust/s0.py`) may read `SDM_CORE_ROUTES`, one example per rule seeded by `selftest.py` (299 cases, one seeding the read in `client.py`; fix round 1); the drawn graph's 19 normal edges equal `cargo metadata`'s, its one dev-only edge `sdm-core` → `sdm-data`; the trimmed rows' fix-round paragraphs are in the tracker verbatim, and only their round labels, review SHAs and superseded attempts left the design; shipped files change by comments only | The bridge headers of the ledger's files (`l0_deps.py`'s `BRIDGE_FILES`) |
 | T1.10e | 1a | Owner decisions of 2026-10-10: E50, the new order and the bridge freeze; E49 approved, E52 and E53 | E50, E49's approval, E52 (state lifetime) and E53 (cuts) in [decisions.md](decisions.md); T1.21c and T1.21d in this table and the tracker, T1.22 gated on T1.21d, T1.23 narrowed, T1.26 unblocked by E52, and T1.18, T1.19, T1.30 and T1.32a to T1.32e amended by E53; the refusal map's `time_name` moved to T1.21d and its owners widened to T1.21c and T1.21d; the bridge freeze, `scripts/rust_core/bridge_freeze.py` and its baseline `bridge_freeze.json`, run by `l0_deps.py`, with its self-tests in `selftest.py` ("Host-held semantics"); the process rule for a package that moves a ledger row | The freeze passes on the tree, its baseline matching the code; in `selftest.py` it fails on each seeded fault (a raise, a warning or a branch added, a new function in a `_rust/` bridge, the baseline raised without an allowance, a stale baseline left too high) and on missing, empty and retyped evidence, and its controls pass; it runs in `prepush.sh`'s cheap tier and CI's `rust-lint` through `l0_deps.py`; no product semantics move and the contract is unchanged | The bridge freeze |
-| T1.12 | 1a | S0 case corpus | Accept cases per task kind and profile, a refusal per validator family, date-literal and capability refusals, and boundary cases: the 4,300-digit limit on both sides, escapes, a D8 packed date and DT-9's query (both diagnostic until T1.6b), the deepest valid query and a start past 64 KB. As built at T1.12, each claim with its mechanism: 19 cases in `contract/cases/s0/` beside T1.10's two, 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 (`\u`, `\t`, `\'`, `\\`, `\/` and a surrogate pair) and a truncated `\u` refused; 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; a query of 72,082 bytes; `test_the_s0_boundary_cases_sit_on_their_boundaries` holds each to that shape and the two DT-9 cases to diagnostic. 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 two DT-9 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 (it needs `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 455 levels in the runner, where the core still answers (reported to the owner, T1.12 notes) | Every case file validates in CI | Case validation |
+| T1.12 | 1a | S0 case corpus | Accept cases per task kind and profile, a refusal per validator family, date-literal and capability refusals, and boundary cases: the 4,300-digit limit on both sides, escapes, a D8 packed date and DT-9's query (both diagnostic until T1.6b), the deepest valid query and a start past 64 KB. 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 455 levels in the runner, where the core answers to 999 and refuses 1,000 (register PQL-2, proposed, recommending the core's bounded behavior) | Every case file validates in CI | Case validation |
 | T1.13 | 1a | S0 reference observations | `contract/reference/<commit>.jsonl` and `contract/reference-env.txt`, recorded after the guard update through `run_python.py` in `python-ref` mode directly until T1.14 lands `gate.sh` | The file carries the guard result and full identity, the observation schema validates it, and the comparator reads it | |
 | T1.14 | 1a | Ratchet, register v2, gate and first baselines | `ratchet.py`, `register.schema.json` for `sdm-register/2` with today's entries migrated, `register.py validate`, `compare-policy.yaml`, `availability.yaml`, `protected-paths.txt`, a minimal `gate.sh` running the checkpoint's harness from its own worktree; the first baselines | First, on the candidate, a corrupted expectation, a missing case, a skipped call and a missing native library each fail; then seeded checks: a changed answer passes with a reviewer-approved exact entry and fails without one; a new refusal fails without the owner; a removed case and a demotion to diagnostic fail; a relaxed rule, an availability downgrade or a field added as unavailable fails without an owner-approved row; a protected-path change not named in the `Reviewed-by:` trailer fails; a new case meeting its effective expectation passes without a baseline; a tightened rule passes; a branch-side baseline edit has no effect; an identity-only change passes; an ID added to `KNOWN_DIFFERING` fails; advancing the phase ref cannot erase a deliberately changed outcome or an unauthorized protected-path edit, and self-comparison is rejected; a package rebased over another landing is judged against the new tip, and a push that lands two packages fails; T1.14's output names the landing from which the checkpoint harness judges | Ratchet; register validation; protected paths; reference immutability |
 | T1.15 | 1a | Coverage generator for S0 | `coverage.py` with rules 1 to 5 and 8, `--check`, `--gate S0` | `--check` and `--gate S0` pass; an unresolved ID and a dropped path each fail | Coverage `--check`, `--gate S0` |