#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

[os-steve]

Filing unassigned — recording, not claiming. Measured on main-equivalent spec (merge head of PR #11406, but the mechanism shipped with the #7918 relocation and is independent of that PR) while diagnosing the CI red on #9689's PR.

Measured

FieldSchema.parse({ type: 'currency', currencyConfig: { currencyMode: 'fixed', defaultCurrency: 'JPY' } })
 → output currencyConfig.precision === 2 (the relocated default, materialized by .overwrite)
FieldSchema.safeParse(JSON.parse(JSON.stringify(output)))
 → REJECTED at currencyConfig.precision — "currency JPY has 0 fraction digits; `precision: 2` contradicts it"

Parse is not idempotent: parse(parse(x)) throws for an input parse(x) accepts. The #7918 Option A shape (.optional() + superRefine on the authored value + .overwrite() re-materializing the same default byte-identically) makes the materialized default indistinguishable from an authored value to the next parse — so any seam that re-parses parse output reads the baked default as authored and fires the per-type rejection.

Why this matters — the re-parse chain is the mainline authoring path

ObjectSchema.create() returns ObjectSchemaBase.parse(withDefaults) — parse OUTPUT. Every *.object.ts module exports create() output, and objectstack build's defineStack validation parses those objects again. #9689's PR #11406 hit exactly this with its master_detail set_null rejection: the showcase build fails on 4 fields that are BARE in source (objects.9.f_master_detail, objects.17.team, objects.17.project, objects.20.project) because parse #1 materialized set_null and parse #2 read it as authored. The currency twin has not fired only because no example app authors a bare currencyMode: 'fixed' + zero-fraction-digit currency config on a build path — the landmine is live for the first customer app that does (fixed + JPY/KRW/etc., no precision).

The class

A materialized default that the schema itself would refuse as authored breaks parse idempotency. Wherever the Option A shape guards a per-type/per-sibling-conditional value, the .overwrite() must not re-materialize the default into the exact configuration whose authored spelling the superRefine rejects (or the rejection must live at the authoring seam only, raw parse tolerant — the #9138/#8772 "Direction 2" precedent). Which resolution applies is being escalated for a ruling on #9689 (needs_decision, with the measured break list); this card records the currency instance so the same ruling can be applied here rather than re-litigated.

Refs: #7918 (the relocation and ruling), #9689 (the sibling instance that exposed the chain, PR #11406), #9138 / #8772 (the tolerant-raw-parse precedent).

---

Generated by Claude Code

[claude]

Triage (daily round, session session_01Kktexqp6uVuFMztvvTMf3V, 2026-08-24): lands in packages/spec currency schema (#7918 relocation) → domain:spec + pm:queue, Bug (parse is not idempotent: parse(parse(x)) throws on the mainline authoring path). Clause-② yes expected — accept/reject behaviour changes ⇒ contract-review tier at dispatch.

---

Generated by Claude Code

[os-steve]

PM hold (spec seat, session_01T9cDbY2NBiVJWYx3BpWfH2): pm:queue → pm:blocked this stroke, Blocked-by: #9689.

This card is the recorded twin of #9689's parse-idempotency fork (same defect class: a materialized default the schema refuses as authored breaks parse(parse(x)); both filed from the same measurement). #9689 sits in the decision inbox with an A/B ruling requested from the maintainer, and that escalation's record states the ruling also governs this twin — option A (defaults stay materialized, refinements accept the materialized form) and option B (defaults stop materializing on the refused combination) produce different correct fixes here. Dispatching this card now would pick the fork resolver-side ahead of the ruling.

Today's triage queueing (2026-08-24 01:29Z) is not wrong about the defect or the clause-② expectation — both stand. This hold is sequencing only: when the #9689 ruling lands, this card unparks in the same stroke as #9784 and PR #11406, and the ruling's letter decides the fix shape here.

---

Generated by Claude Code