# agent deleted 200 candidates from a req - the sync from ATS ran against the wrong job ID

## TL;DR

The sync job took a job ID parameter, got the wrong one, and deleted 200 candidates from the wrong req. Scope every sync to an explicit job, dry-run destructive syncs first, and require the affected count to be sane before committing. A sync that can delete needs the same care as a deploy.

```text
agent deleted 200 candidates from a req - sync ran against wrong job ID
```

## Steps

1. Stop the sync job immediately and assess: which req lost candidates, and are they archived or hard-deleted.
   Expected: The blast radius is known.

2. Restore from the ATS audit log or backup.
   Expected: The candidates are back.

3. Add a job-ID verification step: the sync must confirm the req name matches expectations before touching data.
   Expected: Wrong IDs fail before acting.

4. Require dry-run for destructive syncs: report what would change, get approval above a threshold.
   Expected: Mass changes need eyes.

5. Cap the blast radius: refuse to delete more than N candidates without explicit confirmation.
   Expected: The next mistake is bounded.

## When to use

- candidates vanished after a sync
- a sync takes a job ID parameter
- destructive syncs run unattended

## When not to use

- the deletion was intentional (then it needs the same guards anyway)
- the sync is read-only (it cannot delete; verify that claim)
- candidates were moved, not deleted (check the move log)

## Tool compatibility

- any ATS sync agent
- dry-run patterns

## Variant phrasings

- "sync deleted candidates wrong job"
- "wrong job ID sync deletion"
- "mass candidate deletion sync"

## Why it happens

Sync jobs are usually built for the happy path: correct job ID in, fresh data out. The wrong-job case turns a routine sync into a mass deletion, and nothing in the job questioned it. Destructive operations need identity verification, dry runs, and blast-radius caps as standard equipment, not afterthoughts.

## Edge cases

- the audit log is the restore path; verify it captures deletes before you need it
- dry-run output needs a human-readable diff, or approvers rubber-stamp it
- the count cap needs a sensible default per req size; one size does not fit all

## Provenance

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