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

Inline comments:
In `@ROADMAP.md`:
- Line 60: Update the ROADMAP.md entry that groups Map and Set under "key
constraints" to clarify that Map requires key constraints (e.g., Eq + Hash for
keys) while Set requires element/member constraints; edit the bullet mentioning
"Map and Set collections — requires abilities for key constraints (`Eq + Hash`)"
to explicitly state "Map: key constraints (`Eq + Hash`) and Set: element/member
constraints (`Eq + Hash`)" so the documentation accurately distinguishes
constraints for Map vs Set.

In `@spec/09-standard-library.md`:
- Around line 248-261: Update the generic signatures for the Set operations to
include ability constraints so they match the prose: change every `forall<T>` in
the `set_new`, `set_add`, `set_contains`, `set_remove`, `set_size`, and
`set_to_array` declarations to `forall<T where Eq<T>, Hash<T>>`; likewise ensure
Map operation signatures use `forall<K, V where Eq<K>, Hash<K>>` for map APIs.
Locate the table rows referencing the symbols `set_new`, `set_add`,
`set_contains`, `set_remove`, `set_size`, and `set_to_array` and add the `where
Eq<T>, Hash<T>` constraint to their `forall` clauses (and update Map rows to use
`where Eq<K>, Hash<K>`).

In `@TESTING.md`:
- Line 73: The TESTING.md conformance test count is inconsistent: the table
entry for `test_conformance.py` lists 290 tests while the conformance run
snippet still says “parametrized — 280 tests”; verify the actual number of
parametrized tests in `test_conformance.py` and update all occurrences in
TESTING.md (the table row for `test_conformance.py` and the conformance run
snippet that mentions “parametrized — 280 tests”) so both show the correct,
matching count.
- Around line 53-55: The TESTING.md coverage table entries for `test_checker.py`
and `test_codegen.py` still only mention Map collection even though this PR
added Set tests; update those two summary lines to include "Set" alongside "Map"
(e.g., "Map, Set collection") and verify any other collection mentions in the
same file (such as the `test_verifier.py` row) reflect the new Set coverage so
the Markdown accurately matches the tests added.

In `@tests/test_checker.py`:
- Around line 1626-1697: Test suite is missing a negative test for wrong element
type in sets; add a new test method (e.g., test_set_add_wrong_element_type) in
class TestSetChecker that mirrors the existing good-case tests but calls set_add
with a mismatched element type so the type checker fails. Use _check_err
(similar to test_set_wrong_arity) and assert an error message containing "type";
reference set_new(), set_add(...) and the let binding using `@Set`<Int>.0 to
construct the failing call. Ensure the new test name and body follow the same
style as test_set_new_type_checks and test_set_wrong_arity so it runs with the
rest of tests.

In `@tests/test_codegen.py`:
- Around line 7858-7944: Add tests inside the TestSetCollection class that
verify immutability and empty/zero edge paths for the set builtins: ensure
set_add and set_remove return new handles without mutating the original handle
(e.g., capture an original `@Set` from set_new()/set_add, call set_add/set_remove
to get a new set, then assert original's set_size/set_contains unchanged), add
tests for removing a non-existent element and removing from an empty set
(set_remove on set_new() yields same size 0), test set_contains and set_to_array
on an empty set (contains false/0 and array_length 0), and include a test for
adding a zero-like element if relevant (e.g., adding 0 or empty string) to
ensure edge values are handled; reference the existing helpers/set builtins
set_new, set_add, set_remove, set_contains, set_size, set_to_array and add new
test methods (e.g., test_set_immutability, test_set_remove_from_empty,
test_set_contains_empty, test_set_to_array_empty) to follow the existing test
style.

In `@vera/browser/runtime.mjs`:
- Around line 1269-1271: Replace the undefined readStr calls with the existing
readString function in the wasm host wrappers (e.g. the imports.vera[name]
closure and any set_add/set_contains/set_remove string-specialised paths), and
fix the set_to_array$es -> allocArrayOfStrings usage so it passes a proper array
of JS strings (not the raw mem or four args). Concretely: change readStr(...) to
readString(...) wherever used; when converting a Set to an array
(set_to_array$es), build an array like mem.map(([ptr,len]) =>
readString(ptr,len)) and call allocArrayOfStrings(stringsArray) (matching
allocArrayOfStrings' single-argument signature) so the runtime returns the
populated string array.
- Around line 1277-1279: The code coerces WebAssembly i64 import values to
Number (ns.add(et === "i" ? Number(e) : e)), which loses precision for BigInt
values; update the import handlers used for set operations (the
imports.vera[name] functions that implement set_add, set_contains, set_remove
and set_to_array) to stop converting i64 cases to Number and instead use the raw
BigInt (i.e., remove Number(e) for et === "i" so you add/compare/remove e
directly when et is "i"), and apply the same change to the other three analogous
handlers referenced in the diff.

In `@vera/wasm/calls.py`:
- Around line 7638-7656: The helper _infer_set_elem_from_set_arg incorrectly
assumes any FnCall preserves a set by recursing into expr.args[0]; change it to
only recurse for set-preserving builtins (e.g., set_add, set_remove), and for
other FnCall cases attempt to use the callee/return-type info (the function's
return type) instead of the first-arg fallback; likewise handle ModuleCall by
checking the module call's return type before recursing into arguments (do not
recurse blindly), and return None (bail out) when no reliable return-type or set
element can be determined (examples to keep in mind:
set_to_array(build_strings(flag)) where build_strings' arg is not a set). Ensure
references to _infer_vera_type remain for explicit element extraction when
appropriate.
- Around line 7672-7679: When building the set import signature in the
translators (e.g. the block using elem_type =
self._infer_vera_type(call.args[1]) and et = self._map_wasm_tag(elem_type)
before calling _register_set_import), add a guard so unknown element types do
not default to the "b" ABI: if elem_type is None, try to derive the element type
from the set operand (call.args[0]) by inspecting its Set<T> generic; if that
yields a concrete type use it, otherwise treat the element type as unknown and
return None (do not call _map_wasm_tag/_map_wasm_types or register the import).
Apply the same guard to the other two translator sites that construct set
imports (the blocks around set_add/set_contains at the other two locations).

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

Inline comments:
In `@tests/test_codegen.py`:
- Around line 7919-7926: Add tests that exercise the typed Set<String> -> array
codepath by creating a typed empty set and a typed set with string elements and
asserting set_to_array returns the expected lengths/contents; mirror the style
of test_set_to_array_length by adding new test functions (e.g.,
test_set_to_array_length_strings and test_set_to_array_empty_typed_strings) that
call _run on sources using set_new(), set_add(..., "str"), and set_to_array and
assert the results (length and/or element values) to cover the string ABI route
for set_to_array.

---

Duplicate comments:
In `@vera/browser/runtime.mjs`:
- Around line 1277-1281: The Set insertion callback (imports.vera[name])
currently coerces i64 elements with Number(e) which loses precision; update it
to store the element value directly (leave e as a BigInt when et === "i") by
adding e (or Number(e) only for non-i types) into the Set created from
setStore.get and then call setAlloc; make the same change in set_contains and
set_remove so they compare/remove BigInt values without Number coercion;
finally, update set_to_array to return elements as BigInt (don't convert stored
BigInt back to Number) so consumers expecting i64 receive the original BigInt
values. Ensure you reference setStore, setAlloc, imports.vera[name],
set_contains, set_remove, and set_to_array when applying the fixes.

In `@vera/wasm/calls.py`:
- Around line 7638-7658: _infer_set_elem_from_set_arg currently only handles
SlotRef and a few FnCall names, so calls like ast.ModuleCall or general helper
FnCalls (e.g., set_to_array(build_strings(flag))) return None and cause wrong
ABI selection in _translate_set_to_array; update _infer_set_elem_from_set_arg to
also detect ModuleCall and general FnCall return types by (1) handling
isinstance(expr, ast.ModuleCall) by inspecting expr.target/expr.name or its
flattened inner call to see if it yields a Set<T> and then extracting T, and (2)
for general ast.FnCall, if the call's own inferred type (use
self._infer_vera_type(expr) or expr.type_name/type_args) indicates a Set<...>,
extract and return the element type; still fall back to recursing into the first
arg when the function is a set-constructor helper. Ensure these checks reference
_infer_set_elem_from_set_arg, _infer_vera_type, ast.ModuleCall, ast.FnCall and
that _translate_set_to_array will then get the correct element layout.

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

Duplicate comments:
In `@tests/test_codegen.py`:
- Around line 7974-8005: Add two codegen/runtime tests to tests/test_codegen.py:
one that verifies removing an element from an already-empty set leaves size 0
(e.g., add a test similar to test_set_empty_to_array but calling
set_remove(set_new(), 5) and asserting result 0 by calling set_size), and
another that verifies zero-value handling by inserting 0 into a set then
asserting set_contains returns true and set_size is 1 (or checking set_remove of
0 changes size appropriately). Place tests near the existing set tests (see
test_set_remove_absent_element, test_set_empty_contains,
test_set_empty_to_array) and follow existing test structure and _run usage so
they exercise host-import edges for empty inputs and numeric zero values.

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

Inline comments:
In `@README.md`:
- Line 599: The README's hard-coded test count ("2,824 tests") is inconsistent
with the PR status (2,811); update the README.md line containing the sentence
that begins "Testing is organized in three layers: **unit tests**..." to either
reflect the current accurate test count or remove the exact numeric literal and
replace it with a non-hardcoded phrasing (e.g., "≈2,800 unit tests" or
"thousands of unit tests") to avoid churn; ensure the linked TESTING.md
reference and any other counts in README.md are checked for consistency after
the change.

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

Duplicate comments:
In `@README.md`:
- Line 599: Update the unit test count in README.md (the sentence containing
"unit tests (2,826 tests across 26 files...)" to reflect the current PR's local
run or remove the hard-coded exact count to avoid churn; specifically change the
"2,826" figure to "2,811" to match this PR or rephrase to a non-exact statement
like "≈2,800 unit tests across 26 files" in that same sentence so the
documentation stays accurate and resilient to future test count changes.