presence defect cannot reach blank label visibility - Liplus-Project/liplus-language GitHub Wiki
存在側の欠陥は空欄ラベルの可視性に届かない
Question
Axis statement form の各パートに要求を足すとき、その検出は「未記入のラベルが可読な欠落として残る」artifact visibility と同等の構造性を持てるか。持てない場合、仕様側はどう書くか。
Current resolution
持てない。そして、届いたと書かずに差を書く。
skills/evolution-parallel-agent-eval/SKILL.md Axis statement form が立っている機構は、パートが文字通り空欄であることの可視性である。何も当てない読み手にも欠落として見える——これが空欄ラベルの強さの正体であり、欠陥が不在だから成立する。
多義な述語（forced / consistent / resolves wrongly）は反対で、Question フィールドを通常の文面で埋めている。欠陥は存在側にあり、「これは操作を名乗っていない」と読むには区別を当てる必要がある。散文の内側で存在側の欠陥を「読まずに見える」形にする手段は無いため、この class に対して「artifact visibility と同等以上」は充足不能である。
したがって PR #1770 は、requirement を Question パート本体へ埋め込む（＝事後手続きの追加を避ける）ところまでを取り、届く範囲と残余を本文に明記した。得ているのは「区別を、その場に在って引用可能なテキストへ当てられる」ことであり、空欄ラベルより狭い。残余（著者と N 体の評価者が同じ読みへ収束し、split が出ず信号も出ない場合）は同ファイル Non-scope が既に採っている post-merge observation 軸で受容する。
Edges
- depends on
subtractive-structural-beauty-framing— procedure-vs-structure binary（実行保証の無い手続きは構造へ置き換えよ）の適用結果として本判断が立つ - relates to
release-version-rule-always-on-relocation— 同 binary を適用し、常駐化という構造への置換が実際に取れた事例 - relates to
hook-driven-gate-trigger— 同 binary を適用し、hook という構造への置換が実際に取れた事例 - 上記2件との対比が本 entry の位置である。binary は「required か unnecessary か」を問うが、置換先の構造が存在しない class があり、そこでは差を書くことが唯一の正解になる
Background
Axis statement form Question は「1軸が複数の問いを運ぶ」ことを防ぐために置かれていたが、捉えるのは and やカンマで繋いだ2節だけだった。1つの interrogative の述語側が多義である形（連言が一語の内側へ圧縮されている形）は届かず、brake 1 で4サイクルにわたり再発した（#1720 forced / #1733 sweep 言語 / #1763 整合 / #1766 resolve wrongly）。
issue #1768 は修正にあたり、「軸を書いた後に多義性を検査せよ」という事後手続きの追加を禁じた（それ自体が実行保証の無い手続きになるため）。そのうえで「同ファイルが既に採っている artifact visibility と同等以上の構造性」を要求した。
PR #1770 の brake 1（N=3）は、この要求が満たされていないことを3体全員が独立に指摘した。指摘の核は、:125 の可視性が空欄フィールドの性質であるのに対し、評価的述語は通常の文面でフィールドを埋めるため、同じ機構だと書くのは過大主張であるという点。
Constraints
- 事後検査手続きの追加は禁止（issue #1768 constraints）——実行保証が無く、置き換えるべき当のものになる
- 安全網の追記も禁止——
rules/model/subtractive-structural-beauty.mdの binary は required か unnecessary かのみを認める - 既存の「
and/ カンマ結合の禁止」は削除しない - 満たしたと書くことは
rules/model/foundational-invariant.md（correctness = 実挙動であって説明ではない）に反し、同ファイル自身の固定軸（impression vs literal）が立っている当のものに抵触する
Conclusion
採用したのは「requirement をパート本体へ埋め込み、届く範囲と残余を明記する」形。Question は判定を生む操作を名乗ることを要求し、数える対象を節から操作へ移した。多義な述語は読みごとに為すことが違うため、操作を書くと読みが軸を書いているその場で別々の疑問文へ分かれ、既存の節の禁止が他の対と同じように発火する——追記ではなく、既存の禁止に届かなかった経路を返す形である。
却下したのは以下2つ。
- 「同等以上を満たした」と書く案 — 空欄ラベルとの差が実在する以上、虚偽になる。満たしたと書くほうが欠陥として重い
- 事後の多義性検査ステップを別surfaceへ置く案 — issue が明示的に禁じた形であり、
rules/model/subtractive-structural-beauty.mdが「落ちた手順を、憶えておくべき1行として別の面へ置き直す」を構造ではないと述べている当のもの
残余の受容は post-merge observation 軸（memory/self-evolution-observation.md、PR #1770 のエントリ）で追跡する。要求文言そのものの充足可能性——存在側の欠陥に対して構造的検出が原理的に取れるか——は本 issue の外にあり、未解決点として残る。