takt 0.35.3 → 0.36.0

package/builtins/en/workflows/dual.yaml

@@ -115,6 +115,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     session: refresh
     knowledge:
       - frontend
@@ -201,6 +202,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     session: refresh
     knowledge:
       - frontend
@@ -409,6 +411,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - react

package/builtins/en/workflows/review-fix-dual-cqrs.yaml

@@ -179,6 +179,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - backend
@@ -239,6 +240,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - backend

package/builtins/en/workflows/review-fix-dual.yaml

@@ -155,6 +155,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - backend
@@ -214,6 +215,7 @@ steps:
       - coding
       - testing
       - design-fidelity
+      - screen-api
     knowledge:
       - frontend
       - backend

package/builtins/ja/INSTRUCTION_STYLE_GUIDE.md

@@ -12,7 +12,7 @@
 | `architect.md` | 設計（アーキテクチャ設計） |
 | `implement.md` | 実装（コーディング + レポート埋め込み） |
 | `review-ai.md` | AIレビュー（parallel sub-step 汎用） |
-| `ai-fix.md` | AI指摘修正（全ピース共通） |
+| `ai-fix.md` | AI指摘修正（全ワークフロー共通） |
 | `fix.md` | レビュー指摘修正（汎用 fix / supervise fix） |
 | `arbitrate.md` | 裁定（レビュアー vs コーダー） |
 | `supervise.md` | 最終検証（レポート埋め込み） |
@@ -21,14 +21,14 @@
 
 ## インストラクションとは
 
-ピースのムーブメントで実行する具体的な手順。`instruction` フィールドでファイル参照するか、インラインで直接記述する。
+ワークフローのステップで実行する具体的な手順。`instruction` フィールドでファイル参照するか、インラインで直接記述する。
 
 | 項目 | 内容 |
 |------|------|
-| 目的 | ムーブメントの実行手順と出力要件の定義 |
+| 目的 | ステップの実行手順と出力要件の定義 |
 | 配置 | Phase 1 メッセージの `## Instructions`（`{{instructions}}`） |
-| 対象 | 1つのムーブメント |
-| 判断基準 | 「この手順は特定のムーブメント/ピースに固有か？」→ YES |
+| 対象 | 1つのステップ |
+| 判断基準 | 「この手順は特定のステップ/ワークフローに固有か？」→ YES |
 
 ### 実際の配置先
 
@@ -37,7 +37,7 @@
 ```
 ## 実行コンテキスト（作業ディレクトリ）
 ## 実行ルール（git commit禁止、cd禁止、edit権限）
-## Piece Context（ピース名、Iteration、Movement Iteration、Report Directory）
+## Workflow Context（ワークフロー名、Iteration、Step Iteration、Report Directory）
 ## User Request（自動注入）
 ## Previous Response（自動注入、pass_previous_response: true 時）
 ## Additional User Inputs（自動注入）
@@ -45,7 +45,7 @@
 {{instructions}}  ← ★ インストラクションがここに展開される
 ```
 
-インストラクションの前に実行コンテキスト、ピース情報、ユーザーリクエスト、前回レスポンス等が既に提供されている。これらを再記述する必要はない。
+インストラクションの前に実行コンテキスト、ワークフロー情報、ユーザーリクエスト、前回レスポンス等が既に提供されている。これらを再記述する必要はない。
 
 ### ペルソナ・ポリシーとの分離
 
@@ -53,7 +53,7 @@
 この内容は…
 ├── エージェントの identity・専門知識 → ペルソナ
 ├── 複数エージェントの共有ルール → ポリシー
-└── ムーブメント固有の手順・出力形式 → インストラクション
+└── ステップ固有の手順・出力形式 → インストラクション
 ```
 
 ---
@@ -69,7 +69,7 @@
 | セクション | 内容 | デフォルト |
 |-----------|------|-----------|
 | `## User Request` | ユーザーの元リクエスト | **常に表示** |
-| `## Previous Response` | 前ムーブメントの出力 | **初回以外は常に表示**（`pass_previous_response` デフォルト: `true`） |
+| `## Previous Response` | 前ステップの出力 | **初回以外は常に表示**（`pass_previous_response` デフォルト: `true`） |
 | `## Additional User Inputs` | 蓄積されたユーザー入力 | **常に表示** |
 
 抑制したい場合は `instruction` 内にプレースホルダー（`{task}`, `{previous_response}`, `{user_inputs}`）を含めるか、`pass_previous_response: false` を設定する。通常は不要。
@@ -80,9 +80,9 @@ InstructionBuilder が `instruction` 内の `{変数名}` を展開する。イ
 
 | 変数 | 内容 |
 |------|------|
-| `{iteration}` | ピース全体のイテレーション数 |
-| `{max_movements}` | 最大イテレーション数 |
-| `{movement_iteration}` | ムーブメント単位のイテレーション数 |
+| `{iteration}` | ワークフロー全体のイテレーション数 |
+| `{max_steps}` | 最大イテレーション数 |
+| `{step_iteration}` | step 単位のイテレーション数 |
 | `{report_dir}` | レポートディレクトリ名（`.takt/runs/{slug}/reports`） |
 | `{report:filename}` | 指定レポートの内容展開（ファイルが存在する場合） |
 | `{cycle_count}` | ループモニターで検出されたサイクル回数（`loop_monitors` 専用） |
@@ -118,7 +118,7 @@ InstructionBuilder が `instruction` 内の `{変数名}` を展開する。イ
 実行済みの証跡を確認し、最終承認を行ってください。
 
 # 悪い例
-このムーブメントではタスクの分析を行います。  ← 説明文になっている
+このステップではタスクの分析を行います。  ← 説明文になっている
 ```
 
 ### 注意事項・条件
@@ -132,7 +132,7 @@ InstructionBuilder が `instruction` 内の `{変数名}` を展開する。イ
 その内容を踏まえて計画を見直してください（replan）。
 
 # 良い例（イテレーション追跡）
-**これは {movement_iteration} 回目の AI Review です。**
+**これは {step_iteration} 回目の AI Review です。**
 2回目以降は、前回の修正が実際には行われていなかったということです。
 ```
 
@@ -197,7 +197,7 @@ InstructionBuilder が `instruction` 内の `{変数名}` を展開する。イ
 | テンプレート変数を正しく使う | 自動注入される変数を手動で書く |
 | 出力契約は```markdownで囲む | プレーンテキストで出力契約を書く |
 | 必須出力の見出しを `##` で指定 | 出力形式を指定しない |
-| そのムーブメントの手順に集中 | ペルソナ（専門知識）の内容を混ぜる |
+| そのステップの手順に集中 | ペルソナ（専門知識）の内容を混ぜる |
 | `{report:filename}` でレポートを参照 | ファイルパスをハードコードする |
 
 ---
@@ -207,12 +207,12 @@ InstructionBuilder が `instruction` 内の `{変数名}` を展開する。イ
 1. **ペルソナの内容**: エージェントの専門知識、検出手法、行動姿勢
 2. **ポリシーの内容**: DRY、Fail Fast 等の共有コーディング原則
 3. **自動注入される内容**: `{task}`, `{previous_response}` のプレースホルダーを明示的に書かない（エンジンが自動付加する）
-4. **他のムーブメント名の直接参照**: 「implement ムーブメントに戻る」等（ルーティングはルール定義の責務）
-5. **ピース固有のルーティング**: 「APPROVE なら次へ」等（ルール条件の責務）
+4. **他のステップ名の直接参照**: 「implement ステップに戻る」等（ルーティングはルール定義の責務）
+5. **ワークフロー固有のルーティング**: 「APPROVE なら次へ」等（ルール条件の責務）
 
 ### 例外: レポート参照
 
-`{report:filename}` を使ったレポート内容の展開は許容する。これはピース固有の概念だが、インストラクションの中核機能。
+`{report:filename}` を使ったレポート内容の展開は許容する。これはワークフロー固有の概念だが、インストラクションの中核機能。
 
 ```markdown
 # 許容
@@ -301,4 +301,4 @@ InstructionBuilder が `instruction` 内の `{変数名}` を展開する。イ
 - [ ] 出力契約埋め込みが```markdownで囲まれているか
 - [ ] 必須出力の見出しが `##` で指定されているか
 - [ ] ファイルパスがハードコードされていないか（`{report:filename}` を使う）
-- [ ] そのムーブメントの手順に集中しているか（ルーティング指示なし）
+- [ ] そのステップの手順に集中しているか（ルーティング指示なし）

package/builtins/ja/KNOWLEDGE_STYLE_GUIDE.md

@@ -30,7 +30,7 @@
 ```
 User Message (Phase 1):
   [実行コンテキスト]
-  [Piece Context]
+  [Workflow Context]
   [User Request]
   [Previous Response]
   [Instructions]
@@ -197,7 +197,7 @@ const ChildGood = ({ value, onChange }) => {
 
 1. **横断的な行動規範**: DRY、Fail Fast 等の全エージェント共通ルール → ポリシー
 2. **実行手順**: どのファイルを読め、何を実行しろ等 → インストラクション
-3. **ピース固有の概念**: ムーブメント名、レポートファイル名
+3. **workflow固有の概念**: step名、レポートファイル名
 4. **ツール固有のパス**: `.takt/runs/` 等の具体的なディレクトリパス
 
 ### 例外: ドメイン固有の評価基準

package/builtins/ja/OUTPUT_CONTRACT_STYLE_GUIDE.md

@@ -19,14 +19,14 @@
 
 ## 出力契約とは
 
-エージェントが出力するレポートの構造定義。ピースYAMLの `report.format` フィールドで使用する。
+エージェントが出力するレポートの構造定義。workflow YAML の `report.format` フィールドで使用する。
 
 | 項目 | 内容 |
 |------|------|
-| 目的 | エージェント出力の構造を統一し、後続ムーブメントで機械的に参照可能にする |
+| 目的 | エージェント出力の構造を統一し、後続 step で機械的に参照可能にする |
 | 配置 | Phase 2 メッセージの `## Instructions` 内（`{{outputContract}}`） |
 | 対象 | 1つのレポートファイル |
-| 判断基準 | 「この出力は後続ムーブメントが `{report:filename}` で参照するか？」→ YES |
+| 判断基準 | 「この出力は後続 step が `{report:filename}` で参照するか？」→ YES |
 
 ### 実際の配置先
 
@@ -35,7 +35,7 @@
 ```
 ## 実行コンテキスト（作業ディレクトリ）
 ## 実行ルール（ソース変更禁止、レポートのみ）
-## Piece Context
+## Workflow Context
 ## Instructions
   "レポートとして回答してください。ツールは使えません。"
   {{outputContract}}  ← ★ 出力契約がここに展開される
@@ -49,7 +49,7 @@ Phase 2 はツール使用不可。エージェントは Phase 1 のセッショ
 |--|-------------------|-------------------|
 | 目的 | 何をすべきかの手順 | 出力の構造定義 |
 | 配置 | Phase 1 `{{instructions}}` | Phase 2 `{{outputContract}}` |
-| 読者 | エージェント（実行時） | 後続ムーブメントのエージェント（参照時） |
+| 読者 | エージェント（実行時） | 後続 step のエージェント（参照時） |
 | 形式 | 自由文 + 箇条書き | ```markdown コードブロック |
 
 ---
@@ -150,7 +150,7 @@ Phase 2 はツール使用不可。エージェントは Phase 1 のセッショ
 - REJECT → 問題点を表形式で（30行以内）
 ```
 
-目的: 問題がない場合に冗長な出力を抑制する。後続ムーブメントの入力コストを下げる。
+目的: 問題がない場合に冗長な出力を抑制する。後続 step の入力コストを下げる。
 
 ---
 
@@ -171,7 +171,7 @@ Phase 2 はツール使用不可。エージェントは Phase 1 のセッショ
 
 1. **実行手順**: 「まず〜を確認し」等の手順はインストラクションの責務
 2. **判断基準の詳細**: 「何をもって REJECT とするか」はペルソナまたはインストラクションの責務
-3. **ピース固有のルーティング**: 「REJECT の場合は fix ムーブメントへ」等
+3. **workflow 固有のルーティング**: 「REJECT の場合は fix step へ」等
 
 ---
 
@@ -226,7 +226,7 @@ Phase 2 はツール使用不可。エージェントは Phase 1 のセッショ
 
 - 結果ステータス: 固定値「完了」
 - セクション構造: タスク → 結果 → 変更内容テーブル → 検証証跡
-- ピースの最終出力として使用
+- workflow の最終出力として使用
 
 ---
 
@@ -246,7 +246,7 @@ Phase 2 はツール使用不可。エージェントは Phase 1 のセッショ
 - 英語小文字のみ
 - 番号プレフィックスを付けない（`01-plan.md` ではなく `plan.md`）
 
-番号プレフィックスはピース構造に依存するため、共有ファイルでは使用しない。番号はピースYAMLの `report.name` フィールドで付ける。
+番号プレフィックスは workflow 構造に依存するため、共有ファイルでは使用しない。番号は workflow YAML の `report.name` フィールドで付ける。
 
 ### ファイルサイズ
 

package/builtins/ja/PERSONA_STYLE_GUIDE.md

@@ -31,8 +31,8 @@
 
 ```
 # TAKT
-  ## TAKTの仕組み（ピース、ムーブメントの説明）
-  ## 現在のコンテキスト（ピース名、ムーブメント名、処理フロー）
+  ## TAKTの仕組み（ワークフロー、ステップの説明）
+  ## 現在のコンテキスト（ワークフロー名、ステップ名、処理フロー）
 ---
 # {エージェント名}     ← ★ ペルソナがここに展開される
   ## 役割の境界
@@ -40,7 +40,7 @@
   ## ドメイン知識
 ```
 
-`# TAKT` と `# {エージェント名}` が同じ見出しレベルで並ぶ。`---` が境界。ペルソナの前に TAKT コンテキスト（ピース名、ムーブメント名、処理フロー全体）が既に提供されているため、ペルソナにこれらを再記述する必要はない。
+`# TAKT` と `# {エージェント名}` が同じ見出しレベルで並ぶ。`---` が境界。ペルソナの前に TAKT コンテキスト（ワークフロー名、ステップ名、処理フロー全体）が既に提供されているため、ペルソナにこれらを再記述する必要はない。
 
 ### ポリシーとの分離
 
@@ -48,7 +48,7 @@
 このルール/知識は…
 ├── 特定のエージェントだけが必要 → ペルソナ（ドメイン知識）
 ├── 複数のエージェントが共有 → ポリシー
-└── 特定のピースの実行手順 → instruction（ペルソナに書かない）
+└── 特定のワークフローの実行手順 → instruction（ペルソナに書かない）
 ```
 
 ---
@@ -99,7 +99,7 @@
 ### 役割の境界（必須）
 
 - 「やること」「やらないこと」を箇条書きで列挙
-- 他エージェント名やムーブメント名に依存せず、そのペルソナ単体で責務境界が読めるようにする
+- 他エージェント名やステップ名に依存せず、そのペルソナ単体で責務境界が読めるようにする
 - 他のエージェントの責務を侵食しないことを明示
 
 ```markdown
@@ -147,7 +147,7 @@
 | DO | DON'T |
 |----|-------|
 | ロール定義は1-2文で簡潔に | 長い自己紹介を書く |
-| 他エージェント名を書かずに責務境界を明確にする | 他エージェントやムーブメントへの依存を書く |
+| 他エージェント名を書かずに責務境界を明確にする | 他エージェントやステップへの依存を書く |
 | ドメイン知識はテーブルとコード例で具体的に | 抽象的な原則だけ並べる |
 | そのエージェント固有の知識のみ記載 | ポリシーの詳細ルール（コード例・テーブル）を転記 |
 | 行動姿勢に1行の行動指針としてポリシーと同じ概念を記載 | 汎用的なコーディングルールの詳細を混ぜる |
@@ -157,8 +157,8 @@
 ## ペルソナに書いてはいけないもの
 
 1. **ポリシーの詳細ルール**: コード例・判定基準・例外リスト等の詳細はポリシーの責務（1行の行動指針は行動姿勢に記載してよい）
-2. **他エージェント・他ムーブメントへの依存**: エージェント名、ムーブメント名、担当の受け渡し、連携前提の説明
-3. **ピース固有の概念**: ムーブメント名、レポートファイル名、ステップ間ルーティング
+2. **他エージェント・他ステップへの依存**: エージェント名、ステップ名、担当の受け渡し、連携前提の説明
+3. **ワークフロー固有の概念**: ステップ名、レポートファイル名、ステップ間ルーティング
 4. **ツール固有の環境情報**: `.takt/runs/` 等のディレクトリパス、テンプレート変数（`{report_dir}` 等）
 5. **実行手順**: 「まず〜を読み、次に〜を実行」のような手順は instruction の責務
 
@@ -222,9 +222,9 @@
 
 - [ ] ロール定義が1-2文で書かれているか
 - [ ] 「やること」「やらないこと」が明確に分かれているか
-- [ ] 他エージェント名やムーブメント名に依存せず、責務境界が読めるか
+- [ ] 他エージェント名やステップ名に依存せず、責務境界が読めるか
 - [ ] 行動姿勢がポリシーの詳細ルール（コード例・テーブル・例外リスト）を転記していないか（1行の行動指針はOK）
 - [ ] ドメイン知識がそのエージェント固有のものか
-- [ ] ピース固有の概念（ムーブメント名、レポートファイル名等）が含まれていないか
+- [ ] ワークフロー固有の概念（ステップ名、レポートファイル名等）が含まれていないか
 - [ ] ツール固有のパス（`.takt/` 等）が含まれていないか
 - [ ] `####` 以下のネストがないか

package/builtins/ja/POLICY_STYLE_GUIDE.md

@@ -29,7 +29,7 @@
 このルール/知識は…
 ├── 特定のエージェントだけが必要 → ペルソナ（ドメイン知識）
 ├── 複数のエージェントが共有 → ポリシー
-└── 特定のピースの実行手順 → instruction（ポリシーに書かない）
+└── 特定のワークフローの実行手順 → instruction（ポリシーに書かない）
 ```
 
 ---
@@ -99,7 +99,7 @@
 ## ポリシーに書いてはいけないもの
 
 1. **特定エージェント固有の知識**: Architecture Reviewer だけが使う検出手法等
-2. **ピース固有の概念**: ムーブメント名、レポートファイル名
+2. **ワークフロー固有の概念**: ステップ名、レポートファイル名
 3. **ツール固有のパス**: `.takt/runs/` 等の具体的なディレクトリパス
 4. **実行手順**: どのファイルを読め、何を実行しろ等
 
@@ -164,6 +164,6 @@ const good = ...
 - [ ] 原則テーブルがあるか
 - [ ] 複数のエージェントに適用可能な内容か
 - [ ] 特定エージェント固有の知識が混入していないか
-- [ ] ピース固有の概念が含まれていないか
+- [ ] ワークフロー固有の概念が含まれていないか
 - [ ] ツール固有のパスが含まれていないか
 - [ ] `####` 以下のネストがないか

package/builtins/ja/STYLE_GUIDE.md

@@ -32,10 +32,10 @@ System Prompt:
 
 User Message (Phase 1):
   [実行コンテキスト]
-  [Piece Context]
+  [Workflow Context]
   [User Request]
   [Previous Response]
-  [Instructions]          ← ムーブメント固有の手順
+  [Instructions]          ← step 固有の手順
     └── [ポリシー]        ← 共有行動規範（instruction 内に含まれる）
 ```
 
@@ -46,6 +46,6 @@ User Message (Phase 1):
 ├── 特定のエージェントだけが必要 → ペルソナ
 ├── 「〜すべき」行動規範 → ポリシー
 ├── 「〜はこう動く」「〜はこういう設計にすべき」ドメイン知識 → ナレッジ
-├── ムーブメント固有の手順 → インストラクション
+├── step 固有の手順 → インストラクション
 └── エージェント出力の構造定義 → 出力契約
 ```

package/builtins/ja/config.yaml

@@ -52,7 +52,7 @@ language: ja         # 表示言語: ja | en
 #   retention_days: 30             # イベントファイルの保持期間（日）
 
 # インタラクティブモード
-# interactive_preview_movements: 3 # インタラクティブモードでのムーブメントプレビュー数 (0-10)
+# interactive_preview_steps: 3 # インタラクティブモードでの step プレビュー数 (0-10)
 
 # ペルソナ別プロバイダー・モデル指定
 # persona_providers:
@@ -63,7 +63,7 @@ language: ja         # 表示言語: ja | en
 #     provider: codex
 #     model: gpt-5.2-codex
 
-# プロバイダー固有オプション（最低優先度、ピース/ムーブメントで上書き可能）
+# プロバイダー固有オプション（最低優先度、workflow/step で上書き可能）
 # provider_options:
 #   codex:
 #     network_access: true
@@ -119,5 +119,5 @@ language: ja         # 表示言語: ja | en
 # ワークフロー一覧/カテゴリ
 # enable_builtin_workflows: true                          # builtins/{lang}/workflows を有効化
 # disabled_builtins:
-#   - magi                                                # 無効化するビルトインピース名
+#   - magi                                                # 無効化するビルトイン workflow 名
 # workflow_categories_file: ~/.takt/preferences/workflow-categories.yaml  # カテゴリ定義ファイル

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

@@ -1,4 +1,4 @@
-**これは {movement_iteration} 回目の AI Review です。**
+**これは {step_iteration} 回目の AI Review です。**
 Report Directory内のレポートを一次情報として参照してください。不足情報の補完が必要な場合に限り、Previous Responseや会話履歴を補助的に参照して構いません（Previous Responseは提供されない場合があります）。情報が競合する場合は、Report Directory内のレポートと実際のファイル内容を優先してください。
 
 2回目以降は、前回の修正が実際には行われていなかったということです。

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

@@ -1,4 +1,4 @@
-**これは {movement_iteration} 回目のAI Reviewです。**
+**これは {step_iteration} 回目のAI Reviewです。**
 
 初回は網羅的にレビューし、指摘すべき問題をすべて出し切ってください。
 2回目以降は、前回REJECTした項目が修正されたかの確認を優先してください。

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

@@ -5,9 +5,14 @@
 - 監査レポート: {report:02-architecture-audit.md}
 
 **やること:**
-1. 指摘された module、boundary、call chain を全文読む
-2. 構造上の主張を再確認し、前回どこを飛ばしたか、どこが証拠不足だったかを明確にする
-3. 具体的なファイル根拠、明示的なスコープ充足状況、必要なら漏れ理由を付けて監査結果を更新する
+1. 監査レポートと計画レポートを突き合わせ、未監査の module や不足している boundary を特定する
+2. 未監査・指摘対象の module、boundary、call chain を全文読む
+3. 具体的なファイル根拠、明示的なスコープ充足状況、必要なら漏れ理由を付けて監査結果を記録する
+
+**出力の原則:**
+- 前回の監査レポートの既存 Findings・Audit Scope を保持し、新たな結果を統合した完全版を出力する
+- 新たに監査したモジュールを Audit Scope テーブルに追加する
+- 未監査モジュールが残る場合は Follow-up Notes にその理由を明記する
 
 **厳禁:**
 - production code を変更すること

package/builtins/ja/facets/instructions/architecture-audit-team-leader.md

@@ -4,9 +4,11 @@
 
 **やること:**
 1. 計画レポートのモジュール棚卸しと高リスク領域を確認する
-2. モジュールまたは責務境界ごとに 3 グループへ分割する
+2. 計画レポートの全対象モジュール・サブプロジェクトを漏れなく 3 グループへ分割する
 3. 各パートに排他的な担当範囲を割り当て、すべての対象モジュールが一度ずつ監査されるようにする
 
+**重要:** 計画レポートに列挙されたすべてのモジュール・サブプロジェクトがいずれかのパートに割り当てられていることを確認してください。未割り当てがあってはなりません。
+
 **各パートの instruction に必ず含めること:**
 - 担当モジュールとファイル一覧
 - 確認すべき責務境界と呼び出しチェーン

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

@@ -5,18 +5,18 @@
 - 監査が不十分と指摘されたファイルの一覧
 - 具体的な指摘内容
 
+**重要:** 監査レポートを参照してください: {report:02-audit-security.md}
+
 **やること:**
 1. 指摘された全ファイルを **Read tool で1つずつ全文を読む**
 2. 各ファイルについてセキュリティ観点でレビューする
 3. 発見した問題を重大度付きで報告する
 
+**出力の原則:**
+- 前回の監査レポートの既存結果を保持し、新たな結果を統合した完全版を出力する
+- 新たに監査したファイルを監査結果に追加する
+
 **絶対禁止事項:**
 - Grep でキーワード検索してヒットしたファイルだけ見る → 禁止
 - ファイルの一部だけ読んで判断する → 禁止
 - 「問題なさそう」で読み飛ばす → 禁止
-
-**必須出力（見出しを含める）:**
-## 再監査結果
-- {各ファイルごとの監査結果}
-## 検出された問題
-- {問題の詳細（重大度、場所、修正案）}

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

@@ -5,10 +5,17 @@
 - 根拠不足のカバレッジ主張
 - Issue 品質やスコープに関する具体的フィードバック
 
+**重要:** 監査レポートを参照してください: {report:02-e2e-audit.md}
+
 **やること:**
 1. 指摘されたルート関連コードと対応 E2E テストをすべて読む
 2. 指摘されたシナリオのカバレッジ主張を再確認し、前回どこを飛ばしたか、どこが根拠不足だったかを明確にする
-3. 具体的な根拠、明示的なスコープ充足状況、必要なら漏れ理由を付けて、Issue 化できる形式に監査結果を更新する
+3. 具体的な根拠、明示的なスコープ充足状況、必要なら漏れ理由を付けて監査結果を記録する
+
+**出力の原則:**
+- 前回の監査レポートの既存結果を保持し、新たな結果を統合した完全版を出力する
+- 新たに監査したフローを監査結果に追加する
+- 未監査フローが残る場合はその理由を明記する
 
 **禁止事項:**
 - E2E テストや本番コードを変更すること

package/builtins/ja/facets/instructions/implement-after-tests.md

@@ -1,5 +1,5 @@
 計画に従って、テストがパスするように実装してください。
-Piece Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
+Workflow Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
 Report Directory内のレポートを一次情報として参照してください。不足情報の補完が必要な場合に限り、Previous Responseや会話履歴を補助的に参照して構いません（Previous Responseは提供されない場合があります）。情報が競合する場合は、Report Directory内のレポートと実際のファイル内容を優先してください。
 
 **重要**: テストは既に作成済みです。既存テストがパスするように実装してください。

package/builtins/ja/facets/instructions/implement-terraform.md

@@ -1,5 +1,5 @@
 計画に従って Terraform コードを実装してください。
-Piece Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
+Workflow Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
 
 **重要**: 実装完了後、以下の検証を順番に実行してください。
 1. `terraform fmt -check` — フォーマット違反があれば `terraform fmt` で修正

package/builtins/ja/facets/instructions/implement-test.md

@@ -1,5 +1,5 @@
 テスト計画に従って単体テストを実装してください。
-Piece Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
+Workflow Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
 
 **重要: プロダクションコードは変更しないでください。テストファイルのみ編集可能です。**
 

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

@@ -1,5 +1,5 @@
 計画に従って実装してください。
-Piece Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
+Workflow Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。
 Report Directory内のレポートを一次情報として参照してください。不足情報の補完が必要な場合に限り、Previous Responseや会話履歴を補助的に参照して構いません（Previous Responseは提供されない場合があります）。情報が競合する場合は、Report Directory内のレポートと実際のファイル内容を優先してください。
 
 **重要**: 実装と同時に単体テストを追加してください。

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

@@ -1,5 +1,5 @@
 **アーキテクチャと設計**のレビューに集中してください。
-AI特有の問題はレビューしないでください（ai_reviewムーブメントで実施済み）。
+AI特有の問題はレビューしないでください（ai_reviewステップで実施済み）。
 
 **レビュー観点:**
 - 構造・設計の妥当性
@@ -19,18 +19,21 @@ AI特有の問題はレビューしないでください（ai_reviewムーブメ
 - ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
 
 **前回指摘の追跡（必須）:**
-- まず「Previous Response」から前回の open findings を抽出する
-- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved` で判定する
+- まず Report Directory 内で、このステップが前回までに出力したレビュー結果とそのタイムスタンプ付き履歴を確認し、無印ファイルを最新結果、直前のタイムスタンプ付きファイルを前回結果として扱う
+- `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
+- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved / reopened` で判定する
 - `persists` と判定する場合は、未解決である根拠（ファイル/行）を必ず示す
+- 前回レポートにある open findings を、今回のレポートへ欠落させない
 
 ## 判定手順
 
-1. まず前回open findingsを抽出し、`new / persists / resolved` を仮判定する
+1. まず前回open findingsを抽出し、`new / persists / resolved / reopened` を仮判定する
 2. 変更差分を確認し、構造・設計の観点に基づいて問題を検出する
    - ナレッジの判定基準テーブル（REJECT条件）と変更内容を照合する
    - DRY違反を見つけた場合は解消を要求する
    - ただし修正案を出す前に、共通化先が既存の責務境界・契約・公開APIに整合するか確認する
    - 新しい wrapper / helper / 公開API を求める場合は、その抽象化先が自然である根拠を示す
    - 指示書や plan にない追加抽象化を要求する場合は、必要性とスコープ妥当性を明示する
+   - ビルド・テスト・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
 3. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-4. ブロッキング問題（`new` または `persists`）が1件でもあればREJECTと判定する
+4. ブロッキング問題（`new`、`persists`、または `reopened`）が1件でもあればREJECTと判定する

package/builtins/ja/facets/instructions/review-cqrs-es.md

@@ -1,5 +1,5 @@
 CQRS（コマンドクエリ責務分離）とEvent Sourcing（イベントソーシング）の観点から
-変更をレビューしてください。AI特有の問題のレビューは不要です（ai_reviewムーブメントで実施済み）。
+変更をレビューしてください。AI特有の問題のレビューは不要です（ai_reviewステップで実施済み）。
 
 **レビュー観点:**
 - Aggregate設計の妥当性

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

@@ -14,16 +14,19 @@
 - ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
 
 **前回指摘の追跡（必須）:**
-- まず「Previous Response」から前回の open findings を抽出する
-- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved` で判定する
+- まず Report Directory 内で、このステップが前回までに出力したレビュー結果とそのタイムスタンプ付き履歴を確認し、無印ファイルを最新結果、直前のタイムスタンプ付きファイルを前回結果として扱う
+- `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
+- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved / reopened` で判定する
 - `persists` と判定する場合は、未解決である根拠（ファイル/行）を必ず示す
+- 前回レポートにある open findings を、今回のレポートへ欠落させない
 
 ## 判定手順
 
-1. まず前回open findingsを抽出し、`new / persists / resolved` を仮判定する
+1. まず前回open findingsを抽出し、`new / persists / resolved / reopened` を仮判定する
 2. 変更差分を確認し、品質保証の観点に基づいて問題を検出する
    - ナレッジの判定基準テーブル（REJECT条件）と変更内容を照合する
    - テストが通っていても、task や plan にない追加変更が妥当か確認する
    - レビュー起因で設計変更が膨らんでいる場合、その追加変更が本当に必要かを評価する
+   - ビルド・テスト・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
 3. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-4. ブロッキング問題（`new` または `persists`）が1件でもあればREJECTと判定する
+4. ブロッキング問題（`new`、`persists`、または `reopened`）が1件でもあればREJECTと判定する

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

@@ -13,9 +13,11 @@
 - ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
 
 **前回指摘の追跡（必須）:**
-- まず「Previous Response」から前回の open findings を抽出する
+- まず Report Directory 内で、このステップが前回までに出力したレビュー結果とそのタイムスタンプ付き履歴を確認し、無印ファイルを最新結果、直前のタイムスタンプ付きファイルを前回結果として扱う
+- `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
 - 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved / reopened` で判定する
 - `persists` と判定する場合は、未解決である根拠（ファイル/行）を必ず示す
+- 前回レポートにある open findings を、今回のレポートへ欠落させない
 
 ## 判定手順
 
@@ -28,5 +30,6 @@
    - 一部ケースしか確認できていない場合は `充足` にしない
 5. 要求にない変更を列挙し、妥当か不要かを判定する
 6. 前回 finding を `new / persists / resolved / reopened` で整理する
-7. 検出した問題ごとに、Policy のスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-8. ブロッキング問題（`new`、`persists`、または `reopened`）が1件でもあれば REJECT と判定する
+7. テスト・ビルド・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
+8. 検出した問題ごとに、Policy のスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
+9. ブロッキング問題（`new`、`persists`、または `reopened`）が1件でもあれば REJECT と判定する