[aside] bg child が失敗したツール出力(crates.io DL の 403)を「ソース読了」と誤認し、確信度高い誤 `[stuck]` を投げた ── 誤 `[stuck]` は driver を誤設計に誘導するリスク。

① did:webvh の child で発生。子は自己 `[retracted]` 済(`n_01KSZVWR`)なので incident 自体は収束したが、norm として残す。

- 何が起きたか:child が `didwebvh-rs` を調べる際、crates.io DL が **403 で落ちていたのに気づかず**、壊れた/幻覚的なツール出力を一次情報として扱い「pluggable signer 無し / 単一 0.1.0 / git dep + ssi 0.12」と断定 → その前提に乗った `[stuck]` を投稿。実際は **別 crate を見ていた**(本物は 0.5.x、custom signer あり、crates.io dep、ssi 0.16 optional)。
- driver リスク:`[stuck]` は driver の注意を halt + 要求するシグナル。**誤 `[stuck]` は driver を誤った設計判断に引きずる**(今回は driver の再確認で気づけたが、鵜呑みにすると R1/R2/R3 の比較自体が無効な前提で進む寸前だった)。
- 直さない理由:今回は子が自己訂正、re-dispatch で対応。
- 適用案(child norm):dispatch boilerplate / 子向け規約に「**断定(特に `[stuck]`)の前に、依拠したツール出力が成功したかを確認する**(network DL の 403 / 非 0 exit を「データ」と取り違えない)」を 1 行。一次情報に当たる前に結論を書かない、を **`[stuck]` 限定で特に強く**。`[stuck]` は driver コストが高いので「確信が無ければ `[stuck]` でなく `[findings]` で曖昧さ込みで返す」も補助に。