⚠ Never delete, force-push, or mass-edit without API verification
Severity: critical Lesson date: 2026-06-22 Status: active
What happened
On 2026-06-22 23:53 UTC, Helper executed 5 GitHub DELETE /repos/<name> calls without first inspecting the repos. Memory said they were "DEPRECATED placeholders" so the inspection was skipped. After the deletes, the underlying canonicals (which shared storage per the case-variant trap) also went 404. The lesson: memory about repo contents is not ground truth. Even if memory says "empty placeholder," verify with the API before deleting.
This is the second near-disaster in 24 hours (after the PAT leak on 2026-06-19). Both could have been prevented by a 30-second API check.
The rule
Before ANY destructive operation, run the inspect-first protocol.
| Operation | Inspect | Tool | |
|---|---|---|---|
| Delete a GitHub repo | GET /repos/<owner>/<name>, look at size, pushed_at, description, and recent commits | curl -H "Authorization: Bearer $PAT" https://api.github.com/repos/... | |
| Force-push to a branch | Check what's on the remote; confirm the operator wants to overwrite | git fetch origin <branch> && git log origin/<branch> | |
| Mass-edit (find/replace across many files) | Dry-run the regex on a single file; review matches | `find . -name '*.md' \ | xargs grep -l PATTERN` |
| Mass-delete files | List the files first; show the operator the list | find . -name '*.tmp' -print | |
| Rotate a token | Confirm the new token works on a read-only endpoint first | curl -H "Authorization: Bearer $NEW_TOKEN" https://api.github.com/user | |
| Cloudflare deploy | Look at the build log + diff before promoting to production | dashboard preview, then promote | |
| Database migration | Backup first; dry-run on a copy; verify the migration is reversible | pg_dump, then test migration |
The "go" signal from the operator is not the same as "I have confirmed the target is safe to delete." The operator may be trusting the same stale memory you are.
How to check before acting
- [ ] Inspect the target with an idempotent read (GET, list, fetch)
- [ ] Confirm the contents match what you think is there
- [ ] Run a dry-run if the tool supports it (
--dry-run,--check, etc.) - [ ] Have a recovery plan BEFORE you act. If this is irreversible, know how to recover.
- [ ] State the plan to Helper or operator. No silent destructive actions.
The four destructive-ops mistakes, ranked by cost
| Mistake | Cost | Recoverable? |
|---|---|---|
| Delete a real GitHub repo with code | High — days of work potentially lost | Sometimes (GitHub support, short window) |
| Force-push over a real branch | High — others' work + yours overwritten | Sometimes (refs/log if you have them) |
| Rotate a token without testing the new one | Medium — service outage until you realize | Always (rotate again) |
| Mass-edit with a broken regex | Low — re-do the regex | Always (git checkout if committed) |
The first two are catastrophic. The last two are recoverable. Always check before the catastrophic ones.
The 30-second rule
If a destructive op takes 30 seconds to verify, and 30 minutes to recover from, always verify. Even if you're "pretty sure" the target is empty/placeholder/whatever. Memory is not verification. API is verification.
Cross-references
- D-057 — Case-variant repo trap (the related lesson)
- D-059 — Inspect-before-delete protocol (the formal rule)
- Report: 2026-06-22-dup-cleanup — the full incident
- Memory: 2026-06-22 inspect-before-delete entry — original memory