tadori1. ルールを 1 行書く
詳細設計の工程（dd）のルールセットに、「詳細設計の節には change 列が入っている」というルールを書きます。判定の種類は filled（列が埋まっている）です。
id phase kind from to field only owner label
R4 dd filled DD change 設計担当 詳細設計の節に改修後の対応（変わる／変わらない／未決）が書いてある2. 台帳には、節と「何を元にしたか」だけ
台帳（ledger/items.tsv）には節の ID・名前・原本の場所・元にした基本設計の章を書きます。設計書の中身は写しません。
| id | title | source | refs | change |
|---|---|---|---|---|
| DD-2.3 | 貸出上限の判定 | docs/detail-design.md §2.3 | BD-2 | 空 |
| DD-3.1 | 返却期限の扱い | docs/detail-design.md §3.1 | BD-3 | 変わらない |
| DD-3.2 | 延滞中の貸出拒否 | docs/detail-design.md §3.2 | BD-3 | 変わる |
3. 残課題の画面で、担当と直し方を見る
詳細設計の工程を選ぶと、R4 の漏れとして DD-2.3 が出ます。担当（設計担当）と、どのファイルの何行目のどの列に書けば消えるかが並びます。 md のアイコンからは、その行を md-business で開けます。
4. 「変わる」と決めた節だけ、次の工程で確かめる
改修後の対応が「変わる」になった節は、実装の工程で commit から参照されているべきです。ルールの only 列で、対象を「変わる」の節だけに絞ります。「変わらない」節に commit を求めて、形だけの漏れを出すことはありません。
R6 impl covered DD COMMIT change=変わる 開発担当 改修後に「変わる」詳細設計の節が commit から参照されている5. 直したら、もう一度確かめる
設計担当が DD-2.3 に「変わる」などを書いて保存すると、画面はその場で描き直されます。tadori check --log で確かめた結果は、チェックの記録（5W1H）に残ります。
前のチェックで漏れだった行は、つながりを辿る画面で「対応済み」と出ます。直ったと認めるのは人です。