Inventory: Split / Refactor Hotspots (Q2 2026)¶

Status: Refreshed inventory baseline Date: 2026-03-27 Baseline: origin/main @ bfbb2989 Scope: Largest handwritten Rust hotspots plus immediate watchlist candidates Constraint: Inventory only; no behavior or API changes are implied by this document

Why this inventory exists¶

The trust-compiler line is now on main, and the next refactor work should be driven by explicit hotspot inventory rather than ad hoc file-size intuition.

This inventory is therefore intentionally narrow:

• focus on handwritten Rust hotspots
• distinguish production, test-heavy, and already-partially-split modules
• recommend a wave order that keeps behavior freeze and reviewability realistic
• avoid treating generated files or fresh trust-compiler surfaces as automatic split targets

Baseline method¶

The baseline starts from the current largest handwritten Rust files on origin/main.

• Generated outliers are excluded from split priority:
• crates/assay-ebpf/src/vmlinux.rs
• The initial production threshold is the current repo helper convention:
• scripts/largest_rust_files.sh
• A few sub-800 LOC watchlist files are included where they remain architecturally important even if they no longer cross the old threshold

Hotspot signal snapshot¶

This is a compact snapshot of simple review signals at the baseline head. It is not a quality score, but it does help explain why some files are better next-wave candidates than others after Wave43-Wave49 already retired the earlier MCP / registry / pack / sim hotspots.

Most recent top 10 handwritten hotspots¶

This is the current raw size-ranked handwritten top 10 on origin/main, excluding the generated crates/assay-ebpf/src/vmlinux.rs outlier.

Inventory table¶

Why these bands¶

P1 — best near-term split candidates¶

These are the strongest current candidates because they combine:

• large enough size to hurt reviewability
• central runtime or registry/CLI behavior
• bounded seams that can be moved mechanically behind stable facades
• immediate payoff without reopening freshly settled trust-compiler surfaces

P2 — valuable, but not the first wave¶

These are real hotspots, but the timing matters:

• crates/assay-core/src/vcr/mod.rs and crates/assay-registry/src/lockfile.rs are both solid candidates, but they are slightly less urgent than the next registry auth / core proxy seams
• crates/assay-cli/src/cli/commands/profile.rs is useful cleanup, but its payoff is lower than sandbox.rs

P3 — big files, but mostly test/support debt¶

The test-heavy files are worth splitting, but not as initial production waves:

• they should follow the production seam split they validate
• otherwise the repo risks spending an early wave on test reorganization without improving the underlying hotspot

Recommended wave order¶

R50 — Registry auth split¶

Primary file:

• crates/assay-registry/src/auth.rs

Goal:

• reduce auth.rs to a stable facade and isolate provider selection, OIDC exchange, cache handling, and request/header plumbing

Suggested target structure:

crates/assay-registry/src/auth_next/
  mod.rs
  providers.rs
  oidc.rs
  cache.rs
  headers.rs
  diagnostics.rs

Hard constraints:

• no registry auth semantic drift
• no token refresh or cache lifetime drift
• no request/exchange URL drift
• no resolver or trust-store coupling drift

R51 — MCP proxy split¶

Primary file:

• crates/assay-core/src/mcp/proxy.rs

Goal:

• isolate config parsing, process/http lifecycle, and proxy surface helpers behind the stable McpProxy entrypoint

Suggested target structure:

crates/assay-core/src/mcp/proxy_next/
  mod.rs
  config.rs
  lifecycle.rs
  transport.rs
  diagnostics.rs

Hard constraints:

• no proxy runtime behavior drift
• no configuration-shape drift
• no request/response contract drift
• no coupling drift into handler/evidence/CLI layers

R52 — Sandbox command split¶

Primary file:

• crates/assay-cli/src/cli/commands/sandbox.rs

Goal:

• keep CLI command UX stable while isolating backend detection, degradation payloads, profile wiring, and process execution

Why after R50/R51:

• it is important, but it is less central than the next registry/core runtime candidates
• it carries unsafe and backend-specific behavior, so the best split will benefit from the now-mature freeze/split/closure pattern

R53 / R54 — VCR and registry lockfile follow-ons¶

Primary files:

• crates/assay-core/src/vcr/mod.rs
• crates/assay-registry/src/lockfile.rs

Rule:

• choose between them after R50-R52 based on whichever subsystem is creating more review pain
• both are better later than the auth/proxy/sandbox trio

T-R1 / T-R2 / T-A2A — Follow-on test decomposition¶

Follow-on files:

• crates/assay-core/tests/decision_emit_invariant/main.rs
• crates/assay-core/src/mcp/tool_call_handler/tests/mod.rs
• crates/assay-adapter-a2a/src/adapter_impl/tests.rs

Rule:

• only split these after the corresponding production seam is frozen
• otherwise the test refactor risks obscuring the real production split

What should not be first¶

• generated files such as crates/assay-ebpf/src/vmlinux.rs
• fresh trust-compiler product surfaces such as crates/assay-evidence/src/trust_basis.rs
• already partially split facades such as crates/assay-core/src/engine/runner.rs and crates/assay-core/src/storage/store.rs
• test-only giant files before the next production seam is chosen
• simulation/support modules unless they are explicitly blocking product work

Suggested next concrete step¶

If the repo wants one new refactor lane now, the best sequence is:

1. R50 — crates/assay-registry/src/auth.rs
2. R51 — crates/assay-core/src/mcp/proxy.rs
3. R52 — crates/assay-cli/src/cli/commands/sandbox.rs
4. R53/R54 — vcr/mod.rs vs registry/lockfile.rs

That order keeps the next unsplit production hotspots ahead of the giant test-only files and avoids reopening newly stabilized trust-compiler surfaces too early.