@takuma-hirai/hirai-method 0.1.0

package/.claude/rules/why-x5-output.md

@@ -0,0 +1,97 @@
+<!--
+2026-05-23 v10 確定: 1 行 format「<何のため> のため、<何をやる> を行う」に集約。
+task-51 Step 3 (2026-05-28): Layer A/B 2 層分割。
+task-67 (2026-06-01): details.md → 断片群 (why-x5-output/) に再構造化。
+-->
+
+# 「何のために何をやるのか」1 行出力ルール (v11、2026-06-01 緩和)
+
+メインエージェントは、**各ターン冒頭に 1 回** 「何のために何をやるのか」を 1 行で先出しする。常時参照 (frontmatter 無し、毎セッション AI が読む)。
+
+> **v11 緩和 (task-68 §3.3、research §11 F2-4/F3-3/F1-5)**: v10 の「tool 呼び出し前に毎回」を「**ターン冒頭 1 回**」へ緩和。同一ターン内の連続 tool 呼び出しごとの再掲は不要 (prose↔tool 往復頻度を下げ tool-call markup 崩れリスクを減らす)。**大きな方針転換 / 別 task への移行時のみ追加 1 行可**。思考ロジック (下記) は内部で毎ステップ踏む = 透明性は維持。memory [[feedback_why_x5_once_per_turn]] と整合。
+
+> **Layer B (詳細版) Read trigger** (4 条件):
+> 1. **違反検出時**: hook BLOCK / warn 注入受領 / regex 不一致
+> 2. **規範変更時**: rule 編集 / draft 起案 / 採用 N 条改定
+> 3. **新規事案**: 初遭遇 keyword / 例外パターン疑い
+> 4. **学習 / dogfood**: task 着手前依存先必読 / harness audit / 副産物整理
+>
+> 通常運用は Layer A のみで判断、Layer B Read skip (token 節約)。
+> 詳細: 各 § 末尾 pointer から該当断片を直リンク Read (断片群: [`../rules-details/why-x5-output/`](../rules-details/why-x5-output/))
+
+## format
+
+```
+「<何のため (目的)> のため、<何をやる (今のステップ / tool / file)> を行う」
+```
+
+## 要件
+
+- **ターン冒頭に 1 回** 先出し (v11 緩和)。同一ターン内の tool 呼び出しごとの再掲は不要
+- 大きな方針転換 / 別 task 移行時のみ追加 1 行可 (それ以外は冒頭 1 行で当該ターンの作業群をカバー)
+- 装飾 (見出し / 表 / 矢印列挙 / 連番セクション) は禁止、純粋な 1 行のみ
+- 「何のため」と「何をやる」の **両方が含まれる**
+
+## 思考ロジック (必須、頭の中で踏む)
+
+可視化 (1 行出力) と同等以上に思考ロジックは重要。
+
+1. **何のため (目的)** — システム意義 / ユーザ要求とどう繋がるか
+2. **何をやる (今のステップ)** — どの tool / file / 1 ステップか
+3. **代替案検討** — 出力には書かないが、必要なら別ステップとして 1 行追記
+
+## 適用範囲
+
+- すべての作業ターン冒頭 (雑談・短い確認応答も含む) に 1 回
+- 同一ターン内で複数 tool / 複数 file を扱う場合も、冒頭 1 行でターン全体の目的×作業を表現 (個別 tool ごとの再掲不要)
+- 例外: `feedback_skip_why_x5_for_mode_command.md` 該当 command (`/mode` 等) のみ
+
+## 強制機構
+
+`.claude/hooks/why-x5-reminder.sh` (SessionStart wrapper child) が **session 開始時に 1 度**本ルールの compact pointer を `<system-reminder>` で提示する。本 rule 全文は frontmatter-less 常時参照として **毎ターン context に load 済**のため、ターン冒頭 1 行の遵守はその in-context rule に基づく (hook の毎ターン注入には依存しない)。
+
+> 起源・規範化経緯: [why-x5-output/origin.md](../rules-details/why-x5-output/origin.md)
+
+## 判定基準 (出力前 self-check)
+
+- [ ] 1 行 format か (改行 / 見出し / 連番セクションが無いか)
+- [ ] 「何のため」と「何をやる」の両方が含まれているか
+- [ ] ターン冒頭で先出しできているか (同一ターン内 tool ごとの過剰再掲をしていないか)
+
+## OK 例
+
+- 「install.sh を smoke test するため、tmp dir に実 install を実行する」
+- 「規範を v10 化するため、why-x5-output.md を全文書き換える」
+- 「user に結果を報告するため、install 完了 summary を 1 行で返す」
+
+## NG 例
+
+- 「【システムの存在意義】【whyN】【現在行っていること】【他の選択肢を取らない理由】」と 4 セクションで書く (v9 format、廃止)
+- 「何をやる」だけ書いて「何のため」を省略 (例: 「install.sh を smoke test する」 — NG)
+- 1 ステップで 2 行以上書く (例: 改行で目的と作業を分けて書く — NG)
+- **(v11)** 同一ターン内で tool 呼び出しごとに毎回 why 行を再掲して冗長化 (ターン冒頭 1 行でカバー、方針転換時のみ追加)
+
+> 拡張例 (廃止 format 4 種詳細): [why-x5-output/examples.md](../rules-details/why-x5-output/examples.md)
+
+## 一時無効化
+
+雑談セッションや短い確認のみで一時的に off:
+
+```bash
+export HC_WHY_X5_DISABLE=1
+```
+
+通常運用では **無効化しない**。
+
+## 関連 feedback memory (代表)
+
+- `feedback_why_x5_v10_one_liner.md` (2026-05-23、本 rule v10 改訂の起源)
+- `feedback_why_x5_once_per_turn.md` (v10 でも継続有効、ターン冒頭 1 回 / ステップ単位 / 未来時制)
+- `feedback_skip_why_x5_for_mode_command.md` (`/mode` 等 format 省略許可 command 規範、v10 でも有効)
+
+> feedback memory 全件 (SUPERSEDED 含む): [why-x5-output/feedback-memory.md](../rules-details/why-x5-output/feedback-memory.md)
+> v1→v10 経緯 table (full): [why-x5-output/v1-v10-history.md](../rules-details/why-x5-output/v1-v10-history.md)
+
+---
+> **project 固有の追補・override は `.claude/project-rules/why-x5-output.md` に書く** (本 file は harness 所有、`install.sh --update` で上書きされる。project 固有編集は下記 import 先へ)。
+@../project-rules/why-x5-output.md

package/.claude/rules/workflow.md

@@ -0,0 +1,157 @@
+---
+paths:
+  - "docs/draft/**"
+  - "docs/tasks/**"
+  - ".claude/commands/**"
+  - ".claude/hooks/workflow-guard.sh"
+  - ".claude/.workflow-state/**"
+---
+
+# Workflow Enforcement — 設計レビュー fan-out / テスト設計 MECE / 新規・修正 workflow / リファクタリング強制
+
+本ルールは [`development-process.md`](./development-process.md) の **後段** に位置する「品質保証 orchestration」レイヤを定義する。タスク化以降の **何を / どの順で / どこで止めるか** を W1〜W4 hook で構造強制し、reviewer 偏り / テスト観点抜け / phase skip / refactor 未実施のまま完了を防ぐ。
+
+> **Layer B (詳細版) Read trigger** (4 条件):
+> 1. **違反検出時**: hook BLOCK / warn 注入受領 / regex 不一致
+> 2. **規範変更時**: rule 編集 / draft 起案 / 採用 N 条改定
+> 3. **新規事案**: 初遭遇 keyword / 例外パターン疑い
+> 4. **学習 / dogfood**: task 着手前依存先必読 / harness audit / 副産物整理
+>
+> 通常運用は Layer A のみで判断、Layer B Read skip (token 節約)。各 § 末尾の pointer から該当断片を直リンクで明示 Read する (断片群: [`../rules-details/workflow/`](../rules-details/workflow/))。
+
+## 概要
+
+- **テスト設計 MECE** (W1): テスト観点を 20 カテゴリ MECE で user 判断強制
+- **設計レビュー fan-out** (W2): `reviewer-registry` を並列起動して観点漏れを防ぐ
+- **モジュール / システムレビュー** (W3): TDD 完了直後と全体統合後の 2 段リファクタリング強制
+- **14 / 10 stage workflow** (W4): 新規 14-stage / 修正 10-stage を `workflow-guard.sh` で `/finish-task` 段で検証
+
+## 関連 command 一覧
+
+| command | 役割 | Wave |
+|---|---|:---:|
+| [`/test-design <slug>`](../commands/test-design.md) | 設計 draft から MECE 20 カテゴリのテストカタログ生成 + user スコープ承認 | W1 |
+| [`/design-review <slug>`](../commands/design-review.md) | `reviewer_registry_design` + `_security` を並列起動して fan-out レビュー | W2 |
+| [`/module-review <module>`](../commands/module-review.md) | TDD 完了直後に 3 観点レビュー (持続可能性 / 汎用性 / 非冗長化) | W3 |
+| [`/system-review`](../commands/system-review.md) | 全モジュール統合後にモジュール間重複 / 設計乖離検出 | W3 |
+| [`/new-feature <slug>`](../commands/new-feature.md) | 新規機能 14-stage workflow orchestrator | W4 |
+| [`/modify-feature <slug>`](../commands/modify-feature.md) | 既存機能修正 10-stage workflow orchestrator | W4 |
+| [`/finish-task <id>`](../commands/finish-task.md) | 完了クローズ。`workflow-guard.sh` が state JSON を検証して BLOCK | W4 |
+
+## 新規機能開発フロー (14-stage)
+
+`/new-feature <slug>` で起動。`requirements` → `basic-design` → `detailed-design` → `test-design` → `design-review` → `user-approval` → `task-creation` → `tdd` → `module-review` → `local-test` → `system-review` → `ci-cd` → `scenario-test` → `finish` の 14 stage を順次進める。stage 名の SSoT は env `HC_WORKFLOW_STAGES_NEW` (= `harness-config.yml` の `workflow_stages_new`)。各 stage 完了時にメインが state JSON の `current_stage` を進める (Stage 7 で初期化)。
+
+> **14-stage full 表 (役割 / 起動 command) + Stage 8 TDD git log 確認義務 / Stage 10 完了条件検証 / Stage 13 UI 必須化 / Stage 12 ci-cd skip 条件**: [workflow/14-stage.md](../rules-details/workflow/14-stage.md)
+
+## 既存機能修正フロー (10-stage)
+
+`/modify-feature <slug>` で起動。`branch-decision` → `checkout` → `recover-design` → `pre-test` → `redesign` → `retest-design` → `tdd` → `module-review` → `full-test` → `system-review` の 10 stage を順次進める。stage 名の SSoT は env `HC_WORKFLOW_STAGES_MODIFY`。`/new-feature` との差分: 要件定義 / `design-review` / `task-creation` / `ci-cd` / `scenario-test` を省略し、`recover-design` / `pre-test` / `retest-design` を追加。
+
+> **10-stage full 表 + Stage 7 TDD git log 検証 / `/new-feature` との差分詳細**: [workflow/10-stage.md](../rules-details/workflow/10-stage.md) + [`modify-feature.md`](../commands/modify-feature.md)
+
+## workflow-guard.sh による強制機構
+
+> **preset aware (task-70 Phase 2)**: 本 § 以下の draft-flow / workflow / task-rule / gateguard / review-required の「BLOCK」記述は **enforcement preset** に依存する。team-default / strict では BLOCK、harness-dev (本 repo 採用) では advisory (緩和理由は `harness-config.yml` の `enforcement_matrix.<guard>.disabled_reason`)。現 effective 状態と docs/config mismatch は `bash .claude/scripts/hc-config.sh --summary`、整合は `.claude/tests/enforcement-mismatch-smoke.sh` が機械検証する。
+
+`.claude/hooks/workflow-guard.sh` は **PreToolUse(Bash)** で `/finish-task <slug>` 実行直前に発火し、構造化 JSON 解析で 2 判定 (A: `current_stage` が stage 列の最終要素か / B: `pending_findings.module_review` と `system_review` が両方空配列か) を行い、いずれか fail で **team-default / strict preset では exit 2 (BLOCK) / harness-dev preset では advisory** (`feature_workflow_enforcement_enabled`、現状は `--summary` 参照) + stderr に「問題 / 推奨アクション / bypass 手順」出力。stage 名で判定 (step 番号 / 順序判定ではない)。state JSON 構造定義は [`SCHEMA.md`](../.workflow-state/SCHEMA.md) が SSoT。
+
+> **判定ロジック詳細手順 (1〜6) / state JSON schema field 表 (型・説明) / bypass.log 集計補足**: [workflow/workflow-guard.md](../rules-details/workflow/workflow-guard.md)
+
+## Bypass と audit
+
+| 方法 | 系統 | スコープ | 痕跡 |
+|---|---|---|---|
+| `ECC_WORKFLOW_GUARD_OFF=1` | env 系統 | 1 セッション | `bypass.log` に append |
+| `HC_WORKFLOW_GUARD_ENABLED=false` | config 系統 | 1 セッション | 同上 |
+| `ECC_BYPASS_REASON='<reason>'` | 補助 | bypass 1 回分の理由を log 列に記録 | bypass.log の最終列 |
+
+両系統併存は env と config から独立に bypass 可能とし、片方が誤って enabled なまま放置される事故を防ぐ。`.claude/.workflow-state/bypass.log` は `lib/bypass-logger.sh` 経由で統一フォーマット (`<ISO-8601> | <session_id> | <hook_name> | <env_var> | <reason>`) で append、`harness-audit.py` の `bypass_log_summary()` が `/harness-audit` で最近 N 日分を集計表示。honor system: bypass 根拠は CLAUDE.md / docs/tasks/ にも記録 (env 系統だけだと持続的トレース不能)。
+
+## draft-flow-guard.sh による docs/ 直下 block (2026-05-28 緩和後)
+
+`.claude/hooks/draft-flow-guard.sh` は **PreToolUse(Edit/Write)** で `docs/` 直下 (深さ 1) の新規設計文書 Write を、対応 `docs/draft/<basename>.md` 不在で **team-default / strict preset では BLOCK / harness-dev preset では advisory** (`feature_draft_flow_guard_enabled`、現状は `--summary` 参照)。`.claude/rules/` 等への新規 Write / Edit は 2026-05-28 緩和で監視対象外 (旧 task-40 拡張撤廃、`ECC_RULE_CHANGE_GUARD_OFF` 等は dead path)。bypass: `ECC_DRAFT_FLOW_GUARD_OVERRIDE=1` (env、bypass.log 記録) / `HC_DOCS_APPROVED_DIR=<dir>[,...]` (config)。honor system: bypass 根拠は `docs/tasks/<task-N>.md` 該当 entry に記録。
+
+> **2026-05-28 緩和の経緯 (task-40 拡張撤廃) / 監視対象 path 表 / 緩和後 hook 役割 / 規範変更 honor system 降格 / 起源**: [workflow/draft-flow-guard.md](../rules-details/workflow/draft-flow-guard.md)
+
+## リファクタリング強制 (W3)
+
+`/module-review` と `/system-review` は workflow の **必須 stage**、skip は default 禁止 (workflow-guard.sh が `/finish-task` で BLOCK)。
+
+### 観点 (`/module-review` 3 観点 + `/system-review` system-level)
+
+`/module-review` は **持続可能性 (Sustainability)** / **汎用性 (Generality)** / **非冗長化 (Deduplication)** の 3 観点。`/system-review` はこれに加え system 全体で **モジュール間重複** (module 横断 DRY) / **横断的責務漏れ** (logging / error handling / observability / rate limiting / authn-authz の一貫性) / **設計乖離** (draft §3 採用案逸脱 / test-design ☒ 誤実装 / §6 DoD 充足) を検査。各観点の sub-checklist 各論は fragment 参照。
+
+### pending_findings 連携
+
+CRITICAL / HIGH findings は state JSON の `pending_findings.module_review` / `pending_findings.system_review` 配列 (id / severity / summary) に追加。**CRITICAL / HIGH 残存中は `workflow-guard.sh` が `/finish-task` を BLOCK**。MEDIUM / LOW のみ残存は user 承認のうえ `skip_log` 記録で pass 可。
+
+**yml 値による制御**: `/module-review` は `review_required_module` / `review_min_count_module` / `review_max_count_module`、`/system-review` は `review_required_system` / `review_min_count_system` / `review_max_count_system`。`review_iteration_max` は全レビュー共通。**具体値は散文に hardcode せず、起動前に `bash .claude/scripts/hc-config.sh --get review_max_count_module` 等で現在値を確認する** (値解決順 `env > harness-config.local.yml > harness-config.yml > default`)。`hc-config.sh --set review_required_module=false` で局所無効化可。
+
+> **review prompt 規約 (behavior-preserving / 末尾 confidence:0.X) / 3 観点 sub-checklist 各論 / system-level sub-checklist / MEDIUM-LOW skip フロー**: [workflow/refactoring.md](../rules-details/workflow/refactoring.md) + [`module-review.md`](../commands/module-review.md) Phase 3
+
+## テスト設計の MECE 強制 (W1)
+
+`/test-design <slug>` は承認済 draft (`docs/draft/<slug>.md`) を読み、`_TEST_DESIGN_TEMPLATE.md` から **MECE 20 カテゴリ** (単体 / 統合 / E2E / DB / 境界値 / 異常系 / 回帰 / カバレッジ計測 / 網羅性検証 / 完全性検証 / 性能 / 負荷 / セキュリティ / 互換性 / アクセシビリティ / i18n / smoke / シナリオ / chaos・障害注入 / 契約テスト) のテストカタログを `docs/draft/<slug>.test-design.md` に生成。
+
+### user スコープ承認の強制
+
+各カテゴリは user が **採用 (☑) / 不採用 (☒)** を全行決定。不採用には必ず理由を 4 種 (`scope-excluded` / `not-applicable` / `existing-coverage` / `accepted-risk`) から選ぶ。W4 実装後、`/new-task` は本 user 判断が未確認の場合 BLOCK (workflow-guard.sh の Stage 4 検証)。並列起動 agent は `tdd-guide` / `test-automator` / `qa-expert` (`reviewer_registry_test`)、3 agent 中 2 以上採用推奨で default ☑ / 2 以上不採用で ☒ / 意見割れで ☐ + 「user 判断要」。
+
+**yml 値による制御**: `review_required_test` / `review_min_count_test` / `review_max_count_test` / `review_iteration_max` で集中制御。**reviewer 並列起動数は固定 default ではなく `min ≤ N ≤ max` の範囲で動的選定**し、起動前に `bash .claude/scripts/hc-config.sh --get review_max_count_test` で上限を確認する (青天井「5+」は task-64 で廃止、値解決順 `env > harness-config.local.yml > harness-config.yml > default`)。
+
+> **20 MECE カテゴリ各論 (採用 / 不採用判定例 table) / 3 agent 投票 default 判定**: [workflow/mece-20.md](../rules-details/workflow/mece-20.md) + [`_TEST_DESIGN_TEMPLATE.md`](../templates/docs/draft/_TEST_DESIGN_TEMPLATE.md)
+
+## 設計レビューの fan-out (W2)
+
+`/design-review <slug>` は `reviewer_registry_design` + `reviewer_registry_security` カテゴリ登録 agent を **並列起動** (`run_in_background: true` 必須) し、findings を `docs/draft/<slug>-review.md` に集約。reviewer-registry (design / security / test / impl の 4 キー) と起動対象 agent の対応は `harness-config.yml` が SSoT、env (例: `HC_REVIEWER_REGISTRY_DESIGN`) で改行区切り上書き可。
+
+**並列数 / 反復制御**: `review_required_design` / `review_min_count_design` / `review_max_count_design` / `review_iteration_max` で制御。**具体値は hardcode せず `hc-config.sh --get review_min_count_design` 等で現在値確認** (値解決順 `env > harness-config.local.yml > harness-config.yml > default`)。draft レビューは「修正 → 再レビュー」を **CRITICAL + HIGH + MEDIUM = 0** になるまで反復 (LOW は許容、cosmetic finding として記録のみ)、reviewer は **3 体以上** 並列起動 (不足で user escalation)、反復上限超過時は user escalation (bypass: `ECC_DESIGN_REVIEW_OFF=1`)。各 iter の reviewer / 件数 / 修正 commit hash は draft §「レビューサイクル」table に append。
+
+> **reviewer-registry 4 キー全 agent 表 / 並列数・反復制御 yml 値 / 収束条件 table / stack heuristic 絞り込みロジック (database / API / UI 検出) / 集約フォーマット / reviewer 最低数 3 体の理由**: [workflow/fan-out.md](../rules-details/workflow/fan-out.md)
+
+## reviewer prompt 共通規約 (2026-05-28 追加)
+
+`/design-review` (W2) / `/test-design` (W1) / `/module-review` (W3) / `/system-review` (W3) + 採用 6 条 4「テスト設計レビュー」([`task-management.md`](./task-management.md)) で起動する**全 reviewer subagent prompt**の必須 5 項目。reviewer は単一 draft の inside-out 評価では不十分であり、プロジェクト全体 + 他 task 文脈を踏まえた findings を必ず提示する。
+
+1. **対象 artifact Read** — 対象 draft / test-design / module / system の全文
+2. **観点** — reviewer-registry / agent type 固有 (architect / security / qa 等)
+3. **findings format** — CRITICAL / HIGH / MEDIUM / LOW + 具体修正提案 (behavior-preserving、public API 変更禁止)
+4. **末尾 `confidence: 0.X`** — F3 confidence-gate 抽出対象 (閾値 0.6 未満は block)
+5. **プロジェクト整合性 + 他 task 影響確認** (2026-05-28 user 直接指示) — `docs/tasks/list.md` + 依存先 task.md / draft.md + `next-actions.md` + `.claude/rules/*.md` + `README.md` / `docs/INVENTORY.md` + 既存実装 (Glob/Grep) を Read し、他 task 重複・前提崩壊 / 既存 rule 矛盾 / 副産物 entry 解決機会 / 既存 hook・command・skill 再利用 / SSoT 不整合を findings に含める
+
+bypass: `HC_REVIEW_PROJECT_CONTEXT_REQUIRED=false` (項目 5 の project context 確認 skip、typo 1 行修正 / comment-only refactor / 直前 round 確認済 round-N+1 等 cost 過大ケース、honor system)。新規 feature の `/design-review` 初回 / `.claude/rules/` 編集 change / 採用 6 条 4 初回での bypass は NG。
+
+> **起源 (2026-05-28 user 直接指示) / 必須項目 5 詳細手順 + findings 観点 / OK・NG 例 / 既存規約 (behavior-preserving / confidence) との関係 / commands 連携 / 採用 6 条 4 連携 / bypass 運用詳細 / Loop モード時の動作**: [workflow/reviewer-prompt.md](../rules-details/workflow/reviewer-prompt.md)
+
+## 副産物 discharge (5 層強制機構)
+
+タスク実装中・レビュー中・セッション中に発生した「副産物 (byproduct)」を **物理的に消えない設計** で管理。詳細は [`development-process.md`](./development-process.md) §「副産物発生時の即時 draft 起こし義務」参照。5 層: (1) `docs/tasks/next-actions.md` registry (entry 追加) (2) `_TASK_TEMPLATE.md` 派生 task セクション (3) `next-actions-surface.sh` (SessionStart で未処理 entry を `<system-reminder>` 強制提示) (4) `byproduct-discharge-guard.sh` (Stop で 🔴 未処理残存なら exit 2 BLOCK) (5) `/discharge-byproduct` (entry → draft / parking-lot / 無視 の移行 helper)。bypass: `ECC_NEXT_ACTIONS_SURFACE_OFF=1` (surface 無効化) / `ECC_BYPASS_DISCHARGE_GUARD=1` (discharge-guard 無効化)、両者 bypass.log 記録。honor system: bypass 理由を next-actions.md 当該 entry コメント列に記録。
+
+> **処理フロー (entry → draft / parking-lot / 無視 の判定) / 各層機構 table / 関連 artifact / 違反パターン**: [workflow/byproduct-discharge.md](../rules-details/workflow/byproduct-discharge.md)
+
+## Loop モード自律規律
+
+詳細は [`modes.md`](./modes.md) §「Loop モード自律規律の 5 層強制機構」を参照。subagent 並走中の独立作業義務 (modes.md 遵守事項 7) と自律実行禁止 11 カテゴリ (同 8) を 5 層強制機構 (規範 / reminder hook / action-guard hook / settings 配線 / smoke) で構造防止。bypass 経路と関連 artifact も modes.md 側に集約。
+
+## Session 永続化と PM Orchestration
+
+`/sc:save` `/sc:load` `/sc:pm` (SuperClaude plugin) を `.claude/` 単独で portable な自前実装 ([`/save-state`](../commands/save-state.md) / [`/resume-state`](../commands/resume-state.md) / [`/pm-start`](../commands/pm-start.md)) に置換。Serena MCP 必須化 + SessionStart resume prompt + PDCA cycle memory 永続化を統合。各 command の Phase 1 で `mcp__serena__activate_project` を必須実行 (onboarding 未済は graceful error で `/onboarding` 案内)、`mode-session-start.sh` が `session/context` memory 存在時に `/resume-state` 提案を自動注入。memory key schema は `session/{context,last,checkpoint}` + PDCA 系 (`plan/` `execution/` `evaluation/` `learning/`) + `project/{context,architecture,conventions}`。
+
+> **memory key schema 全列挙 / Serena 必須化の設計補足 (旧 check_onboarding_performed tool 不在経緯) / 関連 artifact 完全 list / SessionStart 自動 resume 動作詳細**: [workflow/session-persistence.md](../rules-details/workflow/session-persistence.md)
+
+## 関連ルール / skill (代表)
+
+- [`development-process.md`](./development-process.md) — TDD / サブエージェント委譲 / タスク管理 (本ルールの前段)
+- [`task-management.md`](./task-management.md) — タスク管理メイン専任 / Parking Lot 運用 / 採用 6 条
+- [`self-improvement.md`](./self-improvement.md) — L1〜L5 + F1/F2 (本ルールの W は F2 verification-loop と相補)
+- [`modes.md`](./modes.md) — Normal / Loop モード (`user-approval` Stage 6 は例外)
+- [`git-workflow.md`](./git-workflow.md) — branch 命名規約 (`/modify-feature` Stage 2 `checkout` の検証基準)
+- state schema: [`.workflow-state/SCHEMA.md`](../.workflow-state/SCHEMA.md)
+
+> **全 skill 完全 list (直接関連 / 補助関連 / audit 系)**: [workflow/related-skills.md](../rules-details/workflow/related-skills.md)
+> **各規範の起源 / commit hash / 採用判断**: [workflow/origin.md](../rules-details/workflow/origin.md) (git log + 関連 draft / 副産物 entry 参照)
+
+---
+> **project 固有の追補・override は `.claude/project-rules/workflow.md` に書く** (本 file は harness 所有、`install.sh --update` で上書きされる。project 固有編集は下記 import 先へ)。
+@../project-rules/workflow.md

package/.claude/rules-details/README.md

@@ -0,0 +1,67 @@
+# .claude/rules-details/ — Layer B (詳細版) SSoT
+
+本 dir は HIRAI メソッドハーネスの規範文書 **Layer B (詳細版)** を集約する。**Claude Code は `.claude/rules/` のみを discover + startup load する** (公式 doc: [code.claude.com/docs/en/memory.md](https://code.claude.com/docs/en/memory.md))。本 dir はその discover 範囲の外側のため、startup context に**注入されない**。
+
+## 採用経緯 (task-51)
+
+`.claude/rules/<rule>.details.md` に Layer B を置き frontmatter `paths: []` で非注入を狙う初期設計は **Claude Code 仕様上成立しない** ことが claude-code-guide subagent + 公式 doc で確定 (`paths:` は path match 時の**追加適用**機構で除外機構ではなく、`paths: []` は spec undefined、frontmatter に negation pattern 不在)。
+
+→ 2026-05-28 A 案 (user 承認) で `.claude/rules-details/` 配下へ物理移動、startup から ~25K tok 削減 (実測値は移動後 fresh session で再計測予定)。
+
+## ファイル命名規約 (task-67 で断片化、2026-06-01)
+
+```
+.claude/rules/<rule>.md                    # Layer A (要約 + command/key 表 + pointer のみ、常時 startup 注入、目標 <120 行)
+.claude/rules-details/<rule>/<topic>.md    # Layer B 断片 (topic 別、明示 Read のみ、目標 <100 行)
+```
+
+- **1 断片 = 1 Layer A pointer 先 = 1 cohesive topic** (旧 `<rule>.details.md` の 1 `##` section ≒ 1 断片)。
+- `<topic>` は kebab-case (例: `14-stage`, `workflow-guard`, `mece-20`)。
+- **旧方式 `<rule>.details.md` (1 rule = 1 巨大ファイル) は task-67 で `<rule>/` ディレクトリへ分割**。「detail 1 個欲しいだけで全文 Read」を解消し on-demand Read を断片単位 surgical 化する。
+
+## link reference 規約 (task-67 断片版、断片ファイル直リンク)
+
+### Layer A → B 断片 (forward-link、Layer A 内に書く)
+```markdown
+> 詳細: [<rule>/<topic>.md](../rules-details/<rule>/<topic>.md)
+```
+旧 `<rule>.details.md §<section> anchor` 方式は廃止 (断片ファイルを直接指すことで Read を最小化)。
+
+### Layer B 断片 → A (back-link、各断片冒頭に書く、`../../` の 2 階層上り)
+```markdown
+> Layer A: [`<rule>.md`](../../rules/<rule>.md) §<該当 section> | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+```
+
+## auto-load 非対象の保証 (CRITICAL)
+
+- Claude Code は `.claude/rules/*.md` のみ discover + startup load する。`.claude/rules-details/<rule>/` は rules/ の **外** かつ subdir のため **auto-load されない** (断片化で subdir を作っても本性質は不変)。
+- **検証方法 (Step 4 smoke)**: (1) 全 Layer A (`rules/*.md`) の `(../rules-details/...)` pointer を抽出し、各リンク先断片の実在を assert (dangling 0)。(2) `rules-details/` 配下に置くべき断片が誤って `rules/` 直下に無いことを assert。(3) `layer-b-context-isolation-smoke.sh` を断片構造に対応更新。
+
+## Read trigger 4 条件 (Layer A 冒頭に共通明記)
+
+1. 違反検出時 (hook BLOCK / warn 注入受領 / regex 不一致)
+2. 規範変更時 (rule 編集 / draft 起案 / 採用 N 条改定)
+3. 新規事案 (初遭遇 keyword / 例外パターン疑い)
+4. 学習 / dogfood (依存先必読 / harness audit / 副産物整理)
+
+通常運用は Layer A のみで判断、Layer B Read skip (token 節約)。
+
+## Layer B 断片 index (task-67、Step 2 で随時更新)
+
+各 rule の `<rule>/` ディレクトリ配下の断片一覧。Layer A の pointer はこの断片を直リンクする。
+
+| rule | ディレクトリ | 断片 (topic) | 移行状態 |
+|---|---|---|---|
+| workflow | `workflow/` | 14-stage / 10-stage / workflow-guard / draft-flow-guard / refactoring / mece-20 / fan-out / reviewer-prompt / byproduct-discharge / session-persistence / related-skills / origin (12 断片) | ✅ (task-67) |
+| development-process | `development-process/` | research-reuse / delegation-requirements / parallelization-origin / staging-strategy / cross-repo-write / confidence-gate / harness-sync / origin (8 断片) | ✅ (task-67) |
+| modes | `modes/` | compliance-items / five-layer-enforcement / mode-hooks / artifacts / origin (5 断片) | ✅ (task-67) |
+| task-management | `task-management/` | six-articles / mandatory-reading / task-migration / ui-detection / plan-first / hook-enforcement / parking-lot / origin (8 断片) | ✅ (task-67) |
+| self-improvement | `self-improvement/` | when-to-use-layers / l4-mechanics / related-skills / origin (4 断片) | ✅ (task-67) |
+| why-x5-output | `why-x5-output/` | examples / v1-v10-history / feedback-memory / origin (4 断片) | ✅ (task-67) |
+
+> 移行完了した rule は旧 `<rule>.details.md` を削除し、本表の移行状態を ✅ に更新する。
+
+## install.sh / smoke test 配下対応
+
+- `install.sh` の `rsync -a .claude/` で本 dir は自動同期される (RSYNC_EXCLUDES 不在のため)
+- `.claude/tests/layer-b-context-isolation-smoke.sh` は本 dir を Layer B 検査対象として参照する

package/.claude/rules-details/development-process/confidence-gate.md

@@ -0,0 +1,22 @@
+> Layer A: [`development-process.md`](../../rules/development-process.md) §サブエージェント完了サマリ (Confidence Gate / F3 必須) | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# confidence-gate 詳細 (Layer B)
+
+## 記載例
+
+```text
+F3 confidence-gate.sh を実装し以下を確認:
+- 6 ケースの mock transcript で期待動作を確認（pass/block/env override/bypass）
+- harness-audit に新セクション追加、bypass.log を集計
+- settings.json の SubagentStop に wired
+
+confidence: 0.9
+```
+
+## major subagent only block (2026-05-13、task #9) の補足
+
+F3 confidence-gate は **major subagent (`general-purpose` / `Explore` / `Task` allowlist or `is_sidechain==path_subagents`)** のみ confidence 自己評価を強制し、軽量 sidechain (Task tool query / 短い tool-use only sidechain) は **fail-open** で通過させる。
+
+- env `HC_CONFIDENCE_MAJOR_AGENT_ONLY=false` で従来動作 (全 stop event で block 判定) に復帰可
+- 設計起源: `docs/draft/harness-audit-followups.md` §3 W1 (2026-05-13)
+- 観測: `/harness-audit` で `regex_no_match` 累計が major subagent 由来のみに絞られる

package/.claude/rules-details/development-process/cross-repo-write.md

@@ -0,0 +1,35 @@
+> Layer A: [`development-process.md`](../../rules/development-process.md) §cross-repo write 例外 (agent 経路 deny / user manual 専用) | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# cross-repo write 起源 (Layer B)
+
+## 例外 (単一 repo との境界)
+
+- **単一 repo 内 (hirai-method 内 `.claude/hooks/` 等の編集) は staging 戦略で subagent から可能** ([staging-strategy.md](./staging-strategy.md) §例外)
+- **cross-repo Write のみが完全 deny** — 「`.claude/` への subagent write は全部 deny」という誤読を防ぐ境界
+
+## 適用手順 (How to apply)
+
+- 3 リポ反映系 task は `bash install.sh --update <target>` を **user に手動依頼** が default
+- task draft / task file の Phase 計画段で「**Phase N (cross-repo): user manual `bash install.sh --update <target>` 案内**」と最初から明記
+- 副産物 entry 起票時も「**(c) user manual 経路で対応**」を推奨処理に明記
+- 「sandbox deny で進められない」を loop 停止理由にしない
+
+## 実証経緯
+
+- 2026-05-23 task-24 W1 subagent a174bcef696b54860 confidence 0.85 で実証 (cross-repo Write / cp / mv / heredoc redirect が一律 deny、`dangerouslyDisableSandbox: true` 付き Bash も block)
+- task-26 W6 / task-21 W3.3 で同じ blocker を再確認、user manual `bash install.sh --update <target>` で 3 リポ反映完了
+
+## 関連 artifact
+
+- Serena memory: `feedback_cross_repo_write_sandbox_block.md` (2026-05-23、本 rule の事実根拠)
+- 副産物 entry: `docs/tasks/next-actions.md` entry #17 (2026-05-23、🟡)
+- 規範化 task: #31 (本セクション追加)
+- audit: `.claude/.workflow-state/bypass.log` (cross-repo agent 試行 block 痕跡)、`harness-audit.py` `bypass_log_summary` (再発検知)
+
+## 関連 memory (緩和方向)
+
+- `feedback_cross_repo_write_sandbox_block.md` (2026-05-26 SUPERSEDED): task-42 Step 9 で 4 リポ全件 agent 直接 Read/Write 成功実証 (classlab-weekly-news / TEST / recall_poc / taskManageSystem confidence 0.92)、cross-repo task は最初に試行 → block 確認で user manual 切替の判断順序に変更
+
+## 将来追随窓口
+
+system-level sandbox 仕様変化 (例: Claude Code が cross-repo Write を opt-in で許可する future feature) への追随は `docs/tasks/parking-lot.md` 🔍「cross-repo sandbox 緩和の future Claude Code 仕様変化追随」entry で四半期 review、Claude Code release notes 監視を user manual で実施。

package/.claude/rules-details/development-process/delegation-requirements.md

@@ -0,0 +1,158 @@
+> Layer A: [`development-process.md`](../../rules/development-process.md) §サブエージェント委譲の必須要件 7 件 | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 委譲必須要件 詳細 (Layer B)
+
+## 要件 1: background 起動強制 の補足
+
+- **理由**: メインがサブの完了を待つ間、ユーザーが新規指示を出せない (UX 劣化)。長時間タスクの進捗確認・追加指示・割り込みを常に受け付けるためメインを解放
+- **違反例**: foreground 起動でメインがブロックされ、ユーザーが「進捗確認」さえ困難
+- **運用**: 完了通知は SubagentStop hook 経由でメインに届く (ポーリング不要)
+
+## 要件 2: 順序整合性保証 の各論
+
+- **依存関係解決**: タスク A の出力をタスク B が消費する場合、A 完了通知を受けてから B 起動。サブに委譲不可
+- **並行可能性判定**: 独立ファイル領域 / 独立ブランチ / 独立 cost セッションのタスクは並行 OK。重なる場合は逐次化
+- **partial commit 整合性**: 各サブの commit が conflict しないことをメインが事前判定 (同一 file 編集の重複起動を防ぐ)
+- **完了通知 → 次タスク**: メインが完了通知を受けたら次タスク起動 / user 判断要請 / 中断のいずれかをメイン責任で決定
+
+## 要件 4: TaskCreate 登録 の必須項目
+
+- **subject**: サブに振り出した作業の概要 (例: 「config-loader env override 汎用化」)
+- **description**: 委譲スコープ / 完了条件 / 想定 cost / 並行可否
+- **metadata.subagent_id**: Agent tool 起動時の `agentId` (追跡可能性)
+- **status 遷移**: `pending` → `in_progress` (起動直後) → `completed` (完了通知受信時)
+
+### 依存関係の明示
+
+- 並行可能タスクは独立に作成 (依存なし)
+- 逐次タスクは `addBlockedBy` / `addBlocks` で依存関係明示
+- メインは TaskList でいつでも全状態確認可能にする
+
+### 違反例
+
+- TaskCreate せずに subagent 起動 → ユーザーが何が走っているか不明
+- 完了通知後に `completed` にしない → 古いタスクが残留
+- subagent_id 未記録 → 後追いトレース不能
+
+### 理由
+
+- **可観測性**: ユーザーが `TaskList` でいつでも進捗確認
+- **責任の明確化**: メインの orchestration 義務 (要件 3) を Claude Code 標準機構に裏付け
+- **再開性**: セッション再起動時もタスクリストから現状復元可能
+
+## 要件 5: Bash deny 時の委譲反射 の詳細
+
+### 禁止事項
+
+- **Bash deny を loop 停止理由にしてはならない**
+- 「これ以上進めない」と user に報告して止まる前に、必ず Agent tool で subagent に振り出す
+- whitelist への 1 行追加申請は user の選択肢として提示してよいが、提示前に subagent 委譲を試行する
+
+### 委譲反射の手順
+
+1. Bash が deny された → tool error / hook block / whitelist 不在を検知
+2. 直ちに Agent tool 起動 (`run_in_background: true` 必須)
+3. subagent に「メインで block された Bash 操作」を委譲
+4. TaskCreate でタスク登録 (要件 4)
+
+### 違反例
+
+- メインが「Bash 全面 block でこれ以上進めません。loop 停止します」と発言 → 誤動作
+- whitelist 1 行追加申請のみ提案して subagent 委譲を試みない → 申請は user 検討事項、まずは委譲反射
+
+### 例外
+
+- subagent も deny で進められない場合 (極稀) → user に状況報告 + permission 設定変更を依頼
+- 委譲先が無いタスク (例: メインの memory 操作) → そもそも Bash 不要なはず
+
+### 理由
+
+- Bash whitelist は **メインからの直接 Bash** 許可リスト。subagent 経由は別経路
+- 委譲ガード (`delegation-guard.sh`) は「メインが直接コードを触る」ことを防ぐためで、subagent はその対象外
+- 「Bash deny = 進行不能」と短絡判断するとハーネス本来の目的 (メイン → subagent 委譲) を裏切る
+
+## heredoc / quoted string の保護 (要件 4 補足)
+
+`git commit -m "table|cell"` や `git commit -m 'A || B'` の `|` `||` `&&` `;` は quote-aware segment splitter (`split_command_segments` 関数、`.claude/hooks/delegation-guard.sh`) が separator 扱いせず単一 segment として whitelist 照合する。詳細は `.claude/tests/delegation-guard-segment-smoke.sh` Case 4-6 を参照。
+
+heredoc 本文 (`<<EOF ... EOF`) は単行解析の限界で未対応 (将来 B フル parser 化で対応予定)。
+
+## 要件 6: 並列化義務 の機械強制詳細
+
+### 機械強制 hook の判定境界 (count ≤ 1 で warning)
+
+`parallel-subagent-reminder.sh` は **TTL filter 後の他 Agent 起動数 ≤ 1** で「単独起動」と判定し warning 注入:
+
+- `count=0`: 完全初回起動 (warning)
+- `count=1`: 直前 TTL 内に 1 件、本起動が 2 件目だが保守的に warning 注入 (並列化推奨継続)
+- `count≥2`: 並列起動済み (silent)
+
+「他 Agent 起動なし = 0 件」と読めた旧表現は `≤ 1` 境界値の正確な表現に修正。
+
+### 違反例
+
+- 独立 file 領域 (例: 3 file 編集) を 1 subagent に統合委譲 → 並列化機会逃失
+- 「規範追加 + hook 新設 + smoke 新設」のような完全独立 sub-task を sequential 起動 → 3 倍時間消費
+
+### 違反検出時の対応
+
+1. **即時切替**: 起動済 subagent を継続させつつ、次の sub-task 群から並列起動に切替
+2. **教訓記録**: memory `feedback_*.md` に「並列化逃失の trigger / 真因 / 再発防止策」追記
+3. **規範補強**: 同種違反の再発観測時、本セクションに具体例追加
+
+## 要件 7: agent type 選定義務 の各論
+
+### 設定不要原則 (user 強調要件、2026-05-25)
+
+採用者は `harness-config.yml` を編集しなくても、**hook 内 hardcode の default mapping** で agent type が自動判定される。`harness-config.yml` での override は任意 (advanced 用途のみ)、未設定でも完全動作。
+
+これは「ハーネス採用 = box-open で即動作」を保証する SSoT 設計。default mapping を hook 内 SSoT として保持し、yaml override は補完オプション位置付け。
+
+### agent-router skill 連携 (補完オプション、Phase 2 future)
+
+既存 `agent-router` skill (Anthropic 提供) を SessionStart で auto-trigger 可能なら、本 hook と組合せで深い解析対応:
+
+- 本 hook (`parallel-subagent-reminder.sh`): PreToolUse(Agent) 時点の即時 warning 注入 (軽量 keyword 照合)
+- `agent-router` skill: task description の semantic 解析 (LLM 経由、深い推論)
+
+採用判断:
+- **Phase 1 (現状)**: 本 hook のみ実装 (軽量、確実、LLM cost 0)
+- **Phase 2 (future)**: `agent-router` skill auto-trigger 検討 (LLM cost 評価後)
+
+### 違反例
+
+- test 拡張 task で `general-purpose` を default 採用 → `test-automator` の専門知識を逃失 (2026-05-25 task-35 Subagent B 実例)
+- refactor task で `general-purpose` を default 採用 → `refactoring-specialist` の behavior-preserving 知識を逃失 (2026-05-25 task-34 Step 5 実例)
+- 言語別 build error で `general-purpose` 採用 → 言語特化 `*-build-resolver` の error pattern 知識を逃失
+
+### 違反検出時の対応
+
+1. **即時切替**: 該当 sub-task を停止せず継続、次の同種 sub-task から専門 agent type 採用
+2. **mapping 拡張検討**: 既存 mapping に該当 keyword がない場合、Layer A の mapping 表に追記提案 (規範化 task 起票)
+3. **教訓記録**: memory `feedback_*.md` に「agent type 選定逃失の trigger / 真因」追記
+
+### 機械強制 (soft warning)
+
+同 `parallel-subagent-reminder.sh` 内で agent type 選定を照合:
+
+- PreToolUse(Agent) 時点で `tool_input.subagent_type == "general-purpose"` ∧ task description に専門 type 適合 keyword 検出 → `<system-reminder>` で「専門 type 推奨」warning 注入
+- BLOCK しない (false positive 回避、AI 判断尊重)
+
+### bypass
+
+並列化義務 §6 の bypass (`HC_PARALLEL_SUBAGENT_REMINDER_ENABLED=false`) で agent type 選定 warning も同時無効化 (1 hook 統合のため)。個別無効化は現状未提供 (将来 `HC_AGENT_TYPE_REMINDER_ENABLED` 等で分離検討可)。
+
+### 任意 override (advanced 用途)
+
+採用者が hook 内 default mapping を上書き / 拡張したい場合のみ `harness-config.yml` で override 可:
+
+```yaml
+# 設定不要原則のため、本キーは optional (未設定なら hook 内 hardcode 使用)
+agent_type_keyword_mapping:
+  test-automator:
+    - "smoke 拡張"
+    - "test 追加"
+    - "<採用者追加 keyword>"
+```
+
+env override: `HC_AGENT_TYPE_KEYWORD_MAPPING=...` (改行区切り、advanced 用途)。

package/.claude/rules-details/development-process/harness-sync.md

@@ -0,0 +1,21 @@
+> Layer A: [`development-process.md`](../../rules/development-process.md) §harness 取込チェックリスト (proactive sync、consuming repo 必須) | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# harness 取込 詳細 (Layer B)
+
+## CI 自動化 (将来 opt-in、parking-lot)
+
+CI (GitHub Actions 等) で hirai-method SSoT と `.claude/` の diff を定期検出 → PR / issue 自動起票する自動化案 (案 B) は **consuming repo 側の opt-in** で将来導入。詳細は `docs/tasks/parking-lot.md` の 🔍 entry「CI 自動 .claude diff 検出 (G2 案 B)」を参照。
+
+## 取込手順の補足
+
+- **hirai-method 最新化**: consuming repo 側に直接 push する場合は不要
+- **`bash install.sh --update <consuming repo absolute path>`** は cross-repo write のため **user manual (terminal) 実行のみ可能** (詳細: §「cross-repo write 例外」)
+- **分離 commit** (task-58 G1) で `chore: sync .claude/ from hirai-method <YYYY-MM-DD>` 形式で記録、`install.sh --update --commit` flag で自動 commit 可能
+
+## 起源
+
+- 2026-05-28 task-59 (G2: harness-sync-proactive-workflow)、設計 draft: [`docs/draft/harness-sync-proactive-workflow.md`](../../docs/draft/harness-sync-proactive-workflow.md) §3 採用案 C ハイブリッド
+- 前提:
+  - task-56 = F (stale-harness-detect、reactive 検出 + WARN 案内、commit `f5149fb`)
+  - task-58 = G1 (未 commit drift、`install.sh --update --commit` flag)
+- F WARN 連携: `stale-harness-detect.sh` の WARN 文に既に「`bash install.sh --update <repo>`」案内が含まれる (commit `f5149fb`、smoke Case 2 で grep verify 済、Case 10 で取込手順 strengthen)

package/.claude/rules-details/development-process/origin.md

@@ -0,0 +1,13 @@
+> Layer A: [`development-process.md`](../../rules/development-process.md) | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 起源 (Layer B)
+
+- **コーディング指針 (karpathy-guidelines)**: 採用済 skill `.claude/skills/karpathy-guidelines/SKILL.md`、LLM コーディング行動規約の SSoT
+- **TDD 4 step**: 採用済 skill `.claude/skills/tdd-workflow/SKILL.md` 由来
+- **委譲必須要件 7 件**: 各要件の起源は各 §「起源」 (要件 6: task-35 / 要件 7: task-35 + task-34)、規範化 task #38
+- **staging 戦略**: task #12 (2026-05-13)、規範化 task #13
+- **cross-repo write 例外**: task-24 W1 / task-26 W6 / task-21 W3.3 (2026-05-23)、規範化 task #31、緩和 task-42 (2026-05-26)
+- **Confidence Gate F3**: F3 confidence-gate.sh、`docs/CONFIDENCE-GATE.md` SSoT、major subagent only block は task #9 (2026-05-13)
+- **harness 取込チェックリスト**: task-59 (G2、2026-05-28)、前提 task-56 (F) / task-58 (G1)
+- **副産物即時 draft 起こし義務**: `docs/draft/byproduct-discharge-mechanism.md`、強制機構は次セッション実装予定
+- 各規範の commit hash / 採用判断は git log + 関連 draft 参照

package/.claude/rules-details/development-process/parallelization-origin.md

@@ -0,0 +1,22 @@
+> Layer A: [`development-process.md`](../../rules/development-process.md) §サブエージェント委譲の必須要件 7 件 | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 並列化義務 起源 (Layer B)
+
+## 並列化義務 (要件 6) の起源
+
+- 2026-05-25 task-35 Step 1+2+4 を 1 subagent に統合委譲した実例 (本来 3 並列起動可能だった file 領域独立 sub-task)
+- 設計 draft: `docs/draft/parallel-subagent-enforcement.md` §4.1 (規範強化部)
+- 副産物 entry #23
+- 規範化 task: #38
+
+## agent type 選定義務 (要件 7) の起源
+
+- 2026-05-25 task-35 Subagent B (test 拡張) で `general-purpose` 採用、`test-automator` を逃失
+- 2026-05-25 task-34 Step 5 (refactor) で `general-purpose` 採用、`refactoring-specialist` を逃失
+- user 強調要件「設定不要で自動的に判断」(2026-05-25 13th save-state 後)
+- 設計 draft: `docs/draft/parallel-subagent-enforcement.md` §4.5 + §4.5.0 設定不要原則
+- 規範化 task: #38
+
+## Hook による補助 (soft warning)
+
+`.claude/hooks/agent-marker-set.sh` は PreToolUse(Agent) で foreground 起動を検出した場合、stderr に WARN を出す (block ではない)。`tool_input.run_in_background != true` のときに発火。