Problem: This is the single largest, highest-fan-in file in the entire candidate set — thousands of lines, over a hundred exports, more than twenty external consumers across nearly every part of the codebase. It's the biggest blast-radius item in this whole initiative and should be done alone, last, not combined with any other phase.
Area: ORB / gittensory-engine
Proposal: Move the file into gittensory-engine, leaving a temporary full re-export shim in its old location so none of its many consumers need an import-path change in the same PR. Follow the same playbook already recommended for the in-flight queue-decomposition work: one direction of movement per PR, verified against the coverage/rename tooling (per the first issue in this phase) before doing it for real.
Deliverables:
- The file moved, with a working full re-export shim, all existing consumers unaffected.
Acceptance criteria:
Boundaries:
- Do not combine this move with any other refactor, cleanup, or behavior change in the same PR — the blast radius alone is enough to manage carefully.
Problem: This is the single largest, highest-fan-in file in the entire candidate set — thousands of lines, over a hundred exports, more than twenty external consumers across nearly every part of the codebase. It's the biggest blast-radius item in this whole initiative and should be done alone, last, not combined with any other phase.
Area: ORB / gittensory-engine
Proposal: Move the file into
gittensory-engine, leaving a temporary full re-export shim in its old location so none of its many consumers need an import-path change in the same PR. Follow the same playbook already recommended for the in-flight queue-decomposition work: one direction of movement per PR, verified against the coverage/rename tooling (per the first issue in this phase) before doing it for real.Deliverables:
Acceptance criteria:
Boundaries: