Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@ROADMAP.md`:
- Line 11: The ROADMAP.md statement and the CI tooling table are inconsistent:
the top summary says "3,700 tests" while the CI tooling table still lists
"3,658". Update the downstream reference in the CI tooling table to match the
canonical test count or replace the hardcoded number with a dynamic/non-numeric
phrase (e.g., "tests (see CI)"); locate the CI tooling table entry referenced in
the file (the line shown around the table) and change the numeric value to the
canonical count produced by running pytest tests/ --collect-only -q or python
scripts/check_doc_counts.py, or swap the literal with a non-numeric reference to
avoid future drift.
- Line 25: The ROADMAP contains a stale backlog entry for issue `#490` in the
"Compiler internals" table that contradicts the paragraph (which states `#490` was
closed in v0.0.132); remove or update the table row referencing "#490" so it no
longer appears as open — either delete that row entirely or change its
status/notes to indicate it was closed in v0.0.132 (and optionally add a short
parenthetical "closed in v0.0.132" to match the paragraph). Ensure you update
only the table entry for "#490" in ROADMAP.md so the paragraph and table are
consistent.

In `@tests/test_codegen.py`:
- Around line 15573-15600: Update test_transient_map_handles_freed_after_gc to
assert that intermediate transient maps are actually freed: after executing the
program via _run (or the executor used), invoke the host GC sweep
(host_gc_sweep) or trigger gc_collect, then query the host-side map store size
(expose or call a helper like _map_store_size or inspect _map_store) and assert
it decreased to only contain the final live Map; keep the functional assertion
(result == 3) but add the explicit post-GC assertion that the internal map store
length/count equals the expected number (e.g., 1) so the test fails pre-fix.
Ensure you reference test_transient_map_handles_freed_after_gc, _run,
host_gc_sweep/_gc_collect and the map store accessor when making the changes.
- Around line 15476-15502: The test test_array_fold_with_decimal_accumulator
only calls _compile_ok and checks result.exports, so it never exercises the
runtime fold; change it to instantiate and invoke the compiled "main" export so
the runtime path runs and would trap on regression: after obtaining result from
_compile_ok (or its returned module/instance), instantiate or get the runtime
export for "main" (refer to how other runtime-executing tests invoke exports in
this test suite), call/invoke that export and assert it completes without
raising/trapping (e.g., no exception or specific success value), ensuring the
Decimal accumulator fold actually runs; update references to
result.exports/result.instance as needed to match the test harness.
- Around line 15424-15458: Replace the brittle sp_advance_count check (counting
"global.set $gc_sp") in the lookup_or_zero WAT test with a direct detection of
the shadow-push idiom that roots the first parameter ($p0): search fn_body for
the sequence that indicates a param shadow-push — "global.get $gc_sp" followed
shortly by "local.get 0" (or "local.get $p0") and then "i32.store" (and
optionally the matching "global.set $gc_sp") — and assert that this exact
sequence does NOT appear for $p0; keep the existing explanatory message but base
the assertion on that concrete pattern instead of counting global.set
occurrences.

In `@vera/browser/runtime.mjs`:
- Around line 2044-2045: The early return in imports.vera.host_gc_sweep (the
line "if (heapPtr <= heapStart) return;") prevents store pruning when the live
heap is empty; update the condition so pruning still runs when heapPtr ===
heapStart (e.g., change to "if (heapPtr < heapStart) return;" or remove the
return) so that candidates can be empty and transient host handles/stores are
still dropped; ensure the rest of the function still uses heapStart, heapPtr and
candidates as before so pruning logic executes.
- Around line 2065-2074: The current pruning loop for mapStore, setStore, and
decimalStore only keeps keys present in candidates, dropping nested handles
reachable only through those stores; modify the sweep to compute a reachable set
(starting from candidates) and expand it by traversing entries in mapStore,
setStore, and decimalStore to include any handles referenced as values/contents
(repeat until fixed point), then delete keys from mapStore, setStore, and
decimalStore that are not in this reachable set; ensure you reference the
existing variables mapStore, setStore, decimalStore and candidates and perform
the traversal before the deletion loop so nested live host handles are
preserved.

In `@vera/codegen/api.py`:
- Around line 1616-1622: The stores _map_store, _set_store, and _decimal_store
allocate handles starting at 1 which collides when the sweep routine prunes by
raw positive i32 membership; change allocation so handles are globally unique by
either (A) using a shared allocator used by all stores (move their counters into
a common generator) or (B) bit-encode the store kind into the handle value
(e.g., top bits or a tag) so the sweep's numeric membership test can distinguish
kinds before pruning; update any creation/lookup code that references
_map_store/_set_store/_decimal_store handles and the _handle_stores registration
so lookups still work with the new global allocator or encoded handles (also
apply the same fix at the other occurrences mentioned).

In `@vera/wasm/calls_arrays.py`:
- Around line 1065-1076: The current logic sets u_is_adt/t_is_adt to false for
host-handle types via _is_host_handle_type(), which clears
u_needs_root/t_needs_root and causes accumulators/elements in array_fold and
array_sort_by to live only in locals (unrooted) across call_indirect; to fix,
ensure host-handle values are shadow-stack rooted when they can survive a
call_indirect: either stop excluding host-handle types in the u_is_adt/t_is_adt
check (remove the "and not _is_host_handle_type(...)" condition) or explicitly
force u_needs_root/t_needs_root true for host-handle types before emitting the
local/accumulator stores in array_fold (array_fold accumulator at ~lines
1106–1108) and array_sort_by (element at ~2169–2170), so that the generated code
pushes/populates the shadow stack around call_indirect and host_gc_sweep can see
them.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@ROADMAP.md`:
- Line 37: Update the `#570` entry to accurately reflect current implementation:
note that _translate_array_map() roots arr_ptr, fn_tmp, and dst once before the
loop and does not push each produced element onto the GC shadow stack per
iteration, so reword the failure mode accordingly (remove the incorrect claim
that each iteration pushes a new ptr). Also delete or soften the blanket
assertion that siblings like array_flatten share the pattern (array_flatten has
no callback path); suggest the correct mitigation options (perform per-iteration
shadow-stack unwind in array_map codegen or avoid per-element roots by writing
directly into the already-rooted dst) and keep the issue link to `#570`.

In `@tests/test_codegen.py`:
- Around line 15512-15633: The test only asserts pruning of _map_store but `#346`
also affects _set_store and _decimal_store; update
TestHostGcSweep346.test_transient_map_handles_freed_after_gc to also assert
exec_result.host_store_sizes.get("set") and
exec_result.host_store_sizes.get("decimal") have the expected sizes (likely 0 or
the appropriate retained count for this scenario) alongside the existing map
assertion so regression in Set/Decimal sweeping is caught; locate the test by
the method name test_transient_map_handles_freed_after_gc and add the two
mirrored assertions immediately after the map assertion.
- Around line 15498-15505: The Decimal fold test using array_fold with
accumulator `@Decimal` doesn't force a GC while the accumulator is live; modify
the fold callback (the anonymous fn used in array_fold that calls decimal_add
and decimal_from_int) to create deliberate heap pressure so a collection is
unavoidable (for example, allocate and populate a large temporary array or
perform many small allocations inside the fold body, or invoke the runtime
gc_collect API if available) so the rooting behavior is exercised during the
fold; ensure the added allocations are confined to the callback and don't change
the final numeric logic checked by decimal_eq.

In `@vera/browser/runtime.mjs`:
- Around line 2055-2123: The sweep currently uses a single numeric Set
candidates which mixes independent per-store handle namespaces (mapStore,
setStore, decimalStore) and lets low numeric handles from one store keep entries
in other stores alive; fix by tracking candidates per store: create separate
Sets (e.g., mapCandidates, setCandidates, decimalCandidates), populate the
appropriate per-store set when scanning heap/stack/iterating mapStore/setStore
(use the same logic that recognizes whether a numeric handle refers to
map/set/decimal), update the transitive-closure loops to iterate and add into
the matching per-store candidate Set (use mapStore, setStore, decimalStore as
the sources), and finally prune each store by checking its own candidate Set
rather than the global candidates.
- Around line 2050-2124: The host_gc_sweep implementation can run re-entrantly
(e.g., via wasm.alloc) and must bail out if already sweeping; add a
module-scoped boolean guard (e.g., hostGcSweeping) and wrap the body of
imports.vera.host_gc_sweep with: if (hostGcSweeping) return; hostGcSweeping =
true; try { ... } finally { hostGcSweeping = false; } so the logic that scans
heap/stack and prunes mapStore, setStore, decimalStore only runs when not
already in progress; update references to imports.vera.host_gc_sweep, mapStore,
setStore, decimalStore accordingly.

In `@vera/codegen/assembly.py`:
- Around line 262-277: The import gate for host_gc_sweep only triggers when
self._map_ops_used/_set_ops_used/_decimal_ops_used are true, but
write_json()/write_html() populate self._map_store without setting those flags
so JSON/HTML-backed map entries are never GC-scanned; update the condition in
assembly generation (the block guarded by self._needs_alloc and the tuple of op
flags, and the similar block at the second occurrence around the other import)
to also check for the presence of map-backed data (e.g., if self._map_store is
non-empty) or set a new boolean flag (e.g., self._map_store_used) inside
write_json() and write_html() and include that flag in the conditional, ensuring
the host_gc_sweep import is emitted when map-backed entries exist.

In `@vera/wasm/helpers.py`:
- Around line 265-268: The usage comment for _is_host_handle_type is stale;
update its docstring to state that the classifier IS consulted by GC-rooting
code paths—specifically mention that vera/wasm/context.py::translate_block()
uses _is_host_handle_type to root let-bound host handles—so readers are not
redirected to the old files (vera/codegen/functions.py and
vera/wasm/calls_arrays.py) as the sole rooting references; keep the note that it
documents which types are host-handles but explicitly note its current runtime
usage in translate_block.

---

Duplicate comments:
In `@vera/codegen/api.py`:
- Around line 1682-1688: The code currently uses separate per-store integer
counters for _map_store, _set_store, and _decimal_store while host_gc_sweep
tracks live handles as plain ints, causing cross-store collisions that prevent
proper pruning; change all stores to allocate handles from a single shared
counter/namespace (e.g., _next_handle or a shared make_handle() function) so
every store inserts keys using that global handle and update any creation
functions that return handles (map/set/decimal constructors and places
referenced by symbols _map_store, _set_store, _decimal_store and host_gc_sweep)
to consume the shared generator; ensure any existing places that assumed
per-store counters are adjusted to use the unified handle allocation and that
host_gc_sweep continues to check membership against those global integer
handles.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@HISTORY.md`:
- Line 269: Update the v0.0.132 HISTORY.md row to reflect that the change
introduces a shared classifier `_is_host_handle_type` (which treats Map, Set,
Decimal as host-handle candidates) combined with a new host import
`host_gc_sweep` that prunes transient handles after each `$gc_collect`, rather
than saying Map/Set/Decimal are simply excluded from GC rooting; mention
classification + sweep behavior and that host handles remain on the shadow stack
for `host_gc_sweep` to discover before pruning.

In `@tests/test_codegen.py`:
- Around line 15411-15459: Extend the test to cover Set and Decimal handle
parameters the same way as Map: for each of the types `@Set<_>` and `@Decimal`
create equivalent `src` snippets (or parameterize the existing one) that declare
a function like `lookup_or_zero` taking that handle as param 0, compile with
`_compile_ok`, extract the function body using the same `fn_start`/`fn_end`
logic, and assert the same `push_pattern` (`global.get $gc_sp` + `local.get 0` +
`i32.store`) is present. Keep the current `push_pattern` and error message but
update or duplicate it to refer to Set and Decimal (or generalize the message)
and ensure the new assertions run within `test_map_param_is_shadow_pushed` or in
new tests named e.g. `test_set_param_is_shadow_pushed` and
`test_decimal_param_is_shadow_pushed`.
- Around line 15541-15590: The existing assertions in
test_host_gc_sweep_sweep_import_emitted_for_map_program and
test_no_host_gc_sweep_for_pure_adt_program only check for the string
"host_gc_sweep" in result.wat which can be misleading if other output formats
(JSON/HTML) are emitting it; update the tests to explicitly compile/request WAT
output (call _compile_ok with an explicit output format or assert the result is
WAT) before checking result.wat and ensure the negative test similarly confirms
no host_gc_sweep in WAT only—modify usages of _compile_ok and the checks around
result.wat in these two tests
(test_host_gc_sweep_sweep_import_emitted_for_map_program and
test_no_host_gc_sweep_for_pure_adt_program) so the gate is exercised against WAT
output only.

In `@vera/codegen/assembly.py`:
- Around line 627-633: Update the Phase 4 docstring to reflect the actual
arguments passed to the imported $host_gc_sweep call when uses_host_handles is
True: it pushes four globals—gc_heap_start, heap_ptr, gc_stack_base, and
gc_sp—so replace the current mention of "(gc_heap_start, heap_ptr)" with the
correct four-tuple or list of parameters and mention $host_gc_sweep and
uses_host_handles to make the behavior explicit.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@HISTORY.md`:
- Line 269: Update the v0.0.132 release row for "Opaque-handle GC-rooting
hygiene" to explicitly reference the deferred follow-up issue `#573`: replace or
augment the phrase "`#346` deferred — active reclamation needs a
heap-wrap-as-ADT design, tracked as follow-up" with wording that includes a link
to issue `#573` (e.g., "tracked as follow-up (see `#573`)") so the release note
for v0.0.132 clearly names the concrete deferred issue.

In `@vera/codegen/functions.py`:
- Around line 129-133: The i32 branch guarding GC-pointer rooting misses Json
because _is_host_handle_type() doesn't currently classify Json; update the
classifier so Json is considered a host-handle (i.e., add "Json" to the set of
types returned true by _is_host_handle_type or otherwise extend its logic) so
the condition in the if-block that checks wt == "i32" and type_name not in
("Bool","Byte", None) will correctly exclude Json; apply the same fix for the
identical pattern used around the wt/type_name check at the other occurrence
(the one referenced at 285-288) so Json is consistently treated as an opaque
host handle across both branches.

---

Outside diff comments:
In `@vera/wasm/calls_arrays.py`:
- Around line 2043-2050: The comment describing GC-rooting for sort-by is out of
sync: it claims Map/Set/Regex/Decimal are handled via the t_needs_root path and
that Regex is a value type, but the current predicate explicitly excludes host
handles and Regex is not a value type; update the prose around the t_needs_root,
tmp_a, tmp and comparator call_indirect discussion (and the similar block at
2150-2157) to accurately reflect that host handles are excluded from
t_needs_root, list the exact types that do require shadow-stack rooting (e.g.,
pair-typed T like String/Array<X> via tmp_a, and ADTs/user handles via tmp), and
remove/replace the incorrect references to Regex and host-handle flow so the
comment matches the implementation.

---

Duplicate comments:
In `@tests/test_codegen.py`:
- Around line 15409-15459: The test test_map_param_not_shadow_pushed is
asserting the wrong behavior: Map/Set/Decimal params must be shadow-pushed so
change the assertion to require the canonical shadow_push sequence is present;
in the test body (function lookup_or_zero) replace the negative check "assert
not push_pattern.search(fn_body)" with a positive check "assert
push_pattern.search(fn_body)" and update the failure message to state that the
Map param (param 0) must be shadow-rooted so host_gc_sweep can find live
host-store handles; keep references to push_pattern, lookup_or_zero and the
host-handle exclusion/_is_host_handle_type rationale.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@KNOWN_ISSUES.md`:
- Line 9: Update the KNOWN_ISSUES.md sentence that reads "v0.0.132 attempted a
`host_gc_sweep` design but the resulting six-piece interlocking machinery..." to
unambiguously state the timeline: say that an earlier draft of v0.0.132
attempted the `host_gc_sweep` design but it was reverted during development and
did not ship in v0.0.132, and then mention that the released v0.0.132 only
included the codegen fixes for `#347` and `#490`; keep the rest of the description
about the six-piece machinery and the recommended heap-wrap-as-ADT path
unchanged.

In `@tests/test_codegen.py`:
- Around line 15421-15434: The shadow-push detector currently only matches
"local.get 0" which misses forms like "local.get $p0" and also lacks a
non-vacuous check that GC prologue exists in the target function; update the
logic around result.wat/fn_body and push_pattern so the regex accepts both
numeric and named local.get forms (e.g., allow "local.get 0" or "local.get
$name"/any "$..." identifier) and after slicing fn_body confirm the prologue was
actually found (i.e., assert that the push_pattern search/match is non-empty)
before treating the push as detected; adjust the symbol references in tests to
use push_pattern, fn_body, fn_marker, and _compile_ok accordingly.

---

Duplicate comments:
In `@ROADMAP.md`:
- Line 11: Update the stale test-count in the CI tooling table to match the
canonical count used elsewhere (change “3,658 tests” to “3,700 tests” or replace
with a non-numeric phrase like “the test suite”) so ROADMAP.md is consistent;
locate the CI tooling table text that currently reads “3,658 tests” and edit it
to either the numeric 3,700 or a non-numeric reference, and add/update a short
comment or note (if present) to indicate the canonical source for the count is
produced by running `pytest tests/ --collect-only -q` or `python
scripts/check_doc_counts.py`.
- Line 25: The ROADMAP.md entry incorrectly lists issue `#490` as still open under
the "Compiler internals" backlog; open ROADMAP.md, find the "Compiler internals"
section and remove or update the backlog row that references `#490` (it was
closed in the v0.0.132 note), ensuring the backlog no longer lists `#490` as
open and that any related row/entry is adjusted for consistency with the
v0.0.132 closure mentioned in the v0.0.132 changelog paragraph.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@tests/test_codegen.py`:
- Around line 15560-15666: Add a mirrored test for array_map similar to
test_decimal_accumulator_not_rooted: the issue is missing coverage for the
array_map path (t_is_adt) so regressions there can slip by. Create a new test
(e.g. test_decimal_mapper_not_rooted) that compiles two sources—one mapping to
an Int accumulator and one mapping to a Decimal host-handle—and uses the same
global.set $gc_sp counting helper (count_main_pushes) to assert the Decimal case
emits the same number of global.set $gc_sp idioms as the Int case; also add a
functional run test mirroring test_array_fold_with_decimal_runs_correctly to
ensure array_map produces the correct Decimal results. Target symbols to
modify/add: test_decimal_accumulator_not_rooted (as model), count_main_pushes,
array_map, and ensure the classifier exercised is t_is_adt.

---

Duplicate comments:
In `@tests/test_codegen.py`:
- Around line 15578-15638: In test_decimal_accumulator_not_rooted replace the
brittle global.set $gc_sp counting logic (the count_main_pushes function and its
uses on int_wat/decimal_wat) with a direct check for the accumulator shadow-push
idiom inside the generated fold helper: locate the test function
test_decimal_accumulator_not_rooted, call _compile_ok(...) to get wat, find the
fold helper function emitted for array_fold (same helper referenced by the `#347`
param-0 tests), and assert the presence/absence (or equal counts) of the
concrete shadow-push instruction sequence used for the fold accumulator (the
same pattern you use in the `#347` tests) rather than counting "global.set $gc_sp"
in $main; update count_main_pushes to scan the fold helper body for that exact
shadow-push pattern and compare int_wat vs decimal_wat.