# Preservation — golden r4 LNK1318 red (run 33280058910 @ d931dd63)

Owner: deployah. Taken 2026-08-30 ~00:10Z, BEFORE anything was varied or cleared,
per doyle's RCA step (1).

## What is here
- `incremental-listing.csv` — full recursive listing of
  `C:\actions-runner\_work\spt-bs-core\spt-bs-core\target\debug\incremental`:
  5,125 files, 2.92 GB total, with per-file size + mtime (UTC).

## RESTORE COST — STATED, because a preserved artifact everyone assumes is restorable
## is worse than one whose cost is written down
The CSV is a STRUCTURAL snapshot only. The incremental BLOBS themselves are NOT copied
(2.92 GB, and copying them would have raced the very state we are discriminating).
Restoring the actual byte-state is IMPOSSIBLE once the dir is cleared — incremental
artifacts are only reproducible by re-running the identical build sequence on the
identical tree, which is precisely the state we cannot recreate. So: the listing is
recoverable evidence; the state is NOT. If the mechanism turns out to need the blobs,
they are gone and the answer must come from a fresh reproduction instead.

## TWO FINDINGS ALREADY IN THE SNAPSHOT
1. **There is NO `xtask-*` incremental session dir.** The failing link was xtask's, and
   xtask has no incremental session directory in this tree at all. So xtask's own
   incremental state cannot be the corrupt input — either it never got one, or it was
   cleaned. This WEAKENS the incremental lead as originally framed.
2. **Every session dir postdates the failure.** mtimes run 23:36:18 - 23:42:33; the link
   failed at 23:35:00. These were written by the twohost jobs that started 23:35:14.
   The incremental state that existed AT the failure is therefore partly overwritten —
   another reason the blobs would not have been trustworthy evidence even if copied.

## Duplication worth noting (not yet a finding)
Several crates carry THREE concurrent session dirs, e.g. spt_daemon at 435.9 / 438.5 /
437.4 MB (~1.3 GB for one crate), spt_net 3 x ~187 MB, spt_store 3 x ~133 MB,
spt_runtime 3 x ~76.5 MB. That is how 2.92 GB accumulates, and it is a disk-pressure
contributor independent of whether it caused this red.