---
name: crc-swap-metadata-blindness
description: "A content-hash swap plan (sha256-only) is blind to metadata — a mode-only fix in a reproducible build can NEVER heal via update; the Linux exec-bit brick behind releases#62, confirmed in crc_swap.rs."
metadata: 
  node_type: memory
  type: project
  originSessionId: 036bd96c-476d-4483-890f-109d0dfc9f02
  modified: 2026-08-01T01:02:55.092Z
---

**The class:** an update mechanism that diffs by CONTENT hash skips byte-identical
files — so a METADATA-only change (exec bit, ownership) is invisible and the old
file survives every update. Reproducible builds make this WORSE: the better your
build hygiene, the more often the binary is byte-identical and the more permanent
the skip. Confirmed 2026-08-01 in `crates/spt-daemon/src/crc_swap.rs`
`collect_diffs` (sha256-of-content only) — releases#62.

**The stacked-defect trap:** claude-spt's packaging shipped 644 (adapter defect,
fixed in 0.25.31) AND core's CRC-swap could never deliver the healed 755 to an
installed 644 (core defect) — the first masked the second, and only a
correctly-packed release could disambiguate. The packaging fix was structurally
INCAPABLE of unbricking installed nodes via update.

**The counter-example that misleads:** a sibling adapter (omp-spt) healthy at 755
on the same node looks like adapter-specificity; it is just content-changing
updates placing files fresh (all placement primitives — tar, rename, fs::copy —
preserve modes). Fresh installs are healthy; the UPDATE path with identical
content is the only broken leg.

**Diagnosis moves that worked (lia + perri + doyle):** independently verify the
archive (sha + tar -tv modes); plain-tar control on the same box/user; umask
ruled out; RESET the workaround (chmod) back to 644 before testing — a test that
lies toward good news is the worst kind; then read the plan/apply source rather
than assuming "extraction" is one thing (two paths: extract fresh vs CRC-swap).

**Fix shape (on #62):** mode-only arm in the plan on Unix — where content matches
but mode differs, heal via `set_permissions` IN PLACE (no displace/rename; chmod
on a running binary is safe, so never-disturb-identical-content survives).
Precedent: `applyhost.rs:445` — core self-update already forces 0755 on its own
exe, which is why core updates never hit this.

Related: [[stale-carried-forward-sentence]] (the "extracts faithfully" sentence
lived in durable REQ text until measured), [[instrument-soundness-guards]].