evolution task rule bodies carry behavior only

rules/evolution と rules/task の本文は振る舞いのみを載せ、剥いだ理由はここが保持する

Question

rules/evolution/*.md と rules/task/task.md（常時ロード）の本文から、rules/model/liplus-coding-rule.md Body States Behavior の判別線（読んだ者の行いが変わるか）で理由を剥いだとき、剥いだ理由はどこが保持するか。

Current resolution

本文は振る舞い（何を・いつ・どの条件で・何を禁じるか）だけを持つ。剥いだ理由は、既存 entry が既に保持しているものはそちらが持ち（下の「合流先」）、それ以外は本 entry が持つ（下の「本 entry が保持する理由」）。

PR #2112（issue #2109）で 7 ファイル合計 68.4KB → 54.9KB（約 −20%）。見出し・semantic tag は不変。本文にポインタは置かない（judgment-record-pointer-requirement-dropped）。

合流先（既存 entry が既に保持している理由）

剥いだ位置	合流先
initiator-autonomy.md Governed surface の「brake 1 の検出器は読み手」と各 bullet の「読むことだけが検出器」説明、tests/** / .github/workflows/** が発火側である理由、tests/ / .github/ を Scope に載せた経緯	brake1-firing-closed-by-criterion
initiator-autonomy.md Record surfaces の「誤った行の代償は読み直し 1 回、その評価は読み直しで捕まる行にだけ成り立つ」	record-surface-exclusion-holds-only-for-reread-catchable-lines
initiator-autonomy.md Merge brake の「再開で実装文脈が保たれ、親が報告から文脈を組み直すコストを払わない」	brake-adjudication-by-resumed-author
initiator-autonomy.md Merge brake の往復上限を持たない理由	brake1-round-cap-removed-recurrence-escalates
promotion-judgment.md Tally の「アダプタごとの tally は床を割り、どちらも閾値に届かず、割れを何も検出しない」	tally-placed-under-the-mechanism-name-not-an-adapter-home
cold-start-synthesis.md Hook Emission Contract の partition 関連の背景	cold-start-state-partitioned-by-agent-key

本 entry が保持する理由

memory-entry-format.md

• Position: memory ファイル先頭の運用注記を本規則への参照に置き換えるのは、二重保持のドリフトを避けるため。
• Scope: cluster tally も一過性だが memory の外に置くのは、memory がワークスペース単位で解決するのに対し tally はホストにつき 1 つの計数面だから。
• Trigger point: 「一過性か永続か」の判断を観測のたびに置くことで、永続情報が memory に沈殿する構造的欠陥を断つ。
• Artifact deletion calibration: rules/model/subtractive-structural-beauty.md Core principle (A) を、爆発半径を load-bearing な基準として当てはめたもの。両方向の失敗は同 Core principle (C) の一例。
• Announce vs execute: 「後で記録する」「記録に値する」と言うことは、行動から切り離された誠実さの演技であり、観測上は何も書かれていない言葉だけの置き場である。
• Self-Evolution Observation Format: cluster tally は起票前の観測で memory の外に置かれ、こちらはマージ後の観測。check を取らない session があっても、毎 session 再 surface されるので trigger は失われない。
• retired の線引き: settle はサンプル（観測された適用瞬間）に依拠し、retired はサンプルが存在しえないことを示す。inconclusive は待っているサンプル、retired は生成できないサンプルであり、後者は根拠が書ける。「見ていない」は条件の消滅ではない。
• Consolidate Trigger の外部ツール非名指し: 同梱していない skill だけを経路として書けば、その skill を持たないホストで手順が止まり、止まりに出会った agent が他者の読めない即興の pass を入れる。
• Consolidate Trigger の記録を 1 箇所にする理由: 前回実行は memory 集合につき 1 つの事実であり、全ファイルへ複製したタイムスタンプはドリフトする二つ目の写しになる（Core principle (A)）。
• Consolidate Trigger を経過時間の一本腕にした理由: 廃止した二本目の腕「前回以降の新規追記 5 件以上」は gross の量を問うが、memory 集合の大きさのスナップショットからは gross が復元できない（Entry Format の削除が追記量と残存量の差を消し、索引済み運用ファイルへの追記は大きさを動かさない）。大きさの差は net の問いに答えるだけで、数える対象を絞っても gross を削除から守れない。単調増加カウンタは、構造で保証できる側（memory ディレクトリへの書き込みを数える hook）が数えるのが書き込み操作であって追記ではなく、追記を数える側は書き手のインクリメント＝保証されない手順に依存する。落とした腕が担っていた volume 比例の発火は文面上だけで、一度も発火していない（これまでの consolidate はすべて経過側で走った）。#1826 / #1829。
• Language: 英語推奨は Li+ source と同じ二軸（意味精度とトークン経済）による。

cold-start-synthesis.md

• Operational criterion: diff-only + no-new-material marker で黙るのは、marker 自体が session 境界の人間向けの確認だから。Latest の位置で黙るのは、Latest flip が複数セッションの実機観測に掛かった人間ゲートであり、AI 側からの surface は go-sign の要請でオリエンテーションではないため（完了報告の瞬間については rules/operations/main-agent-procedures.md Release completion report discipline が同じ規律を持つ）。
• 目標: セッション開始時に Li+ 状態を人間に再説明させないこと、かつ重複オリエンテーションのノイズを避けること。hook が生の surface（startup では diff-only の経済）を担い、step 3 は合成の差分だけを担う。
• Anchor cut: 本ファイルは常時ロードなので全文を再 emit すると同じ本文が 1 session に二重に入る。preamble は step 3 で適用される部分で、H2 以下はそうではない。H2 の無いファイルを丸ごと出すのは、cut は経済であって anchor を失うほうが重い失敗だから。
• PowerShell port の fail-safe 集合: JSON をネイティブに parse するため node 依存が無く、SHA256 を可用性ガード無しに無条件で呼ぶため、二つのツール理由はそこで発火しない。
• last_emit_at 読み返し行: diff-only でのみ出すのは、full emit は何も抑止しておらず、marker 状態は境界を既に 1 行で述べているから。識別子を持たないのは、この行が述べるのは基準線がいつ動いたかであって誰が動かしたかではないため（partition 内でも同じ。状態ファイルの top level が partition 鍵を名乗るのはファイルの構造上の事実で、この行が surface するフィールドではない）。
• no-new-material marker を silent skip にしないのは、人間が session 境界を観測できるように。surface された observation / tally / clone を material に数えるのは、それらと「新しい material 無し」を並べれば自己矛盾の出力になるから。resume / clear / compact / fork で anchor だけなのは、作業文脈が連続しているから。
• overdue 優先: 期限切れの entry では next_check も通常過去にあり二条件が同時に成り立つ（tally では第二条件が第一条件に含まれる）。overdue がエスカレーションを運ぶ軸であり、1 件を両軸に出すのはノイズ。
• material 収集の位置: 既存の memory scan + Decision-Structure 索引 head emit と並列。
• Promotion Tally Expiry Surface: 解決したパスを emit が名指すのは、どの規則もパスを述べず、そのパスが agent が occurrence を書く場所だから。cluster が verdict を持たず存在そのものが未解決状態なのは、Threshold Rules の全出口が cluster の除去で終わるため。毎 session 再 surface されるので判断を取らない session があっても trigger は失われない。occurrence 数を行に載せるのは、それで Threshold Rules の行が選ばれるから。
• Clone Branch Fetch Surface（#1911 / #1921、docs/2.-Evolution.md 同段落）:
  • 述語を source 側で読む理由: --single-branch の clone を wildcard literal で照合すると毎 session 誤報する。refspec を一続きの文字列として検査すると dst 側の refs/heads/ で健全と誤読する。^<pattern> は写像を作らない。
  • surface が要る理由: そうした clone は失敗しない。tag は解決するので fetch --tags は成功し、素の git fetch origin は no-op として成功し、branch は動かない。何も raise せず、update-status の軸は実際に進む ref である tag を読む。
  • state-driven と lifecycle 不在: 既存 2 面は日付駆動で、明示的な除去（observation は verdict、tally は閾値判断）まで entry が残る。state 駆動の面は条件が消えた瞬間＝修理が入った瞬間に emit が止まるので、verdict_state / expires / 除去手順を足すと、報告した条件が消えた後に残る entry というまさに不在が防いでいるものを再導入する。
  • LI_PLUS_UPDATE_STATUS に載せない理由: 同 marker は adapter startup 手順 step 2 の起動条件で、status だけで分岐し reason では分岐しないため、そこへ置いた reason は更新手続きを起動する。検出のみの検査がその経路を持ってはならず、reason 文字列を足せることは既存の reason と同じ軸にある証拠ではない。
  • 修理を人間の go-sign に置く理由: 修理は共有されたローカル git state の書き換えで、rules/evolution/memory-entry-format.md Artifact deletion calibration の local non-git config / state (gitignored, meaningful) = caution high。hook-surfaced items = silent がこの面を黙らせないのは、その行が控えるのは人間が既に持つ material の再報告であり、ここで動ける主体が人間だけである以上、黙る session は surface を読み手なしに残すから。
  • api mode / git 不在で黙る理由: どちらも refspec についての証拠ではなく、証拠のように報告すれば修理対象の無いワークスペースへ所見を置く。
• Dependency Ordering Surface: GraphQL で読むのは、どの gh バージョンでも面が成り立つように。

task.md（#1824 / #1828、docs/3.-Task.md 同段落）

• state が複数回入れる理由: これらは状態であってイベントではない。
• review-pending が blocked にならない理由: その待ちが人間に求めるのは完成した作業への判定であり、作業が必要とする入力ではない。
• Scope end: close は state machine 内の遷移ではなく機械からの退出であり、その後は何も current でないので不変条件が縛る時点が残らない。close の瞬間に剥がす手順を置かないのは、Closes #<n> による自動 close がマージの副作用として発火し issue の前に主体が立たないため（rules/model/subtractive-structural-beauty.md はこの形を構造へ送る）。構造（close 時にラベルを剥がす workflow）も作らないのは、誰も読まない性質を維持することになるから。state ラベルの読み手は全て既に open フィルタを持つ（adapter/claude/hooks/on-session-start.sh / adapter/codex/hooks/on-session-start.sh / adapter/codex/hooks/on-session-start.ps1 はいずれも --state open --label in-progress）ので残存は不活性で、それを維持する機構は Core principle (A) の構造ノイズ。
• Search surface: open フィルタは「いま何が動いているか」という問いを述べる部分。in-progress の残存が false lock を生まないのは、lock は issue を「取られている」と読むことから生じ、closed issue は pickup のために読まれないから。

initiator-autonomy.md

• 条件 1 は十分条件と誤読されやすい（initiator path が確定した時点で読みが止まる）。
• hooks/ はトップレベルに存在しない。
• 評価者が受け取るものを PR URL / SHA / CI run URL に固定するのは、評価中に基準線が動かないため。
• 位置・手順・数値を本面に再掲しない理由: 本面は毎 session 全体が注入され skill 本文は invoke 時に遅延ロードされるため、条件を失った写しが常に文脈にあり、条件付きの原本は誰も開いていない側になる。二つ目の写しがドリフトする（always-on-duplication-removal-direction と同じ非対称）。
• 親が全所見を読む要件は不変で、移ったのは満たす場所（各ラウンドから出口へ）。
• 不要な eval のコストは eval 1 回、見逃しのコストはゲートそのもの（どちらでもない面を発火側に置く理由）。
• Scope と条件 2 は別軸で、docs/ が両者の食い違う項目。一方の所属から他方を読むと誤る。
• tests/** の例示: tests/test_check_webhook_notifications.py が poll-mode helper の分類・フィルタ経路を覆うので、黙って狭まるフィルタは未配達ではなく check の失敗として露出する。

promotion-judgment.md

• Cluster: 基準化は再現性と引き換えに観測ノイズを取り込み cluster 粒度を縮める。再現性のトレードオフは受容済み。
• disposition log を末尾に置くのは、cluster parse が上の ## cluster: 見出しを読むため。log の記録対象はすべて tally を既に離れた cluster。
• recall で tally を開くことは発火点ではなく、保証されたことも無い（rules/model/subtractive-structural-beauty.md Spec write applies (B)）。disposition 行を別手順にしないのも同じ理由。
• 3 出口すべてに disposition 行を要する理由: tally から消えた cluster は一度も観測されなかった cluster と区別できず、それは各出口で同じ。
• promotion marker で検索するのは、それが Issue Creation Metadata が作成時に付ける作成経路フラグだから。
• 再発予測の禁止: 1 回の観測から「重要」と保持する過剰判断を招く。
• forming で始めるのは、作成時点で既に 3 回以上観測されているから。

evolution.md / autonomy-block-shape.md

• substrate が polling-on-input なのは --channels が Claude Desktop に届かないと判断したため（docs/G.-Sheepdog-Engineering.md substrate 節）。merge brake は安全側の規律を保つ。substrate 層 Sheepdog は judgment 層完了の scope 外。
• Loop Safety / Accepted Tradeoff Handling / Review Output Partition は実行時不変条件であって自己更新機構ではない。
• judgment learning と decision structure write の対は、層を出ずに session を跨ぐ判断知識のループを閉じる。
• cross-block 定数を集めるのは、per-block 宣言を自身の load-bearing 面に集中させるため。
• Explicit exclusion scope が防ぐ失敗: 1 つの「X を保存するな」が autonomy 宣言全体を permission-ask へ戻すこと。
• 印象ベースの記載は、後の印象批判ループの燃料になる。

Background

issue #2109（Master「無駄なやつ全部蒸留して」）。rules/operations と adapter は別 issue（#2110）。

Constraints

• 振る舞いは 1 節も変えない。削るのは理由だけ（issue #2109 constraints）。
• 本文の変更は rules/evolution/ と rules/task/ に限る。adapter/claude/CLAUDE.md の Substrate caveat は同じ --channels 括弧句を持ち続けるが、adapter は本 issue の対象外。
• tests/test_clone_refspec_branch_check.py が Clone Branch Fetch Surface 内の state-driven / verdict_state / expires を固定しており、これは lifecycle 不在の宣言（振る舞い）なので本文に残した。

Conclusion

採用: 剥いだ理由を本 entry と既存 entry へ移し、本文は振る舞いだけにする。 却下: 理由の置き場を docs/2.-Evolution.md / docs/3.-Task.md や導入 PR 本文だけに任せる案（issue #2109 の constraints が置き場を Decision Structure wiki と名指している。PR #2112 brake 1 round 1 で指摘）。

Edges

• depends on source-body-behavior-only-reasoning-relocates — 判別線と移設の規則そのもの
• depends on judgment-record-pointer-requirement-dropped — 本文にポインタを残さない
• relates to parallel-agent-eval-body-carries-behavior-only — 同じ規則の skill 本文への先行適用

Related

• issue #2109 / PR #2112