takt 0.35.3 → 0.36.0

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

@@ -10,6 +10,13 @@
 - {report:coder-decisions.md} を確認し、記録された設計判断を把握してください。
 - 記録された意図的な判断は、そのまま FP として退けず、`order.md`・`plan.md`・実コードに照らして妥当性を評価してください。
 
+**前回指摘の追跡（必須）:**
+- まず Report Directory 内で、このステップが前回までに出力したレビュー結果とそのタイムスタンプ付き履歴を確認し、無印ファイルを最新結果、直前のタイムスタンプ付きファイルを前回結果として扱う
+- `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
+- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved / reopened` で判定する
+- `persists` と判定する場合は、未解決である根拠（ファイル/行）を必ず示す
+- 前回レポートにある open findings を、今回のレポートへ欠落させない
+
 **重要:**
 - 仕様上の優先順位、拡張点、設定のオーバーライドを、それだけで脆弱性と断定しないでください。
 - 対話確認や警告プロンプトが消えたこと自体を、直ちにセキュリティ境界の後退とみなさないでください。
@@ -27,5 +34,6 @@
    - その挙動が `order.md` や `plan.md` で意図された仕様か
    - 明示的な selector や引数指定によりユーザー意図が十分に表現されているか
    - 低信頼側が高信頼側を上書きできること自体ではなく、信頼境界の破壊や新しい攻撃能力があるか
-5. 検出した問題ごとに、Policy のスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-6. ブロッキング問題が1件でもあれば REJECT と判定する
+5. テスト・ビルド・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
+6. 検出した問題ごとに、Policy のスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
+7. ブロッキング問題が1件でもあれば REJECT と判定する

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

@@ -1,5 +1,5 @@
 **Terraform 規約準拠**のレビューに集中してください。
-AI特有の問題はレビューしないでください（ai_reviewムーブメントで実施済み）。
+AI特有の問題はレビューしないでください（ai_reviewステップで実施済み）。
 
 **レビュー観点:**
 - 変数宣言の規約準拠（type, description, sensitive）

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

@@ -15,9 +15,18 @@
 - 記録された意図的な判断は FP として指摘しない
 - ただし設計判断自体の妥当性も評価し、問題がある場合は指摘する
 
+**前回指摘の追跡（必須）:**
+- まず Report Directory 内で、このステップが前回までに出力したレビュー結果とそのタイムスタンプ付き履歴を確認し、無印ファイルを最新結果、直前のタイムスタンプ付きファイルを前回結果として扱う
+- `Previous Response` がある場合は補助情報として参照してよいが、findings の状態判定はレポート履歴を優先する
+- 各 finding に `finding_id` を付け、今回の状態を `new / persists / resolved / reopened` で判定する
+- `persists` と判定する場合は、未解決である根拠（ファイル/行）を必ず示す
+- 前回レポートにある open findings を、今回のレポートへ欠落させない
+
 ## 判定手順
 
-1. Report Directory内のテスト計画・テストスコープに関するレポートと実装されたテストを突合する
-2. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
-3. ブロッキング問題が1件でもあればREJECTと判定する
-4. 外部契約があるのに入力位置（root body / query / path）の検証が欠けていれば、原則としてカバレッジ不足として扱う
+1. まず前回 open findings をレポート履歴から抽出し、`new / persists / resolved / reopened` を仮判定する
+2. Report Directory内のテスト計画・テストスコープに関するレポートと実装されたテストを突合する
+3. テスト・ビルド・動作確認を根拠に書く場合は、確認対象・確認内容・結果をレポート内に具体的に残す
+4. 検出した問題ごとに、Policyのスコープ判定表と判定ルールに基づいてブロッキング/非ブロッキングを分類する
+5. ブロッキング問題が1件でもあればREJECTと判定する
+6. 外部契約があるのに入力位置（root body / query / path）の検証が欠けていれば、原則としてカバレッジ不足として扱う

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

@@ -1,9 +1,9 @@
 実行済みのテスト・ビルド・動作確認の証跡を確認し、最終承認を行ってください。
 
-**ピース全体の確認:**
-1. レポートディレクトリ内の全レポートを確認し、ピース全体の整合性をチェックする
+**ワークフロー全体の確認:**
+1. レポートディレクトリ内の全レポートを確認し、ワークフロー全体の整合性をチェックする
    - 計画と実装結果が一致しているか
-   - 各レビュームーブメントの指摘が適切に対応されているか
+   - 各レビューステップの指摘が適切に対応されているか
    - タスクの本来の目的が達成されているか
    - 前段レビューの finding が、指示書・計画・実コードに照らして妥当か
 2. 指示書・計画・意思決定履歴を一次情報として確認する
@@ -29,11 +29,20 @@
    - finding が成立しても、タスク目的を外れた追加要求や過剰な一般化なら overreach として記録する
    - false positive / overreach を暗黙のまま流さない
 5. テスト・ビルド・動作確認の扱い
-   - このムーブメントでコマンドを再実行する前提で書かない
+   - このステップでコマンドを再実行する前提で書かない
    - 実行ログ、レポート、CI結果など、この run で確認できる証跡だけを使う
    - 証跡がない項目は「未確認」と明記し、成功扱いにしない
    - レポート本文と実行証跡が矛盾する場合は、その矛盾自体を指摘する
 
+**レポートの読み方:**
+- 同名レポートは、無印ファイルを最新結果、`{レポート名}.{タイムスタンプ}` を履歴として扱う
+- 前段 finding の再評価では、無印ファイルと直前のタイムスタンプ付き履歴を比較し、`new / persists / resolved / reopened` の意味が維持されているか確認する
+- 要約レポートは一次証跡としては扱わない。一次証跡は、実行結果を記録したレポート、具体的な確認内容を記したレビューレポート、実コードの順で確認する
+- 実行結果を記したレポート内の `ビルド結果` / `テスト結果` は一次証跡として扱ってよい
+- レビューレポートの「成功を確認した」という記述は、確認対象・確認内容・結果が具体的に書かれている場合のみ補助証跡として扱う
+- 証跡同士が矛盾する場合は、`実行結果を記したレポート > 具体的な確認内容を持つレビューレポート > 要約レポート` の優先順位で判断する
+- 後続レポートが前段 finding を `resolved` / `false_positive` / `overreach` と再評価している場合、その再評価が task・plan・実コードと整合するかを確認して採否を決める
+
 **レポートの確認:** Report Directory内の全レポートを読み、
 未解消のブロッキング finding が残っていないか、またその finding 自体が妥当か確認してください。
 

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

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

package/builtins/ja/facets/instructions/write-tests-first.md

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

package/builtins/ja/facets/knowledge/architecture.md

@@ -118,8 +118,8 @@ Vertical Slice の判定基準:
 
 ```typescript
 // REJECT - 実行層が設定ソースを直接知っている
-async function executePiece(options) {
-  const engine = new PieceEngine({
+async function executeWorkflow(options) {
+  const engine = new WorkflowEngine({
     provider: options.provider ?? globalConfig.provider,
   });
 }
@@ -132,9 +132,9 @@ class AgentRunner {
 }
 
 // OK - 境界で解決し、内部は解決済み値を使う
-async function executePiece(options) {
+async function executeWorkflow(options) {
   const context = resolveExecutionContext(options);
-  const engine = new PieceEngine(context);
+  const engine = new WorkflowEngine(context);
 }
 
 class AgentRunner {
@@ -228,7 +228,7 @@ for (const transition of step.transitions) {
 export function matchesCondition(status: Status, condition: TransitionCondition): boolean {
 
 // OK - 設計判断の理由（Why）
-// ユーザー中断はピース定義のトランジションより優先する
+// ユーザー中断はワークフロー定義のトランジションより優先する
 if (status === 'interrupted') {
   return ABORT_STEP;
 }
@@ -475,13 +475,13 @@ DRY にしないケース:
 
 ```typescript
 // 配線漏れ: projectCwd を受け取る口がない
-export async function executePiece(config, cwd, task) {
-  const engine = new PieceEngine(config, cwd, task);  // options なし
+export async function executeWorkflow(config, cwd, task) {
+  const engine = new WorkflowEngine(config, cwd, task);  // options なし
 }
 
 // 配線済み: projectCwd を渡せる
-export async function executePiece(config, cwd, task, options?) {
-  const engine = new PieceEngine(config, cwd, task, options);
+export async function executeWorkflow(config, cwd, task, options?) {
+  const engine = new WorkflowEngine(config, cwd, task, options);
 }
 ```
 

package/builtins/ja/facets/knowledge/frontend.md

@@ -288,43 +288,17 @@ const WeeklyCalendar = ({ facilityId }) => {
 
 ### 独立ウィジェットパターン
 
-WordPress のサイドバーウィジェットのように、どのページにも「置くだけ」で動くコンポーネント。親のデータフローに参加しない自己完結型。
-
-該当する例:
-- 通知バッジ・通知ベル（未読数を自分で取得）
-- ログインユーザー情報表示（ヘッダーのアバター等）
-- お知らせバナー
-- 天気・為替など外部データ表示
-- アクティビティフィード（サイドバー）
-
-```tsx
-// OK - 独立ウィジェット。どのページに置いても自分で動く
-const NotificationBell = () => {
-  const { data } = useNotificationCount({ refetchInterval: 30000 })
-  return (
-    <button aria-label="通知">
-      <Bell />
-      {data?.unreadCount > 0 && <span className="badge">{data.unreadCount}</span>}
-    </button>
-  )
-}
-
-// OK - ヘッダーに常駐するユーザーメニュー
-const UserMenu = () => {
-  const { data: user } = useCurrentUser()
-  return <Avatar name={user?.name} />
-}
-```
+どのページにも「置くだけ」で動く自己完結型コンポーネント（通知バッジ、ログインユーザー表示等）。
 
 ウィジェットと判定する条件（すべて満たすこと）:
-- 親のデータと**完全に無関係**（親から props でデータを受け取る必要がない）
-- 親の状態に**影響を与えない**（結果を親にバブリングしない）
-- **どのページに置いても同じ動作**をする（ページ固有のコンテキストに依存しない）
+- 親のデータと完全に無関係
+- 親の状態に影響を与えない
+- どのページに置いても同じ動作をする
 
 1つでも満たさない場合は View でデータ取得し、props で渡す。
 
 ```tsx
-// WRONG - ウィジェットに見えるが、orderId という親のコンテキストに依存
+// WRONG - orderId という親のコンテキストに依存。ウィジェットではない
 const OrderStatusWidget = ({ orderId }: { orderId: string }) => {
   const { data } = useGetOrder(orderId)
   return <StatusBadge status={data?.status} />
@@ -336,16 +310,49 @@ const OrderStatusWidget = ({ status }: { status: OrderStatus }) => {
 }
 ```
 
-判断基準: 「親が管理する意味がない / 親に影響を与えない」ケースのみ許容。
-
 | 基準 | 判定 |
 |------|------|
 | コンポーネント内で直接fetch | Container層に分離 |
 | エラーハンドリングなし | REJECT |
 | ローディング状態の未処理 | REJECT |
-| キャンセル処理なし | 警告 |
 | N+1クエリ的なフェッチ | REJECT |
 
+### 画面専用APIの利用
+
+画面が必要とするデータは、その画面専用のAPIエンドポイントから取得する。既存の汎用APIを流用して画面を組み立てない。APIが存在しない場合は、フロントで回避するのではなく、バックエンドに専用エンドポイントの追加を先に行う。
+
+| 基準 | 判定 |
+|------|------|
+| 一覧APIのレスポンスを詳細画面でも使い回す | REJECT |
+| 一覧の表示単位とAPIの取得単位がずれている | REJECT |
+| 判定だけのために全件取得する（集計APIを使うべき） | REJECT |
+| 画面ごとに専用の取得口を持ち、必要なデータだけ返す | OK |
+
+```tsx
+// REJECT - 一覧APIを詳細画面で流用
+const DetailScreen = ({ itemId }) => {
+  const { data: list } = useListItems({ date })
+  const item = list?.items.find(i => i.id === itemId)
+  return <Detail item={item} />
+}
+
+// OK - 詳細画面は詳細APIを使う
+const DetailScreen = ({ itemId }) => {
+  const { data: item } = useGetItem(itemId)
+  return <Detail item={item} />
+}
+```
+
+### 通信スコープの限定
+
+通信はタブ・画面単位で閉じる。他タブのために先読みしない。定期ポーリングは表示中の画面だけで行う。
+
+| 基準 | 判定 |
+|------|------|
+| タブ切替で表示中の画面だけが通信する | OK |
+| 全タブ共通の親でまとめて通信し、子タブに配る | REJECT |
+| 非表示タブでもポーリングが動き続ける | REJECT |
+
 ## 共有コンポーネントと抽象化
 
 ### カテゴリ分類

package/builtins/ja/facets/knowledge/react.md

@@ -67,6 +67,45 @@ useEffect(() => {
 | loading state 更新で再取得が走る | REJECT |
 | message 表示や dialog 開閉で再取得が走る | REJECT |
 
+## データフェッチライブラリのキャッシュ適性
+
+データフェッチライブラリ（React Query 等）のキャッシュはすべてのデータ取得に適するわけではない。データの変動頻度とページング方式で判断する。
+
+| データ特性 | キャッシュ | 判定 |
+|-----------|----------|------|
+| 単一リソースの詳細（設定値、プロフィール等） | 有効 | OK |
+| 安定した一覧（マスタデータ、変更頻度が低い） | 有効 | OK |
+| cursor ページングかつ途中で追加・削除・並び替えが起きる一覧 | 無効 | local state で取得 |
+| offset ページングかつ途中でデータ変動が起きる一覧 | 無効 | local state で取得 |
+
+cursor ページングとキャッシュの相性が悪い理由:
+
+- nextId（cursor）が古くなり、次ページ取得で欠落や重複が発生する
+- 削除された行を基準に次ページを取ると取りこぼしが起きる
+- タブ復帰時に途中ページを自動再取得すると「いま見えている一覧」とサーバーの実態がズレる
+
+データフェッチライブラリを使う場合でもキャッシュを実質無効にする必要があるなら、そのライブラリを使う意味がない。画面の責務として毎回取り直す方が安全。
+
+```tsx
+// REJECT - 変動する cursor paged 一覧に React Query のキャッシュを適用
+const { data } = useInfiniteQuery({
+  queryKey: ['records'],
+  queryFn: ({ pageParam }) => fetchRecords(pageParam),
+  getNextPageParam: (last) => last.nextId,
+  staleTime: 5 * 60 * 1000,  // 途中で削除されうるのにキャッシュを効かせている
+})
+
+// OK - local state で画面の責務として取得
+const [records, setRecords] = useState<Record[]>([])
+const [nextId, setNextId] = useState<string | undefined>()
+
+const loadMore = async () => {
+  const result = await fetchRecords(nextId)
+  setRecords(prev => [...prev, ...result.items])
+  setNextId(result.nextId)
+}
+```
+
 ## custom hook の責務
 
 React custom hook は「React の state/effect/ref を使う状態遷移」に限定する。純粋計算だけなら custom hook ではなく関数モジュールでよい。

package/builtins/ja/facets/knowledge/takt.md

@@ -2,28 +2,28 @@
 
 ## コア構造
 
-PieceEngine は状態機械。movement 間の遷移を EventEmitter ベースで管理する。
+WorkflowEngine は状態機械。step 間の遷移を EventEmitter ベースで管理する。
 
 ```
-CLI → PieceEngine → Runner（4種） → RuleEvaluator → 次の movement
+CLI → WorkflowEngine → Runner（4種） → RuleEvaluator → 次の step
 ```
 
 | Runner | 用途 | 使い分け |
 |--------|------|---------|
-| MovementExecutor | 通常の3フェーズ実行 | デフォルト |
-| ParallelRunner | 並列サブムーブメント | parallel ブロック |
+| StepExecutor | 通常の3フェーズ実行 | デフォルト |
+| ParallelRunner | 並列サブステップ | parallel ブロック |
 | ArpeggioRunner | データ駆動バッチ処理 | arpeggio ブロック |
 | TeamLeaderRunner | タスク分解 → サブエージェント並列 | team_leader ブロック |
 
-各 Runner は排他。1つの movement に複数の Runner タイプを指定しない。
+各 Runner は排他。1つの step に複数の Runner タイプを指定しない。
 
 ### 3フェーズ実行モデル
 
-通常 movement は最大3フェーズで実行される。セッションはフェーズ間で維持される。
+通常 step は最大3フェーズで実行される。セッションはフェーズ間で維持される。
 
 | フェーズ | 目的 | ツール | 条件 |
 |---------|------|--------|------|
-| Phase 1 | メイン作業 | movement の allowed_tools | 常に |
+| Phase 1 | メイン作業 | step の allowed_tools | 常に |
 | Phase 2 | レポート出力 | Write のみ | output_contracts 定義時 |
 | Phase 3 | ステータス判定 | なし（判定のみ） | タグベースルール時 |
 
@@ -49,7 +49,7 @@ RuleEvaluator は5段階フォールバックで遷移先を決定する。先
 | `all("...")` / `any("...")` | 集約条件 | `AGGREGATE_CONDITION_REGEX` |
 | 文字列 | タグまたは AI フォールバック | — |
 
-新しい特殊構文を追加する場合は pieceParser.ts の正規表現と RuleEvaluator の両方を更新する。
+新しい特殊構文を追加する場合は workflowParser.ts の正規表現と RuleEvaluator の両方を更新する。
 
 ## プロバイダー統合
 
@@ -72,7 +72,7 @@ ProviderAgent.call(prompt, options) → AgentResponse
 5段階の優先順位でモデルを解決する。上位が優先。
 
 1. persona_providers のモデル指定
-2. movement の model フィールド
+2. step の model フィールド
 3. CLI `--model` オーバーライド
 4. config.yaml（プロバイダー一致時）
 5. プロバイダーデフォルト
@@ -104,8 +104,8 @@ vitest を使用。テストファイルの命名規約で種別を区別する
 | プレフィックス | 種別 | 内容 |
 |--------------|------|------|
 | なし | ユニットテスト | 個別関数・クラスの検証 |
-| `it-` | 統合テスト | ピース実行のシミュレーション |
-| `engine-` | エンジンテスト | PieceEngine シナリオ検証 |
+| `it-` | 統合テスト | ワークフロー実行のシミュレーション |
+| `engine-` | エンジンテスト | WorkflowEngine シナリオ検証 |
 
 ### Mock プロバイダー
 

package/builtins/ja/facets/output-contracts/architecture-review.md

@@ -36,6 +36,11 @@
 |---|------------|------------|----------------|---------|------|--------|
 | 1 | ARCH-REOPENED-src-file-L55 | design-violation | `前回: src/file.ts:10 で修正済み` | `src/file.ts:55 で再発` | 問題の説明 | 修正方法 |
 
+## 検証証跡
+- ビルド: {確認対象・確認内容・結果。未確認ならその旨}
+- テスト: {確認対象・確認内容・結果。未確認ならその旨}
+- 動作確認: {確認対象・確認内容・結果。未確認ならその旨}
+
 ## REJECT判定条件
 - `new`、`persists`、または `reopened` が1件以上ある場合のみ REJECT 可
 - `finding_id` なしの指摘は無効

package/builtins/ja/facets/output-contracts/qa-review.md

@@ -35,6 +35,11 @@
 |---|------------|------------|----------------|---------|------|--------|
 | 1 | QA-REOPENED-src-test-L55 | test-coverage | `前回: src/test.ts:10 で修正済み` | `src/test.ts:55 で再発` | 問題の説明 | 修正方法 |
 
+## 検証証跡
+- ビルド: {確認対象・確認内容・結果。未確認ならその旨}
+- テスト: {確認対象・確認内容・結果。未確認ならその旨}
+- 動作確認: {確認対象・確認内容・結果。未確認ならその旨}
+
 ## REJECT判定条件
 - `new`、`persists`、または `reopened` が1件以上ある場合のみ REJECT 可
 - `finding_id` なしの指摘は無効

package/builtins/ja/facets/output-contracts/requirements-review.md

@@ -41,6 +41,11 @@
 |---|------------|------------|----------------|---------|------|--------|
 | 1 | REQ-REOPENED-src-file-L55 | req-gap | `前回: file:line で修正済み` | `file:line で再発` | 問題の説明 | 修正方法 |
 
+## 検証証跡
+- ビルド: {確認対象・確認内容・結果。未確認ならその旨}
+- テスト: {確認対象・確認内容・結果。未確認ならその旨}
+- 動作確認: {確認対象・確認内容・結果。未確認ならその旨}
+
 ## REJECT判定条件
 - `new`、`persists`、または `reopened` が1件以上ある場合のみ REJECT 可
 - `finding_id` なしの指摘は無効

package/builtins/ja/facets/output-contracts/security-review.md

@@ -33,6 +33,11 @@
 |---|------------|------------|----------------|---------|------|--------|
 | 1 | SEC-REOPENED-src-auth-L55 | injection-risk | `前回: src/auth.ts:20 で修正済み` | `src/auth.ts:55 で再発` | 問題の説明 | 修正方法 |
 
+## 検証証跡
+- ビルド: {確認対象・確認内容・結果。未確認ならその旨}
+- テスト: {確認対象・確認内容・結果。未確認ならその旨}
+- 動作確認: {確認対象・確認内容・結果。未確認ならその旨}
+
 ## 警告（非ブロッキング）
 - {セキュリティに関する推奨事項}
 

package/builtins/ja/facets/output-contracts/testing-review.md

@@ -37,6 +37,11 @@
 |---|------------|------------|----------------|---------|------|--------|
 | 1 | TEST-REOPENED-src-test-L55 | test-structure | `前回: src/test.ts:10 で修正済み` | `src/test.ts:55 で再発` | 問題の説明 | 修正方法 |
 
+## 検証証跡
+- ビルド: {確認対象・確認内容・結果。未確認ならその旨}
+- テスト: {確認対象・確認内容・結果。未確認ならその旨}
+- 動作確認: {確認対象・確認内容・結果。未確認ならその旨}
+
 ## REJECT判定条件
 - `new`、`persists`、または `reopened` が1件以上ある場合のみ REJECT 可
 - `finding_id` なしの指摘は無効

package/builtins/ja/facets/personas/research-analyzer.md

@@ -42,4 +42,4 @@
 
 - そのギャップは元の依頼にとって重要か（重要でなければ無視してよい）
 - 追加調査で埋められる見込みがあるか（公開データが存在しそうか）
-- 調査コスト（ムーブメント消費）に見合うか
+- 調査コスト（ステップ消費）に見合うか

package/builtins/ja/facets/personas/supervisor.md

@@ -29,12 +29,15 @@
 - 実行していないコマンド結果を推測で書かない。証跡がなければ未確認として扱う
 - レポート本文と実行証跡が矛盾する場合は、矛盾自体を最優先の問題として扱う
 - false positive と overreach を区別する。成立しない指摘と、範囲外の指摘を同じ扱いにしない
+- 無印レポートを最新結果、タイムスタンプ付きレポートを履歴として扱う
+- 要約レポートより、実行結果を記したレポートと具体的な確認内容を持つレポートを優先する
+- 後続レポートが前段 finding を再評価している場合、その再評価が task・plan・実コードと整合するかを確認してから採用する
 
 ## ドメイン知識
 
 ### Human-in-the-Loop チェックポイント
 
-あなたは自動化されたピースにおける人間の代理。承認前に以下を自問する。
+あなたは自動化されたworkflowにおける人間の代理。承認前に以下を自問する。
 
 - これは本当にユーザーの問題を解決しているか？
 - 意図しない副作用はないか？

package/builtins/ja/facets/policies/ai-antipattern.md

@@ -169,6 +169,21 @@ Legacy対応の判定基準:
 - `.transform()` による正規化、`LEGACY_*_MAP` のようなマッピング、`@deprecated` な型定義は追加しない
 - 新しい値のみをサポートし、シンプルに保つ
 
+## 早すぎるキャッシュ戦略の導入
+
+AIはパフォーマンスを「改善」するためにキャッシュ機構を先回りで導入しがちである。明示的に要求されるまでキャッシュ戦略は追加しない。
+
+| パターン | 例 | 判定 |
+|---------|-----|------|
+| データ取得にキャッシュレイヤー追加 | stale-while-revalidate設定、インメモリキャッシュ、Redis導入 | REJECT |
+| ローカルへのキャッシュ保存 | APIレスポンスをローカルストレージやファイルに保存して再利用 | REJECT |
+| 計測なしのメモ化 | ボトルネック未特定のままメモ化を多用 | REJECT |
+| キャッシュ無効化の独自実装 | TTL、キャッシュキー管理、パージ機構の追加 | REJECT |
+
+判断基準: 「キャッシュが必要」という明示的な要求または計測結果があるか?
+- YES → 実装してよい
+- NO → 実装しない。素朴なデータ取得で十分
+
 ## デッドコード検出
 
 AIは新しいコードを追加するが、不要になったコードの削除を忘れることが多い。

package/builtins/ja/facets/policies/design-planning.md

@@ -49,4 +49,4 @@
 
 - **画面単位の雑な要約だけで計画すること** - 要素の抜け漏れが発生する
 - **根拠なしに参照資料の意図を狭めること** - 実装とレビューの前提がずれる
-- **スコープ外の説明を省略すること** - 後続ムーブメントで判断不能になる
+- **スコープ外の説明を省略すること** - 後続ステップで判断不能になる

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

@@ -76,6 +76,18 @@ DRY違反の修正案は、単に共通化を求めるだけでは不十分と
 | grep で呼び出し元・使用箇所を検索 | 記憶に基づいて指摘する |
 | 型定義・スキーマを突合 | 推測でデッドコードと判断する |
 | 生成ファイル（レポート等）とソースを区別 | 生成ファイルをソースコードとしてレビュー |
+| ツール出力が正常に読めることを確認 | 文字化け・異常文字を含む出力に基づいて指摘する |
+| 「存在しない」主張は対象行を直接読んで検証 | 検索結果だけで「コードにない」と断定する |
+
+### ツール出力の信頼性
+
+ツール出力が正常に読めない場合、読める方法で読み直してから判断する。
+
+| 状況 | 対応 |
+|------|------|
+| 出力が文字化け・エンコーディング異常を含む | 文字化けを認識し、別の手段（ファイルを直接開く、行番号指定で該当箇所を読む）で正しい内容を取得してから判断する |
+| 検索コマンドで該当コードが見つからなかった | ファイルの該当行を直接読み、存在しないことを確認してから指摘する。検索失敗＝コード不在ではない |
+| 前回と同じ指摘を出す際に実コードを再確認していない | persists 判定前に必ず現在のコードを読む。前回の記憶で再指摘しない |
 
 ## 具体的な指摘の書き方
 

package/builtins/ja/facets/policies/screen-api.md

@@ -0,0 +1,109 @@
+# 画面専用APIポリシー
+
+画面が必要とするデータは、画面専用のAPIエンドポイントで提供する。汎用APIの流用で画面を組み立てない。
+
+## 原則
+
+| 原則 | 基準 |
+|------|------|
+| 画面とAPIの対応 | 画面が必要とするデータ構造に合わせた専用エンドポイントを用意する |
+| 一覧と詳細の分離 | 一覧APIのレスポンスを詳細画面で使い回さない |
+| 集計は集計APIで | 件数・合計・判定に全件取得して手元で集計しない |
+| ページング責務はサーバー | ページサイズ・ソート順・フィルタ条件はサーバーが管理する |
+| 不足はAPIを足す | フロントで回避するのではなく、バックエンドにエンドポイントを追加する |
+
+## 画面単位のAPI設計
+
+画面ごとに「その画面が何を表示し、何を操作するか」を基準にエンドポイントを設計する。
+
+| パターン | 判定 | 理由 |
+|---------|------|------|
+| 一覧画面が一覧API、詳細画面が詳細APIを使う | OK | 画面責務とAPI責務が一致 |
+| 詳細画面が一覧APIを叩いて結果からIDで検索する | REJECT | 不要なデータを取得し、APIの契約もずれる |
+| 判定用に全件取得してフロントで集計する | REJECT | サーバーに集計APIを用意する |
+| 処理中と完了済みを同じAPIで取って画面で仕分ける | REJECT | サーバー側で分けて返す |
+| 既存APIにない情報が画面に必要になった | APIを追加する | フロントで別APIを組み合わせて代替しない |
+
+```typescript
+// REJECT - 一覧APIを詳細画面で流用
+async function loadDetail(id: string) {
+  const list = await fetchList({ date })
+  return list.items.find(item => item.id === id)
+}
+
+// OK - 詳細画面は詳細APIを使う
+async function loadDetail(id: string) {
+  return await fetchDetail(id)
+}
+```
+
+## ページングとデータ量の制御
+
+ページングの責務はサーバーに寄せる。フロントはページサイズを指定せず、サーバーが適切な件数を返す。
+
+| パターン | 判定 |
+|---------|------|
+| サーバーがデフォルトのページサイズを持ち、フロントは nextId だけ送る | OK |
+| フロントが limit を指定してサーバーに送る | 避ける（サーバーだけで変更できなくなる） |
+| 一覧APIが件数制限なしで全件返す | REJECT |
+| サーバーが limit の上限をバリデーションする | OK |
+
+```typescript
+// 避ける - フロントがページサイズを決めている
+const result = await fetchList({ date, limit: 10, nextId })
+
+// OK - フロントは nextId だけ送り、ページサイズはサーバー任せ
+const result = await fetchList({ date, nextId })
+```
+
+## 集計と判定の責務
+
+「何件あるか」「生成可能か」「再生成すべきか」のような判定はサーバーが行い、結果を返す。
+
+| パターン | 判定 |
+|---------|------|
+| 一括生成の可否判定のために記録全件を取得する | REJECT |
+| 集計APIで確認済み件数・未確認件数を返す | OK |
+| 再生成可能フラグをサーバーが計算して返す | OK |
+| フロントで生成済みメモIDを比較して再生成可能を判定する | REJECT |
+
+```typescript
+// REJECT - 判定のために全件取得
+const memos = await fetchAllMemos({ date })
+const canGenerate = memos.filter(m => m.confirmed).length > 0
+
+// OK - サーバーが集計を返す
+const counts = await fetchMemoCounts({ date })
+// counts: { childId, memoCount, confirmedCount, unconfirmedCount }
+```
+
+## タブ・画面遷移と通信スコープ
+
+通信はタブ・画面単位で閉じる。他タブのために先読みしない。
+
+| パターン | 判定 |
+|---------|------|
+| タブ切替で表示中の画面だけが通信する | OK |
+| 全タブ共通の親でまとめて通信し、子タブに配る | REJECT |
+| 定期ポーリングは表示中の画面だけで行う | OK |
+| 非表示タブでもポーリングが動き続ける | REJECT |
+
+## バックエンド側の責務
+
+フロントが画面専用APIを使えるよう、バックエンドは以下を提供する。
+
+| 責務 | 内容 |
+|------|------|
+| 一覧と詳細の分離 | 一覧は軽量なサマリー、詳細は必要な情報を含む |
+| 関連データの内包 | 画面が必要とする関連データはレスポンスに含める（N+1回避） |
+| 集計エンドポイント | 件数・確認状況等の集計は専用エンドポイントで返す |
+| 判定フラグの算出 | 再生成可否・生成可否等はサーバーが計算してフラグで返す |
+| ページング基盤 | nextId カーソル、デフォルトページサイズ、上限バリデーション |
+
+## 禁止事項
+
+- **汎用API流用** - 一覧APIを詳細画面で、全件取得を集計目的で使わない
+- **フロント側集計** - 全件取得してフロントで件数を数えない
+- **クロスタブ通信** - 他タブが使うデータを先読みしない
+- **ページサイズのフロント指定** - サーバーに任せる
+- **APIがないからフロントで代替** - 専用エンドポイントを追加する