fix(sql): flag DECIMAL(p) scale-0 narrowing (migrate + revert)

[cursor]

Bug and impact

DECIMAL(p) / NUMERIC(p) means DECIMAL(p,0) in SQL. Migrating or reverting a column from numeric(10,2) → numeric(10) truncates fractional digits, but:

• Compare/Migrate pre-flight (findNarrowingTypeChanges) skipped the scale check when the desired type omitted scale, so there was no NARROWING_TYPE_CHANGE warning.
• History revert (parseTypeText) stored the sole argument as length, so scale comparison never ran and the revert was classified safe — Execute needed no data-loss confirmation.

Concrete trigger: Original has amount NUMERIC(10), Target has amount NUMERIC(10,2) with values like 19.99. Syncing Target to Original (or reverting to that version) rounds away cents without warning.

Root cause

Both checkers required scale to be defined on both sides. The omitted-scale form left scale undefined (tokenizer single-arg → length in reverse parsing), so the reduction was invisible to the safety net. Explicit NUMERIC(10,0) was already flagged.

Fix

• isNarrowing: treat missing scale as 0 when precision is present.
• parseTypeText: map numeric/decimal/number/dec single-arg forms to { precision, scale: 0 }.

Validation

• Unit tests for migrate narrowing and revert lossy classification on numeric(10,2) → numeric(10).
• npx vitest run packages/sql — 700 passed, 2 expected fail.

  

---

Note

Medium Risk
Changes how narrowing and revert-risk are classified for decimal columns; behavior is safer (more warnings) but could affect migrate/revert UX where omitted-scale types were previously treated as non-narrowing.

Overview
Treats DECIMAL(p) / NUMERIC(p) as (p, 0) so fractional-digit loss is no longer invisible when scale is omitted on one side of a comparison.

Migrate pre-flight (isNarrowing in migration-validation.ts): when comparing decimal types, missing scale is now 0 if precision is set, so numeric(10,2) → numeric(10) surfaces a NARROWING_TYPE_CHANGE warning instead of being skipped.

History revert (parseTypeText in reversal.ts): single-argument numeric/decimal/number/dec forms are parsed as { precision, scale: 0 } rather than length, so classifyReversal marks numeric(10,2) → numeric(10) as lossy (scale 2 → 0) instead of safe.

Tests cover parsing, migrate narrowing, and revert classification for these cases.

^{Reviewed by Cursor Bugbot for commit c7c549c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_4c4d83ea-007a-4590-833c-382f6bc92627)