refactor(issue-flow): move branch creation guidance to operations layer

Li+github.md

@@ -142,9 +142,7 @@ Issue Rules
   Failure reporting:
   On failure, subagent writes failure report as issue comment. Format is not specified.
 
-  Branch linking:
-  gh issue develop targets child issue, not parent.
-  Reason: PR merge auto-closes the linked issue. Linking parent causes premature parent close.
+  Branch linking: see Li+operations.md Branch_And_Label_Flow.
 
   If subagent capability is unavailable:
   Parent executes operations directly. All rules still apply.

Li+operations.md

@@ -68,6 +68,18 @@ Event-Driven Operations
   Issue link via gh issue develop is always required.
   gh issue develop must precede first push to GitHub.
 
+  Sub-issue branch rules:
+  Sub-issue does not get its own branch.
+  Session branch links to parent issue.
+  Multiple child issues can share one session branch.
+  Session branch = branch-side external memory and handoff surface.
+  Another AI may continue from parent issue + linked branch without relying on prior chat memory.
+  Reason: gh issue develop links only one issue per branch.
+
+  Branch linking target:
+  gh issue develop targets child issue, not parent.
+  Reason: PR merge auto-closes the linked issue. Linking parent causes premature parent close.
+
   On local error:
   gh issue develop may fail locally but succeed on GitHub side.
   Check linked branches before retrying:

docs/2.-Task.md

@@ -90,11 +90,9 @@ issue の完了判断は本文項目ではなく、issue 状態と PR/CI/release
 
 ### sub-issue
 
-sub-issue は AI が追跡・実行できる作業単位として使う。sub-issue にはブランチを作らない。セッションブランチは親 issue にリンクする。複数の子 issue の作業を同じセッションブランチで進めてよい。
+sub-issue は AI が追跡・実行できる作業単位として使う。分割は**責務**で行う。粒度で分けない。同じ責務なら1つの issue にまとめる。複数ファイルにまたがっていても責務が同じなら1つでよい。
 
-セッションブランチは branch 側の外部記憶であり、引き継ぎ面でもある。別の AI は親 issue とリンク済みブランチを読めば、以前の会話に依存せず途中から継続できる状態を目指す。
-
-分割は**責務**で行う。粒度で分けない。同じ責務なら1つの issue にまとめる。複数ファイルにまたがっていても責務が同じなら1つでよい。
+sub-issue のブランチルール（ブランチを作らない、セッションブランチは親 issue にリンクする等）はオペレーションレイヤー仕様書のブランチ運用セクションを参照。
 
 sub-issue API：
 
@@ -106,7 +104,7 @@ gh api repos/{owner}/{repo}/issues/{number} --jq '.id'
 gh api repos/{owner}/{repo}/issues/{parent}/sub_issues --method POST -f sub_issue_id={id}
 ```
 
-同時タスクは親子 issue 構造を使う。複数タスクを同一セッションで並行進行する場合、issue を個別に作成するとブランチリンクが1件にしか張れない（プラットフォーム制約）。
+同時タスクは親子 issue 構造を使う。複数タスクを同一セッションで並行進行する場合、独立した issue を個別に作成せず親子構造にまとめる。ブランチリンクの制約詳細はオペレーションレイヤー仕様書を参照。
 
 ### チェックリスト
 
@@ -160,7 +158,7 @@ issue / commit / PR の形式に適用する。
 
 ### ブランチリンク
 
-`gh issue develop` は子 issue に対して実行する。親 issue にリンクしない。理由：PR マージ時にリンクされた issue が自動クローズされるため、親にリンクすると親が早期クローズされる。
+ブランチリンクのターゲットルールはオペレーションレイヤー仕様書のブランチ運用セクションを参照。
 
 ### フォールバック
 

docs/3.-Operations.md

@@ -54,7 +54,11 @@ trigger mode でも issue の作成・本文更新とブランチ準備は待た
 
 ### ブランチ作成
 
-issue リンクは常に必須。リンクは GitHub への初回 push より前に実行する。sub-issue にはブランチを作らない。ブランチを持つのは実際に PR を出す作業単位（親 issue）だけ。
+issue リンクは常に必須。リンクは GitHub への初回 push より前に実行する。
+
+sub-issue にはブランチを作らない。セッションブランチは親 issue にリンクする。複数の子 issue の作業を同じセッションブランチで進めてよい。セッションブランチは branch 側の外部記憶であり、引き継ぎ面でもある。別の AI は親 issue とリンク済みブランチを読めば、以前の会話に依存せず途中から継続できる状態を目指す。`gh issue develop` のリンクは1 issue につき1ブランチの制約があるため、同時タスクでは親子構造を使う。
+
+`gh issue develop` は子 issue に対して実行する。親 issue にリンクしない。理由：PR マージ時にリンクされた issue が自動クローズされるため、親にリンクすると親が早期クローズされる。
 
 ブランチ作成前にローカルとリモートの存在確認を行う。リモートに既存ブランチがある場合、後からリンクは張れない。