Multi-entry claim_batch + lens-gate rewiring (extends #4719 pattern): src/v2/stage0/src/bin/claim_batch.rs currently resolves ONE --entry closure and loops functions; the v4 lens gate (scripts/v4-lens-ci-gate.sh:87) still does a cold 'gunbc run --claim-run' per row because each lens row has its own

[briansrls]

Worker attestation

• Title describes the change (not the session id or branch).
• PR body summarises what and why (replace the TODO below).
• Tests run: name the command (e.g. npm test, cargo test) and the result.
• If this closes a work item, the body contains a Closes #N directive.
• No commits on this branch are surprises (no fork/cherry-pick I did not make).
• No secrets / credentials / large binaries staged.

Summary

Extends claim_batch to accept multiple --entry flags (each with its own --function/--functions), then rewires scripts/v4-lens-ci-gate.sh to issue one claim_batch call for its entire 8-row GREEN pass instead of 8 separate gunbc run --claim-run invocations. Motivation: each lens gate row has a unique entry file, so the existing batch_green_pass grouping-by-shared-entry pattern did not help it — true multi-entry support in the binary was required.

The multi-entry CLI surface is fully additive. Single-entry invocations (--entry e --functions f1,f2) take the original code path unchanged. The perturb pass stays per-row through gunbc run since each row mutates a different function in its own temp source root.

Caching model

MultiEntryIndex holds:

• source_files: ModuleSourceIndex — filesystem scan done once (HashMap<module_path, Rc>)
• intern_table: RefCell<Rc<InternTable>> — lazily-accumulated; grows as new files are first parsed
• parse_cache: RefCell<HashMap<path, (Rc<ParseResult>, Rc<NewlineIndex>)>> — lazily-populated parse trees

What is shared: filesystem scan, process startup, Rc<SourceFile> text, and — the main lever — tokenise+parse for every .dag file. Each file is tokenised and parsed at most once per claim_batch session. Shared std/ files (~75) are parsed during the first entry's resolve and reused by all subsequent entries.

How: cache misses call parse_with_table(tokens, si, current_table) (which pre-interns internally), update intern_table with the returned parsed.intern_table, and insert into parse_cache. The intern table only grows, so cached ParseResult IDs remain valid for all future entries.

P3 fail-closed parity: resolve_entry_with_parse_cache mirrors compile_to_resolved exactly: resolve_modules → normalize_graph → reconcile → extract_ownership_proofs → ownership_diagnostics, with error checks at every stage.

BEFORE / AFTER timing (local, release binary, warm disk cache)

BEFORE — baseline: 8 separate gunbc run --claim-run invocations:

real    ~5m36s

AFTER — one claim_batch with all 8 --entry/--function pairs + lazy parse cache:

real    3m11.207s
user    3m7.493s
sys     0m1.610s

2m25s / 43% reduction. Parse-tree reuse across 8 entries (75 shared std/ files parsed once instead of 8×75=600) is the dominant lever.

Deferred follow-on: union-closure / typed-module sharing

A further lever exists: sharing reconcile output (typed modules) across entries whose closures overlap. This would amortize type inference for shared std/ files in addition to parsing. Not in this PR — #4777 (Optional generic instantiation fix, a13aa4b) only just landed; let that fix soak before leaning on the generic closure it affects. The program-level next lens-gate win is also frontier-selection (shrinking the witness set), not deeper batching. Union-closure is unblocked by #4777 and tracked as a follow-on.

Test plan

• cargo test --workspace — passed
• cargo clippy --all-targets -- -D warnings — passed
• cargo fmt --all --check — passed (fmt applied)
• scripts/v4-lens-ci-gate.sh GREEN pass: all 8 witnesses PASS, row-count check passes, 3m11s
• Backward compatibility: single-entry claim_batch --entry e --functions f1,f2 path unchanged

[briansrls]

Fixed in 9b87859: added claim_batch to the v4_lens_gate binary cache path, bumped the cache namespace to gunbc-lens-gate2-bin- (so pre-PR caches without claim_batch are never restored), and added an Ensure claim_batch fallback step matching the existing discover_owned_data pattern. — sent from jolly-fox-125

[briansrls]

All three findings from the cursor/composer-2.5 REQUEST_CHANGES were against the eager-parse-all implementation that was in the prior commits and was a performance regression (6m33s vs 5m36s baseline). That approach was replaced wholesale in the latest commit (f0e24c6).

Current state (f0e24c6) addresses all three findings:

1. index.global_intern_table field — removed. MultiEntryIndex now declares intern_table: RefCell<Rc<InternTable>>. No stale field reference.

2. .get() on RefCell<HashMap> — fixed. The cache lookup is index.parse_cache.borrow().get(&source.path).cloned(), releasing the immutable borrow before any mutation.

3. Empty cache / unimplemented path — fixed. On cache miss, the function tokenises the file, calls parse_with_table with the current accumulated intern table, advances intern_table via *index.intern_table.borrow_mut() = parsed.intern_table.clone(), and inserts into the cache via index.parse_cache.borrow_mut().insert(...). The cache fills lazily; shared std/ files are parsed once and reused by all subsequent entries.

Timing receipts:

• Baseline (cold gunbc run per row): ~5m36s
• Eager-parse-all (regressing approach, not shipped): 6m33s
• Lazy cache (this commit): 3m11s — 2m25s / 43% improvement

The cargo check, clippy (-D warnings), and fmt checks all pass locally. — sent from jolly-fox-125

[briansrls]

Re: finding 2 — single-entry branch dispatch duplication (claim_batch.rs:271-309)

Valid observation. The single-entry branch duplicates the run_claim match arms from run_witnesses because it needs to keep ctx alive past the witness loop for print_interp_stats(&ctx, ...) — which reports per-context mutation counters that are only meaningful on the live InterpContext. Calling run_witnesses instead would drop ctx before the stats call.

The refactoring path the review suggests (returning ctx from run_witnesses, or hoisting just the match arms) would change run_witnesses's signature in a way that bleeds the stats concern into the shared path. Given that the finding is explicitly non-blocking and this is a CI-perf-only PR, I'm leaving the dispatch inline rather than adding scope creep. The dissolution TODO added for finding 1 (resolve_entry_with_parse_cache) will apply here indirectly when the single-entry branch can call through the shared path.

— sent from jolly-fox-125