手引き: bug（不具合を直す）

期待と違う振る舞いを、再現してから直す。直す前に原因を確かめる。

1. 再現する。 報告の症状を、自分の手で実物に起こす。再現しなければ、条件を変える・入力を合成する・計測を足す。再現できないまま直さない。再現したら、そのコマンドと出力を控える（これが「直った」の判定にもなる）。CI を再現の場にせず、調べるための job や commit を push しない（playbook-verify の「CI を試し場にしない」）。
2. 原因を絞る。 仮説を複数立て、最も多くの可能性を切る観測から順に確かめる。状態が分からなければ計測やログを足して読む。推測で直さない。外の振る舞い（道具・ライブラリ・API・OS とシェルの版）に拠る仮説は、動かす前に仕様（公式の文書・man・リリースノート）を読んで絞る。症状の場所でなく、最初に誤った場所を直す（principle-fix-root-causes）。
3. 検査を先に書く。 安いテストの経路があれば、再現を失敗するテストにしてから直す（tdd）。経路が高い（重い fixture・外部サービス）なら、再現コマンドそのものを判定に使い、そう書く。
4. 直す。 根拠が正当化する最小の変更だけ。「念のため」の guard は仮説であって修正ではないので入れない。反証された仮説のために足した変更は戻す。
5. 確かめる。 元の再現が通ること、既存の検査が通ること、同じ種類の入力で近い箇所に同じ誤りが無いか（欠陥の広がり。1 つの事実で安全と言えるなら、それを実行で示す）。入力の形（全角・BOM・改行・文字コード・パス）の不具合なら、create-property-test-skill の 3 の出所から同じ種類の揺れを並べて確かめる。広がりを直して範囲を広げたら、前に書いた「この変更でしたこと」の文（作業記録の行・要約・PR の本文）を、playbook-verify の「確かめる」のとおり拾い直す。
6. 同じ前提で 2 回落ちたら止まって前提を書く。 修正を足す前に、それまでの修正が共有する前提を 1 文にし、それを見分けるコマンドを先に実行する（principle-attack-the-premise）。
7. 仕上げ。 小さな単位の commit（再現のテストが修正の前に来る順）。変更を届けるなら playbook-verify の形で証拠を添える。

返答: 何が壊れていたか、原因、直し方、失敗から成功に変わった再現の出力（そのまま）、確かめていない範囲。

会話が要約された後は、入口 bb-writ を呼び直して全文を読み直す（要約の後は、先に呼んだ入口が落ちていることがある）。