ADFA-5444: Skip the Downloads restore/collision check for plugin templates

[jimturner-adfa]

ADFA-5444

Summary

Uninstalling a plugin-provided template (reported with the Flutter plugin) unconditionally tried to "restore" it to Downloads first, tripping a false "already exists" collision whenever an unrelated file happened to share its name there. The template was extracted straight from the plugin's own bundled resources (PluginProjectManager.extractBundledCgtTemplates) and never touched Downloads in the first place, so the error was both blocking and factually wrong - matching the ticket's exact repro and screenshot.

• A plugin-provenance item now just gets deleted from the templates directory on uninstall, skipping the Downloads restore/collision check entirely.
• This matches how PluginProjectManager/IdeTemplateServiceImpl already remove plugin templates elsewhere (cleanupPluginTemplates/unregisterTemplate).
• User-imported templates keep the existing restore-to-Downloads behavior, since those genuinely came from there.

Testing

• Added uninstallTemplate_pluginProvenance_neverChecksOrTouchesDownloads; verified it fails without the fix with the exact reported error (IllegalStateException: A download named '...' already exists in ...) and passes with it.
• Reproduced the bug on a physical device using a real installed Flutter plugin (com.ali.fluttertemplate): created a same-named stale file in Downloads for one of its templates, confirmed uninstall previously would have blocked on it, then confirmed with the fix it deletes cleanly - the real template file is removed from the templates directory and the unrelated Downloads file is left untouched. No crashes.

🤖 Generated with Claude Code

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.

_{Tip: disable this comment in your organization's Code Review settings.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: d9cb48b3-b24a-462f-b671-fe9546f2519d

📥 Commits

Reviewing files that changed from the base of the PR and between 5a26dfa and fee3efb.

📒 Files selected for processing (3)

• app/src/main/java/com/itsaky/androidide/repositories/TemplateRepository.kt
• app/src/main/java/com/itsaky/androidide/repositories/TemplateRepositoryImpl.kt
• app/src/test/java/com/itsaky/androidide/repositories/TemplateRepositoryImplTest.kt

Included review availability: Your plan provides up to 2 included reviews per hour; 0 remain after this review.

---

📝 Summary

• Plugin-provided templates are deleted directly from the templates directory.
• The uninstall flow no longer restores plugin templates to Downloads or checks for filename collisions.
• User-imported templates retain the existing restore-to-Downloads behavior.
• Added regression coverage for plugin-template uninstall behavior.
• Validation with an installed Flutter plugin confirmed that the plugin template is removed and an unrelated same-named Downloads file remains unchanged.
• Risk: Plugin-template files are permanently deleted instead of being restored to Downloads.

Walkthrough

uninstallTemplate now deletes plugin-provenance templates directly. User-imported templates keep the restore-to-Downloads flow. KDoc and a regression test describe and verify the behavior.

Changes

Plugin Template Uninstall

Layer / File(s)	Summary
Direct plugin uninstall path app/src/main/java/com/itsaky/androidide/repositories/TemplateRepository.kt, app/src/main/java/com/itsaky/androidide/repositories/TemplateRepositoryImpl.kt, app/src/test/java/com/itsaky/androidide/repositories/TemplateRepositoryImplTest.kt	The implementation deletes plugin-provenance templates without checking or writing to Downloads. User-imported templates retain the existing restore flow. KDoc documents both paths, and the test verifies that Downloads remains unchanged.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Merge Risk: ⚪ Minimal · up to fee3e

The plugin uninstall path deletes plugin-provided templates without interacting with Downloads, while user-imported templates retain their restore behavior. No merge-blocking risk is identified.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 6 functions across 3 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: plugin templates skip the Downloads restore and collision check during uninstall.
Description check	✅ Passed	The description directly explains the bug, the plugin-template uninstall fix, preserved user-template behavior, and test coverage.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ADFA-5444-Extensions-manager-Cant-uninstall-a-Flutter-template

---

_{A rabbit watched the plugin file go,
No Downloads copy had to show.
The template vanished from its place,
While user files kept their restore case.
Tests guarded every path with care.}

_{Comment @coderabbitai help to get the list of available commands.}

[jimturner-adfa]

Merge-order note: if this merges after #2045 (ADFA-5446), you'll hit one real conflict in TemplateRepository.kt - both PRs edit the uninstallTemplate doc comment/signature (this PR describes the plugin/user provenance split; #2045 adds the overwrite param for the Downloads-replace flow). They're not contradictory - I simulated the merge locally and the actual implementation in TemplateRepositoryImpl.kt combines both changes correctly with no manual work needed (the plugin-provenance branch runs first, then the overwrite/collision logic). Only the interface doc comment needs reconciling by hand.

Resolution to use when that conflict comes up:

	/**
	 * Removes [item] from the templates directory and reloads templates. A plugin-provided item is
	 * just deleted, since it never came from Downloads in the first place. A user-imported item is
	 * restored to Downloads first, failing with [TemplateReplaceConflictException] if a file of the
	 * same name already exists there, unless [overwrite] is true.
	 */
	suspend fun uninstallTemplate(
		item: CgtFileItem,
		overwrite: Boolean = false,
	): Result<Unit>

No other files conflict between the two PRs - confirmed with a full local merge simulation (compiles clean, all 22 tests across both PRs pass together).

[Elissa-AppDevforAll]

I could uninstall the individual templates created by the Flutter plugin.

[hal-eisen-adfa]

There's a logic bug here. It doesn't matter where a template comes from (plugin or cgt file). We don't need a "restore" function for templates. If you want to add a "disable" feature to match the plugins, I could see that. But uninstalling a template doesn't need special undo functionality. The user can re-install the original cgt file.

[hal-eisen-adfa]

Templates come from cgt files, not plugins.