@takuma-hirai/hirai-method 0.1.0

package/.claude/rules-details/task-management/six-articles.md

@@ -0,0 +1,68 @@
+> Layer A: [`task-management.md`](../../rules/task-management.md) §タスク構造規範 — 採用 6 条 | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 採用 6 条 詳細 (Layer B)
+
+## 改定理由 (3 問題、task-33 実例観測)
+
+1. **粒度過剰**: task-33 が 5 Phase × 14 Step で deliverable として scope 過大
+2. **status 不可視**: list.md row が task 単位のみ、Step status が IDE 視点で追跡不可
+3. **概要欄混在**: list.md 概要列が task overview / step description 区別なく記載
+
+## 条 2 詳細 (Task 必須項目 5 件)
+
+「観察可能」とは PASS/FAIL or 数値 or before/after diff のように第三者が客観確認できる粒度を指す:
+
+- OK 例: 「全テスト 92/92 PASS」「list.md に新 entry 1 行追加」「Layer A size 元 33K → 目標 ~10K」
+- NG 例: 「動くようにする」「整理する」「適切に処理」(検証不能)
+
+依存先タスクは「**`task-N1, task-N2` 形式で ID 列挙**」 + 各依存先について Task header section に **影響内容 (1-2 文) + 依存先 task.md へのリンク** を記載。
+
+## 条 3 詳細 (Step 必須項目 4 件)
+
+「test PASS」のような曖昧表現ではなく、再現可能な検証コマンドを書く:
+
+- OK 例: 「`bash .claude/tests/foo-smoke.sh` exit 0」「`grep -c '...' file.md` で 2 件以上」
+- NG 例: 「動作確認」「テスト OK」「正常終了」
+
+## 条 4 詳細 (テスト設計レビュー)
+
+**動的選定の判定ヒント** (固定 registry 不採用、case-by-case):
+
+- **常時 base 候補**: tdd-guide / test-automator / qa-expert / pr-test-analyzer
+- **UI 含む** → ui-designer / accessibility-tester / e2e-runner 加味
+- **DB schema / migration** → database-reviewer / postgres-pro 加味
+- **API 変更** → api-designer / api-documenter 加味
+- **言語特定** → 言語別 reviewer (python-reviewer / typescript-reviewer / go-reviewer / rust-reviewer 等) 加味
+- **security 影響** → security-reviewer / security-auditor 加味
+- 上記から **`review_min_count_test`〜`review_max_count_test` の範囲内**で動的選定 (青天井「5+」は task-64 で廃止)。起動前に `bash .claude/scripts/hc-config.sh --get review_max_count_test` で上限を確認し、並列起動数 N が `min ≤ N ≤ max` に収まることを保証する
+
+**ビジュアル検証 (browser/web UI、E2E とは別レイヤ、2026-05-27 採用、draft `ui-visual-verification-mandate.md`)**:
+
+- `agent-browser` skill (vercel/agent browser) で実際にブラウザ描画 → screenshot 取得 → 目視確認
+- 主要 breakpoint (320/768/1024/1440 等) / 主要状態 (hover/focus/active/error 等) / 両 theme (あれば) を撮影
+- レイアウト / 配色 / タイポグラフィ / 余白 / レスポンシブ が設計意図通りか確認 (可能なら before/after 比較)
+- E2E (機能フロー動作) とは別の品質軸。**両方 PASS で初めて UI Task 完了**、E2E のみ / 型チェックのみでは完了宣言しない
+- 非対話 / CI 環境は Playwright screenshot で代替可。honor-system (機械強制 hook なし)
+
+**yml 値による制御 (task-44/45/46、task-64 で enforcement 化 + local.yml 移行)**: reviewer 動的選定の下限 / 上限 / 反復は `review_min_count_test` / `review_max_count_test` / `review_iteration_max` で集中制御。**具体値は固定 default を散文に hardcode せず、起動前に `bash .claude/scripts/hc-config.sh --get review_max_count_test` (上限) / `--get review_min_count_test` (下限) / `--get review_iteration_max` (反復上限) で現在値を確認する**。値解決順: `env(HC_REVIEW_*)` > `harness-config.local.yml` (project override、`install.sh --update` 温存) > `harness-config.yml` (SSoT) > config-loader default。`bash .claude/scripts/hc-config.sh --set review_min_count_test=3` で安全に変更可 (atomic backup + type validation)。詳細は `docs/SELF_IMPROVEMENT.md` §「hc-config.sh による yml 編集」参照。
+
+## 条 6 詳細 (list.md 表現規約)
+
+**依存先列 format** (採用 6 条 2 連動): `task-N1, task-N2, task-N3` (カンマ区切り ID 列挙)、依存なしは `—` (long-dash) で空欄禁止。Task header section に各依存先について **影響内容 + リンク** 記載必須。
+
+**OK/NG 例**:
+
+- **OK 例 (Task 概要欄)**: 「recall_poc plan-first 不在事案の再発防止のため、task-management.md §plan-first を追加し batch planning 時の 📝 行先置きフロー 2 経路分岐を明文化する。完成すれば AI が batch planning 時に list.md plan-first 先置きを規範通り実行できるようになる。」
+- **OK 例 (Step 概要欄)**: 「task-management.md §plan-first 新規 subsection 追加 (経路 A/B 分岐 + 凡例 📝 用途明文化)」
+- **NG 例 (Task 概要欄)**: 「規範を追加」(目的 / 成果不明) / 「Phase 1 完了、Phase 2 進行中」(Step 状態を概要欄に書かない、それは Step Status 列の責務)
+- **NG 例 (Step 概要欄)**: 「task-management.md §plan-first を追加することで AI が規範通り実行できるようになる」(Task 概要欄の規約を Step に流用しない、Step は work only)
+
+## task-29 採用 5 条 supersede 経緯
+
+task-29 採用 5 条 (`docs/draft/phase-step-task-structure.md`、2026-05-23 採用) は task → Phase → Step の 3 階層を規範化したが、task-33 実装で 5 Phase × 14 Step に肥大化し以下の問題を顕在化:
+
+1. Phase 1 完遂時点での status 判定困難 (Phase 完了 = task 完了か Step 完了か曖昧)
+2. Step status が IDE 視点で不可視 (list.md row が task 単位のみ)
+3. 概要欄の Task / Step 区別なし
+
+→ 2026-05-25 user 4 ターン連続承認で **Task = Phase = N Step (2 階層)** に圧縮し採用 6 条として規範化、task-29 採用 5 条を supersede。

package/.claude/rules-details/task-management/task-migration.md

@@ -0,0 +1,16 @@
+> Layer A: [`task-management.md`](../../rules/task-management.md) §既存 task 移行ガイド | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 既存 task 移行 詳細 (Layer B)
+
+## 移行優先度 (G2 → G3)
+
+| task | 状態 | 優先度 | 備考 |
+|---|---|---|---|
+| **task-33 (list-md-plan-first-normative)** | 5 Phase 構造 (Phase 1 完遂、Phase 2 Step 2.2 まで) | **本 commit で即 restructure** | 本規範改定の起源、Wave C-1 で 5 task (33/34/35/36/37) に分割 |
+| task-21 (system-reminder-attention) | W3 残 | **最優先** | 規範整備系で本規範の起源とも近い、整合性確保 |
+| task-23 (recall-poc-recovery) | W4-W5 残 | 高 | 実装系、Wave 跨ぎの依存が多い |
+| task-24 (taskmanagesystem-recovery) | W5 残 | 高 | 規範整備系、本 rule との整合性確保 |
+| task-27 (observe-jq-parse-fix) | W3 残 | 中 | W3 不要判定検討中、不要なら低優先度に降格可 |
+| task-28 (observe-subagent-stop-instrumentation) | Phase 2 残 | 中 | 既に Phase 命名を採用、Step 粒度のみ要確認 |
+
+移行作業は task 着手前 (`/start-task <id>` 実行前後) の準備として実施。新構造へ書き換えても commit 履歴・既存 Phase / Wave での完了実績は temporal record として残す (削除しない)。

package/.claude/rules-details/task-management/ui-detection.md

@@ -0,0 +1,11 @@
+> Layer A: [`task-management.md`](../../rules/task-management.md) §UI 変更検出基準 | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# UI 検出 詳細 (Layer B)
+
+## 機械強制 hook 案 (future work)
+
+本規範採用フェーズでは規範のみ (honor system)。効果観察後に別 task で `task-rule-guard.sh` 拡張により Task 内容を parse → UI 判定 → E2E + ビジュアル検証 (採用 6 条 4、2026-05-27 採用) Step 存在検証を機械強制化する案を検討する (起案は `docs/draft/` 経由で別 task として起こす)。
+
+過検知 (誤って UI と判定) は許容、見逃し (UI なのに非 UI 判定) は不可。
+
+reviewer 確認推奨 (`/module-review` or `/system-review` 時に skip 妥当性をレビュー)。

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

@@ -0,0 +1,41 @@
+> Layer A: [`why-x5-output.md`](../../rules/why-x5-output.md) §OK 例 / §NG 例 | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 例詳細 (Layer B)
+
+## OK 例 (拡張)
+
+- 「install.sh を smoke test するため、tmp dir に実 install を実行する」
+- 「規範を v10 化するため、why-x5-output.md を全文書き換える」
+- 「user に結果を報告するため、install 完了 summary を 1 行で返す」
+- 「Layer A サイズ削減のため、v1→v10 経緯 table を Layer B に退避する」
+- 「subagent 並列起動のため、Task tool を `run_in_background: true` で 3 件起動する」
+
+## NG 例 (拡張、廃止 format 4 種)
+
+- **v9 format (4 セクション分割、2026-05-23 廃止)**:
+  ```
+  【システムの存在意義】... 【whyN】... 【現在行っていること】... 【他の選択肢を取らない理由】...
+  ```
+  → 冗長で認知負荷が高く廃止。v10 で 1 行に集約。
+
+- **v8 format (1 セクション混在、目的→中間→作業、2026-05-14 廃止)**:
+  ```
+  最終的なシステム目的: ハーネスの信頼性向上
+  ↑ そのために規範を整備
+  ↑ そのために why-x5-output.md を書き換え (現在の作業)
+  ```
+  → 多階層 + `↑` 記号で認知負荷高い、user 「冗長、不要」指摘。
+
+- **v7-final format (1 セクション混在、作業→中間→目的、2026-05-14 廃止)**:
+  ```
+  why-x5-output.md を書き換え (現在の作業)
+  ↓ そのために規範を整備
+  ↓ そのためにハーネスの信頼性向上
+  ```
+  → 「最終的なシステム目的 → 必要な機能 に繋がっていません」指摘。
+
+- **「何のため」省略 (例: 「install.sh を smoke test する」だけ)**:
+  → ステップは可視化されるが、システム目的との接続が失われる。
+
+- **「他の選択肢を取らない理由」を毎回 3 件矢印 format で書く (v9 廃止)**:
+  → 代替案検討は思考ロジック内で完結、出力には書かない。

package/.claude/rules-details/why-x5-output/feedback-memory.md

@@ -0,0 +1,14 @@
+> Layer A: [`why-x5-output.md`](../../rules/why-x5-output.md) §関連 feedback memory | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 関連 feedback memory 全件 詳細 (Layer B)
+
+| memory | 状態 | 説明 |
+|---|---|---|
+| `feedback_why_x5_v10_one_liner.md` | 現行 (2026-05-23) | v10 改訂の起源、1 行 format への集約根拠 |
+| `feedback_why_x5_once_per_turn.md` | 現行 | ターン冒頭 1 回 / ステップ単位 / 未来時制で書く運用補足 (v10 でも継続有効) |
+| `feedback_skip_why_x5_for_mode_command.md` | 現行 | `/mode` 等 format 省略許可 command 規範 (v10 でも有効) |
+| `feedback_why_x5_v9_four_sections.md` | **SUPERSEDED** (2026-05-23) | v9 4 セクション format、v10 で 1 行化、entry は経緯保持のみ |
+| `feedback_why_x5_v8_top_purpose_bottom_work.md` | **SUPERSEDED** (2026-05-14) | v8 1 セクション混在、v9 で 4 セクション分割化、間接 supersede |
+| `feedback_why_x5_v7_labeled_sections.md` | **SUPERSEDED** (2026-05-14) | v7-final 1 セクション混在 旧並び、v9 で間接 supersede |
+| `feedback_why_x5_v7_link_to_system_purpose.md` | **SUPERSEDED** (2026-05-23) | v7 運用補足 (中間階層をシステム意義まで繋ぐ)、v10 で「何のため」に統合 |
+| `feedback_why_x5_depth_and_requirement_link.md` | **SUPERSEDED** (2026-05-14) | Why × 5 因果連鎖、v9 で間接 supersede |

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

@@ -0,0 +1,10 @@
+> Layer A: [`why-x5-output.md`](../../rules/why-x5-output.md) §強制機構 / §一時無効化 | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 起源 詳細 (Layer B)
+
+- **v10 改訂起源 (2026-05-23)**: user 明示指摘「4 セクション format 不要、何のために何をやるのかを 1 行で毎回出力に変更」を反映。v9 (4 セクション分割: システム意義 / whyN / 現在の作業 / 他選択肢) は冗長で認知負荷が高く廃止。`feedback_why_x5_v10_one_liner.md` (memory) が起源
+- **v1→v10 取り違え経緯**: 2025 年末 〜 2026-05 にかけて user との iter で format が 10 回変遷。各版の指摘は [`v1-v10-history.md`](./v1-v10-history.md) 参照。「固定するな」「全任意化するな」「多階層は冗長」「1 セクション混在で並び逆転」等の試行錯誤を経て v10 1 行 format に収束
+- **思考ロジック 3 step (何のため / 何をやる / 代替案検討)**: v10 で 1 行出力に集約する代わりに、出力に書かない代替案検討を思考ロジック内で必須化。AI の判断品質を維持したまま出力認知負荷を下げる狙い
+- **強制機構 `.claude/hooks/why-x5-reminder.sh`**: UserPromptSubmit hook で毎ターン本 rule への遵守を `<system-reminder>` として注入。v10 移行後も hook は継続稼働、注入内容のみ 1 行 format に更新
+- **規範化経緯**: 各版の commit hash は git log で `why-x5-output.md` を辿る。v10 確定 commit は 2026-05-23 (`feedback_why_x5_v10_one_liner.md` memory 起こし日と同日)
+- **task-51 Step 3 (2026-05-28)**: Layer A/B 2 層分割を実施。Layer A (~1.5K bytes) を SSoT として残し、v1→v10 経緯 table / SUPERSEDED 履歴 / 拡張例 / 全 feedback memory list を Layer B に退避。常時参照 (frontmatter 無し) の token 負荷を削減

package/.claude/rules-details/why-x5-output/v1-v10-history.md

@@ -0,0 +1,19 @@
+> Layer A: [`why-x5-output.md`](../../rules/why-x5-output.md) §関連 feedback memory | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# v1→v10 経緯 詳細 (Layer B)
+
+再発防止用の取り違え履歴 (10 版分):
+
+| 版 | 構造 / 並び | 指摘 | 廃止日 |
+|---|---|---|---|
+| v1 | 6 階層固定 | 「固定するな」 | 〜 |
+| v2 | 3 要件固定 | 「3 要件も固定するな」 | 〜 |
+| v3 | 全任意化 | 「現在行っていること・他の選択肢は必須」 | 〜 |
+| v4 | 「○○のために○○を行っている」1 文 | 「ではないです、多階層で」 | 〜 |
+| v5 | 多階層 + `↑` 記号 + ラベル | 「認知負荷高い」 | 〜 |
+| v6 | markdown 表 + 視覚記号 | 「【現在行っていること】+【whyN】format で」 | 〜 |
+| v7 | § 等装飾残存 | 「§は不要です」 | 〜 |
+| v7-final | 1 セクション混在 (作業 → 中間 → 目的) | 「最終的なシステム目的 → 必要な機能 に繋がっていません」 | 2026-05-14 |
+| v8 | 1 セクション混在 並び逆転 (目的 → 中間 → 作業) | 「一番上をシステム目的、一番下を現在の作業」 | 2026-05-14 |
+| v9 | 4 セクション分割 + 思考ロジック (何 → 選択肢 → 選定) 強制 | 「冗長、不要」 | 2026-05-23 |
+| **v10** | **1 行 format「<何のため> のため、<何をやる> を行う」** | 「何のために何をやるのかを 1 行で毎回出力に変更」 | (現行) |

package/.claude/rules-details/workflow/10-stage.md

@@ -0,0 +1,43 @@
+> Layer A: [`workflow.md`](../../rules/workflow.md) §既存機能修正フロー (10-stage) | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 10-stage 詳細 (Layer B)
+
+既存機能修正フロー (`/modify-feature <slug>`、`HC_WORKFLOW_STAGES_MODIFY` 10 stage) の full 表 + 各 stage 補足。stage 名の SSoT は env `HC_WORKFLOW_STAGES_MODIFY` (= `harness-config.yml` の `workflow_stages_modify`) で、本表と完全一致する。
+
+## 10-stage full 表
+
+| # | stage 名 | 役割 | 起動 command / 連携 |
+|---:|---|---|---|
+| 1 | `branch-decision` | 影響範囲特定 + branch type (`feat`/`fix`/`refactor`/`hotfix`) 決定 | user 対話 |
+| 2 | `checkout` | branch 切替 (regex 検証: git-workflow.md 規約準拠) | `git switch` |
+| 3 | `recover-design` | 既存 task / draft 探索、不完全なら逆引きで draft 起こし | Glob + Read |
+| 4 | `pre-test` | **修正前** 全テスト PASS を baseline 記録 (regression 検出基準) | test runner |
+| 5 | `redesign` | draft §3 に「変更前 / 変更後」差分追記 | architect agent |
+| 6 | `retest-design` | `/test-design` 再実行で差分部 MECE 再評価 | `/test-design <slug>` |
+| 7 | `tdd` | 新規 test → 最小修正 → refactor (subagent 経由) | TDD ループ |
+| 8 | `module-review` | モジュール毎に 3 観点レビュー | `/module-review <module>` |
+| 9 | `full-test` | 全 test PASS + pre-test baseline regression 検出 | test runner |
+| 10 | `system-review` | 全体整合性レビュー → merge 可否判断 → `/finish-task` 案内 | `/system-review` |
+
+各 stage 完了時、メインが state JSON の `current_stage` を次 stage に進め `completed_stages` に追加 (workflow_type=`modify`)。
+
+## Stage 7 `tdd` の git log 検証
+
+- **Wave 計画前に `git log --all --grep <finding>` で既存 commit 解消確認必須** (2026-05-21 TM 修正での no-op 重複起動再発防止)
+
+## `/new-feature` との差分詳細
+
+`/new-feature` (14-stage) との主要差分: 要件定義 / `design-review` / `task-creation` / `ci-cd` / `scenario-test` は省略され、代わりに `recover-design` / `pre-test` / `retest-design` が入る。
+
+- 要件定義 (Stage 1 `requirements`) → 不要 (既存機能の修正のため)
+- `design-review` (Stage 5 fan-out レビュー) → 不要 (差分のみ retest-design で再評価)
+- `task-creation` (Stage 7 task-creation) → branch-decision + checkout で代替
+- `ci-cd` (Stage 12) → 不要 (既存 CI 流用)
+- `scenario-test` (Stage 13) → full-test (Stage 9) で代替
+
+代わりに以下が入る:
+- `recover-design` (Stage 3) — 既存 task / draft を探索、不完全なら逆引き起こし
+- `pre-test` (Stage 4) — 修正前 baseline 記録
+- `retest-design` (Stage 6) — 差分部 MECE 再評価
+
+詳細比較は [`modify-feature.md`](../../commands/modify-feature.md) の「/new-feature との差分」セクション参照。

package/.claude/rules-details/workflow/14-stage.md

@@ -0,0 +1,52 @@
+> Layer A: [`workflow.md`](../../rules/workflow.md) §新規機能開発フロー (14-stage) | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 14-stage 詳細 (Layer B)
+
+新規機能開発フロー (`/new-feature <slug>`、`HC_WORKFLOW_STAGES_NEW` 14 stage) の full 表 + 各 stage 補足。stage 名の SSoT は env `HC_WORKFLOW_STAGES_NEW` (= `harness-config.yml` の `workflow_stages_new`) で、本表と完全一致する。
+
+## 14-stage full 表
+
+| # | stage 名 | 役割 | 起動 command / 連携 |
+|---:|---|---|---|
+| 1 | `requirements` | WHAT / WHY 確定 + draft §1 | `/new-draft <slug>` |
+| 2 | `basic-design` | 解決アプローチ比較 + draft §2 | architect agent |
+| 3 | `detailed-design` | API / データモデル / UI / DB schema を draft §3 | code-architect agent |
+| 4 | `test-design` | MECE 20 カテゴリのテストカタログ + user スコープ承認 | `/test-design <slug>` |
+| 5 | `design-review` | reviewer-registry design + security を並列起動して fan-out | `/design-review <slug>` |
+| 6 | `user-approval` | draft §8 承認履歴に user 承認エントリ追加 (必須、Loop モードでも) | user 対話 |
+| 7 | `task-creation` | `/new-task` + `.claude/.workflow-state/<slug>.json` 初期化 | `/new-task <id> <slug>` |
+| 8 | `tdd` | RED → GREEN → REFACTOR (subagent 経由のみ)。**Task 最終 3 Steps = テスト設計レビュー → テスト合格 → リファクタリング (固定)** ([task-management.md §タスク構造規範](../../rules/task-management.md) 採用 6 条 4) | `/start-task <id>` |
+| 9 | `module-review` | モジュール毎に 3 観点レビュー | `/module-review <module>` |
+| 10 | `local-test` | `<slug>.test-design.md` ☑ カテゴリ全実行 + Step 完了条件で検証 | subagent test runner |
+| 11 | `system-review` | 全モジュール統合後に重複 / 設計乖離検出 | `/system-review --slug <slug>` |
+| 12 | `ci-cd` | `.github/workflows/` 更新 (skip 可) | — |
+| 13 | `scenario-test` | E2E / シナリオ実行 (UI 変更含む Task は E2E 必須、検出基準: [task-management.md §UI 変更検出基準](../../rules/task-management.md)) | e2e-runner agent |
+| 14 | `finish` | `/finish-task` で完了クローズ。**workflow-guard.sh が state JSON 検証** | `/finish-task <id>` |
+
+各 stage 完了時、メインが `.claude/.workflow-state/<slug>.json` の `current_stage` を次 stage に進め、`completed_stages` に追加。state JSON は Stage 7 で初期化 (Stage 1〜6 完了済として列挙)。
+
+## Stage 8 `tdd` の git log 既存 commit 確認義務
+
+- **Step 計画前に `git log --all --grep <finding>` で既存 commit 解消確認必須** (2026-05-21 TM 修正での no-op 重複起動再発防止)
+- **Task 最終 3 Steps = テスト設計レビュー → テスト合格 → リファクタリング (固定)**:
+  - テスト設計レビューは 5+ reviewer 動的選定 + 修正収束まで反復 + 5 回上限
+  - bypass: `ECC_TEST_DESIGN_REVIEW_OFF=1`
+  - 詳細: [task-management.md §タスク構造規範](../../rules/task-management.md#タスク構造規範-taskphasen-step-phase-中間階層廃止) 採用 6 条 4 [2026-05-25 採用]
+  - 旧採用 5 条 4 を supersede
+
+## Stage 10 `local-test` の Step 完了条件検証
+
+- `<slug>.test-design.md` で ☑ にしたテスト全カテゴリを実行
+- **Step 完了条件 (定量 or 観察可能事実) で test 結果を検証** (採用 5 条 3 起源)
+- 検証コマンドは「`bash .claude/tests/foo-smoke.sh` exit 0」のように再現可能な形で書く
+
+## Stage 13 `scenario-test` の UI 必須化
+
+- **UI 変更を含む Task は E2E 必須** (検出基準: [task-management.md §UI 変更検出基準](../../rules/task-management.md#ui-変更検出基準))
+- 採用 6 条 4 [2026-05-25 採用、旧採用 5 条 4 supersede] でビジュアル検証も併設必須化 (2026-05-27 採用、`agent-browser` skill + screenshot)
+- E2E (機能フロー動作) とビジュアル検証 (見た目) は別レイヤ、両方 PASS で初めて UI Task 完了
+
+## Stage 12 `ci-cd` の skip 条件
+
+- `asana_enabled=false` プロジェクトは default skip
+- skip した場合は state JSON の `skip_log` に `{stage: "ci-cd", reason: "asana-disabled", user_approved_at: <ISO-8601>}` を append

package/.claude/rules-details/workflow/byproduct-discharge.md

@@ -0,0 +1,39 @@
+> Layer A: [`workflow.md`](../../rules/workflow.md) §副産物 discharge (5 層強制機構) | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 副産物 discharge 詳細 (Layer B)
+
+副産物 discharge 5 層強制機構の表 / bypass は Layer A 参照。本 file は処理フロー / 関連 artifact / 違反パターン。
+
+## 処理フロー
+
+```
+副産物発生
+  ↓ (層 1: registry 追加義務)
+docs/tasks/next-actions.md に entry 追加 (緊急度 🔴 / 🟡 / 🟢)
+  ↓ (層 5: command で移行)
+/discharge-byproduct <entry-number>
+  ↓
+[判定]
+  (a) 🔴 / 🟡 → /new-draft <slug> で draft 起こし → user 承認 → /new-task → list.md
+  (b) 🟢 + 設計済 → parking-lot.md に保留タスクとして移行
+  (c) 不要 → 無視、理由を処理結果列に明記、履歴セクションへ移動
+  ↓
+next-actions.md 処理結果列を更新
+```
+
+## 関連 artifact
+
+- [`docs/tasks/next-actions.md`](../../../docs/tasks/next-actions.md) — registry 本体
+- [`.claude/templates/docs/tasks/_TASK_TEMPLATE.md`](../../templates/docs/tasks/_TASK_TEMPLATE.md) — 派生 task セクション (W2 で追加)
+- [`.claude/hooks/next-actions-surface.sh`](../../hooks/next-actions-surface.sh) (W1)
+- [`.claude/hooks/byproduct-discharge-guard.sh`](../../hooks/byproduct-discharge-guard.sh) (W3)
+- [`.claude/hooks/lib/next-actions-parser.sh`](../../hooks/lib/next-actions-parser.sh) — 共通 parser
+- [`.claude/commands/discharge-byproduct.md`](../../commands/discharge-byproduct.md) (W4)
+- [`.claude/tests/next-actions-hooks-smoke.sh`](../../tests/next-actions-hooks-smoke.sh) (W6, 9/9 PASS)
+- 設計起源は採用プロジェクト側 `docs/draft/` を参照 (`.claude/` 単独で portable)
+
+## 違反パターン
+
+- 副産物を memory にのみ保存して draft 化しない → 層 1 違反 (registry 不在で発見不能)
+- 「次セッションで対応」とコメントだけ残してセッション終了 → 層 4 (Stop hook) で 🔴 残存 BLOCK
+- 発生源 task の `/finish-task` 完了前に処理せず後送り → 層 2 (`_TASK_TEMPLATE.md` 派生 task セクション) で task 完了時に検出

package/.claude/rules-details/workflow/draft-flow-guard.md

@@ -0,0 +1,31 @@
+> Layer A: [`workflow.md`](../../rules/workflow.md) §draft-flow-guard.sh による docs/ 直下 block | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# draft-flow-guard 緩和履歴 (Layer B)
+
+`draft-flow-guard.sh` の監視対象 path / bypass 経路本体は Layer A 参照。本 file は 2026-05-28 緩和 (旧 task-40 拡張撤廃) の経緯と緩和後 hook 役割。
+
+## 2026-05-28 緩和 (task-40 拡張の撤廃)
+
+旧 task-40 拡張 (2026-05-26) は `.claude/rules/*.md` / `.claude/commands/*.md` / `.claude/templates/docs/**/*.md` への **新規 Write** も draft 承認 (`approved_at` / `retroactive`) 不在で BLOCK していた。
+
+user 指示「既存 rules file の Edit は PASS (新規 Write のみ BLOCK) → 書き込みも許容してください」により、これらの規範文書 path は **新規 Write / 既存 Edit とも PASS** に緩和。本 hook はもはや `.claude/rules/` / `.claude/commands/` / `.claude/templates/docs/` を一切監視しない。frontmatter parser (`extract_frontmatter_value` / `verify_draft_status`) + 新 path pattern 判定 + retroactive 厳格化ロジックは hook から削除済。
+
+## 規範変更時の hook 役割 (緩和後)
+
+| シナリオ | 動作 |
+|---|---|
+| `.claude/rules/<basename>.md` / `.claude/commands/<basename>.md` / `.claude/templates/docs/**/<basename>.md` の **新規 Write / 既存 Edit** | **PASS (Edit 同様、2026-05-28 user 指示で緩和)** — 旧 task-40 拡張 (draft 承認不在で BLOCK) を撤廃 |
+| `docs/` 直下の既存 file の Edit | **PASS** — 新規 Write のみ block 対象 (`if [ -f "$file_path" ]; then exit 0; fi`) |
+| `docs/` 直下への新規設計文書 Write、対応 draft 不在 | **BLOCK** — 「先に `/new-draft <slug>` で設計を起こせ」(元機能、不変) |
+
+## 規範変更の honor system 降格
+
+機械強制 BLOCK は本緩和で解消されたため、規範変更の draft 経由フローは **honor system に降格**:
+- `.claude/rules/*.md` / `.claude/commands/*.md` / `.claude/templates/docs/**/*.md` への新規 Write / 既存 Edit は user 確認必須 / 設計→承認フロー推奨 (規律として残す方針)
+- `docs/` 直下の設計文書 block は維持 (機械強制 BLOCK)
+
+## 起源
+
+- 2026-05-26 task-40 で `.claude/rules/*.md` 等の規範文書も draft 経由必須化 (機械強制 BLOCK)、設計起源: `docs/draft/task-mgmt-rules-with-draft-flow-enforcement.md`
+- 2026-05-28 緩和: user 直接指示「既存 rules file の Edit は PASS (新規 Write のみ BLOCK) → 書き込みも許容してください」で task-40 拡張部分 (規範文書 path の新規 Write block) を撤廃
+- 関連: [`task-management.md`](../../rules/task-management.md) §「設計→承認→タスク追加フロー」/ [`modes.md`](../../rules/modes.md) 遵守事項 2 例外条項「規範変更」

package/.claude/rules-details/workflow/fan-out.md

@@ -0,0 +1,70 @@
+> Layer A: [`workflow.md`](../../rules/workflow.md) §設計レビューの fan-out (W2) | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# fan-out reviewer-registry 詳細 (Layer B)
+
+`/design-review` の reviewer-registry 表 / 並列数制御 / 収束条件 / stack heuristic 絞り込み / 集約フォーマット / reviewer 最低数 3 体の理由。Layer A は要約のみ。
+
+## reviewer-registry (`harness-config.yml`)
+
+| キー | 起動対象 agent | 用途 |
+|---|---|---|
+| `reviewer_registry_design` | architect / architect-reviewer / code-architect / api-designer / ui-designer / database-reviewer / harness-optimizer | W2 `/design-review` |
+| `reviewer_registry_security` | security-auditor / security-reviewer / penetration-tester | W2 `/design-review` |
+| `reviewer_registry_test` | tdd-guide / test-automator / qa-expert / pr-test-analyzer | W1 `/test-design` |
+| `reviewer_registry_impl` | code-reviewer / refactoring-specialist / 言語別 reviewer 群 | W3 `/module-review` `/system-review` |
+
+env 上書き例: `export HC_REVIEWER_REGISTRY_DESIGN=$'architect\narchitect-reviewer'` (改行区切り) で cost 制御可。
+
+## 並列数 / 反復制御
+
+`review_required_design` (default true) / `review_min_count_design` (default 3) / `review_max_count_design` (default 7) / `review_iteration_max` (default 5) で制御。`hc-config.sh --get review_min_count_design` で現在値確認、`--set` で変更 (atomic backup)。値解決順 `env > harness-config.local.yml > harness-config.yml > default`。
+
+## 収束条件 (反復ループ)
+
+draft レビューは「修正 → 再レビュー」を **CRITICAL + HIGH + MEDIUM = 0** になるまで反復 (LOW は許容、cosmetic finding として記録のみ)。
+
+| 規約 | 内容 |
+|---|---|
+| **reviewer 最低数** | **3 体以上** 並列起動 (default は reviewer-registry 全件 + stack heuristic 絞り込み、`N ≥ 3` 必須、不足で user escalation) |
+| **件数取得 severity** | CRITICAL / HIGH / MEDIUM / LOW の 4 段階 |
+| **収束条件** | CRITICAL = 0 ∧ HIGH = 0 ∧ MEDIUM = 0 (LOW は許容) |
+| **反復上限** | 5 回 (default、超過時 user escalation) |
+| **iteration 記録** | 各 iter の reviewer / 件数 / 修正 commit hash を draft §「レビューサイクル」table に append |
+| **bypass** | `ECC_DESIGN_REVIEW_OFF=1` (反復 5 回上限超過時の user escalation 後の継続用) |
+
+CRITICAL / HIGH / MEDIUM 全て 0 件 → draft「承認待ち」へ遷移可、1 件以上 → 「修正待ち」状態を明示し draft 修正 → 再 `/design-review` で round-N+1 review。
+
+## stack heuristic 絞り込み
+
+draft 本文を grep して以下キーワードを検出し、不要な reviewer を除外:
+
+- `database` / `migration` / `RLS` 不在 → database-reviewer skip
+- `API` / `endpoint` / `REST` / `GraphQL` 不在 → api-designer skip
+- `UI` / `component` / `frontend` 不在 → ui-designer skip
+
+`--skip-stack-filter` で全件起動、`--max-reviewers N` で上限指定可。
+
+## 集約フォーマット
+
+各 reviewer の SubagentStop 通知を受けたら findings を `docs/draft/<slug>-review.md` に append:
+
+```markdown
+## <reviewer-name> (iter <N>)
+- [CRITICAL] <finding summary> — <修正コード提案>
+- [HIGH] <finding summary> — <修正コード提案>
+- [MEDIUM] <finding summary> — <修正コード提案>
+- [LOW] <finding summary>
+
+confidence: 0.X
+```
+
+全件完了後に severity 別件数サマリ表 + blocking findings (CRITICAL / HIGH / MEDIUM) + 各 reviewer の confidence score 一覧を提示。
+
+## reviewer 最低数 3 体の理由
+
+- 1 体 → 偏り過大 (1 視点のみ)
+- 2 体 → 同意 / 不同意の二択判定不能 (合議制成立せず)
+- 3 体 → 過半数判定可能 (2-1 で多数決成立)
+- 5+ 体 → テスト設計レビュー (採用 6 条 4) と同水準、cost と quality のバランス
+
+registry 件数不足で 3 体起動不能なら user escalation (`/design-review --max-reviewers 2 --escalate-low-count`)。

package/.claude/rules-details/workflow/mece-20.md

@@ -0,0 +1,36 @@
+> Layer A: [`workflow.md`](../../rules/workflow.md) §テスト設計の MECE 強制 (W1) | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 20 MECE 各論 (Layer B)
+
+`/test-design` の MECE 20 カテゴリ各論 (採用 / 不採用判定例) + 3 agent 投票による default 判定。20 カテゴリ一覧・user スコープ承認・不採用理由 4 種は Layer A 参照。
+
+## 各カテゴリの採用 / 不採用判定例
+
+| # | カテゴリ | 採用例 | 不採用例 |
+|---|---|---|---|
+| 1 | 単体 | 全機能で原則 ☑ | 純粋 UI prop drilling のみ → `not-applicable` |
+| 2 | 統合 | API + DB 連動 → ☑ | 単一 module 完結 → `scope-excluded` |
+| 3 | E2E | UI 変更含む Task → 必須 ☑ | backend 専用 task → `scope-excluded` |
+| 4 | DB | migration 含む → ☑ | DB 触らない → `not-applicable` |
+| 5 | 境界値 | numeric range / string length 制約あり → ☑ | enum 固定値のみ → `accepted-risk` |
+| 6 | 異常系 | error handling 重要 → ☑ | happy path 確認 task → `scope-excluded` |
+| 7 | 回帰 | 既存機能修正 task は必須 ☑ | 完全新規機能 → `not-applicable` |
+| 8 | カバレッジ計測 | 大規模 module → ☑ | 1 file 数十行 → `scope-excluded` |
+| 9 | 網羅性検証 | enum / discriminated union → ☑ | bool flag のみ → `not-applicable` |
+| 10 | 完全性検証 | invariant 強い構造 → ☑ | 柔軟性優先設計 → `accepted-risk` |
+| 11 | 性能 | response time SLA → ☑ | 内部 utility → `not-applicable` |
+| 12 | 負荷 | 高 throughput endpoint → ☑ | 管理画面 → `accepted-risk` |
+| 13 | セキュリティ | 認証 / 認可 / 入力検証 → ☑ | 内部 helper → `not-applicable` |
+| 14 | 互換性 | 公開 API / DB schema → ☑ | private module → `not-applicable` |
+| 15 | アクセシビリティ | UI 含む → ☑ | backend → `not-applicable` |
+| 16 | i18n | 多言語対応 product → ☑ | 内部 tool → `scope-excluded` |
+| 17 | smoke | 重要 happy path → ☑ | edge case のみ → `existing-coverage` |
+| 18 | シナリオ | user flow 重要 → ☑ | unit-level fix → `scope-excluded` |
+| 19 | chaos・障害注入 | 高可用性要求 → ☑ | 内部 tool → `accepted-risk` |
+| 20 | 契約テスト | microservice 跨ぎ → ☑ | monolith → `not-applicable` |
+
+## 3 agent 投票による default 判定
+
+- 3 agent 中 **2 以上が採用推奨** → デフォルト ☑
+- 3 agent 中 **2 以上が不採用推奨** → デフォルト ☒
+- **意見割れ (1-1-1)** → ☐ + コメント「user 判断要」

package/.claude/rules-details/workflow/origin.md

@@ -0,0 +1,14 @@
+> Layer A: [`workflow.md`](../../rules/workflow.md) (全 §共通の起源 / commit hash) | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 起源 (Layer B)
+
+workflow.md 各規範 (W1-W4 / draft-flow-guard / 副産物 discharge / Session 永続化 / テスト設計レビュー収束条件 / 規範文書 honor system 降格) の起源・commit hash・採用判断の集約。
+
+- **W1-W4 規範化**: 設計起源は採用プロジェクト側 `docs/draft/workflow-enforcement.md` v2 §3 W1〜W4 (`.claude/` 単独で portable、本 file は採用後の規範を保持)
+- **draft-flow-guard.sh 元機能 (`docs/` 直下 block)**: 起源 commit `6ed9337`、後続緩和 task-40 (2026-05-26) → 撤廃 (2026-05-28、user 直接指示)
+- **task-40 拡張 (`.claude/rules/*.md` 等 BLOCK)**: 2026-05-26 採用、設計起源: `docs/draft/task-mgmt-rules-with-draft-flow-enforcement.md`、2026-05-28 緩和で撤廃
+- **副産物 discharge 5 層強制機構**: task #5 で実装、W1 (next-actions-surface) / W2 (`_TASK_TEMPLATE.md`) / W3 (byproduct-discharge-guard) / W4 (`/discharge-byproduct`) / W6 (smoke) の段階実装
+- **Session 永続化と PM Orchestration**: task #7 で実装、SuperClaude plugin の `/sc:save` `/sc:load` `/sc:pm` を `.claude/` 単独で portable な自前実装に置換
+- **テスト設計レビュー収束条件 (CRITICAL+HIGH+MEDIUM=0)**: 2026-05-26 採用 6 条 4 起源、`task-management.md` 採用 5 条 4 から拡張
+- **規範文書 honor system 降格 (2026-05-28)**: user 直接指示「規範文書 path は新規 Write / 既存 Edit とも hook で PASS」、機械強制 BLOCK 撤廃、規律として `modes.md` 遵守事項 2 例外条項「規範変更」で残置
+- 各規範の commit hash / 採用判断は git log + 関連 draft / 副産物 entry 参照

package/.claude/rules-details/workflow/refactoring.md

@@ -0,0 +1,48 @@
+> Layer A: [`workflow.md`](../../rules/workflow.md) §リファクタリング強制 (W3) | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# リファクタリング 3 観点詳細 (Layer B)
+
+`/module-review` 3 観点 / `/system-review` system-level 観点の sub-checklist。3 観点本体・pending_findings 連携・yml 制御は Layer A 参照。
+
+## review prompt 規約 (`/module-review` `/system-review` 共通)
+
+- **behavior-preserving 必須** — public API / DB schema 変更禁止
+- **全 finding に修正コード提案** — finding だけでなく具体的な patch 候補を併記
+- **末尾 `confidence: 0.X`** — F3 抽出対象 (`confidence-gate.sh` で閾値 0.6 未満は block)
+- 詳細は [`module-review.md`](../../commands/module-review.md) Phase 3 参照
+
+## 持続可能性 (Sustainability) sub-checklist
+
+- 命名 (camelCase / PascalCase / 意味的に明確か)
+- 関数 50 行以内 / ファイル 800 行以内 / ネスト 4 階層以内
+- magic number 排除 (定数化)
+- 副作用局所化 (pure function 優先)
+- 型注釈 (TypeScript / Python type hint)
+- silent failure 排除 (error handling 明示)
+
+## 汎用性 (Generality) sub-checklist
+
+- 引数化可能性 (hardcoded value を parameter 化)
+- 1 callee 特化排除 (汎用化推奨)
+- idiom 準拠 (言語別 idiom: Go の error handling / Rust の Result 等)
+- 抽象依存 (interface / trait 経由)
+- test seam (mock 注入可能性)
+
+## 非冗長化 (Deduplication) sub-checklist
+
+- DRY (重複ロジック抽出)
+- table-driven 化 (switch / if-else 連鎖を data 化)
+- util/helper 再発明排除 (既存 utility 流用)
+- 既存型流用 (重複 type 定義排除)
+- over-engineering 排除 (YAGNI)
+
+## system-level 観点 (`/system-review`) sub-checklist
+
+1. **モジュール間重複** — module 横断 DRY (`/module-review` は module 内 DRY のみ)
+2. **横断的責務漏れ** — logging / error handling / observability / rate limiting / authn-authz の一貫性
+3. **設計乖離** — `docs/draft/<slug>.md` §3 採用案からの逸脱 / `<slug>.test-design.md` ☒ テストが誤実装されていないか / §6 DoD 充足
+
+## MEDIUM / LOW のみ残存時の skip フロー
+
+- MEDIUM / LOW のみが残存する場合は user 承認のうえ `skip_log` に記録すれば pass 可能 (運用判断)
+- skip 記録 format: `{stage: "module-review", reason: "<LOW finding ID 列挙> user approved low-priority", user_approved_at: <ISO-8601>}`

package/.claude/rules-details/workflow/related-skills.md

@@ -0,0 +1,22 @@
+> Layer A: [`workflow.md`](../../rules/workflow.md) §関連ルール / skill (代表) | 本 file は **明示 Read のみ** (context 自動注入 OFF)
+
+# 関連 skill 完全 (Layer B)
+
+Layer A の関連ルール / skill (代表) を補完する完全 list。各 stage との連携先 skill を網羅。
+
+## 直接関連
+
+- `salesforce-e2e-testing` — Wave / Phase 完了時の E2E シナリオ設計 (Stage 13 `scenario-test` / Stage 9 `full-test` で参照)
+- `karpathy-guidelines` — surgical changes 原則 (`/module-review` / `/system-review` の behavior-preserving 原則と整合)
+
+## 補助関連
+
+- `tdd-workflow` — Stage 8 `tdd` の RED → GREEN → REFACTOR ループ規範
+- `eval-harness` (L1) — Stage 10 `local-test` の pass@k metrics 連携
+- `verification-loop` (F2) — Stage 14 `finish` 直前の 6 phase 検証
+- `gateguard` (F1) — Stage 8 `tdd` 中の Edit/Write 事前事実検証
+
+## audit 系
+
+- `harness-audit.py` の `bypass_log_summary()` / `fmt_bypass_log()` — `/harness-audit` での bypass 集計
+- `.claude/.workflow-state/SCHEMA.md` — workflow-guard.sh が参照する JSON 仕様 SSoT