takt 0.40.0 → 0.41.0

package/builtins/en/facets/policies/review.md

@@ -203,6 +203,36 @@ Do not tolerate problems just because existing code does the same. If existing c
 - "The code itself existed before" is not a valid reason for non-blocking. As long as it is in a changed file, the Boy Scout rule applies
 - If even one issue exists, REJECT. "APPROVE with warnings" or "APPROVE with suggestions" is prohibited
 
+## Basic Review Procedure
+
+Common procedure that every reviewer must follow. Do not duplicate this in individual instructions.
+
+### Referring to Primary Sources
+
+- Use `order.md`, `plan.md`, and the actual code as primary sources
+- Treat decisions from earlier steps (prior review results, planning decisions) as supplementary
+- When information conflicts, prioritize `order.md` / `plan.md` / actual code
+
+### Referring to Design Decisions
+
+- If the implementation step has emitted `coder-decisions.md`, read it and understand the recorded design decisions
+- Do not dismiss intentional decisions as false positives just because they were recorded. Evaluate validity against `order.md` / `plan.md` / actual code
+- If the design decision itself is flawed, raise it
+
+### Tracking Findings from Previous Reviews
+
+- Look in the Report Directory for review reports this step has previously produced, along with their timestamped history
+- Treat the unsuffixed file as the latest result and the most recent `{report-name}.{timestamp}` as the previous result
+- `Previous Response` may be used as supplementary information, but finding state determinations must prioritize the report history
+- Do not drop open findings from the previous report when producing the new report
+- Apply the `finding_id` management rules when classifying each finding as `new` / `persists` / `resolved` / `reopened`
+
+### Final Decision Steps
+
+1. Classify each detected issue as blocking / non-blocking according to the scope rules and decision rules above
+2. When citing test, build, or behavior verification as evidence, record the target, the check, and the result in the report
+3. REJECT if there is at least one blocking issue (`new`, `persists`, or `reopened`)
+
 ## Detecting Circular Arguments
 
 When the same kind of issue keeps recurring, reconsider the approach itself rather than repeating the same fix instructions.

package/builtins/en/workflows/auto-improvement-loop.yaml

@@ -85,10 +85,17 @@ steps:
       Treat the current issue itself as in-scope, not as a duplicate.
       Avoid tasks that materially duplicate or overlap with an open PR or the other open issues listed above.
 
-      Do not implement anything. Output only the next task instruction in task_markdown.
+      Do not implement anything. Output only the next task metadata as structured output.
       Output the next action in action.
-      Always output task_markdown and issue.
-      For wait_before_next_scan, set task_markdown to an empty string and issue to { create: false, labels: [] }.
+      Always output title, type, scope, summary, goals, acceptance_criteria, and issue.
+      Output labels only when needed.
+      In title, output a concise GitHub Issue title.
+      Do not use generic headings such as "# Task Order" or "Task Order" in title.
+      Set type to one of feature / bug / chore / docs.
+      TAKT renders summary, goals, and acceptance_criteria into this Markdown template:
+      ## Summary / ## Goals / ## Acceptance Criteria
+      For enqueue_new_task, set at least one goal and at least two acceptance criteria.
+      For wait_before_next_scan, set title, scope, and summary to empty strings, type to "chore", goals and acceptance_criteria to empty arrays, labels to an empty array, and issue to { create: false }.
       For an existing issue task, set issue.create to false unless a new GitHub Issue is explicitly needed.
 
       Allowed action values:
@@ -148,10 +155,17 @@ steps:
       Avoid tasks that materially duplicate or overlap with an open PR or tracked open issue.
       If you cannot identify a clearly distinct, high-value task, choose wait_before_next_scan.
 
-      Do not implement anything. Output only the next task instruction in task_markdown.
+      Do not implement anything. Output only the next task metadata as structured output.
       Output the next action in action.
-      Always output task_markdown and issue.
-      For wait_before_next_scan, set task_markdown to an empty string and issue to { create: false, labels: [] }.
+      Always output title, type, scope, summary, goals, acceptance_criteria, and issue.
+      Output labels only when needed.
+      In title, output a concise GitHub Issue title.
+      Do not use generic headings such as "# Task Order" or "Task Order" in title.
+      Set type to one of feature / bug / chore / docs.
+      TAKT renders summary, goals, and acceptance_criteria into this Markdown template:
+      ## Summary / ## Goals / ## Acceptance Criteria
+      For enqueue_new_task, set at least one goal and at least two acceptance criteria.
+      For wait_before_next_scan, set title, scope, and summary to empty strings, type to "chore", goals and acceptance_criteria to empty arrays, labels to an empty array, and issue to { create: false }.
       For a fresh improvement task, set issue.create to true so the task is backed by a GitHub Issue.
 
       Allowed action values:

package/builtins/ja/INSTRUCTION_STYLE_GUIDE.md

@@ -206,9 +206,44 @@ InstructionBuilder が `instruction` 内の `{変数名}` を展開する。イ
 
 1. **ペルソナの内容**: エージェントの専門知識、検出手法、行動姿勢
 2. **ポリシーの内容**: DRY、Fail Fast 等の共有コーディング原則
-3. **自動注入される内容**: `{task}`, `{previous_response}` のプレースホルダーを明示的に書かない（エンジンが自動付加する）
-4. **他のステップ名の直接参照**: 「implement ステップに戻る」等（ルーティングはルール定義の責務）
-5. **ワークフロー固有のルーティング**: 「APPROVE なら次へ」等（ルール条件の責務）
+3. **ナレッジの判定基準・パターン**: 観点リスト、判定基準テーブル、コード例
+4. **自動注入される内容**: `{task}`, `{previous_response}` のプレースホルダーを明示的に書かない（エンジンが自動付加する）
+5. **他のステップ名の直接参照**: 「implement ステップに戻る」等（ルーティングはルール定義の責務）
+6. **ワークフロー固有のルーティング**: 「APPROVE なら次へ」等（ルール条件の責務）
+
+### レビュー系インストラクションでの観点列挙の禁止
+
+レビュー系（review-*, ai-antipattern-review, audit-*-review）の instruction で「**レビュー観点:**」「**チェック項目:**」のような観点リストを列挙してはならない。
+
+理由:
+- 観点・判定基準は対応する Knowledge / Policy に既に揃っている
+- instruction に観点を抜粋すると、policy / knowledge に章を追加しても instruction に反映されず drift する
+- AI が観点リストを「許可リスト」として扱い、Knowledge / Policy 全章の他観点を見落とす
+
+正しい書き方:
+
+```markdown
+# 良い例（フォーカス領域を 1 行で示し、判定基準は policy / knowledge に丸投げ）
+**アーキテクチャと設計**のレビューに集中してください。
+Knowledge と Policy の判定基準・検出パターン全章にしたがって変更差分をレビューしてください。
+Knowledge / Policy はトリミングされる場合があります。Source Path から元ファイルの全章を確認した上で照合してください。
+```
+
+```markdown
+# 悪い例（観点を列挙して許可リスト化）
+**レビュー観点:**
+- 構造・設計の妥当性
+- モジュール化（高凝集・低結合・循環依存）
+- コード品質
+- デッドコード
+- ...
+```
+
+並列レビューで複数の reviewer を差別化するための「フォーカス領域」は 1 行のヒントに留める。詳細な観点・基準は Knowledge / Policy に置く。
+
+### 共通手順の重複禁止
+
+複数の instruction に同一の手順ブロック（「前回指摘の追跡」「設計判断の参照」など）が転記されている場合は、共有 policy か共通ペルソナの「やること」へ集約する。同じ文言を 2 箇所以上に書かない。
 
 ### 例外: レポート参照
 

package/builtins/ja/config.yaml

@@ -74,6 +74,8 @@ language: ja         # 表示言語: ja | en
 # provider_options:
 #   codex:
 #     network_access: true
+#   opencode:
+#     variant: high
 #   claude:
 #     sandbox:
 #       allow_unsandboxed_commands: true

package/builtins/ja/facets/instructions/_system/fallback-notice.md

@@ -0,0 +1,16 @@
+## 注意: このステップは fallback 実行です
+
+直前のステップ実行は外部要因（{{fallback_reason}}）で中断され、新しいセッションで再実行されています。
+前回のセッションのコンテキストは本セッションには引き継がれていません。
+
+- 中断されたステップ: {{step_name}}
+- 中断時の iteration: {{original_iteration}}
+- 中断理由: {{fallback_reason_detail}}
+- 切替前 provider/model: {{previous_provider}} / {{previous_model}}
+- 現在の provider/model: {{current_provider}} / {{current_model}}
+
+ファイルや成果物としてディスクに残っている前回の作業成果は参照可能ですが、チャット上の文脈は失われています。必要に応じて次の手順で文脈を補ってください。
+
+1. {{report_dir}} 配下の既存レポートを確認します
+2. 直前のコミットや作業ブランチの差分を確認します
+3. それでも文脈が不足する場合は、ステップ instruction に基づいて最初から実行します

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

@@ -1,16 +1,9 @@
 **これは {step_iteration} 回目の AI Review です。**
-Report Directory内のレポートを一次情報として参照してください。不足情報の補完が必要な場合に限り、Previous Responseや会話履歴を補助的に参照して構いません（Previous Responseは提供されない場合があります）。情報が競合する場合は、Report Directory内のレポートと実際のファイル内容を優先してください。
 
-2回目以降は、前回の修正が実際には行われていなかったということです。
-**あなたの「修正済み」という認識が間違っています。**
-
-**まず認めること:**
-- 「修正済み」と思っていたファイルは実際には修正されていない
-- 前回の作業内容の認識が間違っている
-- ゼロベースで考え直す必要がある
+Report Directory 内のレポートを一次情報として参照してください。不足情報の補完が必要な場合に限り、Previous Response や会話履歴を補助的に参照して構いません（Previous Response は提供されない場合があります）。情報が競合する場合は、Report Directory 内のレポートと実際のファイル内容を優先してください。
 
 **必須アクション:**
-1. 指摘された全ファイルを Read tool で開く（思い込みを捨てて事実確認）
+1. 指摘された全ファイルを Read tool で開く
 2. 問題箇所を grep で検索して実在を確認する
 3. 確認した問題を Edit tool で修正する
 4. テストを実行して検証する
@@ -18,15 +11,10 @@ Report Directory内のレポートを一次情報として参照してくださ
 
 **報告フォーマット:**
 - NG: 「既に修正されています」
-- OK: 「ファイルXのL123を確認した結果、問題Yが存在したため、Zに修正しました」
-
-**絶対に禁止:**
-- ファイルを開かずに「修正済み」と報告
-- 思い込みで判断
-- AI Reviewer が REJECT した問題の放置
+- OK: 「ファイル X の L123 を確認した結果、問題 Y が存在したため、Z に修正しました」
 
 **修正不要の扱い（必須）**
-- AI Reviewの指摘ごとに「対象ファイルの確認結果」を示せない場合は修正不要と判断しない
+- AI Review の指摘ごとに「対象ファイルの確認結果」を示せない場合は修正不要と判断しない
 - 指摘が「生成物」「仕様同期」に関係する場合は、生成元/仕様の確認ができなければ「判断できない」に対応するタグを出力する
 - 修正不要の場合は「判断できない」に対応するタグを出力し、理由と確認範囲を明記する
 

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

@@ -1,17 +1,11 @@
-**これは {step_iteration} 回目のAI Reviewです。**
+**これは {step_iteration} 回目の AI Review です。**
 
 初回は網羅的にレビューし、指摘すべき問題をすべて出し切ってください。
-2回目以降は、前回REJECTした項目が修正されたかの確認を優先してください。
+2回目以降は、前回 REJECT した項目が修正されたかの確認を優先してください。
 
-AI特有の問題についてコードをレビューしてください:
-- 仮定の検証
-- もっともらしいが間違っているパターン
-- 既存コードベースとの適合性
-- スコープクリープの検出
-- スコープ縮小の検出（タスク要件の取りこぼし）
+AI 特有の問題のレビューを行ってください。
 
-## 判定手順
-
-1. 変更差分を確認し、AI特有の問題の観点に基づいて問題を検出する
-2. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-3. ブロッキング問題が1件でもあればREJECTと判定する
+手順:
+1. Knowledge と Policy の Source Path を Read ツールで開き、全文を取得する
+2. それぞれの `##` セクションをすべて列挙する（取捨選択しない）
+3. 列挙した各セクションの判定基準を変更差分と照合し、該当する問題を検出する

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

@@ -42,13 +42,12 @@ Small / Medium / Large
 ```
 
 **実装完了前の自己チェック（必須）:**
-ビルドとテストを実行する前に、以下を確認してください:
-- 新しいパラメータ/フィールドを追加した場合、grep で呼び出し元から実際に渡されているか確認した
-- `??`, `||`, `= defaultValue` を使った箇所で、フォールバックが本当に必要か確認した
-- リファクタリングで置き換えたコード・エクスポートが残っていないか確認した
-- タスク指示書にない機能を追加していないか確認した
-- if/else で同一関数を呼び出し、引数の差異のみになっていないか確認した
-- 新しいコードが既存の実装パターン（API呼び出し方式、型定義方式等）と一致しているか確認した
+
+ビルドとテストを実行する前に、次の手順で Policy の REJECT 基準を自己点検してください。
+
+1. Policy の Source Path を Read ツールで開き、全文を取得する
+2. 各 `##` セクションをすべて列挙する（取捨選択しない）
+3. 列挙した各セクションの REJECT 基準と自分の実装を照合する
 
 **必須出力（見出しを含める）**
 ## 作業結果

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

@@ -41,13 +41,12 @@ Small / Medium / Large
 ```
 
 **実装完了前の自己チェック（必須）:**
-ビルドとテストを実行する前に、以下を確認してください:
-- 新しいパラメータ/フィールドを追加した場合、grep で呼び出し元から実際に渡されているか確認した
-- `??`, `||`, `= defaultValue` を使った箇所で、フォールバックが本当に必要か確認した
-- リファクタリングで置き換えたコード・エクスポートが残っていないか確認した
-- タスク指示書にない機能を追加していないか確認した
-- if/else で同一関数を呼び出し、引数の差異のみになっていないか確認した
-- 新しいコードが既存の実装パターン（API呼び出し方式、型定義方式等）と一致しているか確認した
+
+ビルドとテストを実行する前に、次の手順で Policy の REJECT 基準を自己点検してください。
+
+1. Policy の Source Path を Read ツールで開き、全文を取得する
+2. 各 `##` セクションをすべて列挙する（取捨選択しない）
+3. 列挙した各セクションの REJECT 基準と自分の実装を照合する
 
 **必須出力（見出しを含める）**
 ## 作業結果

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

@@ -1,39 +1,7 @@
 **アーキテクチャと設計**のレビューに集中してください。
-AI特有の問題はレビューしないでください（ai-antipattern-review-1st ステップで実施済み）。
+AI 特有の問題はレビューしないでください（ai-antipattern-review-1st ステップで実施済み）。
 
-**レビュー観点:**
-- 構造・設計の妥当性
-- モジュール化（高凝集・低結合・循環依存）
-- 関数化（1関数1責務・操作の一覧性・抽象度の一致）
-- コード品質
-- 変更スコープの適切性
-- テストカバレッジ
-- デッドコード
-- 呼び出しチェーン検証
-- 契約文字列（ファイル名・設定キー名）のハードコード散在
-
-
-**設計判断の参照:**
-{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
-- 記録された意図的な判断は FP として指摘しない
-- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
-
-**前回指摘の追跡（必須）:**
-- まず Report Directory 内で、このステップが前回までに出力したレビュー結果とそのタイムスタンプ付き履歴を確認し、無印ファイルを最新結果、直前のタイムスタンプ付きファイルを前回結果として扱う
-- `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
-- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved / reopened` で判定する
-- `persists` と判定する場合は、未解決である根拠（ファイル/行）を必ず示す
-- 前回レポートにある open findings を、今回のレポートへ欠落させない
-
-## 判定手順
-
-1. まず前回open findingsを抽出し、`new / persists / resolved / reopened` を仮判定する
-2. 変更差分を確認し、構造・設計の観点に基づいて問題を検出する
-   - ナレッジの判定基準テーブル（REJECT条件）と変更内容を照合する
-   - DRY違反を見つけた場合は解消を要求する
-   - ただし修正案を出す前に、共通化先が既存の責務境界・契約・公開APIに整合するか確認する
-   - 新しい wrapper / helper / 公開API を求める場合は、その抽象化先が自然である根拠を示す
-   - 指示書や plan にない追加抽象化を要求する場合は、必要性とスコープ妥当性を明示する
-   - ビルド・テスト・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
-3. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-4. ブロッキング問題（`new`、`persists`、または `reopened`）が1件でもあればREJECTと判定する
+手順:
+1. Knowledge と Policy の Source Path を Read ツールで開き、全文を取得する
+2. それぞれの `##` セクションをすべて列挙する（取捨選択しない）
+3. 列挙した各セクションの判定基準を変更差分と照合し、該当する問題を検出する

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

@@ -1,25 +1,9 @@
-CQRS（コマンドクエリ責務分離）とEvent Sourcing（イベントソーシング）の観点から
-変更をレビューしてください。AI特有の問題のレビューは不要です（ai-antipattern-review-1st ステップで実施済み）。
+**CQRS（コマンドクエリ責務分離）と Event Sourcing（イベントソーシング）**のレビューに集中してください。
+AI 特有の問題はレビューしないでください（ai-antipattern-review-1st ステップで実施済み）。
 
-**レビュー観点:**
-- Aggregate設計の妥当性
-- イベント設計（粒度、命名、スキーマ）
-- Command/Queryの分離
-- プロジェクション設計
-- 結果整合性の考慮
+手順:
+1. Knowledge と Policy の Source Path を Read ツールで開き、全文を取得する
+2. それぞれの `##` セクションをすべて列挙する（取捨選択しない）
+3. 列挙した各セクションの判定基準を変更差分と照合し、該当する問題を検出する
 
-**注意**: このプロジェクトがCQRS+ESパターンを使用していない場合は、
-一般的なドメイン設計の観点からレビューしてください。
-
-
-**設計判断の参照:**
-{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
-- 記録された意図的な判断は FP として指摘しない
-- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
-
-## 判定手順
-
-1. 変更差分を確認し、CQRS・イベントソーシングの観点に基づいて問題を検出する
-   - ナレッジの判定基準テーブル（REJECT条件）と変更内容を照合する
-2. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-3. ブロッキング問題が1件でもあればREJECTと判定する
+**注意:** このプロジェクトが CQRS+ES パターンを使用していない場合は、一般的なドメイン設計の観点からレビューしてください。

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

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

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

@@ -1,32 +1,6 @@
-品質保証の観点から変更をレビューしてください。
+**品質保証（テスト戦略・カバレッジ・エラーハンドリング・保守性）**のレビューに集中してください。
 
-**レビュー観点:**
-- テストカバレッジと品質
-- テスト戦略（単体/統合/E2E）
-- エラーハンドリング
-- ログとモニタリング
-- 保守性
-
-
-**設計判断の参照:**
-{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
-- 記録された意図的な判断は FP として指摘しない
-- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
-
-**前回指摘の追跡（必須）:**
-- まず Report Directory 内で、このステップが前回までに出力したレビュー結果とそのタイムスタンプ付き履歴を確認し、無印ファイルを最新結果、直前のタイムスタンプ付きファイルを前回結果として扱う
-- `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
-- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved / reopened` で判定する
-- `persists` と判定する場合は、未解決である根拠（ファイル/行）を必ず示す
-- 前回レポートにある open findings を、今回のレポートへ欠落させない
-
-## 判定手順
-
-1. まず前回open findingsを抽出し、`new / persists / resolved / reopened` を仮判定する
-2. 変更差分を確認し、品質保証の観点に基づいて問題を検出する
-   - ナレッジの判定基準テーブル（REJECT条件）と変更内容を照合する
-   - テストが通っていても、task や plan にない追加変更が妥当か確認する
-   - レビュー起因で設計変更が膨らんでいる場合、その追加変更が本当に必要かを評価する
-   - ビルド・テスト・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
-3. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-4. ブロッキング問題（`new`、`persists`、または `reopened`）が1件でもあればREJECTと判定する
+手順:
+1. Knowledge と Policy の Source Path を Read ツールで開き、全文を取得する
+2. それぞれの `##` セクションをすべて列挙する（取捨選択しない）
+3. 列挙した各セクションの判定基準を変更差分と照合し、該当する問題を検出する

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

@@ -1,35 +1,17 @@
-要件充足の観点から変更をレビューしてください。
+**要件充足**のレビューに集中してください。
 
-**レビュー観点:**
-- 要求された各要件が実装されているか
-- 暗黙の要求（当然期待される動作）が満たされているか
-- 要求にない変更（スコープクリープ）が紛れていないか
-- 部分実装や未実装がないか
+手順:
+1. Knowledge と Policy の Source Path を Read ツールで開き、全文を取得する
+2. それぞれの `##` セクションをすべて列挙する（取捨選択しない）
+3. 列挙した各セクションの判定基準を変更差分と照合し、該当する問題を検出する
 
+## ステップ固有の追加手順
 
-**設計判断の参照:**
-{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
-- 記録された意図的な判断は FP として指摘しない
-- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
-
-**前回指摘の追跡（必須）:**
-- まず Report Directory 内で、このステップが前回までに出力したレビュー結果とそのタイムスタンプ付き履歴を確認し、無印ファイルを最新結果、直前のタイムスタンプ付きファイルを前回結果として扱う
-- `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
-- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved / reopened` で判定する
-- `persists` と判定する場合は、未解決である根拠（ファイル/行）を必ず示す
-- 前回レポートにある open findings を、今回のレポートへ欠落させない
-
-## 判定手順
-
-1. `order.md`、関連タスク本文、`plan.md`、`coder-decisions.md` を読み、要件を1つずつ抽出する
-2. 1つの文に複数条件や経路がある場合、検証可能な最小単位まで分解する
-   - `A/B`、`global/project`、`JSON/leaf`、`allow/deny`、`read/write` を1行にまとめない
+1. `order.md`、関連タスク本文、`plan.md`、`coder-decisions.md` を読み、要件を 1 つずつ抽出する
+2. 1 つの文に複数条件や経路がある場合、検証可能な最小単位まで分解する
+   - `A/B`、`global/project`、`JSON/leaf`、`allow/deny`、`read/write` を 1 行にまとめない
 3. 各要件について、実装されたコード（ファイル:行）を特定する
-4. 各要件を `充足 / 未充足 / 未確認` のいずれかで判定する
+4. 各要件を `充足` / `未充足` / `未確認` のいずれかで判定する
    - 根拠コードがない場合は `充足` にしない
    - 一部ケースしか確認できていない場合は `充足` にしない
 5. 要求にない変更を列挙し、妥当か不要かを判定する
-6. 前回 finding を `new / persists / resolved / reopened` で整理する
-7. テスト・ビルド・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
-8. 検出した問題ごとに、Policy のスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-9. ブロッキング問題（`new`、`persists`、または `reopened`）が1件でもあれば REJECT と判定する

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

@@ -1,39 +1,16 @@
-セキュリティの観点から変更をレビューしてください。以下の脆弱性をチェックしてください。
-- インジェクション攻撃（SQL, コマンド, XSS）
-- 認証・認可の不備
-- データ露出リスク
-- 暗号化の弱点
+**セキュリティ**のレビューに集中してください。
 
-**一次情報の参照:**
-- `order.md` を確認し、要求と禁止事項を把握してください。
-- `plan.md` を確認し、意図したスコープと設計方針を把握してください。
-- {report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
-- 記録された意図的な判断は、そのまま FP として退けず、`order.md`・`plan.md`・実コードに照らして妥当性を評価してください。
+手順:
+1. Knowledge と Policy の Source Path を Read ツールで開き、全文を取得する
+2. それぞれの `##` セクションをすべて列挙する（取捨選択しない）
+3. 列挙した各セクションの判定基準を変更差分と照合し、該当する問題を検出する
 
-**前回指摘の追跡（必須）:**
-- まず Report Directory 内で、このステップが前回までに出力したレビュー結果とそのタイムスタンプ付き履歴を確認し、無印ファイルを最新結果、直前のタイムスタンプ付きファイルを前回結果として扱う
-- `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
-- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved / reopened` で判定する
-- `persists` と判定する場合は、未解決である根拠（ファイル/行）を必ず示す
-- 前回レポートにある open findings を、今回のレポートへ欠落させない
+## ステップ固有の確認事項
 
-**重要:**
-- 仕様上の優先順位、拡張点、設定のオーバーライドを、それだけで脆弱性と断定しないでください。
-- 対話確認や警告プロンプトが消えたこと自体を、直ちにセキュリティ境界の後退とみなさないでください。
-- ブロッキング finding を出すには、攻撃者がどの入力を制御し、何を新たに達成できるのかを具体化してください。
-
-## 判定手順
-
-1. `order.md`、`plan.md`、`coder-decisions.md`、実コードを突き合わせて、変更が意図した仕様かどうかを確認する
-2. 変更差分を確認し、ナレッジの判定基準テーブル（REJECT条件）と照合して問題候補を抽出する
-3. 問題候補ごとに、具体的な攻撃経路を確認する
-   - どの主体が入力や設定を制御できるか
-   - 変更によって新しい権限、データアクセス、コード実行、プロンプト改変が可能になるか
-   - その影響が、既存の仕様上の優先順位や拡張点の範囲を超えているか
-4. 設定の優先順位、local/global の shadow、非対話指定などが関わる場合は、次を追加確認する
-   - その挙動が `order.md` や `plan.md` で意図された仕様か
-   - 明示的な selector や引数指定によりユーザー意図が十分に表現されているか
-   - 低信頼側が高信頼側を上書きできること自体ではなく、信頼境界の破壊や新しい攻撃能力があるか
-5. テスト・ビルド・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
-6. 検出した問題ごとに、Policy のスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-7. ブロッキング問題が1件でもあれば REJECT と判定する
+- 仕様上の優先順位、拡張点、設定のオーバーライドを、それだけで脆弱性と断定しない
+- 対話確認や警告プロンプトが消えたこと自体を、直ちにセキュリティ境界の後退とみなさない
+- ブロッキング finding を出すには、攻撃者がどの入力を制御し、何を新たに達成できるのかを具体化する
+- 設定の優先順位、local/global の shadow、非対話指定などが関わる場合は次を追加確認する
+  - その挙動が `order.md` や `plan.md` で意図された仕様か
+  - 明示的な selector や引数指定によりユーザー意図が十分に表現されているか
+  - 低信頼側が高信頼側を上書きできること自体ではなく、信頼境界の破壊や新しい攻撃能力があるか

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

@@ -1,31 +1,7 @@
 **Terraform 規約準拠**のレビューに集中してください。
-AI特有の問題はレビューしないでください（ai-antipattern-review-1st ステップで実施済み）。
+AI 特有の問題はレビューしないでください（ai-antipattern-review-1st ステップで実施済み）。
 
-**レビュー観点:**
-- 変数宣言の規約準拠（type, description, sensitive）
-- リソース命名の一貫性（name_prefix パターン）
-- ファイル構成の規約準拠（1ファイル1関心事）
-- セキュリティ設定（IMDSv2, 暗号化, アクセス制御, IAM最小権限）
-- タグ管理（default_tags, 重複なし）
-- lifecycle ルールの妥当性
-- コストトレードオフの文書化
-- 未使用の variable / output / data source
-
-
-**設計判断の参照:**
-{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
-- 記録された意図的な判断は FP として指摘しない
-- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
-
-**前回指摘の追跡（必須）:**
-- まず「Previous Response」から前回の open findings を抽出する
-- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved` で判定する
-- `persists` と判定する場合は、未解決である根拠（ファイル/行）を必ず示す
-
-## 判定手順
-
-1. まず前回open findingsを抽出し、`new / persists / resolved` を仮判定する
-2. 変更差分を確認し、Terraform規約の観点に基づいて問題を検出する
-   - ナレッジの判定基準テーブル（REJECT条件）と変更内容を照合する
-3. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-4. ブロッキング問題（`new` または `persists`）が1件でもあればREJECTと判定する
+手順:
+1. Knowledge と Policy の Source Path を Read ツールで開き、全文を取得する
+2. それぞれの `##` セクションをすべて列挙する（取捨選択しない）
+3. 列挙した各セクションの判定基準を変更差分と照合し、該当する問題を検出する

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

@@ -1,32 +1,11 @@
-テスト品質の観点から変更をレビューしてください。
+**テスト品質**のレビューに集中してください。
 
-**レビュー観点:**
-- テスト計画の観点がすべてカバーされているか
-- テスト品質（Given-When-Then構造、独立性、再現性）
-- テスト命名規約
-- 過不足（不要なテスト、足りないケース）
-- モック・フィクスチャの適切さ
-- 外部契約がある場合、request body / query / path の入力位置が契約どおりに検証されているか
-- レスポンス標準の envelope を request 契約へ誤って流用する実装を検出できるテストになっているか
+手順:
+1. Knowledge と Policy の Source Path を Read ツールで開き、全文を取得する
+2. それぞれの `##` セクションをすべて列挙する（取捨選択しない）
+3. 列挙した各セクションの判定基準を変更差分と照合し、該当する問題を検出する
 
+## ステップ固有の追加手順
 
-**設計判断の参照:**
-{report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
-- 記録された意図的な判断は FP として指摘しない
-- ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
-
-**前回指摘の追跡（必須）:**
-- まず Report Directory 内で、このステップが前回までに出力したレビュー結果とそのタイムスタンプ付き履歴を確認し、無印ファイルを最新結果、直前のタイムスタンプ付きファイルを前回結果として扱う
-- `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
-- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved / reopened` で判定する
-- `persists` と判定する場合は、未解決である根拠（ファイル/行）を必ず示す
-- 前回レポートにある open findings を、今回のレポートへ欠落させない
-
-## 判定手順
-
-1. まず前回 open findings をレポート履歴から抽出し、`new / persists / resolved / reopened` を仮判定する
-2. Report Directory内のテスト計画・テストスコープに関するレポートと実装されたテストを突合する
-3. テスト・ビルド・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
-4. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-5. ブロッキング問題が1件でもあればREJECTと判定する
-6. 外部契約があるのに入力位置（root body / query / path）の検証が欠けていれば、原則としてカバレッジ不足として扱う
+1. Report Directory 内のテスト計画・テストスコープに関するレポートと実装されたテストを突合する
+2. 外部契約があるのに入力位置（root body / query / path）の検証が欠けている場合、カバレッジ不足として扱う