aif-implement

実装 - タスク計画の実行

計画内のタスクを実行し、進捗を追跡して、セッションを継続できるようにします。

ワークフロー

ステップ 0（事前）：ハンドオフモードの検出

ハンドオフモードを判定します。呼び出し元がプロンプト内に HANDOFF_MODE と HANDOFF_SKIP_REVIEW を明示的なテキストとして渡した場合は、その値を使用します。そうでない場合は、Bash ツールを使用します。

Bash: printenv HANDOFF_MODE || true
Bash: printenv HANDOFF_SKIP_REVIEW || true

次に、HANDOFF_MODE を確認します。

HANDOFF_MODE が 1 の場合（自律型ハンドオフエージェント）

ハンドオフコーディネーターが、ステータスの遷移と DB への書き込みをすでに直接管理しています。MCP ツールは呼び出さないでください。代わりに、次の手順に従います。

• 対話形式で質問しない： AskUserQuestion は使用しないでください。適切な既定値を使用します（チェックポイントで自動コミットし、一時停止の確認はスキップします）。
• 一時停止／再開の確認をしない： 確認のために停止せず、すべてのタスクを順番に実行します。整合性、安全性、要件の競合に関するブロッキング要因がある場合は、定義された非対話型の結果に従って停止します。

HANDOFF_MODE が 1 ではない場合（手動の Claude Code セッション）

ハンドオフの同期はインラインで処理します。タスク ID の抽出と MCP 同期の開始については、計画ファイルを読んだ後の ステップ 0.2 を参照してください。同期のタイミングは次のとおりです。

• 開始時（ステップ 0.2）： handoff_sync_status → "implementing"（paused: true を指定）
• チェックリストの更新時（ステップ 3.6）： handoff_push_plan（更新した計画の内容を指定）
• 完了時（ステップ 5）： handoff_push_plan（最終計画を指定）、続いて handoff_sync_status → "review"（paused: true を指定）、または "done"（HANDOFF_SKIP_REVIEW=1 の場合は paused: false を指定）

重要： done 以外のすべての handoff_sync_status 呼び出しでは、必ず paused: true を指定してください。これにより、手動で作業している間に自律型ハンドオフエージェントがタスクを引き継ぐことを防ぎます。paused: false を指定できるのは done の場合だけです。

ステップ 0：現在の状態を確認する

最初に： 現在の状態を確認します。

1. Read `.ai-factory/config.yaml` if it exists to resolve:
   - `paths.description`, `paths.architecture`, `paths.rules_file`, `paths.roadmap`, `paths.research`; derive `research_bundles_dir = <parent directory of paths.research>/research/`
   - `paths.plan`, `paths.plans`, `paths.fix_plan`, `paths.patches`
   - `paths.archive`
   - `paths.rules`
   - `language.ui`, `language.artifacts`
   - `git.enabled`, `git.base_branch`, `git.create_branches`
   - `workflow.plan_id_format` (default: `slug`) — used by branch-based plan discovery.
     Active values: `slug` and `sequential`. Discovery treats a root `*.md` as
     a full plan unless it is the resolved `paths.plan` or `paths.fix_plan`.
     Treat a direct child `*/index.md` as an ultra bundle only after reading it
     and confirming that it contains exactly one
     ``; ignore unrelated directories and never count
     phase files independently.
     When `sequential`, resolve both
     `<paths.plans>/[0-9]{4}_<branch-slug>.md` and
     `<paths.plans>/[0-9]{4}_<branch-slug>/index.md`, then choose the
     highest-numbered matching artifact.
     `timestamp` and `uuid` are **reserved values** and currently behave like `slug`.
     Treat any unknown value as `slug`.
   - `rules.base` plus any named `rules.<area>` entries
2. Parse arguments:
   - --list → list available plans only (no implementation; STOP)
   - --without-plan <description> → inline implementation mode; skip plan discovery and jump to Step 0.inline
   - @<path> → explicit plan file, ultra directory, or ultra `index.md` override (highest priority)
   - <number> → start from specific task
   - status → status-only mode
   - Optional inline-mode flag: --docs=yes|no|warn (only valid with --without-plan; default: warn)
3. If `git.enabled = true`, check for uncommitted changes (`git status`)
4. If `git.enabled = true`, check current branch

ステップ 0.list：利用可能な計画を一覧表示する（--list）

$ARGUMENTS に --list が含まれている場合は、読み取り専用で計画を検索し、終了します。

1. Get current branch:
   git branch --show-current (git mode only)
2. Convert branch to canonical stem: replace "/" with "-" (git mode only)
3. Check existence of:
   - <configured plans dir>/<branch-stem>.md and
     <configured plans dir>/<branch-stem>/index.md (git mode only); Read the
     directory entrypoint and report it only when it contains exactly one
     ``
   - when `workflow.plan_id_format = sequential`: also glob
     `<configured plans dir>/[0-9][0-9][0-9][0-9]_<branch-stem>.md` and
     `<configured plans dir>/[0-9][0-9][0-9][0-9]_<branch-stem>/index.md`;
     Read every directory entrypoint, discard those without exactly one marker,
     and report all valid matches (highest-numbered first)
   - if git mode is off or branch creation is disabled: any root `*.md` full
     plan or declared-ultra direct child `*/index.md` entrypoint in
     `<configured plans dir>/`; exclude the resolved fast/fix plan paths
   - <resolved fast plan path>
   - <resolved fix plan path>
4. Print plan availability summary and usage hints
5. STOP.

重要： --list モードでは、次の操作を行わないでください。

• タスクを実行しない
• ファイルを変更しない
• TaskList のステータスを更新しない

出力形式と例の詳細については、次を参照してください。

• skills/aif-implement/references/IMPLEMENTATION-GUIDE.md →「利用可能な計画を一覧表示する（--list）」

ステップ 0.inline：インライン実装モード（--without-plan）

$ARGUMENTS に --without-plan が含まれている場合は、計画ファイルを作成したり読んだりせず、説明から範囲を限定した単一のタスクを実行します。これは、完全な計画を作成するほどではないものの、バグ修正ではない小規模な feat／chore タスク向けの軽量な方法です（バグには /aif-fix を使用します）。

引数の解析：

1. description = everything after `--without-plan`, excluding any recognized flag tokens (`--docs=...`).
2. docs_policy = value of `--docs=yes|no|warn` if present, else `warn` (default).
3. Validation:
   - description is empty →
     ERROR: "Usage: /aif-implement --without-plan <description> [--docs=yes|no|warn]"
     → STOP
   - arguments also contain `@<path>`, `status`, or a bare task id number →
     ERROR: "`--without-plan` is mutually exclusive with @plan-file, status, and task id."
     → STOP
   - `--docs=<value>` where <value> not in {yes, no, warn} →
     ERROR: "Invalid --docs value. Expected yes|no|warn."
     → STOP

スコープガード（大規模タスクの見落としを防止）：

実行前に、説明の範囲を評価します。「and」／「и」で複数の関連しない指示が結ばれている、複数のサブシステムが参照されている、または範囲の説明が概ね約 300 文字を超えているなど、一度のインラインタスクとして範囲が広すぎると思われる場合は、計画を推測して作成しないでください。代わりに、次のメッセージを出力します。

Description looks too broad for inline implementation. Recommended:
  /aif-plan fast <description>

→ 停止します。

範囲が狭く焦点を絞った説明（例：「200 を返す GET /healthz を {status:"ok"} で追加する」）であれば続行します。

既存の計画成果物に関する注意喚起（ブロックなし）：

インラインモードでは、設計上、計画ファイルを無視します。次のいずれかがディスク上に存在する場合は、意図的にスキップすることがユーザーにわかるよう、WARN [inline] 行を出力します（読み込んだり、リダイレクトしたりしないでください）。

• <configured plans dir>/<branch>.md または <configured plans dir>/<branch>/index.md（git モードのみ）、またはその [0-9]{4}_<branch> 連番形式
• 解決済みの高速計画パス（paths.plan）
• 解決済みの修正計画パス（paths.fix_plan）

例：WARN [inline] paths.plan exists but is ignored in --without-plan mode.

プロジェクトのコンテキストを読み込む（通常の実装と同じ）：

ステップ 0 で解決した設定を使用します。

• 存在する場合は paths.description（DESCRIPTION.md）
• 存在する場合は paths.architecture（ARCHITECTURE.md）
• paths.rules_file（RULES.md）＋ rules.base ＋名前付きの rules.<area> エントリー
• .ai-factory/skill-context/aif-implement/SKILL.md — ファイルが存在する場合は必須（Step 0.1 の通常モードと同じ優先順位および適用ルール）
• language.ui、language.artifacts

プラン成果物のポリシー： インラインモードでは、プラン／修正プランファイルを読み込んだり使用したりしません。プランファイルは読み取り、解析、実行のいずれも行いません。最小限の存在確認は、WARN [inline] 行を出力する目的に限り許可されます（上記の surprise-warn セクションを参照）。ディスクから読み取ることは一切ありません。また、再開／復旧時の整合性確認、TaskList の読み込み、チェックボックスの状態比較もスキップします。

タスクを実行します（一度限り）：

1. 次のように通知します：Inline implementation: <description>
2. 説明された範囲に関連するファイルのみを読み取ります
3. 既存のコードパターンと skill-context のルールに従って変更を適用します
4. references/LOGGING-GUIDE.md に従って詳細なログを適用します
5. デフォルトではテストを追加しないでください。説明でテストが明示的に要求されている場合（例：「テスト付きで」「X のテストを追加」）、または既存のプロジェクト規約／変更対象のコードパスで明らかに必要な場合（例：対象領域の各ソースファイルに対応するテストファイルがある、または RULES.md／skill-context のルールでこの種の変更にテストカバレッジが必須とされている場合）に限り、テストを追加します。判断に迷う場合は、テストを追加しないでください。より広範なテストカバレッジが必要であれば、ユーザーが後から /aif-plan を使えるようにします。
6. 変更を検証し、コンパイル／実行できることと、説明された動作が機能することを確認します

インラインモードで禁止される操作：

• paths.plan／paths.plans/*／paths.fix_plan を作成または読み取りしないでください。
• /aif-plan または /aif-fix を呼び出さないでください。
• paths.patches の下にエントリーを作成しないでください（[FIX] の自己改善パッチは禁止です。これはバグ修正のフローではありません）。
• TaskList／TaskGet／TaskUpdate を呼び出さないでください（プランがなければ、永続化されるタスクもありません）。
• ディスク上のプランのチェックボックスを検索または変更しないでください。
• ロードマップのマイルストーン完了チェック、ドキュメントのチェックポイントからのプラン設定、プランファイルのクリーンアップ確認、またはワークツリーのマージ確認を実行しないでください（これらはプランに基づくワークフローに属します）。

Handoff のインラインサポート：

命名に関する補足：--without-plan は「ディスク上のローカルプラン成果物なし」（paths.plan／paths.plans/*／paths.fix_plan なし）を意味します。Handoff タスクがリンクされている場合、そのタスクは handoff_push_plan を介して Handoff 内に合成プランとして引き続き表現されます。これはローカルファイルではなく、リモート表現です。ローカルプランなしという契約は維持され、リモート同期の対象は変わりません。

HANDOFF_MODE が 1 の場合（自律型 Handoff エージェントがインラインモードで起動された場合）：

• mcp__handoff__* ツールを呼び出さないでください（コーディネーターがステータス／同期を直接管理します。Step 0（pre）と同じルールです）。
• ローカルのプラン成果物を作成しないでください（上記の「禁止される操作」のリストが引き続き適用されます）。
• ブランチの切り替え、ワークツリーの作成やマージ、その他コーディネーターが設定したブランチ／ワークツリーの変更を行わないでください。インラインモードは、起動された作業ツリー上で動作します。
• 一度限りの実行を進めます。スキルの実行が戻った後、コーディネーターがタスクを完了にします。

HANDOFF_MODE が 1 ではなく、HANDOFF_TASK_ID が設定されている場合（Handoff タスクにリンクされた手動の Claude Code セッション）：

1. 合成プランの内容を作成します：

   # Inline implementation
   - [ ] <description>
   

2. { taskId: <HANDOFF_TASK_ID>, newStatus: "implementing", sourceTimestamp: "<current UTC ISO 8601>", direction: "aif_to_handoff", paused: true } を指定して handoff_sync_status を呼び出します。

3. { taskId: <HANDOFF_TASK_ID>, planContent: <synthetic content above> } を指定して handoff_push_plan を呼び出します。

4. 実行が成功した後、合成コンテンツ内のチェックボックスを - [x] に変更し、更新したテキストを指定して handoff_push_plan を再度呼び出します。

5. 同期を完了します：

   • HANDOFF_SKIP_REVIEW が 1 の場合 → paused: false を指定して handoff_sync_status を "done" にします。
   • それ以外の場合 → paused: true を指定して handoff_sync_status を "review" にします。

HANDOFF_TASK_ID が設定されていない場合 → この実行では、MCP 同期をすべてスキップします。 ドキュメントポリシー（--docs で制御するインラインモード）：

• --docs=yes → 完了後、ドキュメントのチェックポイントを表示し（通常モードの Docs: yes と同じ AskUserQuestion）、変更を /aif-docs に渡します。
• --docs=no → ドキュメントのチェックポイントを省略し、WARN [docs] --docs=no in inline mode; documentation checkpoint skipped を出力します。
• --docs=warn（デフォルト）→ WARN [docs] Inline mode default is warn-only; documentation checkpoint skipped. Pass --docs=yes to enable. を出力します。

インラインモードでのコンテキストの維持：

• 解決済みの説明アーティファクトの更新：許可されます。通常モードと同じルールが適用されます（新しい依存関係／統合に関する事実の差分のみ）。
• 解決済みのアーキテクチャアーティファクトと AGENTS.md：新しいモジュール／フォルダーが実際に作成された場合に限り許可されます。
• 解決済みのロードマップアーティファクト：インラインモードでは更新されません（計画がないため、マイルストーンとの関連付けができません）。
• 解決済みのルールファイル：インラインモードでは編集されません（通常モードと同じです）。

完了時の出力（インラインモード）：

## Inline Implementation Complete

Task: <description>

Files modified:
- <file> (created|modified)
Documentation: <outcome per --docs>

What's next?

1. 🔍 /aif-verify — Verify the change (recommended)
2. 💾 /aif-commit — Commit directly

続けて、次の選択肢を提示します。

AskUserQuestion: Inline task complete. What's next?

Options:
1. Verify first — Run /aif-verify (recommended)
2. Skip to commit — Go straight to /aif-commit

→ 選択したフォローアップが完了したら停止します。要約ドキュメントやレポートファイルは作成しません。

ステップ 0.0：再開／復旧（中断後または /clear 後）

ユーザーが翌日に再開した場合、セッションが放棄されたと言った場合、または（たとえば /clear の後など）コンテキストが失われたと考えられる場合は、タスクを続ける前にリポジトリからローカルコンテキストを再構築します。

git.enabled = true の場合：

1. git status
2. git branch --show-current
3. git log --oneline --decorate -20
4. (optional) git diff --stat
5. (optional) git stash list

git.enabled = false の場合は、git の復旧コマンドを省略し、解決済みの計画／修正計画のパスと作業ツリーの状態のみを照合します。

次に、計画／タスクの状態を照合します。

• git のブランチ別計画を使用している場合は、現在の計画アーティファクトが現在のブランチと一致することを確認します（@path による上書きが優先されます。それ以外の場合は、ブランチ名の付いた完全なファイルまたは ultra ディレクトリが、解決済みの fast 計画より優先されます）。
• git.enabled = false の場合、またはブランチなしで full／ultra 計画が作成された場合は、次の順に優先します。
  • 明示的に指定された @plan-file-or-directory。
  • 設定された plans ディレクトリ内にある、ルート直下の唯一の *.md 完全な計画、または ultra と宣言された直下の子ディレクトリにある */index.md エントリーポイント。ただし、解決済みの fast／fix 計画パスは除外します。
  • 解決済みの fast 計画パス。
• TaskList のステータスと計画のエントリーポイントにあるチェックボックスを比較します。
  • タスクのコード変更がすでに実装されているように見えるのに、タスクが完了としてマークされていない場合は、すばやく確認してから TaskUpdate(..., status: "completed") を実行し、計画のチェックボックスも更新します。
  • タスクが完了としてマークされているのに、対応するコードがない場合（rebase／reset が行われた場合）は、未完了に戻し、ユーザーと相談します。

未コミットの変更がある場合：

AskUserQuestion: You have uncommitted changes. Commit them first?

Options:
1. Yes, commit now (/aif-commit)
2. No, stash and continue
3. Cancel

選択に応じて：

• はい → /aif-commit を実行してから、計画の検出を続けます。
• いいえ → git stash push -m "aif-implement: stash before plan execution" を実行してから続けます。
• キャンセル → ユーザーに「実装をキャンセルしました。」と伝えます。→ 停止

計画ファイルがなく、解決済みの修正計画がある場合：

修正計画は、計画モードで /aif-fix によって作成されたものです。修正ワークフローに切り替えます。

Found a fix plan at the resolved fix plan path.

This plan was created by /aif-fix and should be executed through the fix workflow
(it creates a patch and handles cleanup automatically).

Running /aif-fix to execute the plan...

→ /aif-fix を呼び出します（引数なし。解決済みの修正計画を検出して実行します）。 → 停止 — 実装ワークフローを続けないでください。

計画ファイルも解決済みの修正計画もない場合（すべてのタスクが完了済み、または新規開始）：

AskUserQuestion: No active plan found. Current branch: <current-branch>.
What would you like to do?

Options:
1. Start new feature from current branch
2. Return to configured base branch and start new feature
3. Create quick task plan (no branch)
4. Nothing, just checking status

選択に応じて：

• 現在のブランチから新機能を開始 → /aif-plan full <description>
• ベースブランチに戻る → git checkout <configured-base-branch> を実行し、続けて git pull origin <configured-base-branch> → /aif-plan full <description>（git モードのみ）
• 簡易タスク → /aif-plan fast <description>
• 何もせず、状態を確認するだけ → ブランチ情報と最近のコミットの概要を表示 → 停止

git.enabled = false の場合は、選択肢 2 を次のように置き換えます。

• 2. ブランチを作成せずに詳細な完全計画を作成
• git コマンドを一切使わずに /aif-plan full <description> に渡します。

計画ファイルがある場合 → ステップ 0.1 に進みます

ステップ 0.1：プロジェクトのコンテキストと過去の経験を読み込む

ステップ 0 の解決済み設定を使用します。

• パス： description、architecture、RULES.md、roadmap、research、plan ファイル、patches、rules ディレクトリ
• 言語： プロンプトには language.ui、生成コンテンツには language.artifacts
• ルールの階層： 解決済みの RULES.md ファイル + rules.base + 名前付きの rules.<area> エントリ

存在する場合は、.ai-factory/DESCRIPTION.md を読み込み（設定で指定されたパスを使用）、以下を把握します。

• 技術スタック（言語、フレームワーク、データベース、ORM）
• プロジェクトのアーキテクチャと規約
• 非機能要件

存在する場合は、解決済みのアーキテクチャ成果物（paths.architecture、既定値：.ai-factory/ARCHITECTURE.md）を読み込み、以下を把握します。

• 選択されたアーキテクチャパターンとフォルダー構成
• 依存関係のルール（何が何に依存するか）
• レイヤー／モジュールの境界と通信パターン
• 実装時はこれらの規約（ファイルの配置、インポート、モジュール境界）に従います

存在する場合は、解決済みの RULES.md パスを読み込みます。

• これらはユーザーが追加した、プロジェクト固有のルールと規約です
• 実装時は必ずこれらのルールに従ってください。一般的なパターンより優先されます
• ルールは簡潔で実行可能な内容です。それぞれを厳守すべき要件として扱ってください

ルールの階層を読み込みます（パスは設定から取得します）。

1. RULES.md – 公理（プロジェクト全体に適用されるルール）
2. rules/base.md — プロジェクト固有の基本規約（命名、構成、パターン）
3. rules. — 設定から解決された領域固有のルールエントリ（例：rules.api、rules.frontend）

利用可能なルールファイルをすべて読み込み、統合します。より具体的なルールが一般的なルールより優先されます。

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

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

skill-context ルールの適用方法：

• このスキルの一般的な指示に対するプロジェクトレベルの上書きとして扱います
• skill-context のルールがこの SKILL.md に記載された一般的なルールと矛盾する場合は、skill-context のルールを優先します（より具体的なコンテキストが優先されます。ネストされた CLAUDE.md ファイルと同じ原則です）
• 矛盾がない場合は、SKILL.md の一般的なルールと skill-context のプロジェクトルールの両方を適用します
• skill-context のルールがこのスキルの既定値と矛盾しているように見えても、無視してはいけません。プロジェクトの経験から既定値では不十分だと判明したために存在しています
• 重要： skill-context のルールは、このスキルのすべての出力に適用されます。作成するコードやプランのチェックボックスの更新方法も含まれます。skill-context のルールに「コードは必ず X に従う」または「実装には必ず Y を含める」とある場合は、必ず従ってください。skill-context のルールに違反するコードを書くことはバグです

適用の徹底： 出力成果物を生成した後は、すべての skill-context ルールに照らして検証します。ルールに違反している場合は、ユーザーに提示する前に出力を修正してください。

パッチによる代替手段（限定的。skill-context がない場合のみ）：

• .ai-factory/skill-context/aif-implement/SKILL.md が存在せず、解決済みの patches ディレクトリが存在する場合：
  • Glob を使用して、解決済みの patches ディレクトリ内の *.md ファイルを検索します
  • パッチのファイル名を辞書順で昇順に並べ、末尾の 10 件（10 件未満の場合はすべて）を選択します
  • 選択したパッチファイルのみを読み込みます
  • Root Cause と Prevention のセクションを優先します
• skill-context が存在する場合、既定ではすべてのパッチを読み込まないでください。
  • タスクが既知の失敗パターンに明確に当てはまる場合に限り、対象を絞って最近のパッチをいくつか読むことができます

実装時にこのコンテキストを活用します。

• 指定された技術スタックに従います
• 正しいインポートパターンと規約を使用します
• 指定どおりに適切なエラー処理とログ記録を行います
• skill-context のルールや、該当する代替パッチに記載された落とし穴を避けます

ステップ 0.2：プラン成果物を見つける

選択した成果物をすべて、次の形式に正規化します。

• plan_entrypoint — 設定と ## Tasks を含む単一の Markdown ファイル
• plan_bundle_dir — fast/full/fix プランでは空、それ以外では ultra ディレクトリ
• phase_files — 単一ファイルプランでは空、それ以外では ultra エントリポイントの ## Phase Index からの順序付きリンク

$ARGUMENTS に @<path> が含まれる場合:

1. パスをプロジェクトルートからの相対パスとして解決します（絶対パスも有効です）。
2. 既存の Markdown ファイル、index.md を含む ultra ディレクトリ、またはその ultra バンドルの index.md を受け付けます。
3. どちらの表現も存在しない場合は、fast ファイル、full ファイル、ultra ディレクトリの例を挙げて不足しているパスを報告し、STOP します。
4. ディレクトリを正規化したり、明示的な index.md を ultra として扱う前に、index.md を Read し、`` がちょうど 1 つだけ存在することを必須とします。そうでなければ、プラン整合性エラーで STOP します。
5. 選択されたファイルが paths.fix_plan の場合は、/aif-fix を呼び出して STOP します。
6. それ以外の場合はそれを使用し、自動検出をスキップします。

明示的な上書きがない場合、次の順序で解決します:

1. Branch-based full/ultra artifact:
   a. Compute <branch-stem> by replacing "/" with "-".
   b. For workflow.plan_id_format=sequential, glob both:
        <paths.plans>/[0-9][0-9][0-9][0-9]_<branch-stem>.md
        <paths.plans>/[0-9][0-9][0-9][0-9]_<branch-stem>/index.md
      Read every directory candidate and retain it only when `index.md` contains
      exactly one . Choose the highest numeric prefix
      across valid artifacts. If multiple valid candidates exist, emit
      WARN [aif-implement] and name the chosen artifact; if both shapes share
      the highest prefix, prefer ultra.
   c. If no valid sequential candidate exists, or sequential mode is inactive,
      check:
        <paths.plans>/<branch-stem>/index.md
        <paths.plans>/<branch-stem>.md
      Read the directory entrypoint before selection and ignore it unless it
      contains exactly one . If both valid shapes
      exist, emit WARN and prefer the ultra entrypoint.
2. If no branch artifact resolves, count active named artifacts as:
     - each root <paths.plans>/*.md file except resolved paths.plan and paths.fix_plan
     - each direct child <paths.plans>/*/index.md containing 
   Exactly one total → use it. More than one → ask the user to choose or use
   @<path>; do not count phase files as independent plans.
3. No named artifact → paths.plan.
4. No regular plan → paths.fix_plan, then redirect to /aif-fix and STOP.

優先順位は変わりません: 明示的なパス → ブランチベースの full/ultra 成果物 → 単一の名前付き full/ultra 成果物 → fast プラン → fix プランへのリダイレクト。検出は paths.plans のみをスキャンします。paths.archive/plans 配下のアーカイブされたファイルとディレクトリは除外されます。

選択された成果物を読み取ります:

• 自動検出されたディレクトリのエントリポイントに `` がちょうど 1 つ含まれていない場合、それは AI Factory プランではありません。それを無視して検出を続行します。マーカーが含まれているものの Phase Index が不正な場合は、別のプランにフォールバックせず、プラン整合性エラーで STOP します。
• 常に plan_entrypoint を完全に読み取ります。
• それが ultra の場合（`` を含む）、すべての相対 Phase Index リンクを検証し、バンドル外に出るパスを拒否し、順序付きのフェーズファイルを記録し、インデックス化されたすべてのタスクがちょうど 1 つの ## Task N セクションにマッピングされることを確認します。壊れたバンドルでは推測せず、警告して STOP します。
• タスクを実装する前に、そのタスクの完全なフェーズファイルを読み取ります。再開時は、前のセッションで読み取っていても、アクティブなフェーズを再読み取りします。
• index.md が唯一の進捗ソースです。フェーズファイルがタスクチェックボックスを重複して持ってはいけません。
• ## Original Request は有用な元のスコープコンテキストとして扱います。実行可能な入力は、設定、依存関係、タスクチェックリスト、コミットされた Research Context、および（ultra の場合は）リンクされたフェーズ仕様のままです。
• エントリポイントの Research Context に research-drift 契約を適用します。最初の Source: / Reference: 行を正規の ^(?:Source|Reference):\s+\x60([^\x60]+)\x60\s+\( 構文で解析し、バッククォートで区切られたパスをキャプチャして、スペースや括弧がそのまま保たれるようにします。古いベアパス形式の行の場合は、^(?:Source|Reference):\s+(.+?)\s+\( にフォールバックします。どちらの形式でも使用可能なパスが特定できない場合にのみ、paths.research にフォールバックします。
• 解析されたソースが research_bundles_dir 内にある場合、その兄弟 INDEX.md に `` がちょうど 1 回含まれていることを必須とし、その RESEARCH.md を ## Artifact Index からリンクします。そうでなければ WARN [research-drift] を出力します。有効な兄弟 C4/ADR/依存関係の成果物は根拠にとどまり、コミットされたスコープを拡張しません。
• SHA256: が存在する場合、現在のソーステキストを と の間から厳密に抽出し、HTML コメントブロックを削除し、行順序と先頭の空白を保持し、各行の末尾スペースを削除し、LF 改行を使用し、1 つの改行で終了します。shasum -a 256 または sha256sum で標準入力を通してハッシュ化します。ダイジェストが正となります。Updated: は SHA256: が存在しない場合のレガシーフォールバックとしてのみ使用します。ソースの欠落/無効、またはリビジョンの不一致の場合は、WARN [research-drift] を出力し、コミットされたプランコンテキストを使用し続けます。この契約の単一ファイル向けの文言では、WARN [research-drift] を出力し、プランに埋め込まれた Research Context をスコープとして使用し続けます。

plan_entrypoint を読み取った直後に、その最初の行に `` が含まれているか確認します:

• 手動モードでは、それを抽出し、ステータス implementing、実際の現在の UTC タイムスタンプ、方向 aif_to_handoff、および paused: true を指定して handoff_sync_status を呼び出します。
• 自律 Handoff モードでは、MCP を呼び出さないでください。
• 存在しない場合は、このセッションの MCP 同期をスキップします。

ultra の進捗を Handoff にプッシュするときは、バンドル全体をエントリポイントのコンテンツとしてシリアライズし、続けてリンクされた各フェーズファイルを順番に、`` をプレフィックスとして付けてシリアライズします。

ステップ 1: 現在の状態を読み込む

TaskList → Get all tasks with status

次を見つけます。

• 次の保留中のタスク（ブロックされておらず、完了していない）
• すべての in_progress タスク（これらを先に再開します）

ステップ 2: 進捗を表示する

## Implementation Progress

✅ Completed: 3/8 tasks
🔄 In Progress: Task #4 - Implement search service
⏳ Pending: 4 tasks

Current task: #4 - Implement search service

ステップ 3: 現在のタスクを実行する

各タスクについて:

3.1: 完全な詳細を取得する

TaskGet(taskId) → Get description, files, context

ultra バンドルの場合、index.md からタスクの詳細リンクを解決し、タスクを in progress としてマークする前に、リンクされたフェーズファイル全体を読み取ります。その順序付けられた実装ステップ、インターフェース、エッジケース、ロギング、受け入れ基準、および検証を要件として扱います。TaskGet に短い要約が含まれているという理由だけで、新しいアプローチに置き換えないでください。フェーズの指示が現在のコードまたはプロジェクトのコンテキストと矛盾する場合は、停止して具体的なドリフトを報告します。ultra が事前に計画することを意図していたアーキテクチャ上の選択を、黙って行わないでください。

3.1.1: 要件整合性ゲートを実行する

動作を変更するタスクを in progress としてマークする前に:

1. 存在する場合は、計画の ## Requirements Reconciliation セクションを読みます。 選択された調査ソースへの引用を、埋め込まれた ## Research Context に対して解決します。これはコミットされた要件スナップショットとして残ります。 ライブの調査ファイルは、ステップ 0.2 のドリフト警告にのみ使用してください。明示的なリベースなしに、それを使ってタスク要件を変更しないでください。引用された他の権威あるソースから関連する箇所を再読します。
2. ソース優先順位の階層は、ユーザーまたはプロジェクトによって宣言されている場合にのみ適用します。ロードマップのテキストは、明示的に別段の宣言がない限り、詳細な契約ではなくスコープとして扱います。
3. タスクの提案された動作を、引用された要件と比較します。それらが明確に矛盾する場合は、ERROR [requirement-conflict] を出力し、タスクを保留のままにし、STOP します。手動モードでは、明確化を求めます。HANDOFF_MODE=1 では、プロンプトを表示しないでください。コーディネーターがタスクをルーティングできるように handoff_outcome: blocked_external を返し、実装の完了またはレビューを通知しないでください。 先に実装して、後から要件アーティファクトを書き換えないでください。
4. 動作が独立したセレクター、状態、モード、または入力形状に依存する場合は、タスクが該当するサポート対象の組み合わせをそれぞれ、検証、永続化、出力/遷移、および副作用にわたってカバーしていることを確認します。ある次元に関するルールから、別の次元に関する制限を推測しないでください。

古い計画に ## Requirements Reconciliation がない場合は、タスク、Original Request、コミットされた Research Context、プロジェクトルール、およびそれらが明示的に参照する権威あるソースから、このゲートを実行します。埋め込まれた Research Context は、そのライブのドリフトソースよりも依然として優先されます。無関係な調査に広げないでください。

3.2: in_progress としてマークする

TaskUpdate(taskId, status: "in_progress")

3.3: タスクを実装する

• 関連するファイルを読む
• 必要な変更を行う
• 既存のコードパターンに従う
• 計画にテストタスクが含まれていない限り、テストは行いません
• レポートや要約は行いません
• 要件、調査、ロードマップ、ルール、およびアーキテクチャのアーティファクトは、アクティブなタスクが所有アーティファクトの変更を明示的に要求しない限り、読み取り専用として扱います。これは、このワークフローで後ほど明示的に許可される事実的なコンテキストのメンテナンスを妨げませんが、それらの更新は、実装に合わせるためだけに動作要件を変更してはなりません。

3.4: 実装を検証する

• コードがコンパイル/実行されることを確認する
• 機能が動作することを検証する
• 当面の問題を修正する
• タスクに割り当てられた検証シナリオを実行します。代表的なリポジトリアーティファクトが契約を定義している場合は、合成フィクスチャだけに頼るのではなく、そのアーティファクトを主要なパスを通して実行します。

3.5: completed としてマークする

TaskUpdate(taskId, status: "completed")

3.6：計画エントリーポイントのチェックボックスを更新する

タスクの完了直後に、計画エントリーポイント（ultra では index.md）のチェックボックスを更新します。

# Before

- [ ] Task 1: Create user model

# After

- [x] Task 1: Create user model

これは必須です — チェックボックスには実際の進捗を反映してください。

• Edit ツールを使って - [ ] を - [x] に変更します
• 各タスクの完了直後に実行します
• 後で削除を提案する場合でも実行します
• 計画エントリーポイントを進捗の信頼できる情報源とします
• ultra のフェーズファイルに重複した進捗チェックボックスを追加または更新しないでください

ハンドオフ同期（手動モードのみ — HANDOFF_MODE が 1 の場合はスキップ）： Step 0.2 で Handoff タスク ID を抽出した場合は、handoff_push_plan を { taskId: <id>, planContent: <full updated plan text> } で呼び出して、チェックリストの進捗を同期します。ultra では、Step 0.2 で定義されたバンドルのシリアライズ形式を使用します。

3.7：必要に応じて解決済みの説明アーティファクトを更新する

実装中に以下のいずれかが発生した場合：

• 新しい依存関係／ライブラリを追加した
• 技術スタックを変更した（例：Redis の追加、ORM の切り替え）
• 新しい統合を追加した（例：Stripe、SendGrid）
• アーキテクチャ上の決定を行った

→ 変更を反映するため、解決済みの説明アーティファクト（paths.description、デフォルト：.ai-factory/DESCRIPTION.md）を更新します。

## Tech Stack

- **Cache:** Redis (added for session storage)

これにより、解決済みの説明アーティファクトを信頼できる情報源として維持できます。

3.7.1：プロジェクト構造が変わった場合は AGENTS.md と ARCHITECTURE.md を更新する

実装中に以下のいずれかが発生した場合：

• 新しいディレクトリまたはモジュールを作成した
• プロジェクト構造が大幅に変わった（新しい src/modules/、新しい API ルートディレクトリなど）
• 新しいエントリーポイントまたは主要ファイルを追加した

→ AGENTS.md を更新し、「Project Structure」ツリーと「Key Entry Points」テーブルを、新しいディレクトリ／ファイルが反映されるように更新します。

→ 解決済みのアーキテクチャアーティファクトを更新します。フォルダー構造のセクションに記載すべき新しいモジュールまたはレイヤーを追加した場合が対象です。

構造が実際に変わった場合にのみ更新してください — タスクごとに書き直す必要はありません。現在の構造マップにない新しいディレクトリが作成されたか確認してください。

3.8：コミットチェックポイントを確認する

計画にコミットチェックポイントがあり、現在のタスクがチェックポイントに該当する場合：

AskUserQuestion: ✅ Tasks <first>-<last> completed. This is a commit checkpoint. Ready to commit? Suggested message: "<conventional commit message>"

Options:
1. Yes, commit now (/aif-commit)
2. No, continue to next task
3. Skip all commit checkpoints

選択に応じた処理：

• はい、今コミットする → 提案されたメッセージを使って /aif-commit を呼び出し、次のタスクに進みます
• いいえ、次のタスクに進む → コミットせずに次のタスクに進みます
• すべてのコミットチェックポイントをスキップする → この /aif-implement の実行中、以降のすべてのチェックポイントでプロンプトを自動的にスキップし、次のタスクに直接進みます（毎回ユーザーが「いいえ、次のタスクに進む」を選択した場合と同じです）。この設定はコンテキスト内で記憶され、/clear または新しいセッションでリセットされます

3.9：次のタスクに進むか、一時停止する

Step 4：セッションの継続

進捗は TaskUpdate によって自動的に保存されます。

一時停止するには：

Current progress saved.

Completed: 4/8 tasks
Next task: #5 - Add pagination support

To resume later, run:
/aif-implement

再開するには（次のセッション）：

/aif-implement

→ 次に未完了のタスクを自動的に見つけます

Step 5：完了

ハンドオフ同期（手動モードのみ — HANDOFF_MODE が 1 の場合は完全にスキップ）： 計画の注釈から Handoff タスク ID を抽出しており、かつ HANDOFF_MODE が 1 ではない場合：

1. handoff_push_plan を { taskId: <id>, planContent: <final updated plan text> } で呼び出します。ultra ではバンドル全体をシリアライズします。
2. HANDOFF_SKIP_REVIEW が 1 の場合：handoff_sync_status を { taskId: <id>, newStatus: "done", sourceTimestamp: "<current UTC time in ISO 8601 format>", direction: "aif_to_handoff", paused: false } で呼び出します。
3. それ以外の場合：handoff_sync_status を { taskId: <id>, newStatus: "review", sourceTimestamp: "<current UTC time in ISO 8601 format>", direction: "aif_to_handoff", paused: true } で呼び出します。

すべてのタスクが完了したら：

## Implementation Complete

All 8 tasks completed.

Branch: feature/product-search
Plan artifact: .ai-factory/plans/feature-product-search.md
Files modified:
- src/services/search.ts (created)
- src/api/products/search.ts (created)
- src/types/search.ts (created)
Documentation: updated existing docs | created docs/<feature-slug>.md | skipped by user | warn-only (Docs: no/unset)

What's next?

1. 🔍 /aif-verify — Verify nothing was missed (recommended)
2. 💾 /aif-commit — Commit the changes directly

ROADMAP.md の進捗を確認する：

解決済みのロードマップアーティファクトが存在する場合：

1. それを読み取ります 1.1. 計画エントリーポイントに ## Roadmap Linkage があり、マイルストーンが none 以外の場合は、完了としてマークするマイルストーンにそのマイルストーンを優先します
2. 完了した作業が、未チェックのマイルストーンに該当するか確認します
3. 該当する場合は [x] にし、今日の日付を付けて Completed テーブルにエントリーを追加します
4. 完了としてマークしたマイルストーンをユーザーに伝えます

コンテキストのメンテナンス（アーティファクト）

具体的に記録すべき内容がある場合にのみ、この手順を実行します。

DESCRIPTION.md（このコマンドで更新可能）：

• この計画で新しい依存関係や統合が導入された場合、またはスタックが変更された場合は、解決済みの説明アーティファクトを、事実に基づく差分のみで更新します。
• 関連のないセクションは書き換えないでください。

ARCHITECTURE.md + AGENTS.md（このコマンドで更新可能）：

• 新しいモジュール／レイヤー／フォルダーが追加された場合（または依存関係のルールが変更された場合）は、新しい構造と制約を反映するよう、解決済みのアーキテクチャアーティファクトを更新します。
• AGENTS.md の構造マップやエントリーポイントを管理している場合、それらが実際の状態と異なるようになったときにのみ更新します。

ROADMAP.md（限定的に更新可能）：

• 明確な根拠がある場合、このコマンドでマイルストーンの完了を記録できます。
• マイルストーンとの対応が曖昧な場合は、WARN [roadmap] ... を出力し、担当者向けのコマンドを提案します。
  • /aif-roadmap check
  • または /aif-roadmap <short update request>

RULES.md（このコマンドでは更新不可）：

• /aif-implement から、解決済みの paths.rules_file アーティファクトを編集してはいけません。
• 実装中に繰り返し適用できる慣習や注意点を見つけた場合は、ルール候補を最大3件提案し、ユーザーに /aif-rules から追加するよう依頼します。
• /aif-rules を自動的に実行してはいけません（ユーザーが実行します）。

ルール候補がある場合：

AskUserQuestion: Capture new project rules in the resolved RULES.md artifact?

Options:
1. Yes — output `/aif-rules ...` commands (recommended)
2. No — skip

ドキュメントポリシーの確認（完了後、計画の整理前）：

計画のエントリーポイントにある Docs: yes/no の設定を確認します。

計画の設定が Docs: yes の場合：

AskUserQuestion: Documentation checkpoint — how should we document this feature?

Options:
1. Update existing docs (recommended) — invoke /aif-docs
2. Create a new feature doc page — invoke /aif-docs with feature-page context
3. Skip documentation

対応方法：

• オプション1 → /aif-docs を実行して、完了した作業に基づき README／ドキュメントを更新します
• オプション2 → コンテキストを指定して /aif-docs を実行し、docs/<feature-slug>.md を作成します。セクション（概要、使い方／ユーザー向けの動作、設定、API／CLI の変更、例、トラブルシューティング、関連項目）を含め、README のドキュメント一覧表にリンクを追加します
• オプション3 → /aif-docs を実行せず、WARN [docs] Documentation skipped by user を出力します

計画の設定が Docs: no または未設定の場合：

• 必須のドキュメント確認プロンプトを表示しないでください
• /aif-docs を自動的に実行しないでください
• WARN [docs] Docs policy is no/unset; skipping documentation checkpoint を出力します

完了時の最終出力には、必ずドキュメントの結果を含めてください：

• Documentation: updated existing docs
• Documentation: created docs/<feature-slug>.md
• Documentation: skipped by user
• Documentation: warn-only (Docs: no/unset)

完了後の計画アーティファクトの扱い：

• 解決済みの高速プランのパス（/aif-plan fast で作成したもの）の場合：

  AskUserQuestion: Would you like to delete the resolved fast plan file? (It's no longer needed)
  
  Options:
  1. Yes, delete it
  2. No, keep it
  

  選択内容に基づく対応：

  • 「はい、削除します」→ ファイルを削除します：

    rm <resolved fast plan path>
    

  • 「いいえ、残します」→ ファイルはそのままにし、次の手順に進みます

• ブランチ名の付いたフルファイルまたはウルトラバンドルディレクトリの場合：

  • そのまま残します。作業内容の記録となります
  • ユーザーは必要に応じてマージ前に削除できます

Git ワークツリー内で実行されているか確認します：

ワークツリーのコンテキストを検出します：

# If .git is a file (not a directory), we're in a worktree
[ -f .git ]

ワークツリー内で実行されている場合は、マージしてクリーンアップするか確認します：

You're working in a parallel worktree.

  Branch:    <current-branch>
  Worktree:  <current-directory>
  Main repo: <main-repo-path>

AskUserQuestion: Would you like to merge this branch into the configured base branch and clean up?

Options:
1. Yes, merge and clean up (recommended)
2. No, I'll handle it manually

選択内容に基づく対応：

• 「はい、マージしてクリーンアップします」→ 以下のワークツリーマージ手順に従います
• 「いいえ、自分で対応します」→ 次のリマインダーを表示します：

  To merge and clean up later:
    cd <main-repo-path>
    git merge <branch>
    /aif-plan --cleanup <branch>
  

ワークツリーのマージ

1. すべての変更がコミット済みであることを確認します — git status を確認します。未コミットの変更がある場合は、先に /aif-commit を実行するよう提案し、完了を待ちます。

2. リポジトリのルートパスを取得します：

   MAIN_REPO=$(git rev-parse --git-common-dir | sed 's|/\.git$||')
   BRANCH=$(git branch --show-current)
   

3. リポジトリのルートに移動します：

   cd "${MAIN_REPO}"
   

4. ブランチをマージします：

   git checkout <configured-base-branch>
   git pull origin <configured-base-branch>
   git merge "${BRANCH}"
   

   マージコンフリクトが発生した場合：

   ⚠️  Merge conflict detected. Resolve manually:
     cd <main-repo-path>
     git merge --abort   # to cancel
     # or resolve conflicts and git commit
   

   → ここで停止し、クリーンアップを続行しないでください。

5. ワークツリーとブランチを削除します（マージが成功した場合のみ）：

   git worktree remove <worktree-path>
   git branch -d "${BRANCH}"
   

6. 確認します：

   ✅ Merged and cleaned up!
   
     Branch <branch> merged into <configured-base-branch>.
     Worktree removed.
   
   You're now in: <main-repo-path> (<configured-base-branch>)
   

→ 停止 — ワークツリーのマージと削除が完了しました。これ以上の手順は不要です。

最終ステップ — 検証またはコミット

AskUserQuestion: All tasks complete. What's next?

Options:
1. Verify first — Run /aif-verify to check completeness (recommended)
2. Skip to commit — Go straight to /aif-commit

選択に応じて：

• 「先に検証」→ /aif-verify を実行 → 完了後、以下のコンテキストのクリーンアップに進みます
• 「コミットに進む」→ /aif-commit を実行 → 完了後、以下のコンテキストのクリーンアップに進みます

コンテキストのクリーンアップ（検証またはコミット後）：

必要に応じて、ユーザーにコンテキスト領域を解放するよう提案します：/clear（完全にリセット）または /compact（履歴を圧縮）。

重要：サマリーレポート、分析ドキュメント、締めくくりのタスクは一切作成しないでください。

コマンド

実装を開始／再開する

/aif-implement

次の未完了タスクから続行します。

利用可能なプランを一覧表示する

/aif-implement --list

解決済みの fast/fix プランのパスと、現在のブランチにある full/ultra アーティファクト（連番を含む）を一覧表示してから、実装せずに終了します。

明示的なプランアーティファクトを使用する

/aif-implement @my-custom-plan.md
/aif-implement @.ai-factory/plans/feature-user-auth.md status
/aif-implement @.ai-factory/plans/feature-user-auth status

自動検出やブランチ／デフォルトのアーティファクトの代わりに、指定されたプランファイル、ultra ディレクトリ、または ultra の index.md を使用します。

インライン実装（プランなし）

/aif-implement --without-plan add GET /healthz endpoint returning {"status":"ok"}
/aif-implement --without-plan rename LogLevel.VERBOSE to LogLevel.TRACE --docs=yes

プランファイルを使わず、小規模なタスクを一度に実行します。@plan-file、status、タスク ID とは併用できません。FIX_PLAN.md やパッチは作成しません。デフォルトのドキュメントポリシーは warn です。ドキュメントのチェックポイントを実行するには --docs=yes、警告を表示しないようにするには --docs=no を渡します。全体の流れについては Step 0.inline を参照してください。

特定のタスクから開始する

/aif-implement 5

タスク #5 から開始します（スキップや再実行に便利です）。

ステータスのみを確認する

/aif-implement status

実行せずに進捗を表示します。

実行ルール

必ず行うこと：

• ✅ 一度に1つのタスクを実行する
• ✅ 作業を始める前にタスクを in_progress にする
• ✅ 完了後にタスクを completed にする
• ✅ 既存のコード規約に従う
• ✅ /aif-best-practices のガイドライン（命名、構造、エラー処理）に従う
• ✅ タスクの説明に記載されたファイルを作成する
• ✅ タスクに記載されたエッジケースに対応する
• ✅ タスクが不明確な場合は中断して確認する

禁止事項：

• ❌ タスクリストに明記されていない限り、テストを書かない
• ❌ レポートファイルを作成しない
• ❌ サマリードキュメントを作成しない
• ❌ プランにないタスクを追加しない
• ❌ ユーザーの許可なくタスクをスキップしない
• ❌ 未完了のタスクを完了済みとしてマークしない
• ❌ ファイルの配置やモジュール境界に関する、解決済みのアーキテクチャアーティファクトの規約に違反しない

アーティファクトの所有範囲

• このコマンドが主に管理するもの：タスクの実行状態とプランの進捗チェックボックス。
• 更新が許可されるコンテキストアーティファクト：解決済みの説明アーティファクト、解決済みのアーキテクチャアーティファクト、および実装の根拠によって妥当性が示される場合の、解決済みのロードマップアーティファクトにおけるロードマップのマイルストーン完了状況。
• このコマンドでデフォルトで読み取り専用となるコンテキスト：解決済みの paths.rules_file、設定済みの paths.research、およびプランのエントリーポイントからリンクされた特定の調査ソース。
• コンテキストゲートの指摘事項は WARN／ERROR の出力のみで伝えてください。これは、以下で定める詳細な実装ログの必須ルールに代わるものではありません。

進捗表示の形式、ブロッカーへの対応、セッション継続の例、および全体の流れの例については、references/IMPLEMENTATION-GUIDE.md を参照してください。

重要なルール

1. タスクリストにテストタスクが明記されていない限り、テストを書かないでください
2. 完了後にレポートやサマリードキュメントを作成しないでください
3. 作業を始める前に必ずタスクを in_progress にしてください
4. 作業を終えた後は必ずタスクを completed にしてください
5. プランファイルのチェックボックスを必ず更新してください — タスク完了後、直ちに - [ ] → - [x] に変更してください
6. 進捗を保持してください — タスクの状態はセッションをまたいで維持されます
7. 一度に1つのタスクだけに取り組んでください — 現在のタスクにのみ集中してください

重要：ログの要件

コードを実装する際は、必ず詳細なログを追加してください。 ログのガイドライン、パターン、管理要件については、references/LOGGING-GUIDE.md を読んでください。

主なルール：関数の開始／終了、状態の変化、外部呼び出し、エラーのコンテキストをログに記録してください。構造化ログと、設定可能なログレベル（LOG_LEVEL 環境変数）を使用してください。

「コードをすっきりさせる」ためにログを省略しないでください。実装中は詳細なログが必須ですが、必ず設定可能にしてください。