Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@README.md`:
- Around line 636-638: Update the three README bug rows to be platform-scoped
and clearer: change the `json_stringify` and `json_parse` entries to indicate
the limitation applies to the Python host (see vera/codegen/api.py which
delegates to the platform JSON module) rather than project-wide, and reword the
`json_get` row to explain that nested JObject returns an opaque handle (not a
deep copy) because JSON values are immutable in the current model; reference the
symbols `json_stringify`, `json_parse`, and `json_get` when editing the table
rows so the scope and immutability rationale are explicit.

In `@spec/09-standard-library.md`:
- Around line 14-15: Remove "Markdown" from the "Future types" bullet so the
overview matches §9.7.3 and existing runtime/tests; specifically edit the
bullets mentioning "Json type" and "Future types" (the lines containing `Json`
and `Markdown`) and either delete the `Markdown` entry or reclassify it as a
current/implemented type per §9.7.3 to keep the spec consistent.
- Line 1535: The paragraph incorrectly describes Json as opaque runtime handles
like Map/Set and claims all JSON functions are host imports; update it to state
that only json_parse and json_stringify are host imports, that query helper
functions are injected Vera functions, and that Json values are ordinary
heap-allocated ADT nodes in WASM memory rather than i32 handles; reference the
symbols json_parse, json_stringify, Json, Map, and Set to clarify the correct
implementation and contrast the real representation with Map/Set handles.

In `@TESTING.md`:
- Around line 9-12: The headline test LOC in the table row "| **Tests** | 2,967
across 26 files (~33,100 lines of test code) |" is stale; update the "~33,100
lines of test code" figure to the current total (~34,013) (or re-run your
line-count script and replace the number with the exact result), and ensure any
other occurrences of the old LOC value in TESTING.md are updated to match.

In `@tests/test_checker.py`:
- Around line 1923-2029: Add tests in TestJsonChecker for the missing built-ins:
create happy-path and wrong-argument tests for json_array_get,
json_array_length, and json_keys following the existing pattern using _check_ok
and _check_err. For each, add a test method (e.g., test_json_array_get /
test_json_array_get_wrong_type, test_json_array_length /
test_json_array_length_wrong_type, test_json_keys / test_json_keys_wrong_type)
that mirrors the style of test_json_array/test_json_object: use a small snippet
that passes correct types to assert _check_ok (e.g., json_array_get(`@Json.0`, 0)
-> `@Option`<Json>, json_array_length(`@Json.0`) -> `@Int`, json_keys(`@Json.0`) ->
`@Array`<String>) and a sibling _check_err case that calls the same builtin with
an incorrect argument type (e.g., String or Int where Json is expected) and
asserts a "type" error; place these methods inside the TestJsonChecker class
alongside the other json tests.

In `@tests/test_codegen.py`:
- Around line 8871-8884: Add a negative-index edge case to the existing
json_array_get OOB test: update or add a test (e.g.,
test_json_array_get_out_of_bounds) that calls json_array_get on a
JArray([JNull]) with index -1 and asserts the result is None (same expected
behavior as the positive OOB case). Locate the test function named
test_json_array_get_out_of_bounds in tests/test_codegen.py and add the extra
assertion or a separate test following the same pattern as the existing positive
OOB check to validate the lower-bound behavior.
- Around line 8643-8695: The tests use string_length(json_type(...)) which only
verifies length and can mask wrong values; update each test (e.g.,
test_json_type_null, test_json_type_bool, test_json_type_number,
test_json_type_string, test_json_type_array, test_json_type_object) to assert
the exact returned JSON type string from json_type (e.g., "null", "bool",
"number", "string", "array", "object") instead of or in addition to asserting
its length — locate occurrences of string_length(json_type(...)) and replace/add
an assertion that the evaluated json_type(...) equals the exact expected string
for the corresponding JNull, JBool, JNumber, JString, JArray, and JObject cases.

In `@vera/browser/runtime.mjs`:
- Around line 1595-1601: The current imports.vera.json_stringify handler calls
JSON.stringify(readJson(ptr)) and passes the result directly to allocString, but
JSON.stringify can return undefined (which would break allocString). Fix
imports.vera.json_stringify by capturing the result of JSON.stringify(value),
checking typeof text === "string" and if not, coerce a safe string (e.g.,
String(value) or "undefined") before calling allocString; reference the
functions readJson, JSON.stringify, allocString and the handler
imports.vera.json_stringify to locate the change.

In `@vera/codegen/assembly.py`:
- Around line 118-120: The current code sets self._needs_alloc and
self._needs_memory when self._json_ops_used is true but the alloc export
decision doesn't consider self._json_ops_used; update the alloc export gating so
that the export of the allocator (the $alloc export decision in the export/build
logic) also checks self._json_ops_used in addition to existing conditions.
Locate the export/alloc gating code in vera/codegen/assembly.py (the logic that
decides whether to export $alloc) and add self._json_ops_used to its predicate
so modules that only use JSON host ops will export $alloc and host-side
marshalling can allocate into WASM memory.

In `@vera/codegen/monomorphize.py`:
- Around line 73-75: The json_parse builtin's return was recorded only as
"Result" causing monomorphiser to drop generic parameter info; update the
_BUILTIN_PARAMETERIZED_RETURNS mapping in monomorphize.py to include a
parameterised return entry for "json_parse" (e.g. the Result generic shape with
its type variables) so _get_arg_type_info can resolve Result<T, E> correctly
during monomorphisation; locate the _BUILTIN_PARAMETERIZED_RETURNS structure and
add a keyed entry for "json_parse" that describes its parameterised return form
consistent with other builtins.

In `@vera/prelude.py`:
- Around line 555-573: The code unconditionally injects JSON combinators when
any JSON name is referenced, which breaks if the user has a custom/shadowed data
Json type; add a standard-shape guard like the Option/Result pattern: implement
a helper (e.g. _has_standard_json(user_data_names, program) or similar) that
verifies the user has the canonical Json constructors (_json_ctors) and/or
standard Json shape, and change the combinator injection to only append
_JSON_COMBINATORS when not json_fn_names.issubset(user_names) AND
_has_standard_json(...) returns true (leave the existing logic that appends
_JSON_DATA when "Json" is absent unchanged).
- Around line 409-424: _source_mentions_json currently only examines ast.FnDecl
nodes and only looks for a limited set of names; update it to scan all top-level
declarations in the ast.Program (not just FnDecl) and use the existing
_node_mentions helper to detect Json usage in TypeAlias, Import/ImportFrom, and
other decl kinds, and extend json_names to include json_type and json_has_field
(and any other Json helpers) so imported/alias-based uses are detected and the
prelude is injected when needed.

In `@vera/wasm/calls.py`:
- Around line 4456-4462: Record the JSON host-import usage in
self._json_ops_used before emitting the call: when you build the instructions
that append "call $vera.json_parse", add self._json_ops_used.add("json_parse")
(or the exact key expected by vera/codegen/functions.py) immediately before
ins.append(...); do the same for the "call $vera.json_stringify" site (add
self._json_ops_used.add("json_stringify")). This ensures the translate_expr path
that sets self.needs_alloc and appends the call also registers the op in
self._json_ops_used so the import is propagated.

In `@vera/wasm/inference.py`:
- Around line 297-301: The Vera-type inference function _infer_fncall_vera_type
is missing cases for the JSON builtins json_parse and json_stringify, causing
_infer_vera_type to return None for those call expressions; update
_infer_fncall_vera_type to return the appropriate Vera types for json_parse
(e.g., a Vera Json/result pointer type matching the "i32" Wasm mapping used in
_infer_fncall_wasm_type) and json_stringify (e.g., a Vera string pair type
matching "i32_pair"), so JSON call expressions produce non-None types
consistently across _infer_fncall_wasm_type, _infer_fncall_vera_type, and
downstream codegen paths.

In `@vera/wasm/json_serde.py`:
- Around line 178-191: The code should fail fast instead of silently returning
{} or None: in the read_json path, when tag == _TAG_JOBJECT and
map_store.get(handle) returns missing, raise an exception (e.g., ValueError)
that includes the handle and ptr so the invalid layout is surfaced, and likewise
replace the final "return None" for unknown tags with an explicit exception that
includes the unexpected tag and ptr; update read_json (and callers if necessary)
to propagate these errors rather than converting them into empty dicts or nulls,
using the existing symbols _TAG_JOBJECT, read_i32, map_store and read_json to
locate the code to change.

---

Outside diff comments:
In `@TESTING.md`:
- Around line 206-212: The prose and the metrics table disagree: the table lists
"Tier 3 (runtime) | 7 contracts" and "Total | 146", while the paragraph mentions
"The 4 remaining Tier 3 contracts"; update the prose to match the table (change
the phrase "The 4 remaining Tier 3 contracts" to "The 7 remaining Tier 3
contracts") or, if the prose is correct, update the table values to reflect the
accurate counts; ensure the "Tier 3 (runtime)" count and the total (146) are
consistent across both the table and the subsequent paragraph.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@vera/browser/runtime.mjs`:
- Around line 1553-1580: In readJson, unknown tag values are currently swallowed
and return null; update the function (readJson) to emit a console.warn when an
unrecognized tag is encountered, including the tag value and ptr (and optionally
related readI32/readF64 outputs) for debugging parity with the Python
RuntimeWarning, then continue returning null so behavior is unchanged; place the
warning just before the final return null to cover unexpected tags while
preserving existing control flow.

In `@vera/codegen/monomorphize.py`:
- Around line 86-90: The mapping _BUILTIN_PARAMETERIZED_RETURNS is missing
entries for json_get, json_array_get, and json_keys, so inner generic types are
lost during monomorphisation; add entries to that dict to preserve inner type
parameters (for example: "json_get": ("Option", ("Json",)), "json_array_get":
("Option", ("Json",)), and "json_keys": ("Option", ("Array", "String"))),
updating the _BUILTIN_PARAMETERIZED_RETURNS dict so _get_arg_type_info can bind
inner generics correctly for these functions.

In `@vera/wasm/json_serde.py`:
- Line 27: Replace the deprecated typing.Callable import with
collections.abc.Callable: update the import line in json_serde.py to continue
importing Any from typing but import Callable from collections.abc so references
to Callable in this module (e.g., type hints used in functions/classes) use the
modern, Python 3.9+ compatible symbol.

---

Duplicate comments:
In `@tests/test_checker.py`:
- Around line 2014-2036: Add negative type-check tests for the three Json
built-ins to complement the existing happy-paths: in tests/test_checker.py add
one test each (mirroring test_json_array_get, test_json_array_length,
test_json_keys) that calls json_array_get, json_array_length, and json_keys with
a wrong argument type so the checker fails (e.g., pass an Int where a Json is
expected for json_array_get and json_array_length, and pass an Int instead of
Json for json_keys), using the project’s existing wrong-type assertion helper
(the same style as other built-in tests) so the type checker rejects these
calls.

In `@tests/test_codegen.py`:
- Around line 8751-8776: Replace the fragile string-length assertions in
test_json_stringify_null, test_json_stringify_bool, and
test_json_stringify_number with round-trip assertions: call json_stringify on
the literal (JNull, JBool(true), JNumber(42.0)), then parse that output back
with json_parse and assert equality to the original AST (e.g. assert
_run("json_parse(json_stringify(JNull))") == JNull). Keep references to the same
test functions (test_json_stringify_null, test_json_stringify_bool,
test_json_stringify_number) and builtins (json_stringify, json_parse, JNull,
JBool, JNumber, _run) so the tests verify semantic equivalence rather than
string length.

In `@vera/codegen/api.py`:
- Around line 1558-1566: Change JSON handling to match browser behavior by
rejecting non-finite numeric constants on parse and producing a compact,
deterministic serialization on stringify: in host_json_parse (which calls
_json.loads) pass a parse_constant that raises so any NaN/Infinity tokens are
rejected (or post-validate parsed numbers with math.isfinite and return an error
via _alloc_result_err_string), and in the corresponding stringify implementation
(the json_stringify path around lines ~1597) call _json.dumps with
allow_nan=False and separators=(',', ':') to avoid Python's spaced separators;
update both host_json_parse and the stringify function to return errors via the
existing _alloc_result_err_string/_alloc_result_ok_string helpers when invalid
values are encountered.

In `@vera/prelude.py`:
- Around line 397-410: The current _has_standard_json(program: ast.Program) only
checks constructor names; instead, validate the full Json shape like the
Option/Result guard by ensuring the DataDecl for "Json" has no type parameters
(decl.type_params empty) and each constructor has the exact arity and field
types expected: JNull with zero fields, JBool with one field of type Bool,
JNumber with one field of type Number, JString with one field of type String,
JArray with one field of type Array<Json>, and JObject with one field matching
the expected object representation (e.g. Array<(String, Json)> or whatever the
prelude uses); locate these checks via program.declarations -> decl
(ast.DataDecl) -> decl.name == "Json" and iterate decl.constructors (c.name,
c.fields) to compare arity and field AST types before returning True.

In `@vera/wasm/json_serde.py`:
- Around line 178-180: When handling tag == _TAG_JOBJECT in the deserializer,
don't silently fall back to {} on a missing map handle: after computing handle =
read_i32(caller, ptr + 4) and fetching raw_map = map_store.get(handle, {}),
detect the missing case (handle not in map_store) and emit a warning/diagnostic
(consistent with the unknown-tag warning behavior) that includes the handle
value and contextual info (e.g., ptr and tag) so memory corruption or stale
pointer issues are visible; keep the fallback to {} but log the warning before
returning.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@TESTING.md`:
- Around line 11-12: Update the stale example counts to reflect the current 29
verified example programs: change the count in TESTING.md (where it currently
says 27) and update the hardcoded value in scripts/build_site.py (the
constant/markup at the site-generation location that currently shows 25) to 29;
if build_site.py computes or exposes an examples count variable, replace the
literal with a dynamic computation from the examples/ directory or update the
constant to 29 so both documentation and site generation match the actual
examples/ count.

In `@tests/test_codegen.py`:
- Around line 8630-8633: The generated WAT can reference host imports for
json_parse/json_stringify even when those helpers were never registered, so
update the JSON host-import helper creation in vera/wasm/calls.py to record
usage by calling self._json_ops_used.add("json_parse") and
self._json_ops_used.add("json_stringify") at the point the helpers are created
(so their imports will be injected when used), and add explicit codegen
assertions in tests/test_codegen.py (e.g. in TestJsonCollection) that generate
WAT for cases that do and do not use json_parse/json_stringify and assert the
corresponding $vera.json_parse/$vera.json_stringify imports are present only
when used.
- Around line 8971-8988: The test test_json_parse_nested_object is asserting the
wrong property: after json_get(..., "inner") it checks json_has_field(...,
"inner") which doesn't validate the nested content; update the test to assert
the nested object contains the field "x" and that its value equals 1 (use
json_has_field and json_get on the returned `@Json` for "x" and compare the
extracted value to 1) so the test verifies the actual parsed nested value
produced by json_parse/json_get.

In `@vera/wasm/json_serde.py`:
- Around line 9-14: Update the module docstring so its example call signatures
match the actual function APIs: change the write_json and read_json signatures
shown in the top-of-file docstring to list the real parameters used by the
implementations (e.g., the same parameter names and order as the write_json
function and the read_json function in this file). Locate the docstring near the
top of vera/wasm/json_serde.py and replace the outdated example lines with
signatures that exactly match the implemented write_json(caller, alloc,
write_i32, write_f64, alloc_string, map_alloc, map_insert_ss, value) → ptr and
read_json(caller, read_i32, read_f64, read_string, map_store) → Any (or the
precise parameter names used in the current definitions) so callers and
maintainers see correct usage.

---

Duplicate comments:
In `@tests/test_codegen.py`:
- Around line 8751-8776: The tests (e.g., test_json_stringify_null,
test_json_stringify_bool, test_json_stringify_number) only assert string lengths
which can hide incorrect serialization; update each to assert the exact
serialized string returned by json_stringify for the given input (e.g., JNull ->
"null", JBool(true) -> "true", JNumber(42.0) -> "42.0") rather than just
string_length or non-empty checks, and apply the same exact-value assertions to
the other json_stringify tests flagged in the review to ensure meaningful
verification of serialization behavior.

In `@vera/wasm/json_serde.py`:
- Line 27: The import is using typing.Callable which is deprecated for modern
typing; update the import in json_serde.py so that Callable is imported from
collections.abc instead of typing (e.g., replace the current "from typing import
Any, Callable" with an import that brings Callable from collections.abc while
keeping Any from typing), ensuring references to Callable in the module remain
unchanged.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@vera/browser/runtime.mjs`:
- Around line 1568-1577: The code path handling tag === 5 silently returns an
empty object when a JObject handle lookup in mapStore (using handle =
readI32(ptr + 4)) is missing; update this branch to emit a warning (e.g.,
console.warn or the module logger) including the missing handle value and any
contextual info (ptr or tag) so memory/layout drift is visible, but keep the
current behavior of returning {} and still calling readJson for existing entries
(symbols to locate: the tag === 5 branch, readI32, mapStore.get(handle), and
readJson).

---

Duplicate comments:
In `@vera/wasm/json_serde.py`:
- Around line 8-14: Update the module docstring so its call signatures match the
actual function definitions: edit the write_json and read_json signatures in the
top docstring to exactly reflect the parameter names used by the implemented
functions (refer to write_json and read_json symbols), remove the stale
map_insert_ss parameter name if it is not present in the implementation and
replace it with the real map-insert parameter name, and add the missing ptr
argument to read_json so the read direction signature shows read_json(..., ptr)
→ Any.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@TESTING.md`:
- Line 76: Update the command snippet comment that still says "300 tests" to
match the table which lists test_conformance.py as 305 tests: locate the command
snippet in TESTING.md referencing test_conformance.py and change the numeric
comment from 300 to 305 (and update any other occurrences of the old count in
that snippet), ensuring the comment text now accurately reflects
test_conformance.py = 305 tests.

In `@tests/test_checker.py`:
- Around line 1990-2036: Add missing wrong-argument checker tests for the JSON
built-ins: update the test methods test_json_get, test_json_has_field, and
test_json_type to include a second `_check_err(..., "type")` case each that
passes an incorrect argument type to the builtin (e.g., pass an Int or String
where a Json is expected, or vice versa) to assert the type checker rejects the
call; reference the functions json_get, json_has_field, and json_type and use
`_check_err` with the "type" message to mirror the existing built-in test
pattern.

---

Duplicate comments:
In `@tests/test_codegen.py`:
- Around line 9005-9023: Update the test_json_parse_nested_object to validate
the nested value content not just existence: after json_parse and
json_get(`@Json.0`, "inner") return Some(`@Json`), call json_get(`@Json.0`, "x") and
assert the retrieved value is the numeric 1 (e.g., match the Some(`@Json`) and
check the contained number equals 1) instead of only using
json_has_field(`@Json.0`, "x"); this ensures the test checks actual value/type
correctness for the "x" field.
- Around line 8785-8811: The tests (e.g., test_json_stringify_null,
test_json_stringify_bool, test_json_stringify_number) currently only assert
string_length(json_stringify(...)) which can pass for incorrect output; change
them to assert the actual JSON output or its parsed structure by calling _run to
get the string from json_stringify(JNull/JBool/JNumber) and then either compare
the exact string (e.g., "null", "true", "42.0") or parse it with Python's
json.loads and assert the resulting value/type equals the expected
(None/True/42.0); update any similar tests mentioned (lines ~8935-8989,
9024-9038) to follow this stricter pattern and reference json_stringify, JNull,
JBool, JNumber, _run, and string_length when making the replacements.