git submodule deinit wipes working tree without warning or checking for local changes

Bug

Claude ran git submodule deinit -f <path> followed by git rm when asked only to remove the submodule reference. This wiped the entire working tree of the submodule, including:

• Uncommitted local changes (the submodule showed as M in git status before the operation)
• Local IDE settings and other gitignored files that only existed on disk

Expected behavior

Before running git submodule deinit, Claude should:

1. Check git -C <submodule-path> status for uncommitted changes
2. Check for gitignored files worth preserving (IDE settings, etc.)
3. Warn the user and ask for confirmation if anything would be lost
4. Default to git rm only (removes submodule tracking, leaves working tree intact) unless the user explicitly asks to clear the directory

Actual behavior

Claude ran git submodule deinit -f <path> && git rm -f <path> immediately, clearing the working tree without any prior check or warning. The user had asked only to "remove webapp as a submodule" — not to delete the local files.

Impact

• Lost uncommitted local changes (unrecoverable)
• Lost gitignored local files (IDE project settings — unrecoverable)

Suggested fix

Treat git submodule deinit as a destructive operation requiring the same caution as rm -rf. Always check for local state first and confirm with the user before proceeding.