always on duplication removal direction - Liplus-Project/liplus-language GitHub Wiki
常時ロード分の重複を削る向き(どちらのコピーを残すか)
Question
Li+ ソースに同一内容のコピーが2つあるとき、どちらを削るか。「重複は削れ」という一般則と、Li+ の主軸である「適用瞬間に必要なリテラルが一箇所に揃っているか(跳躍数)」は、場面によって逆を向く。
Current resolution
境界を跨ぐかどうかで向きが決まる。
- 常時ロード分の内側の重複(
rules/**↔adapter/*/CLAUDE.md/AGENTS.md間)→ 削ってよい。削除で増えるのは文脈内跳躍のみで、追加のツール呼び出しは発生しない。canonical を1つ決め、削除跡にはポインタを残す。 - 常時ロードと遅延ロードを跨ぐ重複(常時ロード分 ↔
skills/*/SKILL.md本体 /docs// hook)→ 常時ロード側を残し、遅延ロード側を削る。 素朴に「重複削除」を適用すると逆をやり、適用瞬間にツール呼び出しを一つ増やす。
合格条件はバイト数ではなくツール呼び出し跳躍が減るか据え置き。文脈内跳躍の増加は罰しない(罰すると内側の重複削除が一切できなくなる)。
Edges
- depends on: liplus-context-rot-tension — always-on ↔ JIT を未解決トレードオフとして受容する判断が前提。本 entry はそのトレードオフの中で「どちらに寄せるか」の運用規則を与える
- relates to: liplus-structure-as-retrieval-surface
- relates to: release-version-rule-always-on-relocation — 判定基準を always-on の単一ソースに置いて跳躍ゼロにした先行事例(本規則の雛形)
背景
Anthropic の記事(Claude 5 世代向けに Claude Code のシステムプロンプトを8割以上削除して劣化なし)が挙げる指針のうち「重複の削除」を Li+ に当てようとして表面化した。Li+ は重複を嫌って参照で繋ぐ設計であり、これ自体は正しい。しかし一つの規則を適用するのに複数ファイルを渡り歩く構造は、跳躍のたびに「読む」を「記憶で済ませる」に置き換える隙を作る。
記事の指針をそのまま適用すると、その場にあったリテラルが消えて跳躍が一つ増える場面が出る。二つの軸が衝突しているように見えたが、跳躍を文脈内(常時ロード分=既に読み込まれている)とツール呼び出し(外に出る=取りこぼしうる)に分けたところで和解した。
なお記事の射程はコーディング評価で測った Claude Code のシステムプロンプトであり、統治レイヤを載せた構成での検証ではない。適用にあたっては統治層(自律を渡す条件として人間と合意した内容)を削減対象から明示的に外す仕分けが先に要る。
制約
- 統治層(二段ブレーキ、人間判断ゲート一覧、
Evolution_Initiator_Autonomy、Human = final judge)は本規則の適用対象外。モデルの能力向上で消える理由がないため、削減の可否を跳躍数で裁いてはならない - A 分類のセクションの内側に統治条項が埋め込まれている箇所がある。セクション単位で削ると統治内容が消えるため、カーブアウトが先
rules/model/subtractive-structural-beauty.mdの Detection signs は同ファイル内で観測面として保護宣言済
結論
採用 = 境界を跨ぐかどうかで削る向きを決める二分規則。合格条件はツール呼び出し跳躍の非増加。
却下 = 「重複は一律に削る」(跨ぐ重複で跳躍を増やす)。却下 = 「跳躍を増やす削除は一切しない」(内側の重複削除が不可能になり、the second copy is what drifts の規律が執行できなくなる)。