docs: record the JSON type a numeric attribute takes on each read path

[robrigo]

Why

Nothing in the corpus said what JSON type a numeric attribute value takes, and the answer is not one type. nodeos prints every float as a quoted decimal string of the widened double, @wharfkit/antelope follows the same convention, and the hosted APIs answer a JSON number, except on values that reached the database through the ABI action path, where the indexer objectified the string form and stored it. A reader written against one path and pointed at another reads the right value at the wrong type.

The page also records where the node's convention loses information. Float32.toString() is toFixed(7), which keeps seven decimal places where a float32 carries about seven significant digits, so a value needing more than seven fractional decimals cannot be read back, and two adjacent float32 values above 0.5 print alike.

The page sits at the reference root rather than under reference/atomicassets/, because none of its facts are contract facts and it covers AtomicMarket fee fields as well. reference/media.md is the precedent for a root-level page that spans layers.

Validation

Every claim carries a source line naming a live read or the library source. Three reads were run for this page and reproduce: an AtomicAssets asset read answering "Strength":"170.7" for a double attribute and "market_fee":0.07 for the collection in the same body, a template read answering "version":1 for a double attribute, and an AtomicHub read answering "market_fee":"0.05" inside collection.extended_attributes. The path rule is read off those responses rather than off indexer source, which the ledger row states. check-frontmatter.mjs, check-validation-consistency.mjs and markdownlint-cli2 are clean.

[Copilot]

Pull request overview

Adds reference guidance for numeric JSON representations across chain, SDK, and hosted API read paths.

Changes:

• Documents float and 64-bit integer JSON types and float32 precision loss.
• Adds validation records, routing, and serialization cross-reference.
• Records the addition in the README and changelog.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
reference/numeric-values-in-json.md	Adds the numeric JSON type reference.
reference/validation.md	Records sources, versions, and validation evidence.
reference/atomicassets/serialization.md	Links decoding guidance to the new reference.
AGENTS.md	Adds outcome-based routing to the page.
README.md	Lists numeric JSON types in repository coverage.
CHANGELOG.md	Records the new documentation.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.

Suppressed comments (1)

reference/numeric-values-in-json.md:47

• Only the JSON type matches nodeos; the textual values are not “exactly” the same. Nodeos is described above as widening to 17 fixed places, while WharfKit uses 7 fixed places for Float32 and the shortest number string for Float64, so consumers can receive different text and float32 round-trip behavior.

`@wharfkit/antelope` follows the node's convention rather than the one the hosted APIs use. `Float32.toString()` returns `value.toFixed(7)`, `Float64.toString()` returns `value.toString()`, and `Float.toJSON()` returns that string, so `Serializer.objectify` yields a string for both widths. Code that decodes a chain response through the library and hands the objectified result to application code is handing it strings, exactly as a raw nodeos read would.