…invalid WASM)

Indexing a *captured* `Array<T>` inside a closure body — `coll[i]`
where `coll` is a SlotRef to an outer-scope binding — produced
invalid WASM. Element type didn't matter: Array<Int>, Array<Bool>,
Array<Array<Bool>> all reproduced. Two failure modes by depth:

  - Flat case: WASM module fails *validation* with "unknown table 0:
    table index out of bounds" (binary structurally invalid).
  - Nested case (two levels): module passes validation but traps at
    runtime with "undefined element: out of bounds table access" or
    "indirect call type mismatch".

Root cause: `_walk_free_vars` in `vera/wasm/closures.py` had no
`IndexExpr` branch. When the walker hit `coll[idx]` inside a closure
body, the `coll` SlotRef referencing a captured outer slot was never
recognised as a free variable. The closure-lift's `captures` list
came back empty, body translation failed (the SlotRef couldn't be
resolved against an empty capture-only env), and
`_compile_lifted_closure` returned None — but the call site at
`_translate_apply_fn` had already emitted a `call_indirect` to the
now-absent function-table entry.

Fix adds the missing `IndexExpr` branch plus seven other AST node
types that were silently falling through with the same bug class:

  - `ArrayLit` (elements may contain captured slots)
  - `InterpolatedString` (Expr parts may reference captures)
  - `HandleExpr` (with proper handler-clause param scoping and
    handler-state @t scoping)
  - `AssertExpr` / `AssumeExpr` (their inner predicate)
  - `ForallExpr` / `ExistsExpr` (domain expr + predicate AnonFn)
  - `ModuleCall` (cross-module call args)

Each silently dropped capture references inside its sub-expressions
the same way IndexExpr did. The fix is mechanical for all eight
branches: walk the sub-expressions with appropriate scope-tracking.

Conformance test ch05_capture_array_index.vera covers the three
documented positions: flat (the minimal IndexExpr-in-walker
reproducer), nested (two-level array indexing through captured
outer), combined (closure body uses captured array as both
IndexExpr and FnCall arg).

Conformance count: 85 -> 86. Total tests 3,740 -> 3,745.

Note: the issue body acknowledged that scaling to a full Conway's
Game of Life implementation may have additional triggers beyond
captured-array indexing. Both documented BUG_REPORT.md reproducers
(repro_min.vera, repro_nested.vera) pass post-fix. The remaining
full-Life corruption (string-output corruption from generation 1+
at 12x30 scale with recursive run_loop) is a separate not-yet-
isolated bug class tracked as #593, masked from the user as a
Python traceback by the v0.0.136 errors="replace" defensive layer
(surfaces as U+FFFD chars in output rather than crashing).

Doc updates:
  - CHANGELOG entry under [0.0.137] Fixed
  - HISTORY.md Stage 11 row for v0.0.137
  - KNOWN_ISSUES.md: drop #588 row (closed); add #593 row (residual)
  - All count surfaces (TESTING.md, ROADMAP.md, etc.) bumped
  - Version files + uv.lock bumped 0.0.136 -> 0.0.137

Co-Authored-By: Claude <noreply@anthropic.invalid>

…ass)

Discovered when the user Ctrl-C'd a Conway's Life animation that uses
IO.sleep(120) between frames: KeyboardInterrupt arrived inside
time.sleep, propagated up through wasmtime's trampoline as a "python
exception" cause, and the user saw a multi-line Python traceback
ending in KeyboardInterrupt — same WasmTrapError contract violation
class as #589's UnicodeDecodeError escape (#516 / #522 / #547 —
runtime traps must surface as Vera-native errors).

Fix: host_sleep catches KeyboardInterrupt and raises _VeraExit(130)
(conventional SIGINT exit code, 128 + signal-2). The _VeraExit chain
unwrap at top of execute() recognises it and returns ExecuteResult
with exit_code=130 plus any captured stdout/stderr — clean process
exit, no Python traceback.

Filed as #595: a follow-on macOS malloc abort can still fire during
wasmtime/ctypes cleanup after the clean exit. That's a separate
wasmtime-interaction bug, not data-integrity, and fixing it is
outside our control unless we can identify what state the program
was in at the Ctrl-C moment. Possibly shares a root cause with #593
(Life corruption from generation 1+) since both surface together.

Bundling this into PR #594 because:
  - Same release target (v0.0.137 host-runtime hygiene)
  - Same class as #589's defensive WasmTrapError-contract work
  - Tiny scope (5-line guard + 1 test class)
  - Discovered while testing #594's #588 fix

Tests added (TestHostSleepKeyboardInterrupt in test_runtime_traps.py):
  - Structural assertion: host_sleep wraps time.sleep in try/except
    KeyboardInterrupt with _VeraExit(130) raise
  - Behavioural test: synthetic KeyboardInterrupt → _VeraExit(130)
    conversion verified end-to-end with unittest.mock.patch

KNOWN_ISSUES.md: adds #595 row for the residual macOS malloc abort.
CHANGELOG entry expanded under [0.0.137] with both fixes.
Test counts: 3,745 → 3,747 (+2 tests in test_runtime_traps.py).

Co-Authored-By: Claude <noreply@anthropic.invalid>

Two findings, both partially valid:

1. HISTORY.md line 3 (header) said "54 active development days" while
   line 314 (footer) said "55". v0.0.137 lands on 7 May, which is
   55 days from the 22 Feb start — header now reads 55, matching
   the footer.

2. TESTING.md had stale "85 conformance" mentions on lines 352 and
   394 (script-validation tables describing check_conformance.py).
   Updated both to "86 conformance" matching the post-#588 count.

Skipped from the rabbit's flagged candidates:
   - Line 187 "425 tests" — actually correct (check_doc_counts
     verified 86 conformance, 425 test_conformance.py runs; not
     every conformance program runs at all 5 stages so 86 != 425/5).
   - Lines 234, 445 "85%" — those are wasm/inference.py coverage
     percentages, not conformance counts. Different number,
     valid as-is.

check_doc_counts.py confirms consistent at 3747 tests, 86 conformance,
33 examples post-fix.

Co-Authored-By: Claude <noreply@anthropic.invalid>

…nt-integration

Reframed "What's next" to acknowledge the stabilisation work uncovered
by the v0.0.119–v0.0.137 bug-killing campaign. Two patterns worth
closing out before declaring runtime-correctness floor raised:

1. Scale-dependent bugs slip past the standard test suite (#515,
   #570, #487, now #593 — all required real-world programs at scale
   to surface; none would have been caught by the existing 3,747
   small focused tests).

2. Walker-completeness gaps are silent failures of the same shape
   (#588 found _walk_free_vars missing 8 AST branches; we don't yet
   know if other walkers in the codebase have similar incompleteness).

The "Implementation order" table is now split into two tiers:

  - Stabilisation tier (priority): #593, #596, #597, #595
  - Agent-integration tier (resumes after): #222, #523, #370

#596 (stress-test harness) and #597 (walker-completeness audit) are
new issues filed in this PR — they convert "I think we're stabilising"
into evidence by building the infrastructure that prevents recurrence
of the bug classes #588 and #593 surfaced.

#593 retains the lead position because it's the largest open codegen
unknown — bisection narrows it to 12x30 + recursive run_loop with
allocating call argument, but the root cause hasn't been isolated.
Until then, "WASM codegen is stable at scale" is unverified.

#595 sits last in the stabilisation tier because it likely shares a
root cause with #593 (both surface together at the same scale); fixing
#593 may close it. The v0.0.137 KeyboardInterrupt guard already
prevents the Python-traceback half.

Order #5 (LSP) doesn't start until orders #1-#4 close (or are
explicitly deferred with an open follow-up). Tier separator is
explicit so future readers don't have to reverse-engineer the
ordering rationale.

Co-Authored-By: Claude <noreply@anthropic.invalid>

…ep test

Both findings valid; fixed both.

1. TESTING.md row 82 was missing the new TestHostSleepKeyboardInterrupt
   suite from its coverage prose, even though the test count and line
   count were already bumped. Appended a clause matching the existing
   per-suite style: names the suite, links #595 (the related residual
   issue this guards the in-our-control half of), summarises both
   tests in the class.

2. test_host_sleep_keyboard_interrupt_propagates_as_vera_exit was a
   "test-the-test" — it defined a LOCAL host_sleep_under_test mirror
   of the production code, patched time.sleep, and asserted the
   conversion. If the production code regressed (KeyboardInterrupt
   guard removed), this test still passed because it was checking
   the LOCAL copy.

   Replaced with test_host_sleep_keyboard_interrupt_end_to_end that:
     - Compiles a real Vera program calling IO.sleep(120)
     - Monkey-patches time.sleep to raise KeyboardInterrupt
     - Runs via execute() (the real production entrypoint)
     - Asserts ExecuteResult.exit_code == 130
     - Asserts pre-sleep IO.print preserved (#522 contract)
     - Asserts post-sleep IO.print did NOT run

   Negative-test verified: temporarily reverting the production
   guard makes this test fail (wasmtime crashes when KeyboardInterrupt
   escapes the trampoline). Restoring the guard makes it pass again.
   So the test now genuinely pins the production path.

   Same "test-the-test" gap rabbit caught on PR #590's #589 e2e
   test. Fixing this one symmetrically — for #589 the gap was less
   tractable (would have required exporting wasmtime linker setup);
   here it was just a 30-line rewrite using execute() directly.

test_runtime_traps.py grows from 2,100 to 2,138 lines (the e2e is
slightly longer than the local-helper form). Test count unchanged
(still 62: structural + e2e is the same shape as before).

Co-Authored-By: Claude <noreply@anthropic.invalid>