[os-bill]

Fixes #18972

Clause-②: no (narrowing)

FieldSchema.scale was declared as any non-negative integer with no upper bound, while every
renderer that turns it into fraction digits hits a hard platform ceiling of 100. Both declarations
of scale in packages/spec/src/data/field.zod.ts now carry that ceiling, with a refusal that says
why — it names the two primitives, the RangeError and the legal maximum — so an author reads a
platform limit they can verify rather than a cap somebody chose.

Evidence below is measured on this branch at 2d62629edf, base origin/main = 176b03582e.

The platform fact the bound rests on

There is no reusable decimal-digit ceiling constant in packages/spec, so the number is newly minted
here and its justification has to be the platform. Measured first-hand this round, node v22.22.2:

probe	reading
(1.5).toFixed(100)	ok
(1.5).toFixed(101)	RangeError: toFixed() digits argument must be between 0 and 100
new Intl.NumberFormat(undefined, { maximumFractionDigits: 100 })	ok
new Intl.NumberFormat(undefined, { maximumFractionDigits: 101 })	RangeError: maximumFractionDigits value is out of range.

The boundary is exactly 100, reproducing objectui#9808's reading rather than carrying it through. A
unit test re-measures both primitives on every run and asserts the schema's own accept/refuse
boundary sits on the same number, so the literal is never trusted on its own: if a future runtime
moves either limit, the pin goes red and the declaration is re-argued.

Corroboration from inside this repo: packages/objectql/src/engine.ts:994 already holds
const MAX_FORMULA_SCALE = 100, whose docblock reads "FieldSchema.scale is z.number().int().min(0)
with no upper bound, so an author CAN declare more — and a display-precision declaration must never be
the reason a read fails." That is the consumer-side half of this same fact, written as a defence. This
PR is the producer-side half. The two are deliberately not one import: packages/spec may not depend
on a consumer package, and the new constant is module-private so no published API surface moves.

The dispatch's open question, answered: BOTH sites in this file are bounded

The file carries two scale declarations. The card names only FieldSchema.scale; whether the
grid-column one reaches the same renderers was left to be measured. It does, by a different primitive,
so both are bounded:

declaration	the reader it reaches	primitive
InlineGridColumnSchema.scale (field.zod.ts:882 at the base)	objectui computeRow, packages/fields/src/widgets/GridField.tsx:322 — next[c.name] = scale != null ? Number(v.toFixed(scale)) : v	toFixed
FieldSchema.scale (field.zod.ts:1158 at the base)	objectui number cell renderer, packages/fields/src/index.tsx:747 — maximumFractionDigits: scale ?? 20	Intl.NumberFormat

The link for the first row is not an inference: InlineGridColumnSchema's own docblock declares it a
"STRICT mirror of the objectui inline-grid renderer's GridColumn (packages/fields/src/widgets/GridField.tsx)",
and GridColumn.scale is the value computeRow hands to toFixed. Measured in the sibling checkout
../objectui at dda8f3815d. Two declarations, two renderers, one ceiling.

Acceptance legs

Subject. scale: 100 parses; scale: 101 is refused at both sites with a too_big issue at
[scale] whose message names toFixed, maximumFractionDigits, RangeError and the legal maximum.

Lit control (the same probe before the change). At 176b03582e, both sites answered scale: 101
with PASS — so this round demonstrably narrowed something, and the probe was never dead.

Dark control. scale: -1 and scale: 2.5 were refused before and are refused after, for the same
reasons, with the same codes and the same wording: too_small / "Too small: expected number to be >=0"
and invalid_type / "Invalid input: expected int, received number". The #8321 refusals are untouched;
only the top of the range moved.

Zero-hit reading, with its radius. Zero scale declarations above 100 exist in this repository —
git grep over all tracked files, 123 scale: N declarations as the lit control, 0 above 100. The
instrument's reachable radius is this repository's tracked file contents at 2d62629edf. A known
target necessarily outside it: a sys_metadata row already stored in a running deployment's database,
which no in-repo instrument can read. Triage recorded the same blind spot on this card.

What this PR deliberately does not touch

• No renderer, no clamp, no fallback. Refusing an unrenderable declaration at the door is this
  card; what a renderer should do when handed a large value is not, and stays objectui#9808's.
• CurrencyConfigSchema's alias table is untouched. Its scale maps to precision on a different
  surface with its own bounds; the file's own comment says "do not conflate", and a pin asserts the
  currency config still accepts precision: 10.
• precision is not bounded. It is a total digit count and reaches neither primitive, so the
  renderer-ceiling argument does not carry to it. A pin records that the omission was measured rather
  than missed.
• objectui is not changed — read only, for the two renderer readings above.

Verification

command	result
pnpm --filter @objectstack/spec build	exit 0
pnpm --filter @objectstack/spec test	exit 0 — 492 files, 14490 tests passed
pnpm --filter @objectstack/spec exec vitest run src/data/field.test.ts src/data/inline-related-columns.test.ts	exit 0 — 284 tests passed
pnpm --filter @objectstack/spec check:generated	exit 0 after --fix regenerated content/docs/references/** (gen:docs) — the two scale descriptions, nothing else
node scripts/check-adr-0087-registration.mjs --base origin/main	exit 0 — one declared-breaking changeset, disposition not-required (no-migration-prescription)
node scripts/check-changeset-no-major.mjs --base origin/main	exit 0
gate families from node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack	every command run, exit code captured before any pipe; see the report for the NOT MEASURED residue

Seven of the derived gate commands could not measure anything in this container: they read built
dist/ of packages this diff does not touch (check:dual-build-cjs-loads, check:lean-entry-closure,
check:docs-transcript-drift, check:type-check-debt, the two @objectstack/lint doc gates, and
check:skill-examples), and each exits with its own PREREQUISITE NOT MET verdict rather than a
finding. They are recorded as NOT MEASURED, not as green; CI builds the closure and runs them for real.

Changeset

skip-changeset does not hold and no label is written: @objectstack/spec publishes dist in its
files[], and this diff changes what that published artifact accepts at runtime. The changeset is a
minor carrying the BREAKING banner and the ADR-0087 disposition, per the launch-window
convention in which major is refused and breaking-ness rides the banner rather than the level.

Acceptance notes

• A third site, measured and deliberately left out of this diff.
  packages/spec/src/ui/view.zod.ts:2768 (FormFieldBaseSchema.scale, the form-row override) carries
  the byte-identical unbounded declaration and reaches the same Intl.NumberFormat renderer — its own
  neighbouring comment states that objectui reads every one of these keys off the form row, copied onto
  the runtime field by form-view.ts mapField and plugin-form sectionFields.ts. The card records
  it as a reading it did not fold into its claim, and the dispatch's declared file surface is
  field.zod.ts only, so widening this diff to a second file would move a surface the claim does not
  name — the instrument this repo uses to keep parallel agents off each other's files. It is reported
  back for a decision rather than fixed silently; the fix is one line plus the shared constant, which
  would have to be promoted out of field.zod.ts at that point (a new export, so that PR declares
  clause ② yes).
• noted, not filed: precision is bounded on one arm and unbounded on two others.
  CurrencyConfigSchema.precision is .max(10); FieldSchema.precision and
  FormFieldBaseSchema.precision have no maximum. No renderer-ceiling argument applies to any of them,
  and whether the three should agree is a judgement about three different field arms. Successor: the
  same seat that takes the view.zod.ts site above, since it is one line away from both.
• noted, not filed: MAX_FORMULA_SCALE and this file's bound now record one platform fact twice.
  Both are module-private and the dependency direction forbids sharing (objectql depends on spec,
  not the reverse), so the duplication is structural rather than an oversight. Successor: none today —
  it would take a shared constants entry point on the published surface, which is a wider decision than
  this card.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/spec, touching 4 documentable anchor(s).

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

• content/docs/concepts/metadata-driven.mdx (via FieldSchema (symbol, a top-level const))
• content/docs/data-modeling/external-datasources.mdx (via FieldSchema (symbol, a top-level const))
• content/docs/data-modeling/field-types.mdx (via FieldSchema (symbol, a top-level const))
• content/docs/data-modeling/validation-rules.mdx (via FieldSchema (symbol, a top-level const))
• content/docs/deployment/troubleshooting.mdx (via FieldSchema (symbol, a top-level const))
• content/docs/deployment/validating-metadata.mdx (via FieldSchema (symbol, a top-level const))
• content/docs/getting-started/quick-reference.mdx (via FieldSchema (symbol, a top-level const))
• content/docs/kernel/contracts/data-engine.mdx (via FieldSchema (symbol, a top-level const))
• content/docs/protocol/backward-compatibility.mdx (via FieldSchema (symbol, a top-level const))
• content/docs/protocol/objectql/types.mdx (via FieldSchema (symbol, a top-level const))
• content/docs/protocol/objectui/concept.mdx (via FieldSchema (symbol, a top-level const))
• content/docs/ui/forms.mdx (via FieldSchema (symbol, a top-level const))

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

• content/docs/releases/v17/17-0.mdx (via FieldSchema (symbol, a top-level const))
• content/docs/releases/v17/17-1.mdx (via FieldSchema (symbol, a top-level const))

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 60 of 215 client-bound route-ledger rows — the other 155 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 155: 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; 100 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 — 136 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 176b03582e600ee5628d21bff9422073c5a5530c → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 6e941dd9543c84dfc127b2151da8db72ca49da31 — the merge of head 2d62629edf61c38b38a1d6c8c9cfbc881adb1f21 into base 176b03582e600ee5628d21bff9422073c5a5530c, 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 6e941dd9543c84dfc127b2151da8db72ca49da31 && git checkout 6e941dd9543c84dfc127b2151da8db72ca49da31
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 176b03582e600ee5628d21bff9422073c5a5530c 2d62629edf61c38b38a1d6c8c9cfbc881adb1f21 && git checkout -B drift-repro 176b03582e600ee5628d21bff9422073c5a5530c && git merge --no-ff 2d62629edf61c38b38a1d6c8c9cfbc881adb1f21

node scripts/docs-audit/affected-docs.mjs --json 176b03582e600ee5628d21bff9422073c5a5530c

⚠️ 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 176b03582e600ee5628d21bff9422073c5a5530c → pass the list as
args.docs, on the commit named under Which tree this was computed on.