Spun out of the durability-soundness re-audit (nit 4 on #120).
offload evaluates the durability gate per file and reports OutcomeNotDurable for any file a required target does not cover. That is the right behavior when durability is genuinely pending. But if a required target is structurally incapable of ever producing a gating component, every file reports not-durable forever with no hint that the policy itself is the problem.
The concrete case: a path-mirrored rclone target forced shallow (size+mtime, never blake3) over an encrypted overlay that exposes no content hash, with no fingerprint path to upgrade it. Such a target advances its vector only with a non-content-verified method and can never be upgraded by a scan-back fingerprint, so the method condition refuses it permanently — but silently, per file.
Proposed: at offload start, before walking candidates, check each required target's configured capability and fail fast with a clear message — e.g. offload_requires target X can never satisfy the gate (shallow path-mirrored, no content verification) — rather than reporting not-durable per file forever.
Deferred from #120 because it needs cross-cutting config analysis (destination type, shallow forcing, crypt overlay, fingerprint capability) rather than a localized gate change. Pure UX/fail-fast surface; it does not affect gate soundness (the gate already refuses correctly — it just doesn't explain why).
Spun out of the durability-soundness re-audit (nit 4 on #120).
offloadevaluates the durability gate per file and reportsOutcomeNotDurablefor any file a required target does not cover. That is the right behavior when durability is genuinely pending. But if a required target is structurally incapable of ever producing a gating component, every file reports not-durable forever with no hint that the policy itself is the problem.The concrete case: a path-mirrored rclone target forced shallow (size+mtime, never
blake3) over an encrypted overlay that exposes no content hash, with no fingerprint path to upgrade it. Such a target advances its vector only with a non-content-verified method and can never be upgraded by a scan-back fingerprint, so the method condition refuses it permanently — but silently, per file.Proposed: at offload start, before walking candidates, check each required target's configured capability and fail fast with a clear message — e.g.
offload_requires target X can never satisfy the gate (shallow path-mirrored, no content verification)— rather than reporting not-durable per file forever.Deferred from #120 because it needs cross-cutting config analysis (destination type, shallow forcing, crypt overlay, fingerprint capability) rather than a localized gate change. Pure UX/fail-fast surface; it does not affect gate soundness (the gate already refuses correctly — it just doesn't explain why).