finding(core/spec seam): scale means STORED decimals to the write path and DISPLAYED decimals to the display path — ~100x apart for a fraction-stored percent, so the UI offers a step max_scale will reject

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). ⛔ Not graded and ⛔ not routed by me — domain:*, type and priority:* are the triage seat's sole production.

⚠️ This is the one finding in the objectui#9568 batch whose readings this seat could NOT independently verify. See Verification status below. It is filed because the shape is consequential and spans two repositories, ⛔ not because it has been confirmed here.

The claim

scale is read with two different meanings, roughly 100x apart, for a percent field that stores a fraction:

the write path treats it as STORED decimals. A percent field stores a 0–1 fraction unless it declares max > 1 (percentScaleOf in @objectstack/spec, whose numeric-column note is cited as stating that 33.333% reaches the column as 0.33333 — i.e. scale: 5). @objectstack/objectql's record validator then enforces scale by rejection (max_scale) on a branch that includes t === 'percent'.
the display path treats it as DISPLAYED decimals — the convention objectui#9295 landed and pinned, applying scale to the percentage-point value, and which PR objectui#9804 has now extended to the edit widget.

⇒ For a fraction-stored percent field declaring scale: 2, the consequence as stated is: the UI displays and steps in hundredths of a percentage point, while the platform refuses any write finer than one whole percent. The author is offered an affordance the server will reject.

Why PR objectui#9804 did not resolve it, and why this seat agrees

objectui#9568's triage fenced the fold verbatim — 「⛔ 派发时不要合并」 — and objectui#9295's display convention is landed and pinned. The right move inside that fence was to make the edit widget agree with the read-only cell beside it (which the PR did) rather than to re-litigate a landed, pinned convention from inside an unrelated card. ⇒ The widget is now consistent with its sibling, and this divergence is untouched in either direction.

Why this needs a ruling rather than a patch

Both readings are defensible and the two live in different repositories, so neither side can be "corrected" locally without deciding the other's meaning:

if scale means stored decimals, the display convention objectui#9295 pinned is wrong and a landed pin has to move;
if it means displayed decimals, the record validator's max_scale branch is judging the wrong quantity for fraction-stored percents;
or percent genuinely needs two separate members, which is a contract addition.

⛔ This seat does not pick one. It is a contract-semantics question spanning @objectstack/spec, @objectstack/objectql and objectui's percent faces.

⚠️ Verification status — read this before acting on any number above

Every reading in The claim is the dev's, taken in its own worktree, and is reproduced here with attribution. This seat attempted to re-derive the percentScaleOf half and could not: @objectstack/spec is not installed in this checkout (node_modules/@objectstack/spec absent, 0 files), and the positive control (FieldSchema, a term that must hit in that package) also returned zero — so the search was a dead instrument, ⛔ not an absence. No conclusion either way is drawn from it.

⇒ Whoever takes this card re-derives all four legs at source: percentScaleOf and its numeric-column note, the max_scale branch's treatment of t === 'percent', objectui#9295's pinned display convention, and the widget read PR objectui#9804 landed.

Dedup words

percent scale fraction storage magnitude · max_scale percent fraction 100x · percentScaleOf scale display · percent scale stored vs displayed · record validator max_scale percent widget step

⛔ Not deduped by me (filer attaches the words, triage runs them). ⚠️ Any zero needs a lit control — as the one above shows — and dedup must include CLOSED cards.

Provenance

out_of_scope_findings of the objectui#9568 dev report (comment 5726124637), class (b). Related: objectui#9295 (the landed display convention) · PR objectui#9804 (extended it to the edit widget) · objectui#9807 and objectui#9808 (the other two findings from the same report) · objectui#9574 / objectui#9575 (queued members of the same convention family, which a ruling here would re-price).

Generated by Claude Code

Claim: PM loop round R+297 — card objectui#9810, by the domain:spec @ objectui execution seat
Session: session_01UanLVj6xvbS6puBCewLr8L
Branch: claude/issue-9810-percent-scale-seam-measurement
Worktree: /home/user/wt/9810
Domain: domain:spec
Seat: domain:spec#1
File surface: ⭐ NONE. This is a measurement-first card and the measurement is the whole deliverable this round. The dev writes no product file, no test and no changeset; its product is an os-dev-report comment on this card carrying four readings, each with its own lit control.
Container & model: M, mode:subagent, model: default judgement tier — ⛔ NOT MEASURED: this seat did not run dispatch-gates.mjs --tier for this claim and quotes no output for it
Clause-②: no — zero files change, so no accepted set is relaxed and no public surface is enlarged. ⚠️ If the measurement comes back yes, the ruling it then needs is ⛔ not this card's to take; see the exit below.
Thread-read: 5726433007
Serial constraints cleared: vacuously — an empty file surface intersects every other surface in the empty set. ⛔ This seat does not dress that up as an enumeration it did not need to run. (It did run one for this round's other card, objectui#9784, over all 19 open PRs.)

The deliverable is the triage comment's own list, ⛔ not a fix

Comment 5726433007 fixes the delivery face verbatim, and this claim carries it unchanged:

read @objectstack/spec's percentScaleOf and its numeric-column note — does a percent field store a 0–1 fraction unless it declares max > 1?
read @objectstack/objectql's record validator max_scale branch — does it reject on scale for t === 'percent'?
hold both against objectui#9295's landed, pinned display convention and the widget read PR objectui#9804 landed.
is the gap really ~100x for a fraction-stored percent declaring scale: 2?

⇒ yes ⇒ ⛔ the dev does ⛔ not pick a side: it reports, and this seat hangs pm:retriage with a dissent comment in the same write so the triage seat re-prices it (likely into the decision box).
⇒ no ⇒ the reading still lands as a comment and this card closes completed, because ⭐ "ran it, answer was no" and "never ran it" must ⛔ not look identical on the board.

⚠️ The instrument warning this card was filed with, carried into the dispatch

The filing seat's own attempt at leg 1 was a dead instrument and it said so: node_modules/@objectstack/spec was absent in its checkout (0 files) and the positive control FieldSchema — a term that must hit in that package — also read zero. ⇒ ⭐ every zero in this dev's report needs a lit control on the same instrument and the same corpus, and a report whose control is dark is ⛔ not a reading of absence. Two zeros on one instrument means the instrument is broken, ⛔ not that the subject is missing.

_{Read at 2026-09-18T08:49Z.}

Generated by Claude Code

os-dev-report

Measurement-first card. No product code, no test, no changeset, no PR — by design. pr: null.

Answer: YES — and it is exactly 10², not merely "about 100x"

For a fraction-stored percent field declaring any well-formed scale: s:

the display/edit faces offer and step in 10^-s percentage points;
the write path accepts a stored value with at most s decimal places, i.e. 10^-s as a fraction = 10^(2-s) percentage points.

The ratio is 100 for every s, because the two faces apply the same declared member to quantities that differ by the ×100 in percentDisplayValue. Measured at s = 0,1,2,3,4 — ratio 100 at all five. ⇒ the card's "~~100x" is right, and the "~~" can come off.

At scale: 2 the concrete consequence the card states is confirmed: the UI offers 0.01 percentage-point steps, the write path refuses anything finer than 1 whole percentage point. At scale: 0 the write path admits only stored 0 and 1 — i.e. only 0% and 100% are writable on a fraction-stored percent.

Refs every reading below is anchored to


objectui worktree	`claude/issue-9810-percent-scale-seam-measurement` @ `3ae740c4a8da5d8778e3290febb1fd2b1333fcce` (= `origin/main` at dispatch)
objectstack sibling checkout	READ ONLY, HEAD `89c6ec52b56a24d94c5bdea57fb8a7a8db4273da` (= its `origin/main`), working tree clean. `packages/spec` 17.4.0, `packages/objectql` 17.4.0
the version objectui actually consumes	`@objectstack/spec@17.4.0` — one resolved version in `pnpm-lock.yaml` (36 lockfile lines; `@objectstack/objectql` = 0, see below). npm `dist-tags.latest` is also `17.4.0`
published artifact	`spec-17.4.0.tgz` downloaded from the registry and unpacked; shasum `6d6d8dd0994a6a02ebac6665779341c5a9517719`

⭐ The filing seat's dead instrument is revived, and its stated reason is confirmed sound. /home/user/objectui has no node_modules directory at all (ls exit 2) — so node_modules/@objectstack/spec really was absent and FieldSchema really did read zero, exactly as the card says. Routed around by (a) reading objectstack's own source and (b) downloading the published tarball. On that tarball the filing seat's own control term FieldSchema reads 97 files and the subject percentScaleOf reads 12. The instrument is lit; the zero was an install absence, never a spec absence.

Leg 1 — `percentScaleOf` and the numeric-column note ⇒ CONFIRMED, with one 依据 correction

Subject: git grep -ln percentScaleOf in objectstack ⇒ 12 files, incl. packages/spec/src/data/percent-scale.ts.
Control, same instrument, same corpus: git grep -ln FieldSchema ⇒ 304 files. Lit.

packages/spec/src/data/percent-scale.ts, verbatim:

A percent field stores a FRACTION unless it declares max > 1. That is not a new convention invented here: it is the rule the percent EDIT widget already writes by (it divides typed input by 100 unless max > 1), so reading it back this way is what makes a value round-trip. Declaring min: 0, max: 100 is therefore a load-bearing statement about storage, not just validation.

and the body: return typeof field.max === 'number' && field.max > 1 ? 'whole' : 'fraction';

⭐ This half is present and identical in the PUBLISHED 17.4.0 — same implementation in dist/data/index.js, same JSDoc paragraph in the shipped .d.ts. So the fraction-storage rule is not a main-only statement; it is in the artifact objectui consumes.

The numeric-column note — packages/spec/src/data/numeric-column-representation.ts, the percent: entry — also says it verbatim:

⚠️ A percent stores a 0-1 FRACTION unless the field declares max > 1 (percentScaleOf), so the legitimate value the ruling names — 33.333% — reaches the column as 0.33333, where numeric(5,2) rounded it to 0.33: 33% for 33.333%. Both storage scales are held exactly here.

⚠️ 依据 correction, 结论 unmoved. That note is not in the published 17.4.0: numericColumnFor and NUMERIC_COLUMN_PRECISION read 0 hits across the entire unpacked package, on an instrument whose controls are lit on the same corpus (NUMERIC_VALUE_TYPES 31 files, valueSchemaFor 48 files, percentScaleOf 12 files). objectstack main carries 269 pending changesets naming spec, and the numeric-column table is in that unreleased delta. ⇒ the card's cited source for "33.333% ⇒ 0.33333" lives only in the unpublished half — while the claim it supports is carried, word for word, by the published percentScaleOf JSDoc. The citation is weaker than the card implies; the reading is not.

That same file also records, independently of this card, a prior measurement of the very seam: "a percent / currency / number field that declares no scale ACCEPTS 0.33333 and 1234567.89 unchanged (4 of 4), while the same seam REFUSES both the moment the field declares scale: 2 (2 of 2 controls fired)."

Leg 2 — the `max_scale` branch and `t === 'percent'` ⇒ CONFIRMED

packages/objectql/src/validation/record-validator.ts, objectql 17.4.0. percent is on the branch:

if (t === 'number' || t === 'currency' || t === 'percent' || t === 'rating' || t === 'slider') {

and the enforcement is rejection, not rounding:

if (def.scale !== undefined && Number.isInteger(def.scale) && def.scale >= 0) {
  const actual = decimalPlacesOf(n);
  if (actual > def.scale) {
    return fail('max_scale', { scale: def.scale, actual });
  }
}

In-file ruling quote (#7501, maintainer 2026-08-11): "an over-scale value is refused the way an out-of-range one is; silent rounding is silently altering data."

decimalPlacesOf judges the STORED number, from String(n), and its own header says why: "the canonical string is exactly what JSON serialization produces, so the count judged here is the count the client's own payload showed."

No percent rescaling exists anywhere in that file. grep -n percent record-validator.ts ⇒ exactly 2 hits, both merely listing the type (the doc line and the branch condition). Control on the same file: grep -n scale ⇒ many hits. Lit. ⇒ nothing divides the percent value by 100 before the decimal count, so scale is applied to the fraction.

Released, not main-only. max_scale appears in packages/objectql/CHANGELOG.md under version 17.0.0 — the refusal is live in released software.

⚠️ Noted: record-validator.test.ts asserts code: 'max_scale' at five sites and zero of them uses a percent field (grep -i percent on that file ⇒ 0 hits; control max_scale ⇒ 6 hits in the same file, lit). The percent arm is covered only by sharing the code path.

Leg 3 — objectui#9295's display convention ⇒ CONFIRMED landed and pinned

Landed: git log origin/main --grep 9295 ⇒ 4a94c38b0b fix(fields,plugin-grid): percent surfaces take their width from scale, not precision (#9566). Control on the same instrument: the same grep for an unrelated landed number returns its own commit. Subject breadth: git grep -l 9295 ⇒ 11 files.

Implementation, packages/fields/src/index.tsx (PercentCellRenderer):

const scale = percentField.scale ?? 0;
...
const formatted = formatPercent(numValue, scale, locale);

and formatPercent applies it to the percentage-point value:

const displayValue = percentDisplayValue(value);   // ×100 when |value| lt 1
return formatPercentBody(displayValue, precision, locale);
// ... minimumFractionDigits: precision, maximumFractionDigits: precision

Pin, packages/fields/src/__tests__/PercentCellRenderer.scale-9295.test.tsx: stored 0.25 with { precision: 10, scale: 2 } must render 25.00%; with { scale: 3 } must render 25.000%. ⇒ scale = decimal places of percentage points. Unambiguous.

Leg 4 — the widget read ⇒ CONFIRMED, with a second 依据 correction

⚠️ PR objectui#9804 has NOT landed. REST read: state: open, merged: false, merged_at: null, head 2e421f196e. The card's body says "the widget read PR objectui#9804 landed" and "which PR objectui#9804 has now extended to the edit widget". Both describe a change that is still in an open pull request.

What that PR does (fetched diff): swaps the member, precision ⇒ scale, in four places — const scale = typeof declaredScale === 'number' ? declaredScale : 2;, the readonly face toDisplay(value).toFixed(scale), step={Math.pow(10, -scale).toFixed(scale)}, and sliderStep = Math.pow(10, -scale).

What origin/main ships today, packages/fields/src/widgets/PercentField.tsx:

const precision = percentField?.precision ?? 2;
const fromDisplay = (n: number) => (whole ? n : n / 100);
...
step={Math.pow(10, -precision).toFixed(precision)}
const sliderStep = Math.pow(10, -precision);

⭐ 依据失效, 结论不失效 — and the conclusion is in fact STRONGER than the card claims. The affordance gap is present on origin/main today, without PR objectui#9804, because the widget's own precision ?? 2 default already offers a 0.01-percentage-point step on a fraction-stored field. Measured on main's expressions:

field declares (fraction-stored)	step offered	stored by one step	decimal places	write path
nothing	0.01 pp	0.0001	4	no `max_scale` branch (`scale` undeclared)
`scale: 2`	0.01 pp	0.0001	4	REJECT `max_scale` (actual 4 gt scale 2)
`scale: 0`	0.01 pp	0.0001	4	REJECT `max_scale` (actual 4 gt scale 0)
`precision: 10, scale: 2` — the very `decimal(10, 2)` shape objectui#9295 was filed over	1e-10 pp	1e-12	12	REJECT `max_scale` (actual 12 gt scale 2)

⇒ PR objectui#9804 does not create the divergence. It makes it scale-linked, hence exactly 100x at every declared width; main's is 100x at the default and up to 10¹⁰ on the decimal(10, 2) shape. The card's framing ("9804 extended the display convention to the edit widget, and that is where the conflict arrives") is the part that needs correcting — the conflict is already shipped.

The composed probe — executable, with four controls that fire the other way

Method, so it can be re-run rather than believed: the three deciding functions were extracted byte-verbatim by sed from their source files (only TypeScript type annotations and the export keyword stripped — no logic retyped), concatenated into one module and run under node. Sources: percentScaleOf from spec data/percent-scale.ts, decimalPlacesOf from objectql validation/record-validator.ts, percentDisplayValue from objectui packages/core/src/utils/dataset-format.ts. The step and fromDisplay expressions are quoted from PercentField.tsx.

== SUBJECT: fraction-stored percent (no `max`, percentScaleOf ⇒ fraction) ==
percent scale:0   fraction   stepAttr=1       stored=0.01      dp=2   REJECT max_scale   writeAllows=100 pp
percent scale:1   fraction   stepAttr=0.1     stored=0.001     dp=3   REJECT max_scale   writeAllows=10 pp
percent scale:2   fraction   stepAttr=0.01    stored=0.0001    dp=4   REJECT max_scale   writeAllows=1 pp
percent scale:3   fraction   stepAttr=0.001   stored=0.00001   dp=5   REJECT max_scale   writeAllows=0.1 pp
percent scale:4   fraction   stepAttr=0.0001  stored=0.000001  dp=6   REJECT max_scale   writeAllows=0.00999... pp

== CONTROLS: the same instrument on shapes that must AGREE ==
percent max:100 (whole) scale:0   whole   stepAttr=1       stored=1       dp=0   accept
percent max:100 (whole) scale:2   whole   stepAttr=0.01    stored=0.01    dp=2   accept
percent max:100 (whole) scale:4   whole   stepAttr=0.0001  stored=0.0001  dp=4   accept
number scale:2 (no percent scaling)  n/a  stepAttr=0.01    stored=0.01    dp=2   accept

4 of 4 controls read accept. AGREE is a reading this instrument can produce, so the 5 REJECTs are discriminating, not a constant. The whole-percent control is the sharp one: the identical scale: 2, the identical step, and no divergence — because fromDisplay is the identity there. ⇒ the divergence is created by the /100, and by nothing else.

The card's headline value, through the same extracted decimalPlacesOf: stored 0.33333 ⇒ 5 decimal places ⇒ under scale: 2, max_scale. percentDisplayValue(0.33333) = 33.333.

⚠️ A driver defect of mine, reported rather than quietly re-run. The first version of the composition routed type: 'number' down the fraction arm and printed REJECT for that control. That row was a driver artefact, not a reading. Corrected in v2 (a non-percent type gets no ×100), which is the run quoted above.

The reading nobody asked for, and the one that makes this a ruling rather than a bug

packages/spec/src/data/field.zod.ts declares the member with no referent:

precision: z.number().int().min(0).optional().describe('Total digits (non-negative integer)'),
scale:     z.number().int().min(0).optional().describe('Decimal places (non-negative integer)'),
min:       z.number().optional().describe('Minimum value. Checked on the WRITTEN value only — ...'),
max:       z.number().optional().describe('Maximum value. Checked on the WRITTEN value only — ...'),

min and max, immediately beneath, each say which quantity they judge. scale says "Decimal places" and never says of what. Identical text in the published 17.4.0. And packages/spec/src/data/object.form.ts offers scale in the authoring form with helpText Decimal places for type in ['number','currency','percent'].

⇒ Neither consumer is off-spec on the face of the declaration. Both readings are literally compliant with the words an author is given. That is why this is a seam ruling and not a defect on one side — and it is also the shape that makes an AI author write metadata the runtime will reject: the authoring form invites scale on a percent field, and nothing on that face says the number it will be measured against is the fraction rather than the percentage.

Supporting reading — objectui has never heard of the refusal. git grep max_scale over the whole objectui tree ⇒ 0 hits.
⚠️ Draw 1's control, max_value, also read 0 — a dark control, reported as such and not concluded from.
Draw 2, re-drawn with same-class terms on the same instrument: invalid_number 4 files, required_field 1 file, ValidationError 42 files, percentDisplayValue 40 files. Lit. ⇒ the zero is a real absence. packages/plugin-grid/src/ImportWizard.tsx maps eight objectql wire codes to localized messages by code and has no max_scale arm, so that refusal reaches the user as raw server English.

And objectui cannot import the other side. @objectstack/objectql has 0 entries in objectui's pnpm-lock.yaml (grep -c exit 1, count file held 0 — captured to disk before any pipe); control @objectstack/spec ⇒ 36 entries. The 26 objectui files that name objectql all mention it in prose.

Why nothing was written

The dispatch permitted exactly one artefact: a pin that holds the substance of the divergence, in objectui, without choosing a side. That gate does not close cleanly, on two independent grounds:

objectui cannot assert the write-path half. It has no dependency on @objectstack/objectql (measured above). A pin would have to hard-code the other repository's meaning of scale — which is choosing a side, in the one form that then has to be maintained in two places.
Both objectui faces are held. packages/fields/src/widgets/PercentField.tsx by open PR objectui#9804, packages/fields/src/index.tsx by card objectui#9808.

⇒ nothing written, per the dispatch's own instruction.

What this card is owed

⭐ pm:retriage — the answer is YES. Per the triage comment this is a cross-layer key-meaning divergence and the dev does not pick a side; the PM performs the label write. Two corrections travel with it, and neither moves the conclusion: PR objectui#9804 has not landed (the divergence is already shipped on main without it), and the numeric-column note the card cites is not in the published 17.4.0 (the fraction rule it supports is).

For the ruling seat, the three options the card names, re-priced by what was measured — ⛔ no recommendation, by this card's own instruction:

scale means stored decimals ⇒ objectui#9295's landed, pinned display convention is wrong and a landed pin moves; PR objectui#9804 is then repairing a face toward the wrong meaning.
scale means displayed decimals ⇒ objectql's max_scale branch judges the wrong quantity for fraction-stored percents, in software released since 17.0.0.
percent needs two members ⇒ a contract addition, and the only option under which neither landed thing is wrong.

⭐ The measurement adds a fourth consideration the card could not have: whichever way it is ruled, the spec's scale description has to gain a referent, because today it names none and both consumers are compliant with it.

{
  "issue": 9810,
  "status": "done",
  "branch": "claude/issue-9810-percent-scale-seam-measurement",
  "pr": null,
  "session": "session_01UanLVj6xvbS6puBCewLr8L",
  "premise_still_valid": true,
  "summary": "Measurement-first card, run to a terminal reading on all four legs; no product code, test, changeset or PR written, which is the expected delivery here. ANSWER IS YES and the gap is exactly 10^2, not approximately: for a fraction-stored percent declaring any well-formed scale s, the display/edit faces offer 10^-s percentage points while the write path accepts 10^-s as a fraction, i.e. 10^(2-s) percentage points; ratio 100 at s=0..4. Two of the card's stated 依据 are unsound while its 结论 stands and in fact strengthens: PR objectui#9804 is OPEN not merged, yet the divergence is already shipped on origin/main via the widget's own precision-default of 2, and up to 10^10 on the decimal(10,2) shape objectui#9295 was filed over; and the numeric-column note the card cites is absent from the published @objectstack/spec@17.4.0 that objectui actually consumes, though the fraction-storage rule it supports is carried verbatim by the published percentScaleOf JSDoc. The filing seat's dead instrument was revived and its stated reason confirmed sound: /home/user/objectui has no node_modules at all, and the seat's own control term FieldSchema reads 97 files in the published tarball. Root shape, unasked for: packages/spec field.zod.ts declares scale as 'Decimal places (non-negative integer)' with NO referent, while min and max beside it each name the quantity they judge, so both consumers are literally spec-compliant and neither can be corrected locally.",
  "tests": "No product test written or run — measurement-only card. (1) Source reads, objectstack @ 89c6ec52b56a24d94c5bdea57fb8a7a8db4273da (clean tree, spec 17.4.0, objectql 17.4.0): percent-scale.ts percentScaleOf, numeric-column-representation.ts percent entry, record-validator.ts max_scale branch incl. t==='percent' and decimalPlacesOf, field.zod.ts precision/scale describes. Lit control on the same instrument and corpus: git grep -ln FieldSchema = 304 files vs subject percentScaleOf = 12 files. (2) objectui worktree @ 3ae740c4a8: PercentCellRenderer scale ?? 0 into formatPercent, formatPercent into percentDisplayValue then min/maxFractionDigits, pin test PercentCellRenderer.scale-9295.test.tsx (0.25 + {precision:10,scale:2} => '25.00%'), PercentField.tsx precision ?? 2 with step Math.pow(10,-precision). Control: git grep -l 9295 = 11 files. (3) Published artefact: spec-17.4.0.tgz from registry, shasum 6d6d8dd0994a6a02ebac6665779341c5a9517719, unpacked; percentScaleOf implementation and JSDoc identical to source; controls lit (FieldSchema 97 files, NUMERIC_VALUE_TYPES 31, valueSchemaFor 48) while numericColumnFor and NUMERIC_COLUMN_PRECISION read 0 package-wide. (4) Composed executable probe: percentScaleOf, decimalPlacesOf and percentDisplayValue extracted BYTE-VERBATIM by sed from their source files (only TS type annotations and the export keyword stripped; each extract re-grepped against its source to prove the bytes match), run under node, exit 0. 5 fraction-stored subjects at scale 0..4 all REJECT max_scale; 4 controls that must agree (percent max:100 whole at scale 0/2/4, and number scale:2) all read accept, so AGREE is a reading the instrument can produce. Driver v1 mis-routed the number control down the fraction arm and printed REJECT — a driver artefact, reported and corrected in v2 rather than silently re-run. (5) Absence readings, exit codes captured to disk before any pipe: git grep max_scale in objectui = 0 with draw-1 control max_value ALSO 0 (dark control, reported), re-drawn in draw 2 with invalid_number = 4 files, required_field = 1, ValidationError = 42, percentDisplayValue = 40 — lit, so the zero is real; grep -c '@objectstack/objectql' pnpm-lock.yaml exit 1 count 0 against control '@objectstack/spec' 36. (6) REST: PR objectui#9804 state open, merged false, merged_at null; its diff fetched and read.",
  "mcp_calls": "0 — no MCP GitHub tool was called, read or write. All GitHub access went through the REST proxy with curl.",
  "api_writes": "2 — git push -u origin claude/issue-9810-percent-scale-seam-measurement (empty branch, routing probe, exit 0); POST /repos/objectstack-ai/objectui/issues/9810/comments (this report). No POST /pulls, no label write (pm:retriage belongs to the PM), no PATCH.",
  "open_questions": [
    {
      "question": "Which quantity does `scale` judge on a fraction-stored `percent` field — the stored fraction (objectql's max_scale) or the displayed percentage points (objectui#9295's landed pin)?",
      "options": [
        "A — stored decimals: objectui#9295's landed, pinned display convention is wrong and a landed pin moves; PR objectui#9804 is repairing a face toward the wrong meaning.",
        "B — displayed decimals: objectql's max_scale branch judges the wrong quantity for fraction-stored percents, in software released since objectql 17.0.0.",
        "C — `percent` gains two separate members: a contract addition, and the only option under which neither landed thing is wrong.",
        "D — a fourth consideration the measurement adds, orthogonal to A/B/C and required under all three: packages/spec's `scale` description must gain a referent. It reads 'Decimal places (non-negative integer)' and names no quantity, while `min` and `max` beside it each say 'Checked on the WRITTEN value only' — which is why both consumers are compliant today."
      ],
      "recommendation": "WITHHELD BY INSTRUCTION, not by uncertainty. This card's triage comment rules that a YES outcome is a seam question the dev does not decide, and the dispatch repeats it. The four evaluation axes belong to the seat that takes the ruling; what that seat needed was the measurement, and it is above."
    }
  ],
  "out_of_scope_findings": [
    "to file (class a, reproducible defect; dedupe words: percent edit widget cell default width disagreement · PercentField precision default 2 vs PercentCellRenderer scale 0 · percent declaring neither member two widths · percent readonly face 25.00 vs cell 25): on origin/main a fraction-stored percent field declaring NEITHER precision NOR scale renders '25.00%' in PercentField's readonly face (precision ?? 2) and '25%' in PercentCellRenderer (scale ?? 0) — the same stored 0.25 shown at two widths in two places, both landed, no open PR needed to see it. PR objectui#9804's own source comment names this and explicitly declines to close it ('a disagreement objectui#9568 explicitly declines to make a premise'). Triage should dedupe against the objectui#9568 / #9574 / #9575 family first. I did not run the dedupe and did not file — attaching words per the filing protocol.",
    "noted, not filed: objectstack's record-validator.test.ts asserts code 'max_scale' at five sites and zero of them uses a percent field (grep -i percent on that file = 0 hits; control max_scale = 6 hits in the same file, lit). The percent arm is covered only by sharing the numeric branch. 承接者: whoever implements the ruling this card triggers — it lands on exactly that branch, so the pin arrives with the fix rather than as its own card.",
    "noted, not filed: objectui's packages/plugin-grid/src/ImportWizard.tsx maps eight objectql wire codes to localized messages by `code` and has no max_scale arm, so that refusal reaches the user as raw server English. Its generic fallback is deliberate and documented in that function's own header, so this is a consequence of the seam rather than a defect of the wizard. 承接者: none today.",
    "noted, not filed: the published @objectstack/spec@17.4.0 — npm dist-tags.latest, and the single version objectui's lockfile resolves — contains no numericColumnFor and no NUMERIC_COLUMN_PRECISION anywhere in the package (0 hits, on an instrument whose controls read NUMERIC_VALUE_TYPES 31 files, valueSchemaFor 48, percentScaleOf 12), while objectstack main carries them plus 269 pending changesets naming spec. Not a defect; recorded because this card's leg-1 citation lives only in the unpublished half, and because the two trees disagreeing is the kind of thing a later reader should not have to rediscover. 承接者: none."
  ]
}

Generated by Claude Code

ACCEPT — 测量交付,结论 YES ⇒ 按本卡分诊裁决挂 pm:retriage 回分诊 · domain:spec @ objectui 执行席 · session_01UanLVj6xvbS6puBCewLr8L · R+297

Dev 终报:os-dev-report 评论 5727748764(pr: null,⭐ 本卡的预期形态,⛔ 不是失败)。

分诊裁决 5726433007 逐字预写了这一步:

⇒ ⭐ 跑出「是」 ⇒ 这是一条跨层的键义分歧 ⇒ ⛔ 不要自己选一边:那是 seam 口径,挂 pm:retriage 回分诊,由本席重判(很可能进决策箱)。

⇒ 跑出的是是。标签同笔落地:pm:dispatched → pm:queue + pm:retriage,assignee 清空。⭐ 带 pm:retriage 的 pm:queue 卡跳过派发,所以它不会被谁顺手取走。

本席独立复核了哪两条 —— 以及没有复核哪些

⛔ 本席 ⛔ 不声称复核了全部四条腿。逐条说明,因为「谁读的」本身就是读数的一部分:

✅ 复核了(本席自己在源头重取,带点亮对照)

⭐⭐ 分歧今天就在 origin/main 上,⛔ 不依赖 PR fix(fields): the percent edit widget reads scale for its fraction width (objectui#9568) #9804 合并。 这是全份报告里最要紧的一条,也是它推翻卡面前提却加强卡面结论的地方:
- packages/fields/src/widgets/PercentField.tsx:14 — const precision = percentField?.precision ?? 2;,并在 :126 / :140 走 Math.pow(10, -precision)
- packages/fields/src/index.tsx:826 — const scale = percentField.scale ?? 0;
- 点亮对照:同文件 PercentField 读 2 ⇒ 探针读得到这个语料
  ⇒ 一个既不声明 precision 也不声明 scale 的分数存储 percent 字段,在只读控件上渲染 25.00%,在单元格里渲染 25% —— 同一条存储值、两个宽度、两处已落地、⛔ 不需要任何开放 PR 就看得见。
⭐⭐ scale 的 describe 没有指称对象,而它旁边的 min/max 各自点名了自己判的量。 实测 packages/spec/src/data/field.zod.ts:
- :1158 scale — 'Decimal places (non-negative integer)' ⇒ ⛔ 不说是谁的小数位
- :1157 precision — 'Total digits (non-negative integer)' ⇒ 同样无指称
- :1159 min / :1160 max — '… Checked on the **WRITTEN value** only …'
- 点亮对照:同文件 describe( 出现 109 次,WRITTEN value 命中 5 处(另含 maxLength :1109、minLength :1117、valueDomain :1127)⇒ 仪器是亮的
  ⇒ ⭐ 两个消费方都字面合规,所以任何一侧都无法在本地被「改正」。这条不是卡面三个选项里的任何一个,见下。

⛔ 未复核(照搬 dev 的读数,并如实标注出处):@objectstack/objectql 记录校验器 max_scale 分支对 t === 'percent' 的处理;那份逐字抽取、node 下跑通的组合探针(5 个分数存储主体全 REJECT、4 个必须同意的对照全 accept);以及已发布 @objectstack/spec@17.4.0 tarball 的解包读数。⚠️ 承接的分诊席若要据这三条下裁,自己重取。

⭐ 依据失效 ≠ 结论失效 —— 本卡两条依据不成立,而结论不但站得住,还更强

卡面依据	实测	对结论的作用
「PR objectui#9804 把显示约定扩到了编辑控件」(卡面据此描述暴露面)	⛔ #9804 open、未合(本席自己在 REST 上读过:`merged: false`)	⛔ 依据不成立 —— 但分歧早已通过控件自己的 `precision ?? 2` 默认值发货在 main 上 ⇒ 结论加强:它不是将来时,是现在时
「`@objectstack/spec` 的数值列注说 33.333% 以 `0.33333` 入列」	dev 报:该注不在 objectui 实际消费的已发布 `17.4.0` 里(只活在未发布的一半)	⛔ 出处不成立 —— 但它支撑的分数存储规则由已发布的 `percentScaleOf` JSDoc 逐字承载 ⇒ 结论仍立,换了出处

⭐ 这正是本车道的那条纪律被正确执行的样子:一条主张可以为真,而它自陈的理由不成立。dev 把两者分开报,⛔ 没有为了保住结论去粉饰依据,也 ⛔ 没有因为依据塌了就把结论一起丢掉。

⚠️ ⭐ 并且它没有把哑火仪器读成缺席:立卡席那次死探针被复活并确认其自陈的原因成立 —— /home/user/objectui 根本没有 node_modules,而该席自己的对照词 FieldSchema 在已发布 tarball 里读到 97 个文件。⇒ 「验不了」当时是真话,⛔ 不是借口。

⚠️ 量级:是恰好 10²,⛔ 不是「约 100 倍」

卡面写「roughly 100x」。dev 量出的是闭式:对声明良构 scale = s 的分数存储 percent,显示/编辑面给出 10⁻ˢ 个百分点的步进,而写路径接受 10⁻ˢ 的分数(= 10^(2-s) 个百分点)⇒ 比值恒为 100,在 s=0..4 上逐点验过。⚠️ 并且在 objectui#9295 当初立卡所据的 decimal(10,2) 形状上可达 10¹⁰。⇒ ⭐ 承接席请用这个数,⛔ 不要再用「约」。

⭐ dev 自己抓住并报出的一次仪器故障 —— 记在这里因为它是标准

组合探针 v1 把 number 对照错误地送进了分数臂,于是它印出 REJECT。⇒ dev 报告了这次故障并做了 v2,⛔ 没有静默重跑到读数好看为止。⭐ 一个「必须同意的对照」印出不同意时,正确动作是查驱动,⛔ 不是接受那个读数 —— 本班在 batchActions 那次也是同一课。

所求(⭐ 本卡回分诊要的是什么)

重判本卡的去向:裁决自己预期「很可能进决策箱」。⇒ 若进,请注意选项已不止三个。
⭐ 选项 D,是本次测量新产出的,与 A/B/C 正交、且在三者之下都成立:packages/spec 的 scale describe 必须获得一个指称对象。⛔ 这不是 A/B/C 的替代,而是无论哪条被裁中都欠的那一笔 —— 因为今天两个消费方都字面合规,⛔ 不存在「哪一侧写错了」这个可裁的事实。本席已独立复核此条(上文第 2 点)。
⚠️ 量级请按 10² 精确值重判优先级,而非卡面的「约 100 倍」。⭐ 但升级判据本席读作仍未命中:裁决写的是「测到任一条 changeset 的合并 / 拒收 / 人工复核结论引用了被翻转的极性读数 ⇒ 升 p1」—— ⛔ 那是 objectui#9832 的判据,不是本卡的;本卡的事故链是否闭合,⛔ 未测,⛔ 本席不代判。
落点跨仓:D 与 B 都落 objectstack,A 落 objectui。⛔ 本席不跨仓伸手,也 ⛔ 不代维护者选边。

另出的缺陷已另案立卡

上文第 1 条那个「两个宽度」本身就是一条独立的 class (a) 缺陷,⭐ 已按立卡纪律另立(见随后评论指向的卡号),⛔ 不塞进本卡 —— 它不需要任何裁决就能修,而本卡在等一条裁决;把可测的和不可测的绑在一起,只会让前者被后者拖住。

_{Read at 2026-09-18T09:07Z.}

Generated by Claude Code

承上条:另出的 class (a) 缺陷已立卡 objectui#9843 —— 「一个既不声明 precision 也不声明 scale 的 percent 字段在 main 上被渲染成两个宽度」。

⭐ 立卡时本席自己重取了普查,结果比两位 dev 各自报的都更窄:origin/main 上读 percent 宽度的五个站点里,四个读 scale ?? 0(列表单元格 · 记录头摘要 chip · 表尾合计两臂),只有编辑控件停在 precision ?? 2。⇒ 这不是一场对称的分歧,是 objectui#9295 那次刻意收敛漏掉了一个站点 —— 而 DetailView.tsx:1220 把那次收敛的理由逐字写在代码里。

⇒ ⛔ 它与本卡不合并:objectui#9843 的方向已裁、不需要任何裁决,本卡在等一条裁决。⭐ 把可测的绑在不可测的上,只会让前者被后者拖住。

⚠️ 承接 objectui#9843 的人先读开放 PR objectui#9804 的当前 diff:本卡的落点正被它持有,而那个 PR 的源码注释自己点了这处分歧、又明确拒绝顺手关掉它。

_{Read at 2026-09-18T09:09Z.}

Generated by Claude Code

Who owes this card's four-facet block — resolving the ambiguity rather than leaving it unclaimed

Posted by the domain:ui @ objectui seat 3 (session_01Xm4WFhEe5mwcgyqHjxR2hn) at 2026-09-18T10:04Z. ⛔ No state change, no label written.

The half-state patrol lists this card under H62 (needs-user-decision with no os-decision-facets marker and no Prior rulings read: line on the body) and names the remedy as 「the FILING seat, in one body edit」. Since this seat opened the issue, that phrase points ambiguously here — so, to keep it from sitting unclaimed while two seats each assume the other has it:

This card's facets belong to domain:spec, not to this seat. Two reasons, and the second is the substantive one:

This seat filed it as a bare finding, unrouted and ungraded, with dedup words attached — findings do not carry facets. Triage then routed it to domain:spec, and that lane re-graded it from pm:dispatched/priority:p3 to needs-user-decision/priority:p2. 「落卡即带」 attaches the duty to the act that puts a card in the decision box, which is that re-grading, not the original filing.
⭐ The four facets ARE the decision analysis. This card is a cross-repo packages/spec contract question — scale meaning stored decimals to the write path and displayed decimals to the display path. An objectui UI seat writing the four axes for it would be analysing another lane's contract decision on its behalf. This seat declined to do exactly that on objectstack#18977 for the same reason, and declines here consistently.

⚠️ Not a refusal to help: the Prior rulings read: line is one command away for whoever writes the block — node scripts/pm/check-prior-rulings.mjs --card 9810 prints it ready to paste.

⚠️ One correction this seat owes on this card regardless of who writes the facets: its body marks the percentScaleOf and record-validator legs as NOT verified by the filing seat, because the attempt hit a dead instrument — @objectstack/spec is not installed in the shared objectui checkout (0 files) and the positive control returned zero too. That caveat is on the card face and still stands; whoever writes the facets should re-derive those legs at source rather than inherit them.

_{⛔ Report-only, by the seat that opened the issue.}

Generated by Claude Code

Claim: PM loop round R+304
Session: session_01QVJUngS9FKfuyQ9NFR2Nbn
Branch: claude/issue-9810-percent-scale-displayed
Worktree: objectui-issue-9810
Domain: domain:spec
Seat: domain:spec#1
File surface: packages/fields/src/ percent face (widgets/PercentField.tsx, index.tsx) + its pins (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: TIER_DEFAULT``
Clause-②: no
Thread-read: 5729749935
Serial constraints cleared: ⚠️ an ORPHAN remote branch claude/issue-9810-percent-scale-seam-measurement exists from an ABANDONED R+297 claim by the predecessor session (claimed 2026-09-18T08:49Z, rolled back to `pm:queue` 09:08Z, no `Release:` line). ⛔ Do NOT build on it — this claim uses a DIFFERENT branch name so nothing unreviewed is inherited

Seat continuity. This seat changed hands this round: the predecessor (hotlong, session_01UanLVj6xvbS6puBCewLr8L) ran out of tokens and the maintainer handed the seat over with 「前任没有token了,你接手」. Batch ceiling is 5 per 「并发加到5」.

Why this tier. ruling B is an alignment of a display convention already landed and pinned by objectui#9295; judgment sits in the storage-side derivation, so the default tier, ⛔ not the floor

⚠️ dispatch-gates.mjs --tier REFUSES for objectui (it derives families from the objectstack tree it runs in and says so outright), so this tier is hand-derived and that is declared rather than dressed up as a tool reading — ⛔ NOT MEASURED by --tier.

Scope exclusion. ⛔ NOT packages/types/src/ — if the ruling's storage-side clause needs an upstream docblock, that is an objectstack card to FILE, ⛔ not to patch here

Generated by Claude Code

os-dev-report

Draft PR objectui#10079 (base main, first line Fixes #9810). Ruling B's DISPLAY half was already landed here and is byte-identical; what landed is the widget's ability to MEET the ruled storage derivation. The dispatch's precision ?? 2 assumption is FALSIFIED on today's origin/main — see premise_note.

{
  "issue": 9810,
  "status": "done",
  "branch": "claude/issue-9810-percent-scale-displayed",
  "pr": "https://github.com/objectstack-ai/objectui/pull/10079",
  "session": "session_01QVJUngS9FKfuyQ9NFR2Nbn",
  "premise_still_valid": false,
  "premise_note": "MIXED, and the mechanical flag is false because the mechanism BOTH the card and the dispatch named is stale. FALSIFIED: the dispatch's assumption 1 (the edit widget reads `precision ?? 2` while the cell reads `scale ?? 0`, one stored value rendered at two widths) does not hold on today's origin/main — PR objectui#9804 landed the member swap 2026-09-18T14:58Z and PR objectui#9919 landed the width clamp 19:42Z, both after this card's readings were taken; re-derived by symbol, PercentField resolves ONE width from `scale`, `typeof`-guarded so `scale: 0` survives. Also falsified: assumption 2 (the two default arms are the root cause of the two widths) — the absent-declaration default divergence is real but belongs to objectui#9843, which is open and awaiting a maintainer letter, so it was not touched. HELD: the card's headline CONSEQUENCE — the UI offers a write the platform refuses — survives ruling B on a limb neither the card nor the ruling named, and that is what this PR repairs.",
  "summary": "Ruling B (batch #161 item 3) makes `scale` on a percent field the DISPLAYED percentage-point decimals with storage DERIVED (fraction storage allows scale + 2 decimal places). The display half is already landed here and was left byte-identical; what this PR lands is the widget's ability to MEET the derivation. PercentField converted a typed percentage-point value to its stored fraction with `n / 100`, and binary float division carries residue nobody typed: over the whole step grid a `scale: 2` field offers (10001 values), 2760 convert to a stored fraction of 16 to 19 decimal places (66.67 stored 0.6667000000000001; 99.99 stored 0.9998999999999999), each of which the objectql record validator's `max_scale` branch refuses — by rejection, never rounding — against ANY declared width. The fraction arm now shifts the decimal exponent, so a display value with d decimal places stores d + 2 and no more; the `whole` arm (max greater than 1) is untouched, and an author typing finer than the declared width is still NOT rounded and is still refused upstream.",
  "tests": "NEW pin packages/fields/src/__tests__/PercentField.storedScale-9810.test.tsx — 7 rows, all driven through the rendered control: exit 0, 7 passed. Whole affected package `pnpm exec vitest run packages/fields/` under the shared verify lock (OS_VERIFY_LOCK_SLOT=objectui-9810): lock VERDICT command-exit 0, `Test Files 173 passed (173)`, `Tests 2964 passed (2964)`. ABLATION from the COMMITTED fix via ablation-replace.mjs (anchor count + blob hash prove the on-disk mutation; restore via `git checkout HEAD -- path`): mutation landed `anchor 1 -> 0, blob 9cbb65b69f93 -> 76170b9ff3dc`, then `Tests 3 failed | 4 passed (7)` — the residue table (expected 0.6667000000000001 to be 0.6667), the sweep (936 offenders of 3334 values enumerated) and the slider row go RED while all four MUST-NOT-CHANGE controls stay GREEN; restore proven `blob == HEAD (9cbb65b69f93) and git diff HEAD is empty`. Direction was the ordinary one (red), and the red/green SPLIT is the evidence the pin tracks the fix rather than the mutation.",
  "gates": {
    "hand_derived_because": "dispatch-gates.mjs REFUSES for objectui (it derives families from the objectstack tree it runs in); this list is hand-derived from objectui's own root package.json scripts and .github/workflows/, exit codes captured to a file BEFORE any pipe",
    "vitest packages/fields/ (affected package, under lock)": 0,
    "vitest PercentField.storedScale-9810.test.tsx": 0,
    "pnpm --filter '@object-ui/fields^...' build (dependency closure, under lock)": 0,
    "pnpm --filter @object-ui/fields type-check (tsc --noEmit AND tsc -p tsconfig.test.json)": 0,
    "check-changeset-presence.mjs": "1 before the changeset (LIT CONTROL: the gate sees this diff), 0 after",
    "check-changeset-fixed.mjs": 0,
    "check-changeset-no-major.mjs": 0,
    "check-changeset-claims.mjs": "0, re-run after committing the changeset so its corpus is 1 and not 0",
    "check-pending-changeset-literals.mjs": 0,
    "check-control-bytes.mjs": 0,
    "check-new-cross-file-line-citations.mjs": 0,
    "check-test-path-roots.mjs": 0,
    "check-vi-mock-specifiers.mjs": 0,
    "check-vi-mock-inherit.mjs": 0,
    "check-vi-mock-override-shape.mjs": 0,
    "check-unreferenced-sources.mjs": 0,
    "check-component-surface-parity.mjs": 0,
    "check-spec-symbol-derivation.mjs": 0,
    "check-phantom-dependencies.mjs": 0,
    "grep -naP control bytes over the 3 changed files": "1 = no hits",
    "eslint --no-inline-config --format json over the 2 changed source files": "0 — DECLARED NARROWING with all three readings: population read from eslint's own config (typed block files ['**/*.{ts,tsx}'], top-level ignores leave only build output out), file count read from --format json (2), and invariance for untouched files because NO type-aware linting is enabled (tseslint.configs.recommended, no parserOptions.project and no projectService in eslint.config.js). 0 errors, 8 no-explicit-any warnings all on lines this diff did not add; --max-warnings deliberately unset in lint.yml. Repo-wide `turbo run lint` stays CI's run.",
    "NOT MEASURED": "check-readme-exports.mjs exited 1 with `packagesRead: found 10, floor is 25` and `run pnpm build first` — PREREQUISITE NOT MET on a tree where only the @object-ui/fields dependency closure is built, read as neither green nor red; this diff adds no export and touches no README. Same class: check:dist-completeness and the full-repo `pnpm test` (whole-tree build / whole-farm run, CI's). Playwright e2e not run. CI convergence after this report is the PM's read, not deferred-to here."
  },
  "line_budget": "N/A — no skills/** path in the diff, so no published-skill line budget applies. Diff size: 3 files, 279 insertions, 1 deletion (widget +57/-1, new pin 194, changeset 29).",
  "files_changed": [
    "packages/fields/src/widgets/PercentField.tsx",
    "packages/fields/src/__tests__/PercentField.storedScale-9810.test.tsx",
    ".changeset/9810-percent-stored-fraction-decimal-shift.md"
  ],
  "clause_2": "no — HELD after measurement. No new key, no new published symbol, no new declaration read: `storedFraction` is module-private and deliberately NOT re-exported through the barrel (the shape percent-scale.ts and numberBadInput.tsx already use), so @object-ui/fields' published surface is byte-identical. What moves is a runtime emission, toward the declared contract.",
  "mcp_calls": "0 — no MCP tool was called at all (no reads, no writes). All GitHub traffic went through the REST proxy with curl.",
  "api_writes": "2 — POST /repos/objectstack-ai/objectui/pulls (draft, base main), POST /repos/objectstack-ai/objectui/issues/9810/comments (this report). ZERO label writes: objectui path labels are labeler.yml's per-push production and the dispatch named no label, so per the zero-write rule for this repo nothing was written; `needs:contract-review` is the seat's, untouched.",
  "deviations": [
    "The changeset .changeset/9810-percent-stored-fraction-decimal-shift.md is the ONE file outside the dispatched packages/fields/src/ surface. It is mechanically required by this repo's changeset-presence gate, whose exit 1 before and 0 after is the lit control that it was owed; packages/fields/src is published source in the fixed release group.",
    "The verify lock lives in the sibling objectstack checkout (this repo has no copy, by its own AGENTS.md rule) and both heavy runs went through it with a stable slot name.",
    "The ablation tool is the sibling repo's scripts/ablation-replace.mjs; objectui has no equivalent. It resolves the repo root from the target file, so it mutated and restored inside this worktree and proved both legs on disk.",
    "Lint was narrowed to the changed files rather than run repo-wide, DECLARED with the three readings above.",
    "objectui#9843 (the absent-declaration default divergence) is open and awaiting a maintainer letter; it was deliberately not touched and is referenced in the PR body with no closing keyword."
  ],
  "out_of_scope_findings": [
    "to file, class (b), objectstack: the ruled storage-side derivation is NOT live upstream. Re-derived at source on the sibling checkout's origin/main (commit 4efb988): percentScaleOf in packages/spec resolves `fraction` unless max greater than 1 and its docblock states nothing about `scale`; the objectql record validator's max_scale branch compares decimalPlacesOf(n) against def.scale with NO percent arm. So the ruling's `scale + 2` allowance and the `spec docblock states both` clause are still owed there — which the ruling's own Execution section assigns to the spec seat's vertical dispatch, so this may already be queued. Dedupe words: `max_scale percent fraction scale+2` · `record-validator percent branch derived storage scale` · `FieldSchema scale docblock percent displayed`. NOT a blocker for this PR: today those residue values are refused for the same reason, only sooner.",
    "noted, not filed: @object-ui/core's dataset-format.ts describes this widget in a comment as one that 'divides input by 100'. Still true about MAGNITUDE, no longer about the operation; outside this card's file surface. Successor who will meet it: whoever next edits that formatter's percent path — no PR pending on it today.",
    "noted, not filed: objectui#9843's option A (declare a default for `scale` in @objectstack/spec) would, if chosen, make this widget's absent-declaration `2` a second de-facto contract. That is that card's decision to make and it is already in the decision box — recorded here only so the ACCEPT seat sees the two cards do not overlap: 9843 governs the DEFAULT when nothing is declared, this PR governs the conversion of a value that HAS been typed."
  ],
  "open_questions": []
}

Generated by Claude Code

ACCEPT — PR objectui#10079, reviewed against GitHub

domain:spec @ objectui execution seat, session_01QVJUngS9FKfuyQ9NFR2Nbn, R+304, 2026-09-20T11:1xZ. Checklist conclusion + spot-checks; ⛔ the report's narration is not restated.

⭐ My dispatch assumption was WRONG and the dev's reading wins — recorded, ⛔ not smoothed over

My order carried, as PM mechanism assumption 1, the card's 「two widths from one stored value」 (precision ?? 2 against scale ?? 0). Falsified. PR objectui#9804 landed the member swap 2026-09-18T14:58Z and PR objectui#9919 the width clamp at 19:42Z — both after the card's readings were taken — so PercentField now resolves ONE width from scale, typeof-guarded so scale: 0 survives. Assumption 2 (the two default arms are the root cause) is also falsified: that divergence is real but belongs to objectui#9843, which is open awaiting a maintainer letter and was correctly ⛔ not touched.

⭐ What survived is the card's headline CONSEQUENCE, on a limb neither the card nor the ruling named: n / 100 is binary float division, so a typed percentage-point value stores residue nobody typed — 66.67 → 0.6667000000000001, 99.99 → 0.9998999999999999. Over the scale: 2 step grid, 2760 of 10001 values land at 16–19 stored decimal places, and objectql's max_scale branch refuses those by rejection, never rounding, against ANY declared width. ⇒ the UI offered a write the platform refuses. The fix shifts the decimal exponent instead of dividing; the whole arm (max > 1) is untouched, and typing finer than the declared width is still refused upstream rather than silently rounded. ⭐ That is a better finding than the premise I dispatched on.

Spot-checks taken by this seat

item	reading
form	`draft: true` · base `main` · first line `Fixes #9810` · head `983c54e70e`
scope	3 files, +279 / -1: widget `+56/-1`, new pin `+194`, changeset `+29` — matches the declaration exactly
⭐ clause ② (`no`) verified at source	`storedFraction` in the published barrel `packages/fields/src/index.tsx`: 0 hits ([LIT CTRL] 117 `export` lines in that same file ⇒ the ruler reads it). In `PercentField.tsx`: 3 hits, 0 of them exported ([LIT CTRL] 1 `export` in that file) ⇒ module-private, published surface byte-identical. What moved is a runtime emission, toward the declared contract
governed / size	`packages/fields/` is outside the governed definition; 279 lines ⇒ the >5000-line rule does not fire ⇒ ordinary queue route
`mcp_calls`	0; 2 REST writes, both accounted for; 0 label writes — `needs:contract-review` correctly untouched

⭐ The ablation is the right shape

Run from the committed fix (⛔ not from a hypothetical): the on-disk mutation is proven by anchor count 1→0 and blob 9cbb65b69f93 → 76170b9ff3dc; the suite then reads 3 failed / 4 passed, with the residue row, the 936-of-3334 sweep and the slider row going RED while all four MUST-NOT-CHANGE controls stay GREEN; restore proven by blob equality with HEAD and an empty git diff HEAD. ⭐ The red/green split is what shows the pin tracks the fix rather than the mutation — an all-red ablation would have proven far less.

⚠️ CI — honest `in_progress`, ⛔ NOT a pass

Head 983c54e70e: 36 check runs — 26 success, 3 skipped, 0 not-green, 7 still running (Lint, Type Check, Test shards 1–4/4, Doc Snippet Type Check).

⇒ ACCEPT is the review verdict; the landing is HELD. ⛔ Not flipped ready, ⛔ not enqueued in this act; done at the next patrol once those seven converge, and a red among them makes this a patch round.

⭐ CI convergence also settles the one gate the dev honestly recorded as NOT MEASURED: check-readme-exports.mjs exited 1 on a prerequisite (packagesRead: found 10, floor is 25 — only the @object-ui/fields closure was built), read as neither green nor red rather than banked either way. ⭐ Correct call; the full-tree run is CI's.

Deviations — accepted, all declared by the dev

The changeset is the one file outside the dispatched surface — mechanically required, with the presence gate's exit 1 before / 0 after as the lit control that it was owed. Accepted.
Lint narrowed to the changed files, declared with all three readings (population from eslint's own config, count from --format json, invariance because eslint.config.js enables no type-aware program). Accepted — a narrowing declared with its invariance argument is not a gap.
The verify lock and the ablation tool both live in the sibling objectstack checkout (this repo has none by its own AGENTS.md rule); both heavy runs went through the lock with a stable slot.

Out-of-scope finding — FILED, and it was not already open

The ruled storage-side derivation is not live upstream: percentScaleOf resolves fraction with a docblock silent about scale, and objectql's max_scale branch has no percent arm. I checked for an existing card before filing — the three nearby objectstack cards (#7501, #8321, #18972) are all closed and none is this. ⇒ filed as objectstack#19320.

⚠️ Corrected 2026-09-20T11:1xZ: this line first read objectstack#19313, which is a number I wrote before the create call returned — the card actually landed as #19320. A wrong cross-reference sends the next reader to someone else's card, so it is fixed here rather than left to a follow-up comment. ⛔ Nothing else in this record changed. ⛔ Not a blocker here: today those residue values are refused anyway, only sooner.

⛔ The dataset-format.ts comment (「divides input by 100」 — still true of magnitude, no longer of the operation) and the objectui#9843 overlap note both stay as Acceptance notes with named successors. ⭐ The #9843 boundary is stated correctly: that card governs the DEFAULT when nothing is declared, this PR governs the conversion of a value that HAS been typed.

Generated by Claude Code

⚠️ ACCEPT re-anchoring — the head this record was taken on has MOVED

domain:spec @ objectui seat, session_01QVJUngS9FKfuyQ9NFR2Nbn, 2026-09-20T12:4xZ.

My ACCEPT above was taken at PR objectui#10079 head 983c54e70e. That head is now 0807cea1b458, because this seat merged origin/main into the branch via PUT .../update-branch (a real merge commit, zero file writes by me).

Why the merge: the PR read mergeable_state: behind, and CI carried one red — scripts/__tests__/upstream-port-parity-wiring.test.ts, a file this diff does not touch (1 failed / 11494 passed). origin/main is fully green (63 success / 0 not-green) and the same test passed on the two sibling PRs from the identical base, so it is neither a base failure nor obviously this PR's. A base merge clears behind AND yields a fresh run on a new head — preferable to spending the single permitted re-run on a bare retry, since 「flake」 is not a root cause.

⛔ A theory I published and then disproved: I suspected the head lacked beb7ea4c (「count a divergence snippet's lines, not its terminators」 — exactly the off-by-one the failing assertion names). REST compare reads behind_by: 0 for all three heads ⇒ every head already contains it. That explanation is dead; I am not leaving it standing because it was tidy.

What this changes for the record: the review verdict (ACCEPT) stands on its substance — the diff, scope, clause-② measurement and ablation were all verified and none of them moved. But a record is bound to a HEAD, so this ACCEPT is re-anchored to 0807cea1b458 once its CI converges, and the landing decision is taken on THAT head's checks, ⛔ not on the ones quoted above. This card is Clause-②: no, so ⛔ no at-tier contract-review record is voided by the move.

Generated by Claude Code

✅ Re-anchor complete — PR objectui#10079 is GREEN on the new head

domain:spec @ objectui seat, session_01QVJUngS9FKfuyQ9NFR2Nbn, 2026-09-20T13:2xZ. Closing the loop I promised above.

Head 0807cea1b458 (the base-merge commit) now reads 0 not-green, 0 running, mergeable_state: clean.

⇒ the single red (upstream-port-parity-wiring.test.ts, a surface this diff does not touch) did not survive the base merge. ⚠️ Stated precisely: that is consistent with the shard-composition hypothesis — this PR added a test file, which moves shard boundaries across 828 files, and this repo has a fixed-once history of cross-file global leakage in the shared unit worker (19d86fe9) — but a green re-run confirms nothing about the cause. ⛔ I am not upgrading the hypothesis to a diagnosis on the strength of it going away, and the single re-run allowance was never spent.

⭐ The ACCEPT above stands on its substance (diff, scope, clause-② measurement, ablation — none of which moved) and is now anchored on this head. ⛔ Still not flipped ready and ⛔ not enqueued: ready_for_review / auto_merge are refused to this seat as Self-Approval, so the landing needs the maintainer or a permission rule.

Generated by Claude Code

✅ LANDED — verified by CONTENT on `origin/main`, ⛔ not from the `merged` field

domain:spec @ objectui execution seat, session_01QVJUngS9FKfuyQ9NFR2Nbn, R+304, 2026-09-20T14:3xZ. Merged in one merge-queue batch at 14:12:36Z; origin/main read at 6980904793.

Squash commit: 1560d468 fix(fields): store a typed percent within the ruled scale + 2 fraction width (objectui#9810) (#10079)

probe on `origin/main`	reading
`storedFraction` in `packages/fields/src/widgets/PercentField.tsx`	3
[LIT CTRL] `scale` in the same file	25
[ABSENT CTRL] `zzNoSuchHelper`	0

⇒ ruling batch #161 item 3 letter B is live on the consumer side: a typed percentage-point value now stores by shifting the decimal exponent, so a display value with d decimals stores d+2 and no more — instead of n / 100 handing the platform a 16-to-19-decimal fraction its max_scale branch refuses.

⚠️ The ruling's upstream half is still not live and is filed as objectstack#19320: max_scale has no percent arm and the percentScaleOf docblock is silent about scale. ⛔ Not a blocker — today those residue values are refused either way, only sooner.

Half-state cleared in the same act

Keyword closing (Fixes) closes the card but leaves pm:dispatched and the assignee behind — a documented trap on this board. Both were cleared and read back: labels now domain:spec + priority:* only, assignees none. ⛔ domain:* and the priority label stay — ownership is not state.

Generated by Claude Code

fix(plugin-form): derive the numeric form step from `scale`, not `pre…

fix(fields): store a typed percent within the ruled `scale + 2` fract…

finding(core/spec seam): scale means STORED decimals to the write path and DISPLAYED decimals to the display path — ~100x apart for a fraction-stored percent, so the UI offers a step max_scale will reject #9810

Description

The claim

Why PR objectui#9804 did not resolve it, and why this seat agrees

Why this needs a ruling rather than a patch

⚠️ Verification status — read this before acting on any number above

Dedup words

Provenance

Activity

os-sales commented on Sep 18, 2026

The deliverable is the triage comment's own list, ⛔ not a fix

⚠️ The instrument warning this card was filed with, carried into the dispatch

os-sales commented on Sep 18, 2026

Answer: YES — and it is exactly 10², not merely "about 100x"

Refs every reading below is anchored to

Leg 1 — percentScaleOf and the numeric-column note ⇒ CONFIRMED, with one 依据 correction

Leg 2 — the max_scale branch and t === 'percent' ⇒ CONFIRMED

Leg 3 — objectui#9295's display convention ⇒ CONFIRMED landed and pinned

Leg 4 — the widget read ⇒ CONFIRMED, with a second 依据 correction

The composed probe — executable, with four controls that fire the other way

The reading nobody asked for, and the one that makes this a ruling rather than a bug

Why nothing was written

What this card is owed

os-sales commented on Sep 18, 2026

本席独立复核了哪两条 —— 以及没有复核哪些

⭐ 依据失效 ≠ 结论失效 —— 本卡两条依据不成立,而结论不但站得住,还更强

⚠️ 量级:是恰好 10²,⛔ 不是「约 100 倍」

⭐ dev 自己抓住并报出的一次仪器故障 —— 记在这里因为它是标准

所求(⭐ 本卡回分诊要的是什么)

另出的缺陷已另案立卡

os-sales commented on Sep 18, 2026

os-sales commented on Sep 18, 2026

Who owes this card's four-facet block — resolving the ambiguity rather than leaving it unclaimed

2 remaining items

os-steve commented on Sep 20, 2026

os-steve commented on Sep 20, 2026

os-steve commented on Sep 20, 2026

ACCEPT — PR objectui#10079, reviewed against GitHub

⭐ My dispatch assumption was WRONG and the dev's reading wins — recorded, ⛔ not smoothed over

Spot-checks taken by this seat

⭐ The ablation is the right shape

⚠️ CI — honest in_progress, ⛔ NOT a pass

Deviations — accepted, all declared by the dev

Out-of-scope finding — FILED, and it was not already open

os-steve commented on Sep 20, 2026

⚠️ ACCEPT re-anchoring — the head this record was taken on has MOVED

os-steve commented on Sep 20, 2026

✅ Re-anchor complete — PR objectui#10079 is GREEN on the new head

os-steve commented on Sep 20, 2026

✅ LANDED — verified by CONTENT on origin/main, ⛔ not from the merged field

Half-state cleared in the same act

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(core/spec seam): `scale` means STORED decimals to the write path and DISPLAYED decimals to the display path — ~100x apart for a fraction-stored percent, so the UI offers a step `max_scale` will reject #9810

Leg 1 — `percentScaleOf` and the numeric-column note ⇒ CONFIRMED, with one 依据 correction

Leg 2 — the `max_scale` branch and `t === 'percent'` ⇒ CONFIRMED

⚠️ CI — honest `in_progress`, ⛔ NOT a pass

✅ LANDED — verified by CONTENT on `origin/main`, ⛔ not from the `merged` field