fix(scan): portion the evidence pass so a single kill is never the whole pass

The evidence pass bypasses the sink-weighted portioning by design: it is the pass that PRODUCES the
weights, and per request it is cheap, 17,700 answered in 44 s. It was still one all-or-nothing batch
protected only by the ceiling. On a plugin push transaction that batch is 22,125 requests, and under
the CPU and memory contention of concurrent test runs it exceeded the ceiling and cost the whole case.

It now runs in portions of 4,000 requests, roughly ten seconds of work behind one JVM start, with
answers merged and the census kept from the first portion that carried it. Streaming keeps what a
killed portion finished; portioning keeps that kill from being the entire pass.

Task 13.3 records the attempt that exposed this honestly: the case deadline was exhausted with no
artifact, and the failure was mine twice over -- the container mounts src live and the backend was
edited mid-run, and the evidence pass was unportioned. Neither is the algorithm. The rerun uses a
frozen export of the committed source with per-invocation logging.

1,423 tests pass, nineteen skipped; mypy clean.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01EmM1j46qgKMh3zqD1QMwEo
This commit is contained in:
Marius Ciepluch
2026-09-22 21:44:45 +02:00
co-authored by Claude Fable 5.1
parent a8b226a5c8
commit a4042fdb27
2 changed files with 34 additions and 2 deletions
+2 -1
View File
@@ -566,8 +566,9 @@ Preserve all completed task evidence below.
- _Attempted 2026-09-21, and the attempt named its own blocker._ At 25 regions the first case now runs to completion and writes a full artifact, in 1,706 s, where at 100 it had exhausted a 2,400 s deadline with nothing. But 25 regions of 4,461 is 0.6% of the population, and the declared target at `classes/class.memberorder.php:936` was not among them: zero findings at the target, because the question was never asked. A bounded population establishes transfer only if it CONTAINS the target, and this one cannot.
- **So this task depends on contributor-scan 7.3, not on a larger budget.** The population that holds the target is affordable only if arbitration stops being paid for questions whose evidence says there is nothing to find. Raising the budget is the thing already measured to fail; making most of the budget unnecessary is the thing that has not been tried.
- _Two further observations from that run, recorded because they cost nothing to keep._ The head scan cost 1,178 s against the base's 219 s, which is worth explaining before M2 designs around either number. And every coverage reason was `ambiguous_line_correspondence`, one per file — so in the PUSH path, unlike the census, correspondence is what stands between this subject and a completed question. The partition work removed one blocker and revealed the next.
- _Sized and attempted 2026-09-22._ One whole-repository scan at 500 regions with a 3,600 s deadline puts the declared target in scope and finds it: 271 of 406 questions completed, 213 findings, 2,950 s. The three-case replay at that budget then exhausted a 7,200 s case deadline with no artifact, and the failure is mine to own twice over: the container mounts `src` live and I edited the backend heavily during the run, including a version that could hang on a timed-out pipe; and the push's EVIDENCE pass is one unportioned 22,125-request batch protected only by the ceiling, which it exceeded under the CPU and memory contention my concurrent test runs created. Neither is the algorithm. The evidence pass is now portioned, streaming keeps what a killed portion finished, and the rerun uses a frozen export of the committed source with per-invocation logging so the record names its own expensive step.
- _Boundary: Evaluation harness, full-run integration_
- _Depends: 13.2, contributor-scan 7.3_
- _Depends: 13.2, contributor-scan 7.3, contributor-scan 7.8_
- _Requirements: 6.2, 6.3, 8.1, 8.2_
- [ ] 13.4 Let a question inside one partition complete, whatever else the repository holds
- **Diagnosed 2026-09-21, and PHP was never the variable.** A repository holding TWO languages can never complete a question, so it can never admit a finding. `partitions.py` raises `cross_partition_semantics_unresolved` whenever more than one language partition exists; that reason is a member of `GRAPH_INTEGRITY_GAPS`; and a graph-integrity gap demotes every completed outcome in the scan.