Skip to content

[P1 refactor] Simplify architecture and retire technical debt; treat build speed as a supporting metric #4830

Description

@phasetr

Objective and priority

Plan and execute a bounded refactoring programme whose primary outcomes are simpler code, coherent abstractions, and retired technical debt. Build-time improvement is supporting evidence and a regression guard, not the reason to accept a design.

Baseline for the initial inventory: main at f23fa1e732d6985a59d305c85e018f06d62b2f88 (2026-08-01 JST). Every child must remeasure at its own start.

Decision order

  1. Preserve the mathematical architecture: weakest useful SimpleGraph core, Ambient transport, then concrete lattice capstones.
  2. Remove responsibility mixing, dependency inversion, repeated proof/API structure, or incoherent file boundaries only when current consumers demonstrate the replacement boundary.
  3. Preserve public/book-facing names unless a citation and consumer audit justifies removal; a one-line semantic alias may be preferable to deletion.
  4. Measure import closure, elaboration time, clean/incremental build cost, and RSS only to compare otherwise sound designs and prevent regressions.

Child workstreams

The linked subissues are the complete initial programme. Each begins with an audit gate. A failed gate closes that child as not planned with measurements; it must not turn into speculative infrastructure.

All seven first-wave children are closed (3 completed: #4832, #4833, #4837; 4 declined not planned after
audit gate: #4831, #4834, #4835, #4836).

Common acceptance criteria

  • Each child records current declarations, responsibilities, consumers, citations, and import edges before proposing edits.
  • Each implementation is a separately reviewable pilot with preserved public entry points and a rollback boundary.
  • New records/typeclasses/helpers require demonstrated current consumers; no anticipated-reuse abstraction.
  • Targeted module, downstream importer, root build, lake exe GKSTest, repository audit gates, representative #print axioms, and documentation/citation checks pass with zero warnings.
  • Any deletion runs escaped/normalised TeX citation checks in addition to ordinary source search.
  • Before/after import closure and build measurements are recorded, but no child is accepted solely for speed or line-count reduction.
  • Public API break, new axiom/placeholder, warning, build failure, cold-build regression over 5%, RSS regression over 10%, or increased regenerated .olean closure blocks merge.
  • The parent closes only after every child is completed or explicitly declined with evidence.

Dependencies and sequencing

  • Execute the P0 exhaustion-family-equation child first. Its A1 must precede A2, and both are serialized against other high-fanout ancestor edits and canonical build measurement.
  • The import-DAG contract child defines the architectural checks used by implementation pilots, but it does not authorize mechanical import rewriting.
  • After P0, record the import-DAG contract, then evaluate finite Gibbs-kernel and AmbientLattice/Defs/Core ownership before derivative-family consolidation.
  • Lee--Yang/Ascoli may audit in parallel with Gibbs/Core after the import contract; its implementation pilot must not overlap high-fanout edits.
  • Large-file cleanup consumes the other audits' concept boundaries; it must not invent boundaries from file length.
  • Changes to near-universal ancestors and canonical build measurements must be serialized.

Non-goals

Historical context

docs/plans/4506-refactoring-replan.md is an archived execution record, not current authorization. #4823 is closed not planned after bounded duplication work. GitHub #4786, #4793, and #4794 are deleted; their local mirrors are historical snapshots only.

Second-wave plan (2026-08-02)

The initial seven-child programme is resolved. A current-code re-audit authorized by the user identified five non-duplicate, bounded follow-ups. They inherit this parent’s decision order, common acceptance criteria, and fail-closed audit discipline.

Second-wave progress: 5/6 resolved (#4850, #4851, #4852/#4853 declined not planned, #4857). GitHub sub_issues_summary = 12/13 across both waves.

Second-wave sequencing

  1. Execute the ownership-correction children first ([P0 refactor] Restore the generic-to-Concrete ownership boundary around extremal configurations #4850, [P0 refactor] Re-home sum_spin at its Spin-level owner #4851 — both completed — then [P0/P1 refactor] Restore generic ownership of gibbsExpectationBC_field_mono (MonotonicityBetaBoundaryCondition -> MagnetizationFieldMonotone) #4857). They are direct responsibility corrections and must be serialized with other high-fanout ancestor edits.
  2. After those ownership boundaries settle, [P1 refactor/audit] Unify edge- and vertex-avoidance proofs behind a consumer-proven forbidden-edge core #4852 and [P1 refactor/audit] Extract the shared numeric core of spectral-gap certificates #4853 may audit in parallel, but their implementation pilots must be separately reviewable and must not overlap canonical build measurement.
  3. Execute [P2 refactor/pilot] Canonicalize one identical-statement Patches group with compatibility aliases #4854 last and alone because its normalized statement checks and docs/TeX synchronization are the primary safety boundary.
  4. Do not reopen [P1 refactor/audit] Consolidate derivative abstractions only after a current contract matrix #4835’s repository-wide derivative-wrapper consolidation or [P2 refactor/audit] Clean up large files and serial micro-modules along concept boundaries #4836’s mechanical file-layout candidates without their recorded reopen conditions.
  5. Close this parent only when every native sub-issue is completed or explicitly declined with evidence (13 as of 2026-08-02: 7 first-wave + 6 second-wave; the count grows if a child's own audit gate spawns a tracked follow-up, as [P0 refactor] Restore the generic-to-Concrete ownership boundary around extremal configurations #4850's AC2 spawned [P0/P1 refactor] Restore generic ownership of gibbsExpectationBC_field_mono (MonotonicityBetaBoundaryCondition -> MagnetizationFieldMonotone) #4857).

Build speed remains a supporting metric throughout this second wave: it can reject a coherent design on regression grounds or break a tie, but cannot create an abstraction boundary or justify deletion.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions