Ratchet — 学びを恒久化する
/debug は、バグを直した後に Generalize で「同じパターンが他にないか」を探しました。ここで止めると、学びはその場限りで消えます。Ratchet（ラチェット） は、その学びを仕組みに変えて、同じ失敗を構造的に繰り返さなくする流れです。
ラチェットという比喩
ラチェットは、一方向にだけ回る歯車です。締めた分は緩まない。ハーネスにおける Ratchet も同じで、「一度学んだことは、次から自動で守られる状態にして、後戻りさせない」ことを指します。
/debug のワークフローには、この判断が組み込まれています。Generalize で同パターンのバグが見つかった、あるいは再発の可能性が高いと判断したとき、「これを恒久化するか？」を問います。
今回のバグパターンを Ratchet 化しますか？
- rules への規範追加 … 文章の規範として rules/*.md に書く（Inferential Guide）
- hook 追加 … hook で決定的に強制する（Computational）
- fitness function 追加 … 構造的な制約として検出する
- learnings 記録のみ / skip … 再発確率が低ければ記録だけ
どの昇格先を選ぶか
選択肢は、Guides と Sensors の十字分類と対応しています。「再発したときの被害」と「誤検出のしにくさ」で選びます。
| 昇格先 | どんな学びに向くか | 分類 |
|---|---|---|
| rules への追加 | 判断を伴い、機械では検出しづらい規範 | Inferential Guide |
| hook 追加 | パターンが明確で、機械的に検出できる失敗 | Computational |
| fitness function | 依存方向や構造の制約（アーキテクチャ違反など） | Computational |
| learnings のみ | 再発確率が低い、または一回性の気づき | 記録 |
たとえば「array[0] を素で返してクラッシュ」が頻発するなら、lint ルールや hook で検出できそうです（Computational に昇格）。一方「この API は事前に状態を確認してから呼ぶ」のような判断を伴う規範は、文章で rules/ に書くのが向きます（Inferential Guide）。
Guides と Sensors で見たとおり、文章の規範（Inferential Guide）は確率的にすり抜けます。だから重要な規範ほど、rules に書く（Guide）と同時に、hook でも検出する（Sensor）——という両構えへ昇格させます。/debug のライフサイクルで見た「対症療法を避けよ（SKILL の文章）」と check-suppression.sh（hook）のペアは、まさにこの形に育った例です。
Phase という育て方
このハーネスは一度に完成したものではなく、Phase（段階）を踏んで育てられてきました。新しい失敗パターンが見つかるたびに Ratchet で昇格し、その積み重ねが Phase として記録されています。筆者の環境では Phase 0〜13 が完了して Phase 14 が進行中、重要な設計判断は docs/adr/（Architecture Decision Record）に 26 件残されています（2026-06-12 時点）。「なぜそうしたか」を後から追えるようにするための記録です。なお Phase 番号は筆者の整理軸で、blog post で示した Phase 0-6 とは別軸（本連載独自）です。
ラチェットの「締めた歯車は緩めない」を示す実例が、Stop hook で見た check-stray-prefix.sh です。原因だった旧モデル固有の問題が解消し回避策を削除した後も、検出側の Sensor は残してあります。原因を直すことと、再発を検出し続けることは別の仕事だからです。
要点は次のとおりです。
- Ratchet は「一度の学びを、次から自動で守られる状態にして後戻りさせない」流れ
/debugは再発防止の段階で「rules / hook / fitness / 記録のみ」の昇格先を判断する- 昇格先は「再発の被害」と「機械検出のしやすさ」で選ぶ
- 重要な規範は Guide（rules）と Sensor（hook）の両構えに育てる
次は subagent と役割分担 で、/debug 単体では出てこない「複数エージェントの並列」を /review への寄り道で見ます。