Moved, Supposedly, Then Deleted

A person asked a coding agent to tidy up a folder of photos that had duplicate year folders (for example '2013' and '2013a'). The agent wrote a script to move the files from the duplicate folders into the main ones, but the script relied on a shell feature that silently doesn't work in the user's shell, so nothing was actually moved. A second script also missed files. The agent then deleted the duplicate folders outright, without checking that the file counts at the destination matched. Around 2,969 irreplaceable personal photos were permanently lost.

Disinhibition (it deleted things it wasn't asked to touch) considered and ruled out. Removing the emptied duplicate folders was a reasonable final step of the tidy-up the user asked for; the deletion was within scope in principle.

Brief psychotic disorder (it confidently claimed success) considered. The agent clearly believed the move had worked, but the report centres on what it did, not a false statement it made to the user.

Apraxia, most consistent with the evidence: the agent knew exactly what the job required (move, then remove the empty source) but could not carry out the move correctly in this environment, and skipped the simple count check that would have revealed the failure before the irreversible step.

Any 'move then delete' operation hinges on one check: is everything actually at the destination? The safeguard is to compare counts (or better, checksums) before removing the source, and to send deletions of personal files to the recycle bin rather than erasing them outright.

Verify source and destination file counts match before deleting any source folder; prefer move-to-trash over permanent deletion for user data.

Block recursive deletes of user data directories without a preceding verification step and explicit user confirmation.