diff --git a/docs/Decision-Structure.md b/docs/Decision-Structure.md
index 5a9bbd6..c0054a0 100644
--- a/docs/Decision-Structure.md
+++ b/docs/Decision-Structure.md
@@ -179,6 +179,7 @@ wiki 内の閲覧は wiki sidebar の「判断構造」セクション、また
 | [`decision-structure-state-form-edge-binding`](https://github.com/Liplus-Project/liplus-language/wiki/decision-structure-state-form-edge-binding) | state 形の要求をエッジの有無に結合し、変換を convert-on-touch にする判断（#1436 / PR #1437、2026-05-31）— 31 entry 監査で 26 が event 形。エッジ無し確定 entry の state 形化は churn のみで情報量不変、エッジ宣言 entry は supersede 経路の収束のため state 形必須。一括移行と「後日の移行パス」はどちらも却下（後者は recall 依存、#1413 の教訓） |
 | [`neuron-graph-rag-integrated-prototype`](https://github.com/Liplus-Project/liplus-language/wiki/neuron-graph-rag-integrated-prototype) | ハイブリッド検索、型付き知識グラフ、活性伝播、成功フィードバックを一つの独立 RAG エンジンとして試作し、Li+ への統合前に有効性を検証する判断 |
 | [`issue-completion-condition-scope`](https://github.com/Liplus-Project/liplus-language/wiki/issue-completion-condition-scope) | issue body の完了条件フィールドの射程を二値で定める判断（#1625 / 実測の出所は `Liplus-Project/github-rag-mcp` #178、2026-07-29）— 判定線は「その完了条件は PR 単体で満たせるか」。満たせるなら書かない（`rules/task/task.md` の汎用 close 条件が覆う）、満たせないなら書く（deploy 後の本番状態・実機の挙動など、PR / CI / release フローが観測しない完了には他に記録面が無い）。「念のため書く」は入らない。元の一律不要規定は撤回せず射程を明示するだけ |
+| [`description-body-coverage-resolution-priority`](https://github.com/Liplus-Project/liplus-language/wiki/description-body-coverage-resolution-priority) | skill の body 節と `description` の被覆ずれを解く手段の優先順を固定する判断（#1634 / PR #1643、#1641 / PR #1644、2026-08-03）— 上から順に「1. body 節を削る（load-bearing でない場合）」「2. 発火モーメントを所有する面（always-on ルール / 既にその瞬間で発火する別 skill の body）へ節を移す（listing コスト増ゼロ）」「3. `description` へ条件を追加（1 / 2 が不可能な場合のみ、選んだ理由を PR 本文に記録）」。却下 = 項目ごとの都度判断（判断の余地を残すと検証しやすい被覆の有無へ寄り、常時コストの軸が黙って犠牲になる）。起票時の前提「`Provides` 句の是正は listing コストの減少側」は PR #1643 の実測で反証（touched 13 本の `description:` 行合計 net +1236 バイト、44 本 corpus 比 約 +7%）＝正確さを上げると記述は伸びる非対称。ゆえに優先順は「コストが減る手段を優先する」ではなく「コストを増やす手段を最後に置く」と読む。`skill-trigger-declaration-in-description` と `li-plus-always-on-footprint-load-bearing` に depends on |
 
 ---