takt 0.32.0 → 0.32.2

package/builtins/en/pieces/review-fix-takt-default.yaml

@@ -12,7 +12,7 @@ loop_monitors:
   - cycle:
       - ai_review
       - ai_fix
-    threshold: 3
+    threshold: 5
     judge:
       persona: supervisor
       instruction: loop-monitor-ai-fix
@@ -24,7 +24,7 @@ loop_monitors:
   - cycle:
       - reviewers
       - fix
-    threshold: 3
+    threshold: 5
     judge:
       persona: supervisor
       instruction: loop-monitor-reviewers-fix
@@ -142,6 +142,9 @@ movements:
         policy:
           - review
           - testing
+        knowledge:
+          - unit-testing
+          - e2e-testing
         provider_options:
           claude:
             allowed_tools:

package/builtins/en/pieces/review-frontend.yaml

@@ -62,7 +62,9 @@ movements:
       - name: frontend-review
         edit: false
         persona: frontend-reviewer
-        policy: review
+        policy:
+          - review
+          - design-fidelity
         knowledge: frontend
         provider_options:
           claude:

package/builtins/en/pieces/review-takt-default.yaml

@@ -117,6 +117,9 @@ movements:
         policy:
           - review
           - testing
+        knowledge:
+          - unit-testing
+          - e2e-testing
         provider_options:
           claude:
             allowed_tools:

package/builtins/en/pieces/security-audit.yaml

@@ -0,0 +1,68 @@
+name: security-audit
+description: Full security audit. Reads every project file one by one for security review
+max_movements: 15
+initial_movement: plan
+
+loop_monitors:
+  - cycle: [supervise, review]
+    threshold: 5
+    judge:
+      persona: supervisor
+      instruction: |
+        The supervise → review cycle for the security audit has repeated {cycle_count} times.
+        Judge the overall quality and completeness of the audit, and decide whether to accept the current results.
+      rules:
+        - condition: Quality is sufficient
+          next: COMPLETE
+        - condition: Quality is insufficient with no prospect of improvement
+          next: ABORT
+
+movements:
+  - name: plan
+    persona: planner
+    instruction: security-audit-plan
+    edit: false
+    output_contracts:
+      report:
+        - name: 01-plan.md
+          format: plan
+    rules:
+      - condition: Project structure understood
+        next: audit
+
+  - name: audit
+    persona: security-reviewer
+    knowledge: security
+    instruction: security-audit-team-leader
+    edit: false
+    team_leader:
+      max_parts: 3
+      part_persona: security-reviewer
+      part_edit: false
+    output_contracts:
+      report:
+        - name: 02-security-audit.md
+          format: security-audit
+    rules:
+      - condition: Audit complete
+        next: supervise
+
+  - name: supervise
+    persona: supervisor
+    knowledge: security
+    instruction: security-audit-supervise
+    edit: false
+    rules:
+      - condition: All files audited with sufficient quality
+        next: COMPLETE
+      - condition: Unaudited files exist or audit is insufficient
+        next: review
+
+  - name: review
+    persona: security-reviewer
+    knowledge: security
+    instruction: security-audit-review
+    edit: false
+    rules:
+      - condition: Re-audit complete
+        next: supervise

package/builtins/en/pieces/takt-default.yaml

@@ -12,7 +12,7 @@ loop_monitors:
   - cycle:
       - ai_review
       - ai_fix
-    threshold: 3
+    threshold: 5
     judge:
       persona: supervisor
       instruction: loop-monitor-ai-fix
@@ -24,7 +24,7 @@ loop_monitors:
   - cycle:
       - reviewers
       - fix
-    threshold: 3
+    threshold: 5
     judge:
       persona: supervisor
       instruction: loop-monitor-reviewers-fix
@@ -72,6 +72,8 @@ movements:
     knowledge:
       - takt
       - architecture
+      - unit-testing
+      - e2e-testing
     provider_options:
       claude:
         allowed_tools:
@@ -305,6 +307,9 @@ movements:
         policy:
           - review
           - testing
+        knowledge:
+          - unit-testing
+          - e2e-testing
         provider_options:
           claude:
             allowed_tools:

package/builtins/en/pieces/terraform.yaml

@@ -51,7 +51,6 @@ movements:
           - Bash
           - WebSearch
           - WebFetch
-    required_permission_mode: full
     quality_gates:
       - terraform fmt -check passes without errors
       - terraform validate succeeds
@@ -176,7 +175,6 @@ movements:
               - Bash
               - WebSearch
               - WebFetch
-        required_permission_mode: full
         rules:
           - condition: AI issue fix complete
           - condition: No fix needed (target file/spec verified)
@@ -198,7 +196,6 @@ movements:
               - Bash
               - WebSearch
               - WebFetch
-        required_permission_mode: full
         rules:
           - condition: Supervisor's findings have been fixed
           - condition: Cannot proceed with fix
@@ -225,7 +222,6 @@ movements:
           - Bash
           - WebSearch
           - WebFetch
-    required_permission_mode: full
     pass_previous_response: false
     rules:
       - condition: AI issue fix complete
@@ -252,7 +248,6 @@ movements:
           - Bash
           - WebSearch
           - WebFetch
-    required_permission_mode: full
     pass_previous_response: false
     rules:
       - condition: Supervisor's findings have been fixed

package/builtins/ja/INSTRUCTION_STYLE_GUIDE.md

@@ -2,17 +2,16 @@
 
 このガイドは `instructions/` のファイルを作成・編集する際のルールを定義する。
 
-## テンプレート
+## 参照元
 
-`templates/instructions/` にテンプレートファイルを用意している。新規作成時は参照して使う。
+`facets/instructions/` を参照元として使う。新規作成時は既存ファイルを参照して使う。
 
-| テンプレート | 用途 |
+| 参照ファイル | 用途 |
 |------------|------|
 | `plan.md` | 計画（タスク分析・要件整理） |
 | `architect.md` | 設計（アーキテクチャ設計） |
 | `implement.md` | 実装（コーディング + レポート埋め込み） |
-| `review.md` | レビュー（parallel sub-step 汎用） |
-| `ai-review-standalone.md` | AIレビュー（standalone、iteration tracking） |
+| `review-ai.md` | AIレビュー（parallel sub-step 汎用） |
 | `ai-fix.md` | AI指摘修正（全ピース共通） |
 | `fix.md` | レビュー指摘修正（汎用 fix / supervise fix） |
 | `arbitrate.md` | 裁定（レビュアー vs コーダー） |
@@ -22,7 +21,7 @@
 
 ## インストラクションとは
 
-ピースのムーブメントで実行する具体的な手順。`instruction_template` フィールドに直接記述するか、ファイル参照で使用する。
+ピースのムーブメントで実行する具体的な手順。`instruction` フィールドでファイル参照するか、インラインで直接記述する。
 
 | 項目 | 内容 |
 |------|------|
@@ -65,7 +64,7 @@
 
 ### セクション注入（`## Instructions` の前に別セクションとして挿入）
 
-`perform_phase1_message.md` のテンプレート側で処理される。instruction_template の外に配置される。
+`perform_phase1_message.md` 側で処理される。`instruction` の外に配置される。
 
 | セクション | 内容 | デフォルト |
 |-----------|------|-----------|
@@ -73,11 +72,11 @@
 | `## Previous Response` | 前ムーブメントの出力 | **初回以外は常に表示**（`pass_previous_response` デフォルト: `true`） |
 | `## Additional User Inputs` | 蓄積されたユーザー入力 | **常に表示** |
 
-抑制したい場合は instruction_template 内にプレースホルダー（`{task}`, `{previous_response}`, `{user_inputs}`）を含めるか、`pass_previous_response: false` を設定する。通常は不要。
+抑制したい場合は `instruction` 内にプレースホルダー（`{task}`, `{previous_response}`, `{user_inputs}`）を含めるか、`pass_previous_response: false` を設定する。通常は不要。
 
-### テンプレート変数展開（instruction_template 内のプレースホルダーを置換）
+### テンプレート変数展開（`instruction` 内のプレースホルダーを置換）
 
-InstructionBuilder が instruction_template 内の `{変数名}` を展開する。インストラクション内で使用可能。
+InstructionBuilder が `instruction` 内の `{変数名}` を展開する。インストラクション内で使用可能。
 
 | 変数 | 内容 |
 |------|------|

package/builtins/ja/KNOWLEDGE_STYLE_GUIDE.md

@@ -2,13 +2,13 @@
 
 このガイドは `knowledge/` のファイルを作成・編集する際のルールを定義する。
 
-## テンプレート
+## 参照元
 
-`templates/knowledge/` にテンプレートファイルを用意している。新規作成時はコピーして使う。
+`facets/knowledge/` を参照元として使う。新規作成時は既存ファイルをコピーして使う。
 
-| テンプレート | 用途 | 使用例 |
+| 参照ファイル | 用途 | 使用例 |
 |------------|------|--------|
-| `knowledge.md` | ドメイン知識 | frontend, backend, security |
+| `takt.md` | ドメイン知識 | frontend, backend, security |
 
 ---
 

package/builtins/ja/OUTPUT_CONTRACT_STYLE_GUIDE.md

@@ -2,15 +2,15 @@
 
 このガイドは `output-contracts/` のファイルを作成・編集する際のルールを定義する。
 
-## テンプレート
+## 参照元
 
-`templates/reports/` にテンプレートファイルを用意している。新規作成時は参照して使う。
+`facets/output-contracts/` を参照元として使う。新規作成時は既存ファイルを参照して使う。
 
-| テンプレート | 用途 |
+| 参照ファイル | 用途 |
 |------------|------|
 | `plan.md` | タスク計画（標準 / 拡張） |
 | `architecture-design.md` | アーキテクチャ設計 |
-| `review.md` | 汎用レビュー結果 |
+| `review-gather.md` | 汎用レビュー結果 |
 | `security-review.md` | セキュリティレビュー（重大度付き） |
 | `validation.md` | 最終検証結果 |
 | `summary.md` | タスク完了サマリー |

package/builtins/ja/PERSONA_STYLE_GUIDE.md

@@ -2,15 +2,15 @@
 
 このガイドは `personas/` のファイルを作成・編集する際のルールを定義する。
 
-## テンプレート
+## 参照元
 
-`templates/personas/` にテンプレートファイルを用意している。新規作成時はコピーして使う。
+`facets/personas/` を参照元として使う。新規作成時は既存ファイルをコピーして使う。
 
-| テンプレート | 用途 | 使用例 |
+| 参照ファイル | 用途 | 使用例 |
 |------------|------|--------|
-| `simple.md` | ドメイン知識を持たない実行系エージェント | coder, planner, conductor, research-digger |
-| `expert.md` | ドメイン知識を持つ専門エージェント | architecture-reviewer, security-reviewer, cqrs-es-reviewer |
-| `character.md` | 固有の人格・口調を持つキャラクター型 | melchior, balthasar, casper |
+| `coder.md` | ドメイン知識を持たない実行系エージェント | coder, planner, conductor, research-digger |
+| `architecture-reviewer.md` | ドメイン知識を持つ専門エージェント | architecture-reviewer, security-reviewer, cqrs-es-reviewer |
+| `melchior.md` | 固有の人格・口調を持つキャラクター型 | melchior, balthasar, casper |
 
 ---
 
@@ -48,7 +48,7 @@
 このルール/知識は…
 ├── 特定のエージェントだけが必要 → ペルソナ（ドメイン知識）
 ├── 複数のエージェントが共有 → ポリシー
-└── 特定のピースの実行手順 → instruction_template（ペルソナに書かない）
+└── 特定のピースの実行手順 → instruction（ペルソナに書かない）
 ```
 
 ---
@@ -158,7 +158,7 @@
 1. **ポリシーの詳細ルール**: コード例・判定基準・例外リスト等の詳細はポリシーの責務（1行の行動指針は行動姿勢に記載してよい）
 2. **ピース固有の概念**: ムーブメント名、レポートファイル名、ステップ間ルーティング
 3. **ツール固有の環境情報**: `.takt/runs/` 等のディレクトリパス、テンプレート変数（`{report_dir}` 等）
-4. **実行手順**: 「まず〜を読み、次に〜を実行」のような手順はinstruction_templateの責務
+4. **実行手順**: 「まず〜を読み、次に〜を実行」のような手順は instruction の責務
 
 ### 例外: ドメイン知識としての重複
 

package/builtins/ja/POLICY_STYLE_GUIDE.md

@@ -2,13 +2,13 @@
 
 このガイドは `policies/` のファイルを作成・編集する際のルールを定義する。
 
-## テンプレート
+## 参照元
 
-`templates/policies/` にテンプレートファイルを用意している。新規作成時はコピーして使う。
+`facets/policies/` を参照元として使う。新規作成時は既存ファイルをコピーして使う。
 
-| テンプレート | 用途 | 使用例 |
+| 参照ファイル | 用途 | 使用例 |
 |------------|------|--------|
-| `policy.md` | 共有行動規範 | coding, review, testing |
+| `coding.md` | 共有行動規範 | coding, review, testing |
 
 ---
 
@@ -29,7 +29,7 @@
 このルール/知識は…
 ├── 特定のエージェントだけが必要 → ペルソナ（ドメイン知識）
 ├── 複数のエージェントが共有 → ポリシー
-└── 特定のピースの実行手順 → instruction_template（ポリシーに書かない）
+└── 特定のピースの実行手順 → instruction（ポリシーに書かない）
 ```
 
 ---

package/builtins/ja/STYLE_GUIDE.md

@@ -10,35 +10,17 @@
 | インストラクション | [INSTRUCTION_STYLE_GUIDE.md](INSTRUCTION_STYLE_GUIDE.md) | Phase 1 メッセージ（`{{instructions}}`） |
 | 出力契約 | [OUTPUT_CONTRACT_STYLE_GUIDE.md](OUTPUT_CONTRACT_STYLE_GUIDE.md) | `report.format` |
 
-## テンプレート
+## 参照元
 
-`templates/` にテンプレートファイルを用意している。新規作成時はコピーまたは参照して使う。
+`facets/` のファイルを参照元として使う。新規作成時はコピーまたは参照して使う。
 
 ```
-templates/
-├── personas/          # ペルソナテンプレート
-│   ├── simple.md      # ドメイン知識なし
-│   ├── expert.md      # ドメイン知識あり
-│   └── character.md   # キャラクター型
-├── policies/          # ポリシーテンプレート
-│   └── policy.md
-├── instructions/      # インストラクションテンプレート
-│   ├── plan.md
-│   ├── architect.md
-│   ├── implement.md
-│   ├── review.md
-│   ├── ai-review-standalone.md
-│   ├── ai-fix.md
-│   ├── fix.md
-│   ├── arbitrate.md
-│   └── supervise.md
-└── reports/           # 出力契約テンプレート
-    ├── plan.md
-    ├── architecture-design.md
-    ├── review.md
-    ├── security-review.md
-    ├── validation.md
-    └── summary.md
+facets/
+├── personas/          # ペルソナ
+├── policies/          # ポリシー
+├── instructions/      # インストラクション
+├── knowledge/         # ナレッジ
+└── output-contracts/  # 出力契約
 ```
 
 ## 3層プロンプトアーキテクチャ

package/builtins/ja/facets/instructions/e2e-coverage-implement.md

@@ -0,0 +1,26 @@
+テストケースリストに基づき、不足しているE2Eテストを実装してください。
+
+**重要:** テスト計画レポートを参照してください: {report:01-e2e-coverage-plan.md}
+
+**注意:** Previous Responseがある場合は差し戻しのため、
+未実装と指摘されたテストケースを確認し、そのケースの実装を行ってください。
+
+**やること:**
+1. テスト計画のテストケースリスト（番号付き）を確認する
+2. 既存E2Eテストのパターン（ファイル構成、ヘルパー、フィクスチャ、モック方針）に合わせて実装する
+3. テストケースリストの全件を実装する（一部だけ実装して終わりにしない）
+4. E2Eテストを実行し、全テストがパスすることを確認する
+5. 既存のE2Eテストが壊れていないことを確認する
+
+**実装の制約:**
+- 既存のE2Eテストフレームワークを変更しない
+- テストは1シナリオ1関心で記述し、期待結果を明確にする
+- 外部依存があるケースは既存のフィクスチャ・ヘルパー・モック方針に合わせる
+
+**必須出力（見出しを含める）**
+## 実装したテストケース
+- {テストケースリストの番号と対応するテストファイル・テスト名}
+## 未実装のテストケース（ある場合）
+- {番号と未実装の理由}
+## テスト結果
+- {実行コマンドと結果}

package/builtins/ja/facets/instructions/e2e-coverage-plan.md

@@ -0,0 +1,38 @@
+アプリケーションのユーザー操作ルートを網羅的に洗い出し、不足しているE2Eテストケースをリスト化してください。
+
+**注意:** Previous Responseがある場合は差し戻しのため、
+その内容を踏まえてリストを見直してください。
+
+**やること:**
+
+1. **E2Eテストインフラの把握**
+   - 既存E2Eテストのディレクトリ構成、テストランナー、ヘルパー、フィクスチャ、モック方針を確認する
+   - テストの実行コマンドと実行方法を把握する
+
+2. **ユーザー操作の起点を特定する**（ドキュメントではなくコードを読む）
+   - CLIの場合: コマンド定義・サブコマンド・オプション一覧をコードから抽出する
+   - Webの場合: ルーティング定義・ページ遷移・APIエンドポイントをコードから抽出する
+   - 各起点のハンドラ・処理フローを追跡し、分岐・状態遷移を把握する
+
+3. **UXバリエーションを深掘りする**
+   - 各起点について、ユーザーが辿りうる全ルートを列挙する
+   - オプション・フラグの組み合わせによる分岐（例: `--pipeline` あり/なし、`--auto-pr` あり/なし）
+   - 状態による分岐（初回実行 vs 既存データあり、設定ファイルあり vs なし）
+   - 正常フローだけでなく、途中で失敗した場合のエラーハンドリング・リカバリールート
+   - 権限・ロール別のルート
+   - 外部依存の状態による分岐（接続成功 vs 失敗、レスポンス正常 vs 異常）
+
+4. **既存E2Eテストとの突き合わせ**
+   - 既存テストが何をカバーしているかをファイル単位で分析する
+   - 洗い出したルートのうち、既存テストでカバー済みのものを特定する
+   - 未カバーのルートを「不足テストケース」としてリスト化する
+
+5. **テストケースリストの作成**
+   - 全テストケースに一意の番号を付ける（supervisor が突き合わせに使う台帳）
+   - 各ケースに優先度を付ける（ユーザー影響度 × 未テストのリスク）
+   - **省略しない。** 1-2件で終わらせず、洗い出した全ルートを網羅すること
+
+**絶対禁止:**
+- ドキュメントやREADMEだけ読んでテストケースを推測する → 禁止。コードを読む
+- 「他にもあるかもしれない」で列挙を打ち切る → 禁止。全件洗い出す
+- 既存テストと重複するケースをリストに含める → 禁止。突き合わせ済みのもののみ

package/builtins/ja/facets/instructions/e2e-coverage-supervise.md

@@ -0,0 +1,21 @@
+テスト計画のテストケースリストと実装結果を突き合わせ、全件実装されたか検証してください。
+
+**重要:** テスト計画レポートを参照してください: {report:01-e2e-coverage-plan.md}
+
+**検証手順:**
+
+1. **テストケースリストとの突き合わせ（最重要）**
+   - 計画レポートのテストケースリスト（番号付き）を1件ずつ確認する
+   - 各ケースに対応するテストファイル・テスト名を特定する
+   - テストファイルを Read して、実際にそのケースがテストされているか確認する
+   - 対応するテストがないケースを「未実装」として列挙する
+   - 未実装が1件でもあれば REJECT する
+
+2. **テストの品質検証**
+   - 各テストがテストケースの意図を正しく検証しているか
+   - アサーションが適切か（存在確認だけでなく、期待値の検証）
+   - モック・フィクスチャの使い方が既存パターンに合っているか
+
+3. **テスト実行の確認**
+   - E2Eテストを実行し、全件パスすることを確認する
+   - 既存テストが壊れていないことを確認する

package/builtins/ja/facets/instructions/fix.md

@@ -1,5 +1,9 @@
 Report Directory内のレビューレポートを確認し、指摘事項を修正してください。
 
+**修正の原則:**
+- 指摘の「修正案」が示されている場合はそれに沿った対応を優先し、独自の迂回策を取らない
+- 指摘の対象コードを直接修正すること。テストやドキュメントの追加で指摘を回避しない
+
 **レポート参照方針:**
 - Report Directory内の最新レビューレポートを一次情報として参照してください。
 - 過去イテレーションのレポートは `{ファイル名}.{タイムスタンプ}` 形式で同ディレクトリに保存されています（例: `architect-review.md.20260304T123456Z`）。各レポートについて `{レポート名}.*` パターンで Glob を実行し、タイムスタンプ降順で最大2件まで読み、persists / reopened の傾向を把握してから修正に入ること。

package/builtins/ja/facets/instructions/loop-monitor-ai-fix.md

@@ -7,6 +7,7 @@ ai_review と ai_fix のループが {cycle_count} 回繰り返されました
 - AIレビュー結果: {report:ai-review.md}
 
 **判断基準:**
-- 各サイクルで新しい問題が発見・修正されているか
-- 同じ指摘が繰り返されていないか
-- 修正が実際に反映されているか
+- 同一 finding_id が複数サイクルにわたって persists しているか
+  - 同一 finding_id が繰り返し persists → 非生産的（スタックしている）
+  - 前回の finding が resolved され、新しい finding が new → 健全（進捗あり）
+- 修正が実際にコードに反映されているか

package/builtins/ja/facets/instructions/loop-monitor-reviewers-fix.md

@@ -4,6 +4,8 @@ Report Directory 内の最新レビューレポートを確認し、
 このループが健全（収束傾向）か非生産的（発散・振動）かを判断してください。
 
 **判断基準:**
-- 各サイクルで new / reopened の指摘件数が減少しているか
-- 同じ family_tag の指摘が繰り返されていないか（persists が増えていないか）
+- 同一 finding_id が複数サイクルにわたって persists しているか
+  - 同一 finding_id が繰り返し persists → 非生産的（スタックしている）
+  - 前回の finding が resolved され、新しい finding が new → 健全（収束傾向）
 - 修正が実際にコードに反映されているか
+- new / reopened の指摘件数が全体として減少傾向にあるか

package/builtins/ja/facets/instructions/plan.md

@@ -25,7 +25,9 @@
 5. ファイル構成・設計パターンを決定する（必要な場合）
 6. 実装アプローチを決める
    - 実装アプローチがナレッジ・ポリシーの制約に違反しないか照合する
+   - 利用者向け機能の追加や変更がある場合、利用者がその機能へ到達する条件・入口・起動経路を固定する
 7. Coder向けの実装ガイドラインに以下を含めること:
    - 参照すべき既存実装パターン（ファイル:行）。同種の処理が既にある場合は必ず示す
    - 変更の影響範囲。特に新しいパラメータを追加する場合、配線が必要な全箇所を列挙する
    - このタスクで特に注意すべきアンチパターン（該当するものがあれば）
+   - 利用者向け機能の追加や変更がある場合、到達経路・呼び出し元・起動条件に関する変更箇所

package/builtins/ja/facets/instructions/review-frontend.md

@@ -1,13 +1,21 @@
 フロントエンド開発の観点から変更をレビューしてください。
 
 **レビュー観点:**
+- デザイン忠実度（デザイン参照が指定されている場合、最優先で確認）
 - コンポーネント設計（責務分離、粒度）
 - 状態管理（ローカル/グローバルの判断）
 - パフォーマンス（再レンダリング、メモ化）
 - アクセシビリティ（キーボード操作、ARIA）
 - データフェッチパターン
+- 利用者が機能へ到達できる配線（route、導線、起動条件）
 - TypeScript型安全性
 
+**デザイン忠実度チェック（デザイン参照がある場合）:**
+1. タスク指示書の参照資料からデザイン参照を特定する
+2. デザインの要素（レイアウト、文言、色、間隔）を実装と要素単位で比較する
+3. 差分がある場合、決定ログで意図的かどうかを確認する
+4. 意図的でない差分はブロッキング問題として報告する
+
 **注意**: このプロジェクトがフロントエンドを含まない場合は、
 問題なしとして次に進んでください。
 
@@ -21,5 +29,6 @@
 
 1. 変更差分を確認し、フロントエンド開発の観点に基づいて問題を検出する
    - ナレッジの判定基準テーブル（REJECT条件）と変更内容を照合する
+   - 新規の画面・機能ファイルが追加されている場合、利用者が到達する入口や呼び出し元の更新有無を確認する
 2. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
 3. ブロッキング問題が1件でもあればREJECTと判定する

package/builtins/ja/facets/instructions/security-audit-plan.md

@@ -0,0 +1,12 @@
+プロジェクトの全体像を把握し、セキュリティ監査の対象ファイル一覧を作成してください。
+
+**やること:**
+1. プロジェクトのソースコードディレクトリを特定し、全ファイルを Glob で一覧化する
+2. プロジェクトの技術スタック、フレームワーク、主要な依存関係を把握する
+3. 各ファイルの役割を簡潔に分類する（API層、ドメイン層、インフラ層、ユーティリティ等）
+4. セキュリティリスクの高いファイルを特定する（認証、入力処理、外部通信、ファイル操作、設定等）
+
+**重要:**
+- 全ファイルを漏れなく一覧化すること。省略しない
+- 設定ファイル、テストファイルも含める
+- ファイル数が多い場合でも省略せず全件列挙する

package/builtins/ja/facets/instructions/security-audit-review.md

@@ -0,0 +1,22 @@
+前回の監査で不十分と判断されたファイルを再監査してください。
+
+**重要:** supervisor の検証結果を確認し、以下を把握してください:
+- 未監査ファイルの一覧
+- 監査が不十分と指摘されたファイルの一覧
+- 具体的な指摘内容
+
+**やること:**
+1. 指摘された全ファイルを **Read tool で1つずつ全文を読む**
+2. 各ファイルについてセキュリティ観点でレビューする
+3. 発見した問題を重大度付きで報告する
+
+**絶対禁止事項:**
+- Grep でキーワード検索してヒットしたファイルだけ見る → 禁止
+- ファイルの一部だけ読んで判断する → 禁止
+- 「問題なさそう」で読み飛ばす → 禁止
+
+**必須出力（見出しを含める）:**
+## 再監査結果
+- {各ファイルごとの監査結果}
+## 検出された問題
+- {問題の詳細（重大度、場所、修正案）}

package/builtins/ja/facets/instructions/security-audit-supervise.md

@@ -0,0 +1,20 @@
+セキュリティ監査の網羅性と品質を検証してください。
+
+**重要:** 計画レポートを参照してください: {report:01-plan.md}
+
+**検証手順:**
+
+1. **網羅性の検証（最重要）**
+   - 計画レポートのファイル一覧と、監査結果で言及されたファイルを突き合わせる
+   - 監査結果に言及がないファイルを「未監査ファイル」として列挙する
+   - 未監査ファイルが1件でもあれば REJECT する
+
+2. **手法の検証**
+   - 各ファイルの監査結果が具体的なコード内容に言及しているか確認する
+   - 「問題なし」のみで具体的な確認内容が書かれていない場合、実際に Read していない可能性がある → REJECT
+   - Grep のキーワードマッチだけで判断している形跡がないか確認する
+
+3. **品質の検証**
+   - 検出された問題の重大度分類が妥当か
+   - 見落としがないか、自分でもセキュリティリスクの高いファイルを数件 Read して確認する
+   - 誤検知（FP）が多すぎないか