distributed source carries no resolved config value - Liplus-Project/liplus-language GitHub Wiki

配布される Li+ source に config の解決値を書かない

Question

Li+config.md で workspace ごとに決まる値(言語など)を、rules/ / skills/ / adapter/ の本文が必要とするとき、その値をどう持つか。

Current resolution

解決値そのものは書かない。契約への参照だけを書き、値の解決は適用の瞬間に契約が行う。

  • 書いてよい = 「どの契約が解決するか」の名指し(例: Workspace_Language_Contract が PR コメントに解決する言語)と、「誰がいつ解決するか」(例: 親が spawn 前に解決してプロンプトへ名指しする)。
  • 書いてはならない = 解決後の値(Japanese / ja 等の具体名)と、precedence 表の写し。
  • precedence の写しよりも解決値の写しの方が悪い。 前者は正本と同期を失うだけだが、後者は他 workspace では契約でない値が契約の顔で届く。

適用範囲は「配布される面」= LI_PLUS_REPO から各 workspace の .claude/ へ入る全ファイル。Li+config.md 自身と、その値を出力する hook は値を持つ側であり本判断の対象外。

Edges

  • depends on distribution-form-github-direct — 「source が全 workspace へ配布される」という前提そのもの。この前提が崩れれば(単一 workspace 専用の配布形式になれば)解決値を書いてよい側に反転する。
  • relates to always-on-duplication-removal-direction — 同一内容の写しが 2 つあるときどちらを削るかの規則。本判断は「そもそも写してよい内容か」を値の性質(workspace ごとに変わるか)で切る側であり、境界を跨ぐかどうかで向きを決める同 entry とは別軸。

Background

2026-08-08、issue #1704(brake 1 の評価者コメントの言語がプロンプトから継がれる穴)の実装中に Master の明示指示で確定した。

顕在化の経路が本判断の芯である。親が委譲プロンプトへ書いた言語指示は、skills/task-subagent-prompt/SKILL.md Delegation prompt hygiene の「How to apply」にプロンプトへ逐語コピーする定型文として置かれていた literal をそのまま採ったものであり、その literal 内に in liplus-language, issue/PR/commit bodies require Japanese と解決値が書かれていた。すなわち Li+ source 側の解決値が、親を経由して subagent の入力へ流れる経路が実在した。親が思いついた値ではない。

同 literal は precedence を名指す形(explicit human instruction → thread agreement → destination repository / workspace project-language default)を既に持っており、そこまでは正しい。欠陥は末尾で precedence を一度解決した結果を literal 内へ焼き付けている点にあった。

grep -rn "Japanese" rules/ skills/ adapter/ による実測で、同型の解決値保持は 6 箇所(rules/operations/operations.md 3 / skills/task-subagent-prompt/SKILL.md 3)。うち operations.md の 2 行は #1580 が 2026-07 時点で既に検出しており、#1575 が閉じるまで意図的に据え置かれていた(下記 Constraints 参照)。

Constraints

  • 正本は 1 つ。 言語の正本は Workspace_Language_Contract(adapter/claude/CLAUDE.md / adapter/codex/AGENTS.md)であり、値の出所は Li+config.md。参照で解決し、写しを置かない。
  • title 系の ASCII English 固定は本判断の対象外(Master 確認済み)。GitHub の推奨に従う固定であり、workspace の言語設定とは別軸。「言語を設定可能にする」作業に入った読み手が 4 行すべてをパラメータ化しようとする誤読が実際に発生しているため、固定側にはその理由を明記する。
  • 参照化には substrate の前提がある。 解決値がその場に書いてあることは「参照の一手を要さない」という点で実際に機能していた。#1575 が閉じる前に外すと、値の解決に「Li+config.md を読む」手続きが要る状態になり、それは #1575 が診断した「ルールは在るが適用の瞬間に発火しない」構造そのものになる。#1575 が閉じた後の substrate では値は on-session-start.sh が session 冒頭の context へ emit するため、参照の一手は「emit された値を見る」であって手続きではない。参照化は substrate が整った後にのみ正しい。

Conclusion

採用 = 参照で解決する形。skills/evolution-parallel-agent-eval/SKILL.md Report shape → Language 節(PR #1706)がこの形の最初の実装で、「親が spawn 前に解決してプロンプトへ名指しする」だけを規定し、値も precedence も持たない。

却下 = 解決値を書く形。理由は上記のとおり、他 workspace へ契約でない値が契約の顔で届くこと。

逐語引用は本判断の対象外。 評価者の所見が引く Li+ source は英語(rules/model/liplus-coding-rule.md Source Language)であり、引用は原文の言語のまま残す。根拠は都合ではなく所見が乗っている性質そのもので、著者は引用に当てて裁定するため、訳された literal は literal ではない。結果として、ja 以外へ解決する workspace では所見は構造的に混在する(引用は英語、地の文は解決後の言語)。

Related

  • #1704 / PR #1706 — 最初の実装(brake 1 評価者コメントの言語)
  • #1580 / PR #1709 — 実測された 6 箇所の是正、完了(#1707 を統合)。rules/operations/operations.md の body 系 2 行を LI_PLUS_PROJECT_LANGUAGE 参照へ、skills/task-subagent-prompt/SKILL.md の 3 箇所から言語名を除去(うち 1 箇所は項目ごと削除 = Mode-specific delegation injection の (a) commit body language、同節の自己規定に乗らないため)。あわせて title 軸が別軸である理由を明文化し、ja / en / English へ掃き出しを広げた
  • #1575 — 言語契約が値を手続きで解決していた問題(参照化の前提条件、2026-07-27 close)