Scope feature dependencies on data modules to real usage

[AhmadKharfan]

Why

An audit of the module graph found that most feature-to-data Gradle edges are not real. Of 18 declared implementation(projects.data.*) edges across the seven feature modules, only three are backed by main-source usage. The rest are leftovers that make the dependency graph look far more tangled than the code actually is, slow builds down by over-linking, and would otherwise have to be encoded as "existing violations" when dependency-rule enforcement is added.

Removing them first means the enforcement baseline describes real coupling rather than accumulated noise.

What changed

Build files only. No production or test source is touched.

• Deleted 12 feature-to-data dependencies with no usage anywhere: onboarding→local; settings→local, git, build; projects→local, git; buildrun→local, git; git→local, git; editor→git, ai.
• Converted 2 to testImplementation, since they are used only from test sources: projects→templates (TemplateRegistryTest), editor→local (EditorRootInvalidationTest, EditorTabLifecycleTest).
• Deleted 2 further unused edges found during review: buildrun→core:common and buildrun→designsystem. Buildrun contains no @Composable at all, so it never needed the design system.

Kept, because they are genuinely used from main source:

• settings → data:ai — AiProviderCatalog
• buildrun → data:build — GradleProjectReader, ActiveBuild, ActiveBuildRepository
• editor → data:build — GradleProjectReader

Behavior

No behavior change. Nothing is added to or removed from the app's runtime classpath: :app declares all five data modules directly, and every Koin definition lives in app/di, so feature-to-data edges were never what put these classes in the APK. None of the removed modules contributes a manifest or any src/main/res, so manifest merging and resource resolution are unaffected.

On why a green build is not by itself proof

implementation dependencies are non-transitive at compile time, so removing one that was genuinely unused cannot break compilation — a passing build is close to tautological here. The removals were justified by symbol-level usage analysis instead, and separately checked for runtime reliance: Koin resolution by type, reflection, Class.forName, service loaders, manifest components, and resource lookup. No removed edge is required by any of those.

The split package that nearly caused a wrong deletion

:data:git and :data:local both declare the Kotlin package root com.ahmadkharfan.androidstudiolite.data.local. A package-based search therefore cannot tell which module owns a symbol, and initially suggested editor → data:git was needed by tests. Resolving it by locating each declaring file showed the two symbols involved — FileChangeBus and LocalFileContentRepository — are both declared in :data:local. So editor → data:git is unused and editor → data:local is test-only.

Note the reverse edge :data:git → :data:local is legitimate and untouched: JGitGitRepository really does use FileChangeBus.

Scope

• The three kept edges reach concrete data classes rather than abstractions. Introducing :domain contracts for them (GradleProjectReader, ActiveBuildRepository, AiProviderCatalog) is a follow-up, kept separate because it touches production code and DI wiring rather than only build files.
• The data.local split package itself is not fixed here; that is its own change.

Tests

No test changes. The existing suites are the check: if any deleted edge had really been used, compilation would fail immediately, and the two downgraded to testImplementation would break their test source sets.

• 707 tests passing, 0 failures.

Verification

Verified from a clean worktree at the branch tip, so no unrelated local work could mask a failure:

• ./gradlew test detekt :app:assembleDebug — BUILD SUCCESSFUL
• 707 tests, 0 failures

Usage was additionally confirmed per symbol rather than per package, to avoid the split-package trap described above.