[objectstack-fleet]

Fixes #20011
Clause-②: yes

FieldSchema stops comparing a currency field's field-level precision with the ISO 4217 fraction digits of its fixed currency. precision: 18 on a fixed-USD field now parses. currencyConfig.precision is a different key, and its check is untouched.

What was wrong (reproduced on origin/main e4471e64, before any edit)

FieldSchema.safeParse through the source, one field per row:

input (type: 'currency')	result on e4471e64
precision: 18, fixed USD	REFUSED at ['precision']
precision: 2, fixed USD	accepted
precision: 1, fixed USD	REFUSED at ['precision']
precision: 18, fixed JPY	REFUSED at ['precision']
precision: 0, fixed JPY	accepted
precision: 18, dynamic	accepted
precision: 18, no currencyConfig	accepted
type: 'number', precision: 18	accepted

The refusal text for the first row, which this PR removes from the field-level path:

currency USD has 2 fraction digits; precision: 18 contradicts it — the amount would render minor-unit digits the currency does not have, or drop digits it does (ISO 4217 / CLDR currencyData). Declare precision: 2, or omit precision and let renderers derive the width from the currency. Codes outside CLDR (crypto/custom) are not checked, and a field in dynamic currencyMode has no single currency to check against.

The key is declared precision: z.number().int().min(0).optional().describe('Total digits (non-negative integer)'). A DECIMAL(18,2) amount is precision: 18, and the remedy asked for a total-digit count of 2. Ruling 乙 on #19910 (5805782503): 「## Ruled — 乙: a currency's decimal places are the currency's, not a setting」.

Real producer: objectui's Studio field designer offers a "Precision" control on every numeric type, currency included (packages/app-shell/src/views/metadata-admin/inspectors/ObjectFieldInspector.tsx:917-919 at the pin f8a9d0fb, patchDef({ precision: v })). An admin who types 18 on a fixed-USD currency field gets this refusal at save.

The premise, re-measured (it is false everywhere)

The check's own comment named its premise: 「the FIELD-level precision key doubles as the currency display width — objectui's CurrencyField reads it」. Before removing it, every face was checked for a read of field-level precision as decimal places. None was found.

objectui at the console pin f8a9d0fb0596 (.objectui-sha on main). git grep -w precision over non-test packages/** and apps/** *.ts / *.tsx gives 83 lines. Each one is one of these:

• A comment or doc. For example, CurrencyField.tsx:64-78 says 「⛔ NOT the field-level precision」.
• A type declaration. types/src/field-types.ts:407,436,446.
• A pass-through copy into a metadata object: ObjectGrid.tsx:2863,3084,3250, RelatedList.tsx:1607, RecordDetailPanel.tsx:167, sectionFields.ts:321, ObjectGallery.tsx:367, useColumnSummary.ts:492.
• The designer's write above.
• formatPercent's own parameter of that name. Its callers pass scale.

The faces that format numbers:

• CurrencyField derives its width from currencyFractionDigits(currency).
• CurrencyCellRenderer calls formatCurrency(num, currency, locale) with no width argument.
• NumberCellRenderer and PercentCellRenderer read scale.
• The grid footer's currency arm calls formatCurrency and reads neither key.
• ObjectMetricWidget resolves only the currency.
• The detail chip reads scale.

objectstack. No packages/** source reads the field-level key. NUMERIC_COLUMN_REPRESENTATION.currency is a fixed (65, 30) column. driver-sql/src/builtin-column-collision.ts:77 says precision is 「this driver does not read it yet」. objectql has no write-seam total-digit check.

So the check guarded a reading that no longer exists. What it still did was refuse the ruled contract.

Decision: delete the check, keep no residual

Zone 2 of the dispatch asked whether some residual stays true, for example precision below the currency's fraction digits. Measured: no numeric type has a total-digit coherence rule. { type: 'number', precision: 1, scale: 2 } parses on main, and so does { type: 'percent', precision: 0, scale: 3 }. Four-axis reading:

• Business need. Nothing reads the key, so a residual guards the internal consistency of a value with no effect. The census below finds no authored producer in any of the three repos.
• Long-term fit. A total-digit coherence rule belongs next to a total-digit enforcement (DDL or the write seam), and neither exists. A currency-only, fixed-mode-only remnant would be the one such rule in the spec.
• AI-authoring safety. The mistake an AI plausibly makes is precision: 2 meaning "decimals". Refusing that would narrow the accept set, which neither this card nor the dispatch authorizes; the dispatch requires that precision: 2 keep parsing. The larger trap is that the key is inert everywhere. That goes to the seat as a finding (Acceptance notes), not a new rule here.
• Startup focus. A new refusal rule is a new gate, and the default is no.

A comment at the old site records why the comparison is absent, so it is not reinstated as an "improvement".

Changes

• packages/spec/src/data/field.zod.ts: the field-level currencyPrecisionContradiction call inside FieldSchema's .superRefine is deleted, and a comment replaces it. The import comment is updated. Region fence: hunks only at the import comment and the old anchor. There is no hunk in CurrencyConfigSchema (its .superRefine / .overwrite and the precision default, [finding] currencyConfig.precision is declared and validated against ISO 4217, but no renderer or runtime reads it — an ADR-0049 enforce-or-remove case, filed on ruling 乙 on #19910 #19992's region), in SelectOptionSchema, or in the requiredWhen / readonlyWhen region.

• packages/spec/src/data/currency-fraction-digits.ts: doc comments only. The helper keeps both of its readers, in CurrencyConfigSchema's .superRefine and .overwrite. The docblock no longer says "shared by BOTH anchors", and it now states that the verdict is ⛔ not for the field-level key. The message text is unchanged.

• packages/spec/src/data/currency-precision-iso4217.test.ts: the field-level block is rewritten (pins below). The header docblock is updated.

• content/docs/data-modeling/field-types.mdx and validation-rules.mdx: both claimed a declared precision must agree with the currency. This PR makes that false for the field-level key, so the text now names currencyConfig.precision. It also says the field-level key is total digits and is never compared. New text in field-types.mdx:

  A currency amount's decimal places are its currency's ISO 4217 minor unit (2 for USD, 0 for JPY, 3 for KWD), not a field setting, so a currency field takes no scale: publish-time validation refuses the key. The field-level precision is the amount's total digit count — a DECIMAL(18,2) amount declares precision: 18 — and is never compared with the currency.

  The same section's table also listed scale ("Decimal places") as a currency property. That contradicts the new paragraph and the landed spec refusal (field.zod.ts, scale on currency is refused, with the same wording in protocol/objectql/schema.mdx), so the row is deleted.

• .changeset/20011-currency-field-precision-total-digits.md: @objectstack/spec minor, Clause-②: yes (widening). Nothing is narrowed, so there is no ADR-0087 entry (check:adr-0087-registration exit 0).

Pins (currency-precision-iso4217.test.ts, block #20011 — field-level precision is total digits…)

• precision: 18 on fixed USD parses, and data.precision is still 18.
• precision: 2 on fixed USD still parses.
• Flipped: precision: 2 on fixed JPY parses (DECIMAL(2,0)). This is the old rejects … (JPY + 2) pin.
• Total digits parse on every fraction-digit class: JPY 0 / 12, USD 2 / 18, KWD 3 / 2 / 15, each with the authored value carried through.
• No currency-only coherence rule: USD precision: 1 parses, as number with precision: 1, scale: 2 does.
• Outside fixed mode (no currencyConfig, dynamic authored or defaulted), nothing changes. Non-currency types are untouched.
• Through the object door: ObjectSchema.create with a fixed-USD precision: 18 field, then ObjectSchema.safeParse of the JSON round-trip, succeeds and keeps 18.
• Kept refusal (genuine, a different key): currencyConfig: { precision: 2, currencyMode: 'fixed', defaultCurrency: 'JPY' } through FieldSchema is refused at ['currencyConfig', 'precision'], code custom. The message contains currency JPY has 0 fraction digits and the prescription Declare \precision: 0``.
• Flipped: the old both anchors fire independently pin. With both keys authored, exactly one issue is raised, at ['currencyConfig', 'precision'] (code + path + prescription asserted). The field-level key raises nothing.
• The #7918 currencyConfig-level block, the #11423 materialization block and the digit-table block are untouched and green.

Pin sweep. Searched for fraction digits; and contradicts it — across objectstack, objectui at the pin, and cloud 48d70663. The only field-level pins were in this test file. The other currencyMode: 'fixed' fixtures (field.test.ts, field-currency-scale-refused.test.ts, three service-analytics tests) carry no field-level precision.

Reverse verification

Run on the committed fix accdab16 with scripts/ablation-replace.mjs plus its own trap restore. The mutation re-inserts the old field-level check under a marker. The marker count was 0, then 1 during the run, then 0 after. The blob went 26f8ef39 → 5c392b24 and back to 26f8ef39.

Expected direction: red. Observed: 6 failed, 24 passed, and the six are exactly the new acceptance pins. Restore was proven by blob == HEAD and an empty git diff HEAD, not by an exit code.

The first attempt was a no-op. My replacement contained the anchor text, so the anchor count could not drop, and the tool refused it before running the test. It was redone with a replacement that drops the anchor. The later merge of main touched neither mutated file.

Producer census (authored currency fields with a field-level precision)

The detector parses Field.currency({…}) and type: 'currency' object literals and reads their top-level keys.

tree	non-test currency declarations	with field-level precision	control (tests, same detector)
objectstack e4471e64 (examples/**, packages/**)	31	0	194 declarations, 2 hits (object.test.ts:800 = 18, lint-liveness-properties.test.ts:780 = 2)
objectui f8a9d0fb	5	0	180 declarations, 14 hits
cloud 48d70663	0	0	44 declarations, 0 hits; no non-test field precision anywhere in packages/**

The one live producer is the Studio designer control named above.

Verification (final head 0e006877, after merging main at 172b4cf3)

• @objectstack/spec suite (vitest run --project local): 540 files, 15871 passed, 2 todo.
• @objectstack/spec typecheck (tsc --noEmit, scripts, test layer): exit 0, and the test-layer debt ledger held.
• check:generated: all 15 generated artifacts up to date.
• Consumer suites: @objectstack/lint 108 files / 4183 passed; @objectstack/platform-objects 55 / 911 passed.
• Gates: dispatch-gates.mjs --commands derived 104 commands for these 6 paths. All 104 exit 0 at 0e006877. --ran reconciliation: 104 derived, 104 run, 0 NOT MEASURED, a derived zero because every line recorded its exit code.
  • At the final head, one first run (check:dual-build-cjs-loads) exited 3 (PREREQUISITE NOT MET). It was re-run to 0 once the packages it named were built.
  • The pre-merge pass at accdab16 had seven such refusals, all cleared the same way.
  • None of those refusals counts as a measurement.
• ESLint, narrowed to the three touched .ts files:
  • All three resolve a config under --print-config.
  • --format json reports 3 files, 0 errors, 0 warnings.
  • eslint.config.mjs never enables type-aware linting (its own note at :326-328), so this diff cannot move any untouched file's verdict.
  • pnpm lint over the whole repo is CI's run.
• NOT MEASURED locally, declared to CI:
  • Dogfood. No dogfood test pins currency precision.
  • The workspace, examples and downstream-contract type-check lanes.
  • The CI-only jobs these paths schedule.

Acceptance notes

• Finding for the seat (not filed here): the field-level precision key has no reader at all. It is declared "Total digits (non-negative integer)" and the Studio designer writes it on every numeric type. Nothing enforces it: not DDL (fixed (65, 30)), not the write seam, and no display face. packages/spec/liveness/field.json props.precision still reads live, citing objectui @11c1e71e reads (CurrencyField.tsx:45, PercentField.tsx:13, index.tsx:662, useColumnSummary.ts:261), all of which are gone at f8a9d0fb. This is the same family as [finding] currencyConfig.precision is declared and validated against ISO 4217, but no renderer or runtime reads it — an ADR-0049 enforce-or-remove case, filed on ruling 乙 on #19910 #19992, which covers currencyConfig.precision with no reader. Details are in the dev report on the card.
• [finding] currencyConfig.precision is declared and validated against ISO 4217, but no renderer or runtime reads it — an ADR-0049 enforce-or-remove case, filed on ruling 乙 on #19910 #19992 (the CurrencyConfigSchema.precision anchor) is not addressed here and remains open. Its region is untouched.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/spec, touching 1 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/spec/src/data/currency-fraction-digits.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

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

• 1 changed file(s) yielded no anchor (packages/spec/src/data/currency-fraction-digits.ts) — pages documenting those are invisible to this run
• the SDK route bridge reached 54 of 207 client-bound route-ledger rows — the other 153 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 153: 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; 98 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.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

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 1c8b320a894b31dcfc76c33c8e7a62b8986d893a → packageMentionDocs.

Which tree this was computed on

This run read content/docs from be91d11c842b2224db031c9fb404dc9425399a26 — the merge of head 0e006877963089d9c1f90b18a69614a15b3578b8 into base 1c8b320a894b31dcfc76c33c8e7a62b8986d893a, 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 be91d11c842b2224db031c9fb404dc9425399a26 && git checkout be91d11c842b2224db031c9fb404dc9425399a26
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 1c8b320a894b31dcfc76c33c8e7a62b8986d893a 0e006877963089d9c1f90b18a69614a15b3578b8 && git checkout -B drift-repro 1c8b320a894b31dcfc76c33c8e7a62b8986d893a && git merge --no-ff 0e006877963089d9c1f90b18a69614a15b3578b8

node scripts/docs-audit/affected-docs.mjs --json 1c8b320a894b31dcfc76c33c8e7a62b8986d893a

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

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 0e006877963089d9c1f90b18a69614a15b3578b8

① Derived judgments

• The deleted guard is exactly the Contract question: should publish-time validation reject a declared currency precision that contradicts the currency's ISO 4217 digits? #7918 FIELD-level anchor and nothing else. git diff origin/main 0e006877 -- packages/spec/src/data/field.zod.ts has two hunks: the import comment (:31-34) and the FieldSchema.superRefine block that read field.type === 'currency' && field.precision !== undefined && field.currencyConfig?.currencyMode === 'fixed' → currencyPrecisionContradiction(defaultCurrency, precision) → ctx.addIssue({ path: ['precision'] }) (main :2314-2333), now a comment. The removed code only ever ADDED an issue (no transform), so every previously accepted field's output is byte-identical, as the changeset says. Right. Merge-base 172b4cf3..head is exactly the 6 files in diff.patch; the 3 commits main gained since (1c8b320a) touch none of them (identical per-file line counts in git diff --stat origin/main..head for those six).
• What now parses that was refused before — measured, head vs origin/main field.zod.ts in a detached probe worktree (probe.mts, same node_modules). 30-row matrix (probe-head.jsonl / probe-main.jsonl; main = head's tree with origin/main:field.zod.ts swapped in, blob 8f35ae5d → 26f8ef39 restored, git diff HEAD empty). Refused→accepted, with the authored value carried: fixed USD precision 18 / 1 / 0, fixed JPY 2 / 18, fixed KWD 2 / 15, fixed with defaulted CNY 0, and ObjectSchema.create + JSON re-parse with fixed-USD 18 (main threw at fields.amount.precision; head keeps 18). Unchanged verdict AND message on every other row: agreeing values (USD 2, JPY 0, KWD 3), fail-open BTC 8, dynamic / defaulted-mode / no-currencyConfig, absent precision, precision: 2.5 (int guard), scale: 2 on currency (still refused at ['scale'], [finding] FieldSchema.scale on a currency field is offered to authors by the field designer, ignored by every display face, and still enforced on writes — half-live in the direction that surprises #19629), number 18, number 1+scale 2, percent 0+scale 3. Two rows still refuse with a SHORTER issue list: precision: -1 (main: int guard + contradiction; head: int guard only) and both keys authored (below). All 13 accepted-on-both rows are byte-identical (JSON.stringify equal). So the widening is exactly "field-level integer precision ≠ the fixed currency's CLDR fraction digits, known codes only" and nothing else.
• currencyConfig.precision anchor ([finding] currencyConfig.precision is declared and validated against ISO 4217, but no renderer or runtime reads it — an ADR-0049 enforce-or-remove case, filed on ruling 乙 on #19910 #19992's region) refuses exactly as before. Call sites at head field.zod.ts:466 (.superRefine) and :506 (.overwrite), identical text to main :465/:505 (one-line shift from the import comment; no hunk in CurrencyConfigSchema, SelectOptionSchema or the requiredWhen/readonlyWhen region). Probed at head, same as main: currencyConfig: { precision: 2, currencyMode: 'fixed', defaultCurrency: 'JPY' } and KWD refused at ['currencyConfig','precision'] with "currency JPY has 0 fraction digits; precision: 2 contradicts it …"; { precision: 0, currencyMode: 'fixed' } (defaulted CNY) refused; the scale alias under currencyConfig still refused as an unrecognized key with the precision suggestion; agreeing USD 2 accepted with identical output. With BOTH keys authored (field precision: 2 + currencyConfig.precision: 2, fixed JPY): main raised two issues, head raises exactly one, at ['currencyConfig','precision'] — the field is still refused. Right.
• The premise is TRUE at the objectui pin f8a9d0fb0596 (.objectui-sha on main and head). git grep -n -w precision f8a9d0fb -- 'packages/**/*.ts{,x}' 'apps/**/*.ts{,x}' minus tests = 83 lines; the 27 non-comment lines are: type declarations (types/src/field-types.ts:407,436,446, form-spec.ts:191), i18n labels, formatPercent/formatPercentBody's own parameter name (fields/src/index.tsx:588-659; its callers pass scale, a pattern-derived decimals, or undefined), pass-through copies into field meta (ObjectGrid.tsx:2863,3084,3250, RelatedList.tsx:1607, RecordDetailPanel.tsx:167, sectionFields.ts:321, ObjectGallery.tsx:367, fieldEnrichment.ts:231, useColumnSummary.ts:492 — built into columnHints and never read by formatSummaryLabel), and the one WRITER ObjectFieldInspector.tsx:917-919 (patchDef({ precision: v }), comment :287 calls it the field-level TOTAL digit count). Faces read: CurrencyField.tsx:80 fractionDigits = currency ? currencyFractionDigits(currency) : 2 (neither key); NumberCellRenderer index.tsx:772 numField.scale; PercentCellRenderer :852 scale ?? 0; formatCurrency(value, currency?, locale?) (:472) takes no width and is what the grid footer's currency arm calls (useColumnSummary.ts currency arm; percent arm column?.scale ?? 0); ObjectMetricWidget.tsx resolves only the currency (resolveFieldCurrency) and a format by type; DetailView.tsx:1259 percentField.scale ?? 0; PercentField.tsx declaredScale = percentField?.scale; ObjectForm.tsx:874-877 copies min/max only. No apps/** hit, no export face reads it, no .js/.mjs hit. So NO face reads the field-level precision as decimal places: the stop condition did not trigger.
• objectstack's own readers: none. \.precision\b over non-test packages/**/*.ts at head: cli/src/commands/generate.ts:1687,2789 and driver-sql/src/sql-driver.ts:18651 read numeric.precision where numeric = numericColumnFor(type) (the fixed NUMERIC_COLUMN_REPRESENTATION, currency: EXACT), never the field; -w precision over packages/*/src outside spec: comments only (objectql, formula, runtime, service-analytics read nothing). Inside spec: CurrencyConfigSchema (a different key), the spec: Field.scale accepts meaningless declarations (2.5, -1) — now that scale is enforced, malformed declarations should be refused at authoring time #8321 conversion field-malformed-scale-precision-removed (shape only), object.form.ts:189 offers the control with helpText Total digits. Storage, drivers, objectql, formula, analytics: no reader. Right.
• No residual rule — judged right on the four axes. Business need: nothing reads the key and no producer authors it (examples: 0 currency fields with a top-level precision; the only writer is the Studio control), so a residual (precision below the minor unit) would guard the internal consistency of an inert value. Long-term fit: a total-digit coherence rule belongs beside a total-digit ENFORCEMENT (DDL or the write seam) and neither exists; measured on main's field.zod.ts: { type: 'number', precision: 1, scale: 2 } and { type: 'percent', precision: 0, scale: 3 } both parse (byte-identical at head), so a currency-only, fixed-only remnant would be the one such rule in the spec. AI-authoring safety: the plausible AI mistake (precision: 2 meaning decimals) is harmless because nothing renders from it, and the dispatch requires precision: 2 to keep parsing; the real trap is the inert key, which is a finding (③), not a rule. Startup focus: no new gate. The site comment forbids reinstating a comparison, which is the right guard against an "improvement".
• Test block: acceptance pins bear weight; no genuine refusal pin deleted. Old block: 7 its; new: 10. The two flipped pins are the widening itself: rejects … (JPY + 2) at ['precision'] → accepted with the authored value carried; both anchors fire independently → still success: false, now asserting exactly ONE issue at ['currencyConfig','precision'] with code, path, message and the Declare \precision: 0`prescription — the genuine refusal is still pinned through theFieldSchemadoor (and separately in the untouchedContract question: should publish-time validation reject a declared currency precision that contradicts the currency's ISO 4217 digits? #7918 currencyConfig-levelblock). Agreeing values (JPY 0, KWD 3) are subsumed by the digit-class loop; no-config, dynamic and non-currency pins kept; added: USD 18 carried,ObjectSchema.createround-trip, no-coherence parity. Ablation re-run here: head's test file againstorigin/main:field.zod.ts(anchor count 2 = the re-inserted field-level call + thecurrencyConfigone) →6 failed | 24 passed (30), the six being exactly the new acceptance pins (USD 18, flipped JPY 2, digit-class loop, no-coherence parity, object door, both-keys-one-issue); restored file blob 26f8ef39== head, then30 passed (30). The pins bear weight. The #7918's relocated currency precision default is round-trip unsafe: a bare fixed-JPY currencyConfig materializes precision 2, and re-parsing that output is rejected #11423` block and the digit-table block have no hunks.
• Docs, sentence by sentence. field-types.mdx: (a) "a currency field takes no scale: publish-time validation refuses the key" — TRUE on main: field.zod.ts if (field.type === 'currency' && field.scale !== undefined) → path ['scale'] ([finding] FieldSchema.scale on a currency field is offered to authors by the field designer, ignored by every display face, and still enforced on writes — half-live in the direction that surprises #19629), pinned in field-currency-scale-refused.test.ts; the deleted scale | Decimal places row was therefore false on main, and deleting it is right. (b) "The field-level precision is the amount's total digit count — a DECIMAL(18,2) amount declares precision: 18 — and is never compared with the currency" — TRUE as the key's declared meaning (describe Total digits (non-negative integer), form helpText Total digits, generated references/data/field.mdx:70) and true at head for the comparison; it states a MEANING, not an enforcement — storage is the fixed numericColumnFor('currency') column and no face reads the key — so the DECIMAL(18,2) example teaches a sizing the platform does not perform. Not false; flagged in ③. (c) The currencyConfig.precision paragraph is the old rule re-keyed: TRUE for the rule at head; "Omit currencyConfig.precision to let renderers derive the width from the currency itself" implies a reader for that key, and objectui at the pin reads currencyConfig.precision nowhere (one comment hit, CurrencyField.tsx:74) — pre-existing wording, [finding] currencyConfig.precision is declared and validated against ISO 4217, but no renderer or runtime reads it — an ADR-0049 enforce-or-remove case, filed on ruling 乙 on #19910 #19992's region, flagged in ③. validation-rules.mdx:155: TRUE (the field-level key is not compared). The unchanged "Precision defaults to 2 decimal places" sentence is the currencyConfig default, pre-existing.
• Changeset body claims. "Nothing that parsed before is refused now" and "output of every previously accepted field is byte-identical": TRUE (issue-only removal). "scale on a currency field is still refused": TRUE (above).

② Semver level

• @objectstack/spec: minor with Clause-②: yes (widening) in the changeset and Clause-②: yes in the PR body. Both spellings are the legal pair in scripts/pm/clause2-line.mjs (yes / yes (widening) — "both take at least minor"). check-changeset-no-major.mjs's level axis (clause ② declared ⇒ at least one moved package graded minor or above) is satisfied by spec: minor; a fix( type may raise a bump but never lower it, so minor stands. The Check Changeset check-run on this head is success. Level and wording are right for a widening that removes a ruling-installed refusal: the accept set grows, nothing is renamed or retired, no consumer migrates.
• ADR-0087 entry rightly absent. check-adr-0087-registration.mjs breakingDeclaration() fires on major, **BREAKING, a ! summary, or a Clause-② arm reading narrowing — its own docblock: "A widening is not a break". Precedent: .changeset/19320-percent-storage-scale-derivation.md (Clause-②: yes (widening), spec+objectql minor, 36 cells refused→accepted, no ADR-0087 marker) — the precedent ruling 乙 item 4 itself names. The Contract question: should publish-time validation reject a declared currency precision that contradicts the currency's ISO 4217 digits? #7918 field-level refusal never had a ledger entry (7918 occurs nowhere under packages/spec/src/migrations), so there is no entry to retire or amend; the #7918 changeset is not in stock (released in v17). The removed refusal is recorded where a widening is recorded: the changeset body and the site comment.

③ Boundary flags

• The field-level precision key has no reader anywhere, and the liveness ledger's live verdict rests on retired evidence. packages/spec/liveness/field.json props.precision reads live (verifiedAt 2026-08-10) citing objectui @11c1e71e reads at CurrencyField.tsx:45, PercentField.tsx:13, index.tsx:662, useColumnSummary.ts:261; at the pin f8a9d0fb all four are gone (CurrencyField derives from the currency; PercentField, the percent cell and the footer read scale). The Spec property liveness check-run is green on this head, so that gate does not re-measure cross-repo evidence at the pin. Meanwhile object.form.ts:189 and objectui's ObjectFieldInspector.tsx:917-919 offer and write the key on every numeric type: an author writing precision: 10 expecting a DECIMAL(10, s) bound gets nothing (DDL is fixed, the write seam reads scale only). ADR-0049 enforce-or-remove applies. The seat reports it folded into [finding] currencyConfig.precision is declared and validated against ISO 4217, but no renderer or runtime reads it — an ADR-0049 enforce-or-remove case, filed on ruling 乙 on #19910 #19992 (same family, currencyConfig.precision no-reader); [finding] currencyConfig.precision is declared and validated against ISO 4217, but no renderer or runtime reads it — an ADR-0049 enforce-or-remove case, filed on ruling 乙 on #19910 #19992 is outside this review's inputs, so the fold is reported, not verified here. Not this PR's to fix; this PR does not make it worse (the check it removes enforced nothing about total digits either).
• Published text claiming the old field-level rule: none found at head. fraction digits / contradicts it / must agree over the whole tree (excluding CHANGELOGs): only the two rewritten docs pages, the scale describe rows (which state the currency-minor-unit contract), releases/v17/index.mdx:175 (history) and field.test.ts:891 (a reference to the .overwrite shape). Generated references/data/field.mdx:70 precision | Total digits and skills/objectstack-data/rules/field-types.md:175 (currencyConfig.precision: 2 on fixed USD, agreeing) are consistent. The remaining #7918 currency precision twin comment at field.zod.ts:2458 refers to #7918's relocated currency precision default is round-trip unsafe: a bare fixed-JPY currencyConfig materializes precision 2, and re-parsing that output is rejected #11423 (the currencyConfig anchor) and stays accurate. currency-fraction-digits.ts docblock now says ⛔ not for the field-level key.
• Docs sentence with an implied reader. "Omit currencyConfig.precision to let renderers derive the width from the currency itself" (field-types.mdx:175-176) — renderers derive the width from the currency whether or not the key is declared; the sentence is the Contract question: should publish-time validation reject a declared currency precision that contradicts the currency's ISO 4217 digits? #7918 message's own wording re-keyed and belongs to [finding] currencyConfig.precision is declared and validated against ISO 4217, but no renderer or runtime reads it — an ADR-0049 enforce-or-remove case, filed on ruling 乙 on #19910 #19992's resolution.
• Authority chain. The anchor was installed under the 2026-08-12 Contract question: should publish-time validation reject a declared currency precision that contradicts the currency's ISO 4217 digits? #7918 ruling (Option A); its removal rests on ruling 乙 (5805782503, item 3 names reading the field-level precision as decimal places as wrong) plus triage's re-derivation (5820411734, which carries its own 「如果维护者另有看法，以维护者为准」). The maintainer has not been asked in one word to confirm retiring the FIELD-level anchor specifically. The derivation is sound (the key's declared meaning and 乙 leave the Contract question: should publish-time validation reject a declared currency precision that contradicts the currency's ISO 4217 digits? #7918 rule with exactly one key whose meaning is decimal places, currencyConfig.precision, which keeps it), and this record is the at-tier review the claim named; recorded so the maintainer sees the step.
• In-place docs deviation. The dev deleted the scale row without a board scan (condition 3 unverified by dev); the seat reports docs(content): apply the approved search-intent title rule to 169 authored pages, short nav labels kept via navTitle #20170 as the only other open PR on these pages (frontmatter only, clean merge-tree). Outside this review's inputs; noted as reported.
• Check-runs at this head (final poll): 39 total — 34 success, 5 skipped, 0 in progress, 0 failing (Test Core 1-6, Dogfood 1-3, Type Check lanes, Lint & Repo Gates, Check Changeset, Spec property liveness, Console Pin Gate skipped, all complete).

Implemented-by: claude/issue-20011-currency-field-precision-anchor
Reviewed-by: session_01Rjy9MeetSfq34PKn81CRiN

VERDICT: PASS