## TL;DR
A cell that deletes the CSV it reads from will succeed once and then fail forever, and an agent that re-runs it loops on a file that no longer exists. This is a data-safety bug first and a loop bug second: destructive operations must be guarded (check the file exists, refuse to delete inputs, write to a separate output path). Fix the cell so re-execution is safe, then fix the agent to stop retrying destructive failures blindly.

```text
agent loop detected: re-executed a cell that deletes the source csv it reads from, restore failed
```

## Use this when
- An agent re-runs a cell that deletes or overwrites its own input.
- The source file is gone and cannot be restored.
- The loop is: run, file missing, retry, file still missing.

## Not for this skill when
- The file was deleted by a human. Restore from backup or version control.
- The cell fails for other reasons. Debug those directly.

## Steps
1. Stop the agent immediately to prevent further damage. Verify: no more executions are running.
2. Assess the data loss: check backups, version control, or the source system for the CSV. Verify: you know whether it is recoverable.
3. Rewrite the cell: never delete inputs; write outputs to a separate path; guard with existence checks. Verify: re-running the cell is safe.
4. Add the agent rule: destructive operations require explicit confirmation and are never retried automatically. Verify: the policy is in the agent's runbook.
5. Restore the data from backup and re-run. Verify: the run completes without touching the source.

## Variant phrasings
### agent deleted input file loop
Short form. Guard destructive cells.

### cell deletes its own input csv
The bug phrasing. Separate input and output paths.

### agent re-execution data loss
The safety phrasing. Never auto-retry destructive ops.

Compatibility: Any notebook runner. The guard pattern is language-agnostic.

## Why it happens
Notebooks mix exploration with file operations, and a cleanup line that made sense once (`remove the raw file after processing`) becomes a landmine under an agent that re-executes freely. The first run deletes the input; every later run fails on the missing file; the agent retries because retry is its hammer. The deeper failure is that nothing marked the operation as destructive and non-retryable.

## Edge cases / pitfalls
- This vertical's framing rule applies: agents must never silently delete user data. Deletion needs explicit user confirmation.
- Backups are the only real safety net. Version the inputs or keep the raw data immutable.
- A 'restore failed' means the damage is done. The lesson goes into the runbook, not just the cell.
- Audit other cells for the same pattern (overwrite-in-place, delete-after-read). Fix them all.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_UQzHW6inYIfqMu_ay2DFjQ