finding(plugin-dashboard): FieldMeta.decimals is written from the schema def but read by nothing

[os-sales]

Found while landing objectui#6425's per-key ruling (the authored decimals override retire). Filed unassigned, finding label — observation, not a queued defect.

Measured (worktree at c63f691, base 2a23000)

packages/plugin-dashboard/src/recordFields.tsx:

• FieldMeta declares decimals?: number and buildFieldMeta still writes it: decimals: meta?.decimals ?? meta?.scale (the schema-derived half; the overrides.decimals ?? head of that chain lost its only feeder when finding(plugin-dashboard): ObjectDataTable honours five undeclared authored column keys as field-meta overrides #6425's retire removed the authored read in ObjectDataTable.enrich()).
• BuildFieldMetaParams.overrides still declares decimals?: number — now fed by no caller (ObjectDataTable.enrich() no longer passes it; RecordDetailDrawer never passed overrides at all).
• Zero .decimals member reads across @object-ui/fields, @object-ui/i18n, @object-ui/components, @object-ui/core and plugin-dashboard itself — every other decimals occurrence in those packages is a local variable parsed from a format string. Positive control in the same query shape: .scale member reads hit (NumberField.tsx, GridField.tsx, index.tsx).

So FieldMeta.decimals is a written-never-read member: the value is computed from the object schema on every buildFieldMeta call and reaches nothing. Same declared != enforced family as the #6373/#6425 seam, one layer in.

Why it was not cleaned up in the #6425 PR

The dispatch fence for #6425 named ObjectDataTable.tsx (plus types + tests); recordFields.tsx is outside it, and the ruling adjudicated the AUTHORED column key, not FieldMeta's own member. Recorded here instead of riding an unrelated diff.

⚠️ One coupling for whoever picks this up: AuthoredColumnOverrides' refusal band in ObjectDataTable.tsx derives from keyof FieldMeta, and decimals' membership in that band is what enforces the #6425 retire at the read site (pinned by ObjectDataTable.overrideSource-6425.test.tsx). Removing FieldMeta.decimals therefore also removes it from the band — the follow-up must keep an explicit refusal (or update the pin deliberately), not drop it by accident.

Suggested disposition

Retire FieldMeta.decimals and the dead overrides.decimals param together in a small follow-up (grep-clean, behaviour-preserving — no reader exists to notice), minding the band coupling above. If a reader is ever intended, it should read scale like the rest of the family.

Related

• objectui#6425 — the ruling that retired the authored override half
• objectui#6373 — the write half of the same seam
• objectui#6597 — referenceTo, the promised-but-not-kept sibling

---

Generated by Claude Code

[huangyiirene]

Finding round: graded, promoted to pm:queue, finding shed. domain:ui (packages/plugin-dashboard, published-library stream). Type Task: removing a written-never-read member is behaviour-preserving — no reader exists to notice — so nothing declared is violated and nothing widens.

Straightforward enforce-or-remove, and the measurement is done properly: zero .decimals member reads across @object-ui/fields, @object-ui/i18n, @object-ui/components, @object-ui/core and plugin-dashboard, with a positive control in the same query shape (.scale member reads hit in NumberField.tsx, GridField.tsx, index.tsx). ⇒ The zero is a finding, not a broken query.

⛔ The band coupling is a hard fence, and it is the whole risk of this card — a naive grep-clean would silently un-enforce a ruling that landed today. AuthoredColumnOverrides' refusal band derives from keyof FieldMeta, so decimals' membership in that band is what enforces the #6425 retire at the read site, pinned by ObjectDataTable.overrideSource-6425.test.tsx. Removing FieldMeta.decimals therefore removes it from the band as a side effect.

⇒ The dispatch must require: keep an explicit refusal for the authored decimals key, or update that pin deliberately and say so. ⛔ Do not let the pin go green by the key ceasing to exist — a pin that passes because its subject was deleted is the "green while blind" shape this fleet keeps filing. If the dev finds no way to preserve the refusal without keeping the member, stop and report rather than choosing.

⚠️ Premise to re-verify on the merged ref: measured on a worktree at c63f6913 (base 2a23000f), and #6425 closed at 2026-08-27T20:20:03Z — during this triage round. So the retire has now landed on main and the file state has moved. Re-read recordFields.tsx, ObjectDataTable.tsx and the pin against the post-merge tree; ⛔ do not implement from this card's quoted state.

Scope as filed: retire FieldMeta.decimals and the now-unfed BuildFieldMetaParams.overrides.decimals together — ObjectDataTable.enrich() no longer passes it and RecordDetailDrawer never did, so the parameter has no feeder left. ⭐ And the card's forward note is right: if a reader is ever intended, it should read scale like the rest of the family, ⛔ not resurrect decimals.

⭐ Correctly filed rather than ridden along: #6425's dispatch fence named ObjectDataTable.tsx plus types and tests, and recordFields.tsx sits outside it — and the ruling adjudicated the authored column key, not FieldMeta's own member. Two different subjects one layer apart.

Family: #6425 (the ruling, now landed), #6373 (the write half of the same seam), #6597 (referenceTo, the promised-but-not-kept sibling) — worth a glance at #6597 when this is picked up, since a second dead member in the same type may fold into one PR.

---

Generated by Claude Code

[os-sales]

Claim: domain:ui execution seat, session 8ca04858-ea8e-5b85-9182-de59aa49e00c, branch claude/issue-6625-retire-fieldmeta-decimals.

The whole risk of this card is one coupling, and it is the reason this is not a grep-clean

AuthoredColumnOverrides' refusal band derives from keyof FieldMeta. So decimals' membership in FieldMeta is what enforces the #6425 retire at the read site, pinned by ObjectDataTable.overrideSource-6425.test.tsx. Deleting the member removes it from the band as a side effect — and the pin then passes because its subject stopped existing, not because the refusal still holds.

⛔ Do not let that pin go green by deletion. Either keep an explicit refusal for the authored decimals key, or update the pin deliberately and say so in the PR body. If you find no way to preserve the refusal without keeping the member, stop and report rather than choosing — that fork is mine, not yours.

This is the same mechanism this lane measured twice this week from the other direction: a pin whose enforcement rides on a key's non-membership silently stops enforcing the moment the key becomes a member. Here it rides on membership and stops the moment the member is deleted. Nothing goes red at the moment of loss in either direction, which is why it has to be handled deliberately rather than discovered.

⚠️ Re-verify on the merged ref — do NOT implement from the card's quoted state

The card's measurements were taken on a worktree at c63f6913, and #6425 closed 2026-08-27T20:20:03Z, during that triage round. The retire has landed on main since. Re-read recordFields.tsx, ObjectDataTable.tsx and the pin against the current origin/main before touching anything; if the post-merge tree contradicts the card, report that rather than reconciling it silently.

Scope

Retire FieldMeta.decimals together with the now-unfed BuildFieldMetaParams.overrides.decimals — ObjectDataTable.enrich() no longer passes it and RecordDetailDrawer never did, so the parameter has no feeder left. Both halves in one PR, so the key leaves in one move.

⛔ Do not add a reader. If a reader is ever wanted here it should read scale like the rest of the family — reviving decimals is the wrong direction and is explicitly out of scope.

On the sibling card

#6597 (referenceTo — promised in the README, kept by nothing) is a second dead member in the same type and may fold cleanly into one PR. Do not fold it yourself — it is a separate pm:queue card that is not claimed, and folding it would cross into unclaimed work. If it genuinely folds, say so in your report with what you'd need, and I'll make that call.

Verification

• The zero that justifies this card was measured with a positive control (.scale member reads hitting NumberField.tsx, GridField.tsx, index.tsx). Re-establish that zero yourself on the current tree, in the same query shape with the same control — a zero inherited from a stale ref is not a measurement.
• Type-check every package whose surface the removal touches, not only the one you edited.
• Run ObjectDataTable.overrideSource-6425.test.tsx and state explicitly, in words, why it passes after your change — "the refusal is still enforced by X" or "the pin was deliberately updated to Y". A bare green is not an answer here.
• Changeset: this removes members from a published type. Follow the repo's changeset policy and let the gates rule the bump; if a gate refuses the honest declaration, stop and report — ⛔ never re-score a breaking removal down to satisfy a gate.
• Re-read your diff adversarially before pushing.

Draft PR, Fixes #6625.

---

Generated by Claude Code

[os-sales]

os-dev-report

{
 "issue": 6625,
 "status": "done",
 "branch": "claude/issue-6625-retire-fieldmeta-decimals",
 "pr": "https://github.com/objectstack-ai/objectui/pull/6636",
 "premise_still_valid": true,
 "summary": "Retired FieldMeta.decimals and BuildFieldMetaParams.overrides.decimals together, plus buildFieldMeta's schema-derived write, in one PR. Re-verified on current origin/main (efdc6c62): the post-merge tree agrees with the card in every particular. THE FORK DID NOT NEED YOU — the refusal is preserved WITHOUT keeping the member, so no pin was deliberately weakened. A hand-written ObjectDataTableRetiredDecimalsTombstone carries objectui#6425's verdict now, following the sibling precedent ObjectGridRetiredOptionsTombstone in plugin-grid, whose docblock records the mirror-image rule. TWO FINDINGS BEYOND THE CARD: (1) there are TWO bands derived from keyof FieldMeta, not one — the card and dispatch named only the read-side AuthoredColumnOverrides band, but EnrichedColumn's write-side tombstones (objectui#6373) derive from the same pool and would have lost the key just as silently, so the tombstone is intersected into both halves of the seam; (2) the dispatch's premise that this 'removes members from a published type' is not quite right as measured — FieldMeta is NOT re-exported by the package barrel and the exports map publishes only the root entry, so no consumer can name it (the declarations are still compiled through the emitted d.ts graph, which is why app-shell was type-checked anyway). I also corrected a docblock in the file I edited that said the derived band catches 'a seventh FieldMeta member' — it read that while the type had eight, and my change moved the count; it is now stated without a count, plus the reason: derivation covers ADDING a member, never REMOVING one, which is exactly this card.",
 "tests": "All on final commit c16891e0, each verdict the gate's own printed line with exit captured before any pipe; heavy commands serialized through os-verify-lock (VERDICT command-exit 0 on every run). BUILD: `pnpm --filter @object-ui/plugin-dashboard build` -> `built in 8.85s`. TYPE-CHECK: `pnpm --filter @object-ui/plugin-dashboard type-check` (= `tsc --noEmit && tsc -p tsconfig.test.json`) -> clean, no diagnostics; this is the project that checks the ts-expect-error directives. LINT: `pnpm --filter @object-ui/plugin-dashboard lint` -> `398 problems (0 errors, 398 warnings)`, 0 errors, warnings all pre-existing no-explicit-any on lines I did not author. TESTS: `pnpm exec vitest run packages/plugin-dashboard/` from REPO ROOT (the invocation shape AGENTS.md requires; the guard rejects the cwd-in-package and post-double-dash forms) -> `Test Files 82 passed (82)` / `Tests 776 passed (776)`. Verbose re-run names both new counter-controls passing. CONSUMER: `pnpm --filter @object-ui/app-shell type-check` -> clean, against a freshly built 29-package closure (app-shell imports plugin-dashboard in source). CHANGESET GATES: check-changeset-presence.mjs -> '4 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)'; check-changeset-no-major.mjs -> 'No changeset declares a major bump.' WHY THE 6425 PIN PASSES, IN WORDS: the refusal is still enforced — by the hand-written tombstone rather than by the derived band; the verdict is unchanged since 2026-08-27 and only the enforcing artefact moved. ABLATION PROVING THAT (not a bare green): neutralized the tombstone to an empty object type; NO REBUILD IS INVOLVED OR NEEDED HERE and that is a property of the subject, not an omission — both pin suites import ../ObjectDataTable as a RELATIVE SOURCE path, so tsc and vitest both resolve source, never dist, and the mutation takes effect directly. Mutation confirmed on disk by grepping BOTH directions anchored on the changed text (injected-text count 1, original-text count 0) and by blob hash moving 012508df -> c430a2f6 — never by the editor's exit code. Result: ABLATED_TYPECHECK_EXIT=2 with error TS2578 'Unused ts-expect-error directive' at emitBoundary-6373.test.tsx(337,5) AND overrideSource-6425.test.tsx(272,5), plus TS2339 at overrideSource-6425.test.tsx(218,60). So without the tombstone this really would have been a pin passing because its subject stopped existing. SECOND ABLATION LEG, and the more useful one: on that same ablated tree the RUNTIME suites stayed GREEN — `Test Files 2 passed (2)` / `Tests 22 passed (22)`, exit 0 — because ts-expect-error is type-erased. The blindness is one-sided: only tsc sees it, a test-run green sees nothing. Both legs restored via `git checkout HEAD -- ABSOLUTE_PATH` under a `trap ... EXIT INT TERM` with an absolute REPO_ROOT, and the restore PROVEN by observed state rather than exit code: blob hash back to 012508df and `git diff HEAD` empty (empty hash would have been read as failure, not as 'nothing to compare').",
 "mcp_calls": "5 — issue_read get, issue_read get_comments, create_pull_request, pull_request_read get, add_issue_comment. Everything else went through git and local greps.",
 "open_questions": [],
 "out_of_scope_findings": [
 "NOT FILED, and deliberately so — objectui#6597 (referenceTo) does NOT fold cleanly, and this is the answer you asked for. MECHANICALLY it folds: FieldMeta.referenceTo is written-never-read on this path by the same evidence (LookupCellRenderer resolves reference_to / reference, computeLookupExpand reads the object schema), it sits in the same type, and removing it hits the SAME coupling — it would drop out of EnrichedColumn's write-side tombstone band, so it needs the identical hand-written tombstone, roughly fifteen lines next to the one this PR adds. DECISIONALLY it does not: #6597 is an enforce-or-remove card whose verdict is still open between TWO branches — fix the spelling chain so the README promise becomes real, or withdraw the README line — and only one of those is a removal. Folding it would silently pick the removal branch on your behalf, which is exactly the ruling that card exists to obtain. What I would need to fold it: your ruling that #6597 takes the WITHDRAW branch. Given that, it is a small addition to this PR; without it, it must not ride along.",
 "NOT FILED — the two-band coupling is recorded in the PR body and in the code, not as a new card, since it is this card's own subject seen more completely. Worth carrying into future retire dispatches as a rule: this repo has TWO seam bands derived from keyof FieldMeta, and a dispatch fence that names only one of them under-describes the blast radius of removing any member."
 ]
}

---

Generated by Claude Code