assurance-looplisted

# assurance-loop — 保証キャンペーンの運転手順 開発専用スキル。規範は campaign 指示（CLAUDE.md 経由の会話）・ADR-114/115/116・ PROC-001・`assurance/README.md`・規範3冊（JERG=検証計画と証拠・STPA=創出・CAST=失敗後更新）。 ## 0. 前提確認（毎回・省略禁止） 1. セッション冒頭に「セッション開始（要点復唱）」の契約注入があるか。無ければ統治フックが 死んでいる（R11）。**報せたうえで止まる。**注入の無いセッションで統治木を編集しない （ガードもリンタも効いていない可能性がある）。レーンの読み取りだけなら続けてよい。 2. `git fetch origin` と open Issue / open PR / CI の再取得。過去の報告を現状として信用しない。 3. `python3 assurance/harness/doctor.py --json` — UNASSESSED ならレーン前提が欠けている。 SDK 実行はせず決定論試験だけで続行し、その旨を台帳と報告へ残す。 4. `python3 plugin/scripts/docs-audit.py --root doctrine_docs --json --today <今日>` — error か warn が 1 件でもあれば、他の何より先に扱う。**`--today` は必ず渡す** （渡さないと壁時計を読み、日付が変わっただけで結果が変わる。WATCH-001 第11項と同じ形）。 ## 1. 次にやることの正本 **手で選ばない。** `assurance/.venv/bin/python assurance/harness/orchestrator.py status` の `next_actions` が決定論で導く（ADR-115）。 **着手は先頭の一件から。** 一回の反復で何件消化してもよいが、飛ばしてはならない。 先頭を飛ばしたくなったら、それは正本の優先順が誤っている疑いなので、飛ばさずに 正本の側を直す（実際に INC-006・INC-012・INC-015 がその形で見つかった）。 優先の意味論: - 事象（incidents）の CAST_ANALYSIS が pending なら、それが新規 DISCOVER より先。 修正済みの欠陥も「なぜ既存の保証が見逃したか」の分析が済むまで閉じない。 - カタログが UNASSESSED / PARTIAL なら INGEST_NORMS（抽出・再開）。順序は jerg→stpa→cast。 - カタログが揃い網羅台帳が UNKNOWN のままなら MAP_COVERAGE（jerg レーンが doctrine の 現状と突き合わせ、五値へ割り当てる。証拠ポインタの無い「実装・試験・証拠あり」は書かない）。 ## 2. 状態機械（外側は決定論。LLM の気分で遷移しない） INGEST_NORMS → MAP_COVERAGE → DISCOVER → CHALLENGE → FORMALIZE → REPRODUCE_RED → FIX → VERIFY → ATTACK_EVALUATOR → RECORD → CURATE（正本: `harness/orchestrator.py`） - 状態は二つに分かれる（ADR-120）。**名指しさ