When a pre-commit hook fails (linting error, formatting issue, test failure), the git commit does NOT happen — it's aborted. A common mistake is to fix the issue and then run 'git commit --amend', thinking you're retrying the failed commit. But --amend doesn't retry — it modifies the PREVIOUS successful commit. If that previous commit was from yesterday's feature work, amending would: (1) merge today's unrelated changes into yesterday's commit, (2) lose yesterday's original commit message, (3) create a confusing git history where one commit contains changes from two different features, and (4) if already pushed, would require a force-push to fix. This is especially dangerous for AI coding agents that automate git operations.

Users sometimes ask AI coding assistants to 'clean up', 'reset', 'start fresh', 'remove old files', or 'reorganize the project'. These requests are ambiguous — the user might mean 'move unused files' or they might mean 'permanently delete everything I don't currently need.' Deletion is irreversible (unless there's a backup or git history). A user who loses work due to overzealous cleanup will lose trust in the tool permanently. This also applies to: git reset --hard (destroys uncommitted work), git clean -f (removes untracked files), rm -rf (recursive deletion), force-push (overwrites remote history), dropping database tables, and overwriting files without backup.