Rules cache fetch address table

Question

Cold-start で context にロードされた rules/*.md 群について、judgment moment で AI が「どの rule path を読むべきか」を引くための fetch アドレス表をどう提供するか。

Current resolution

on-session-start.sh cold-start hook が rules/ のパスツリーを動的生成して emit する。既存 register_section 経由で diff-only mode に乗せ、static artifact 化しない。ツリーには path のみ収録（description / 要約は不要、filename = semantic identifier per Source File Format）。Scope = rules/ only（skills/ は host auto-invoke が別 axis で対処、adapter/ は judgment-time fetch target ではない）。

Edges

• depends on subtractive-structural-beauty-framing — 新規 artifact 追加ではなく既存 cold-start infrastructure（register_section + diff-only mode）への便乗、ツリーに description 追加せず paths のみ、scope を rules/ に narrow、全て subtractive default 適用。
• depends on PR #1270 — cold-start orientation の diff-only emit 機構が前提（本判断は新規 section をその既存機構に乗せる）。

Background

Master との対話で表出した構造観察:

• Cold-start で context の約 8% が rules 読み込みに使われている。rules/*.md の literal text は context に常駐する。
• だが judgment moment で attention が本体 rule に届くとは限らない（rules/model/trigger-check-gate.md Literal check 軸が警告する「gist memory 依存」と同型の構造）。
• 人間は file explorer / IDE のツリービューで rules/ の階層を視覚的に scan できる。これは index として直接機能する。AI の context では各 rule の中身が flat に展開されてヘッダに path が散在しており、ツリー形態の視覚的階層は提示されていない。
• C 出身 Master の analogy: cold-start = cache warming、literal text = main memory、attention 経路 = memory access、Read tool による再読 = cache invalidation。trigger-check-gate.md の Literal check 軸 = cache invalidation policy として読み直せる。

判断対象は「cache から本体を引くための fetch アドレス表（人間にとっての folder tree 視覚に相当するもの）を AI context にどう提供するか」。

Constraints

• 既存 cold-start infrastructure（on-session-start.sh）に既に section emit + diff-only 機構が存在する。
• 新規 artifact 追加は rules/model/subtractive-structural-beauty.md の addition justification を要する。
• rules/*.md の filename は kebab-case slugify で semantic identifier として既に機能する（per Source File Format 規約）。
• L1 Model Layer 非接触で実装可能（rules/evolution + adapter/hooks のみ）。
• skills/ は host の auto-invoke 機構（description semantic match）で別 axis、同じ介入手段を共有しない。

Conclusion

採用 = cold-start hook が rules/ のパスツリーを動的生成して emit、既存 diff-only mode に register_section 経由で乗る形。ツリーには path のみ収録、description / 要約は付けない。

却下案:

• 静的 index 化（新規 artifact）: maintenance discipline と stale 化リスクを抱え、既存機構で済むのに新規 file 追加は subtraction 原則違反。
• on-demand Glob（judgment ごとに tool call）: judgment moment ごとに tool call cost、habit 依存度が高い（実発火しないと意味なし）。
• folder structure 単独（artifact 追加なし）: 視覚的階層は人間視点でのみ index として機能、AI context にはツリー形態が提示されないため AI 側では実 index として働かない。
• rules + skills + adapter 全部 emit: skills は host auto-invoke が別 axis で対処すべき（description semantic match）、adapter は judgment-time fetch target ではない。scope creep を避けるため rules/ に narrow。
• ツリーに description 抽出を併記: filename が既に semantic identifier として要約役を担う（per Source File Format）、description は冗長。brake 1 で確認済（PR #1423 R1 で「Filename discipline side effect」段落を non-load-bearing 判定して削除）。

Related

• Issue #1422 / PR #1423
• Future surface 候補:
  • skills 描述精度向上（rules tree とは別 axis で skills auto-invoke recall gap を対処する別 issue 候補）。
  • filename discipline の明示的拡張 — 本 PR の brake 1 で「filename 規律への副作用」段落を削除した一方、構造的観察自体（filename = index lookup key）は real。後続別 issue 候補で rules/model/liplus-coding-rule.md Source File Format への filename-level discipline 明示の load-bearing-ness を別途検証。