Problem (friction log F13 + F29, both S1 — confirmed live)
Two defects that together make offload unreachable against packed/CA offsites:
F13 — the pending-pack gate is per-run, not per-state. packedHandler.certifyPacked holds the vector only when this run's packs are unverified (verified < len(writes)). Run A packs content, capture fails → correctly held. Run B packs nothing → guard vacuously passes → AdvanceDestinationVectorTo covers the whole volume, including content reachable only through run A's still-pending pack. Conversely, once squirrel verify fills the pending fingerprints, nothing re-advances until the next content-writing sync — observed live as verify reporting everything clean while the vector stayed empty for many cadence ticks.
F29 — the component method is never upgraded. Packed/CA components are written and relayed as verify_method=presence+size forever, and the offload gate — correctly fail-closed — refuses non-content-verified methods:
s3archive2: not content-verified (method "presence+size", asserted by peer nas); a verified fingerprint must back the object before offload.
Combined with mirrors producing no evidence (F21) and receive-only nodes being unable to credit their upstream peer, every gate path in the reference household is closed (only kopia-verify and peer-blake3 are acceptable today).
Decision (Martin, 2026-07-24 — option 1b)
A verified provider-side fingerprint chain (local BLAKE3 at upload → provider checksum of stored bytes confirmed at rest) counts as content-verified for the gate, but only while the destination has a scheduled verify cadence configured (#154), so the evidence keeps being re-confirmed for as long as deletions are permitted.
Plan
- Gate the advance on zero pending artifacts for the (volume, destination) pair, not this run's writes.
- When capture or a verify pass leaves the pair fully fingerprint-verified, upgrade the component to a new
fingerprint-verified method (and re-attempt the advance at that moment, fixing the verify-then-stuck side of F13). The method relays over the durability pull like any other (syncproto already carries verify_method verbatim).
- Gate acceptance of
fingerprint-verified additionally checks the destination's verify cadence per the decision (for relayed components, the responder's cadence — relay it, fail closed when absent, mirroring how verified_at_ns relays).
- Regression tests for both F13 sides + the method upgrade + cadence coupling.
Depends on #154. Related: #129 (real-backend shakedown consumes this), #145 (peer-relayed capability fail-fast).
See design/friction-log.md F13/F29 for the full live evidence.
Problem (friction log F13 + F29, both S1 — confirmed live)
Two defects that together make offload unreachable against packed/CA offsites:
F13 — the pending-pack gate is per-run, not per-state.
packedHandler.certifyPackedholds the vector only when this run's packs are unverified (verified < len(writes)). Run A packs content, capture fails → correctly held. Run B packs nothing → guard vacuously passes →AdvanceDestinationVectorTocovers the whole volume, including content reachable only through run A's still-pending pack. Conversely, oncesquirrel verifyfills the pending fingerprints, nothing re-advances until the next content-writing sync — observed live as verify reporting everything clean while the vector stayed empty for many cadence ticks.F29 — the component method is never upgraded. Packed/CA components are written and relayed as
verify_method=presence+sizeforever, and the offload gate — correctly fail-closed — refuses non-content-verified methods:s3archive2: not content-verified (method "presence+size", asserted by peer nas); a verified fingerprint must back the object before offload.Combined with mirrors producing no evidence (F21) and receive-only nodes being unable to credit their upstream peer, every gate path in the reference household is closed (only
kopia-verifyandpeer-blake3are acceptable today).Decision (Martin, 2026-07-24 — option 1b)
A verified provider-side fingerprint chain (local BLAKE3 at upload → provider checksum of stored bytes confirmed at rest) counts as content-verified for the gate, but only while the destination has a scheduled verify cadence configured (#154), so the evidence keeps being re-confirmed for as long as deletions are permitted.
Plan
fingerprint-verifiedmethod (and re-attempt the advance at that moment, fixing the verify-then-stuck side of F13). The method relays over the durability pull like any other (syncprotoalready carriesverify_methodverbatim).fingerprint-verifiedadditionally checks the destination's verify cadence per the decision (for relayed components, the responder's cadence — relay it, fail closed when absent, mirroring howverified_at_nsrelays).Depends on #154. Related: #129 (real-backend shakedown consumes this), #145 (peer-relayed capability fail-fast).
See
design/friction-log.mdF13/F29 for the full live evidence.