Say why precision.json omits PreciseNumber, and what adding a storage type means [patch]

[matt-edmondson]

Refs #236. Does not close it — see "What this deliberately does not do".

#236 ends on a note that holds under all three of its options: precision.json's relationship to the alias packages should be written down, because "add the storage type to precision.json" is the natural assumption when someone adds the fifth, and it is wrong. That part needs no decision, so it is here on its own. Same shape as ImGuiApp#434 against ImGuiApp#384.

What was wrong

Four storage types ship, one per alias package — Semantics.Quantities.{Double,Float,Decimal,Precise}. precision.json lists three. Nothing in the repository said why, and docs/physics-generator.md actively pointed the wrong way, describing StorageTypes.g.cs as:

The storage types the alias packages cover (decimal, double, float)

That is not what it is. It is the entries of precision.json, and the alias packages cover a fourth the file does not list. A reader who trusts that row concludes the file is the registry of supported storage types and that Precise was forgotten.

The two reasons, verified against the code rather than the issue

Both checked at b0d9485:

• PrecisionGenerator.cs:31 sets Namespace = "ktsu.Semantics.Quantities" — the core — and :53-60 emits DefaultValue = $"typeof({storageType})". A typeof(PreciseNumber) there would make Semantics.Quantities reference ktsu.PreciseNumber, undoing the separation the alias packages exist to keep. Precise carries that PackageReference precisely so the core does not.
• The same block sets Name = storageType.ToUpperInvariant(), so only a C# keyword yields an identifier. ktsu.PreciseNumber.PreciseNumber becomes KTSU.PRECISENUMBER.PRECISENUMBER.

Also confirmed the issue's other premise still holds: outside Generated/, the only mentions of StorageTypes anywhere in the repository are PrecisionGenerator and PrecisionMetadata themselves. There is no reader, so the omission costs nothing at runtime.

Changes

• CLAUDE.md — one bullet in "Working with the source generator", next to the existing alias-props bullet, stating that adding a storage type means a new alias package, its generated build/*.props, and one derived StorageConversionTests<T> class, and that precision.json is not part of it.
• docs/physics-generator.md — corrects the PrecisionGenerator table row, and adds a "Storage types and precision.json" section with the generator excerpt and both consequences spelled out.

The claim about what adding a storage type does require is the repo's own: CLAUDE.md:363 already says "Adding a storage type is one derived class" of StorageConversionTests<T>, and :47 already documents the alias packages and Precise's PackageReference. This connects those to precision.json, which neither did.

Tests

None, and none are possible — the change is two Markdown files. Nothing is generated from either, so the verify-generated workflow is unaffected by construction. No markdownlint config or CLI exists in this repo to run against it.

The factual claims were verified by reading the code named above rather than by a test, which is the available check here.

What this deliberately does not do

The decision #236 is actually about — whether StorageTypes should exist at all (remove it as a major change, keep it and move it out of the core, or leave it enumerating three of four) — is untouched. This change describes the current state and the trap in it; it does not pick a branch, and #236 stays open for that call. The new docs section says so and links back.

🤖 Generated with Claude Code

https://claude.ai/code/session_019ZbSovwSDQ4i4nSzyPXmY3

---

Generated by Claude Code