You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit f96bcbc
Browse filesBrowse the repository at this point in the historyBrowse files
T1.32h fix 1: the main fix lands without D3 and D4
The owner has not answered D3 or D4, so the main fix lands without
them (the orchestrator's decision); both are kept on
rust-core-phase-1-archive-1c-T1.32h-d3d4-94d536f5 for the morning.
- t132h-pending.json: the ids of the D3 and D4 groups that pass on the
main fix alone leave pending (they stay authored): key.twice-missing-
first on python-core and rust-host, as a vector and as a case (a
missing column is refused before any repeat), and the client's
m.key-table-str-subclass (a str subclass naming a table is written
as the plain str). Every other D3 and D4 id stays pending.
- E101: the 53 vectors are the 50 of the main tests and the 3 the D3
test commit adds.
- P1B-12: a 0-d NumPy array as a key raises TypeError on both routes,
the caller's exception let out unchanged as the iteration policy
says (review P3-1).
Signed-off-by: Adi Wadaskar <awadaskar@nvidia.com>
Copy file name to clipboardExpand all lines: docs/design/rust-core/phase-1/decisions.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -133,7 +133,7 @@ Standing decisions are in [migration-plan.md](../migration-plan.md) section 2 an
133
133
| E110 | The ratchet's judging path (T1.32g part 2a): (a) the owner's decision of 2026-10-13, relayed by the orchestrator: where python-old's observation of a case equals the checkpoint's `python-ref` line exactly and that line is `INTERNAL_ERROR`, it is the old client's real crash, the reference's own `StructuredDataError`: held with the reference result as python-old's baseline, and `ratchet.py check` prints a `baselines` note naming it the old client's crash (`old_client_crash`); every other `INTERNAL_ERROR`, python-core's and rust-host's always, still fails, and `register.py` is unchanged. "Exactly" (the orchestrator's reading, after the part's review): equal in the semantic projection (`ratchet.semantic`) less `host.warnings` and `host.origins`, runtime noise (python-old records origins and python-ref none; the floor cell's pandas adds `DeprecationWarning`s); the error class, stage, statements, public schema and every other semantic field must match. The reference records no error message, only the class and stage, so two different crashes at the same stage after the same statements look the same; (b) a proposed baseline at an `INTERNAL_ERROR` (a) does not allow fails the change that proposes it, where only a held one was checked, and `accept` writes no such line; (c) the orchestrator's decision: on a first admission (no baseline of the case for that runner at the checkpoint), a runner's effective expectation is the reference's outcome moved by an approved entry whose `case_outcomes` names the case, cell and runner with `old: none` (P1B-72's convention), under the rule a baselined case's transition already follows (an owner's entry for a new refusal, never `INTERNAL_ERROR`); `effective` gives it to the comparator's `--expect` and to `accept`, and a runner no entry names keeps no expectation, so the reference holds it; (d) `accept` judges each runner alone, leaving out the fields `availability.yaml` marks `unavailable` for it, so one entry text (a stage and error included) serves rust-host as well: a runner meeting its own expectation gets its line, one that does not gets none, and `check` names the acceptance case it lacks; before, a case was written only when every runner given met, so an admission where the core differs under an approved entry could never be written for python-old either | Seven inventory cases have the reference answer with its own `INTERNAL_ERROR`, which the baselines rule took for a panic, so they could not be admitted; and a first admission was held to the reference whatever the register approved (P1B-7, P1B-9, P1B-10, P1B-11) | (a) approved by owner 2026-10-13 (relayed by the orchestrator; recorded at T1.32g part 2a, never the implementer's approval); (b) and (d) implementer, for the reviewers; (c) the orchestrator's decision, owner informed |
134
134
| E111 | A map's and a union's values in canonical form (T1.32g part 2c), a judging-path change: (a) the observation's canonical form (H9) holds a map read as Arrow as `["map", [[key, value], ...]]` in Arrow's entry order, duplicate keys kept (a null map `null`, an empty one `["map", []]`), and a union as `["union", type code, member name, cell]`, never null itself: a null member, or a union DuckDB writes as null (a null under its first member), keeps its tag with a null cell; `contract/t132g-p2c-vectors.json` (the test author's) is the spec, and `run_python.arrow_values` and `sdm-testkit`'s `values` both meet it; (b) an interval stays unencodable, inside a map or a chosen member too, so a result holding one still fails `sql.result`; a member no row chooses names nothing; a map or union read as rows (`fetchall`) stays unencodable (`_LOSSY_AS_ROWS`); `compare.py` is unchanged; (c) the union's type codes and a dense union's offsets are read from its buffers at the array's offset, since pyarrow's `UnionArray.type_codes`, `offsets` and union scalars ignore a slice (a union in a list is one); (d) `result-vectors.json`'s "a map" and "unions of one value under two tags" take the form; (e) the orchestrator's decision: nested.map's and nested.union's python-ref lines are recorded again with the new encoder under T1.13's rules, an encoding-only change of the reference's lines, under register P1B-54 (proposed, for the reviewers) | `compare.py`'s `sql.result` fails every result holding an unencodable value, even against itself, and both cases hold a map or a sparse union in the reference's `from_source` sample of `users`, so neither could ever be admitted; the owner asked for a real canonical form, not a skip | (a), (b) and (d) as the test author's vectors and tests specify; (c) implementer, for the reviewers; (e) the orchestrator's decision, P1B-54 for the reviewers |
135
135
| E100 | Decimals (T1.32b), in two landings: part 1 the core and its evidence, the `decimal.*` cases still diagnostic; part 2 their admission, once its entry and P1B-18 are approved. (a) A decimal feature has the reference's wire dtype at any precision (float64 with a scale, int64 to 18 digits or where every value fits, else string); DECIMAL(38, 38) cells are sent on both hosts. (b) A decimal sum is held to its column's declared precision (INVALID_REQUEST); a decimal mean is taken, rounded half away from zero. (c) A static decimal is compared in a condition, its constant read at the column's type: one it does not hold INVALID_REQUEST, a float past scale 22 by name (P1B-71). (d) A static decimal target stays refused by name (P1B-18). (e) The family's decimal keys succeed (P1B-33's refs) | The test author's 201 vectors and three cases; [as-built.md](as-built.md#t132b)| The orchestrator's brief; P1B-18 approved by both reviewers, P1B-71 the owner's |
136
-
| E101 | Keys and time columns as the contract's `Given` (T1.32h, register P1B-12), contract version 23: (a) `SourceSpec.primary_keys` is `Given<Option<Vec<String>>>` and `SourceSpec.time_columns` `Given<Option<String>>`, by table, as `SchemaEdit` writes the same values (E67): `{"value": ...}` or `"unreadable"`, under a host-neutral conformance rule written on `Given` (a value the contract's type holds is written as it; any other, a number, a set, a mapping, binary, a nested or non-text member, is unreadable; text that cannot cross UTF-8 is the host's encoding refusal; an error raised reading the caller's collection is the caller's, never caught); the decoder refuses only JSON outside that shape, `INVALID_MESSAGE`, a host bug; nothing a user can say (an empty key) is typed out of the schema. (b) The Python host classifies with one function, `_rust/codec.py`'s `given_key` and `given_name_or_none`, moved unchanged from `_rust/edits.py` and shared by `Schema.from_source`'s bridge and the edit setters; the frozen `_rust/schema.py::from_source` calls it, declared `moved` naming T1.32h (the owner allowed the bridge to grow for P1B-12, 2026-10-13, item 18); the host decides nothing of a value's validity. (c) `sdm-schema`'s `apply_keys_and_times` refuses after the source is read: an unreadable key `INVALID_REQUEST` `{field: primary_keys, table, rule: key_not_names}`, a `null` key as an empty key `{field, table}`, an unreadable time column `{field: time_columns, table, rule: time_column_not_a_name}`; the refusals are one helper each, shared with `edit_schema`, the same code, message and `rule`, the field each operation's own (`primary_key` and `time_column` there), and `null` keeps each operation's meaning (an empty key here, cleared there). The edit refusals gaining `rule` is a change of error meaning, so this version (H25). (d) The ordering: the host's steps (reading an iterable, encoding) before the run starts; source failures before any refusal of a value; every key before any time column; within each, the tables by name; within one key the table, then unreadable or `null`, each column's existence, then empty and composite. (e) P1B-12 rewritten and approved on the owner's item 18, its remaining differences named: a list or mapping time column the core's named refusal where the reference fails unnamed (E66(b)'s class), the host's steps before the source is read, and JSON's coercion of a non-`str` table name. (f) Two owner-pending options, each a separate commit that can be dropped: D3, a key naming a column twice refused `key_column_twice` by `describe_source` (P1B-73); D4, a table named by anything but a `str` refused by the host before the run (P1B-74); both proposed | The P1B-12 design of 2026-10-13, revised after Codex's review; the test author's 53 vectors (`contract/given-vectors.json`) on python-core and rust-host and the client's rows of every Python type (`tests/test_t132h_keys_and_times.py`) | approved by owner 2026-10-13 for P1B-12 (item 18, relayed by the orchestrator; recorded at T1.32h, never the implementer's approval); D3 and D4 the owner's, proposed |
136
+
| E101 | Keys and time columns as the contract's `Given` (T1.32h, register P1B-12), contract version 23: (a) `SourceSpec.primary_keys` is `Given<Option<Vec<String>>>` and `SourceSpec.time_columns` `Given<Option<String>>`, by table, as `SchemaEdit` writes the same values (E67): `{"value": ...}` or `"unreadable"`, under a host-neutral conformance rule written on `Given` (a value the contract's type holds is written as it; any other, a number, a set, a mapping, binary, a nested or non-text member, is unreadable; text that cannot cross UTF-8 is the host's encoding refusal; an error raised reading the caller's collection is the caller's, never caught); the decoder refuses only JSON outside that shape, `INVALID_MESSAGE`, a host bug; nothing a user can say (an empty key) is typed out of the schema. (b) The Python host classifies with one function, `_rust/codec.py`'s `given_key` and `given_name_or_none`, moved unchanged from `_rust/edits.py` and shared by `Schema.from_source`'s bridge and the edit setters; the frozen `_rust/schema.py::from_source` calls it, declared `moved` naming T1.32h (the owner allowed the bridge to grow for P1B-12, 2026-10-13, item 18); the host decides nothing of a value's validity. (c) `sdm-schema`'s `apply_keys_and_times` refuses after the source is read: an unreadable key `INVALID_REQUEST` `{field: primary_keys, table, rule: key_not_names}`, a `null` key as an empty key `{field, table}`, an unreadable time column `{field: time_columns, table, rule: time_column_not_a_name}`; the refusals are one helper each, shared with `edit_schema`, the same code, message and `rule`, the field each operation's own (`primary_key` and `time_column` there), and `null` keeps each operation's meaning (an empty key here, cleared there). The edit refusals gaining `rule` is a change of error meaning, so this version (H25). (d) The ordering: the host's steps (reading an iterable, encoding) before the run starts; source failures before any refusal of a value; every key before any time column; within each, the tables by name; within one key the table, then unreadable or `null`, each column's existence, then empty and composite. (e) P1B-12 rewritten and approved on the owner's item 18, its remaining differences named: a list or mapping time column the core's named refusal where the reference fails unnamed (E66(b)'s class), the host's steps before the source is read, and JSON's coercion of a non-`str` table name. (f) Two owner-pending options, each a separate commit that can be dropped: D3, a key naming a column twice refused `key_column_twice` by `describe_source` (P1B-73); D4, a table named by anything but a `str` refused by the host before the run (P1B-74); both proposed | The P1B-12 design of 2026-10-13, revised after Codex's review; the test author's 53 vectors (`contract/given-vectors.json`: 50, and the 3 its D3 commit adds, still pending with D3) on python-core and rust-host and the client's rows of every Python type (`tests/test_t132h_keys_and_times.py`) | approved by owner 2026-10-13 for P1B-12 (item 18, relayed by the orchestrator; recorded at T1.32h, never the implementer's approval); D3 and D4 the owner's, proposed |
137
137
| H1 | Runtime cells: CI cells are named by runtime and pinned from `phase-0/support-matrix.md`, as local semantic cells, not Databricks runtime certification: `ref-pandas3` (the recorded reference environment) compared with the reference on all fields; `dbr17-pandas2` (the observed DBR 17.3 LTS set) where `python-core` equals `python-old`; `floor-pandas2.2` (Python 3.10, pandas 2.2.0, pyarrow 14.0.1, NumPy 1.26.4, the E16 floor), compared like `dbr17-pandas2`; revised by E16 from A8's S0-only pandas 1.5 floor. A runtime-only difference is a register entry naming the cell, never an exclusion; observation identity records platform and cell. Re-review R2 (owner answer 5): the reference stays recorded on macOS and reference comparisons run locally through `gate.sh`; CI gates platform-independent fields; a Linux reference is a later CI build | Locked check 4 never said which pandas it compares on; the first attempt ended with 165 pandas-2 exemptions | approved by owner 2026-10-08 (round 1 answer 1, round 2 answer 5); the cell versions are the orchestrator's reading of support-matrix.md |
138
138
| H2 | Gate integrity: the checkpoint is the last reviewed landing, with no tag, serialized promotion or separate accept commit (re-review R2): `CHECKPOINT_SHA = git merge-base CANDIDATE_SHA BASE_SHA`, with `BASE_SHA` the phase-branch tip resolved at package start and both SHAs recorded and passed to every gate run, never recomputed from a ref that contains the candidate (R2 closure check); each gate run checks it out into its own worktree, overlays only its observation projection and capture (`run_python.py`, the test kit's case loader and observation writer; the pure-Rust host, providers and scripted endpoint are protected candidate code, and `KNOWN_DIFFERING` is a candidate data file accepted only as a subset of the checkpoint's), and runs its harness, comparator, ratchet, L0 scripts and expectations against the candidate's observations; `contract/protected-paths.txt` is read at the checkpoint, and a protected change passes only when the reviewer's `Reviewed-by:` trailer names it, an outcome change only with a reviewer-approved register entry, a relaxation only with an owner-approved row; before T1.14 lands the candidate's harness runs under review, with no acceptance claim; `contract/availability.yaml` fixes availability per runner and field, and "unavailable" cannot pass a locked check; the owner's local merge is the only hard approval; no signing machinery | Re-review found the gate judged by code and expectation files the candidate can edit (learnings lesson 9), and round 2 found the tag procedure could not bootstrap and let the executor authorize its own protected changes | approved by owner 2026-10-08 (round 1 answer 2, round 2 answer 1); the bootstrap, the authorization rule and the narrowed overlay approved at the T1.7b check-in |
139
139
| H3 | A change is one reviewed work package: its proposed baselines are reviewed with it, one final gate run judges it against the checkpoint, it lands only with evidence for its exact SHA (one rerun after review fixes), and landing is the promotion; `rust-lint` clippy skips `sdm-testkit`, so only `rust-test` builds DuckDB | A CI round trip per commit and per baseline-only commit repeats the first attempt's validation overhead; the cold Rust jobs are dominated by the bundled DuckDB build | approved by owner 2026-10-08 (T1.7b check-in); revised re-review R2 |
0 commit comments