4. Operations

オペレーションレイヤー仕様書

本文書は Li+ プログラムのオペレーションレイヤー（rules/operations/*.md + skills/operations-on-*/SKILL.md）の仕様を定義する。要求（何を満たすか）と仕様（どう振る舞うか）を一体として記述する。

rules/operations/*.md は .claude/rules/ 経由で常時コンテキストに存在する（compaction を生存）。skills/operations-on-*/SKILL.md はトリガー時に skill auto-invocation で読み込まれ、ブランチ作成、コミット、PR、マージ、リリース等の操作詳細を提供する。

本文書の各セクションは冒頭に (→ ソース) 形式で対応する権威ソースを明示する。docs/4 は日本語の要求仕様記述面であり、英語の rules/skills が literal なソース・オブ・トゥルースである。両者に差異がある場合はソース側が正となる。

L3 タスクレイヤーとの境界：issue Format、Issue Maturity、Sub-issue Rules は L4 の event-driven トリガーから呼ばれるが、語彙（issue 型・成熟度・ラベル辞書）は L3 タスクレイヤー（rules/task/task.md）が正本である。本文書からは L3 を参照する形にする。

---

イベント駆動トリガー

(→ rules/operations/operations.md の [TRIGGER_INDEX] + 各 skill)

トリガー	対象セクション	権威ソース
act_now	ブランチとラベルフロー	skills/operations-on-branch/SKILL.md
on_issue_create	Issue Format	rules/operations/main-agent-procedures.md の ## Issue format（起票は Parent retains のため常駐面が正本）
on_issue_edit	Issue Format	同上
on_issue_view	Issue Maturity	skills/operations-on-issue-maturity/SKILL.md
on_issue_sub	Sub-issue Rules	skills/operations-on-sub-issue/SKILL.md
on_commit	コミットとプッシュ + docs 同期	skills/operations-on-commit/SKILL.md + skills/operations-on-docs-ownership/SKILL.md
on_pr	PR 作成	skills/operations-on-pr-creation/SKILL.md
on_ci	CI ループ	skills/operations-on-ci/SKILL.md
on_review	PR レビュー	skills/operations-on-pr-review/SKILL.md + skills/task-pr-review-judgment/SKILL.md（判断側、L3） + rules/operations/main-agent-procedures.md の ## Review approval check（承認待ちの手順）
on_merge	マージ	rules/operations/main-agent-procedures.md の ## Merge Execution
on_release	人間確認が必要な操作 / リリース	skills/operations-on-release/SKILL.md
on_release_state	release state フラグ（prerelease / latest）の付与・変更・一括正規化	skills/operations-on-release-state/SKILL.md
on_wiki_sync	リリース後の docs → wiki ミラー同期	skills/operations-on-wiki-sync/SKILL.md
on_webhook_intake	フォアグラウンド webhook 取込	rules/operations/main-agent-procedures.md の ## Foreground webhook notification intake（実行主体がメインのみのため常駐面が正本）
on_long_output	長 output / 出力途切れ	skills/operations-chat-output-limit/SKILL.md
on_discussions_reference	Discussions 経路	skills/operations-discussions/SKILL.md
on_session_boundary	session 境界での引き継ぎ	skills/operations-handoff-continuity/SKILL.md
on_notifications_api_call	notifications API 直接操作	skills/operations-notifications-api/SKILL.md

サブエージェント委任

(→ skills/task-subagent-delegation/SKILL.md（L3、L4 から cross-layer 利用。委任プロンプト作成は skills/task-subagent-prompt/SKILL.md、spawn パラメータは skills/task-subagent-spawn/SKILL.md、subagent 側 lifecycle label は skills/task-subagent-state-labels/SKILL.md）)

長時間セッションでの注意劣化対策として、全 operations トリガーの手順実行をサブエージェントに委任できる。サブエージェントは毎回新鮮なコンテキストで rules/operations/*.md と skills/operations-on-*/SKILL.md を読むため、注意の薄まりが発生しない。

サブは手順を実行して結果を報告する。メインは報告を受けて判断する。PR レビュー判断基準はタスクレイヤー（skills/task-pr-review-judgment/SKILL.md）に置き、メインが operations 系 skill を直接読む場面をゼロにする。メイン自身が実行主体になる手続き（セルフレビューの formal record、マージ）は常駐面の rules/operations/main-agent-procedures.md が正本であり、これが禁止と対になる（「メインエージェントの手続き」節）。

サブエージェント機能は最適化であり必須ではない。使えない環境では従来通りメインが実行する。委任の詳細（何を伝え、何をメインに残すか、モード別スコープ）は L3 の権威ソースに従う。

---

ルール

(→ rules/operations/operations.md の ## Operations Rules)

破ったら壊れる一文一制約。理由・条件なし。

• issue リンク（gh issue develop）は常に必須。GitHub への初回 push より前に実行する
• 親 issue = 1ブランチ。sub-issue ごとの個別ブランチは作成しない
• sub-issue を持つ親 issue = 親 PR 1本。sub-issue ごとの個別 PR は禁止
• コミット単位の CI 可視化は draft PR を親ブランチ上で早期に open することで実現する（PR を分割しない）
• コミットタイトル = ASCII 英語のみ、1行
• コミットボディは省略不可
• コミットボディに含めるもの：変更要約 + 意図または背景 + issue 参照
• コミットボディに LI_PLUS_PROJECT_LANGUAGE の文を最低1文含める
• PR タイトル = ASCII 英語のみ、1行
• PR ボディ = LI_PLUS_PROJECT_LANGUAGE
• PR ボディに issue 参照を含める
• issue 参照の形式 = #<issue番号>。# の前置は形式の一部であり、issue <番号> や裸の <番号> は issue 参照ではない。issue 参照が要求される箇所すべてに適用する
• 上記2本のタイトル行は body 行とは別の軸に乗る。そこでの ASCII 英語は1行タイトルに対する GitHub 側の慣行であって LI_PLUS_PROJECT_LANGUAGE が解決する値ではなく、project language が他の言語である workspace でもタイトルは ASCII 英語のままである。body 行を契約参照として読みながらタイトル行までパラメータ化してしまうのが、この一文が抑える誤読である
• body 行が解決するのは host workspace に対してである。Workspace_Language_Contract（adapter/claude/CLAUDE.md / adapter/codex/AGENTS.md）はその到達範囲がどこで止まるかの正本であり、述べているのは止まる位置だけである（They do not change LI_PLUS_REPO governance）。その先で何が governance するかは定めていない。したがって操作対象のリポジトリが LI_PLUS_REPO のリポジトリ自身である場合、LI_PLUS_PROJECT_LANGUAGE はその body 言語へ届かず、届くものは同リポジトリ自身の governance が定める。ここへ写さず、そちらを読む。直上のタイトル行と1組をなす——あちらは固定されているものをパラメータ化する誤読を抑え、こちらはこれらの行が配布されてきた当のリポジトリを操作しながら body を配布先の値で解決してしまう誤読を抑える
• 実装変更を含む PR は、対応する docs/ の更新を同一 PR 内に含める。分割は禁止
• docs/ を正本とする。Wiki は反映先であり、正本にしない。この行の docs/ は、リポジトリの番号付き要求仕様書とアルファベット付き参考文書を指す。skills/evolution-persistence-tiering/SKILL.md の docs-tier（wiki を含む永続度の階層名）とは同じ語で別の軸である
• 例外は Decision Structure entry。実体は Decision_Structure_Write_Autonomy により wiki へ直接書かれ、他のどこにも存在しないため、この entry については wiki が正本である。docs/Decision-Structure.md が持つのは運用 index のみ。仕様は docs/Decision-Structure.md を正本とし、ここには写さない
• リリース後の Wiki 同期は必須。省略は禁止。Wiki 同期はリリースフロー完了の gate
• 要求仕様書は実装後のフォローアップではない。実装前に作成・更新する
• PR タイトルには変更の影響範囲を含める
• AI の gh release create デフォルトは state フラグなし（prerelease=false、latest=false）
• prerelease フラグは AI の裁量オプション。明示的なテスト期間を取りたい時のみ付与する。タグ名は最終形のまま（alpha.N / rc.N / -pre などの suffix は付けない）。昇格時はフラグを外すだけでタグは作り直さない
• latest フラグは人間専用。実機検証後に gh release edit {tag} --latest=true で人間が flip する（判断 ↔ 実行軸：「人間専用」「人間が flip する」は判断主体を指す表記であって CLI 実行主体ではない。human が判断し、明示的な go-sign 後に AI が gh CLI を実行する。詳細は本ドキュメントの「human 判断ゲート」節）
• リリース body は GitHub generated release notes を使う（--generate-notes を渡す。--notes "" で空 body を渡さない）
• mark_processed は消費した全 webhook イベントに対して必須。省略すると backlog が蓄積する
• 実行主体がメインエージェントになりうる手続きは、operations-* skill ではなく rules/operations/main-agent-procedures.md を正本とする（下の「メインエージェントの手続き」節）

---

メインエージェントの手続き

(→ rules/operations/main-agent-procedures.md)

アダプタの一文「Main never reads operations skills directly when subagent is available.」（adapter/claude/CLAUDE.md / adapter/codex/AGENTS.md）は、単独で置かれた禁止ではない。原型の #881（5333c16）は、この禁止と同時に「メインが必要とするものは常駐で持てる層へ移す」措置を入れている。意図は役割分離（サブが手順を実行し、メインは報告を受けて判断する）であって、コンテキスト節約ではない。

対を明文で置く：この禁止は、実行主体がメインエージェントになりうる手続きのすべてが、メインの読める面に正本を持っているあいだだけ成立する。 メインが読める面 = skills/operations-*/SKILL.md を除く Li+ の全面。サブエージェントは全面を読むので、メインが読める面は両者が届く面でもあり、そこに置いた正本はもう一方のために写しを作る必要がない。

operations-* skill に、実行主体がメインになりうる要求が加わった時点で適用する維持ルール：正本をメインの読める面へ移し、skill 側にはポインタを残す。誤った修復は2つ。

• 写しをメインの読める面にも置き、skill 側にも残す —— 二つ目のコピーが drift する
• 「メインが実行主体のときは読んでよい」と禁止の射程を絞る —— 禁止が存在する理由である役割分離を捨てることになり、しかも要求は依然として pull 面にあるため、実行主体はすでに動き始めてからしかそこへ届かない

検出サイン：operations-* skill の中に、実行主体がモード依存で書かれた手続き、あるいは「マージ判断を持つエージェント」と書かれた手続きがある。それは auto / semi_auto では親である（skills/task-subagent-delegation/SKILL.md の Rules）から、要求は実行主体が読めない場所に着地している。本ルール成立以前に3例が実測されている（#1708、いずれも semi_auto）：セルフレビューの formal record とマージ手続きはここへ移し、再開プロンプトの停止条件は移さない —— その literal の実行主体はサブエージェントであり親は運び手にすぎないので、親はリテラルではなくポインタを運ぶ形にした（skills/task-subagent-prompt/SKILL.md Resume-phase authority boundary）。

4例目（#1714）は、ルールに先行したのではなく検出サイン自身が捕まえた最初の1件である：承認待ちの確認手順（Review approval check）を「PR レビュー」節の指す常駐面へ移した。#1713 がこのサインを実装している最中に発見され、その PR の射程外に置かれたため、サインは既知の陽性を1件抱えたまま出荷されていた。サインに捕まったことは修復の中身を変えない —— 適用する維持ルールも移設の形も同じである。

修復の分岐は正本側に基準として置いてある：メインが自分で実行しなければならない要求は正本ごと移し、メインが運ぶだけの要求はポインタを残す。 後者は literal の実行主体がサブエージェント側にある形であり、正本は skill 側に留まる。

正本の移設は半分にすぎない（#1762）

skill は description が場面に合致することで起動する。したがって正本が抜けたあとも description がメインの立つ瞬間を名指したままなら、skill はメインを引き込み続ける —— 禁止を破るのはエージェントの選択ではなくファイル自身のトリガーであり、移設は違反を修復したのではなく改名しただけになる。残り半分は、description を その skill に残る読み手 まで絞ること。残る読み手はサブエージェント、およびサブエージェント不在フォールバック時のメイン（skills/task-subagent-delegation/SKILL.md の Autonomy）である。後者はサブエージェントが存在しないときにのみ発火し、それは禁止が適用されない条件そのものなので、そこへ絞った description は禁止に抵触しない。

どちらの読み手も残らない skill は空であり、ポインタとして残さず削除する。ただし読み手以外に1つだけファイルを支えるものがある：編集できないポインタの解決先であること。 削除するとポインタが宙に浮くため load-bearing であり、その場合は「起動条件を持たない」と宣言するリダイレクトスタブとして残す。

編集できないアダプタリテラル（#1762）

adapter/claude/CLAUDE.md / adapter/codex/AGENTS.md の ## Optional Webhook Notification Flow ブロックはバイト単位で凍結されている。Li+update.md が、インストール済みファイルから剥がす legacy trailer をこの同じブロックから導出するため、ここが drift すると移行前インストールに対する migration が黙って壊れる。禁止を満たすためにアダプタを編集することは、ガバナンス上の欠陥を実働の migration 欠陥と交換する取引になる。

rules/model/axis-separation.md は層をまたぐ矛盾を「上位が勝つ」で決着させず境界の修理へ差し戻すので、リダイレクトは rules/operations/main-agent-procedures.md 側が持つ。検出サイン：禁止と同じ sentinel 区画の中に、operations-* skill を方針の所在として名指すアダプタ行がある。

実測3例（#1762）

• skills/operations-foreground-webhook-intake —— 実行主体はメインのみ（発火の瞬間がユーザー turn の開始であり、サブエージェントは turn を持たない）。2026-08-16 のセッション冒頭、サブエージェント利用可能な状態でメインが実際に起動した。正本を常駐面へ移し、skill はリダイレクトスタブとして残した（凍結アダプタ行の解決先であるため）。
• skills/operations-on-issue-format —— skills/task-subagent-delegation/SKILL.md の Rules が issue creation / issue management をモード分岐なしで Parent retains に置く。正本を常駐面へ移し、skill はポインタとして残した（サブエージェントは実装中の issue body 更新と失敗報告コメントで到達する）。
• 本 issue の起票そのもの —— 2例目と同一経路。同じ移設で解消される。

---

自走 (autonomous run) の停止条件

(→ rules/operations/operations.md の ## Autonomous Run Stop Condition)

AI が人間の介在なしに走る場合（夜間、semi_auto / auto モードで deploy まで到達するケース）、「deploy 成功」は停止条件にならない。静的検証（TS check、unit test、CI）は runtime 正しさを保証しない。subrequest 上限、IPC、rate limit、schema migration の副作用などの runtime 経路は、静的検証とは別軸に存在する。

production に到達する自走では、以下を最終ステップとして必ず実行する：

• deploy 完了後、production log を最低 5 分観測する
• cron 駆動のワークでは、「deploy 完了」とは「deploy コマンドが exit 0 で終わった時点」ではなく「deploy 後の最初の cron 周回が log で観測できた時点」を指す
• ホストの logs surface（ブラウザの dashboard、wrangler tail、同等の CLI）を使う。事前付与済みのブラウザ権限は、人間監視下のセッションのために留保するのではなく、自走中に積極的に活用する

アンチパターン：「human が朝に確認するから、自走の post-deploy 観測は不要」。検出タイミングの利得（夜間検出 vs 朝検出）こそ自走が提供すべき価値であり、観測を省略するとその価値を放棄することになる。

停止条件が誤適用されている兆候：

• deploy 成功の瞬間に走完サマリを書き始めている
• 自走自身が verify する前に「人間が見てくれる」を理由にしている
• dashboard / log アクセス権限が事前付与されているのに自走中に未使用
• 走完報告が cron interval 1 周分より短い時間で提出されている

---

責務

条件→行動。省略不可。AI が条件を判断し、条件に合致したら必ず実行する。

ブランチとラベルフロー

(→ skills/operations-on-branch/SKILL.md)

着手意思は対話の空気から判断する。チェックリストで確認しない。不明瞭な場合は機械的にではなく、感じをもって聞く。

タイミング	ラベル	ブランチ
NOW（今やる）	in-progress	作成する
SOON（近いうち）	backlog	作成しない
SOMEDAY（いつか）	deferred	作成しない

上表が決めるのはどの tier に当たるかであり、in-progress 遷移が何で構成されるかではない。その遷移はラベル単体であり、skills/task-subagent-state-labels/SKILL.md Work start が正本である（タスクレイヤー仕様書「actor 軸（issue assignee）」）。

ライフサイクルラベルは「いつ着手するか」、成熟度ラベルは「どこまで収束したか」。ライフサイクルラベルを成熟度の代用にしない。

空気読みは timing tier 判定（NOW / SOON / SOMEDAY）にのみ適用する。label 付与は tier 結果からの決定的な写像であり、空気読みの二度目を伴わない。tier が決まればラベルは上表に従って機械的に付与する。

trigger mode でも issue の作成・本文更新とブランチ準備は待たない。人間トリガーの対象は実装開始と PR レビューである。

ブランチ作成

(→ skills/operations-on-branch/SKILL.md)

gh issue develop は親 issue のみに対して実行する。sub-issue（子・孫・…）は親ブランチ上でコミットする。親ブランチは gh issue develop で親 issue にリンクされるため、そのブランチからの PR マージは親を自動クローズする。これは single parent PR flow（後述「sub-issue ルール」参照）の下では意図通りの挙動である。親 PR 1本のマージは全 sub-issue 完了後に行われるため、親の自動クローズもそのタイミングで正しく発火する。

sub-issue ごとに親ブランチ上で個別 PR を作る運用は禁止する。最初の PR が merge された時点で、残りの sub-issue が未完了のまま親が自動クローズされるためである。独立ブランチ・独立 PR が必要な単位は sub-issue ではなく sibling issue として切る。

ブランチ作成前にローカルとリモートの存在確認を行う。リモートに既存ブランチがある場合、後からリンクは張れない。

# 存在確認
local:  git branch --list {branch-name}
remote: gh api repos/{owner}/{repo}/branches/{branch-name}  # 404 = not exists

# ブランチ作成 + issue リンク
gh issue develop {issue_number} -R {owner}/{repo} --name {session-branch} --base main

ブランチ作成は assignee 手順を持たない。actor 軸が発火するのは親の委譲の瞬間であり、ブランチ作成の時点でも in-progress 遷移の時点でもない（タスクレイヤー仕様書「actor 軸（issue assignee）」／ skills/task-subagent-delegation/SKILL.md ルール、フィールドの読み方は skills/task-subagent-state-labels/SKILL.md Actor axis）。

ローカルエラー時の対処：gh issue develop がローカルで失敗してもGitHub 側では成功する場合がある。リンク済みブランチを確認してから判断する。

gh api graphql -f query='{ repository(owner:"{owner}",name:"{repo}") { issue(number:{number}) { linkedBranches { nodes { ref { name } } } } } }'

リンク済みならそのブランチを使用する。リンクなしならリトライまたは人間にエスカレーションする。

sub-issue ルール

(→ skills/operations-on-sub-issue/SKILL.md + rules/operations/operations.md の親子 PR 制約)

sub-issue は AI が追跡する作業単位。粒度ではなく責務で分ける。

sub-issue か sibling issue かの分類リトマス

問い：「この単位は親の atomic deliverable を壊さず独立に ship できるか？」

答え	分類	運用
Yes（独立 ship 可）	sibling issue	親子ではなく独立 issue として立てる。各 issue が自前のブランチと PR を持つ
No（親と一体で初めて意味を持つ）	正当な sub-issue	親ブランチ上でコミットし、親 PR 1本に合流させる

独立に ship できるなら sub-issue にする意味がない。「sub-issue ごとに別 PR で独立に出したい」と感じた時点で、それは元々 sibling issue にすべき単位だったというシグナルである。PR を分割するのではなく、分類を見直す。

single parent PR フロー（本筋、#919 原設計）

sub-issue を持つ親 issue は、以下の構造で運用する：

• 全 sub-issue のコミットを1本の親ブランチに蓄積する
• 親ブランチに対する PR は親 issue あたり1本だけ、main へ向けて作成する
• sub-issue はその1本の PR の中で処理される
• コミット単位の CI を見たい場合は、最初のコミット push 直後に親 PR を draft で open する。pull_request.synchronize によって以降の push ごとに CI が走り、PR を分割せずに per-commit CI が得られる
• 親 PR の ready for review（gh pr ready {pr}）は全 sub-issue 完了と PR 本文の確定後に行う
• merge は全 sub-issue 完了後に1回だけ行う
• parent auto-close はこの構造下では正しく働く：親 PR の merge は最後のイベントであり、その時点で全 sub-issue は既に closed になっている

sub-issue ごとに個別 PR を作る運用は禁止する。親ブランチ上で複数 PR を連続 merge すると、最初の merge で親が自動クローズされ、残りの sub-issue が未完のまま親が閉じる事故が発生する（観測: github-webhook-mcp#198 / PR #203）。

並列性と分類

同一セッション内で複数のタスクを並行で扱う場合は、独立 issue の並列作成ではなく親子構造（親 issue + sub-issue）にする。複数 ready issue のファイル重複分析は target files で判定する。

重複	判断
なし	並列安全。並列 sub-issue 構造を人間に提案
部分重複	共有ファイルへの変更を統合 sub-issue に分離して提案
統合 sub-issue	並列 sub-issue 完了後に直列実行（依存順序あり）

target files が issue body に無い場合は、purpose と premise から推定する。

ドキュメント同期と要求仕様の責務

(→ skills/operations-on-docs-ownership/SKILL.md)

配布向けプロジェクトでは、最低限の docs/ として要求仕様書を持つ。新規・小規模プロジェクトではまず1ファイルの要求仕様書を作ればよい。規模が大きい場合は分割してよい。

実装を始める前に、対応する要求仕様書を先に作成または更新する。挙動変更・バグ修正・仕様変更では、まず要求仕様書の該当箇所を変更し、コードとテストはその仕様差分を実装・検証するために更新する。

Li+ の挙動や運用ルールに効く判断は、番号付き要求仕様書（1–9）と対応するプログラムファイルへ固定する。補助メモや実験ログを残してもよいが、それを正本にしない。要求仕様書は可読性が向上する場合に分割してよい。

spec（Li+*.md）または動作コードを変更するコミットでは、docs/ に対応する更新があるか確認する。未更新であれば push 前に追加する。別 PR への分離は禁止。

同期が必要な集合のメンバーを 1 つ編集するときは、編集の前後で grep-sweep を pair で実行する。編集前に所属する集合全体を grep して全メンバーを列挙し（記憶ではなく列挙から編集対象を確定）、編集後に同集合を再 grep して旧形のメンバーが残っていないことを確認する。典型的な集合 = docs mirror 同期対象（docs/ とその wiki mirror）/ parity 全 block（claude CLAUDE.md ⇔ codex AGENTS.md 等）/ 同一規範文の全出現箇所。

PR タイトルの良い例・悪い例：

# bad:  fix(config): negative duration handling
# good: fix(config): treat negative durations as below-minimum rather than error

コミットとプッシュ

(→ skills/operations-on-commit/SKILL.md)

プライマリは git push。git が使えない環境では GitHub API フォールバック（blob/tree/commit/ref 作成）を使う。複数ファイル時は tree 作成後にファイル数を検証し、減少していた場合はコミット中止する。

# プライマリ
git push origin {session-branch}:{target-branch}

# フォールバック（単一ファイル）
gh api repos/{owner}/{repo}/contents/{path}  # PUT base64 sha

# フォールバック（複数ファイル）
1. create blobs: gh api .../git/blobs  # per file
2. create tree:  gh api .../git/trees  # verify count after
3. create commit: gh api .../git/commits
4. update ref:   gh api .../git/refs/heads/{branch}

PR 作成

(→ skills/operations-on-pr-creation/SKILL.md)

親 issue あたり PR は1本（上の「single parent PR フロー」参照）。sub-issue を持つ親 issue では、すべての sub-issue と親自身を1つの PR の merge で閉じる。sub-issue ごとの個別 PR は禁止する。

draft PR の早期 open（オプション、per-commit CI 用）

sub-issue を持つ親 issue では、最初のコミットを push した直後に親 PR を draft で open してよい。

gh pr create --draft -R {owner}/{repo} --base main --head {session-branch} ...

以降の push ごとに pull_request.synchronize で CI が走り、PR を分割せずコミット単位の CI 可視化が得られる。全 sub-issue 完了と PR body 確定後に gh pr ready {pr} で ready for review に切り替える。draft PR の早期 open は必須ではなく、長期化する親作業のための利便機能である。

PR body 形式

issue ごとのブロック形式で記述する。クローズさせる issue（sub-issue と親 issue の両方）は Closes #xxx で参照する。各ブロックに2〜3行の要約を書く。詳細は issue を参照。deferred・open のまま残す子 issue は含めない。

single parent PR flow 下では、親 issue も sub-issue と同じく Closes #xxx で参照する。親 PR は最終 merge 1回で親と全 sub-issue を同時に閉じるため、親をクローズしない理由がない。

Part of #xxx は、現在の PR が最終親 PR ではない場合にのみ使う（例：別の親 issue に対して明示的に deferred な残部を先行 merge するケース）。canonical な single parent PR flow では Part of は登場しない。

GitHub の自動クローズキーワード（公式リスト）：close / closes / closed / fix / fixes / fixed / resolve / resolves / resolved。Refs はクローズキーワードではなく自動クローズしない。マージ時にクローズさせたい issue には Refs を使わない。

PR 作成後：

1. 実行中の GitHub CLI 認証 actor を PR の assignee に self-assign する：

   gh pr edit {pr} -R {owner}/{repo} --add-assignee "@me"
   

   目的：issue 側の assignee は PR エンティティに自動継承されないため、PR の Assignees フィールドに実行中の認証 actor を明示し「この PR は AI が owner」という UI 上の trail を残す。 メカニズム注記：GitHub は --add-reviewer の自己指定を silent に拒否するが、--add-assignee による PR author 自身の assignee 追加は許可される（2026-04-20 に PR #1099 で empirical 検証済）。 スコープ：assignee self-assign は UI trail のためであり、正式な self-review 記録（rules/operations/main-agent-procedures.md の ## Self-review formal record、「PR レビュー」節にも日本語での記述がある）を置き換えるものではない。

2. CI ループへ即座に移行する。人間の指示は不要。

3. マージの実行者は全モードで AI に統一されている（「マージ」節参照）。GitHub の auto-merge 機能への一般的な委譲は廃止されているが、trigger モードでは例外として PR 作成時点で --auto --squash を有効化する（下記「モード別の PR auto-merge ポリシー」参照）。

モード別の PR auto-merge ポリシー

(→ rules/operations/operations.md の PR auto-merge policy is mode-specific)

PR 作成時の gh pr merge --auto --squash 付与は実行モードで振る舞いが異なる。一律ではない。

モード	auto-merge 付与	根拠
trigger	PR 作成時点で gh pr merge {pr} --auto --squash を必須で有効化する	承認 gate は人間レビューが担う。auto-merge は承認が入った瞬間に自動でマージするだけで、毎回「merge strategy どれ？」と確認する往復を省く
semi_auto	minor / major PR には --auto を付けない（人間レビューが gate）。patch PR はセルフレビュー pass → AI が直接 merge（auto-merge 不要）	minor / major は人間レビュー必須のため、auto-merge で承認即マージしても意味がない。patch は即マージで十分
auto	repo 設定の "Allow auto-merge" を意図的に無効化する。gh pr merge --auto が enablePullRequestAutoMerge 権限不足で蹴られるのは設計通り	repo-level auto-merge が有効だと CI pass 時点で GitHub が自動マージし、parent AI のセルフレビューを飛ばす抜け道になる。Parent AI がセルフレビュー後に手動 gh pr merge {pr} --squash を実行する

auto モードで --auto --squash が拒否された場合、それは設定漏れではなく意図された状態である。「auto-merge を有効化することを提案」してはならない。Li+config.md の対象リポジトリの _EXE_MODE（例: USER_REPO1_EXE_MODE / LI_PLUS_REPO_EXE_MODE）を確認してからモード分岐する。

subagent に PR 作成を delegate する場合、parent は delegation prompt 内に mode 判定結果と auto-merge 指示を literal で注入する（subagent は parent の memory を読まない）。

CI ループ

(→ skills/operations-on-ci/SKILL.md)

CI ループは PR 作成とは独立したタスクである。PR 作成後または修正リコミット後に開始する。

step 1: 最新コミット SHA 取得

gh pr view {pr} -R {owner}/{repo} --json headRefOid --jq '.headRefOid'

step 2: 全チェックランの完了を待機

webhook 経由を優先する。

mcp__github-webhook-mcp が利用可能な場合：

• get_pending_status を60秒間隔でポーリング
• check_run の pending があれば list_pending_events → get_event で SHA 一致を確認 → mark_processed
• 全チェックランが完了するまで収集

利用不可の場合：

gh api repos/{owner}/{repo}/commits/{sha}/check-runs --jq '.check_runs[] | {name,status,conclusion}'

全ての status=="completed" になるまで sleep で繰り返す。

step 3: 結論判定

• CI FAIL = いずれかの conclusion=="failure"
• CI PASS = 全て conclusion が success / skipped / neutral

CI PASS → PR レビューへ移行。 CI FAIL → 修正してリコミット（CI ループを step 1 から再開）。ループ安全閾値（3回）を超えた場合は issue コメントに外部化し、人間に委ねる。

PR レビュー

(→ skills/operations-on-pr-review/SKILL.md + skills/task-pr-review-judgment/SKILL.md（判断側、L3）)

AI セルフレビューは全モード（trigger / semi_auto / auto）で必ず実行する。 マージ前のセルフレビュー省略は仕様違反である。セルフレビューが先に走り、必要に応じて人間レビューがその上に重ねられる（置き換えではない）。

レビューの基準は repository state first である。issue 本文、リンク済みブランチの差分、PR 本文、CI 結果を読む。ローカルで動いたことだけではレビュー完了にしない。

セルフレビュー手順（全モード共通）

実行主体は auto / semi_auto では親、trigger ではサブエージェント（skills/task-subagent-delegation/SKILL.md のルール）。前二者ではそれはマージするエージェント自身である。trigger ではマージするエージェントが居ない（「マージ」節参照）ため、実行主体は反対側から固定される——サブエージェントのセルフレビューは自身の停止点より手前に入り、その後に PR 上に立つものは無い。

その主体が PR diff を issue 要件と照合してレビューする（判断基準は L3 の skills/task-pr-review-judgment/SKILL.md）。

• セルフレビュー pass → formal review record 投稿（下記）→ モード別の人間ゲートへ。
• セルフレビュー fail → 修正してリコミット（CI ループ再開）。

委譲されたサブエージェントの停止条件（モードで割る）

（→ skills/operations-on-pr-review/SKILL.md の Delegated-subagent stop condition）

auto / semi_auto：PR open + CI green で停止する。サブエージェントはセルフレビューを実行も投稿もせず、そこで報告して終える。

この停止点には2回以上到達し、上の文言がそのすべての停止条件である。

• 1回目 = issue の変更を実装し終えた時点。以降、親は rules/evolution/initiator-autonomy.md Two-stage brake の定める位置で brake 1（PR が L1 Model Layer ソースに触れる場合は加えて brake 2）を走らせる。
• 2回目 = 指摘が PR コメントとして載った状態（brake 1 は評価者の報告を親が統合して 1 本投稿し、brake 2 も評価者に投稿面が無いため親が載せる）でこのサブエージェントを再開し、それが指摘を裁き、受入 / 却下とその理由を commit body に記録し、受け入れた分をプッシュした時点。再び CI green に到達したところでこのパスが終わる。何も受け入れなかった場合は新しいコミットなしで同じ点に到達し、裁定は報告に乗って親へ渡る。
• 3回目以降 = 親が裁定を検分し、修正を名指ししてこのサブエージェントを再開した各ラウンドの末尾。回数に上限は無く、収束判断を保持するのは親である（skills/evolution-parallel-agent-eval/SKILL.md Procedure の Inspect the adjudication）。

指摘の裁定は停止と停止のあいだで起き、再開したサブエージェントのものであって親のものではない（rules/evolution/initiator-autonomy.md Two-stage brake の Adjudication actor）。親は最後の停止の後にセルフレビューしてマージする。brake の位置そのものはここに再掲しない（日本語側の解説は進化レイヤー仕様書「実行モード」節にある）。

trigger：PR open + auto-merge enabled + CI green + self-review posted + awaiting human review で停止する。セルフレビューは全モードで人間ゲートに先行し、このモードではその実行主体がサブエージェント自身であるため、停止点より手前に入る。マージは人間の承認後に GitHub auto-merge が発火するので、サブエージェントのセッションはその前に終わる。

正本は上記の skill 側であり、他の面もそこを指している。本節はその日本語での要求記述であって二つ目の正本ではない（本書冒頭のとおり、差異があれば英語のソース側が正）。

セルフレビューの formal record 投稿（全モード、必須）

（→ 正本は rules/operations/main-agent-procedures.md の ## Self-review formal record。実行主体は auto / semi_auto では親であり、親は skills/operations-on-pr-review/SKILL.md を読まないため、正本は skill 側ではなく常駐面に置かれている）

内部のセルフレビューが pass した後、AI は結果を GitHub 上の正式な PR review として必ず投稿する：

gh pr review {pr} -R {owner}/{repo} --comment --body "<セルフレビュー結果の要約>"

目的は PR の Reviews タブに audit trail を残し、AI レビュー記録を PR 作者属性から分離すること。 実装メカニズムの注記：GitHub は --add-reviewer による self-assignment を silent に拒否する。PR author が自己レビュー記録を残す唯一の手段は gh pr review --comment（2026-04-20 に PR #1095 で empirical 検証済）。 body には以下を含める：受け入れ条件の照合結果、scope deviation（ある場合）、次ステップ想定（例：trigger / semi_auto の minor-major では「人間レビュー待ち」）。

モード別の人間ゲート（セルフレビュー pass 後）

execution_mode == auto：人間ゲートなし。セルフレビュー pass → マージへ移行。

execution_mode == semi_auto：タイプ連動の人間ゲート。

• patch → 人間ゲートなし。セルフレビュー pass → マージへ移行。
• minor / major → セルフレビュー pass 後に人間確認が必要（手順は下記「承認待ちの確認手順」）。

バージョン種別の判断軸はリリース時と同じ（「バージョン種別」節参照）。AI は PR 作成時点でタイプを提案し、判断が曖昧な場合は安全側（minor）に寄せて人間に確認する。

Per-PR exception（content-based axis） と、それを上書きする L1 brake 2 override は rules/operations/execution-mode.md の semi_auto mode: が正本である。人間ゲートを waive する前にそちらを読むこと。ここには再掲しない——過去に exception だけを写した結果、後から正本にだけ追加された override が写しに届かず、L1 Model Layer ソースに触れる PR が「patch 相当だから waive」で読める状態が残った。二つ目のコピーが drift する。

execution_mode == trigger：全 PR で人間確認が必要。セルフレビュー pass 後に下記「承認待ちの確認手順」を実施する。

承認待ちの確認手順（Review approval check）

（→ 正本は rules/operations/main-agent-procedures.md の ## Review approval check。この待ちに立つ実行主体は、ゲートを持つどのモードでも親である —— semi_auto ではゲートそのものが親のもの（skills/task-subagent-delegation/SKILL.md Rules の Parent retains: ... review judgment、および「実行モード」の Mode matrix が人間チェックを minor / major に置く）であり、trigger では委譲サブエージェントが awaiting human review で既に停止している（#1715 で確定）ため承認はそのセッションが終わった後に来る。どのモードでもここにサブエージェントは立たないので、メインの読める面に置いた正本ひとつで両方を賄える。親は skills/operations-on-pr-review/SKILL.md を読まないため、正本は skill 側ではなく常駐面にある。#1708 が名指しした3経路と同一クラスの4件目であり、検出サインが先行ではなく自分で捕まえた最初の1件（#1714））

semi_auto の minor / major と trigger の全 PR で、セルフレビュー pass の後に走る。auto は人間ゲートを持たないためここには到達しない。

webhook 経由を優先する。

mcp__github-webhook-mcp が利用可能な場合：

• get_pending_status を60秒間隔でポーリング
• pull_request_review の pending があれば list_pending_events → get_event で当該 PR を確認 → mark_processed

利用不可の場合：

• 人間がレビュー完了を通知するまで待機（ポーリングしない）
• 通知を受けたら確認：

gh pr view {pr} -R {owner}/{repo} --json reviewDecision --jq '.reviewDecision'

ここで読むのはレビュー判断の入力であって判断そのものではない。APPROVED と CHANGES_REQUESTED が何を解放するかは L3 の skills/task-pr-review-judgment/SKILL.md が正本である（タスクレイヤー仕様書「PR レビュー判断」節）。APPROVED の先のマージ経路はモード別で「マージ」節にある。

deferred 項目の follow-through

セルフレビュー記録は項目を「PR scope 外」として正当に deferred 化することがある（例：workspace memory のクリーンアップ、フォローアップ issue 起票、docs-only フォローアップ）。deferred は ignore と同義ではない：

• workspace 側の deferral（memory 編集、ローカル設定変更）は merge 直後の同一セッション内で実行する。次セッションに先送りしない
• repo 側の deferral（フォローアップ issue、関係ない掃除の別 PR）は merge 前に file しておく。merge してから後追いで作ると流れる
• 人間の APPROVED コメントに「〜したんだよね？」「did you also do X?」のような確認文が埋め込まれている場合、それは承認条件の一部であり small talk ではない。追加 gate として扱い、同一セッション内で応答する

merge は閉じ括弧ではない。deferred 項目の handoff まで完了して初めて閉じる。

マージ

(→ rules/operations/main-agent-procedures.md の ## Merge Execution。#1708 以前は skills/operations-on-merge/SKILL.md が正本だったが、その skill が発火すべき瞬間に、居合わせていて かつ 読むことを許された読者が一人もいなかった。auto / semi_auto でそこに立つのは親であり、親は operations 系 skill を読まない。trigger ではゲートが開くのは委譲サブエージェントのセッションが終わった後であり（skills/operations-on-pr-review/SKILL.md Delegated-subagent stop condition）、invoke する主体がそもそも居ない。ポインタ化ではなく削除して常駐面へ移した。trigger の merge 実行主体がどちらであるかを確定させる必要はない——そこに立つのがどのエージェントであれ、rules/** は invoke を要さずロードされるため、置き換えた skill より到達性は高い。その後 #1715 がこの問いを確定させた——マージは GitHub への handoff であり、そこに立つエージェントは居ない（下記「マージ」）。削除の根拠はそれに影響されず、それが「確定に依存しない」ということである)

マージの実行者は全モード（trigger / semi_auto / auto）で AI に統一されている。 ただしこれは actor 軸の話であり、その「AI の行為」が何であるかはモードで異なる。行為を actor から読み取ったことが #1715 まで続いたソースの割れであり、trigger で誰がマージするかの読みで4面が2対2に割れていた。

• semi_auto / auto = 直接マージ。すべての前提条件（セルフレビュー、モード別の人間ゲート、下記のマージ可能状態チェック）が揃った時点で、AI が gh pr merge（--auto なし）を実行する。
• trigger = handoff。AI の行為は PR 作成時点で GitHub auto-merge（gh pr merge --auto）を有効化することであり、マージ自体は人間の承認を受けて GitHub が発火させる。承認の瞬間にマージコマンドを実行する主体は居ないし、そこに立っている主体もそもそも居ない（「委譲されたサブエージェントの停止条件」節参照）。

モード分岐の authoritative は operations.md PR auto-merge policy。

マージ前のマージ可能状態確認（直接マージ経路のみ）

trigger では auto-merge を armed のまま GitHub がマージ可能になるのを待つ状態で PR が置かれ、確認に立つ主体が居ないため、この節は直接マージ経路の手続きである。

gh pr view {pr} -R {owner}/{repo} --json mergeStateStatus --jq '.mergeStateStatus'

• CLEAN → そのままマージへ進む。
• BEHIND → git fetch origin main && git rebase origin/main && git push --force-with-lease で CI ループを step 1 から再開。
• CONFLICTING → rebase を試行。成功なら再 push + CI 再実行。失敗なら git rebase --abort → issue コメント → 人間にエスカレーション。
• BLOCKED / UNKNOWN → 待機して再確認（GitHub が計算中の可能性）。

マージ戦略（全モード共通）

既定のマージ戦略は squash（リポジトリの慣例に従う）。直接マージ経路では AI が以下を実行する。

gh pr merge {pr} -R {owner}/{repo} --squash

trigger の handoff 経路では、同じ戦略が PR 作成時点の --auto --squash 有効化で固定される。

AI が squash 以外を選ぶ必要があると判断した場合のみ人間に確認する（pause して確認）。

PR 本文に Closes #xxx が含まれていると、マージ時にプラットフォームが issue を自動クローズする（Refs はクローズキーワードではないため自動クローズしない）。

実機テストはマージ後に main 上で行う。マージゲートにはしない。

人間確認が必要な操作

(→ skills/operations-on-release/SKILL.md の # Human Confirmation Required)

「待って」「止めて」「まって」と言われたら即座に停止する。

確認が必要な操作：

• リリース作成（バージョン種別とターゲットタグ）— 実行前に CD チェックが必要
• ブランチ削除（リンクされた issue がクローズされる可能性がある場合）
• force push
• trigger mode のみ：issue 選択、issue 実行開始

リリースチェック

(→ skills/operations-on-release/SKILL.md の ## Release checks (pre-create))

リリース作成前に以下を確認する。

CD チェック： CD PASS なら次へ。CD FAIL なら人間にエスカレートし、リリースは作成しない。

mcp__github-webhook-mcp が利用可能な場合：

• get_pending_status を60秒間隔でポーリング
• workflow_run の pending があれば list_pending_events → get_event で conclusion を確認 → mark_processed

利用不可の場合：

• gh api で全 CD チェックが完了するまでポーリングする。

バージョン種別

(→ rules/operations/release-version-rule.md 権威ソース（判定基準、always-on rules 層に移設 #1484）。Version Base Rule は skills/operations-on-release/SKILL.md。本節はその日本語ミラー)

v0.x.x は初期開発版。何でも変わりうる。v1.0.0 以降が正式版（semver 準拠）。

判断軸は「変更の規模」と「user/system から観測できるか」の2つ。

バージョン	適用条件	判断者
patch	それ以外すべて（docs / 小 fix / 小 spec / config / 内部ルール変更 / user/system から観測できない governance 構造変更）	AI が提案
minor	大きな refactor または大きな構造変更であり、かつ user/system から観測できる	AI が提案、人間が承認
major	大規模変更または大きな目標達成（フェーズ移行、プロジェクト節目）	人間が判断

重要な注記： 「構造変更 → minor」ではない。「構造変更かつ user/system observable → minor」。governance や spec rule の変更は、構造的には大きくても観測できなければ patch で扱う。本 issue (#1087) 自身がその典型で、release rule の再設計は governance 構造の変更だが Li+ ユーザーの surface から見えないため patch で ship する。

AI は patch または minor を提案する。minor / major の採用は人間が確認し、AI が実行する。バージョン番号はプレリリースを含む直近のリリースを基準にする。

Application-moment trigger（判断形成の瞬間で発動）： バージョン分類（patch / minor / major）を任意の artifact に書く直前に、本 rule（rules/operations/release-version-rule.md）を literal 再読する。再発失敗は minor の "large" 修飾子省略 — observable な変更を minor と誤分類するが scope は incremental（つまり patch）というケース。詳細は skills/model-trigger-check-gate-actions/SKILL.md の Trigger moments を参照。

リリース術語の解釈優先順位

(→ rules/operations/operations.md の Release terminology interpretation ladder)

「プレリリースタグ」「stable タグ」等の人間発話は、GitHub Release の prerelease フラグ（boolean 属性） を指すものとして第一解釈する。git tag オブジェクトや release entry そのものの削除を指すとは解釈しない。

「〜を削除で」「〜外して」等の曖昧な発話は、release 属性変更 vs release 削除 vs git tag 削除で挙動が全く異なる。より保存的な解釈を先に試し、literal delete は最後に置く。

順位	解釈	例
1	属性・フラグ変更（最も保存的）	prerelease → stable 昇格、draft → published、latest flip
2	可視性変更	archive、hide、unlist
3	新 release で置換	supersede、後継 release で deprecate
4	明示確認（停止して人間に問う）	上記で解釈不能な場合、destructive 操作の前に確認
5	文字通りの削除	人間が明示的に「削除」「消す」「unpublish」「tag 削除」と言った場合のみ

「削除」指示に対して step 4（明示確認）で必ず停止する対象成果物： GitHub Release、git tag、npm / PyPI / crates.io のバージョン、merge 済み PR（close は削除ではない）、main ブランチ（revert は削除ではない）、公開済み docs、公開済み wiki。これらは公開済みかつ不可逆性の高い成果物であり、確認前の literal delete は禁止する。

復元手順（git tag を誤って削除した場合の参考）：

git for-each-ref refs/tags/...                       # ローカル保持 SHA 確認
git push origin refs/tags/{tag}                      # tag 復元
gh release create {tag} --generate-notes --latest=false  # release 復元

リリース state ルール（バージョン種別とは独立した軸）

(→ skills/operations-on-release-state/SKILL.md の # Release State Rule 節)

state は version type（patch / minor / major）に依存しない独立 axis として扱う。

state	既定値と意味	操作者
default（state フラグなし）	gh release create の既定。prerelease=false、latest=false。version type に関係なく AI はこの default で出す	AI
prerelease	AI が明示的にテスト期間を取りたい時のみ付与する裁量フラグ。タグ名は最終形のまま（alpha.N / rc.N / -pre などの suffix は付けない）。昇格時はフラグを外すだけでタグは作り直さない	AI
latest	実機検証済みを示す。version type（patch / minor / major）に関係なく実機テストが gate。gh release edit {tag} --latest=true で flip	人間のみ（判断主体）

判断 ↔ 実行軸：上表の「人間のみ」は判断主体を指す。CLI（gh release edit ... --latest=true）を打つのは AI で、human が明示的な go-sign を出してから AI が実行する。詳細は本ドキュメント「human 判断ゲート」節を参照。

AI の canonical release 作成コマンド

AI が release を作成する際は、以下の形を canonical とする。

gh release create {tag} \
  --target main \
  --title {version} \
  --generate-notes \
  --latest=false

--latest=false は明示必須。省略すると gh CLI の default は legacy（semver + date の auto-pick）に fallback し、新 release が Latest に昇格してしまい、既存の Latest anchor を黙って降格させる。

Latest anchor 要件

repo には常に1つ以上、explicit Latest な release（make_latest=true）が存在している必要がある。この release を Latest anchor と呼ぶ。

anchor が不在の状態で新 release に --latest=false を渡しても、legacy default に巻き込まれて無効化され、新 release が Latest 化してしまう。anchor は「各 release の属性」ではなく「repo 全体の persistent な state」として扱う。

Anchor flip 手順（人間、実機検証後）

gh release edit {new_tag} --repo {owner}/{repo} --latest=true

GitHub の one-Latest-only 制約により、旧 anchor は自動で Latest badge を失い、default（state なし）に遷移する。新 release が Latest anchor に昇格する。タグ名は flip 前後で不変で、state のみが移動する。

Bootstrap / transient state

repo の初回非 prerelease release、または anchor 消失時は、GitHub が legacy auto-pick によって一時的に最新 release を Latest 化する。この transient Latest state は、人間が explicit Latest anchor を設定した時点で one-Latest-only 制約によって自然に解消される。

この transient Latest は AI が意図的に付けた state ではなく、プラットフォーム側の default 挙動であり、governance 上の判断ではない。

一括 state 正常化

既存の複数 release を一括で default（state なし）に正常化する場合、先に1つを anchor（--latest=true）に固定してから、他を --latest=false で PATCH する。順序を逆にすると anchor 不在の状態で --latest=false が無効化され、ターゲットのいずれかが再び Latest 化してしまう。

リリースルール

• リリースタグ・タイトルはプロジェクト固有の規約に従う
• リリース body は GitHub generated release notes を使う（--generate-notes を渡す。--notes "" で空 body を渡さない）

バージョン番号はプレリリースを含む直近のリリースを基準にする（latest stable のみではない）。

gh release list --limit 1  # プレリリースを含む

リリースタグ・タイトル規約

(→ skills/operations-on-release/SKILL.md の # Release Tag and Title Rule 節)

プロジェクトの docs/ または CI/CD 設定を確認してから作成する。

プロジェクト種別	タグ形式	タイトル形式
Li+ language（デフォルト）	build-YYYY-MM-DD.N	{version}（例: v1.9.0）
npm パッケージ	v{semver}	v{semver}

CD workflow がタグを作成するプロジェクトでは、既存の CD 作成タグを使い、新規タグを作らない。npm version を使うプロジェクトでは、npm version コマンドがタグを作成する。

リリース後の Wiki 同期

(→ skills/operations-on-wiki-sync/SKILL.md)

リリース公開後、docs/ を GitHub Wiki にミラーする。同期はリリースフロー完了の gate であり、省略は禁止。

所有境界

• docs/ 所有 = docs/ 直下のすべての *.md。配置場所が決め、ファイル名は参照しない。docs/ が正本で、同期後は Wiki 側と byte 単位で一致する。docs/installation.md は docs/4.-Operations.md と同様に docs/ 所有である。docs/Decision-Structure.md は index する entry がすべて Wiki 専属であっても docs/ 所有側に置く。adapter/claude/hooks/on-session-start.sh が cold-start 素材として docs/ 側を読むため、Wiki 側に寄せて docs/ 側を畳むことはできない。直下のみ — Wiki の名前空間はフラットであり、入れ子の docs/**/x.md は Wiki 側に counterpart を持たないので同期の対象外
• Wiki 専属 = 明示リストであり、以下で閉じる。docs/ に counterpart を持たない。同期はこれらを copy も delete もしない
  • _Sidebar.md。docs/ から生成する同期手順は存在しない。リストに載るナビはこれだけである。Home.md と _Footer.md は docs/ にあるため、配置場所によってすでに docs/ 所有になっている。どちら側にも属さない Wiki ナビは unclassified として人間に上がり、その escalation がこのリストの増やし方である（リポジトリごとの慣習ではなく skills/operations-on-wiki-sync/SKILL.md の変更として行う）
  • docs/Decision-Structure.md が index する判断構造 entry すべて。本文は Decision_Structure_Write_Autonomy のもとで Wiki 側に直接書かれるため、これらについては Wiki が source である（docs/ 正本原則に対するこの例外は rules/operations/operations.md が規定する）。entry は順序 prefix を持たないので、順序はファイル名ではなく当該 index と _Sidebar.md で明示する
• それ以外の Wiki ページは unclassified である（Wiki に存在し、docs/ に無く、上記リストにも無い）。削除候補ではない。該当ページを名指しして STOP しエスカレートする（手順 3）。所有は Wiki 側からは観測できない — unclassified なページは、docs/ 側 rename の残骸（削除が正しい）か、リストが追いついていない Wiki 正本ページ（削除は正本の破壊）かのどちらかである。後者の再発形は、index 行が merge される前に Wiki へ push された判断構造 entry である。skills/evolution-decision-structure-write/SKILL.md は手順 5 で entry を Wiki へ直接 push し、docs/Decision-Structure.md の更新は手順 6 で main repo の PR flow に載せるため、この窓は異常状態ではなく通常運用である。二つの誤りのうち一方はこちら側から回復できないため、上記の所有境界の拡張は削除を決める権限を持たない。どちらであるかは人間が名指しする

所有の軸と削除の軸は別軸であり、本節が動かすのは前者だけである。どちらが source かは配置場所と明示リストで決まり、孤児を削除するかは human judgment gate に留まる（rules/operations/execution-mode.md human judgment gate — 人間が判断し、AI が実行する）。拡張された所有規則を拡張された削除規則として読むことが、Wiki 正本 entry を消す経路である

push 前検証

以下 3 つのアサーションは手順 4 の後、手順 5/6 のコミット前に実行する。いずれも失敗時は該当ファイルを名指しで人間にエスカレートして STOP し、push しない。この層で Wiki を修復もしない。sidebar drift も broken cross-reference も、先行 PR が自分の変更したものを保守しなかったということであり、release sync は再帰チェックポイントであって修復層ではない。

• git -C {tmpdir} status --short の D / M が docs/ に存在する名前のみであることを確認する。 それ以外の名前に D / M が出ていれば、手順 4 のファイル集合が所有境界から逸脱している。この逸脱が本手順の再発する故障モード。例外は 1 つ、手順 3 で人間が削除を承認したページは D が出るのが期待動作である

• Sidebar 整合性：{tmpdir}/_Sidebar.md が navigable entry を網羅参照しているか検証する。 期待 slug 集合は docs/ ローカルでも index 文書でもなく {tmpdir} ファイルシステムから構築する（両所有系統が Wiki 上に存在する形で数えるため）：{tmpdir}/*.md のすべて（slug は拡張子を除いたファイル名）。この 1 つの glob が docs/ 所有ファイルと Wiki 専属 entry の双方に届き、どちらであるかを問わない

  期待集合から除外：_Sidebar.md、_Footer.md（ナビ基盤であって被参照 entry ではない）。下記アルゴリズムで {tmpdir}/_Sidebar.md からコード記法を除去する。コード除去後の本文から、Markdown inline link の ](<slug>) target と GitHub Wiki native link の [[target]] / [[label|target]] target の和集合を参照 slug 集合として抽出する。label 付き native link は | の右側を target とし、各抽出 target の #section fragment は resolution 前に除去する。期待 − 参照 が空でなければ STOP。

• Cross-reference 整合性：{tmpdir}/*.md 内のすべての Wiki 内部リンクが実在 entry を指すか検証する。 解決集合を構築する：

  • 実在 target = {tmpdir}/*.md の各実在ファイルについて、拡張子なし slug と .md 付き完全ファイル名の両方（Home と Home.md を含む）。.md 付き target は、この列挙で対応する Markdown ファイルが実在する場合だけ解決集合へ入る。所有ごとの集合ではなく 1 つの glob で列挙するのは、このアサーションが問うのは target が実在ファイルに解決するかどうかだけであり、それは所有に依存しないため
  • 抽出 target = コード除去後の本文中の ](<x>) 出現のうち、<x> が :// を含まず、# で始まらず、/ を含まないもの。#section フラグメントがあれば剥がしてから resolution する。.md は一律に剥がさず、抽出表記のまま解決集合と照合する

  抽出 target に解決集合外のものが 1 件でもあれば STOP。両表記が有効なのは、これらの本文がリポジトリ docs/ にも mirror され、そちら側では .md 付きだけが解決するため（#1608）。

コード記法の除去（両アサーション共通）

コード内、または HTML コメント内のリンク風記法は、記法そのものの説明か描画されない markup であり、実リンクではない。この除去を飛ばすのは稀な取りこぼしのリスクではなく、全リリースで確実に偽陽性 STOP を出す。アサーションの仕様文自体（本ファイル、skills/operations-on-wiki-sync/SKILL.md、wiki entry wiki-sync-sidebar-integrity-check）がその記法でパターンを説明しているため。次の順序で除去し、各パスは本文全体に適用してから次のパスに進む：HTML コメント、次に HTML 要素、次にフェンスドコードブロック、次にインデントコードブロック、最後にインラインコードスパン。

• HTML コメント：<!-- で開始し、次に現れる --> で閉じる。閉じる --> が無ければ、コメントはファイル末尾まで及ぶ
• HTML 要素：<pre>...</pre>（block-level）または <code>...</code>（inline-level）。閉じタグとの対応は大文字小文字を区別せずに判定する。開始タグに対応する閉じタグが無ければ、要素はファイル末尾まで及ぶ
• フェンスドコードブロック：開始行はバッククォート 3 個以上、またはチルダ 3 個以上の run のみで構成される行（同じ行に info string が続くのは許容）。ブロックは、同様に同じ文字の run のみで構成され長さが開始側以上である次の行まで及ぶ。該当する行が無ければ、フェンスはファイル末尾まで及ぶ
• インデントコードブロック：4 スペースまたはタブでインデントされた行が連続する最大の範囲。インデントされていない最初の行の手前で終わる
• インラインコードスパン：バッククォート N 個の run を、次に現れるちょうど N 個の run で閉じた範囲。ちょうど N 個で閉じる run が無ければ、開始側の run はコードスパンとみなさず literal text として残す

この順序は二つの軸で load-bearing である。HTML コメントをインデント判定より先に除去するのは、コメント除去が行の先頭空白を変化させ、その行がインデントコードブロックに該当するかどうかを左右しうるため。すべての囲い込み形式をインラインコードスパンより先に除去するのは、フェンスやタグ自身のバッククォート run がインラインスパンの区切りと誤認され、無関係なテキストを飲み込むのを防ぐため。

新規 repo セットアップ（初回 sync 前のワンショット）

• 初期 docs/ に Home.md、_Footer.md、当該リポジトリの要件仕様・リファレンス文書を配置する。docs/Decision-Structure.md も含める。ファイル名の形は自由であり、docs/ 直下に置くことが docs/ 所有にする条件である
• _Sidebar.md は wiki repo 側に直接 push する。Wiki 専属であり、docs/ から生成する同期手順は存在しない
• 判断構造 entry（<topic>.md、小文字 kebab-case、順序 prefix なし）は作成時点から Wiki 側に作る。docs/ に置くと docs/ 所有のミラー対象ファイルになってしまう

手順

1. 行末正規化を無効にして Wiki リポジトリを clone し、作業ツリーを raw blob と byte 一致させる:
   git -c core.autocrlf=false clone https://github.com/{owner}/{repo}.wiki.git {tmpdir}
   Windows ホストの既定 clone は autocrlf=true が効き、blob が LF でも作業ツリーを CRLF で
   チェックアウトするため、docs/ 所有ファイルが軒並み drift 判定になり純粋な行末 churn を push する。
2. identity を設定する。clone-and-throw-away パターンは identity を継承せず、未設定だと手順 6 の
   コミットが失敗する:
   git -C {tmpdir} config user.name  "{commit-author-name}"
   git -C {tmpdir} config user.email "{commit-author-email}"
3. drift set を計算する。docs/ source と wiki 作業ツリーで内容が異なるファイルだけを列挙し、その集合
   のみを操作する。Wiki 作業ツリーへの unbounded な破壊的 glob は代替にならない。blast radius が
   Wiki 全体になり、`rules/evolution/memory-entry-format.md` の Artifact deletion calibration
   の軸で誤った側に落ちる。auto-mode classifier が拒否するのも一過性ではなく構造的な理由による。
   - to_copy = wiki 側と内容が異なる docs/ 所有ファイル（新規 + 内容変更。解決 glob: `docs/*.md`）
   - unclassified = `{tmpdir}/` に存在し、docs/ 所有でも Wiki 専属リストでもない名前。空でなければ
     該当を名指しして STOP しエスカレートする。削除せず手順 4 へも進まない。docs/ 側の rename / 削除
     もここに出るが、リストが追いついていない Wiki 正本ページも同じくここに出る。名指ししたページに
     人間の明示 go-sign が出た場合のみ `rm -f` して継続し、出なければそのページは残す。
   Wiki 専属リストの構築は、`_Sidebar.md` に加えて `docs/Decision-Structure.md` が持つ wiki link
   target から slug を抽出する（ファイル名パターンではなく index を追う）。過剰抽出はページを削除から
   守るだけ、抽出漏れは人間に上げるだけなので、この抽出の精度はどちらの向きにも load-bearing でない。
   内容比較は CR 除去後に行い、行末差だけでは drift 扱いしない（LF のみのホストでは no-op。手順 1 より
   後で CR が再混入しても行末が drift にならないようにする防御）。
   drift 計算自体が失敗した場合（`cmp` / `tr` が無い、process substitution 非対応 — bash 系シェルを
   前提とする、ファイルシステムのエンコーディング不一致）は STOP してエスカレートする。wipe パターンへ
   フォールバックしない。参照実装は `skills/operations-on-wiki-sync/SKILL.md` を source とする。
4. drift set を per-file 操作で適用する:
   for name in "${to_copy[@]}"; do cp "docs/$name" "{tmpdir}/$name"; done
   to_copy・unclassified とも空 = drift なし。commit / push を skip して手順 8（後片付け）へ進み、
   no-op を報告する。
5. 追加・削除を全てステージング: git -C {tmpdir} add -A
6. コミット: git -C {tmpdir} commit -m "sync: docs -> wiki ({release_tag})"
7. push: git -C {tmpdir} push
8. 後片付け: rm -rf {tmpdir}

push が権限等で失敗した場合は人間にエスカレートする。省略は禁止。

Windows 固有（case-only rename ハザード）

Windows ホストの wiki repo ファイルシステムは case-insensitive。Installation.md → installation.md のような rename は 1 回の git mv では適用できず、index に旧 case が残る。2 段 rename を使う：

git mv Installation.md __tmp_inst.md
git mv __tmp_inst.md installation.md

検出: git -C {tmpdir} status --short に同名で case 違いの D と ?? のペアが現れる。Linux/Mac はこのハザードを起こさないが、ホスト間で手順を同一に保つため 2 段 rename は同様に適用する。

---

責務（追加）

条件→行動。省略不可。

実行モード

(→ rules/operations/execution-mode.md)

リポジトリごとの _EXE_MODE（USER_REPO1_EXE_MODE / LI_PLUS_REPO_EXE_MODE 等、対象リポジトリ key 名 + _EXE_MODE）によって AI の自律度を切り替える。未設定の場合、セッション開始時に AI が対話で設定する。有効値は trigger / semi_auto / auto の3種。デフォルトは trigger。

モードマトリクス

軸	trigger	semi_auto	auto
着手タイミング	人間が判断	AI が判断	AI が判断
AI セルフレビュー	必須	必須	必須
人間による PR レビュー	全 PR	minor / major のみ	なし
マージ実行者	AI（--auto handoff）	AI（直接マージ）	AI（直接マージ）
リリース承認	人間	人間	人間

AI セルフレビューは全モードで必ず実行する（「PR レビュー」節参照）。 マージは全モードで AI が実行する（「マージ」節参照）。マトリクスの「マージ実行者」行は actor 軸で読む——AI の行為が何であるかはモードで異なる。trigger ではその行為は PR 作成時点での GitHub auto-merge（--auto）有効化であり、マージ自体は人間の承認で GitHub が発火させる（承認の瞬間にマージコマンドを実行する主体は居ない）。semi_auto / auto は AI 直接 merge。

各モードの運用

• trigger モード：実装開始のタイミングを人間が決める。PR は AI のセルフレビューの上に、全 PR で人間レビューが必要。実装開始の合図が出たら、ローカル専用の作業空間ではなく issue にリンクした個人ブランチを主作業面として使う。
• semi_auto モード：着手タイミングは AI が決める。PR レビューはタイプ連動。
  • patch → セルフレビュー pass で AI が即マージ（人間レビューなし）
  • minor / major → セルフレビュー pass 後に人間確認 → 承認で AI マージ
  • 狙い：自己進化ループの回転が設計目標であり、低リスク変更（patch）の人間ボトルネックを外す。minor / major には人間の目を残す。
  • 多層防御（意図的に2層）：Layer 1 = AI セルフレビュー + Li+ 仕様規律（日常的なミスを吸収）、Layer 2 = リリース時の人間ゲート（latest flip、致命的な user 露出を防止）。
• auto モード：着手タイミングも PR レビューも AI が完結。人間レビューなし。

共通事項

• issue 作成・クローズ・修正はアサイニー（AI）の責任
• 情報不足時は人間に確認する
• リリースは全モードで人間の確認が必要

human 判断ゲート（判断 ↔ 実行軸の分離）

(→ rules/operations/execution-mode.md の human judgment gate 節)

以下の操作は human 判断ゲートの対象。release create / Latest flip / force push / tag delete / マージ済み PR delete / main ブランチへの破壊的変更 / 公開済み artifact への破壊的変更。これらのゲートは判断権限に対するものであって、実行権限に対するものではない。

• human が yes / no を判断する。
• 明示的な go-sign（例：「yes」「latest にして」「両方で」）を受けてから AI が gh CLI を実行する。
• 仕様文中の「human-only」「human flips via ...」「人間専用」「人間が flip する」等の表記は判断主体を指し、実行主体ではない。
• AI の返答内で human に gh CLI を打つように指示しない。CLI は AI が打ち、human は go-sign を出す。

ゲート対象操作に対する human の発話が曖昧な場合は、最も保存的な解釈をデフォルトとして採る。先行する go-sign を別ゲートに自動拡張しない（release create の go-sign は Latest flip の go-sign ではない）。

---

自律

AIが自律的に判断して動く領域。

repo-first の作業面

(→ skills/operations-on-branch/SKILL.md の # Repo-first Execution Surface 節)

高注意で扱うのは、main のような保護された共有ブランチである。issue にリンクした個人ブランチは通常の実装面として扱う。リポジトリ全体を過度に「間違えてはいけない場所」とみなさない。

ローカル確認はブランチ作業と両立する。push の前でも後でも実行してよい。ただし、作業継続性の正本は issue にリンクしたブランチ側に置く。ローカルで動いたことだけを完了条件にしない。

引き継ぎ

(→ skills/operations-handoff-continuity/SKILL.md)

トークン上限、セッション切断、モデル切り替えなどで作業が中断されそうな時は、issue にリンクした個人ブランチへ中間状態を push してよい。引き継ぎ時の正本は、会話ログではなく issue body + linked branch + commit / PR state である。

意味のある進捗をローカルワークスペースや一時的な会話だけに閉じ込めない。

チャット出力制限

(→ skills/operations-chat-output-limit/SKILL.md)

長い出力は途中で止まることがある。物理的な制限であり、破損ではない。必要に応じてチャンキングする。

---

ラベル運用

(→ ラベル辞書の正本は L3 タスクレイヤー rules/task/task.md の ## Task Label Definitions。本節は運用ルールと廃止履歴のみ保持。L4 と L3 の ### Sync 相互参照により辞書変更時の同期義務が成立する)

ルール

(→ rules/operations/operations.md の ## Operations Label)

• すべての issue に作成時点でタイプラベルを1つ以上付与する
• すべての issue に作成時点で成熟度ラベルを1つ付与する

責務

• ライフサイクルラベルは状態変化時に適用する
• ラベルは AI の可読性とフィルタリングのためにある

廃止・改名されたラベル

ラベル	理由
done	review-pending へ改名（#1681）。close 操作と同じ「完了」を名乗り、実装フェーズ終了という意味を単体で運べていなかった

ラベルの追加・変更・廃止を行った場合はタスクレイヤー（rules/task/task.md の Label Definitions セクション）も合わせて更新する。

---

通知 API

(→ skills/operations-notifications-api/SKILL.md)

GET    /notifications?all=false                -> 200  inbox 確認
PATCH  /notifications/threads/{id}             -> 205  既読（Inbox に残る）
PUT    /notifications {"read":true}            -> 205  全既読
DELETE /notifications/threads/{id}             -> 204  完了（Inbox から除去）

scope = notifications（classic PAT）

通知 API の生操作はオペレーションレイヤーから参照してよい。ただし、前景関連性判定、claim、ack/read、consume/done、mention、cleanup の意味論は 5. Notifications を正本とする。

フォアグラウンド webhook 取込

(→ rules/operations/main-agent-procedures.md の ## Foreground webhook notification intake。skills/operations-foreground-webhook-intake/SKILL.md はリダイレクトスタブとして残る)

各ユーザー turn の開始時に webhook イベントを検査し、前景関連または特記すべき項目のみ言及する。前景関連性が安価に判定できない場合は保持して沈黙する。別 AI プロセスの起動は本フローでは禁止。

自操作の到達確認

webhook 通知には自分の操作結果（push、PR、issue、リリースなど）も含まれる。これらは GitHub への到達確認として機能する。自操作イベントはフォアグラウンドチェック時または操作直後に速やかに mark_processed する。一括クリアのために溜め込まない。外部からのイベント（他ユーザー、bot）は保持し、フォアグラウンド報告または明示的な処理フローに委ねる。

---

Discussions

(→ skills/operations-discussions/SKILL.md)

Discussions は外部ユーザーの入口。bot が常駐し、issue 作成と issue 読込が可能。コミット・コード変更はできない。

外部ユーザーが Discussions に投稿 → bot が issue を作成 → AI が issue から実装する。

---

進化

再構築・削除・最適化はすべて許容する。構造の一貫性のみ維持する。