fix(driver-sql): a MySQL NOW() datetime default carries its column's precision

[objectstack-fleet]

Fixes #21241

Clause-②: no

What was wrong

On MySQL a declared Field.datetime is built as DATETIME(3). For its defaultValue: 'NOW()' default, SqlDriver.nowColumnDefault('datetime') fell through to a bare knex.fn.now(), which is CURRENT_TIMESTAMP at precision 0. MySQL 8.0 refuses a CURRENT_TIMESTAMP default whose precision differs from its column's, so the whole CREATE TABLE failed and so did ALTER TABLE … ADD. The builtin created_at / updated_at columns beside it carried their own literal now(3) and were accepted.

Measured at the base be5a83cf against a throwaway MySQL 8.0.46 (server zone +08:00):

boot	schema sync	refused DDL	data door
pnpm dev:crm -- --fresh --database mysql://…	synced 80, skipped 0, failed 1	sys_activity: `timestamp` datetime(3) default CURRENT_TIMESTAMP → Invalid default value for 'timestamp'	GET /api/v1/data/sys_activity?limit=1 → 500 DATABASE_ERROR
pnpm dev:showcase -- --fresh --database mysql://…	synced 102, skipped 2, failed 2	sys_activity as above, and sys_presence: `last_seen` datetime(3) default CURRENT_TIMESTAMP → Invalid default value for 'last_seen'	GET /api/v1/data/sys_presence?limit=1 → 500, sys_activity → 500

The fix

• One source for the precision. MYSQL_DATETIME_PRECISION is a module constant in sql-driver.ts. Five sites read it: the declared datetime column (createColumn), the builtin audit columns (createAuditTimestampColumn), the NOW() default (nowColumnDefault), the UPDATE stamp (updatedAtStamp) and the legacy TIMESTAMP widening (migrateMysqlDatetimeColumns). Before this PR, five literal 3s lived at those sites. Now there is one, and no new literal was added.
• nowColumnDefault('datetime') on MySQL returns knex.fn.now(MYSQL_DATETIME_PRECISION), which renders CURRENT_TIMESTAMP(3).
• The builtin audit column's MySQL default is routed through nowColumnDefault('datetime'), the way the SQLite branch already is. The declared column and the builtin column now share one definition. The emitted DDL for the audit columns is byte-identical: datetime(3) default CURRENT_TIMESTAMP(3).
• PostgreSQL and SQLite emit unchanged SQL. On PostgreSQL the driver builds timestamptz, and CURRENT_TIMESTAMP on it was measured accepted on PostgreSQL 16.14. timestamp(3) default CURRENT_TIMESTAMP is also accepted there, rounding silently. So the mismatch does not exist on that dialect.

Bounded in-place fix in the same statement: the TIMESTAMP widening dropped a declared NOW() default

The widening's ALTER … MODIFY line now reads the constant, so this PR touches it. That same statement restated the default of created_at / updated_at and dropped the default of a declared NOW() column. The TIME twin (migrateMysqlTimeColumns) already restates it.

Measured on MySQL 8.0.46 with the driver built at this branch before the change: a legacy stamped_at timestamp null default current_timestamp column came out of schema sync as datetime(3) with COLUMN_DEFAULT null, and create without the field answered stamped_at = null. The widening now restates nowColumnDefault('datetime') for a declared NOW() column as well. All four conditions for an in-place fix hold:

• same family (a MySQL NOW() datetime default that is not honoured);
• mechanical, with the shape fixed by the TIME twin;
• same file and claim;
• same gate family.

The changed lines are sql-driver.ts migrateMysqlDatetimeColumns, and a MySQL-only pin, §3.

Pins: packages/drivers/driver-sql/src/sql-driver-21241-mysql-now-default-precision.test.ts

• §1, run on every runner with no server: for mysql2, pg and better-sqlite3, the compiled DDL of a declared NOW() datetime column is byte-identical to the builtin audit column's. A second case reads the mysql2 DDL of the required sys_activity.timestamp shape and checks that its CURRENT_TIMESTAMP(n) names the column's own datetime(n). This compares against the column, not against a literal.
• §2, one cell per dialect through declareDialectCell:
  • the table syncs, both on create and on add-column for a table that already exists;
  • create without the field answers the instant the column DEFAULT stored. The check uses a window and confirms that the answer equals findOne;
  • a raw insert that never names the column is filled by the DEFAULT alone;
  • the server's own catalogue (information_schema / pragma table_info) reports the declared column's type and default equal to created_at's.
• §3, MySQL only: a legacy TIMESTAMP NOW() column keeps a default through the widening, equal to created_at's.

Verification (HEAD d334fe314b)

Every reading below was re-run at d334fe314b: the branch plus one merge of origin/main 4727fcb22a, which touches no driver-sql file and no lockfile. The readings match the earlier head e5cab5f20b, except the driver-turso count, which moved because #21226 landed on main. (Seat edit.)

The live servers were local: MySQL 8.0.46 at +08:00 and PostgreSQL 16.14 at Asia/Shanghai, with TZ=America/New_York.

• Pins: vitest run --reporter=verbose src/sql-driver-21241-mysql-now-default-precision.test.ts with both URLs set → 17 passed (17).
• Reverse verification. sql-driver.ts was written back to the base blob e65a0f08 while the HEAD blob 533a790b stayed committed. On-disk hash equal to the base blob, grep -c MYSQL_DATETIME_PRECISION → 0. Result: 7 failed | 10 passed (17). Every failure is MySQL: §1 mysql2 ×2, §2 live mysql ×4 (Invalid default value for 'stamped_at' at create and at add-column), and §3. The SQLite and PostgreSQL cells stayed green (the control). The restore was checked: hash equal to the HEAD blob and git diff HEAD empty.
• Ablation of the widening half. Through scripts/ablation-replace.mjs: anchor 1 → 0, blob 533a790b → 16057202. Only §3 went red, dflt: null against CURRENT_TIMESTAMP(3); the other 16 stayed green. Restored: blob equal to HEAD and git diff HEAD empty.
• @objectstack/driver-sql, the whole suite against both live servers with OS_EXPECT_LIVE_DIALECT_MATRIX=1: 224 files passed, 5386 passed | 1 skipped. The live-dialect reporter printed "all 3 dialects were exercised".
• @objectstack/driver-sql, the SQLite tier (pnpm --filter @objectstack/driver-sql test, no URLs, at 04b23d2791 before the widening commit): 213 files passed | 11 skipped, 3570 passed | 200 skipped.
• Typecheck of @objectstack/driver-sql, @objectstack/driver-sqlite-wasm and @objectstack/driver-turso (the inheritors): all three Done. tsc --listFiles includes the new test file once.
• Tests of the inheritors: driver-sqlite-wasm 36 files / 675 passed; driver-turso 87 files / 2349 passed | 33 skipped.
• pnpm check:driver-conformance gave the same reading before the first edit and after the last commit: OK — 50 covered cell(s), 0 in the DEBT ledger, 0 exempt, with 0 in the DIALECT ledger.
• Gates: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands derived 63 families. All 63 ran with exit 0. --ran reconciliation: 63 derived, 63 run, 0 NOT-MEASURED, 0 UNRUN, with every line recording its exit code. The derivation warned that the tree is one main commit behind (3dc33b2d13, file-disjoint from this diff, and it touches check-route-envelope.mjs / engine-double-contract.pinned.json). CI re-derives on the merge ref.
• Lint, narrowed:
  • eslint --no-inline-config --format json over the two changed .ts files: 2 files, 0 errors, 0 warnings.
  • Population: both files are linted, not ignored.
  • Invariance: the config's parserOptions carry no project / projectService, so linting is not type-aware and this diff cannot move a verdict on an untouched file.
  • Repo-wide pnpm lint is left to CI.

After the fix, same boot

pnpm dev:showcase -- --fresh --database mysql://… at e5cab5f20b:

• no Schema sync FAILED;
• GET /api/v1/data/sys_presence → 200 and sys_activity → 200;
• information_schema reports sys_activity.timestamp and sys_presence.last_seen as datetime(3) / CURRENT_TIMESTAMP(3), equal to their created_at;
• a POST / PATCH / DELETE on showcase_account left three sys_activity rows (created, updated, deleted).

Raise-rule reading (triage)

At the base on MySQL, with sys_activity absent, a missing table does not break a record write. POST /api/v1/data/crm_account → 201, PATCH → 200 (a read-back showed the new name), DELETE → 200 (a read-back answered 404). sys_audit_log holds 3 rows for the record. Each mutation lost its activity row: the server logged Insert operation failed {object: sys_activity …} at warn and Audit write FAILED (ER_NO_SUCH_TABLE …) at error. The API answers carried nothing about it. Applying the rule is the seat's decision.

Acceptance notes

• Existing tables / migration (H5). On MySQL no table could have been created with the refused default, so a fresh boot after this change creates the missing tables and no migration is owed. A column that an earlier release's TIMESTAMP widening already left without a default does not get one back from this change. The widening only touches columns that are still timestamp. This is a read-only inference beyond the measurement above.
• MariaDB not measured. No MariaDB server here. client: 'mariadb' is not in the driver's MySQL family, but mysql2 pointed at a MariaDB server is. Whether MariaDB accepted the bare default, and so holds tables with a precision-0 default, is NOT MEASURED.
• Operator text. At the base, the Audit write FAILED line for the sys_activity insert names sys_audit_log as the row that "never landed" and as the table to check. It printed 4 times despite "reported ONCE". Observation only, nothing filed.
• sys_packages. Its raw DDL (created_at TEXT DEFAULT CURRENT_TIMESTAMP) is still refused on MySQL in both boots. This was already recorded in PR fix(driver-sql): create and bulkCreate answer the stored row on MySQL (#21227) #21239's acceptance notes; it is domain:services, and no door was measured.
• Not filed from this PR, handed to the seat in the report. At the base on MySQL, GET /api/v1/auth/jwks and GET /api/v1/auth/token answered 500. An insert into sys_jwks is refused with Incorrect datetime value … for column 'updated_at', and the server logs JWT signing failed with alg "EdDSA".

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/driver-sql, touching 7 documentable anchor(s).

9 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/data-modeling/drivers.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/data-modeling/index.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/data-modeling/queries.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/permissions/tenant-audit-census.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/plugins/packages.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/protocol/kernel/index.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/protocol/kernel/lifecycle.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/protocol/objectql/query-syntax.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/protocol/objectql/types.mdx (via SqlDriver (symbol, a top-level class))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17/17-0.mdx (via SqlDriver (symbol, a top-level class))
• content/docs/releases/v17/17-5.mdx (via SqlDriver (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

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

Coarse fallback — 11 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 4727fcb22a7e6a28da1ad20ef74469fbabb8dd0e → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 79d9b22c215da0644acf4761b0f01e01d201d9ef — the merge of head d334fe314b451d84ae64f59697391df55dd3aff2 into base 4727fcb22a7e6a28da1ad20ef74469fbabb8dd0e, 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 79d9b22c215da0644acf4761b0f01e01d201d9ef && git checkout 79d9b22c215da0644acf4761b0f01e01d201d9ef
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4727fcb22a7e6a28da1ad20ef74469fbabb8dd0e d334fe314b451d84ae64f59697391df55dd3aff2 && git checkout -B drift-repro 4727fcb22a7e6a28da1ad20ef74469fbabb8dd0e && git merge --no-ff d334fe314b451d84ae64f59697391df55dd3aff2

node scripts/docs-audit/affected-docs.mjs --json 4727fcb22a7e6a28da1ad20ef74469fbabb8dd0e

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 4727fcb22a7e6a28da1ad20ef74469fbabb8dd0e → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

Contract review

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

Inputs, and nothing else: card #21241 (body; comments 5940340798, 5941097310, 5941379243, 5942461506, 5942490638), PR #21252 (body as the seat edited it, file list of 3, the net diff against merge base 4727fcb22a fetched as the three-dot diff and compared byte-equal to a local git diff of the fetched head), the head's check-runs read last. Reads were git show / git grep on the fetched ref and REST GETs; nothing built, run or re-run.

① Derived judgments

One precision source — right. At the base (e65a0f08) the code carried five MySQL DATETIME-precision literals: updatedAtStamp (now(3)), the TIMESTAMP widening (current_timestamp(3) and datetime(3) in one statement), createAuditTimestampColumn (precision: 3 and now(3)) and createColumn's datetime arm (precision: 3). At the head the module constant MYSQL_DATETIME_PRECISION = 3 (line 408) is read at exactly those five sites (8376, 13103, 17881, 17963, 19495) and no code literal of that family remains; the only residual DATETIME(3) is prose inside the widening's info log string, not DDL. The time(3) literals are a different family (TIME precision) and outside this card. Triage's premise that the source "already existed" was false at the base; creating it is the direction's intent carried out, as the claim amendment records.

nowColumnDefault('datetime') on MySQL — right. The new arm sits after the time and date arms inside the !isSqlite branch and is guarded by type === 'datetime' && this.isMysql, returning knex.fn.now(MYSQL_DATETIME_PRECISION); PostgreSQL still falls to the bare knex.fn.now() and the SQLite switch is untouched. The declared column (createColumn → applyDeclaredColumnDefault → nowColumnDefault(type)) therefore renders datetime(3) default CURRENT_TIMESTAMP(3).

Builtin audit columns' MySQL DDL bytes unchanged — right. createAuditTimestampColumn's MySQL arm now reads table.datetime(name, { precision: MYSQL_DATETIME_PRECISION }).defaultTo(this.nowColumnDefault('datetime')), and on MySQL that default is the same knex.fn.now(3) it spelled before. The reverse verification shows it from the other side: with sql-driver.ts reverted to the base blob, §1 mysql2 received the declared column as datetime(3) default CURRENT_TIMESTAMP against the audit column's CURRENT_TIMESTAMP(3), so the audit column rendered the same bytes at base and head. updatedAtStamp is byte-identical (now(3)).

PostgreSQL and SQLite DDL unchanged — right. No PostgreSQL or SQLite arm is touched in nowColumnDefault, createAuditTimestampColumn or createColumn; the only other nowColumnDefault('datetime') caller (the SQLite-only table rebuild at 14332) takes the untouched SQLite branch. §1's pg and better-sqlite3 cases and §2's two live cells are a real control: they were equal before the fix and stayed green under the reverse verification.

The widening restating a declared NOW() default — right, and bounded. legacyMysqlTimestampColumns enumerates only the audit columns plus declared non-multivalued datetime fields, and only those information_schema still types timestamp; the restatement condition is isAudit || isNowDefaultValue(fields[col.name]?.defaultValue), where isNowDefaultValue is spec's isNowDefaultToken (/^now\(\)$/i after trim). A declared datetime with a literal default keeps today's behaviour; a column already widened is never re-touched. The restated expression is nowColumnDefault('datetime').toString(), so fresh and widened columns share one spelling (the TIME twin keeps its own literal expression, outside this card). The case change from current_timestamp(3) to CURRENT_TIMESTAMP(3) is not consumer-visible: MySQL's catalogue reports CURRENT_TIMESTAMP(3) either way. previewDatetimeConvergence (the os migrate plan twin) lists columns from the same predicate and never prints the default clause, and the net diff has no hunk in it, so plan and apply still agree by construction.

Pins — they prove what they claim. §1 compiles DDL offline on mysql2, pg and better-sqlite3 and asserts declared-equals-audit plus a non-vacuous default; the required-column case reads the datetime(n) precision off the DDL and requires the CURRENT_TIMESTAMP(n) to match it, with a missing (n) read as 0, so it compares the column to itself, not to a literal. §2 goes through declareDialectCell (a total measure; a missing URL is reported un-run and is a failure under OS_EXPECT_LIVE_DIALECT_MATRIX=1) and measures create, add-column on an existing table, create without the field inside a window and equal to findOne, a raw insert naming no column (the DEFAULT alone), and the server catalogue equal to created_at's. §3 (MySQL only) seeds a pre-#3942 timestamp null default current_timestamp column, runs initObjects, and requires the widened column's catalogue row to equal created_at's; because created_at is always restated, that equality is not tautological, and the dev's ablation confirms it bites: removing the restatement turned only §3 red (dflt: null against CURRENT_TIMESTAMP(3)). The reverse verification's 7-failed/10-passed split, every failure MySQL, is the right shape for a MySQL-only fix with two controls. The CI Temporal Conformance (live PG + MySQL) job succeeded on this head, so the live MySQL cells were measured in CI, not only on the dev's box.

No migration for fresh MySQL tables — right. A CREATE TABLE MySQL refused left no table; the next boot creates it. The legacy stripped default — acceptable as a recorded Acceptance note. A column an earlier release's widening already moved to datetime(3) and left default-less is outside legacyMysqlTimestampColumns's data_type = 'timestamp' filter, so this PR does not repair it; the population is bounded to pre-#3942 MySQL databases holding a declared NOW() datetime field, and every engine write path fills NOW() app-side, so only a writer bypassing the engine sees NULL. That is a repair of its own (restate the declared default on datetime columns whose COLUMN_DEFAULT is null), not a reason to hold this fix; see ③.

Inheritors. createAuditTimestampColumn now couples to the protected nowColumnDefault; driver-sqlite-wasm and driver-turso are SQLite-family (isMysql false), their suites passed per the report, and Test Core and the type-check jobs are green on the head.

② Semver level

.changeset/21241-mysql-now-default-precision.md declares '@objectstack/driver-sql': patch with Clause-②: no at line start (line 7); the PR body carries Clause-②: no at line start (line 3). Right. The accept set is unchanged: Field.datetime({ defaultValue: 'NOW()' }) was already an accepted declaration on every surface, and the spec's token recogniser is untouched; the driver now emits DDL MySQL accepts for a declaration it already promised to honour. No export, key or option is added or removed, nothing accepted before is refused, and the widening's restatement moves a column toward its declaration rather than widening what an author may write. A fix that makes previously refused DDL succeed is a bug fix in a released package, which the rules bind to patch, never none. CI's Check Changeset succeeded on the head.

③ Boundary flags

• Deviation 1 (container restart around the PR's opening). The branch holds all four commits and the head is the merge; every reading was re-run at d334fe314b and the net diff is self-consistent. No action.
• Deviation 2 (one merge of origin/main 4727fcb22a). The merge base of the head with origin/main is 4727fcb22a; the three-dot diff and a local diff against that base are byte-equal and touch only the 3 listed files, so the merge brought nothing of its own into this review. Accepted.
• Deviation 3 (PR body quoting e5cab5f20b). The seat changed the heading to Verification (HEAD d334fe314b) and the driver-turso line, marked (Seat edit.); the remaining e5cab5f20b citations are readings taken at that commit and say so. Answered.
• Deviation 4 (PostgreSQL data dir in /var/tmp). A local-environment matter, removed afterwards; no repo artefact. No action.
• Open question (widening in-place or split): the seat's answer A is right. The bounded in-place exemption's four conditions hold: same defect class (a declared NOW() datetime default MySQL does not honour); mechanical, with the shape already pinned by the TIME twin; no other claim holds the file (core/driver-sql: the JSON-column refusal tells a single-value file field (media columns not yet moved) to use $contains, which answers no rows there; its repair is the media-column move #21236 is queued behind this card, driver-sql on MySQL: create() answers the insert id (0) instead of the inserted record, so sign-up answers 400 FAILED_TO_CREATE_USER, the dev admin seed fails and no user can sign in #21227's PR landed); same gate family, the pin being one case in the same new file under the same live-dialect gate. Both debts are paid: the claim amendment 5942490638 records the widening in the file surface the same round, and the PR body names the fix with the measured evidence.
• sys_jwks MySQL finding. Filed by the seat as On MySQL, the JWT signing-key row is never written (Incorrect datetime value for sys_jwks.updated_at), so /auth/jwks and /auth/token answer 500 and no OIDC/MCP token can be issued #21259 (open). Not this PR. Closed.
• sys_packages. On MySQL, sys_packages is never created (its raw DDL fails three ways), so package publish answers 500 and an installed or edited package silently disappears on restart while install and PATCH answer success #21243 (open, p1, domain:services). Not this PR. Closed.
• Operator-text note — escalated to the seat. The audit writer's Audit write FAILED line names sys_audit_log as the row that never landed and as the table to check while the refused insert was sys_activity, and it printed 4 times despite "reported ONCE". That is a reproducible defect with a named landing site and measured evidence; it deserves a card in the audit writer's lane. Not blocking here.
• Legacy stripped default — escalated to the seat as a candidate card, accepted here as an Acceptance note (judgment in ①): a declared NOW() datetime column an earlier release's widening left default-less stays so; the repair is a separate, bounded migration and the engine's app-side fill masks it on every engine write.
• MariaDB not measured — acceptable as recorded. mysql2 against MariaDB takes the isMysql path; MariaDB 10.2+ accepts CURRENT_TIMESTAMP(3), so new tables are unaffected, and a DDL default governs only new tables. Whether MariaDB previously accepted the precision-0 default is unknown and not a CI target.

Check-runs on the head, read at 2026-10-01T23:19:36Z: 41 runs, all completed; 36 success, 5 skipped (Build Docs, Console Pin Gate, the opt-in packed-tarball smoke, and the body-edit re-triggers of Auto Label and Check PR Size whose first runs succeeded), 0 failed, 0 in progress. Temporal Conformance (live PG + MySQL) completed success at 2026-10-01T22:49:14Z; Lint & Repo Gates at 2026-10-01T22:50:00Z; Governed Surface Queue Guard success (no governed path in the file list). Combined status success (Vercel).

Implemented-by: claude/issue-21241-mysql-now-default-precision
Reviewed-by: session_017xfMoEjKUuSh2xYB8sCozp

VERDICT: PASS

Rendered 2026-10-01T23:23Z by a subagent of the seat session; the seat adopts the verdict.

---

Generated by Claude Code