Bring the four oversized modules touched by Issue 26 under the size gate

[fwyc0573]

Problem

AGENTS.md sets a 2,000-line soft limit on any critical module. Four modules that the Issue 26 correctness fixes have to edit were far above it. Editing them in the same pull request as the behavior fixes would have made that diff unreadable, because a reviewer could not tell a moved line from a changed one.

This PR brings those four under the gate through a cleanup-first pass and a functional split, with no behavior change and no numeric change. The correctness work is stacked on top as #35.

Result

Module	Before	After	Split into
frontier/config/config.py	5720	788	12 modules, largest 1888
frontier/scheduler/replica_scheduler/vllm_v1_engine_replica_scheduler.py	5138	1386	8 modules
frontier/execution_time_predictor/shared_prediction_model_manager.py	4614	722	6 modules
frontier/execution_time_predictor/sklearn_moe_execution_time_predictor.py	3539	1557	5 modules

Five modules remain above 2,000 lines: sklearn_execution_time_predictor.py 8263, metrics_store.py 5586, sklearn_disaggregation_execution_time_predictor.py 2985, profiling/attention/main.py 2157, entities/request.py 2125. These were named as out of scope in plan.md section 1, in commit 56efdf7, before any source change was made, not justified afterwards. The gate applies to modules a change touches, and the Issue 26 fixes touch none of these five. They are a documented boundary, not an oversight.

How the no-change claim is verified

A 71-case matrix runs each case through a checked-in example wrapper on both this branch and a read-only checkout of the base commit, then compares every artifact the run produces. The gate is exact equality, not a tolerance: a behavior-preserving refactor has no reason to change a simulated number.

Compared per case: request_metrics.csv, system_metrics.json, frontier_stage_batch_ledger.jsonl, op_precision_metadata.csv and config.json, plus the set of files produced. Only three run-specific absolute paths are normalized; the metrics artifacts carry no timestamps, wall-clock durations or hostnames, so nothing else needs to be.

Coverage: co-location, sequential PDD and sequential PD-AF; dense and MoE; offline and online; the dummy predictor and the checked-in profiling CSVs; 4 to 64 requests, prompts from 128 to 3584 tokens, three arrival rates; chunked prefill, all three decode CUDA graph modes, prefix caching, speculative decoding, thinking mode; TP, PP, attention DP and EP variations; the Sarathi and SGLang schedulers.

Each measurement is taken from a read-only detached checkout of its own commit, never from a shared working tree, so no result can be a mixture of unrelated edits. The harness lives in tests/e2e/refactor_fidelity/; measure_commit.py performs one such measurement end to end.

The predictor cache comparison

The matrix also compares the names of the predictor cache files each side produces. This matters because output equality alone would not catch a changed training identity: retraining from the same CSV reproduces the same numbers, so a re-keyed estimator is invisible in the metrics.

It is the load-bearing check for the manager split, which moves _get_model_hash, _get_hash_relevant_config, the trained-model registry and the FFN contract signature into different modules. All 426 cache file names matched, and the comparison classifies any difference as re-keyed, baseline-only or candidate-only so that a hash change cannot be mistaken for a new model.

Correction after external review (2026-09-22, C34-01). The eligibility rule for this comparison accepted cache_clean_before_run plus an empty case_filter, which a --start/--limit continuation also satisfies, so a clean partial run merged onto full retained results could have compared a partially populated cache. 2310417 requires each manifest's cases_executed_in_last_run to equal the full case table and adds gate tests for --limit, --start, symmetric partial caches and a manifest without the field. The acceptance verdict above was re-derived on the retained outputs with the corrected rule and is unchanged: both labels executed all 71 cases, predictor_cache_compared: true, 0 cache differences (report).

Review round 1: the gate was corrected before it was trusted

Maintainer review found that the harness producing the evidence above could report success without having compared anything. That was addressed first, because a passing result from an unsound gate is worth less than no result.

The gate could pass while comparing nothing (R34-01). baseline_failures was missing from the failure predicate, and completeness tested only whether both result tables contained every case id — which a table of failure records satisfies. Separately, list_artifacts returns [] for a path that does not exist, so two deleted artifact directories compared as identical. Completeness now means compared, not present; missing_evidence_for checks that a successful record still names a directory that exists and whose files match the recorded inventory; and an unexplained bucket lists any case that was neither compared nor reported under a specific finding, so a future code path cannot drop a case silently and still pass.

One label could describe several measurements (R34-02). Continuation runs merged retained records and then rewrote the label manifest with the current run's revision and cache listing, and a reused checkout was accepted after comparing HEAD alone. Every case record now carries source_revision, source_dirty and harness_revision; a continuation whose retained records disagree is refused before anything runs; case_count counts lines actually written; cache names are compared only when both sides' manifests show one clean, unfiltered run whose executed case list equals the whole table, so --start/--limit continuations are excluded as well (tightened after external review finding C34-01, 2310417); and a reused checkout with modifications is reported and refused rather than cleaned.

Both were reproduced before and after against the pre-fix harness with identical synthetic inputs. Four scenarios that returned exit 0 before now fail; both healthy controls are unchanged:

Scenario	Before	After
All 71 cases failed on both sides	exit 0, compared 0	exit 1
Baseline failure hiding a candidate failure	exit 0, compared 70	exit 1
Baseline failure, candidate succeeded	exit 0, compared 70	exit 1
Artifact directories deleted on both sides	exit 0, compared 71 as identical	exit 1, excluded as missing evidence
Healthy identical sides (control)	exit 0	exit 0
Healthy content mismatch (control)	exit 1	exit 1

Committed as tests/unit/test_refactor_fidelity_gate.py, 22 tests. One of them asserts that the dirty-checkout check leaves the modified file untouched, so the check cannot start repairing a checkout in order to pass itself.

Review round 2: the final record, taken with the corrected gate

The earlier chronological runs were genuine per step, but none of them could serve as the acceptance record (R34-03). candidate_db15e64 held 67 records and no DP-placement case, so the four cases that took the table from 67 to 71 had never run against the refactor tip; and the baseline label's last execution was a filtered four-case run merged onto 67 without a cache clean, which is why it reported a case_count of 72 over 71 result lines. The provenance stamp added above also invalidates every label captured before it, by design.

Both sides were therefore recaptured as single clean full runs, driven by the harness at one revision:

	baseline	candidate
Source revision	1f694f7	bb582a4
Source working tree	clean	clean
Harness revision	bb582a4	bb582a4
Case filter	none	none
Cases executed	71	71
Cache cleaned first	yes	yes
Cache files produced	426	426

71 of 71 compared, 71 identical, 0 mismatched, no failures on either side, no missing evidence, no differing case definitions, no cases uncompared, no provenance findings, and 0 predictor-cache differences. Comparison exit code 0.

Whole tests/unit: 84 failed / 3679 passed / 49 skipped here, against 84 / 3644 / 49 on 1f694f7. The 84 failure identities are byte-identical — diff of the sorted FAILED lists is empty — and the 35 extra passes are exactly the tests added in these two rounds. Ten modules do not collect on either side for want of torch or matplotlib; they are listed in the report rather than counted as passing. This is a regression comparison, not a claim that those 84 pass.

The checks that specifically protect a move-heavy refactor are now committed rather than run once (R34-04): tests/unit/test_module_split_boundaries.py, 13 tests covering annotation resolution in each defining module, generation of the flat CLI, the public re-export surface from both entry points, mixin order for each split class, ClusterConfig field ownership, loading a cached estimator into a fresh registry, and importing every split module in a fresh interpreter.

Two results from that work are worth stating on their own:

• All 142 estimators in the baseline-produced cache unpickle under the split code, and the 86 exposing n_features_in_ also predict. A pickle records the module path of the class it holds, and moving code is what invalidates that; matching cache names could not have shown it.
• typing.get_type_hints(ClusterConfig) raises NameError: BaseCCBackendConfig, because cc_backend_config is annotated with a name the module does not import at runtime. The same lookup fails on 1f694f7, so it predates the split and the generated CLI is unaffected. It is pinned in KNOWN_UNRESOLVED_CONFIG_ANNOTATIONS so a new unresolvable annotation fails, and so does fixing this one without dropping the pin.

Test changes, in three kinds

Eight test files changed. No assertion, expected value or tolerance changed anywhere.

1. A patch target moved with the code. Most of them. A test patches or imports a module-level name and the code under test now resolves it in the module it moved to. A patch aimed at the wrong module does not fail loudly, it silently stops intercepting, so these were found by comparing failure identities between the two sides rather than failure counts. Counts alone would have hidden them, because several of the same files already have pre-existing failures.

2. A governance allowlist entry. test_raw_model_profile_resolution_callsites_are_allowlisted is an exhaustive, commented list of every (file, function, kind) permitted to resolve a raw model architecture profile, with how many times each may do so. The diff there is one line, and it is a file path: same function _resolve_model_architecture_profile, same kind helper, same expected count of 1, still 11 entries. The property the gate protects is intact; only the module hosting one entry moved. An entry added, removed, or given a higher count would be the change worth scrutiny, and none of those happened.

3. A test that gained a patch, as evidence rather than cost. MOE_FAMILY was one binding in one module and is now imported by two modules that the path under test both read, so three tests install the fake family in both. The assertion is unchanged, and the second patch is needed precisely because the production code genuinely reads the name in both places.

What a reviewer should check

• The splits are moves: method bodies, method names and call sites are unchanged. The groups extracted from a class are mixins that the class inherits, not free functions taking the object, so that external callers and tests keep working without shims.
• Every new module carries the imports its own annotations need. This is a correctness constraint, not style: the flat CLI generator resolves annotation strings in the defining module's namespace.
• The generated CLI is unchanged at 753 flags, and the flag names diff empty between 1f694f7 and the tip. Every name other modules import from frontier.config still resolves, from whichever of the two entry points imports it.
• Four regressions were introduced by the splits and fixed, all of them cross-module references that a pure move exposes: a module-level logger object, two missing imports, and a test patch target. A static check that reports names loaded but neither imported, defined locally, nor builtin is what found the third.

Review material

Tracked under task_memory/task_2026-09-21_oversized_module_split/: plan.md (scope, boundaries, sequencing, matrix design, acceptance), module_survey.md (grep-backed survey of all four modules), issues.md (every regression with cause and resolution), progress.md, summary.md, and the test reports — including the base-commit baseline, the failures that already exist on main, and the two rounds above:

• test_report_2026-09-22_checkpoint_a_fidelity_gate.md — the gate defects, the corrections, and the before/after reproduction
• test_report_2026-09-22_checkpoint_b_final_evidence.md — the final 71-case record, the unit-suite comparison, the retained checks, and the limits of each

Status

Open for review (no longer a draft on GitHub). Do not merge before review.