Ruled: 5933283974 · letter A (deferred) · 2026-10-01T14:14Z
Filing-gate category: ① a derived item of the in-flight card objectui#9843, filed by its claiming seat, domain:ui seat 2 (session_011p7ikEivgXefNDaE5S5Uec). It is the unexecuted remainder of a recorded ruling, so it is not lost when objectui#9843 closes. Reader who acts: triage first. It grades and routes the card, and decides whether the design question below needs a ruling. Then the domain:ui seat that dispatches it. ⛔ Not graded here.
Dedup: the 1,000 most recently updated objectui issues and PRs (open and closed, down to #10467), read through REST and grepped locally.
ObjectMetricWidget gives 18 hits. None is about width: they are the I18nLabel family, refresh and arm cards, and PR objectui#11246 itself.- A metric tile or widget within 80 characters of
scale gives 0 hits.
19628 gives 1 hit, PR objectui#11246.
The ruling it completes
objectstack-ai/objectstack#19628 was ruled A′ (ruling 5791809146, batch #215 item 2, maintainer 「215 同意」). The pointer on objectui#9843 (5791883815) states what it asks of objectui's consumers:
number has no absent-scale row, so absent means no fixed width, and every consumer deletes its private ?? 0 and reads through resolveFieldScale;- computed results (the summary footer and the metric widget) round to "the widest decimal count among the values that entered the computation — derived from the data, ⛔ never a constant".
PR objectui#11246 (objectui#9843) executes this for the percent faces and the grid's summary footer. Its dev reported the metric-widget half as outside that claim (report 5916318159, open_questions[1]). Contract review 5916522120 ③ agreed that the half should be filed on its own.
What is there today (read at objectui origin/main, packages/plugin-dashboard/src/ObjectMetricWidget.tsx)
- The tile infers a pattern from the field type:
'0,0%' for percent, '0,0' for number / integer. Elsewhere it picks '0,0' or '0,0.00' by whether the amount is an integer.
- A comment in the file says it no longer builds a pattern from
valueFieldDef.scale ?? 0. So the pointer's ?? 0 reference has drifted: the tile now reads no width at all, declared or resolved.
- Read at source, not measured: a percent field that declares
scale: 2 gets a whole-percent pattern on the tile, while the list cell, the detail chip, the footer and the widget read its declared width after PR objectui#11246. A number field with no declared width gets a constant pattern, not the width the ruling derives from the data.
Why it needs its own design (not dispatchable on the ruling text alone)
The tile renders a server aggregate (sum, avg, count and so on). The ruling's "widest decimal count among the values that entered the computation" needs those values' widths, and the tile never sees the input rows. Whoever acts must decide where that width comes from, from options such as:
- the declared
scale when declared, and otherwise a width the aggregate query reports;
- the aggregate's own natural precision;
- an explicit tile format on the widget.
Some of these touch the query or the spec. ⛔ Not a constant, per the ruling.
Reach
No first-party producer was found: no object-metric over a number or percent field. The examples' metrics are dataset-backed and go through formatMeasure. It is a ruled item, not a measured defect, so a low grade fits. It is filed so the recorded ruling is tracked.
The rest of ruling A′'s "no ?? N in any consumer", tracked here in one place
From report 5916318159, confirmed as carrier notes by review 5916522120 ③. Percent faces outside objectui#9843's claim:
- the
ObjectGantt percent case and the ObjectGrid mobile card. Both pass undefined to formatPercent, whose precision = 0 default coincides with the protocol's percent row today. The mobile card also classifies percent by a column-name substring.
GroupRow group-header aggregates: a type-blind toFixed(2), with no unit.formatPercent's own precision = 0 parameter default, still reached for progress, for fields promoted by format: 'percent', and by the two callers above. Retiring it needs those callers on the resolver, and a protocol answer for progress.
Dedupe words: ObjectMetricWidget scale width · metric tile widest decimal computed result · ruling A prime 19628 metric half · formatPercent precision default callers
Generated by Claude Code
Ruled: 5933283974 · letter A (deferred) · 2026-10-01T14:14Z
Filing-gate category: ① a derived item of the in-flight card objectui#9843, filed by its claiming seat,
domain:uiseat 2 (session_011p7ikEivgXefNDaE5S5Uec). It is the unexecuted remainder of a recorded ruling, so it is not lost when objectui#9843 closes. Reader who acts: triage first. It grades and routes the card, and decides whether the design question below needs a ruling. Then thedomain:uiseat that dispatches it. ⛔ Not graded here.Dedup: the 1,000 most recently updated objectui issues and PRs (open and closed, down to #10467), read through REST and grepped locally.
ObjectMetricWidgetgives 18 hits. None is about width: they are the I18nLabel family, refresh and arm cards, and PR objectui#11246 itself.scalegives 0 hits.19628gives 1 hit, PR objectui#11246.The ruling it completes
objectstack-ai/objectstack#19628 was ruled A′ (ruling
5791809146, batch #215 item 2, maintainer 「215 同意」). The pointer on objectui#9843 (5791883815) states what it asks of objectui's consumers:numberhas no absent-scalerow, so absent means no fixed width, and every consumer deletes its private?? 0and reads throughresolveFieldScale;PR objectui#11246 (objectui#9843) executes this for the percent faces and the grid's summary footer. Its dev reported the metric-widget half as outside that claim (report
5916318159,open_questions[1]). Contract review5916522120③ agreed that the half should be filed on its own.What is there today (read at objectui
origin/main,packages/plugin-dashboard/src/ObjectMetricWidget.tsx)'0,0%'forpercent,'0,0'fornumber/integer. Elsewhere it picks'0,0'or'0,0.00'by whether the amount is an integer.valueFieldDef.scale ?? 0. So the pointer's?? 0reference has drifted: the tile now reads no width at all, declared or resolved.scale: 2gets a whole-percent pattern on the tile, while the list cell, the detail chip, the footer and the widget read its declared width after PR objectui#11246. Anumberfield with no declared width gets a constant pattern, not the width the ruling derives from the data.Why it needs its own design (not dispatchable on the ruling text alone)
The tile renders a server aggregate (sum, avg, count and so on). The ruling's "widest decimal count among the values that entered the computation" needs those values' widths, and the tile never sees the input rows. Whoever acts must decide where that width comes from, from options such as:
scalewhen declared, and otherwise a width the aggregate query reports;Some of these touch the query or the spec. ⛔ Not a constant, per the ruling.
Reach
No first-party producer was found: no
object-metricover anumberorpercentfield. The examples' metrics are dataset-backed and go throughformatMeasure. It is a ruled item, not a measured defect, so a low grade fits. It is filed so the recorded ruling is tracked.The rest of ruling A′'s "no
?? Nin any consumer", tracked here in one placeFrom report
5916318159, confirmed as carrier notes by review5916522120③. Percent faces outside objectui#9843's claim:ObjectGanttpercentcase and theObjectGridmobile card. Both passundefinedtoformatPercent, whoseprecision = 0default coincides with the protocol's percent row today. The mobile card also classifies percent by a column-name substring.GroupRowgroup-header aggregates: a type-blindtoFixed(2), with no unit.formatPercent's ownprecision = 0parameter default, still reached forprogress, for fields promoted byformat: 'percent', and by the two callers above. Retiring it needs those callers on the resolver, and a protocol answer forprogress.Dedupe words:
ObjectMetricWidget scale width·metric tile widest decimal computed result·ruling A prime 19628 metric half·formatPercent precision default callersGenerated by Claude Code