engine: db.rs is 1 line from the 6000-line lint cap; split before it blocks an unrelated commit

[bpowers]

Problem

src/simlin-engine/src/db.rs is currently 5999 lines. The repo-wide lint scripts/lint-project.sh enforces a hard MAX_LINES=6000 threshold on Rust source files (rule 2 at scripts/lint-project.sh:38-52), and that lint runs in the pre-commit hook and CI. The file is effectively one line away from breaking pnpm lint: any future addition to db.rs of more than ~1 line will trip the threshold and force whoever is working there to do a tangential refactor before they can commit unrelated changes.

This is the same class of problem as #471 (vdf.rs at 6001 lines), but caught proactively — db.rs is right at the edge rather than already over it.

How it got here

The file crept up to 5999 during the LTM cross-element-aggregate-scoring work on branch ltm-503-cross-element-agg. Several commits on that branch had to actively manage headroom — de-duplicating helpers and moving LTM wiring into sibling modules (db_ltm.rs, ltm_agg.rs) — specifically to stay under the cap. There is no slack left.

Why it matters

• The next non-trivial change to db.rs will fail pnpm lint / pre-commit / CI on an unrelated diff, the same way engine: vdf.rs exceeds MAX_LINES=6000 lint threshold (6001 lines), breaking pnpm lint #471 broke pnpm lint on main.
• The hard threshold exists to force modularization of super-sized files; bumping it ad hoc would undermine the policy.
• db.rs is the salsa-incremental-compilation hub and a high-traffic file (it's where most new compilation/analysis wiring lands), so the squeeze will recur often.

Component

• src/simlin-engine/src/db.rs
• Lint rule in scripts/lint-project.sh

What's in db.rs

The salsa machinery: SimlinDb; the SourceProject / SourceModel / SourceVariable salsa inputs; compile_project_incremental; the dependency graph; assemble_module (including a substantial block of LTM wiring in its pass 3); compute_layout; the diagnostic accumulator. It already uses the #[path = "..."] mod ...; pattern to host related code in db_analysis.rs, db_ltm.rs, and ltm_agg.rs.

Possible approaches

Following the existing #[path] submodule precedent (and the #471 fix pattern):

• Move the assemble_module / compute_layout layout-and-assembly section — or specifically the LTM-wiring portion of assemble_module's pass 3 — into a new sibling submodule (e.g. db_assemble.rs or db_layout.rs) declared via #[path] mod ...; with pub(super) visibility, alongside db_analysis.rs / db_ltm.rs / ltm_agg.rs.
• Or extract the dependency-graph construction into its own submodule.

The fix is mechanical: find a cohesive 200-500-line cluster and relocate it to a db_<name>.rs submodule. Doing it now (with headroom to spare) is lower-risk than doing it under duress when a feature commit is blocked.

Context

Identified during the LTM cross-element-aggregate-scoring work (docs/design-plans/2026-05-09-ltm-503-cross-element-agg.md / branch ltm-503-cross-element-agg), where keeping db.rs under the cap required repeated headroom management.

Related, lower priority

src/simlin-engine/tests/simulate_ltm.rs is 6652 lines — over the 6000-line threshold — but scripts/lint-project.sh excludes */tests/*, so it does not fail the lint. It is nonetheless a very large test file that would benefit from being split by topic (A2A loops, cross-element loops, polarity analysis, etc.).

[bpowers]

Recurrence during Vensim macro support work (Phase 3)

This concern recurred on a completely independent feature stream, confirming it is a recurring tax rather than an artifact of the LTM work that originally surfaced it.

During Phase 3 of the Vensim macro support implementation (docs/implementation-plans/2026-05-13-macros/, branch macros), the macro-registry compilation wiring tripped the MAX_LINES=6000 cap on db.rs multiple times across two separate tasks:

• First over the cap at 6124 lines.
• Then repeatedly back over at 6001 / 6002 lines while landing the registry wiring.

Each occurrence forced defensive, off-task work to get back under the cap:

• Extracted a new sibling module src/simlin-engine/src/db_macro_registry.rs (via the established #[path] mod ...; pattern, same precedent as db_ltm_ir / db_analysis / db_ltm / ltm_agg).
• Condensed existing comments in db.rs to reclaim lines.

After that work db.rs again sits with only ~1 line of margin under the 6000 cap, so the next change that touches it at all will trip the cap and force yet another unrelated decomposition/comment-trimming side quest.

Why this strengthens the case

The original report framed this as fallout from the LTM cross-element-aggregate-scoring work. This recurrence on the macro stream demonstrates the squeeze is structural: db.rs is the salsa-incremental-compilation hub where most new compilation/analysis wiring lands, so essentially every feature that adds a compilation pass pays this tax. Bumping headroom by one extraction at a time (db_ltm_ir, now db_macro_registry) keeps deferring the real fix.

Recommended remediation (updated)

Proactively split cohesive chunks of db.rs into sibling modules following the established db_ltm_ir / db_macro_registry pattern, targeting a comfortable margin (not ~1 line) under the cap. Candidate cohesive groups:

• The sync_from_datamodel family.
• The diagnostic-collection helpers.
• (Per original report) the assemble_module / compute_layout layout-and-assembly section or its LTM-wiring portion, and/or the dependency-graph construction.

Goal: bring db.rs to a comfortable margin under the 6000-line cap so routine changes stop tripping it.

Context

Identified during Phase 3 of the Vensim macro support work (docs/implementation-plans/2026-05-13-macros/). This is tech debt out of scope for the macro-support task; tracked here, not fixed there.

[bpowers]

Recurrence during GH #554 macro fix (intrinsic false self-recursion)

A third+ recurrence, on a later commit than the Phase 3 comment above, on the same macros branch but a distinct task: landing the GH #554 fix (b0ef57a2 engine: fix false self-recursion for intrinsic macros).

That fix touches the salsa-incremental compilation hub (it adds a salsa-tracked macro_body_owner map and threads macro-self-recursion detection through collect_called_macros / BuiltinVisitor::walk). Implementing it again pushed src/simlin-engine/src/db.rs over the MAX_LINES=6000 cap enforced by scripts/lint-project.sh (line 40, MAX_LINES=6000; check at line 46-47).

To get back under the cap the implementer had to:

• Relocate logic into the existing src/simlin-engine/src/db_macro_registry.rs sibling module (the same #[path] mod ...; decomposition template established by db_ltm_ir / db_macro_registry), and
• Tighten an otherwise-unrelated in-context comment in db.rs purely to reclaim lines and fit the cap.

After that work db.rs sits at exactly 6000 lines -- zero margin:

$ wc -l src/simlin-engine/src/db.rs src/simlin-engine/src/db_macro_registry.rs src/simlin-engine/src/db_ltm_ir.rs
  6000 src/simlin-engine/src/db.rs
   384 src/simlin-engine/src/db_macro_registry.rs
   693 src/simlin-engine/src/db_ltm_ir.rs

So the very next change that touches db.rs at all will trip the cap and force yet another unrelated decomposition / comment-trimming side quest -- exactly the failure mode this issue's title calls out.

Why this strengthens the case

This is now the third+ time the chronic db.rs cap has imposed an unrelated decomposition + comment-trimming tax on an in-flight feature change (the LTM cross-element-aggregate work in the original report, the macro Phase 2/3 work in the comment above, and now the GH #554 fix). The pattern is consistent and structural: db.rs is the salsa-incremental-compilation hub, so essentially every feature adding a compilation/analysis pass pays this tax, and each one-extraction-at-a-time bump (db_ltm_ir, then db_macro_registry) just re-arms the trap at ~0-1 lines of margin.

The remediation already proposed in this issue still stands and is reinforced: proactively split cohesive chunks of db.rs into sibling modules following the established db_ltm_ir / db_macro_registry template, targeting a comfortable margin under the 6000 cap rather than landing back at the cap each time.

Context

Identified while landing the GH #554 fix (b0ef57a2) on branch macros (docs/implementation-plans/2026-05-13-macros/). Out of scope for the macro epic; recorded here as fresh recurrence evidence, not fixed there.

[bpowers]

Update (2026-05-19, surfaced by the element-cycle-resolution Phase 6c code review):

Current measurements after element-cycle-resolution Phase 6:

• src/simlin-engine/src/db.rs: 5895 lines (still under the 6000 cap; the squeeze recurs as predicted)
• src/simlin-engine/src/vm.rs: 5920 lines (now also within ~80 lines of the cap)

The relief pattern this issue recommends has continued: db.rs has since spun out db_dep_graph.rs, db_ltm_ir.rs, db_macro_registry.rs, and db_var_fragment.rs (in addition to the db_analysis.rs/db_ltm.rs/ltm_agg.rs named in the original description) specifically to stay under the cap.

vm.rs is now in the same situation this issue describes for db.rs: it has already spun out vm_vector_elm_map.rs and vm_vector_sort_order.rs to manage headroom, and at 5920 lines a future task adding to it will be forced to split mid-stream. Filed as a separate, focused issue (cross-referenced) so the vm.rs half is tracked independently of the db.rs salsa-hub work.