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

Inline comments:
In `@FAQ.md`:
- Line 206: The prose in FAQ.md is inconsistent: the conformance suite count was
changed to "81-program conformance suite" but an adjacent example bullet still
says "30"; update the example bullet so counts match the release (use "81"
instead of "30") or run/consult scripts/check_doc_counts.py to derive the
canonical example counts and replace the outdated "30" with the authoritative
number from that script to keep FAQ.md consistent with the release docs.

In `@HISTORY.md`:
- Line 258: Condense the Stage 11 HISTORY.md row into one or two sentences: keep
the core accomplishments (nested closures and ADT capture now work end-to-end,
closure-lifting and by-reference sig/ID sharing to avoid name collisions) and
mention the key fix (_walk_free_vars now recurses into AnonFn) plus removal of
the CVE-2026-3219 ignore, but remove detailed examples and multi-clause
explanations so the entry matches the concise style used elsewhere.

In `@README.md`:
- Line 184: Update the inconsistent example count in the README by running the
canonical check script scripts/check_doc_counts.py to determine the correct
number of examples, then make the prose consistent (replace the "33 examples" or
the "32" example occurrence so both match the script's reported value); ensure
both occurrences of the example count in the README (the sentence containing
"Vera is in **active development** at v0.0.121 — ... 33 examples" and the
project structure line that currently says "32") are changed to the single
canonical value and re-run scripts/check_doc_counts.py to verify no other doc
counts need adjustment.

In `@ROADMAP.md`:
- Line 272: Update the aggregate summary string that currently reads "120 tagged
releases (as of v0.0.120)" to reflect the new release by bumping it to "121
tagged releases (as of v0.0.121)"; locate the text in ROADMAP.md containing the
phrase "120 tagged releases (as of v0.0.120)" and change both the numeric count
and the referenced release tag to "121" and "v0.0.121" respectively so the
summary matches the newly added release row.
- Line 25: The summary sentence claiming "ten remain in the campaign" is
inconsistent with the listed issue IDs (`#515`, `#516`, `#517`, `#520`, `#475`,
`#535`, `#487`, `#348`, `#346`, `#347`, `#490`) which total eleven; update the
sentence in the paragraph that mentions v0.0.120/v0.0.121 and the remaining bugs
to reflect the correct count (change "ten" to "eleven") or remove/adjust the
count so it matches the listed issue IDs exactly, ensuring the phrase "ten
remain in the campaign" or its surrounding clause is corrected wherever it
appears.

In `@tests/test_codegen_closures.py`:
- Around line 625-630: Replace the fragile exact-name assertions that look for
"(func $anon_0" and "(func $anon_1" with a count-based check that the WAT
contains at least two lifted anon closures; for example, search the generated
WAT string for the substring "$anon_" (or a regex r"\$anon_\d+") and assert the
number of matches is >= 2 while keeping the existing table-size check below;
update the assertions in tests/test_codegen_closures.py (the block currently
asserting "(func $anon_0" and "(func $anon_1") to use this occurrence-count
approach so ordering/ordinal changes won't break the test.

In `@tests/test_verifier.py`:
- Around line 1609-1611: The explanatory narrative above the assertions for t1,
t3, and total is out of date; locate the explanatory comment or docstring that
describes the historical counts (near the assertions that check t1, t3, and
total) and update the numbers and wording to match the new expected totals 219
(T1), 26 (T3), and 245 (total) so the test message and narrative align with the
assertions.

In `@vera/codegen/closures.py`:
- Around line 43-44: The loop uses an ordinary list and worklist.pop(0) which is
O(n) per removal; replace worklist with a collections.deque and use popleft()
for O(1) removals: import collections (or from collections import deque),
initialize worklist = deque(...) where it is created, and change worklist.pop(0)
to worklist.popleft() in the while loop that destructures anon_fn, captures,
closure_id.

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

Inline comments:
In `@FAQ.md`:
- Around line 206-207: Update the stale bullet that reads "153 built-in
functions" to match the release docs by changing the text to "164 built-in
functions"; locate the list items in FAQ.md where the adjacent bullets mention
built-in functions (the line currently showing "153 built-in functions") and
replace that number so the status snapshot matches the other release
documentation.

In `@HISTORY.md`:
- Line 258: The release footer still reads "120 tagged releases" but you added a
new entry "v0.0.121"; update the footer count to "121 tagged releases" so the
tagged-release total matches the new v0.0.121 entry (look for the footer text
containing "tagged releases" in HISTORY.md and increment the numeric value).

In `@README.md`:
- Line 184: Update the stale test total in the README headline: replace the
"3,548 tests" figure in the string that begins "Vera is in **active
development** at v0.0.121 — 810+ commits, 121 releases, 3,548 tests, ..." with
the correct pytest collected total (3,567) to match the release totals (3,553
passed / 14 skipped). Regenerate or verify the number against the canonical
source scripts/check_doc_counts.py or TESTING.md before committing so the README
and release metrics remain consistent.

In `@tests/test_codegen_closures.py`:
- Around line 547-572: The test test_nested_closure_with_outer_param_capture
currently only asserts array_length(`@Array`<Array<Int>>.0) == 3 which doesn't
verify that the inner closure captures `@Int.1`; change the test body so the
nested array contents are reduced to a capture-dependent scalar (for example,
flatten or sum the inner arrays produced by array_map over array_range) and
assert the numeric total (e.g. 18) instead of length; update the invocation that
checks the result via _run("test")/assert to expect the scalar sum so that the
inner closure's use of `@Int.1` (and functions array_map, array_range, nat_to_int,
array_length) is actually exercised and validated.

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

Inline comments:
In `@TESTING.md`:
- Line 76: Update the inconsistent test count in TESTING.md so the "Running the
conformance suite" example matches the actual parametrized test total for
test_conformance.py: either change the text "(parametrized — 400 tests)" to
"(parametrized — 405 tests)" or remove the hard-coded numeric count entirely and
use a generic phrase (e.g., "(parametrized — X tests)" or "parametrized tests")
to avoid future drift; edit the "Running the conformance suite" example and any
other occurrences referencing test_conformance.py to keep them consistent.
- Around line 11-12: Update the mismatched conformance count so the "Conformance
Suite" intro text that currently reads "a collection of 80" is changed to "a
collection of 81" to match the table entry (**Conformance programs** | 81
programs...) and ensure any other occurrences of "80" referring to the
conformance suite in TESTING.md are updated for consistency.

In `@tests/test_codegen_closures.py`:
- Around line 520-545: The test test_nested_closure_inner_returns_array only
asserts the outer length and can miss malformed inner Array<Int> payloads;
update the test body (the src string used by _run) so the nested array_map
produces a scalar derived from inner elements (e.g., sum or a specific
transformed element) and assert that _run("test") returns that expected scalar
value, thereby validating the inner Array<Int> payload produced by the inner
closure (look for the array_map calls and the nat_to_int(array_length(...))
return expression and replace it with a scalar computation based on inner
values).

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

Inline comments:
In `@tests/test_codegen_closures.py`:
- Around line 610-679: Add a new unit test that builds two separate outer
closures each defining inner closures (similar structure to
test_nested_closure_emits_anon_for_inner) to exercise shared `_next_closure_id`
allocation; use _compile_ok(src) to get result.wat, use re.findall(r"\(func
\$anon_\d+") to collect anon function names and assert len(anon_funcs) >= 4 and
len(set(anon_funcs)) == len(anon_funcs) to ensure uniqueness, then
re.search(r"\(table\s+(\d+)\s+funcref\)", wat) to extract table_size and assert
table_size >= 4 so all lifted closures are placed in the table and invokable.