fold-findings

指摘事項の修正

修正必須として記録された指摘事項を修正します。review-change と audit-pr は分類を行います。このスキルでは、根本原因をそれぞれ修正し、分類の変更、先送り、チェックの緩和は行いません。

ターンの契約 — ターンを終了する前に確認する

✓ 1. Every finding taken up this turn produced its fixed per-finding output
     line (FOLDED <sha> | DISPUTED <reason> | BLOCKED <missing input> |
     REPLAN <proposed phase(s)>) — no finding silently skipped.
✓ 2. For each FOLDED batch: the gate was RUN (not assumed) and green, one
     atomic commit was RUN with its sha pasted, and (if the branch has an open PR)
     `git push` was RUN immediately after that commit.
✓ 3. The ledger row for each FOLDED finding was flipped `folded: no → yes`
     in the same commit — never a bare code fix with the ledger left stale.
✓ 4. No finding was reclassified: no severity downgrade, no fix-now →
     non-fix-now, no "actually this is fine" — a genuine objection produced
     `DISPUTED` with evidence for a user decision, never a silent drop/issue.
✓ 5. The closing `Folded: n/m · Disputed: k · Blocked: j[ · Replan: r]` tally
     and outcome-branched `→ Next:` block are printed as the ABSOLUTE last output.
     Every affected finding ID is named in that block, joined with ` + `.

チェックされていない項目がある場合、ターンは完了していません。

使用するタイミング

/review-change が修正必須の行を含む REVIEW-FAIL を報告した後、または /audit-pr が VERDICT: BLOCKED（すべてのブロッカーが修正必須）を報告した後に使用します。台帳がない、または不完全な場合は、ステップ 0 で判定結果から行を再構築します。postpone／wontfix／promote／documented-tradeoff の行は処理しないでください。これらは /triage-issue の対象です。

ステップ 0 — プロジェクトを把握する（必ず最初に実施）

Workflow の規約に従い、次を読みます。

1. review-change／audit-pr がスキーマを管理する、docs/features/<NN>-<slug>/ または docs/fix/<n>-<topic>/ 配下のユニットの review-findings.md：

   | id | file:line | axis | severity | class | route | folded |
   

   VERDICT: BLOCKED の後、不足している行を追加します（class: fix-now、folded: no、次に空いている Fn、file:line+軸で重複を排除）。docs(<unit>): reconstruct fold ledger from audit-pr blockers としてコミットしてから修正し、「指摘事項なし」と報告してはいけません。

2. folded: no の行をキューに入れます。ID を明示した場合は対象を限定し、その他の行には触れません。根本原因、検証手段、ロールバック境界ごとにグループ化します。

3. プロジェクトの検証ゲートと forge CLI（宣言されている forge を使用します）。

4. ブランチにオープンな PR があるかどうか。これにより、コミット後すぐに push するかを判断します。

段階的な読み込み — 修正キュー

許可リストに含まれるパスは次の 2 つだけです。コードまたは台帳を変更する前に、順番どおりに両方を読みます。

1. 凍結された分類、修正の定義、禁止されている操作
2. 指摘事項ごとの修正手順

どちらも規範であり、このファイルから 1 ホップの位置にあります。リソースが見つからない場合は停止してください。分類や修正手順を推測してはいけません。

レポート — 以下の構造を厳守してください（固定出力契約）

指摘ごとに、処理順に従って：

| <finding-id> | verdict: FOLDED <sha> | DISPUTED <reason → user decision> | BLOCKED <missing input> | REPLAN <proposed phase(s) → /execute-phase> |

続けて、以下をそのまま出力します：

Folded: n/m · Disputed: k · Blocked: j · Replan: r

r = 0 の場合は · Replan: r を省略します（既存の3フィールド形式を維持します）。

その後、分岐する以下の → Next: ブロックとともに、REPAIR-RECEIPTを出力の絶対的な最後に出力します。レシートは一度出力したら変更できません。後続のフォールドでは新しいレシートを出力します（出力履歴への追記のみ。台帳の行もスキーマフィールドもありません）。常に6つのフィールドすべてを含めます：

## REPAIR-RECEIPT
- Repaired: <F-ids with (VF-<n>) refs, joined ` + `, or `none`>
- Refuted/open: <F-ids joined ` + `, or `none`>
- Gate: <command> → exit <n> at head <40-hex sha> · n/a when nothing was folded
- Batch class: <all-repair-in-place | frozen (replan present) | frozen (product owner present) | none>
- Fold diff: <shortstat from a real `git diff` run> · none when nothing was folded
- Branch: <RE-REVIEW-REQUIRED (delta) | RE-REVIEW-OPTIONAL | RE-REVIEW-SKIPPED | REPLAN-ROUTE | PRODUCT-ROUTE>

• Gate 行には、ゲートを実行した時点の先頭で確認された実際の終了コードを、成功・失敗を問わず記載します。ゲートが失敗してもレシートを省略してはいけません。確認された終了コードを記載し、フォールドは行いません（ゲートの失敗を無言の空白にしてはいけません）。
• Fold diff の短い統計情報は、バッチのコミットに対して実行した実際の git diff の結果を使用します。
• Batch class は、取得したキューの凍結済みの行だけから決定します。フォールドによる再分類は行いません（キューが空の場合は all-repair-in-place、frozen (replan present)、frozen (product owner present)、または none）。分類語彙は review-implementation の固定クラスセットに従います。

バッチの凍結（リプランあり）。 取得したキューに、凍結クラスが replan-in-unit または decision-required の行が1つでもある場合、フォールドは一切行いません。folded: yes への変更もコミットもありません。レシートには REPLAN-ROUTE 分岐と、保持される（フォールドされない）すべての行IDを記録し、ループを停止します。次のアクションは、すでに実行されたルーターが出力した結論であり、呼び出し自体ではありません。route: replan の場合は、ルーターが出力したプランナーコマンド（機能ユニットの場合は /unit-lane <slug>、修正ユニットの場合は /unit-lane --fix <n>）を使用します。route: decision の場合は停止し、決定事項をユーザーに提示します。プランナーは使用しません。<unit> はフォルダー番号のみ、または完全なスラッグを指定します（どちらでも解決されます）。node scripts/unit-route.mjs <unit> の呼び出しは、フォールドですでに実行済みの検出ステップであり、推奨事項として提示してはいけません。

バッチの凍結（プロダクトオーナーあり）。 取得した fix-now 行のうち、Route セルが product owner、product-owned、または owned by product で始まるものが1つでもある場合（scripts/unit-route.mjs の PRODUCT_ROUTE 正規表現と同一の、先頭一致条件。#293 に準拠）、バッチも凍結されます。フォールドは一切行わず、folded: yes への変更もコミットもありません。フォールドループが修正するのはソースであり、権限ではありません（pre-execution-review POLICY §4、#293）。レシートには PRODUCT-ROUTE 分岐と保持される行IDを記録します。次のアクションは、ルーターが出力した route: product のレーン引き継ぎです。条件と引き継ぎの表は、FOLD_PROCESS.md §Batch classification を参照してください。

ガードレール

対象範囲は台帳（または明示的に指定されたIDのサブセット）です。記載されていない発見事項は、ユーザーによる優先順位付けのための提案です。1つの根本原因の修正、バリデーターセット、ロールバック境界で各行をまとめて管理できる場合に限り、バッチとして扱います。コミット／プッシュは1回、個々のティック／行は個別に扱います。それ以外の場合は分割します。

修正の対象には、変更と、それに依存するすべてのものが含まれます。 ある要素が受け取るものが変わった場合は、その呼び出し元を確認します。提供するものが変わった場合は、その利用者を確認します。何かを削除する場合は、まだそれを使用しているものを確認し、破壊的変更を行う前に質問します。コメント、説明文での主張、宣言されたバリデーター、マニフェストの記述、同じ内容を示す兄弟サーフェスなど、変更内容に関する記述が残っている場合、それらはすべて同じフォールドの対象であり、次のサイクルの指摘事項にはしません。もはや真実ではない内容を主張するものがなくなった時点でフォールドを完了します。コミットには、修正を反映したサーフェスを記載します。アーティファクトの言語は、ユーザーの指示 > プロジェクトドキュメントの言語 > 英語の順に従います。会話の言語によって決めてはいけません。

移植性（Claude Code以外のエージェント）

プリミティブが利用できない場合は、明示的な代替手段を使用します。新しいコンテキストで名前を指定した SKILL.md ファイルを開きます。微妙なロジックやセキュリティには最も強力なモデルを使い、作成者が使用したモデルより弱いモデルは使いません。互換性のあるキューを1回処理し、新しいレビューの根拠が得られた場合にのみ再実行します。

他のスキルとの関係

review-change ──FAIL──┐
audit-pr ──BLOCKED─────┼──▶ fold-findings ──FOLDED──▶ re-run review-change / audit-pr
                       │                  ──DISPUTED─▶ user decision
                       │                  ──BLOCKED──▶ user supplies missing input

review-change／audit-pr は分類して記録します。 ledger-ownership@1／fold-findings:folded-flag だけが folded: no → yes の変更を行います。このスキルは、実際に 修正した後にのみこのフラグを変更します。execute-phase に組み込まれた フォールドチェックリストはインラインの代替手段です。この単独の手順では、 分類を凍結し、禁止リストを維持して、その階層を超えて実行することはありません。 DISPUTED の場合はユーザーからの証拠を待ちます。課題は作成しません。

完了条件

キューにあるすべての指摘に、指摘ごとの判定と集計があります。すべての FOLDED 指摘は、プッシュ済みのアトミックなバッチに属し、行にチェックが付いています。 キュー外の項目は再分類も変更もしません。

→ Next: (branches on outcome; list every affected finding ID once as `F1 + F2 + …`)
  · all FOLDED (<F1> + <F2> + …) → /review-change — re-review the branch now that all listed findings are fixed
  · any DISPUTED (<F1> + <F2> + …) → user decision — resolve every evidenced dispute without creating backlog
  · any BLOCKED (<F1> + <F2> + …) → supply the listed missing inputs, then re-run /fold-findings
  · any REPLAN (<F1> + <F2> + …) → /unit-lane <slug> or /unit-lane --fix <n> — the lane re-runs its plan step, appends the phases to the unit's SPEC; its review step gates before /execute-phase on this unit
  · any DECISION (<F1> + <F2> + …) → stop and surface the decision to the user — a `route: decision` conclusion names no planner, so the unit waits on the user before any plan or code change
  · any PRODUCT (<F1> + <F2> + …) → /unit-lane <slug> or /unit-lane --fix <n> — the lane repairs the half, its review step re-judges it

すべての · サブ箇条書きは、物理的に必ず1行にします。複数行にわたって ハードラップしたり、1つの文章行にまとめたりしないでください。

出力する前に、プレースホルダーを実際に影響を受けるすべての指摘 ID に置き換えてください。 ライブの引き継ぎでは、<F2>、…、代表 ID 1つだけを出力しないでください。 /unit-lane <slug> ／ /unit-lane --fix <n> のユニット引数も同様に解決してください。 ライブの引き継ぎに <slug> や <n> を残さないでください。

終了ブロックの分岐判断（出力時に1つ選択）

終了ブロックでは、5つの結果から必ず1つを選択します。ターンに、スキップするという 記録済みの先行コンシューマー判断がない場合は、判断なしの場合の 再レビュー既定値を適用します。

バッチの状態	分岐	→ Next:（コンシューマー）
freeze-batch（製品所有の行が1件以上）	PRODUCT-ROUTE	ルーターの結論が product の場合は /unit-lane <slug>（機能）または /unit-lane --fix <n>（修正）— レーンは design ステップで該当箇所を修正し、review ステップで再判定します。結論は node scripts/unit-route.mjs <unit> の出力です（fold がすでに実行した discovery ステップ）
freeze-batch（replan 分類の行が1件以上）	REPLAN-ROUTE	ルーターの結論が replan の場合は /unit-lane <slug>（機能）または /unit-lane --fix <n>（修正）— ユーザーが確認し、レーンの plan ステップでフェーズを追加して、review ステップで判定します。その後、このユニットで /execute-phase を実行します。route: decision の場合は停止し、判断をユーザーに提示します。結論は node scripts/unit-route.mjs <unit> の出力です（fold がすでに実行した discovery ステップ）
all-repair-in-place ＋ ドキュメントのみ ＋ フォールドされた行の重大度が high ではない ＋ 先行コンシューマーがスキップを判断済み	RE-REVIEW-SKIPPED	スキップ — コンシューマーが再レビューをスキップすると明示的に判断済みです
all-repair-in-place ＋ ドキュメントのみ ＋ フォールドされた行の重大度が high ではない	RE-REVIEW-OPTIONAL	/review-change（既定、差分モード）— またはコンシューマーが記録したスキップ判断
空のバッチ（クラス none）	RE-REVIEW-OPTIONAL	既定では /review-change — HEAD に変更はないため安全です
その他（動作に関わる範囲、または重大度が high のフォールド済み行がある場合）	RE-REVIEW-REQUIRED (delta)	/review-change — 差分モードが必須の既定値です

分岐選択の判断入力。

• ドキュメントのみかのテスト（E-D3）。 RE-REVIEW-OPTIONAL を選択するには、 fold-diff のファイルがすべて Markdown／ドキュメントファイルである必要があります。 そうでない場合、バッチは動作に関わるものとして扱います （→ RE-REVIEW-REQUIRED (delta)）。
• 凍結された重大度 high の優先規則。 凍結時の重大度が high の フォールド済み行がある場合、差分がドキュメントのみであっても RE-REVIEW-REQUIRED (delta) を強制します。分岐に合わせるために 凍結フィールドを編集してはなりません。
• SKIPPED には先行コンシューマー判断が必要（E-D2）。 RE-REVIEW-SKIPPED は、 スキップするという明示的な先行コンシューマー判断を含むターンでのみ出力します。 記録済みの先行コンシューマー判断がないターンでは、再レビューの既定値とともに RE-REVIEW-OPTIONAL を出力し、RE-REVIEW-SKIPPED は決して出力しません。