aif-improve

改善 - 計画の精緻化（第2回）

コードベースに照らして既存の計画を再分析し、精緻化します。不足している項目やタスク、誤った依存関係を見つけ、タスクの品質を高めます。

核となる考え方

existing plan + deeper codebase analysis + user feedback (optional)
    ↓
find gaps, missing edge cases, wrong assumptions
    ↓
enhanced plan with better tasks, correct dependencies, more detail

ワークフロー

ステップ 0：設定の読み込みと引数の解析

最初に： .ai-factory/config.yaml が存在する場合は読み込み、以下を解決します。

• コマンドのデフォルト値： workflow.improve_check（ブール値、デフォルト：false）。値がない場合はfalseを使用します。値または型が無効な場合（引用符付きのブール値文字列を含む）は、WARN [config] invalid workflow.improve_check; falling back to falseを出力し、falseを使用します。
• パス： paths.plan、paths.plans、paths.fix_plan、paths.research、paths.description、paths.architecture、paths.roadmap、paths.rules_file、paths.rules、paths.patches、paths.archive。また、research_bundles_dir = <paths.researchの親ディレクトリ>/research/を導出します。
• 言語： プロンプトと要約にはlanguage.ui、計画アーティファクトの更新にはlanguage.artifacts、計画アーティファクト内の人が読む技術用語にはlanguage.technical_termsを使用します。
• Git： git.enabled、git.base_branch、git.create_branches
• ワークフロー： workflow.plan_id_format（デフォルト：slug）—ブランチベースの計画検出に使用します。
  有効な値はslugとsequentialです。ルート直下の*.mdは、解決された高速計画または修正計画のパスでない限り、名前付きの完全な計画として扱います。直下の*/index.mdは、``が1つだけ含まれている場合に限り、バンドル形式の計画エントリーポイントとして扱います。sequentialの場合は、[0-9]{4}_<branch-slug>.mdと[0-9]{4}_<branch-slug>/index.mdの両方を検索し、最も大きい接頭辞を選択します。timestampとuuidは予約値であり、現在はslugと同じように動作します。不明な値はslugとして扱います。

config.yamlが存在しない場合は、デフォルト値を使用します。

• 計画：paths.plan（デフォルト：.ai-factory/PLAN.md）
• plans/：.ai-factory/plans/
• 修正計画：paths.fix_plan（デフォルト：.ai-factory/FIX_PLAN.md）
• 調査：.ai-factory/RESEARCH.md
• patches/：.ai-factory/patches/
• DESCRIPTION.md：.ai-factory/DESCRIPTION.md
• アーキテクチャ：.ai-factory/ARCHITECTURE.md
• ロードマップ：.ai-factory/ROADMAP.md
• ルールファイル：.ai-factory/RULES.md
• ルールディレクトリ：.ai-factory/rules/
• ui_language：en
• artifact_language：en
• technical_terms_policy：keep
• workflow.plan_id_format：slug

解決された言語値：

• ui_language = language.ui || "en"
• artifact_language = language.artifacts || language.ui || "en"
• technical_terms_policy = language.technical_terms || "keep"

technical_terms_policyがkeep、translate、mixedのいずれでもない場合は、keepとして扱います。englishなどの旧形式の値もkeepと同じように扱います。

AskUserQuestionのすべてのプロンプト、進捗状況の更新、精緻化レポート、要約、次のステップに関する案内は、必ずui_languageで記述してください。

paths.plan、paths.plans、paths.fix_planの下に生成または更新する計画アーティファクトの内容は、必ずartifact_languageで記述してください。

例外：既存の## Original Requestセクションは、生の入力ソースであり、生成されたアーティファクトの文章ではありません。編集または再生成のたびに、計画ファイルから読み取った見出しと本文をそのまま保持してください。artifact_languageが異なる場合でも、翻訳、要約、正規化、トリミング、書き換えを行わないでください。 テンプレートと例は構造を定義するものであり、固定された英語の出力を定義するものではありません。artifact_language が en でない場合は、人が読む見出し、ラベル、タスクの説明文、ロードマップの根拠、調査の要約、改善メモ、依存関係のメモを翻訳してから保存してください。Markdown の構造、チェックボックスの構文、タスク ID、数値の接頭辞、ブランチ名、コミットメッセージ、コマンド、ファイルパス、設定キー、パッケージ名、API 名、WARN／INFO ラベル、生のエラーは変更せず保持してください。後続の調査ドリフトチェックで互換性トークンとして解析されるため、## Research Context、Source:、Active Summary、Updated:、SHA256: はそのまま保持してください。後続のワークフローチェックで互換性トークンとして解析されるため、## Requirements Reconciliation はそのまま保持してください。その他の人が読む用語には technical_terms_policy を適用してください。

最初に引数を解析します：

- --list    → list available plans only (read-only, then STOP)
- +check    → after refinement, validate findings via a fresh-context subagent
- --no-check → skip findings validation for this invocation, overriding config
- @<path>   → explicit plan file, ultra directory, or ultra `index.md` override (highest priority)
- remaining argument text → optional improvement prompt

+check と --no-check は単独の制御トークンであり、$ARGUMENTS 内のどこにあってもかまいません。@<path> と改善プロンプトを解決する前に、これらのトークンのみを取り除いてください。パスや文章内の部分文字列は取り除かないでください。明示的なフラグがある場合はそれを使用し、ない場合は workflow.improve_check から check_enabled を解決してください。両方のフラグがある場合は、最後のフラグが優先されます。設定済みのデフォルト値を $ARGUMENTS や改善プロンプトの先頭に追加してはいけません。

--list がある場合は、これを優先し、改善処理は実行しません。--list モードでは、どちらの検証フラグと workflow.improve_check も無視し、そのことを通知しません（改善処理の実行前に検証するものがないためです）。以下では、「+check が設定されている」とは、設定または明示的なフラグによって check_enabled = true と解決された状態を指します。

Step 0.list：利用可能な計画の一覧表示（--list）

$ARGUMENTS に --list が含まれている場合は、references/LIST-MODE.md の手順を実行して終了してください。このドキュメントが、検出ルール、出力形式、読み取り専用の契約（改善処理を行わない、ファイルを変更しない、+check は通知なく無視する）の唯一の情報源です。内容をここに重複して記載しないでください。

Step 1：アクティブな計画の解決

このステップはデフォルト（--list 以外）モードで実行され、以下の優先順位に従って、改善対象となる計画アーティファクトを1つ選びます。--list の検出リストロジックは references/LIST-MODE.md に記載されており、このステップとは独立しています。

次の優先順位に従って、アクティブな計画アーティファクトを特定します：

1. If `$ARGUMENTS` contains `@<path>`:
   - Resolve the path (relative to project root; absolute paths allowed)
   - Accept a markdown file, an ultra directory containing `index.md`, or that `index.md`
   - If missing → show "Plan artifact not found: <path>" and STOP
   - Before normalizing a directory or treating an explicit `index.md` as ultra,
     Read `index.md` and require exactly one
     ``; otherwise STOP with a plan-integrity error
2. No explicit `@<path>` override → Check current git branch:
   git branch --show-current
   → Convert branch name to filename: replace "/" with "-" (this is <branch-slug>)
   → When `workflow.plan_id_format = sequential`, glob both:
     `<configured plans dir>/[0-9][0-9][0-9][0-9]_<branch-slug>.md`
     `<configured plans dir>/[0-9][0-9][0-9][0-9]_<branch-slug>/index.md`
     Read every directory candidate and retain it only when `index.md` contains
     exactly one ``. Choose the highest-numbered
     valid artifact and emit `WARN [aif-improve]` when multiple valid candidates
     exist; if both shapes share the highest prefix, prefer ultra.
   → If no valid sequential match exists, or sequential mode is inactive, check
     `<configured plans dir>/<branch-slug>/index.md` and
     `<configured plans dir>/<branch-slug>.md`. Read the directory entrypoint
     before selection and ignore it unless it contains exactly one ultra marker;
     if both valid shapes exist, warn and prefer ultra.
   Example (slug):       feature/user-auth → .ai-factory/plans/feature-user-auth.md
   Example (sequential): feature/user-auth → .ai-factory/plans/0042_feature-user-auth.md
3. If the branch-based plan is missing or git mode is off:
   → Count root `*.md` full plans plus declared-ultra direct child `*/index.md`
     entrypoints; exclude resolved `paths.plan` and `paths.fix_plan`
   → If exactly one artifact exists, use it
   → Do not count ultra phase files as plans
   → If multiple exist, ask the user to choose or require `@<path>`
4. No named full/ultra plan → Check the resolved fast plan path (from /aif-plan fast)
5. No regular plan and no resolved fast plan → Check the resolved fix plan path (from /aif-fix plan mode)

注： 計画の検出対象は paths.plans/ のみです。/aif-archive によって paths.archive/plans/ にアーカイブされた計画は、検出対象から除外されます。 自動検出された */index.md の候補はすべて、選択前に読み込む必要があります。 また、`` が1つだけ含まれている場合を除き、候補から除外してください。マークされた ultra バンドルにリンク切れがある場合は、ブロッキングとなる整合性エラーであり、フォールバックの機会ではありません。

どの場所にも計画ファイルが見つからない場合：

No active plan found.

To create a plan first, use:
- /aif-plan full <description>  — for a rich single-file feature plan
- /aif-plan ultra <description> — for an exhaustive multi-file plan bundle
- /aif-plan fast <description>  — for a quick task plan
- /aif-fix <bug description>    - for a bugfix plan (use the resolved fix plan path)

→ ここで終了します。 計画アーティファクトなしで先に進んではいけません。

計画アーティファクトが見つかった場合 → ステップ 2（コンテキストの読み込み）に進みます。

Step 2：コンテキストの読み込み

2.1：計画アーティファクトを読む

選択されたエントリーポイントを最後まで読みます。ultra の index.md の場合は、その Phase Index のリンクを検証し、バンドルを分析または再生成する前に、リンクされたすべてのフェーズファイルを順番に読みます。バンドルは一体の計画として扱います。次の内容を把握してください。

• 機能の範囲と目標
• ## Original Request がある場合：元のユーザーの意図と、計画の変更不可な範囲の基準。このセクションは未加工のソース入力として扱い、計画を編集または再生成する際もそのまま保持してください。
• 現在のタスク（対象、説明、依存関係）
• 設定（テスト、ログの設定）
• コミットのチェックポイント
• 完了済みのタスク（チェックボックス - [x]）
• ultra の場合：各タスクのフェーズファイルに記載された正確なパス／シンボル、実装手順、契約、リスク、受け入れ基準、検証

2.2：プロジェクトのコンテキストを読む

存在する場合は .ai-factory/DESCRIPTION.md（設定に記載されたパスを使用）を読みます。

• 技術スタック
• アーキテクチャ
• 規約
• 非機能要件 解決済みのアーキテクチャおよびロードマップの成果物がある場合は、それらを読みます。解決済みのルール階層を次の順に読みます：paths.rules_file、rules.base、次に計画に関連する名前付きの rules.<area> エントリです。より具体的なルールは一般的なルールより優先されます。プロジェクトで詳細な動作についての権威ある情報源として明示されていない限り、ロードマップの内容はスコープとして扱います。

計画に ## Research Context が含まれている場合は、その埋め込みコピーを確定済みの要件スナップショットとして扱います。最初の Source: / Reference: 行を、正規の ^(?:Source|Reference):\s+\x60([^\x60]+)\x60\s+\( 構文で解析します。旧形式のパスのみの行については、^(?:Source|Reference):\s+(.+?)\s+\( にフォールバックします。使用可能なパスをどちらの形式でも特定できない場合に限り、設定済みの paths.research にフォールバックします。

解析されたソースが research_bundles_dir 内にある場合、兄弟ファイルの INDEX.md に `` が1回だけ含まれ、## Artifact Index からその RESEARCH.md へのリンクがあることを必須とします。そうでない場合は WARN [research-drift] を出力します。有効な兄弟 C4／ADR／依存関係の成果物は根拠としてのみ扱い、計画のスコープを拡大してはなりません。

SHA256: がある場合は、現在のソーステキストを と の間から厳密に抽出し、HTML コメントブロックを削除して、行順と先頭の空白を保持し、各行末の空白を削除し、改行を LF に統一し、末尾を改行1つで終わらせます。shasum -a 256 または sha256sum を使って標準入力からハッシュを計算します。ダイジェストを正とします。SHA256: がない場合に限り、Updated: を旧形式のフォールバックとして使います。ソースが見つからない場合や無効な場合、またはリビジョンが一致しない場合は WARN [research-drift] を出力します。ユーザーが明示的にリベースを要求しない限り、埋め込みの Research Context を基に調整します。

リンクされていない計画に ## Research Context を追加する場合は、同じ正規化アルゴリズムを使い、SHA256: の値と同じ最初の出力フィールドを使用します。一時的なリポジトリアーティファクトを作成せず、標準入力またはインラインのシェル入力から計算します。

それ以外の場合は、/aif-plan と同じ慎重な優先順位に従って、関連する調査ソースを最大1つ選択します。明示的なソース、明確に一致する直接の子バンドルで、その INDEX.md に `` が1回だけ含まれ、Status: active が宣言され、## Artifact Index から RESEARCH.md へのリンクがあるもの、次に設定済みの旧形式ファイルの順です。複数のソースを統合したり、更新日の新しさだけで選択したりしてはなりません。

.ai-factory/skill-context/aif-improve/SKILL.md を読みます — ファイルが存在する場合は必須です。

このファイルには、パッチ、コードベースの規約、技術スタック分析から /aif-evolve が蓄積したプロジェクト固有のルールが含まれています。これらのルールは現在のプロジェクトに合わせて調整されています。

2.3：パッチを読む（限定的なフォールバック）

パッチは既定の情報源ではなく、フォールバックのコンテキストとして使用します。

• .ai-factory/skill-context/aif-improve/SKILL.md が存在せず、解決済みのパッチディレクトリが存在する場合：
  • Glob: <resolved patches dir>/*.md
  • パッチのファイル名を昇順（辞書順）に並べ、その後、最後の 10 個（または存在する数がそれ未満の場合はその数）を選択します
  • 選択したパッチファイルのみを読みます
  • 計画の品質に影響する、再利用可能な Prevention／Root Cause のパターンに焦点を当てます
• スキルコンテキストが存在する場合、既定ではすべてのパッチを読んではなりません。
  • 既知の再発する問題を中心に調整する場合は、対象を絞った少数のパッチを任意で確認できます スキルコンテキストのルールを適用する方法：
• これらは、このスキルの一般的な指示に対するプロジェクトレベルの上書きとして扱います
• スキルコンテキストのルールが、この SKILL.md に記載された一般的なルールと競合する場合は、 スキルコンテキストのルールが優先されます（より具体的なコンテキストが優先されます。ネストされた CLAUDE.md ファイルと同じ原則です）
• 競合がない場合は、両方を適用します。SKILL.md の一般的なルールと、スキルコンテキストのプロジェクトルールです
• スキルコンテキストのルールがこのスキルの既定のルールに反しているように見えても、無視してはいけません。 既定のルールでは不十分だとプロジェクトの経験から判明したため、これらのルールが存在します
• 重要： スキルコンテキストのルールは、このスキルのすべての出力に適用されます。計画の 改良レポートや、計画への変更も含まれます。スキルコンテキストのルールに「タスクには必ず X を含める」 または「計画の構成には必ず Y が必要」とある場合、改良時にも必ず適用してください。スキルコンテキストの ルールを無視した改良レポートを作成するのはバグです。

遵守の確認： 出力成果物を生成した後は、スキルコンテキストのルールをすべて満たしているか確認してください。 ルールに違反している場合は、ユーザーに提示する前に出力を修正してください。

2.4：現在のタスクリストを読み込む

TaskList → Get all tasks with statuses

すでに作成されたもの、進行中のもの、完了したものを把握します。

ステップ 3：コードベースの詳細分析

ここでは、/aif-plan が最初に行った調査よりも深くコードベースを調査します。

3.1：既存のコードパスをたどる

計画内の各タスクについて、関連ファイルを見つけます。

Glob + Grep: Find files mentioned in tasks
Read: Understand current implementation

以下を確認します。

• 計画が踏襲すべき既存のパターン
• タスクの説明内容をすでに部分的に実装しているコード
• 計画で見落とされていた隠れた依存関係
• 新たに作成するのではなく、計画で使用すべき共通ユーティリティやサービス

3.2：統合ポイントを確認する

計画で見落とされている可能性がある項目を確認します。

• 更新が必要な API ルート
• 必要なデータベースマイグレーション
• 変更が必要な設定ファイル
• インポート／エクスポートの更新
• 適用されるミドルウェアやガード
• 既存のバリデーションパターン

3.3：エッジケースを確認する

技術スタックとコードベースに基づいて、以下を確認します。

• プロジェクトで使用されているエラー処理パターン
• null／undefined の安全性に関するパターン
• 必要な認証／認可チェック
• レート制限とキャッシュに関する考慮事項
• 境界でのデータ検証

3.4：要件と動作の組み合わせを照合する

• 計画に ## Requirements Reconciliation セクションがある場合は、それを読みます。調査に基づく引用は、埋め込みの ## Research Context と照合して解決します。ユーザーが明示的に再ベースを依頼しない限り、最新の調査ソースは内容のずれを示すものとしてのみ扱います。ほかに引用されている箇所は、現在の権威あるコンテキストと照合して確認します。
• ソースの優先順位は、ユーザーまたはプロジェクトが定めている場合にのみ適用します。競合するソースの権威性が定められていない場合は、黙ってどちらかを選ばず、曖昧さを報告します。
• プロジェクトで明示的に詳細な動作契約として扱うよう定められていない限り、ロードマップ項目は詳細な動作契約ではなく、スコープを示すものとして扱います。
• 動作が、互いに独立したセレクター、状態、モード、入力形式に依存する場合は、入力検証、永続化、出力／状態遷移、副作用において、サポートされる組み合わせを確認します。個別には説明されていても、組み合わせとしては未検証のものがないか確認します。
• 実際のリポジトリデータ、設定、フィクスチャ、スキーマ、コンテンツが契約を定義している場合は、代表的な既存の成果物が主要な統合パスを通ることを計画で確認します。

ステップ 4：改善点を特定する

計画と調査結果を比較します。元の意図／範囲の基準として、## Original Request がある場合はそれを、現在のタスクリストおよびコミット済みの ## Research Context と併せて使用します。提案する修正が範囲内となるのは、元の依頼、または明示的に承認されたユーザーの修正依頼をサポートする場合に限られます。それ以外はアクティブな計画に追加せず、4.6（out_of_scope）に振り分けます。問題を分類します。

4.1：タスクの不足

• 必要なのに存在しないタスク（例：移行、設定の更新、インデックスの作成）
• 対応されていないエッジケースのタスク

4.2：タスク品質の問題

• 説明が曖昧すぎる（ファイルパスや具体的な実装詳細がない）
• ログ要件がない
• エラー処理の詳細がない
• ファイルパスが誤っている
• 要件の参照が欠落または誤っている、未解決のソース間の矛盾がある、またはステップ 3.4 で必要とされる ## Requirements Reconciliation セクションがない
• サポート対象の動作の組み合わせまたは代表的な実際の成果物の検証がない。計画のテスト設定に従ってください。テストが有効な場合にのみテストを追加し、それ以外の場合は実行可能な手動検証ステップを追加します。

4.3：依存関係の問題

• タスクの順序が誤っている（タスク A が B に依存しているのに、B が A の後にある）
• 依存関係が欠落している（タスク C がタスク A の成果物を必要としているのに、A によってブロックされていない）
• 不要な依存関係がある（タスクを並行して実行できる）

4.4：重複または冗長なタスク

• 同じ作業を行うタスクが 2 つある
• コードがすでに存在するため不要なタスク
• 既存の機能と重複するタスク

4.5：タスクのサイズに関する問題

• タスクが大きすぎる（分割する必要がある）
• タスクが小さすぎる（統合する必要がある）
• 分割／統合に関する指摘は、「📝 Task Improvements」レポートセクション（4.2 と同じ improvements グループ）に記載します。既存タスクの構成を変更するものであり、タスクを追加または削除するものではありません。

4.6：範囲外のタスク

• 計画に含まれているものの、それ自体は有用そうでも、計画対象の機能とは無関係なタスク（過剰な機能追加）
• 承認された場合は、アクティブな計画から削除されます。これは removals と同じ削除操作です（ステップ 6.4 を参照）。異なるのはレポート上の扱いのみです。範囲外のタスクは「🗑️ Removals」にまとめず、独自の「💡 Out of scope」セクションに記載します。これにより、ユーザーは有用だが無関係なアイデアが削除される前に確認し、別の場所に記録するかどうかを選べます。このスキル自体は、範囲外の項目をどこにも保存しません。

4.7：ユーザープロンプトによる改善（$ARGUMENTS が指定されている場合）

ユーザーが $ARGUMENTS に具体的な改善指示を指定している場合（--list、+check、--no-check、@<path> トークンを除く）：

• ユーザーのフィードバックを計画に反映します
• プロンプトに基づいて変更が必要なタスクを確認します
• ユーザーのプロンプトで必要となる場合は、新しいタスクを追加します

これはディスパッチャーのステップであり、独立した指摘カテゴリではありません。このステップで生じる各指摘は、その性質に応じたグループに振り分けます。新しいタスクは 4.1（missing）、既存タスクの言い換えや拡張は 4.2（improvements）、明示的な削除依頼は 4.4（removals）、有用だが範囲外のアイデアは 4.6（out_of_scope）に振り分けます。ステップ 5 のレポートにも +check の検証にも、独立した 4.7 グループはありません。

任意：ステップ 4 とステップ 5 の間の +check 検証

check_enabled = true（かつ --list が指定されていない）の場合は、ここで、ステップ 4 とステップ 5 の間に references/CHECK-MODE.md の検証手順を実行します。新しいコンテキストのサブエージェントを使って、参照されているファイルを再読込し、その後、捏造された項目を除外し、部分的に正しい項目を書き直し、絞り込んだリストに基づいて依存関係を再計算します。ultra の場合、検証者には計画の成果物としてエントリーポイントと、リンクされたすべてのフェーズファイルを渡す必要があります。index.md のみの検証では不完全です。check_enabled = false の場合は、これを完全に省略します。出力には検証関連の行が含まれず、Summary ブロックは 2 つの +check カウンター行を含まない既定の形式のままです。

ステップ 5：改善点を提示する

見つかった内容を、わかりやすい形式でユーザーに提示します。絵文字でグループ分けされたセクションは一覧性のために維持しますが、「🆕 Missing Tasks」、「📝 Task Improvements」、「🗑️ Removals」、「💡 Out of scope」の各項目はすべて、同じ文章形式に従います。Why:／Issue:／Fix: のラベル付きフィールドは使用しません。

1. 動作への影響 — 計画を現状のままにした場合に、何が機能しなくなるか、または難しくなるか（機能の欠落、曖昧なタスクによる誤った実装、作業を浪費する重複タスクなど）。
2. 補足事項（任意） — コードベースからの短い引用、計画が準拠すべき既存のパターン、または予想される結果。情報を補う場合にのみ記載します。
3. 計画内の位置 — Task #X への参照（新規タスクの場合は「Task #X の後」）。
4. 提案する編集 — 追加する内容、修正する説明、削除する項目を具体的に示します。

「🔗 Dependency Fixes」グループは、この形式では記述しません。他の4つのグループの処理後（およびフラグが設定されている場合は references/CHECK-MODE.md を参照し、+check によるフィルタリング後）に必ず計算し、従来の短い形式で記述します。Task #X should depend on Task #Y. Reason: …。依存関係の項目では、フィルタリング後に残ったタスクのみを参照します。

以下のステップ 5 のレポートテンプレートは、構造のみを定義します。このユーザー向け応答に含まれる、人が読むすべてのテキストを ui_language で表示します。コマンド名、パス、タスク ID、セクション構成、オプション構成、タスク数、数値、WARN／INFO ラベル、および生のエラーは変更せずに保持します。

## Plan Refinement Report

Plan: [plan artifact path]
Tasks analyzed: N

### Findings

#### 🆕 Missing Tasks (N found)
1. The plan currently leaves authenticated requests without a session refresh step — long-running clients silently lose access after the access-token TTL. The existing middleware in `src/middleware/auth.ts` already exposes a `refresh()` hook, so the plan should reuse it instead of inventing a new one. After Task #3. Add a new task: "Wire `authMiddleware.refresh()` into the login flow and cover the expired-token path with an explicit test."

#### 📝 Task Improvements (N found)
1. Task #4 ("Add validation") gives no field-by-field contract — implementer will either over-validate or skip the email format check that the rest of the codebase enforces via `validators/email.ts`. Task #4. Rewrite as: "Validate `email` (via `validators/email.ts`), `password` (min 12 chars), and `displayName` (1-64 chars) in `RegisterRequest`; return 422 with field-level errors when validation fails."

#### 🔗 Dependency Fixes (N found)
1. Task #5 should depend on Task #2. Reason: Task #5 consumes the session helper introduced in Task #2.

#### 🗑️ Removals (N found)
1. Task #7 ("Create UserRepository") duplicates `src/repos/user.ts:12` which already exposes the same query surface — keeping the task will lead to a parallel implementation. Task #7. Remove the task; rely on the existing repository and adjust Task #8 to import it.

#### 💡 Out of scope — for later (N found)
1. Task #11 ("Refactor the logging module") looks reasonable on its own but is unrelated to the login feature this plan is about — keeping it expands scope without any concrete trigger from the current code paths. Task #11. Drop it from the active plan; the idea is surfaced here so you can capture it elsewhere (issue tracker, backlog note) if it's worth revisiting as its own feature later.

#### 📋 Summary
- Missing tasks: N
- Tasks to improve: N
- Dependencies to fix: N
- Tasks to remove: N
- Out of scope: N

When `+check` ran successfully, two extra rows (`Hidden by +check: N`, `Adjusted by +check: M`) are appended to the Summary block — the exact wording and failure-mode replacements live in `references/CHECK-MODE.md`.

AskUserQuestion: Apply these improvements?

Options:
1. Yes, apply all
2. Let me pick which ones
3. No, keep the plan as is

選択内容に基づく処理：

• すべて適用する → すべての改善点を計画ファイルに適用します
• 適用する項目を選ぶ → 各改善点を個別に提示し、承認を求めます
• 適用せず、計画を維持する → 変更せずに終了します

改善点が見つからなかった場合：

以下の完了テンプレートは、構造のみを定義します。これらのユーザー向け応答に含まれる、人が読むすべてのテキストを ui_language で表示します。コマンド名、パス、タスク数、数値は変更せずに保持します。

## Plan Review Complete

The plan looks solid! No significant gaps or issues found.

Plan: [plan artifact path]
Tasks: N

Ready to implement:
/aif-implement

ステップ 6：承認された改善点を適用する

ユーザーの選択に基づいて処理します。

6.1：タスクの説明を改善する

説明を改善する必要がある既存のタスクについて：

TaskGet(taskId) → read current
TaskUpdate(taskId, description: "improved description", subject: "improved subject")

6.2：不足しているタスクを追加する

新規タスクについて：

TaskCreate(subject, description, activeForm)
TaskUpdate(taskId, addBlockedBy: [...]) → set dependencies

6.3：依存関係を修正する

TaskUpdate(taskId, addBlockedBy: [...])

6.4：重複タスクまたはスコープ外のタスクを削除する

removals と out_of_scope は、計画ファイル上では同じ処理に変換されます。つまり、タスクを削除します。

TaskUpdate(taskId, status: "deleted")

この2つの違いはレポートにのみあります。removals は、言及された後に忘れられた、不要な重複タスクです。out_of_scope の項目は「💡 Out of scope」セクションに表示されるため、ユーザーはそのアイデアが認識されたうえで、この計画から意図的に除外されたのであり、痕跡もなく削除されたのではないとわかります。このスキルはスコープ外のタスクをどこにも保存しません。そのアイデアを別の場所（課題管理システム、バックログなど）に記録するかどうかは、ユーザーの判断に委ねられます。

6.5：計画アーティファクトを更新する

重要： すべての変更を加えた後、新しい状態が反映されるように、選択した計画アーティファクトを更新します。

• 適切なフェーズに - [ ] チェックボックス付きで新しいタスクを追加します
• タスクの説明が変わった場合は更新します
• 依存関係が変わった場合はタスクの順序を修正します
• 削除されたタスクを削除します
• タスク数が大幅に変わった場合はコミットのチェックポイントを更新します
• 完了済みタスクの - [x] チェックボックスはそのまま維持します
• 既存の ## Original Request は、見出し、本文、空白、改行を含めて完全にそのまま維持します。翻訳、要約、正規化、トリミング、書き換えは行いません。このセクションは生の入力ソースであり、artifact_language による書き換えの対象外です。
• ユーザーが計画を現在の調査に基づいて明示的に再構成するよう求めない限り、既存の ## Research Context とその Source:／リビジョンマーカーは、書き換えの際も完全にそのまま維持します
• 計画の確定済みの根拠に基づいて ## Requirements Reconciliation を維持または更新します。見出し、宣言された権限、引用、該当する組み合わせ表、検証シナリオは、洗練されたタスクと整合させてください。リンクされた調査に差異が生じている場合、ユーザーが明示的に再構成を求めるまでは、調査に裏付けられた決定を維持します。ライブ調査ソースに基づいて更新できるのは、その再構成時のみです
• リンクされていない計画を現在の調査に基づいて洗練する場合は、該当する Active Summary をコピーして ## Research Context を追加し、Source: `<selected research path>` (Active Summary, Updated: <research Updated timestamp>, SHA256: <sha256 of copied Active Summary>) と記載します
• 正規化されたドリフト判定を用いてハッシュを計算します。HTML コメントブロックを削除し、行の順序と先頭の空白を維持し、各行末の空白を削除して、改行コードを LF にし、末尾に改行をちょうど 1 つ付けます。正規化したテキストを一時ファイルではなく、標準入力またはインラインのシェル入力を通じて shasum -a 256 または sha256sum に渡し、出力の先頭フィールドをコピーします
• リンクされた計画に調査のドリフトがある場合は、確定済みの Research Context とソースリビジョンを計画内に維持し、洗練レポートに WARN [research-drift] を含めます
• ultra の場合は、index.md と影響を受けるフェーズファイルをアトミックに更新します：
  • タスクのチェックボックスは index.md のみに記載します
  • 各タスク ID がちょうど 1 つのフェーズセクションに対応するようにします
  • フェーズファイルの追加、削除、名前変更は、Phase Index とタスクリンクの更新と同時に行います
  • 詳細を改善する際も、完了済みタスクのステータスを維持します
  • リンク、孤立、依存関係、タスクのマッピングに関する整合性チェックを再実行します
  • ultra の詳細要件を維持します：正確なパス／シンボル、順序付けられた編集、契約、エラー／ログ記録の動作、テストポリシー、受け入れ基準、検証

ファイルに外科的な変更を加えるには Edit を使用し、変更範囲が広い場合は影響を受けるファイルを再生成するために Write を使用します。フェーズの詳細を変更した場合、index.md のみを再生成してはいけません。

計画アーティファクトを編集または再生成する際は、人間が読むアーティファクトのすべての内容を artifact_language にしてください。上記の例は構造のみを示しています。完了済みの - [x] チェックボックスは正確に維持します。## Original Request セクションは明示的な言語ポリシーの例外です。生成されたアーティファクトの文章ではなく、ユーザーの生のリクエストであるため、原文のまま維持してください。

識別子の不変条件： 既存の完全な計画ファイル名または ultra ディレクトリ名が ^[0-9]{4}_.*(\.md)?$ に一致する場合、書き換え時に数値プレフィックスを正確に維持します。改善作業中に計画の番号を振り直してはいけません。このプレフィックスは固定されており、再生成後も維持する必要があります。読み込んだものと同じファイルまたはバンドルディレクトリに書き戻してください。

6.6：完了を確認する

以下の Step 6.6 完了テンプレートは構造のみを定義します。このユーザー向け回答の人間が読むテキストは、すべて ui_language で記述してください。コマンド名、パス、タスク数、数値の件数は変更せずに維持します。

## Plan Refined

Changes applied:
- Added N new tasks
- Improved N task descriptions
- Fixed N dependencies
- Removed N redundant tasks

Updated plan: [plan artifact path]
Total tasks: N

Ready to implement:
/aif-implement

コンテキストのクリーンアップ

必要に応じて、/clear（完全にリセット）または /compact（履歴を圧縮）を使用してコンテキストの空き容量を確保するよう、ユーザーに提案します。

成果物の所有権

• 主な所有対象：改善対象の計画成果物（解決済みのブランチ計画パス、名前付きの完全な計画パス、解決済みの簡易計画パス、または明示的に対象として指定された解決済みの修正計画パス）。
• 設定の使用：paths.plans を使用して完全な計画のディレクトリを解決し、paths.plan と paths.fix_plan を使用して簡易計画と修正計画を解決します。git.enabled と git.create_branches を使用して Git の動作を設定します。また、paths.research と、そこから導出される兄弟ディレクトリ research/ から、任意のレガシー／同梱の調査コンテキストを取得し、パッチのフォールバックには paths.patches を使用します。
• 読み取り専用のコンテキスト：説明、アーキテクチャ、ロードマップ、ルール、調査成果物。ただし、アクティブな計画ファイル自体を更新する場合を除きます。

重要なルール

1. 最初から書き直さない — 既存の計画を改善し、置き換えないでください
2. 完了した作業を保持する — 完了済みのタスク - [x] は変更も削除もしないでください
3. 改善の根拠を追跡可能にする — すべての変更は、コードベースの分析またはユーザー入力に基づく必要があります
4. 設定を尊重する — テストが「なし」の場合、テストタスクを追加しないでください。ロギングが「最小限」の場合、冗長なロギングタスクを追加しないでください
5. 過剰な作り込みをしない — 重大な理由がない限り、機能の範囲外のタスクを追加しないでください。計画にすでに含まれているタスクが範囲外に逸脱している場合は、「🗑️ 削除」ではなく「💡 範囲外」レポートのセクションに振り分けてください。有用ではあるものの今回の範囲外であるアイデアと、不要な重複項目を分けてユーザーに提示します。
6. 最小限で有効な改善にする — あらゆる改善案を挙げるのではなく、重要なものだけを提案してください
7. まずユーザーの承認を得る — ユーザーの確認なしに変更を適用しないでください
8. 計画ファイルを同期させる — 改善後、計画ファイルはタスクリストと必ず一致させてください
9. Original Request は変更不可 — 存在する場合は、範囲の判断に ## Original Request を使用し、計画を編集または再生成するたびに、その内容を一字一句変えずに保持してください
10. 要件は外部の根拠として扱う — 計画との整合性を保つために、要件、調査、ロードマップ、ルール、アーキテクチャの成果物を書き換えないでください。計画を改善するか、矛盾を報告してください。

例

デフォルト、プロンプト駆動、計画なし、明示的な計画ファイル指定、「計画に問題なし」の各フローの例は references/EXAMPLES.md にあります。--list モードの例は references/LIST-MODE.md に、+check モードの例は references/CHECK-MODE.md にあります。