## TL;DR
The scan ran fine; the bookkeeping failed. The agent wrote its "done" marker somewhere the next run could not read (wrong volume, relative path, ephemeral container fs), so every run thought the image was unscanned. Write the marker to a shared, absolute, persistent path, write it only after a successful scan, and alert when any image gets scanned more than twice in a window.

```text
the agent's triage loop re-scanned the same image 12 times because the scan-complete marker was written to a path the next run couldn't read
```

## Use this when
- Scan counts per image climb while the fleet size stays flat.
- The agent logs "scan complete" but the next run scans the same image again.
- Marker files exist but in a different directory or container layer than the reader expects.

## Not for this skill when
- The scan itself hangs or OOMs. Fix the scanner first; markers cannot help a scan that never finishes.
- You need faster scans. That is sharding and caching, a different problem.

## Steps
1. Find both paths: where the writer puts the marker and where the reader looks. Verify: print both absolute paths from inside the actual runtime (not from your laptop).
2. Move the marker to a shared persistent location both runs can reach, e.g. a mounted volume or a small state table keyed by image digest. Verify: run twice; the second run logs "already scanned, skipping".
3. Write the marker only after the scan exits 0 and results are stored. Verify: kill a scan mid-run and confirm no marker is written and the next run retries it.
4. Key markers by image digest, not tag, so retags do not confuse the check. Verify: retag the image and confirm it is still treated as scanned.
5. Add an alert: more than 2 scans of the same digest in 24h pages the pipeline owner. Verify: trigger it once deliberately and confirm the alert fires.

## Variant phrasings
### scan-complete marker not found
The reader-side phrasing.
### triage loop rescanning same image
The symptom search.
### scan marker path mismatch
The root-cause phrasing.

Compatibility: applies to any marker scheme (files, SQLite, Redis, DB rows); the rule is always "writer and reader must share the exact key and location".

## Why it happens
Agents often run in fresh containers per invocation with relative working directories. A marker written to `./state/done` in run N lives in a filesystem that run N+1 never sees. The scan logic is correct; the state is not shared, so the loop can never converge.

## Edge cases / pitfalls
- Writing the marker before the scan finishes (optimistic marking) causes skipped scans after crashes; always mark after success.
- If the marker store itself is lossy (ephemeral Redis), the same loop restarts after every eviction; use persistent storage for completion state.
- Digest-keyed markers miss tag-level findings; store the tag alongside the digest for reporting, but dedupe on digest.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sCgg-rukN7yzWv9CbVeP4Q