fix(metadata): canonicalise the timestamps migrateSysNotificationToEvent writes

[zhuangjianguo]

Part of #13998 — the code half only. The data half of that card (whether any deployment has already run this migration against Postgres or MySQL, and therefore whether a backfill is owed) is unanswered and is a maintainer floor, so this PR deliberately does not carry a closing keyword. Reading below.

All gates and tests quoted here were run at 3fc4e3bf24, which is this branch's head.

What was wrong

selectLegacyRows reads the legacy sys_notification table through driver.raw/execute, and the migration then wrote

constcreatedAt=row.created_at!=null ? String(row.created_at) : now();at: isRead&&row.read_at!=null ? String(row.read_at) : createdAt,

into created_at on the new sys_inbox_message row and into created_at / at on the new sys_notification_receipt row. On Postgres and MySQL an instant column materialises as a JS Date, so String(...) spells

Sun Aug 30 2026 18:19:25 GMT+0800 (China Standard Time)

— whole seconds in the migrating host's zone, milliseconds dropped, and a trailing zone name that is in no dialect's timestamp grammar. This migration is one-way, so that spelling is what the platform carries afterwards.

The fix

One canonicaliser, applied at both sites, matching the repo's existing correct form (metadata-protocol/src/protocol.ts, the occurred_at read in readMetadataAuditEvents):

functioncanonicalTimestampText(value: unknown): string{if(typeofvalue==='string')returnvalue;if(valueinstanceofDate)returnvalue.toISOString();returnString(value);}

Route A of #13973 (canonicalise at the migration), as triaged — not the driver-side read-door normalisation, and not a tolerant ?? fallback. A Date and ISO text are two materialisations of one instant, not two spellings of a key. Anything that is neither a string nor a Date keeps its previous String() rendering unchanged rather than having a unit guessed for it on a one-way write path; widening that would be a second, unevidenced decision.

Why neither column could be repaired further upstream

This read path bypasses formatOutput entirely — execute() returns await builder untouched, the same class of bypass sql-driver.ts:3964-3965 already names for aggregate and distinct. Even at the record read door the two columns diverge by different gates, and neither one closes:

• created_at is a builtin audit column, so it is never in datetimeFields and no declared-field coercion reaches it; formatOutput repairs it only inside its if (this.isSqlite) arm (repairNaiveUtcAuditTimestamp over AUDIT_TIMESTAMP_COLUMNS = ['created_at', 'updated_at'], sql-driver.ts:269).
• read_at is a legacy column ADR-0030 removed from the object, so it is not a declared Field.datetime either — datetimeFields is built from declared datetime columns, and read_at appears nowhere in packages/platform-objects/src today. No arm of formatOutput could reach it on any dialect.

The pin, and why it is the real content here

The defect was invisible because this migration's tests drive SQLite/memory shapes, where the legacy stamps are already canonical ISO text and String(row.created_at) is the identity. The new cases break that identity by feeding a hand-made Date — the discriminating input — through the migration's read path under a forced process zone. @objectstack/metadata has no driver dependency and must not grow one, so a hand-made Date is the right instrument, exactly as the OCC seam's own suite uses one.

They live in the existing test file and reuse its already-pinned engine doubles, so check:engine-double-contract's ledger is untouched.

Ablation, on the committed tree, no rebuild leg (the pin imports ./migrate-sys-notification-to-event.js relatively, so vitest resolves source; dist/ is not on this path — stated rather than fabricated):

• mutation proven on disk in both directions — injected String(row.created_at) / String(row.read_at) count 2, removed canonicalTimestampText(row. count 0 — and by blob: 1f9ef52ee8 to fb4534c3e5
• result: Tests 1 failed | 7 passed (8), failing precisely on the new case with AssertionError: inbox.created_at must be canonical ISO-Z: expected 'Sun Aug 30 2026 18:19:25 GMT+0800 (Ch…' to match /^\d{4}-\d{2}-\d{2}T…/ — the production spelling, reproduced
• the other 7 cases stayed green under the mutation, which is the SQLite identity demonstrated rather than asserted
• restore under trap ... EXIT INT TERM with absolute paths, proven by an empty git diff HEAD (0 bytes from --name-only), a clean git status, and a restored blob matching the HEAD blob 1f9ef52ee8

Verification

• pnpm --filter '@objectstack/metadata^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/metadata test — Test Files 38 passed (38), Tests 628 passed (628)
• gate family derived by node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack at 3fc4e3bf24 (34 commands, path-derived plus the test-file convention kind): 33 exit 0, 1 NOT MEASURED — node scripts/check-test-completeness.mjs exits 3 with no test-run log to read, which its own output states is not a red and not a finding
• pnpm check:type-check-debt re-measured 29 ledger entries at this head and reports surplus: none — every entry sits exactly at its measurement, so any new error is red, so the new test code adds zero tsc errors to @objectstack/metadata's frozen 89
• pnpm check:dual-build-cjs-loads and pnpm check:type-check-debt both needed a built workspace (turbo run build --filter='./packages/*' --filter='./packages/*/*', 70/70 successful) and were re-run green afterwards rather than left at their exit-3 prerequisite state

ESLint — a declared narrowing, measured on three counts rather than skipped. Run on the changed files only, --no-inline-config --format json: 0 errors, 0 warnings.

1. The population is read from ESLint's own config, not guessed: --print-config resolves a real config for both .ts files (6 and 5 active rules), and ESLint itself reports the changeset as File ignored because no matching configuration was supplied.
2. The file count is read from --format json: 3 result objects, 2 linted, 1 ignored.
3. Untouched files cannot move: --print-config shows no parserOptions.project on either file, and eslint.config.mjs:328 records — measured with a positive control — that this repo never enables type-aware linting ... for ANY file. Every file's verdict therefore depends only on its own bytes and the shared config, and this diff changes neither the config nor any other file.

Readings the card asked for

• Has any deployment already run this migration against PG/MySQL — the data half.Cannot be ruled out, so the data half stays open and this PR writes no backfill. The repo keeps no record that could answer it: the migration has no caller anywhere (no CLI command, no boot hook — docs/handoff/adr-0030-notification-convergence.md labels it "Data migration (not auto-run)" and hands operators a manual cut-over sequence), and it is not in the sys_migration ledger — the well-known ids are only adr-0104-file-references and adr-0104-value-shapes. Meanwhile it is published: migrateSysNotificationToEvent appears in seven package CHANGELOGs. What narrows the population is the finding below: no driver in this repo defines .raw, so the documented call errors out before touching data. That leaves only an operator who passed a knex-like handle of their own, which the repo cannot see either way.
• Which failure shape occurs on a live server — accepted-and-skewed, or rejected mid-run.NOT MEASURED.OS_TEST_POSTGRES_URL and OS_TEST_MYSQL_URL are unset and nothing is listening in this container, so no live dialect was reachable. The fix is safe under either shape: it removes the input to both, since the value written is canonical ISO text on every dialect. The JavaScript half that needs no server — that String(Date) drops the milliseconds and bakes the process zone — is measured in the pin.
• Does read_at share the defect, and by which gate. Yes, and by a different gate than created_at — the two bullets above. Both are covered by the fix.
• Any sibling migration with the same shape. No. The card's expression over packages/metadata/src/migrations/ returns the two lines in this file and nothing else; widened to String\((row|r|legacy|old)\.[A-Za-z_]*_at\b across all of packages, the other hits are read-side sites already accounted for by the [finding] Sweep: which consumers compare or format a value whose runtime type differs between the Date-materialising drivers and the ISO-text ones #13973 census family (objectql/engine.ts, rest-server.ts, platform-objects/system/migration-flag.ts, metadata-protocol/protocol.ts, cli/commands/migrate/duplicates.ts) plus services/service-queue/src/db-queue-adapter.ts:262. The three other files in this migrations directory contain no _at reference at all.

Out-of-scope finding, filed not folded

#14023 — every migration in packages/metadata/src/migrations/ requires driver.raw(...), and no driver in this repo defines that method; they all expose execute(). Deduped against the backlog first. Different defect class, so it is not repaired here, and #14023 remains open on its own terms.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

2 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 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.

Coarse fallback — 12 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 c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from c98582dd0e0827bc597c495fd557b1dbd2730b24 — the merge of head 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b into base c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37, 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 c98582dd0e0827bc597c495fd557b1dbd2730b24 && git checkout c98582dd0e0827bc597c495fd557b1dbd2730b24
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b && git checkout -B drift-repro c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 && git merge --no-ff 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b
node scripts/docs-audit/affected-docs.mjs --json c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37

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

[zhuangjianguo]

Part of #13998 — the code half only. The data half of that card (whether any deployment has already run this migration against Postgres or MySQL, and therefore whether a backfill is owed) is unanswered and is a maintainer floor, so this PR deliberately does not carry a closing keyword. Reading below.

All gates and tests quoted here were run at 3fc4e3bf24, which is this branch's head.

What was wrong

selectLegacyRows reads the legacy sys_notification table through driver.raw/execute, and the migration then wrote

constcreatedAt=row.created_at!=null ? String(row.created_at) : now();at: isRead&&row.read_at!=null ? String(row.read_at) : createdAt,

into created_at on the new sys_inbox_message row and into created_at / at on the new sys_notification_receipt row. On Postgres and MySQL an instant column materialises as a JS Date, so String(...) spells

Sun Aug 30 2026 18:19:25 GMT+0800 (China Standard Time)

— whole seconds in the migrating host's zone, milliseconds dropped, and a trailing zone name that is in no dialect's timestamp grammar. This migration is one-way, so that spelling is what the platform carries afterwards.

The fix

One canonicaliser, applied at both sites, matching the repo's existing correct form (metadata-protocol/src/protocol.ts, the occurred_at read in readMetadataAuditEvents):

functioncanonicalTimestampText(value: unknown): string{if(typeofvalue==='string')returnvalue;if(valueinstanceofDate)returnvalue.toISOString();returnString(value);}

Route A of #13973 (canonicalise at the migration), as triaged — not the driver-side read-door normalisation, and not a tolerant ?? fallback. A Date and ISO text are two materialisations of one instant, not two spellings of a key. Anything that is neither a string nor a Date keeps its previous String() rendering unchanged rather than having a unit guessed for it on a one-way write path; widening that would be a second, unevidenced decision.

Why neither column could be repaired further upstream

This read path bypasses formatOutput entirely — execute() returns await builder untouched, the same class of bypass sql-driver.ts:3964-3965 already names for aggregate and distinct. Even at the record read door the two columns diverge by different gates, and neither one closes:

• created_at is a builtin audit column, so it is never in datetimeFields and no declared-field coercion reaches it; formatOutput repairs it only inside its if (this.isSqlite) arm (repairNaiveUtcAuditTimestamp over AUDIT_TIMESTAMP_COLUMNS = ['created_at', 'updated_at'], sql-driver.ts:269).
• read_at is a legacy column ADR-0030 removed from the object, so it is not a declared Field.datetime either — datetimeFields is built from declared datetime columns, and read_at appears nowhere in packages/platform-objects/src today. No arm of formatOutput could reach it on any dialect.

The pin, and why it is the real content here

The defect was invisible because this migration's tests drive SQLite/memory shapes, where the legacy stamps are already canonical ISO text and String(row.created_at) is the identity. The new cases break that identity by feeding a hand-made Date — the discriminating input — through the migration's read path under a forced process zone. @objectstack/metadata has no driver dependency and must not grow one, so a hand-made Date is the right instrument, exactly as the OCC seam's own suite uses one.

They live in the existing test file and reuse its already-pinned engine doubles, so check:engine-double-contract's ledger is untouched.

Ablation, on the committed tree, no rebuild leg (the pin imports ./migrate-sys-notification-to-event.js relatively, so vitest resolves source; dist/ is not on this path — stated rather than fabricated):

• mutation proven on disk in both directions — injected String(row.created_at) / String(row.read_at) count 2, removed canonicalTimestampText(row. count 0 — and by blob: 1f9ef52ee8 to fb4534c3e5
• result: Tests 1 failed | 7 passed (8), failing precisely on the new case with AssertionError: inbox.created_at must be canonical ISO-Z: expected 'Sun Aug 30 2026 18:19:25 GMT+0800 (Ch…' to match /^\d{4}-\d{2}-\d{2}T…/ — the production spelling, reproduced
• the other 7 cases stayed green under the mutation, which is the SQLite identity demonstrated rather than asserted
• restore under trap ... EXIT INT TERM with absolute paths, proven by an empty git diff HEAD (0 bytes from --name-only), a clean git status, and a restored blob matching the HEAD blob 1f9ef52ee8

Verification

• pnpm --filter '@objectstack/metadata^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/metadata test — Test Files 38 passed (38), Tests 628 passed (628)
• gate family derived by node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack at 3fc4e3bf24 (34 commands, path-derived plus the test-file convention kind): 33 exit 0, 1 NOT MEASURED — node scripts/check-test-completeness.mjs exits 3 with no test-run log to read, which its own output states is not a red and not a finding
• pnpm check:type-check-debt re-measured 29 ledger entries at this head and reports surplus: none — every entry sits exactly at its measurement, so any new error is red, so the new test code adds zero tsc errors to @objectstack/metadata's frozen 89
• pnpm check:dual-build-cjs-loads and pnpm check:type-check-debt both needed a built workspace (turbo run build --filter='./packages/*' --filter='./packages/*/*', 70/70 successful) and were re-run green afterwards rather than left at their exit-3 prerequisite state

ESLint — a declared narrowing, measured on three counts rather than skipped. Run on the changed files only, --no-inline-config --format json: 0 errors, 0 warnings.

1. The population is read from ESLint's own config, not guessed: --print-config resolves a real config for both .ts files (6 and 5 active rules), and ESLint itself reports the changeset as File ignored because no matching configuration was supplied.
2. The file count is read from --format json: 3 result objects, 2 linted, 1 ignored.
3. Untouched files cannot move: --print-config shows no parserOptions.project on either file, and eslint.config.mjs:328 records — measured with a positive control — that this repo never enables type-aware linting ... for ANY file. Every file's verdict therefore depends only on its own bytes and the shared config, and this diff changes neither the config nor any other file.

Readings the card asked for

• Has any deployment already run this migration against PG/MySQL — the data half.Cannot be ruled out, so the data half stays open and this PR writes no backfill. The repo keeps no record that could answer it: the migration has no caller anywhere (no CLI command, no boot hook — docs/handoff/adr-0030-notification-convergence.md labels it "Data migration (not auto-run)" and hands operators a manual cut-over sequence), and it is not in the sys_migration ledger — the well-known ids are only adr-0104-file-references and adr-0104-value-shapes. Meanwhile it is published: migrateSysNotificationToEvent appears in seven package CHANGELOGs. What narrows the population is the finding below: no driver in this repo defines .raw, so the documented call errors out before touching data. That leaves only an operator who passed a knex-like handle of their own, which the repo cannot see either way.
• Which failure shape occurs on a live server — accepted-and-skewed, or rejected mid-run.NOT MEASURED.OS_TEST_POSTGRES_URL and OS_TEST_MYSQL_URL are unset and nothing is listening in this container, so no live dialect was reachable. The fix is safe under either shape: it removes the input to both, since the value written is canonical ISO text on every dialect. The JavaScript half that needs no server — that String(Date) drops the milliseconds and bakes the process zone — is measured in the pin.
• Does read_at share the defect, and by which gate. Yes, and by a different gate than created_at — the two bullets above. Both are covered by the fix.
• Any sibling migration with the same shape. No. The card's expression over packages/metadata/src/migrations/ returns the two lines in this file and nothing else; widened to String\((row|r|legacy|old)\.[A-Za-z_]*_at\b across all of packages, the other hits are read-side sites already accounted for by the [finding] Sweep: which consumers compare or format a value whose runtime type differs between the Date-materialising drivers and the ISO-text ones #13973 census family (objectql/engine.ts, rest-server.ts, platform-objects/system/migration-flag.ts, metadata-protocol/protocol.ts, cli/commands/migrate/duplicates.ts) plus services/service-queue/src/db-queue-adapter.ts:262. The three other files in this migrations directory contain no _at reference at all.

Out-of-scope finding, filed not folded

#14023 — every migration in packages/metadata/src/migrations/ requires driver.raw(...), and no driver in this repo defines that method; they all expose execute(). Deduped against the backlog first. Different defect class, so it is not repaired here, and #14023 remains open on its own terms.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

2 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 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.

Coarse fallback — 12 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 c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from c98582dd0e0827bc597c495fd557b1dbd2730b24 — the merge of head 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b into base c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37, 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 c98582dd0e0827bc597c495fd557b1dbd2730b24 && git checkout c98582dd0e0827bc597c495fd557b1dbd2730b24
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b && git checkout -B drift-repro c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 && git merge --no-ff 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b
node scripts/docs-audit/affected-docs.mjs --json c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37

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

[zhuangjianguo]

Part of #13998 — the code half only. The data half of that card (whether any deployment has already run this migration against Postgres or MySQL, and therefore whether a backfill is owed) is unanswered and is a maintainer floor, so this PR deliberately does not carry a closing keyword. Reading below.

All gates and tests quoted here were run at 3fc4e3bf24, which is this branch's head.

What was wrong

selectLegacyRows reads the legacy sys_notification table through driver.raw/execute, and the migration then wrote

constcreatedAt=row.created_at!=null ? String(row.created_at) : now();at: isRead&&row.read_at!=null ? String(row.read_at) : createdAt,

into created_at on the new sys_inbox_message row and into created_at / at on the new sys_notification_receipt row. On Postgres and MySQL an instant column materialises as a JS Date, so String(...) spells

Sun Aug 30 2026 18:19:25 GMT+0800 (China Standard Time)

— whole seconds in the migrating host's zone, milliseconds dropped, and a trailing zone name that is in no dialect's timestamp grammar. This migration is one-way, so that spelling is what the platform carries afterwards.

The fix

One canonicaliser, applied at both sites, matching the repo's existing correct form (metadata-protocol/src/protocol.ts, the occurred_at read in readMetadataAuditEvents):

functioncanonicalTimestampText(value: unknown): string{if(typeofvalue==='string')returnvalue;if(valueinstanceofDate)returnvalue.toISOString();returnString(value);}

Route A of #13973 (canonicalise at the migration), as triaged — not the driver-side read-door normalisation, and not a tolerant ?? fallback. A Date and ISO text are two materialisations of one instant, not two spellings of a key. Anything that is neither a string nor a Date keeps its previous String() rendering unchanged rather than having a unit guessed for it on a one-way write path; widening that would be a second, unevidenced decision.

Why neither column could be repaired further upstream

This read path bypasses formatOutput entirely — execute() returns await builder untouched, the same class of bypass sql-driver.ts:3964-3965 already names for aggregate and distinct. Even at the record read door the two columns diverge by different gates, and neither one closes:

• created_at is a builtin audit column, so it is never in datetimeFields and no declared-field coercion reaches it; formatOutput repairs it only inside its if (this.isSqlite) arm (repairNaiveUtcAuditTimestamp over AUDIT_TIMESTAMP_COLUMNS = ['created_at', 'updated_at'], sql-driver.ts:269).
• read_at is a legacy column ADR-0030 removed from the object, so it is not a declared Field.datetime either — datetimeFields is built from declared datetime columns, and read_at appears nowhere in packages/platform-objects/src today. No arm of formatOutput could reach it on any dialect.

The pin, and why it is the real content here

The defect was invisible because this migration's tests drive SQLite/memory shapes, where the legacy stamps are already canonical ISO text and String(row.created_at) is the identity. The new cases break that identity by feeding a hand-made Date — the discriminating input — through the migration's read path under a forced process zone. @objectstack/metadata has no driver dependency and must not grow one, so a hand-made Date is the right instrument, exactly as the OCC seam's own suite uses one.

They live in the existing test file and reuse its already-pinned engine doubles, so check:engine-double-contract's ledger is untouched.

Ablation, on the committed tree, no rebuild leg (the pin imports ./migrate-sys-notification-to-event.js relatively, so vitest resolves source; dist/ is not on this path — stated rather than fabricated):

• mutation proven on disk in both directions — injected String(row.created_at) / String(row.read_at) count 2, removed canonicalTimestampText(row. count 0 — and by blob: 1f9ef52ee8 to fb4534c3e5
• result: Tests 1 failed | 7 passed (8), failing precisely on the new case with AssertionError: inbox.created_at must be canonical ISO-Z: expected 'Sun Aug 30 2026 18:19:25 GMT+0800 (Ch…' to match /^\d{4}-\d{2}-\d{2}T…/ — the production spelling, reproduced
• the other 7 cases stayed green under the mutation, which is the SQLite identity demonstrated rather than asserted
• restore under trap ... EXIT INT TERM with absolute paths, proven by an empty git diff HEAD (0 bytes from --name-only), a clean git status, and a restored blob matching the HEAD blob 1f9ef52ee8

Verification

• pnpm --filter '@objectstack/metadata^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/metadata test — Test Files 38 passed (38), Tests 628 passed (628)
• gate family derived by node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack at 3fc4e3bf24 (34 commands, path-derived plus the test-file convention kind): 33 exit 0, 1 NOT MEASURED — node scripts/check-test-completeness.mjs exits 3 with no test-run log to read, which its own output states is not a red and not a finding
• pnpm check:type-check-debt re-measured 29 ledger entries at this head and reports surplus: none — every entry sits exactly at its measurement, so any new error is red, so the new test code adds zero tsc errors to @objectstack/metadata's frozen 89
• pnpm check:dual-build-cjs-loads and pnpm check:type-check-debt both needed a built workspace (turbo run build --filter='./packages/*' --filter='./packages/*/*', 70/70 successful) and were re-run green afterwards rather than left at their exit-3 prerequisite state

ESLint — a declared narrowing, measured on three counts rather than skipped. Run on the changed files only, --no-inline-config --format json: 0 errors, 0 warnings.

1. The population is read from ESLint's own config, not guessed: --print-config resolves a real config for both .ts files (6 and 5 active rules), and ESLint itself reports the changeset as File ignored because no matching configuration was supplied.
2. The file count is read from --format json: 3 result objects, 2 linted, 1 ignored.
3. Untouched files cannot move: --print-config shows no parserOptions.project on either file, and eslint.config.mjs:328 records — measured with a positive control — that this repo never enables type-aware linting ... for ANY file. Every file's verdict therefore depends only on its own bytes and the shared config, and this diff changes neither the config nor any other file.

Readings the card asked for

• Has any deployment already run this migration against PG/MySQL — the data half.Cannot be ruled out, so the data half stays open and this PR writes no backfill. The repo keeps no record that could answer it: the migration has no caller anywhere (no CLI command, no boot hook — docs/handoff/adr-0030-notification-convergence.md labels it "Data migration (not auto-run)" and hands operators a manual cut-over sequence), and it is not in the sys_migration ledger — the well-known ids are only adr-0104-file-references and adr-0104-value-shapes. Meanwhile it is published: migrateSysNotificationToEvent appears in seven package CHANGELOGs. What narrows the population is the finding below: no driver in this repo defines .raw, so the documented call errors out before touching data. That leaves only an operator who passed a knex-like handle of their own, which the repo cannot see either way.
• Which failure shape occurs on a live server — accepted-and-skewed, or rejected mid-run.NOT MEASURED.OS_TEST_POSTGRES_URL and OS_TEST_MYSQL_URL are unset and nothing is listening in this container, so no live dialect was reachable. The fix is safe under either shape: it removes the input to both, since the value written is canonical ISO text on every dialect. The JavaScript half that needs no server — that String(Date) drops the milliseconds and bakes the process zone — is measured in the pin.
• Does read_at share the defect, and by which gate. Yes, and by a different gate than created_at — the two bullets above. Both are covered by the fix.
• Any sibling migration with the same shape. No. The card's expression over packages/metadata/src/migrations/ returns the two lines in this file and nothing else; widened to String\((row|r|legacy|old)\.[A-Za-z_]*_at\b across all of packages, the other hits are read-side sites already accounted for by the [finding] Sweep: which consumers compare or format a value whose runtime type differs between the Date-materialising drivers and the ISO-text ones #13973 census family (objectql/engine.ts, rest-server.ts, platform-objects/system/migration-flag.ts, metadata-protocol/protocol.ts, cli/commands/migrate/duplicates.ts) plus services/service-queue/src/db-queue-adapter.ts:262. The three other files in this migrations directory contain no _at reference at all.

Out-of-scope finding, filed not folded

#14023 — every migration in packages/metadata/src/migrations/ requires driver.raw(...), and no driver in this repo defines that method; they all expose execute(). Deduped against the backlog first. Different defect class, so it is not repaired here, and #14023 remains open on its own terms.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

2 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 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.

Coarse fallback — 12 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 c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from c98582dd0e0827bc597c495fd557b1dbd2730b24 — the merge of head 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b into base c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37, 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 c98582dd0e0827bc597c495fd557b1dbd2730b24 && git checkout c98582dd0e0827bc597c495fd557b1dbd2730b24
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b && git checkout -B drift-repro c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 && git merge --no-ff 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b
node scripts/docs-audit/affected-docs.mjs --json c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37

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

[zhuangjianguo]

Part of #13998 — the code half only. The data half of that card (whether any deployment has already run this migration against Postgres or MySQL, and therefore whether a backfill is owed) is unanswered and is a maintainer floor, so this PR deliberately does not carry a closing keyword. Reading below.

All gates and tests quoted here were run at 3fc4e3bf24, which is this branch's head.

What was wrong

selectLegacyRows reads the legacy sys_notification table through driver.raw/execute, and the migration then wrote

constcreatedAt=row.created_at!=null ? String(row.created_at) : now();at: isRead&&row.read_at!=null ? String(row.read_at) : createdAt,

into created_at on the new sys_inbox_message row and into created_at / at on the new sys_notification_receipt row. On Postgres and MySQL an instant column materialises as a JS Date, so String(...) spells

Sun Aug 30 2026 18:19:25 GMT+0800 (China Standard Time)

— whole seconds in the migrating host's zone, milliseconds dropped, and a trailing zone name that is in no dialect's timestamp grammar. This migration is one-way, so that spelling is what the platform carries afterwards.

The fix

One canonicaliser, applied at both sites, matching the repo's existing correct form (metadata-protocol/src/protocol.ts, the occurred_at read in readMetadataAuditEvents):

functioncanonicalTimestampText(value: unknown): string{if(typeofvalue==='string')returnvalue;if(valueinstanceofDate)returnvalue.toISOString();returnString(value);}

Route A of #13973 (canonicalise at the migration), as triaged — not the driver-side read-door normalisation, and not a tolerant ?? fallback. A Date and ISO text are two materialisations of one instant, not two spellings of a key. Anything that is neither a string nor a Date keeps its previous String() rendering unchanged rather than having a unit guessed for it on a one-way write path; widening that would be a second, unevidenced decision.

Why neither column could be repaired further upstream

This read path bypasses formatOutput entirely — execute() returns await builder untouched, the same class of bypass sql-driver.ts:3964-3965 already names for aggregate and distinct. Even at the record read door the two columns diverge by different gates, and neither one closes:

• created_at is a builtin audit column, so it is never in datetimeFields and no declared-field coercion reaches it; formatOutput repairs it only inside its if (this.isSqlite) arm (repairNaiveUtcAuditTimestamp over AUDIT_TIMESTAMP_COLUMNS = ['created_at', 'updated_at'], sql-driver.ts:269).
• read_at is a legacy column ADR-0030 removed from the object, so it is not a declared Field.datetime either — datetimeFields is built from declared datetime columns, and read_at appears nowhere in packages/platform-objects/src today. No arm of formatOutput could reach it on any dialect.

The pin, and why it is the real content here

The defect was invisible because this migration's tests drive SQLite/memory shapes, where the legacy stamps are already canonical ISO text and String(row.created_at) is the identity. The new cases break that identity by feeding a hand-made Date — the discriminating input — through the migration's read path under a forced process zone. @objectstack/metadata has no driver dependency and must not grow one, so a hand-made Date is the right instrument, exactly as the OCC seam's own suite uses one.

They live in the existing test file and reuse its already-pinned engine doubles, so check:engine-double-contract's ledger is untouched.

Ablation, on the committed tree, no rebuild leg (the pin imports ./migrate-sys-notification-to-event.js relatively, so vitest resolves source; dist/ is not on this path — stated rather than fabricated):

• mutation proven on disk in both directions — injected String(row.created_at) / String(row.read_at) count 2, removed canonicalTimestampText(row. count 0 — and by blob: 1f9ef52ee8 to fb4534c3e5
• result: Tests 1 failed | 7 passed (8), failing precisely on the new case with AssertionError: inbox.created_at must be canonical ISO-Z: expected 'Sun Aug 30 2026 18:19:25 GMT+0800 (Ch…' to match /^\d{4}-\d{2}-\d{2}T…/ — the production spelling, reproduced
• the other 7 cases stayed green under the mutation, which is the SQLite identity demonstrated rather than asserted
• restore under trap ... EXIT INT TERM with absolute paths, proven by an empty git diff HEAD (0 bytes from --name-only), a clean git status, and a restored blob matching the HEAD blob 1f9ef52ee8

Verification

• pnpm --filter '@objectstack/metadata^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/metadata test — Test Files 38 passed (38), Tests 628 passed (628)
• gate family derived by node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack at 3fc4e3bf24 (34 commands, path-derived plus the test-file convention kind): 33 exit 0, 1 NOT MEASURED — node scripts/check-test-completeness.mjs exits 3 with no test-run log to read, which its own output states is not a red and not a finding
• pnpm check:type-check-debt re-measured 29 ledger entries at this head and reports surplus: none — every entry sits exactly at its measurement, so any new error is red, so the new test code adds zero tsc errors to @objectstack/metadata's frozen 89
• pnpm check:dual-build-cjs-loads and pnpm check:type-check-debt both needed a built workspace (turbo run build --filter='./packages/*' --filter='./packages/*/*', 70/70 successful) and were re-run green afterwards rather than left at their exit-3 prerequisite state

ESLint — a declared narrowing, measured on three counts rather than skipped. Run on the changed files only, --no-inline-config --format json: 0 errors, 0 warnings.

1. The population is read from ESLint's own config, not guessed: --print-config resolves a real config for both .ts files (6 and 5 active rules), and ESLint itself reports the changeset as File ignored because no matching configuration was supplied.
2. The file count is read from --format json: 3 result objects, 2 linted, 1 ignored.
3. Untouched files cannot move: --print-config shows no parserOptions.project on either file, and eslint.config.mjs:328 records — measured with a positive control — that this repo never enables type-aware linting ... for ANY file. Every file's verdict therefore depends only on its own bytes and the shared config, and this diff changes neither the config nor any other file.

Readings the card asked for

• Has any deployment already run this migration against PG/MySQL — the data half.Cannot be ruled out, so the data half stays open and this PR writes no backfill. The repo keeps no record that could answer it: the migration has no caller anywhere (no CLI command, no boot hook — docs/handoff/adr-0030-notification-convergence.md labels it "Data migration (not auto-run)" and hands operators a manual cut-over sequence), and it is not in the sys_migration ledger — the well-known ids are only adr-0104-file-references and adr-0104-value-shapes. Meanwhile it is published: migrateSysNotificationToEvent appears in seven package CHANGELOGs. What narrows the population is the finding below: no driver in this repo defines .raw, so the documented call errors out before touching data. That leaves only an operator who passed a knex-like handle of their own, which the repo cannot see either way.
• Which failure shape occurs on a live server — accepted-and-skewed, or rejected mid-run.NOT MEASURED.OS_TEST_POSTGRES_URL and OS_TEST_MYSQL_URL are unset and nothing is listening in this container, so no live dialect was reachable. The fix is safe under either shape: it removes the input to both, since the value written is canonical ISO text on every dialect. The JavaScript half that needs no server — that String(Date) drops the milliseconds and bakes the process zone — is measured in the pin.
• Does read_at share the defect, and by which gate. Yes, and by a different gate than created_at — the two bullets above. Both are covered by the fix.
• Any sibling migration with the same shape. No. The card's expression over packages/metadata/src/migrations/ returns the two lines in this file and nothing else; widened to String\((row|r|legacy|old)\.[A-Za-z_]*_at\b across all of packages, the other hits are read-side sites already accounted for by the [finding] Sweep: which consumers compare or format a value whose runtime type differs between the Date-materialising drivers and the ISO-text ones #13973 census family (objectql/engine.ts, rest-server.ts, platform-objects/system/migration-flag.ts, metadata-protocol/protocol.ts, cli/commands/migrate/duplicates.ts) plus services/service-queue/src/db-queue-adapter.ts:262. The three other files in this migrations directory contain no _at reference at all.

Out-of-scope finding, filed not folded

#14023 — every migration in packages/metadata/src/migrations/ requires driver.raw(...), and no driver in this repo defines that method; they all expose execute(). Deduped against the backlog first. Different defect class, so it is not repaired here, and #14023 remains open on its own terms.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

2 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 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.

Coarse fallback — 12 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 c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from c98582dd0e0827bc597c495fd557b1dbd2730b24 — the merge of head 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b into base c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37, 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 c98582dd0e0827bc597c495fd557b1dbd2730b24 && git checkout c98582dd0e0827bc597c495fd557b1dbd2730b24
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b && git checkout -B drift-repro c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 && git merge --no-ff 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b
node scripts/docs-audit/affected-docs.mjs --json c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37

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

[zhuangjianguo]

Part of #13998 — the code half only. The data half of that card (whether any deployment has already run this migration against Postgres or MySQL, and therefore whether a backfill is owed) is unanswered and is a maintainer floor, so this PR deliberately does not carry a closing keyword. Reading below.

All gates and tests quoted here were run at 3fc4e3bf24, which is this branch's head.

What was wrong

selectLegacyRows reads the legacy sys_notification table through driver.raw/execute, and the migration then wrote

constcreatedAt=row.created_at!=null ? String(row.created_at) : now();at: isRead&&row.read_at!=null ? String(row.read_at) : createdAt,

into created_at on the new sys_inbox_message row and into created_at / at on the new sys_notification_receipt row. On Postgres and MySQL an instant column materialises as a JS Date, so String(...) spells

Sun Aug 30 2026 18:19:25 GMT+0800 (China Standard Time)

— whole seconds in the migrating host's zone, milliseconds dropped, and a trailing zone name that is in no dialect's timestamp grammar. This migration is one-way, so that spelling is what the platform carries afterwards.

The fix

One canonicaliser, applied at both sites, matching the repo's existing correct form (metadata-protocol/src/protocol.ts, the occurred_at read in readMetadataAuditEvents):

functioncanonicalTimestampText(value: unknown): string{if(typeofvalue==='string')returnvalue;if(valueinstanceofDate)returnvalue.toISOString();returnString(value);}

Route A of #13973 (canonicalise at the migration), as triaged — not the driver-side read-door normalisation, and not a tolerant ?? fallback. A Date and ISO text are two materialisations of one instant, not two spellings of a key. Anything that is neither a string nor a Date keeps its previous String() rendering unchanged rather than having a unit guessed for it on a one-way write path; widening that would be a second, unevidenced decision.

Why neither column could be repaired further upstream

This read path bypasses formatOutput entirely — execute() returns await builder untouched, the same class of bypass sql-driver.ts:3964-3965 already names for aggregate and distinct. Even at the record read door the two columns diverge by different gates, and neither one closes:

• created_at is a builtin audit column, so it is never in datetimeFields and no declared-field coercion reaches it; formatOutput repairs it only inside its if (this.isSqlite) arm (repairNaiveUtcAuditTimestamp over AUDIT_TIMESTAMP_COLUMNS = ['created_at', 'updated_at'], sql-driver.ts:269).
• read_at is a legacy column ADR-0030 removed from the object, so it is not a declared Field.datetime either — datetimeFields is built from declared datetime columns, and read_at appears nowhere in packages/platform-objects/src today. No arm of formatOutput could reach it on any dialect.

The pin, and why it is the real content here

The defect was invisible because this migration's tests drive SQLite/memory shapes, where the legacy stamps are already canonical ISO text and String(row.created_at) is the identity. The new cases break that identity by feeding a hand-made Date — the discriminating input — through the migration's read path under a forced process zone. @objectstack/metadata has no driver dependency and must not grow one, so a hand-made Date is the right instrument, exactly as the OCC seam's own suite uses one.

They live in the existing test file and reuse its already-pinned engine doubles, so check:engine-double-contract's ledger is untouched.

Ablation, on the committed tree, no rebuild leg (the pin imports ./migrate-sys-notification-to-event.js relatively, so vitest resolves source; dist/ is not on this path — stated rather than fabricated):

• mutation proven on disk in both directions — injected String(row.created_at) / String(row.read_at) count 2, removed canonicalTimestampText(row. count 0 — and by blob: 1f9ef52ee8 to fb4534c3e5
• result: Tests 1 failed | 7 passed (8), failing precisely on the new case with AssertionError: inbox.created_at must be canonical ISO-Z: expected 'Sun Aug 30 2026 18:19:25 GMT+0800 (Ch…' to match /^\d{4}-\d{2}-\d{2}T…/ — the production spelling, reproduced
• the other 7 cases stayed green under the mutation, which is the SQLite identity demonstrated rather than asserted
• restore under trap ... EXIT INT TERM with absolute paths, proven by an empty git diff HEAD (0 bytes from --name-only), a clean git status, and a restored blob matching the HEAD blob 1f9ef52ee8

Verification

• pnpm --filter '@objectstack/metadata^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/metadata test — Test Files 38 passed (38), Tests 628 passed (628)
• gate family derived by node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack at 3fc4e3bf24 (34 commands, path-derived plus the test-file convention kind): 33 exit 0, 1 NOT MEASURED — node scripts/check-test-completeness.mjs exits 3 with no test-run log to read, which its own output states is not a red and not a finding
• pnpm check:type-check-debt re-measured 29 ledger entries at this head and reports surplus: none — every entry sits exactly at its measurement, so any new error is red, so the new test code adds zero tsc errors to @objectstack/metadata's frozen 89
• pnpm check:dual-build-cjs-loads and pnpm check:type-check-debt both needed a built workspace (turbo run build --filter='./packages/*' --filter='./packages/*/*', 70/70 successful) and were re-run green afterwards rather than left at their exit-3 prerequisite state

ESLint — a declared narrowing, measured on three counts rather than skipped. Run on the changed files only, --no-inline-config --format json: 0 errors, 0 warnings.

1. The population is read from ESLint's own config, not guessed: --print-config resolves a real config for both .ts files (6 and 5 active rules), and ESLint itself reports the changeset as File ignored because no matching configuration was supplied.
2. The file count is read from --format json: 3 result objects, 2 linted, 1 ignored.
3. Untouched files cannot move: --print-config shows no parserOptions.project on either file, and eslint.config.mjs:328 records — measured with a positive control — that this repo never enables type-aware linting ... for ANY file. Every file's verdict therefore depends only on its own bytes and the shared config, and this diff changes neither the config nor any other file.

Readings the card asked for

• Has any deployment already run this migration against PG/MySQL — the data half.Cannot be ruled out, so the data half stays open and this PR writes no backfill. The repo keeps no record that could answer it: the migration has no caller anywhere (no CLI command, no boot hook — docs/handoff/adr-0030-notification-convergence.md labels it "Data migration (not auto-run)" and hands operators a manual cut-over sequence), and it is not in the sys_migration ledger — the well-known ids are only adr-0104-file-references and adr-0104-value-shapes. Meanwhile it is published: migrateSysNotificationToEvent appears in seven package CHANGELOGs. What narrows the population is the finding below: no driver in this repo defines .raw, so the documented call errors out before touching data. That leaves only an operator who passed a knex-like handle of their own, which the repo cannot see either way.
• Which failure shape occurs on a live server — accepted-and-skewed, or rejected mid-run.NOT MEASURED.OS_TEST_POSTGRES_URL and OS_TEST_MYSQL_URL are unset and nothing is listening in this container, so no live dialect was reachable. The fix is safe under either shape: it removes the input to both, since the value written is canonical ISO text on every dialect. The JavaScript half that needs no server — that String(Date) drops the milliseconds and bakes the process zone — is measured in the pin.
• Does read_at share the defect, and by which gate. Yes, and by a different gate than created_at — the two bullets above. Both are covered by the fix.
• Any sibling migration with the same shape. No. The card's expression over packages/metadata/src/migrations/ returns the two lines in this file and nothing else; widened to String\((row|r|legacy|old)\.[A-Za-z_]*_at\b across all of packages, the other hits are read-side sites already accounted for by the [finding] Sweep: which consumers compare or format a value whose runtime type differs between the Date-materialising drivers and the ISO-text ones #13973 census family (objectql/engine.ts, rest-server.ts, platform-objects/system/migration-flag.ts, metadata-protocol/protocol.ts, cli/commands/migrate/duplicates.ts) plus services/service-queue/src/db-queue-adapter.ts:262. The three other files in this migrations directory contain no _at reference at all.

Out-of-scope finding, filed not folded

#14023 — every migration in packages/metadata/src/migrations/ requires driver.raw(...), and no driver in this repo defines that method; they all expose execute(). Deduped against the backlog first. Different defect class, so it is not repaired here, and #14023 remains open on its own terms.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

2 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 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.

Coarse fallback — 12 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 c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from c98582dd0e0827bc597c495fd557b1dbd2730b24 — the merge of head 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b into base c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37, 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 c98582dd0e0827bc597c495fd557b1dbd2730b24 && git checkout c98582dd0e0827bc597c495fd557b1dbd2730b24
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b && git checkout -B drift-repro c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 && git merge --no-ff 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b
node scripts/docs-audit/affected-docs.mjs --json c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37

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

[zhuangjianguo]

Part of #13998 — the code half only. The data half of that card (whether any deployment has already run this migration against Postgres or MySQL, and therefore whether a backfill is owed) is unanswered and is a maintainer floor, so this PR deliberately does not carry a closing keyword. Reading below.

All gates and tests quoted here were run at 3fc4e3bf24, which is this branch's head.

What was wrong

selectLegacyRows reads the legacy sys_notification table through driver.raw/execute, and the migration then wrote

constcreatedAt=row.created_at!=null ? String(row.created_at) : now();at: isRead&&row.read_at!=null ? String(row.read_at) : createdAt,

into created_at on the new sys_inbox_message row and into created_at / at on the new sys_notification_receipt row. On Postgres and MySQL an instant column materialises as a JS Date, so String(...) spells

Sun Aug 30 2026 18:19:25 GMT+0800 (China Standard Time)

— whole seconds in the migrating host's zone, milliseconds dropped, and a trailing zone name that is in no dialect's timestamp grammar. This migration is one-way, so that spelling is what the platform carries afterwards.

The fix

One canonicaliser, applied at both sites, matching the repo's existing correct form (metadata-protocol/src/protocol.ts, the occurred_at read in readMetadataAuditEvents):

functioncanonicalTimestampText(value: unknown): string{if(typeofvalue==='string')returnvalue;if(valueinstanceofDate)returnvalue.toISOString();returnString(value);}

Route A of #13973 (canonicalise at the migration), as triaged — not the driver-side read-door normalisation, and not a tolerant ?? fallback. A Date and ISO text are two materialisations of one instant, not two spellings of a key. Anything that is neither a string nor a Date keeps its previous String() rendering unchanged rather than having a unit guessed for it on a one-way write path; widening that would be a second, unevidenced decision.

Why neither column could be repaired further upstream

This read path bypasses formatOutput entirely — execute() returns await builder untouched, the same class of bypass sql-driver.ts:3964-3965 already names for aggregate and distinct. Even at the record read door the two columns diverge by different gates, and neither one closes:

• created_at is a builtin audit column, so it is never in datetimeFields and no declared-field coercion reaches it; formatOutput repairs it only inside its if (this.isSqlite) arm (repairNaiveUtcAuditTimestamp over AUDIT_TIMESTAMP_COLUMNS = ['created_at', 'updated_at'], sql-driver.ts:269).
• read_at is a legacy column ADR-0030 removed from the object, so it is not a declared Field.datetime either — datetimeFields is built from declared datetime columns, and read_at appears nowhere in packages/platform-objects/src today. No arm of formatOutput could reach it on any dialect.

The pin, and why it is the real content here

The defect was invisible because this migration's tests drive SQLite/memory shapes, where the legacy stamps are already canonical ISO text and String(row.created_at) is the identity. The new cases break that identity by feeding a hand-made Date — the discriminating input — through the migration's read path under a forced process zone. @objectstack/metadata has no driver dependency and must not grow one, so a hand-made Date is the right instrument, exactly as the OCC seam's own suite uses one.

They live in the existing test file and reuse its already-pinned engine doubles, so check:engine-double-contract's ledger is untouched.

Ablation, on the committed tree, no rebuild leg (the pin imports ./migrate-sys-notification-to-event.js relatively, so vitest resolves source; dist/ is not on this path — stated rather than fabricated):

• mutation proven on disk in both directions — injected String(row.created_at) / String(row.read_at) count 2, removed canonicalTimestampText(row. count 0 — and by blob: 1f9ef52ee8 to fb4534c3e5
• result: Tests 1 failed | 7 passed (8), failing precisely on the new case with AssertionError: inbox.created_at must be canonical ISO-Z: expected 'Sun Aug 30 2026 18:19:25 GMT+0800 (Ch…' to match /^\d{4}-\d{2}-\d{2}T…/ — the production spelling, reproduced
• the other 7 cases stayed green under the mutation, which is the SQLite identity demonstrated rather than asserted
• restore under trap ... EXIT INT TERM with absolute paths, proven by an empty git diff HEAD (0 bytes from --name-only), a clean git status, and a restored blob matching the HEAD blob 1f9ef52ee8

Verification

• pnpm --filter '@objectstack/metadata^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/metadata test — Test Files 38 passed (38), Tests 628 passed (628)
• gate family derived by node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack at 3fc4e3bf24 (34 commands, path-derived plus the test-file convention kind): 33 exit 0, 1 NOT MEASURED — node scripts/check-test-completeness.mjs exits 3 with no test-run log to read, which its own output states is not a red and not a finding
• pnpm check:type-check-debt re-measured 29 ledger entries at this head and reports surplus: none — every entry sits exactly at its measurement, so any new error is red, so the new test code adds zero tsc errors to @objectstack/metadata's frozen 89
• pnpm check:dual-build-cjs-loads and pnpm check:type-check-debt both needed a built workspace (turbo run build --filter='./packages/*' --filter='./packages/*/*', 70/70 successful) and were re-run green afterwards rather than left at their exit-3 prerequisite state

ESLint — a declared narrowing, measured on three counts rather than skipped. Run on the changed files only, --no-inline-config --format json: 0 errors, 0 warnings.

1. The population is read from ESLint's own config, not guessed: --print-config resolves a real config for both .ts files (6 and 5 active rules), and ESLint itself reports the changeset as File ignored because no matching configuration was supplied.
2. The file count is read from --format json: 3 result objects, 2 linted, 1 ignored.
3. Untouched files cannot move: --print-config shows no parserOptions.project on either file, and eslint.config.mjs:328 records — measured with a positive control — that this repo never enables type-aware linting ... for ANY file. Every file's verdict therefore depends only on its own bytes and the shared config, and this diff changes neither the config nor any other file.

Readings the card asked for

• Has any deployment already run this migration against PG/MySQL — the data half.Cannot be ruled out, so the data half stays open and this PR writes no backfill. The repo keeps no record that could answer it: the migration has no caller anywhere (no CLI command, no boot hook — docs/handoff/adr-0030-notification-convergence.md labels it "Data migration (not auto-run)" and hands operators a manual cut-over sequence), and it is not in the sys_migration ledger — the well-known ids are only adr-0104-file-references and adr-0104-value-shapes. Meanwhile it is published: migrateSysNotificationToEvent appears in seven package CHANGELOGs. What narrows the population is the finding below: no driver in this repo defines .raw, so the documented call errors out before touching data. That leaves only an operator who passed a knex-like handle of their own, which the repo cannot see either way.
• Which failure shape occurs on a live server — accepted-and-skewed, or rejected mid-run.NOT MEASURED.OS_TEST_POSTGRES_URL and OS_TEST_MYSQL_URL are unset and nothing is listening in this container, so no live dialect was reachable. The fix is safe under either shape: it removes the input to both, since the value written is canonical ISO text on every dialect. The JavaScript half that needs no server — that String(Date) drops the milliseconds and bakes the process zone — is measured in the pin.
• Does read_at share the defect, and by which gate. Yes, and by a different gate than created_at — the two bullets above. Both are covered by the fix.
• Any sibling migration with the same shape. No. The card's expression over packages/metadata/src/migrations/ returns the two lines in this file and nothing else; widened to String\((row|r|legacy|old)\.[A-Za-z_]*_at\b across all of packages, the other hits are read-side sites already accounted for by the [finding] Sweep: which consumers compare or format a value whose runtime type differs between the Date-materialising drivers and the ISO-text ones #13973 census family (objectql/engine.ts, rest-server.ts, platform-objects/system/migration-flag.ts, metadata-protocol/protocol.ts, cli/commands/migrate/duplicates.ts) plus services/service-queue/src/db-queue-adapter.ts:262. The three other files in this migrations directory contain no _at reference at all.

Out-of-scope finding, filed not folded

#14023 — every migration in packages/metadata/src/migrations/ requires driver.raw(...), and no driver in this repo defines that method; they all expose execute(). Deduped against the backlog first. Different defect class, so it is not repaired here, and #14023 remains open on its own terms.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

2 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 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.

Coarse fallback — 12 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 c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from c98582dd0e0827bc597c495fd557b1dbd2730b24 — the merge of head 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b into base c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37, 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 c98582dd0e0827bc597c495fd557b1dbd2730b24 && git checkout c98582dd0e0827bc597c495fd557b1dbd2730b24
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b && git checkout -B drift-repro c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 && git merge --no-ff 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b
node scripts/docs-audit/affected-docs.mjs --json c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37

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

[zhuangjianguo]

Part of #13998 — the code half only. The data half of that card (whether any deployment has already run this migration against Postgres or MySQL, and therefore whether a backfill is owed) is unanswered and is a maintainer floor, so this PR deliberately does not carry a closing keyword. Reading below.

All gates and tests quoted here were run at 3fc4e3bf24, which is this branch's head.

What was wrong

selectLegacyRows reads the legacy sys_notification table through driver.raw/execute, and the migration then wrote

constcreatedAt=row.created_at!=null ? String(row.created_at) : now();at: isRead&&row.read_at!=null ? String(row.read_at) : createdAt,

into created_at on the new sys_inbox_message row and into created_at / at on the new sys_notification_receipt row. On Postgres and MySQL an instant column materialises as a JS Date, so String(...) spells

Sun Aug 30 2026 18:19:25 GMT+0800 (China Standard Time)

— whole seconds in the migrating host's zone, milliseconds dropped, and a trailing zone name that is in no dialect's timestamp grammar. This migration is one-way, so that spelling is what the platform carries afterwards.

The fix

One canonicaliser, applied at both sites, matching the repo's existing correct form (metadata-protocol/src/protocol.ts, the occurred_at read in readMetadataAuditEvents):

functioncanonicalTimestampText(value: unknown): string{if(typeofvalue==='string')returnvalue;if(valueinstanceofDate)returnvalue.toISOString();returnString(value);}

Route A of #13973 (canonicalise at the migration), as triaged — not the driver-side read-door normalisation, and not a tolerant ?? fallback. A Date and ISO text are two materialisations of one instant, not two spellings of a key. Anything that is neither a string nor a Date keeps its previous String() rendering unchanged rather than having a unit guessed for it on a one-way write path; widening that would be a second, unevidenced decision.

Why neither column could be repaired further upstream

This read path bypasses formatOutput entirely — execute() returns await builder untouched, the same class of bypass sql-driver.ts:3964-3965 already names for aggregate and distinct. Even at the record read door the two columns diverge by different gates, and neither one closes:

• created_at is a builtin audit column, so it is never in datetimeFields and no declared-field coercion reaches it; formatOutput repairs it only inside its if (this.isSqlite) arm (repairNaiveUtcAuditTimestamp over AUDIT_TIMESTAMP_COLUMNS = ['created_at', 'updated_at'], sql-driver.ts:269).
• read_at is a legacy column ADR-0030 removed from the object, so it is not a declared Field.datetime either — datetimeFields is built from declared datetime columns, and read_at appears nowhere in packages/platform-objects/src today. No arm of formatOutput could reach it on any dialect.

The pin, and why it is the real content here

The defect was invisible because this migration's tests drive SQLite/memory shapes, where the legacy stamps are already canonical ISO text and String(row.created_at) is the identity. The new cases break that identity by feeding a hand-made Date — the discriminating input — through the migration's read path under a forced process zone. @objectstack/metadata has no driver dependency and must not grow one, so a hand-made Date is the right instrument, exactly as the OCC seam's own suite uses one.

They live in the existing test file and reuse its already-pinned engine doubles, so check:engine-double-contract's ledger is untouched.

Ablation, on the committed tree, no rebuild leg (the pin imports ./migrate-sys-notification-to-event.js relatively, so vitest resolves source; dist/ is not on this path — stated rather than fabricated):

• mutation proven on disk in both directions — injected String(row.created_at) / String(row.read_at) count 2, removed canonicalTimestampText(row. count 0 — and by blob: 1f9ef52ee8 to fb4534c3e5
• result: Tests 1 failed | 7 passed (8), failing precisely on the new case with AssertionError: inbox.created_at must be canonical ISO-Z: expected 'Sun Aug 30 2026 18:19:25 GMT+0800 (Ch…' to match /^\d{4}-\d{2}-\d{2}T…/ — the production spelling, reproduced
• the other 7 cases stayed green under the mutation, which is the SQLite identity demonstrated rather than asserted
• restore under trap ... EXIT INT TERM with absolute paths, proven by an empty git diff HEAD (0 bytes from --name-only), a clean git status, and a restored blob matching the HEAD blob 1f9ef52ee8

Verification

• pnpm --filter '@objectstack/metadata^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/metadata test — Test Files 38 passed (38), Tests 628 passed (628)
• gate family derived by node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack at 3fc4e3bf24 (34 commands, path-derived plus the test-file convention kind): 33 exit 0, 1 NOT MEASURED — node scripts/check-test-completeness.mjs exits 3 with no test-run log to read, which its own output states is not a red and not a finding
• pnpm check:type-check-debt re-measured 29 ledger entries at this head and reports surplus: none — every entry sits exactly at its measurement, so any new error is red, so the new test code adds zero tsc errors to @objectstack/metadata's frozen 89
• pnpm check:dual-build-cjs-loads and pnpm check:type-check-debt both needed a built workspace (turbo run build --filter='./packages/*' --filter='./packages/*/*', 70/70 successful) and were re-run green afterwards rather than left at their exit-3 prerequisite state

ESLint — a declared narrowing, measured on three counts rather than skipped. Run on the changed files only, --no-inline-config --format json: 0 errors, 0 warnings.

1. The population is read from ESLint's own config, not guessed: --print-config resolves a real config for both .ts files (6 and 5 active rules), and ESLint itself reports the changeset as File ignored because no matching configuration was supplied.
2. The file count is read from --format json: 3 result objects, 2 linted, 1 ignored.
3. Untouched files cannot move: --print-config shows no parserOptions.project on either file, and eslint.config.mjs:328 records — measured with a positive control — that this repo never enables type-aware linting ... for ANY file. Every file's verdict therefore depends only on its own bytes and the shared config, and this diff changes neither the config nor any other file.

Readings the card asked for

• Has any deployment already run this migration against PG/MySQL — the data half.Cannot be ruled out, so the data half stays open and this PR writes no backfill. The repo keeps no record that could answer it: the migration has no caller anywhere (no CLI command, no boot hook — docs/handoff/adr-0030-notification-convergence.md labels it "Data migration (not auto-run)" and hands operators a manual cut-over sequence), and it is not in the sys_migration ledger — the well-known ids are only adr-0104-file-references and adr-0104-value-shapes. Meanwhile it is published: migrateSysNotificationToEvent appears in seven package CHANGELOGs. What narrows the population is the finding below: no driver in this repo defines .raw, so the documented call errors out before touching data. That leaves only an operator who passed a knex-like handle of their own, which the repo cannot see either way.
• Which failure shape occurs on a live server — accepted-and-skewed, or rejected mid-run.NOT MEASURED.OS_TEST_POSTGRES_URL and OS_TEST_MYSQL_URL are unset and nothing is listening in this container, so no live dialect was reachable. The fix is safe under either shape: it removes the input to both, since the value written is canonical ISO text on every dialect. The JavaScript half that needs no server — that String(Date) drops the milliseconds and bakes the process zone — is measured in the pin.
• Does read_at share the defect, and by which gate. Yes, and by a different gate than created_at — the two bullets above. Both are covered by the fix.
• Any sibling migration with the same shape. No. The card's expression over packages/metadata/src/migrations/ returns the two lines in this file and nothing else; widened to String\((row|r|legacy|old)\.[A-Za-z_]*_at\b across all of packages, the other hits are read-side sites already accounted for by the [finding] Sweep: which consumers compare or format a value whose runtime type differs between the Date-materialising drivers and the ISO-text ones #13973 census family (objectql/engine.ts, rest-server.ts, platform-objects/system/migration-flag.ts, metadata-protocol/protocol.ts, cli/commands/migrate/duplicates.ts) plus services/service-queue/src/db-queue-adapter.ts:262. The three other files in this migrations directory contain no _at reference at all.

Out-of-scope finding, filed not folded

#14023 — every migration in packages/metadata/src/migrations/ requires driver.raw(...), and no driver in this repo defines that method; they all expose execute(). Deduped against the backlog first. Different defect class, so it is not repaired here, and #14023 remains open on its own terms.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

2 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 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.

Coarse fallback — 12 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 c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from c98582dd0e0827bc597c495fd557b1dbd2730b24 — the merge of head 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b into base c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37, 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 c98582dd0e0827bc597c495fd557b1dbd2730b24 && git checkout c98582dd0e0827bc597c495fd557b1dbd2730b24
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b && git checkout -B drift-repro c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 && git merge --no-ff 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b
node scripts/docs-audit/affected-docs.mjs --json c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37

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

[zhuangjianguo]

Part of #13998 — the code half only. The data half of that card (whether any deployment has already run this migration against Postgres or MySQL, and therefore whether a backfill is owed) is unanswered and is a maintainer floor, so this PR deliberately does not carry a closing keyword. Reading below.

All gates and tests quoted here were run at 3fc4e3bf24, which is this branch's head.

What was wrong

selectLegacyRows reads the legacy sys_notification table through driver.raw/execute, and the migration then wrote

constcreatedAt=row.created_at!=null ? String(row.created_at) : now();at: isRead&&row.read_at!=null ? String(row.read_at) : createdAt,

into created_at on the new sys_inbox_message row and into created_at / at on the new sys_notification_receipt row. On Postgres and MySQL an instant column materialises as a JS Date, so String(...) spells

Sun Aug 30 2026 18:19:25 GMT+0800 (China Standard Time)

— whole seconds in the migrating host's zone, milliseconds dropped, and a trailing zone name that is in no dialect's timestamp grammar. This migration is one-way, so that spelling is what the platform carries afterwards.

The fix

One canonicaliser, applied at both sites, matching the repo's existing correct form (metadata-protocol/src/protocol.ts, the occurred_at read in readMetadataAuditEvents):

functioncanonicalTimestampText(value: unknown): string{if(typeofvalue==='string')returnvalue;if(valueinstanceofDate)returnvalue.toISOString();returnString(value);}

Route A of #13973 (canonicalise at the migration), as triaged — not the driver-side read-door normalisation, and not a tolerant ?? fallback. A Date and ISO text are two materialisations of one instant, not two spellings of a key. Anything that is neither a string nor a Date keeps its previous String() rendering unchanged rather than having a unit guessed for it on a one-way write path; widening that would be a second, unevidenced decision.

Why neither column could be repaired further upstream

This read path bypasses formatOutput entirely — execute() returns await builder untouched, the same class of bypass sql-driver.ts:3964-3965 already names for aggregate and distinct. Even at the record read door the two columns diverge by different gates, and neither one closes:

• created_at is a builtin audit column, so it is never in datetimeFields and no declared-field coercion reaches it; formatOutput repairs it only inside its if (this.isSqlite) arm (repairNaiveUtcAuditTimestamp over AUDIT_TIMESTAMP_COLUMNS = ['created_at', 'updated_at'], sql-driver.ts:269).
• read_at is a legacy column ADR-0030 removed from the object, so it is not a declared Field.datetime either — datetimeFields is built from declared datetime columns, and read_at appears nowhere in packages/platform-objects/src today. No arm of formatOutput could reach it on any dialect.

The pin, and why it is the real content here

The defect was invisible because this migration's tests drive SQLite/memory shapes, where the legacy stamps are already canonical ISO text and String(row.created_at) is the identity. The new cases break that identity by feeding a hand-made Date — the discriminating input — through the migration's read path under a forced process zone. @objectstack/metadata has no driver dependency and must not grow one, so a hand-made Date is the right instrument, exactly as the OCC seam's own suite uses one.

They live in the existing test file and reuse its already-pinned engine doubles, so check:engine-double-contract's ledger is untouched.

Ablation, on the committed tree, no rebuild leg (the pin imports ./migrate-sys-notification-to-event.js relatively, so vitest resolves source; dist/ is not on this path — stated rather than fabricated):

• mutation proven on disk in both directions — injected String(row.created_at) / String(row.read_at) count 2, removed canonicalTimestampText(row. count 0 — and by blob: 1f9ef52ee8 to fb4534c3e5
• result: Tests 1 failed | 7 passed (8), failing precisely on the new case with AssertionError: inbox.created_at must be canonical ISO-Z: expected 'Sun Aug 30 2026 18:19:25 GMT+0800 (Ch…' to match /^\d{4}-\d{2}-\d{2}T…/ — the production spelling, reproduced
• the other 7 cases stayed green under the mutation, which is the SQLite identity demonstrated rather than asserted
• restore under trap ... EXIT INT TERM with absolute paths, proven by an empty git diff HEAD (0 bytes from --name-only), a clean git status, and a restored blob matching the HEAD blob 1f9ef52ee8

Verification

• pnpm --filter '@objectstack/metadata^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/metadata test — Test Files 38 passed (38), Tests 628 passed (628)
• gate family derived by node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack at 3fc4e3bf24 (34 commands, path-derived plus the test-file convention kind): 33 exit 0, 1 NOT MEASURED — node scripts/check-test-completeness.mjs exits 3 with no test-run log to read, which its own output states is not a red and not a finding
• pnpm check:type-check-debt re-measured 29 ledger entries at this head and reports surplus: none — every entry sits exactly at its measurement, so any new error is red, so the new test code adds zero tsc errors to @objectstack/metadata's frozen 89
• pnpm check:dual-build-cjs-loads and pnpm check:type-check-debt both needed a built workspace (turbo run build --filter='./packages/*' --filter='./packages/*/*', 70/70 successful) and were re-run green afterwards rather than left at their exit-3 prerequisite state

ESLint — a declared narrowing, measured on three counts rather than skipped. Run on the changed files only, --no-inline-config --format json: 0 errors, 0 warnings.

1. The population is read from ESLint's own config, not guessed: --print-config resolves a real config for both .ts files (6 and 5 active rules), and ESLint itself reports the changeset as File ignored because no matching configuration was supplied.
2. The file count is read from --format json: 3 result objects, 2 linted, 1 ignored.
3. Untouched files cannot move: --print-config shows no parserOptions.project on either file, and eslint.config.mjs:328 records — measured with a positive control — that this repo never enables type-aware linting ... for ANY file. Every file's verdict therefore depends only on its own bytes and the shared config, and this diff changes neither the config nor any other file.

Readings the card asked for

• Has any deployment already run this migration against PG/MySQL — the data half.Cannot be ruled out, so the data half stays open and this PR writes no backfill. The repo keeps no record that could answer it: the migration has no caller anywhere (no CLI command, no boot hook — docs/handoff/adr-0030-notification-convergence.md labels it "Data migration (not auto-run)" and hands operators a manual cut-over sequence), and it is not in the sys_migration ledger — the well-known ids are only adr-0104-file-references and adr-0104-value-shapes. Meanwhile it is published: migrateSysNotificationToEvent appears in seven package CHANGELOGs. What narrows the population is the finding below: no driver in this repo defines .raw, so the documented call errors out before touching data. That leaves only an operator who passed a knex-like handle of their own, which the repo cannot see either way.
• Which failure shape occurs on a live server — accepted-and-skewed, or rejected mid-run.NOT MEASURED.OS_TEST_POSTGRES_URL and OS_TEST_MYSQL_URL are unset and nothing is listening in this container, so no live dialect was reachable. The fix is safe under either shape: it removes the input to both, since the value written is canonical ISO text on every dialect. The JavaScript half that needs no server — that String(Date) drops the milliseconds and bakes the process zone — is measured in the pin.
• Does read_at share the defect, and by which gate. Yes, and by a different gate than created_at — the two bullets above. Both are covered by the fix.
• Any sibling migration with the same shape. No. The card's expression over packages/metadata/src/migrations/ returns the two lines in this file and nothing else; widened to String\((row|r|legacy|old)\.[A-Za-z_]*_at\b across all of packages, the other hits are read-side sites already accounted for by the [finding] Sweep: which consumers compare or format a value whose runtime type differs between the Date-materialising drivers and the ISO-text ones #13973 census family (objectql/engine.ts, rest-server.ts, platform-objects/system/migration-flag.ts, metadata-protocol/protocol.ts, cli/commands/migrate/duplicates.ts) plus services/service-queue/src/db-queue-adapter.ts:262. The three other files in this migrations directory contain no _at reference at all.

Out-of-scope finding, filed not folded

#14023 — every migration in packages/metadata/src/migrations/ requires driver.raw(...), and no driver in this repo defines that method; they all expose execute(). Deduped against the backlog first. Different defect class, so it is not repaired here, and #14023 remains open on its own terms.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

2 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 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.

Coarse fallback — 12 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 c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from c98582dd0e0827bc597c495fd557b1dbd2730b24 — the merge of head 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b into base c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37, 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 c98582dd0e0827bc597c495fd557b1dbd2730b24 && git checkout c98582dd0e0827bc597c495fd557b1dbd2730b24
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b && git checkout -B drift-repro c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37 && git merge --no-ff 3fc4e3bf24a7bc75fdca1cbed7e36a9adc89a04b
node scripts/docs-audit/affected-docs.mjs --json c54d4d3d7d0a7f3e6ec848dd0cb415ee35ebbb37

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