ds-unstick

ds-unstick

2 つの修正が同じように失敗する場合、問題はたいてい編集内容ではなく、誤った思い込みにあります。その思い込みを見つけて検証してください。

手順

1. 編集を中断します。同じ修正の 3 つ目のバリエーションは試さないでください。
2. 失敗した試行をそれぞれ 1 行で書き出します。変更内容と結果を記載してください。正確なエラーテキストも含めます。
3. すべての試行に共通していた前提を書き出します。典型的な例：「このファイルが実行される」「設定が読み込まれている」「関数は文字列を受け取る」「キャッシュはクリアされている」「エラーは自分のコードに起因する」。1 つを選び、1 文で示します。
4. はい／いいえで答えがわかる、最も手軽な調査方法でその前提を直接検証します。print 文、ログ行、which や --version、実際の呼び出し箇所を探す grep、最小限のスクリプト、またはインストール済みの正確なバージョンに対応するドキュメントの確認などが使えます。結果を貼り付けます。
5. 前提が誤りなら、真の問題が見つかったことになります。新たにわかった事実に基づいて修正を計画します。
6. 前提が正しければ、異なるアプローチを 3 つ挙げます。「異なる」とは、同じ編集への微調整ではなく、別の仕組み、ライブラリ、レイヤー、またはデータ経路を意味します。それぞれについて、コストとリスクを 1 行で示します。
7. アプローチを 1 つ選び、その理由を 1 文で述べます。
8. 失敗した試行の痕跡が残っている場合は、クリーンな状態から再開します。git（git stash または git checkout -- <files>）でそれらを元に戻し、選んだアプローチだけを適用します。
9. 後のセッションで同じ試行が繰り返されないよう、誤った前提または選んだアプローチを PROGRESS.md に記録します（ds-context-reset を参照）。
10. 新しいアプローチで ds-verify-loop に戻ります。

中止する条件

• 手順 4 の調査で失敗の原因が明らかになった場合、または新しいアプローチが検証に合格した場合。
• このスキルを 2 ラウンド実行しても失敗した場合は中止し、試したこと、検証した前提、得られた証拠をユーザーに報告します。指示を求めてください。

ルール

• 小さな変更を加えた場合も含め、すでに失敗した修正を繰り返さないでください。
• 推論より証拠を優先します。調査に 1 分かかるなら、実行してください。
• 失敗した試行の一覧は残してください。報告において最も役立つ情報です。
• 新しいアプローチを試す前に、クリーンな状態にしてください。古い編集によって結果がわかりにくくならないようにします。