finding(types): PercentFieldMetadata declares precision and NOT scale — after objectui#9804 the widget reads only scale, so the published face offers the one member that does nothing #9807

Surfaced by the os-dev implementing objectui#9568 (PR objectui#9804) as an out-of-scope finding, and filed by the dispatching domain:ui seat 3 (session_01Xm4WFhEe5mwcgyqHjxR2hn) because the dev correctly declined to fix it in place. ⛔ Not graded and ⛔ not routed by me — domain:*, type and priority:* are the triage seat's sole production.

The fact — re-derived at source by this seat on origin/main, ⛔ not taken from the report

packages/types/src/field-types.ts:427-432:

export interface PercentFieldMetadata extends BaseFieldMetadata {
  type: 'percent';
  precision?: number;
  min?: number;
  max?: number;
}

⇒ no scale member. The control sits 25 lines above it, NumberFieldMetadata at :402-410, which declares both and documents the distinction in its own words:

  /** Total number of digits (the `p` in a `decimal(p, s)` column). Not a display setting. */
  precision?: number;
  /** Number of decimal places to display (the `s` in a `decimal(p, s)` column). */
  scale?: number;
  step?: number;

Why this is the trap shape rather than a tidiness item

After PR objectui#9804, PercentField reads scale for its decimal-place width and no longer reads precision at all. So the published authoring interface for a percent field now offers exactly one of these two members — the one that does nothing — and omits the one the widget actually reads.

An author reading PercentFieldMetadata to find out how to control a percent field's decimal places is offered precision. Declaring it produces no effect. The member that works is undeclared, so declaring scale is what an author has to guess, against a published type that does not admit it. The sibling interface one screen up spells out that precision is "Not a display setting" — so the correct answer is documented in this very file, for a different field type.

⚠️ It is plausibly the root cause of objectui#9568 itself: the widget read precision because precision is what the percent metadata face declares.

Secondary, measured on the same read: the two detail hosts that build the inline-edit field bag (RecordDetailPanel and RelatedList) already forward scale beside precision, and PercentField reaches it through a field as any cast. The cast is what lets the working member bypass the declaration — so the type face and the runtime behaviour disagree with no compiler anywhere to notice.

Why the objectui#9568 dev did not fix it in place, and why this seat agrees

Widening an exported type is a public-face change: it would have flipped that card's Clause-②: no declaration, and packages/types was outside its declared file surface. ⛔ Correctly fenced out rather than ridden along.

Dedup words

PercentFieldMetadata scale missing · percent field metadata precision only · types field-types percent scale · PercentFieldMetadata precision declared · percent metadata scale undeclared

⛔ Not deduped by me (filer attaches the words, triage runs them). ⚠️ Search on this board has produced false zeros before — any zero needs a lit control, and dedup must include CLOSED cards.

Provenance

out_of_scope_findings of the objectui#9568 dev report (comment 5726124637), class (c). Every code reading above was verified independently by this seat on origin/main before filing.

Generated by Claude Code