# 保留課題をbacklogへ分離する

## 結論

文書を、現行仕様・保留課題・検討履歴の3種類に分ける。
後回しにできる問い・検証・改善候補はbacklog/README.mdにまとめる。
現在の仕様が依存する未確認の前提は、引き続き仕様書の末尾に残す。

## 案の比較

| 置き場 | 判断 |
| --- | --- |
| 各仕様書の未確認事項にすべて残す | 現行実装の前提と、将来考えればよい課題が混ざる |
| journalへ移す | 結論反映後に削除できる履歴と、再開まで残す課題では寿命が異なる |
| 直下にbacklog.mdを置く | 直下へ追加したくないというユーザーの意向で採らない |
| backlog/README.mdへまとめる | 採用。役割をフォルダで区別し、必要になれば分割できる |

## 運用の意図

既存ルールの狙いは、採用した仕様に過去の検討を混ぜず、未確認の前提を事実と誤認して実装しないこと。
保留課題は現在の仕様でも解決済みの履歴でもないため、第3の文書種別として扱う。

移動の基準は未確認かどうかではなく、現在の実装がその答えに依存するかどうか。
保留中の対応範囲・暫定仕様は仕様書に明記し、その範囲で進められる問いだけを移す。
backlogへの移動自体は、仮説の採用や実装の許可を意味しない。

各項目は元の番号にレイヤー名を付け、関連仕様・未決事項・保留理由・再開条件・完了条件を持つ。
再開条件で「いつ考え直すか」を、完了条件で「何を確認または決定すれば終わるか」を残す。
事実確認と設計上の意思決定をともに「格上げ」と呼ぶことはやめる。
解決または取り下げた項目は削除し、完了済み課題の一覧は作らない。

仕様書側の「保留課題」は、対応するbacklogの区分へのリンク箇条書きだけに固定した。
問いの要約や項目名の列挙を重ねると片方だけ古くなるため、詳細はbacklogで一元管理する。
末尾は保留課題・検討済み非採用・未確認事項の順とし、空の保留課題セクションは残さない。

## 適用範囲

PHY・ELC・IDXの10件を整理した。ELC-P-3は責任分担の決定後に残る方式別の確認として扱い、
IDX-P-1は別途決定済みの仕様を維持して既存レイアウトとの互換性の実測だけを残した。
実機確認や既存コミュニティレイアウトの再調査は行っていない。
他の既存文書の全体再編は、この変更には含めない。

doc-lintもルール5に対応させる。backlogを検査対象に加え、項目の必須欄、
仕様書側の固定書式と参照先、事実確認と設計判断の完了条件を検査する。