refactor: targeted module reorganization after cleanup stack #150

New issue

Closed

opened 2026-09-21 18:12:33 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-09-21 18:12:33 +00:00

Owner

Original issue: barrettruth/diffs.nvim#347
Original author: barrettruth
Original date: 2026-05-13T18:11:09Z

Tracked By

#315

Context

lua/diffs/ has a broad flat top-level module set. That is a real organization smell, but it should be handled after the current behavior-preserving refactor stack lands, not mixed into those PRs.

Scope

Do a targeted reorganization only where ownership boundaries are already clarified by the preceding refactors. Avoid a broad file-move PR that only churns require() paths.

Likely candidates after the cleanup stack:

generated-buffer metadata/source helpers under a generated/view-owned namespace
hunk actionability helpers near actions/hunks ownership
integration metadata under an integration-owned namespace if the single module grows
behavior utilities under clearer support modules only where duplication has already been reduced

Acceptance Criteria

no behavior changes
no public API changes
no broad move-only churn without ownership simplification
module moves are paired with a concrete reduction in duplication or clearer ownership

> Original issue: barrettruth/diffs.nvim#347 > Original author: `barrettruth` > Original date: 2026-05-13T18:11:09Z ## Tracked By - #315 ## Context `lua/diffs/` has a broad flat top-level module set. That is a real organization smell, but it should be handled after the current behavior-preserving refactor stack lands, not mixed into those PRs. ## Scope Do a targeted reorganization only where ownership boundaries are already clarified by the preceding refactors. Avoid a broad file-move PR that only churns `require()` paths. Likely candidates after the cleanup stack: - generated-buffer metadata/source helpers under a generated/view-owned namespace - hunk actionability helpers near actions/hunks ownership - integration metadata under an integration-owned namespace if the single module grows - behavior utilities under clearer support modules only where duplication has already been reduced ## Acceptance Criteria - no behavior changes - no public API changes - no broad move-only churn without ownership simplification - module moves are paired with a concrete reduction in duplication or clearer ownership

barrettruth

2026-09-21 18:12:33 +00:00