windows-safe-cleanup-recovery

name	windows-safe-cleanup-recovery
description	Use for conservative Windows cleanup, duplicate cleanup, cache cleanup, C/D drive migration, or recovery after a cleanup breaks tools; emphasizes scan-first evidence, keep-side confirmation, backups, skip-on-failure deletion, and log-backed path recovery.

Windows Safe Cleanup Recovery

Core Workflow

1. Scan and report before modifying anything.
2. Confirm the keep/delete side for duplicate or cross-drive cleanup.
3. Back up or export evidence before moves, deletes, registry edits, or path rewrites.
4. Prefer narrow, named targets over broad cleanup patterns.
5. Delete or move with skip-on-failure behavior; do not force through locked or unclear files.
6. Stop further modification immediately if the user reports breakage.
7. Recover original paths from logs, shortcuts, registry entries, or app metadata before guessing.

Common Scenarios

• Duplicate cleanup across C and D drives: hash first, group candidates, confirm which drive to keep, then delete only verified duplicates.
• Cache cleanup: distinguish disposable caches from app state, IDE settings, indexes, plugins, credentials, and runtime configs.
• Tool breakage after cleanup: stop cleaning, inspect logs, recover install path, and restore or repair the minimum needed files.
• Original install path request: answer with a path backed by evidence such as logs, registry, shortcuts, or process metadata.
• Large directory cleanup: produce a candidate list with sizes, owners, and risk notes before deletion.

Decision Rules

• Treat "safe cleanup" as evidence gathering plus reversible action.
• Do not delete development tool state, user configs, model weights, datasets, or project folders unless explicitly requested.
• Do not use git reset --hard, broad registry replacements, or recursive deletes as shortcuts.
• When deletion fails because a file is locked, switch to lock diagnosis or a reboot-time plan instead of repeated force attempts.
• Keep a log of what was changed and what was skipped.

Verification

• The scan output matches the intended target scope.
• The keep/delete direction was confirmed or safely inferred from the user's explicit instruction.
• Backups or restore evidence exist for risky changes.
• Deleted files are limited to verified candidates.
• Skipped locked or unclear files are listed.
• If repairing a broken tool, the final answer cites the evidence used to identify the working path.