[objectstack-fleet]

Fixes #20280
Clause-②: no (narrowing)

What this changes

The datetime half of the card, by triage's answer A (comment 5905050200): a datetime value names a year from 1000 to 9999, and one before year 1000 is refused at both engine doors. A date keeps 0001..9999, and a time column's range does not move.

• One per-kind bound, in core's one range function. packages/core/src/utils/temporal-storage-form.ts: FIRST_SUPPORTED_YEAR is now { date: 1, datetime: 1000 }, and isOutsideTemporalYearRange asks FIRST_SUPPORTED_YEAR[kind]. No dialect switch: the range is the contract on every backend. The write door (the record validator) and the comparand door both reach it through isUninterpretableTemporalComparand, so neither door needed a second edit to the range. The date rule's four-digit padding reads the date bound (FIRST_SUPPORTED_YEAR.date), so it still pads 0001..0999.
• The refusal words. packages/objectql/src/temporal-comparand-door.ts: the datetime year class names 1000 to 9999. A datetime in 0001..0999 gets its own consequence sentence, because it sorts and compares as the instant it names on every backend. The misorder sentence ("does not sort as an instant") would be false for it. The existing wire codes are unchanged: INVALID_FILTER / 400 for a comparand, and VALIDATION_FAILED with the field's invalid_date code for a written value.
• The time class keeps its meaning. A time refusal's class ("an instant whose UTC year falls outside the years 0001 to 9999, so no time of day is read from it") used to ask the datetime range. It now asks the four-digit years explicitly, through core's date range over the instant the datetime rule reads. The corpus below shows every time answer byte-identical.
• Comments that stated 0001..9999 for a datetime are corrected in temporal-storage-form.ts, temporal-comparand.ts, datetime.ts, record-validator.ts, and one comment-only line in packages/spec/src/data/calendar-day.ts (the spec lane's file; declared here and in the report).

The published accept sets that narrow (per door, per spelling)

Each one refuses a datetime whose UTC year falls in 0001..0999, and accepted it at the base:

• Write door (VALIDATION_FAILED / invalid_date). Covers engine.insert, engine.update (one row and many) and the dry-run engine.validate, so also POST /api/v1/data/:object, PATCH /api/v1/data/:object/:id and each row of POST /api/v1/data/:object/import. Spellings: an ISO instant string, a bare YYYY-MM-DD (midnight UTC), a zone-naive YYYY-MM-DD HH:MM, and a Date. A number was already refused there, because a datetime is stored as text, so no number spelling narrows at this door.
• Comparand door (INVALID_FILTER / 400). Covers where, a per-aggregation filter and having, on the engine and on POST /api/v1/data/:object/query. Spellings: a string, a Date and a number (epoch milliseconds). The analytics native-SQL strategy asks the same predicate (service-analytics comparand-shape.ts), so it declines such a comparand and the query reaches this door. That is read from source; its suite is green.
• The year is the UTC year: 1000-01-01T00:00:00+08:00 (year 999 in UTC) is refused, and 0999-12-31T23:00:00-02:00 (year 1000 in UTC) is read.

Nothing widens: across the corpus below, no answer moved from refused to accepted.

Before and after, measured (scratch harness, not committed)

Every door answer went through the public engine API on a recording driver: find (where), aggregate (a per-aggregation filter, and having on min), validate, insert and update. The fields were a date, a datetime and a time. There were 69 values: 12 years, from -1 and 0 up to 9999 and 10000, each as a string, a number and a Date, plus zone-crossing offsets, impossible days, non-ISO spellings, bare days, zone-naive stamps, bare-integer strings, placeholders and junk. That is 1242 answers. Base 4b45afaed5 against head 65728398b2 (the source commit; later commits are tests and the changeset):

• date field: 0 of 414 answers moved. time field: 0 of 414 moved.
• datetime field: 189 moved. 126 are narrowings over 24 values in 0001..0999, in every spelling (108 accepted-to-refused, plus 18 validate verdicts from valid to invalid). 63 are refusals whose words moved: the range now reads 1000 to 9999. Six of those, in 0001..0999, were already refused for their spelling or day (0500-02-30T10:00:00Z, 0500/07/15 10:00, a bare-integer string) and are now named by their year class first, as a year past 9999 already was.
• 1000 and 9999, in every spelling, answer as before (accepted).

Stored rows before the floor (ADR-0087: refused with guidance, never shifted)

Nothing rewrites a stored datetime below 1000. It reads back as before; on MySQL a year in 0001..0099 still presents a century late (ADR-0053 D-F2; ruling 5859414357, C: no mysql2 parser change). An operator finds such rows with $lt on 1000-01-01T00:00:00.000Z, a comparand both doors admit. A PATCH that leaves the field out is accepted. A write that carries a year below 1000 is refused, so the field is written again with an instant from year 1000 on, or null. packages/rest/src/data-date-read-year-below-100.test.ts pins exactly this at the REST door: the census, the refused comparand below the floor, a PATCH of another field on such a row, a refused PATCH that keeps the year, and an accepted PATCH onto 1000. The changeset carries one ADR-0087 marker, not-required (no-migration-prescription): the change refuses a value, and no key, export or stored metadata shape moves. Its body has no FROM/TO table and no arrow.

Tests

All at head a3afb404b6 (after merging origin/main b28054654d), process TZ=America/New_York:

• @objectstack/core 60 files, 1729 passed · @objectstack/objectql 344 files, 6773 passed · @objectstack/driver-memory 65 files, 1470 passed · @objectstack/service-analytics 141 files, 3267 passed.
• @objectstack/driver-sql 209 passed, 3 skipped files (4047 passed, 95 skipped), on SQLite and on a private PostgreSQL 16.13 (server zone Asia/Shanghai). @objectstack/rest 233 files, 4571 passed, 33 skipped, on SQLite and the same PostgreSQL.
• NOT MEASURED: live MySQL. No MySQL server is available in this container, so every MySQL cell ran as a named skip. Temporal Conformance (live PG + MySQL) runs driver-sql's year-range file there, including its new year-1000 row.
• Typecheck, each exit 0: core, objectql, driver-memory, driver-sql, rest and spec, each with its check:test-typecheck test layer held.
• Ablation of the bound (run at d767c1ca81; the merge did not touch the file, blob 17abe8b044 both sides):
  • node scripts/ablation-replace.mjs set { date: 1, datetime: 1000 } back to { date: 1, datetime: 1 } (anchor 1 to 0, blob 17abe8b044 to 7a7adacdb9). Core was rebuilt, and ablation-dist-preflight found the marker in dist/index.js and dist/index.cjs (exit 0, with --source-marker).
  • Result: core 3 failed of 109, objectql 7 failed of 69. Every red is a floor pin: the datetime 0001..0999 refusals on both doors, the having twin, and the year-0050 write control.
  • Restore under trap: blob equals HEAD, git diff HEAD empty, core rebuilt, preflight --absent exit 0 with a clean tree. Green again: 109 of 109 and 69 of 69.
• Lint: eslint --no-inline-config --format json over the 19 changed TS files reported 19 files, 0 errors, 0 warnings. Population: eslint.config.mjs line 971, files: ['**/*.{ts,tsx,mts,cts,js,jsx,mjs,cjs}'], covers all 19. Invariance: the config enables no type-aware linting (its lines 327-328), so this diff moves no untouched file's verdict.
• Gates: node scripts/pm/dispatch-gates.mjs --commands at a3afb404b6 derived 89. All were run with recorded exit codes. --ran reports "89 derived, 87 run, 2 NOT-MEASURED, 0 UNRUN". The two NOT MEASURED are check:dual-build-cjs-loads and check:type-check-debt, both exit 3 (PREREQUISITE NOT MET: they read every package's dist and this worktree built only the touched closures).

The pins, and each one's fate

• Flipped to refused, with the 1000 edge added as the accepted control:
  • core temporal-storage-form.test.ts and temporal-comparand.test.ts;
  • objectql engine-temporal-year-range.test.ts (both doors, every position), engine-aggregate-having-temporal-door.test.ts (the year-1 control became a refusal row; year 1000 is read), engine-temporal-write-real-day-iso.test.ts (the 0050-01-01T10:00:00Z write);
  • rest data-temporal-year-range.test.ts, import-date-cell-iso-real-day.test.ts (the dt cell 0001-01-01 is now refused per row by the write door behind the reader), import-datetime-year-below-100.test.ts (the reader layer is kept; the import door refuses each row below 1000 and stores 1000 and 2026; the round trip runs at 1000 and 2026), and data-query-calendar-day-year-below-100.test.ts (the whole-day bound is measured at 1000-01-01; the card's 0050-01-01 bounds and row are pinned as refusals).
• Moved to date as the control: the year-4 leap day in core, and date 0001..0999 in every file above (still accepted).
• Kept because they never pass a door: driver-memory memory-20264-temporal-year-range.test.ts and driver-sql sql-driver-20264-temporal-year-range.test.ts. They write straight through the driver, and their datetime rows below 1000 are what a row stored before the floor holds. Headers are corrected, and a year-1000 edge row is added. Also kept: the [finding] outside calendar-day.ts, a year from 0001 to 0099 is still read as 1900..1999: Date.UTC's two-digit-year remap in core's datetime and bucket helpers, filter-tokens and the REST import's datetime cell #20599 / spec nextUtcCalendarDay answers null for every day in years 0001..0099 (Date.UTC reads them as 1900..1999), so a datetime $lte / $between max on such a day skips whole-day widening and misses that day's rows #20550 unit pins on parts, week keys and calendar-day helpers (core datetime-year-below-100.test.ts, service-analytics week-key-year-below-100.test.ts, spec calendar-day.test.ts), since no door is in their path.
• data-date-read-year-below-100.test.ts (rest) now writes its datetime values below 1000 through the driver, as stored-before-floor rows, and pins the operator path above.

Acceptance notes

• File surface. Five REST test files went red and are rewritten above, plus one comment line in a sixth (count corrected by the seat after review 5910551203). REST's source is untouched. The dispatch's surface named pins in core, objectql, driver-memory and driver-sql; these are the same pins one door further out.
• The write door's words name the kind, not the range. The ruling asks for a refusal "naming the kind and the range". The comparand door names both. The write door answers the existing invalid_date sentence ("must be a valid datetime (ISO-8601)"), as it did for the 0001..9999 range: naming the range there needs a new validation-message.ts key in packages/spec, outside this card's surface. Raised in the report.
• Placeholders are not judged by the door, by design. A relative-date placeholder is stepped around ahead of its resolution, so {1977_years_ago} on a datetime still reaches the driver. It compares as the instant it names (year 49; measured, correct rows). The same path lets placeholders that land past 9999 or before year 1 through, with wrong answers. That class is older than this change; the measured case is in the report.
• Levels. minor for @objectstack/core and @objectstack/objectql, whose source moves. REST and the analytics service narrow through them without a source change of their own, and the changeset config's one version group moves them in lockstep.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

16 anchor(s) derived from 3 changed package(s); no hand-written page names any of them. ⚠️ 3 changed file(s) yielded no anchor (packages/core/src/utils/datetime.ts, packages/core/src/utils/temporal-comparand.ts, packages/spec/src/data/calendar-day.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

What this run could not see

• 3 changed file(s) yielded no anchor (packages/core/src/utils/datetime.ts, packages/core/src/utils/temporal-comparand.ts, packages/spec/src/data/calendar-day.ts) — pages documenting those are invisible to this run
• 7 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 142 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 1741c5dcb62d11bc9b59702dd67080ef6a7ac9e8 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 303dd621fc30a3d5d5a9274687418f2a2c4645ac — the merge of head a3afb404b6418eaa640f223e06d0ca5ed71286e0 into base 1741c5dcb62d11bc9b59702dd67080ef6a7ac9e8, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 303dd621fc30a3d5d5a9274687418f2a2c4645ac && git checkout 303dd621fc30a3d5d5a9274687418f2a2c4645ac
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 1741c5dcb62d11bc9b59702dd67080ef6a7ac9e8 a3afb404b6418eaa640f223e06d0ca5ed71286e0 && git checkout -B drift-repro 1741c5dcb62d11bc9b59702dd67080ef6a7ac9e8 && git merge --no-ff a3afb404b6418eaa640f223e06d0ca5ed71286e0

node scripts/docs-audit/affected-docs.mjs --json 1741c5dcb62d11bc9b59702dd67080ef6a7ac9e8

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: a3afb404b6418eaa640f223e06d0ca5ed71286e0
Local-runs: none

PR #20843 on card #20280 (the datetime half; PR #20306 landed the date half). The head was a3afb404b6418eaa640f223e06d0ca5ed71286e0 at both reads, draft, open. Inputs: the card's body and all eleven comments, #20264, the PR body, its 20-file list, the net diff against main at the merge base b28054654d (20 files, +560/−158), and the head's check-runs. Read-only: git reads of the fetched branch and REST reads; nothing built, run or re-run.

Check-runs on this head, read once just before this record was written: 34 runs, 26 success, 3 skipped, 5 in_progress, 0 failure. success: Temporal Conformance (live PG + MySQL), Build Core, TypeScript Type Check with Type Check · workspace, · source gates, · consumer gates and · debt ledger, Dogfood Regression Gate (three shards and the rollup), Dogfood Verify CLI, Governed Surface Queue Guard, Check Changeset, Spec property liveness, Test Core (2/6), Test Core (4/6), and the PR-shape checks (the card claims this branch; no other open PR claims the issue or the single-writer path; Part-of parity; PR size; documentation links; docs-affected flag). Still in_progress: Lint & Repo Gates, Test Core (1/6), (3/6), (5/6), (6/6). Not waited on.

① Derived judgments

Accept sets, door by door and spelling by spelling; each judged against the diff.

1. The write door (record-validator.ts, VALIDATION_FAILED with the field code invalid_date) narrows for a datetime field: a value whose UTC year falls in 0001..0999 was accepted at the base and is refused at the head, in every spelling the door read: an ISO instant string (with Z, an offset, or none), a bare YYYY-MM-DD (midnight UTC), a zone-naive YYYY-MM-DD HH:MM[:SS[.f]] or T form, and a Date. A number was already refused (the arm's readable predicate admits only a Date or a Date.parse-readable string), so no number spelling moves. Reached on engine.insert, engine.update (one row or many) and engine.validate. Right: the validator's source diff is comment-only; it asks isUninterpretableTemporalComparand, which asks isOutsideTemporalYearRange, which now reads FIRST_SUPPORTED_YEAR[kind]: one per-kind bound, no dialect switch, no second edit to the range.
2. The comparand door (temporal-comparand-door.ts, INVALID_FILTER / 400) narrows for a datetime field at where, at a per-aggregation filter and at having (list-operator members included): a string the datetime rule reads, a Date and a number (epoch milliseconds) whose UTC year falls in 0001..0999 are refused before any driver read. Right: the door's diff moves words and classes only; the verdict stays core's predicate. Pinned at every position (engine-temporal-year-range.test.ts, and the having twin).
3. REST narrows through those two doors with no packages/rest/src change: POST /api/v1/data/:object, PATCH …/:id, each row of POST …/import (the reader layer is unchanged; the write door behind it refuses the row as invalid_date), and POST …/query. Right; pinned in the six REST test files.
4. service-analytics' native-SQL decline: comparand-shape.ts asks the same core predicate of every temporal literal, so NativeSQLStrategy.canHandle now declines a datetime comparand in 0001..0999 and the query is served on the engine path, where the door refuses it. Right; no source change in that package; read from source, as the PR says.
5. The UTC year is the year judged: the first instant of year 1000 at an offset of plus eight hours (year 999 in UTC) is refused; the last hour of year 999 at an offset of minus two hours (year 1000 in UTC) is read. Right; pinned on both doors.
6. date is unchanged on both doors: 0001..9999, padded to four digits from FIRST_SUPPORTED_YEAR.date. Right by construction (the date entry stays 1 and the padding reads that entry) and by the date controls added in every pin file. The date year-class sentences are byte-identical: the misorders() helper composes exactly the base template ("It would reach the driver in a form that does not sort as a day and answer the wrong rows, or a database error." and "Compared with each group, it does not sort as a day and would keep the wrong groups.").
7. time is unchanged: the H2 fork. misreadClassOf asked isOutsideTemporalYearRange(value, 'datetime') for a time hit and now asks isInstantOutsideFourDigitYears, which reads a string into the instant the datetime rule reads (temporalStorageForm) and asks core's date range of that instant; a number or a Date goes straight through. At the base the datetime range was 0001..9999; at the head the date range is 0001..9999, and both read a number, a Date or a string's instant by its UTC year, so every time answer is unchanged by reading. A time refusal's verdict never consulted the floor (the time predicate reads keepsTimeOfDay, which the floor does not touch), and its misread class keeps the four-digit years. The helper asks core's function and does no year arithmetic of its own; it borrows the date kind's bound as "the four-digit years", which its docblock says out loud. Consistent with the dev's 0 of 414 moved. Right.
8. Words only, not accept sets: YEAR_CLASS names 1000 to 9999 for a datetime; the new DATETIME_BEFORE_YEAR_1000 class gives 0001..0999 its own consequence sentence (such a value sorts as the instant it names on every backend, so the base's "does not sort as an instant" would be false for it); year 0 and a year past 9999 keep the misorder words. A comparand in 0001..0999 already refused for its spelling or its day is now named by its year class first (the six the PR body counts). No tracker number in the runtime strings.
9. Public surface: nothing exported moves. isOutsideTemporalYearRange keeps its signature; FIRST_SUPPORTED_YEAR (now a per-kind record) and isInstantOutsideFourDigitYears are module-private; temporalStorageForm was already exported from core. The packages/spec change is one docblock sentence in calendar-day.ts. Right.
10. Widening: none. The only bound that moved went from 1 to 1000; nothing refused at the base is accepted at the head. The dev's corpus reads 0 refused-to-accepted, consistent with the source.
11. Seat ruling 5859414357 C holds: no mysql2 parser change. driver-sql's source is untouched; its one changed file is the year-range test.

Triage's answer A (5905050200), item by item: a datetime below year 1000 refused at both doors: met. date keeps 0001..9999: met. One per-kind bound inside isOutsideTemporalYearRange, no dialect switch, no second edit: met. The existing refusal codes: met (INVALID_FILTER; VALIDATION_FAILED / invalid_date; no new code). "Naming the kind and the range": met at the comparand door; the write door names the kind and keeps its existing sentence (③ item 7). Pins: the datetime 0001..0999 controls flip to refused on both doors, 1000 and 9999 are accepted, date 0001..0999 stay accepted: met, in core, objectql, driver-memory, driver-sql and rest. A BREAKING minor with an ADR-0087 disposition: met (②).

② Semver level

• .changeset/20280-datetime-year-floor.md: @objectstack/core minor, @objectstack/objectql minor, a **BREAKING** banner, Clause-②: no (narrowing). Right: the launch-window convention ships an accept-set narrowing as minor with the banner as the carrier, and the two packages whose published source moves are the two graded. rest and service-analytics narrow through a dependency with no src/** change of their own and are named in the prose; under this repo's rule (WHICH LEVEL: the level follows the act on a package's own published surface, and the level axis judges only a declared clause ②) they need no frontmatter entry, the fixed group moves them in lockstep, and Check Changeset is success on this head. Right.
• Clause-②: no (narrowing) is the line: the diff widens no surface and narrows two doors, which is the no (narrowing) arm of clause2-line.mjs; triage's yes (narrowing) spelling would have read as "widens one surface and narrows another", which this diff does not do. The PR body carries the same line.
• ADR-0087: exactly one marker, not-required (no-migration-prescription). The body carries no FROM/TO table, no arrow and no migration heading (the only arrow-shaped bytes in the file are the marker's own closing delimiter). The category is right: the change refuses a value; no authorable key, spelling, export or stored metadata shape moves, so nothing exists for objectstack migrate meta to rewrite; a datetime stored below 1000 is record data, and the body says it is never shifted. The operator path in the body (a $lt census on the floor's first instant, then a write into the range or null) is guidance about data, not a rewrite of a consumer's code or metadata; the prescription refusal is about consumer rewrites, and the disposition triage asked for ("refused with guidance, never silently shifted") is exactly that paragraph.
• Review faces, sentence by sentence:
  • The changeset: every factual sentence read true, with two notes. The MySQL sentences are true by mechanism and by measurement: the century shift is mysql2's read presentation of 0001..0099 (from 0100 up MySQL reads a DATETIME back as written; card comment 5875809297), and the $lt census finds such rows "because the comparison runs on the stored value": the SQL WHERE compares the stored DATETIME literal, not the presented Date, which is what PR fix(driver-sql): a MySQL date reads back the day it stores, so a year below 100 no longer comes back a century late #20306's live rows showed ($eq on the written value found the year-9 datetime row at base and head). Not re-measured on this head: no live MySQL locally, and the REST file's MySQL cell is a local instrument by ruling 5859414357 B. A precision note, not a falsity: "or with null" holds for a field that is not required.
  • The PR body: one false sentence, in Acceptance notes: "Four REST test files went red and are rewritten above, plus one comment line in a fifth." The file list has six REST test files: five rewritten because they pinned a datetime below 1000 at the public door (data-temporal-year-range, data-date-read-year-below-100, data-query-calendar-day-year-below-100, import-date-cell-iso-real-day, import-datetime-year-below-100) and a comment-only sixth (data-query-date-year-range). The body's own pins section and the os-dev-report count all six; the sentence should read five and a sixth. A body edit, which does not move the head. Every other factual sentence read true, including "later commits are tests and the changeset" (no non-test source changed after 65728398b2), the two eslint config lines cited, and the sentence on Temporal Conformance (that job runs the whole driver-sql suite with the live MySQL URL and the matrix expectation set, so the year-range file's new year-1000 row runs there).
  • The refusal prose in temporal-comparand-door.ts: true. The datetime year class names 1000 to 9999; the before-1000 sentence states MySQL's documented floor and the measured 0001..0099 misread and claims no misorder; the remedy names the range; the docblock's history matches what temporal values outside the years a four-digit text or a backend holds: a datetime comparand for year 10000 or −1 misorders on memory/SQLite and 500s on PostgreSQL; a date in year 0000 500s on PostgreSQL; a date write stores +010000-… verbatim #20264 and driver-sql on MySQL reads a year 0..99 back a century late — REST create stores placed_on: "0009-03-04" correctly, and …/query returns "1909-03-04"; a datetime 0009-03-04T10:00Z returns 2004-09-03T10:00Z #20280 measured.
  • packages/spec/src/data/calendar-day.ts: one docblock sentence, true (the years end at 9999; a date 0001..9999, a datetime 1000..9999; the doors refuse the rest). Declared in the PR body and in the report as the spec lane's file.

③ Boundary flags

1. Five REST test files changed: answered, right. REST source is untouched; the files pinned the two doors one layer out, at the public door, and had to move with them; the dispatch's pin surface named the inner packages and these are the same pins. The PR body's count is wrong by one (② above); the report's is right.
2. YEAR_CLASS changed shape; DATETIME_BEFORE_YEAR_1000 added; date refusals byte-identical: answered, right, and confirmed by composing the templates (① item 6). The old single misorder template was false for a datetime in 0001..0999.
3. The driver pins keep rows below 1000: answered, right. Neither driver is a door (both file headers say the doors sit in the engine); the rows are the stored-before-floor class the disposition describes, written straight through the driver; headers corrected and a year-1000 edge row added in each; the MySQL cell still asserts the stored text for 0001..0099.
4. One merge of main: answered. The merge commit brings b28054654d in. main had moved one file of this diff since the dev's base 4b45afaed5, import-date-cell-iso-real-day.test.ts, by /import: a time cell with milliseconds (10:00:00.250), exactly as /export writes it, is refused per row as invalid_date, so the export does not re-import #20722's codeOf change, and the merge combined both edits without conflict; the merged table is coherent (the new dt row below 1000 is refused as invalid_date, the code codeOf gives a dt cell). The net diff of the other 19 files has the same patch-id as the dev's pre-merge branch, byte for byte. The report's "touched no file of this diff" is inexact for that one file; the PR body's narrower claim (the merge left temporal-storage-form.ts at the same blob) is true. The dev's suites and gates ran at the merged head.
5. check:dual-build-cjs-loads and check:type-check-debt NOT MEASURED locally: answered from CI. Build Core hosts the first (its "Every published require entry point actually loads" step) and Type Check · debt ledger runs the second; both success on this head.
6. Live MySQL NOT MEASURED locally: answered from CI. Temporal Conformance (live PG + MySQL) is success on this head. It runs pnpm --filter @objectstack/driver-sql test against live PostgreSQL 16 and MySQL 8.0 with the matrix expectation set, so sql-driver-20264-temporal-year-range.test.ts, its year-1000 edge row and its MySQL stored-text cell ran there.
7. open_questions[0]: answered by the seat (5910336270): A in this PR, B filed as [finding] the write door refuses a readable ISO datetime outside its years with "must be a valid datetime (ISO-8601)", a false sentence for that value; the comparand door names the range, the write door does not #20846. Judged only for the faces: A leaves no face sentence false. The changeset says the write refusal is the existing invalid_date sentence for a datetime field, and the PR body says the write door names the kind, not the range, and why. Triage's "naming the kind and the range" is met at the comparand door; the write door's range words are [finding] the write door refuses a readable ISO datetime outside its years with "must be a valid datetime (ISO-8601)", a false sentence for that value; the comparand door names the range, the write door does not #20846's.
8. The out-of-scope finding (a relative-date placeholder resolving outside the four-digit years steps around the door): this diff does not touch that path. The placeholder step-around in isUninterpretableTemporalComparand (the classifyFilterToken exemption) and the door's position before token resolution are unchanged. Filed by the seat as [finding] a relative-date filter token that resolves outside years 0001..9999 ({8000_years_from_now}, {2027_years_ago}) reaches the driver as extended-year text and matches every row: the comparand door runs before token resolution #20844.
9. Governed surfaces: none in the file list (.changeset and packages/** only); Governed Surface Queue Guard is success.
10. Before landing: correct the PR body's REST file count (five rewritten and a comment-only sixth), a body edit that does not move this head; and read Lint & Repo Gates and the four remaining Test Core shards green, as the queue rule asks.

Implemented-by: claude/issue-20280-datetime-year-floor
Reviewed-by: session_01DEvba2nBuD4tWzfq8r8NFY

VERDICT: PASS

---

Generated by Claude Code