@@ -0,0 +1,54 @@
+---
+'@objectstack/spec': minor
+---
+
+fix(spec)!: the form-row `scale` is bounded at the renderer ceiling of 100 (#19088)
+
+Clause-②: no (narrowing)
+
+`FormFieldBaseSchema.scale` — the per-field override a form row carries — was declared as
+any non-negative integer with no upper bound. It is the third declaration of `scale` to
+reach the same platform ceiling #18972 bounded on the two in `data/field.zod.ts`: every
+renderer that turns a declared `scale` into fraction digits reaches one of two platform
+primitives, and both refuse above 100. `Number.prototype.toFixed` throws `RangeError:
+toFixed() digits argument must be between 0 and 100`, and `Intl.NumberFormat` throws
+`RangeError: maximumFractionDigits value is out of range.` So a spec-valid declaration was
+unrenderable by any conforming consumer, and its author got no signal at publish time —
+the failure arrived as a render-time crash in someone else's repository. The route from
+this row to that reader, measured in the sibling checkout at the `.objectui-sha` pin
+`53ded82bf7`: plugin-form copies the row's constraint keys onto the runtime field
+(`packages/plugin-form/src/sectionFields.ts:220`, `if (fd.scale != null) base.scale =
+fd.scale;`), and the number cell renderer hands that value straight to `Intl.NumberFormat`
+(`packages/fields/src/index.tsx:661-667`, `maximumFractionDigits: scale ?? 20`). That one
+route carries the premise on its own.
+
+The row now carries that upper bound, and the refusal says **why** — it names both
+primitives, the `RangeError` and the legal maximum — so an author reads a platform limit
+they can verify rather than a cap somebody chose. The bound is the platform's own: at 100
+both primitives are measured to succeed, at 101 both are measured to throw, and a unit
+test re-measures that boundary on every run rather than trusting the literal.
+
+**BREAKING** — a form-row `scale` above 100 that parsed clean before is refused at
+authoring now. This is a deliberate narrowing of a published accepted set, priced as such
+rather than as a tidy-up. The declarations it refuses could only ever have crashed a
+renderer: there is no value above 100 that any conforming consumer can render, which is
+why the bound is the platform's limit and not a policy number.
+
+Unchanged in both directions: `scale: 100` still parses, `scale: 0` still parses, absence
+is still absence, and the malformed-declaration refusals from #8321/#12174 (`scale: -1`,
+`scale: 2.5`) keep their existing codes and their existing wording. `precision` is
+untouched on this row as on the object-field row — it is a total digit count that reaches
+neither primitive, so the renderer-ceiling argument does not carry to it.
+
+The number itself moves into `src/shared/scale-ceiling.ts`, a spec-internal leaf module
+that no package entry re-exports, so no published export moves and `check:api-surface`,
+`check:export-origins` and `check:declaration-map` all stay green. `data/field.zod.ts`
+keeps the module-private copy #18972 minted; a pin asserts the two sites refuse with
+byte-identical text, so the duplication is held equal rather than left to drift, and that
+file can adopt the shared module later as a pure delete-and-import.
+
+Shipped as `minor` under the repo's launch-window convention, in which
+`check-changeset-no-major` refuses `major` and breaking-ness is carried by this banner
+plus the ADR-0087 disposition rather than by the level.
+
+<!-- adr-0087: not-required (no-migration-prescription) no authorable key is renamed, retired or reshaped: `scale` keeps its name, its place on the form row and its type, and what moves is the top of one existing key's accepted numeric range. So `objectstack migrate meta` has nothing to visit — there is no stored spelling to rewrite and no FROM side to map, because the values this now refuses have no correct mechanical replacement: 101 fraction digits is not a precision a renderer can honour at all, and picking the display precision an author actually meant is their judgement, not a transform the ledger can carry. A ledger row would therefore have to invent the very semantics ADR-0078 and PD #12 forbid inventing, and the channel that does reach every affected author is the parse refusal itself, which names both primitives, the `RangeError` and the legal maximum at the moment the declaration is written. Measured on this tree at `7e52288463`: 126 `scale: N` declarations across `*.ts` / `*.tsx` / `*.json` / `*.mdx` / `*.yml` / `*.yaml` as the lit control, of which four read above 100 and all four are refusal fixtures or prose about them (two from #18972's tests, two from this branch's) — zero authored declarations above the ceiling. The instrument's radius is this repository's tracked file contents; the known target outside it is a `sys_metadata` row already stored in a running deployment's database, which no in-repo instrument reaches, and #18972 recorded the same blind spot. The other four categories are closed on facts: `@objectstack/spec` publishes to npm and declares no `private` (not `unpublished`); no ADR-0087 id is minted in this diff (not `registered`) and none pre-dating the base covers it (not `already-registered`); and the surface that moves is a Zod metadata schema, not a runtime-only TS interface and not a type annotation (neither `runtime-interface-only` nor `type-surface-only`). -->
@@ -189,7 +189,7 @@ Column footer summary configuration
 | **min** | `number` | optional | Minimum value (for number/currency/percent/slider) |
 | **max** | `number` | optional | Maximum value |
 | **precision** | `integer` | optional | Total digits (non-negative integer; for number/currency) |
-| **scale** | `integer` | optional | Decimal places (non-negative integer) |
+| **scale** | `integer` | optional | Decimal places (integer 0-100). The upper bound is the platform's, not a policy: renderers turn `scale` into fraction digits through `toFixed` and `Intl.NumberFormat`'s `maximumFractionDigits`, both of which throw a RangeError above 100 — so a larger declaration is unrenderable by any conforming consumer. |
 | **multiple** | `boolean` | optional | Allow multiple values (for select/lookup/file/image) |
 | **label** | `string \| Record<string, string>` | optional | Display label override |
 | **placeholder** | `string \| Record<string, string>` | optional | Placeholder text |
@@ -354,7 +354,7 @@ View filter rule
 | **min** | `number` | optional | Minimum value (for number/currency/percent/slider) |
 | **max** | `number` | optional | Maximum value |
 | **precision** | `integer` | optional | Total digits (non-negative integer; for number/currency) |
-| **scale** | `integer` | optional | Decimal places (non-negative integer) |
+| **scale** | `integer` | optional | Decimal places (integer 0-100). The upper bound is the platform's, not a policy: renderers turn `scale` into fraction digits through `toFixed` and `Intl.NumberFormat`'s `maximumFractionDigits`, both of which throw a RangeError above 100 — so a larger declaration is unrenderable by any conforming consumer. |
 | **multiple** | `boolean` | optional | Allow multiple values (for select/lookup/file/image) |
 | **label** | `string \| Record<string, string>` | optional | Display label override |
 | **placeholder** | `string \| Record<string, string>` | optional | Placeholder text |
 
@@ -0,0 +1,97 @@
+// Copyright (c) 2026 ObjectStack. Licensed under the Apache-2.0 license.
+
+/**
+ * # The platform ceiling on decimal places (#18972, #19088)
+ *
+ * Every renderer that turns a declared `scale` into fraction digits reaches one
+ * of two platform primitives, and BOTH refuse above 100. Measured first-hand on
+ * node v22.22.2:
+ *
+ *   (1.5).toFixed(100)                                       -> '1.5000...'  (ok)
+ *   (1.5).toFixed(101)                                       -> RangeError: toFixed() digits argument must be between 0 and 100
+ *   new Intl.NumberFormat(u, { maximumFractionDigits: 100 }) -> ok
+ *   new Intl.NumberFormat(u, { maximumFractionDigits: 101 }) -> RangeError: maximumFractionDigits value is out of range.
+ *
+ * So the bound is the PLATFORM's, not a policy: it is the largest value every
+ * conforming consumer can render, and a declaration past it is unrenderable
+ * rather than merely large. The literal is never trusted on its own — the pins
+ * beside each consuming schema re-measure both primitives on every run and
+ * assert the schema's own accept/refuse boundary sits on the same number, so a
+ * runtime that moves either limit turns the pin red instead of silently
+ * shifting what authors may write.
+ *
+ * ## Why this module exists, and why it exports nothing to consumers
+ *
+ * #18972 minted this fact inside `data/field.zod.ts` as a module-private
+ * `MAX_RENDERABLE_SCALE`, for the two `scale` declarations that file carries.
+ * #19088 is the third site — `FormFieldBaseSchema.scale` in `ui/view.zod.ts`,
+ * the form-row override — which reaches the same `Intl.NumberFormat` reader
+ * through plugin-form. Measured in the sibling checkout at the `.objectui-sha`
+ * pin `53ded82bf7`:
+ *
+ *   packages/plugin-form/src/sectionFields.ts:220
+ *     if (fd.scale != null) base.scale = fd.scale;   // form row -> runtime field
+ *   packages/fields/src/index.tsx:661-667
+ *     maximumFractionDigits: scale ?? 20             // runtime field -> Intl
+ *
+ * ⛔ Do NOT cite an objectui "spec bridge" (`form-view.ts` `mapField`) here.
+ * That route is RETIRED at this pin — the tree carries
+ * `.changeset/retire-spec-bridge-6366.md`, there is no `spec-bridge/`
+ * directory, and the only `mapField` hits are `mapFieldTypeToFormType` in
+ * `app-shell`, a different symbol. The citation survives in this repo's older
+ * neighbouring comments (the #12174 block in `ui/view.zod.ts` and its test),
+ * inherited from `liveness/view.json`'s 2026-08-26 reading at objectui@f7c52e2;
+ * it was carried forward once into this card and corrected here. The
+ * plugin-form route above carries the premise on its own.
+ *
+ * A second file needing the same number left three ways to share it, each with
+ * its own price:
+ *
+ * 1. **Duplicate the literal** in `view.zod.ts` — cheapest edit, and it records
+ *    one platform fact in a second place with nothing holding the two equal.
+ * 2. **Promote `MAX_RENDERABLE_SCALE` out of `field.zod.ts` as a published
+ *    export** — `data/index.ts` re-exports that file with `export *`, so the
+ *    constant would land on the `@objectstack/spec/data` surface: a new export
+ *    (`Clause-②: yes`, at least `minor`, and a contract-tier review) bought for
+ *    one bound, on a file another card holds.
+ * 3. **This module** — a `src/shared/` leaf that is deliberately absent from
+ *    `shared/index.ts`, so it reaches no package entry and no `api-surface`
+ *    snapshot. It is the established shape for spec-internal constants
+ *    (`strict-object.ts`, `editability-boundary.ts`, `union-branch-policy.ts`
+ *    are the same kind), it imports nothing so it cannot participate in a
+ *    cycle, and adopting it costs a consumer one import line.
+ *
+ * Route 3 is what landed. `data/field.zod.ts` still carries its own private
+ * copy of both values, because the surface #19088 was dispatched against is
+ * `ui/view.zod.ts` alone — this module is the home that copy can move into
+ * later as a pure delete-and-import, with no export and no review to buy. Until
+ * it does, the two are held equal from the other end: the pin beside
+ * `FormFieldBaseSchema.scale` asserts its refusal text is byte-identical to the
+ * one `FieldSchema.scale` produces, so a drift between the copies is a red
+ * test rather than two divergent messages for one platform limit.
+ *
+ * The consumer-side half of the same fact lives in `packages/objectql` as its
+ * module-private `MAX_FORMULA_SCALE` (it skips formula rounding past the
+ * ceiling so a display declaration can never fail a read). That one is
+ * deliberately not folded in here either: `packages/spec` may not depend on a
+ * consumer package.
+ */
+
+/**
+ * The largest `scale` (decimal places) every conforming renderer can honour.
+ * Both platform primitives throw `RangeError` above it.
+ */
+export const MAX_RENDERABLE_SCALE = 100;
+
+/**
+ * The refusal text for a `scale` past {@link MAX_RENDERABLE_SCALE}. It names
+ * WHY, so an author reads a platform limit they can verify rather than an
+ * arbitrary cap somebody chose. Every occurrence of the number is derived from
+ * the constant, so the prose cannot drift from the bound it explains.
+ */
+export const SCALE_UPPER_BOUND_MESSAGE =
+  'Decimal places cannot exceed ' + MAX_RENDERABLE_SCALE + ' — the limit is the renderers\', not a policy: every consumer '
+  + 'turns `scale` into fraction digits, and both `Number.prototype.toFixed` and '
+  + '`Intl.NumberFormat`\'s `maximumFractionDigits` throw a RangeError above ' + MAX_RENDERABLE_SCALE + ', so a larger '
+  + 'declaration is unrenderable rather than merely large. Declare at most ' + MAX_RENDERABLE_SCALE + ' (an IEEE-754 '
+  + 'double carries ~17 significant digits, so a meaningful display precision is far below it).';