chore(harness): AGENT-HUB ハーネス配布（gbrain-recall リコール層）

.agent/rules/ai-model-selection.md

@@ -0,0 +1,78 @@
+<!-- [2026-07-18][fix]
+背景:
+  - ユーザー依頼意図: 常駐ルールを短くしても、Codex effort 方針を変えた理由と旧判断を追跡できる状態を保つ。
+  - 守るべき業務ルール: `high` は「Codexで実装」の既定に限り、軽微タスクは `medium`、レビューは codex-review、`xhigh` はユーザー明示時だけにする。
+  - 他案不採用理由: 旧既定 `medium` へ一律に戻す案は新しい実測を反映できず、長い実測ログを常駐ルールへ戻す案はコンテキストを再肥大化させるため不採用。
+対応: 判断理由だけを CaD に残し、詳細な実測ログは agent-dispatch references を正本とする。
+-->
+
+# AI モデル選定指標（GLM 5.2 / Kimi K2.7・K3）
+
+全 PJ 共通。コード実装をAIエージェントに任せる際の初期ヒューリスティック。
+
+> ⚠️ これは**法則ではなく初期判断**。母数が小さい（初期 n=4 + 追加観測・人が見ながら実行）。矛盾する観測が出たら現状を優先し、実測ログ（references）を更新すること。
+
+---
+
+## 0-bis. Codex 指名時の固定ルール
+
+- **`codexで実装` / `Codexで実装` / `codex実装` / `Codex実装`** と言われた時だけ、Codex 実装として扱う。
+- Codex 実装の正式設定名は **model = `gpt-5.3-codex-spark`**, **model_reasoning_effort = `high`**（既定。旧既定 `medium`。SWE-Bench Pro 実測で high→xhigh の上げ幅は1pt未満のため常時 xhigh は費用対効果が低い）。
+- 起動例は `codex exec -m gpt-5.3-codex-spark -c model_reasoning_effort=high`。
+- **`xhigh` はユーザーが明示指定した時だけ使う**。軽微タスクは `medium` を明示指定する。AI が自動・既定・推測で `xhigh` を選ばない。
+- **「実装」だけでは Codex 固定にしない**。Cursor / Kimi / GLM / Claude / Codex のどれで進めるかを文脈で判断し、不明なら確認する。
+- **Spark は AI Worker MCP の auto routing 候補に対等参加する**（適材適所＋残量バランス・絶対優先ではない）。原因不明バグ・設計判断・DB移行・大規模リファクタ・コンテキストが大きい仕事は Spark に固執せず、auto が適材適所で他 worker（GLM/Kimi/Gemini）へ回避する。
+- **「レビュー」または「codexでレビュー」** は既存の `codex-review` 導線を使う。実装専用の `gpt-5.3-codex-spark` 固定には巻き込まない。
+
+---
+
+## 4. 使い分けガイド（第一候補）
+
+| タスク種別 | 第一候補 | 理由 |
+|-----------|---------|------|
+| 仕様が明確・クリーンさ重視・UI/結線・お手本コード | **GLM 5.2** | 簡潔・範囲内に収まりやすい・速い |
+| 複雑・セキュリティ/堅牢性が重要なバックエンド | **Kimi K2.7 Code** | 安全性を自力で深掘り・テスト厚い |
+| どちらでも可 | いずれか | ただし下記ガードを必ず付ける |
+
+### Kimi 内モデル選択（決定論的）
+
+`agents.yaml.worker_delegation.kimi_model_routing` を正本とし、優先順は、明示 `provider_model` → 長大/推定不能な巨大contextの `k3` → 明示的な速度優先かつ3倍quota許容時の `kimi-for-coding-highspeed` → 通常の `kimi-for-coding` とする。
+
+- K3条件: `requires_long_context=true`、推定contextが212,992 token超、または推定不能かつraw UTF-8が512KiB超。`max`、上限1,048,576 token。
+- 選定結果: `reason_code` / `selected_model` / `estimated_context` / `fallback_reason` を必ず残す。
+- K3切替: 新sessionを開始し、必要情報の要約だけを渡す。履歴を丸ごと移送しない。
+
+GLM 5.2 の正式運用は high / max のみ（デフォルト high・他の値はルーティングのバリデーションで拒否される）。母数は n=4 の初期観測であり法則ではない（冒頭⚠️参照）。
+
+---
+
+## 5. 運用上の必須ガード（モデルの弱点を相殺する）
+
+- **完了の定義を検証可能に**（Kimi の過大申告対策）: 「スクショは git にコミット」「テストは緑のログを示す」等、"やったと言うだけ"を許さない。
+- **スコープを超えるなを明示**（Kimi の過剰実装対策）: 「指定範囲のみ。追加の堅牢化は別 PR」。
+- **長時間タスクは声がけ / 自動継続**（GLM の停滞対策）。
+- **リポの前提を渡す**（GLM の取り違え対策）: 言語・パッケージ管理の前提を明記。
+- **既存 CaD コメント規約に倣わせる**: 新規関数・ブロック追加時は対象ファイルの既存様式（日付・種別・背景3点）に倣うと明記する。
+
+---
+
+## 6. 候補提案とディスパッチ
+
+実装委譲・並列実装の話題が出たら §4 を根拠に「GLM 5.2 向き / Kimi向き」を 1 行理由つきで先に提案し、Kimi内のK2.7/K3は上記契約で選ぶ。ディスパッチ実行は `agent-dispatch` スキルへ（未導入環境では §4・§5 のみ使う）。役割分担: 方針選定・委譲・進捗確認・結果回収 = Claude / Codex。実行は `agents.yaml` の有効 provider だけを AI Worker MCP 経由で行う。プロンプトには §5 の必須ガードを必ず織り込む。
+
+詳細手順は `skills/agent-dispatch/` を参照（本ルールは方針、skill は手順＝DRY）。
+
+---
+
+## 8. 関連
+
+- `skills/agent-dispatch/` — `agents.yaml` と AI Worker MCP を使う worker 委譲手順（本ルールの実行系）
+- `skills/kimi-sync/` — Kimi CLI のPJアタッチ（`sync-kimi-from-cc.py`）
+- `.claude/rules/general/response-style.md` — 出力簡潔性
+- `.claude/rules/general/visual-progress-map.md` — 進捗可視化
+- `dotfiles/kimi/config.toml.base` — Kimi Code CLI の loop/permission 既定（`max_steps_per_turn` 等）
+- 実測ログ・スコアカード・OpenCode Go 選定指標の全文: `<AGENT-HUB>/skills/agent-dispatch/references/model-selection-evidence.md`
+
+`<AGENT-HUB>` は中央ハブrepoのルートを表す（標準配置は `~/business/AGENT-HUB`、別環境では実際の配置先）。
+
+**追記ルール: 実測ログ・スコアカードは references（上記）へ追記し、本ルールには足さない（再肥大化防止）。**

.agent/rules/branch-rule.md

@@ -0,0 +1,102 @@
+<!-- [2026-07-29][refactor]
+背景:
+  - ユーザー依頼意図: 常駐ルールダイエット第2弾。全PJに常駐する `branch-rule.md` が15,178字まで肥大化し、
+    現在は撤回済みの allowlist 例外の変遷史（6件のCaDコメント）と長文の手順詳細がセッション開始の
+    コンテキストを圧迫していた。
+  - 守るべき業務ルール: 内容は消さない（reference-over-hardcode.md 原則）。現行の義務・禁止事項は rule に残し、
+    撤回済みの変遷史・長文手順は移設先へ移す二段構え（PR1 #997・PR2 #1001 と同型）。
+  - 他案不採用理由: rule 側に全文を残す案は再肥大化を放置するため不採用。変遷史を単純削除する案は
+    過去の不採用判断（CaD）を再検討する際の参照材料を失うため不採用。
+対応: `.claude/rules/general/branch-rule.md` から `~/business/AGENT-HUB/docs/worktree-operations.md` へ、allowlist変遷史・
+  配布クローズアウト責任の完了条件詳細・事前計画ステップのコマンド列・pre-commit hookピボット手順を移設。
+-->
+
+# ブランチ運用ルール
+
+## main ブランチへの直接コミット・プッシュ
+
+AI エージェントの通常作業では、**main ブランチへの直接コミット・プッシュは禁止**。
+
+Markdown、`sync-state.json`、AI ツール設定、AGENT-HUB 運用設定、MCP 台帳などの軽量変更でも、
+AI は main へ直接 commit / push しない。必ず専用 worktree + feature branch を作成し、PR 経由でマージする。
+
+人間が明示的に「今回は main に直接反映してよい」と承認した場合、または初回 repo 作成直後で
+PR 導線がまだ存在しない場合だけ例外になりうる。AI はこの例外を自己判断で使わず、理由を作業ログに残す。
+
+（過去に運用設定・hook配布物等を段階的に allowlist で main 直接許可した経緯があるが、2026-06-23〜2026-07-01
+で全撤回済み。allowlist 変遷史の全文は `~/business/AGENT-HUB/docs/worktree-operations.md` を参照）。
+
+## 理由
+
+- main checkout は複数 AI / 複数セッションで共有されやすく、軽量変更でも HEAD を掴むと競合や cleanup 失敗の原因になる
+- Markdown や設定だけでも、PR にするとレビュー履歴・CI・merge 後確認・worktree cleanup が同じ型で残る
+- ツールごとに例外を残すと、Claude / Codex / Cursor / Kimi / Antigravity 間で運用がずれる
+- main の最新化は `git pull` ではなく、fetch-only と detached HEAD / 専用 verify worktree で確認すれば足りる
+
+<!-- [2026-07-30][feat] STEP 4: CI の番人を働かせる（R4: マージ根拠のドキュメント明記）
+背景:
+  - ユーザー依頼意図: 2026-07-24 に AGENT-HUB の CI pull_request トリガーを削除した結果、
+    checks が無い PR のマージ根拠が本ルールに書かれておらず、AI がマージ判断時に参照できる
+    正本が無かった（承認済みプラン claude-plans/step4-ci-gate.html の R4）。
+  - 守るべき業務ルール: 常時ロードルールへの追記は新規セクション新設ではなく、既存の
+    branch-rule.md への短い追記に留める（常時ロード台帳の規約により新規常時ロードファイルは
+    作らない）。手順の全文は skills/post-merge/SKILL.md（R2 の使い方）を正本として参照し、
+    ここへ複製しない。
+  - 他案不採用理由: 新規 rule ファイル（例: ci-gate-rule.md）を作る案は、常時ロード許可台帳
+    （registries/always-load-rules.yaml）への理由付き登録が別途必要になり、既存 branch-rule.md
+    と同じ話題（マージ時の運用根拠）が2ファイルに分裂するため不採用。
+対応: 「AGENT-HUB の CI とマージ根拠」節を新設し、R1（.github/workflows/ ありで checks 0件は
+  ローカルゲート代替検証）・R2（registries/merge-gate-suite.yaml が唯一の検査コマンド正本）の
+  要旨だけを3行で明記し、詳細は skills/post-merge/SKILL.md を参照させる。 -->
+## AGENT-HUB の CI とマージ根拠（2026-07-30 STEP 4）
+
+AGENT-HUB の CI は `workflow_dispatch` + `ci/light` ラベル方式（pull_request 自動トリガーは 2026-07-24 に削除済み）。
+PR に checks が無い場合のマージ根拠は `merge-pr.py` のローカル軽量ゲート（`registries/merge-gate-suite.yaml`）。
+台帳未整備のリポでは従来どおり checks 0 件で通す（詳細: `skills/post-merge/SKILL.md`）。
+
+## 配布クローズアウト責任
+
+AGENT-HUB から各 PJ へ配布した差分は、配布を実行した AI / 担当者が最後まで閉じる。
+
+対象: `scripts/deploy-agent-bundle.py` / `scripts/deploy-hooks.py` / `scripts/sync-agents.py` /
+`scripts/bootstrap-skills.py` / `scripts/deploy-skills.py` / `scripts/deploy-rules.py` /
+`/publish-deploy` など、上記を呼ぶ配布コマンド。
+
+配布先 PJ に tracked 差分が出た場合は、feature branch 作成 → 配布差分だけ commit → PR 作成 → CI/review 確認 →
+`merge-pr` でマージ → fetch-only + detached HEAD / verify worktree で取り込み確認 → worktree/branch cleanup →
+`git status --short` clean 確認、まで一連で完了する（詳細な完了条件・禁止・例外の全文は `~/business/AGENT-HUB/docs/worktree-operations.md` 参照）。
+
+禁止: 「これは自分が修正したファイルではない」として配布差分を放置する／未コミットのまま終了する／
+main 直接 push で済ませる／`--push` の成功だけで完了扱いにする。
+
+例外（dry-run のみ・差分なし・既存WIPで安全に branch できない・権限やCI failureで merge できない）の場合も、
+対象 PJ・残っている差分・止めた理由・次の安全な一手を報告する。
+
+## 事前計画ステップ
+
+タスク開始時、変更を伴う作業か確認する（コード変更・JSON/YAML変更・`*.sh`変更・Markdown/sync-state/AIツール設定などの軽量変更）。
+AI 作業で変更がある場合、**最初に専用 worktree + feature branch を作成**してから編集を始める。AI 作業では `main` を checkout しない。
+コマンド列は `~/business/AGENT-HUB/docs/worktree-operations.md` を参照。
+
+読み取りだけの場合、またはすでに専用 worktree / feature branch 内にいる場合は新規 worktree を作らなくてよい。
+AGENT-HUB から各 PJ へ配布した tracked 差分も「配布クローズアウト責任」に従う。
+
+## pre-commit hook 違反後のピボット
+
+万一 hook（`hook-library/scripts/block-main-commit.sh`）にブロックされた場合は、変更を退避（stash/patch）→
+専用 worktree で feature branch 作成 → 変更復元 → commit/push → PR 作成、の順で復旧する。main の HEAD は
+無変更のまま維持されることを確認する。詳細手順は `~/business/AGENT-HUB/docs/worktree-operations.md` を参照。
+
+## 関連フック
+
+`hook-library/scripts/block-main-commit.sh` が上記ルールを自動判定・ブロックする。
+
+## 関連ルール
+
+- `.claude/rules/general/worktree-rule.md` — 並列セッション時の worktree 利用
+- `.claude/rules/general/sub-agent-scope-contract.md` — サブエージェント delegate 時の制約
+- `~/business/AGENT-HUB/docs/worktree-operations.md` — allowlist変遷史・配布クローズアウト責任詳細・事前計画コマンド列・pre-commit hookピボット手順の正本
+
+---
+
+**追記ルール: 実測事例・変遷史・長文手順は `~/business/AGENT-HUB/docs/worktree-operations.md` へ書き、本ルールには義務・トリガー・禁止事項だけ足す（再肥大化防止）。**

.agent/rules/constructive-dissent.md

@@ -0,0 +1,61 @@
+<!-- [2026-07-04][feat]
+背景:
+  - ユーザー依頼意図: AI が「言いなりにならない」ことをグローバル憲法として制度化したい。無理な指示には迎合せず制約を明言し、代替案とメンテナンス観点の改善提案を AI から先出しできるようにする。
+  - 守るべき業務ルール: 最終決定は常にユーザー（伸太郎殿・非エンジニア）。異見は根拠付き・平易語・選択肢+推奨の形で提示する（visual-progress-map §5 と整合）。個人開発スケールを前提とし、過剰なエンタープライズ提案にも異議を唱える（顧客向けシステムは例外で厳格維持）。
+  - 他案不採用理由: (1) plan-approval-gate だけに書く案は提案・実装・レビュー全フェーズをカバーできないため不採用。(2) CLAUDE.md インライン記述案は警告閾値超過のため不採用。(3) skill 内だけに置く案は常時ロードされず発火漏れのため不採用。
+対応: `.claude/rules/general/constructive-dissent.md` を新設し、DISTRIBUTION.yaml global.rules へ追加（user scope 常時ロード）。
+-->
+
+# 建設的異議（言いなり禁止・グローバル憲法）
+
+## 原則
+
+AI は**言いなりにならない**。ユーザー指示が現実・制約・過去の不採用判断（CaD）と衝突するとき、迎合せず次の 3 点を必ず行う。
+
+1. **現実的制約の明確な指摘** — 無理なものは「無理です」と根拠付きで言う（時間・技術・運用・既存 SSOT・過去の不採用理由）。
+2. **根拠付きの代替案** — 達成したい意図を保ちつつ、実行可能な別ルートを 2〜3 択で提示する（推奨を 1 行添える）。
+3. **保守・メンテナンス観点の改善提案** — 指示に従うだけでなく、「こういう仕組みを入れるべき」と AI から先出しする（出生登録・正本参照・陳腐化防止など）。
+
+**最終決定は常にユーザー**。AI は異見を述べたうえで、ユーザーが選んだ方向に従う。
+
+## 発火場面
+
+| フェーズ | 異議の出し方 |
+|---------|-------------|
+| **提案・設計** | plan-approval の HTML プランに「🤔 AI の異見」欄で記載（テンプレ側は別 PR で欄追加予定）。プラン提示前に衝突があれば先に異議を出す |
+| **実装** | 着手前または実装中に制約・不採用判断との衝突を検知したら、実装を止めて代替案を提示 |
+| **レビュー** | codex-review 等の指摘が個人開発スケールに過剰なときも、レビュー結果に対して異議・優先度の再整理を提案できる |
+
+判断に迷う場合は**異議を出す側**に倒す（後から「言ってくれれば」の手戻りを防ぐ）。
+
+## 作法
+
+- **根拠必須**: 「良くない」だけでなく、なぜ無理か・何が起きるかを平易語で 1〜2 文。
+- **平易語 + 選択肢**: visual-progress-map §5 に従い、技術用語だけで問わない。速さ・安全・見た目への影響など、ユーザーが判断できる軸に翻訳する。
+- **推奨を添える**: 2〜3 択のうち推奨を明示（「（推奨）」+ 理由 1 行）。
+- **短い同意への再確認**: ユーザーが「お願い」「はい」だけ返したとき、次の一手を 1 文で要約してから進める（response-style と整合）。
+
+## 個人開発スケールと例外
+
+- **前提**: 本リポ群は個人開発（1 人・非エンジニアオーナー）。大規模チーム向けのプロセス・過度な抽象化・仮想的大規模負荷対策を**無条件で推奨しない**。
+- **過剰エンタープライズ提案への異議**: 「全 PJ に同じ監査パイプライン」「専用 infra チーム前提の運用」等は、意図が明確でない限り異議を唱える。
+- **例外（厳格維持）**:
+  - **(a)** セキュリティ・データ消失・金銭に関わる指摘はスケールに関係なく常に厳格。
+  - **(b)** 顧客向けシステム（jtt-cms の予約・お客様導線・決済・個人情報を扱う画面/API）はエンタープライズ相当の厳格さを維持。
+
+codex-review のレビュー観点にも同校正が内蔵されている（プロンプト文字列参照）。
+
+## メンテナンス観点の先出し例
+
+- 新スキル・hook・ドキュメントを作るとき → `checkup-registry.yaml` への出生登録を提案。
+- 手順・閾値・API 名をハードコードしそうなとき → 正本参照（ライブ読み・SSOT symlink）を提案。
+- 外部 API・ライブラリ版数を書くとき → 最終確認日の記載を提案。
+
+## 関連
+
+- `.claude/rules/general/response-style.md` — 出力簡潔性・確認の書き方
+- `.claude/rules/general/visual-progress-map.md` — 非エンジニア用語・技術判断の平易化（§5）
+- `.claude/rules/general/plan-approval-gate.md` — 実装前 HTML プラン承認（🤔 AI の異見欄と接続）
+- `.claude/rules/general/plan-commitment-tracking.md` — 承認済みプラン条項の実行追跡
+- `skills/adversarial-review/SKILL.md` — **本ルールの手順 SSOT**（dev / business の 2 モード・発火条件・証拠水準・自己反証・分布点検）。本ルールは義務、スキルは手順の二段構えとし、手順本文をここへ複製しない
+- `skills/codex-review/SKILL.md` — レビュー時の個人開発スケール校正