spec-runner 1.0.7 → 1.0.8

package/templates/.spec-runner/steps//346/206/262/347/253/240.md

@@ -1,74 +1,95 @@
-> **Phase 0: CHARTER（憲章策定）**成果物は **`docs/01_憲章/憲章.md`** のみ（spec.md セクション 2 に準拠）。
-> **初回またはプロジェクト変更時**: **初期化**（`.spec-runner/scripts/setup/init-project.sh`）で、テストコマンド・命名規則・必須ドキュメントを対話しながら設定できる。設定は **`.spec-runner/project.json` に集約**される。
+---
+step_id: charter
+phase: 0
+primary_output: docs/01_憲章/憲章.md
+---
 
-## フォルダの作成
+# 憲章策定（Phase 0: CHARTER）
 
-- **`docs/` や `docs/01_憲章/` が存在しない場合**: このフェーズで **`docs/01_憲章/` を新規作成**し、その中に `憲章.md` を配置する。spec-runner はフェーズごとにフォルダを1つずつ作っていく流れを想定している。
-- **他フェーズのフォルダ（`docs/02_ドメイン設計/` 等）が存在する場合でも、憲章策定時はそれらの既存ドキュメントからプロジェクト内容を推測しないこと。**憲章はユーザー入力と対話のみで策定**し、既存ドキュメントに合わせて書き換えない。
+**やること**: `docs/01_憲章/憲章.md` のプロジェクト憲章を作成・更新する。spec.md セクション 2（Phase 0）に準拠する。
+
+| 項目 | 内容 |
+|------|------|
+| **成果物** | `docs/01_憲章/憲章.md` のみ |
+| **動的設定** | 命名規則・必須ドキュメント・テストコマンドは **`.spec-runner/project.json` を AI が直接編集**して上書き |
+| **テンプレ** | 無い場合は `.spec-runner/templates/憲章.md` から生成してから埋める |
 
 ## ユーザー入力
 
+`$ARGUMENTS`（空でなければ必ず考慮）
+
 ```text
 $ARGUMENTS
 ```
 
-（空でない場合）処理を進める前にユーザー入力を**必ず**考慮すること。
+## 前提条件
 
-## 概要
+| 状況 | 行動 |
+|------|------|
+| `docs/` や `docs/01_憲章/` が無い | このフェーズで **`docs/01_憲章/` を新規作成**し、その中に `憲章.md` を置く |
+| `docs/01_憲章/憲章.md` が無い | テンプレから生成してから埋める（上記テンプレパス） |
+
+## 禁止
 
-**`docs/01_憲章/憲章.md`** のプロジェクト憲章を更新する。このファイルは角括弧のプレースホルダ（例: `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`）を含む場合がある。作業内容は (a) 具体的な値を収集・導出する、(b) テンプレートを正確に埋める、(c) 変更を依存成果物に反映させる、の三つである。
+- **他フェーズのフォルダ**（`docs/03_ドメイン設計/` 等）が既にあっても、**その既存ドキュメントからプロジェクト内容を推測しない**。憲章は**ユーザー入力と対話のみ**で策定し、既存ドキュメントに合わせて書き換えない。
+
+## 概要
 
-**注**: `docs/01_憲章/憲章.md` がまだない場合は、spec.md の Phase 0 テンプレート（目的・ビジョン、非交渉要件、技術スタック、投資判断、スコープ外、ガバナンス）に沿って新規作成する。
+- 角括弧プレースホルダ（例: `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`）を (a) 収集・導出 (b) テンプレを正確に埋める (c) 依存成果物へ反映、の三つで進める。
+- まだ無い場合は spec.md Phase 0 テンプレ（目的・ビジョン、非交渉要件、技術スタック、投資判断、スコープ外、ガバナンス）に沿って新規作成する。
 
-### 実行フロー
+## 実行フロー
 
-1. **既存の憲章を読み込む**: `docs/01_憲章/憲章.md` が**存在する場合のみ**読み、`[ALL_CAPS_IDENTIFIER]` 形式のプレースホルダをすべて特定する。**存在しない場合は**、spec.md の Phase 0 テンプレートに沿って新規作成する（上記「フォルダの作成」に従い `docs/01_憲章/` を作成してから `憲章.md` を書く）。**重要**: ユーザーがテンプレートより少ない/多い原則を求める場合がある。数が指定されていればそれに従い、一般的なテンプレートに沿って文書を更新する。
+1. **既存憲章の読み込み**  
+   `docs/01_憲章/憲章.md` が**ある場合のみ**読み、`[ALL_CAPS_IDENTIFIER]` 形式のプレースホルダをすべて特定。**無い場合**は Phase 0 テンプレに沿って新規作成（フォルダ作成ルールに従う）。  
+   **重要**: ユーザーがテンプレより少ない/多い原則を求める場合がある。数が指定されていればそれに従い、一般的なテンプレに沿って更新する。
 
-2. **プレースホルダへの値の収集・導出**:
-   - ユーザー入力（会話）で値が与えられていればそれを使う
-   - なければ既存リポジトリ（README・docs・過去の憲章）から推測する
-   - ガバナンスの日付: `RATIFICATION_DATE` は当初の採択日（不明なら質問するか TODO）、`LAST_AMENDED_DATE` は変更があれば今日、なければ前回のまま
-   - `CONSTITUTION_VERSION` はセマンティックバージョニングで増やす:
-     - MAJOR: 後方互換のないガバナンス/原則の削除・再定義
-     - MINOR: 新規原則/セクションの追加または重要な拡張
-     - PATCH: 明確化・表現・誤字修正・意味を変えない調整
-   - バージョン上げの種類が曖昧な場合は、確定前に理由を提示する
+2. **プレースホルダへの値の収集・導出**
+   - ユーザー入力（会話）で与えられていればそれを使う
+   - 不明は **推測で確定しない**。本文に **`[要確認: ...]`**（例: `[要確認: PROJECT_NAME（正式名称）]`）
+   - ガバナンス日付: `RATIFICATION_DATE` は採択日（不明なら質問か TODO）、`LAST_AMENDED_DATE` は変更があれば今日、なければ前回のまま
+   - `CONSTITUTION_VERSION` はセマンティック:
+     - **MAJOR**: 後方互換のないガバナンス/原則の削除・再定義
+     - **MINOR**: 新規原則/セクション追加または重要な拡張
+     - **PATCH**: 明確化・表現・誤字・意味を変えない調整
+   - 種類が曖昧なら確定前に理由を提示
 
-3. **更新後の憲章文案を作成**:
-   - すべてのプレースホルダを具体テキストで置き換える（意図的に残すスロット以外は角括弧を残さない。残す場合は理由を明記する）
-   - 見出し階層を維持する。コメントは置き換え後は削除してよい（説明になっている場合は残す）
-   - 各原則セクション: 簡潔な名前・非交渉ルールをまとめた段落（または箇条書き）・理由が自明でなければ明示
-   - ガバナンスセクションに改正手続き・バージョン方針・準拠レビューの期待を記載する
+3. **更新後の憲章文案**
+   - プレースホルダは具体テキストで置換（意図的スロット以外は角括弧を残さない。残す場合は理由を明記）
+   - 見出し階層はテンプレと同一。コメントは置換後削除可（説明になっていれば残す）
+   - 各原則: 簡潔な名前・非交渉ルールの段落/箇条書き・理由が自明でなければ明示
+   - ガバナンス: 改正手続き・バージョン方針・準拠レビューの期待
 
-4. **整合性の伝播チェックリスト**（該当フォルダが**既に存在する場合のみ**実施）:
-   - `docs/02_ドメイン設計/` や `docs/03_アーキテクチャ/` が存在するときだけ、それらの文書が更新した憲章の原則と矛盾していないか確認する。存在しないフェーズのフォルダは無視する。
-   - README.md や spec-runner のガイダンスに、変更した原則への参照更新が必要であれば案内する
+4. **整合性の伝播**（該当フォルダが**既に存在する場合のみ**）
+   - `docs/03_ドメイン設計/` や `docs/04_アーキテクチャ/` があれば、憲章原則と矛盾がないか確認。存在しないフェーズは無視
+   - README / spec-runner ガイダンスで原則参照の更新が必要なら案内
 
-5. **最終出力前の検証**:
-   - 説明のない角括弧トークンが残っていない
-   - バージョン行が変更内容と一致
-   - 日付は ISO 形式 YYYY-MM-DD
-   - 原則は宣言的・テスト可能で、曖昧な表現（「should」は必要に応じて MUST/SHOULD と理由に置き換える）がない
+5. **最終検証**（成果物・検証も参照）
 
-6. 完成した憲章を **`docs/01_憲章/憲章.md`** に上書きする。**憲章ファイルの先頭に HTML コメントの「同期影響レポート」や `status: reviewed` は付けない**。レビュー状態は `.spec-runner/phase-locks.json` のみで管理する。
+6. **書き込み**  
+   完成した憲章を **`docs/01_憲章/憲章.md`** に上書き。**憲章先頭に HTML コメントの「同期影響レポート」や `status: reviewed` は付けない**（`.spec-runner/phase-locks.json` のみで管理）。
 
-7. **ユーザーへの最終サマリ**:
-   - 新バージョンとバージョン上げの理由
+7. **ユーザーへの最終サマリ**
+   - 新バージョンと上げた理由
    - 手動フォローアップが必要なファイル
-   - 推奨コミットメッセージ（例: `docs: 憲章を vX.Y.Z に改正（原則追加とガバナンス更新）`）
+   - 推奨コミットメッセージ例: `docs: 憲章を vX.Y.Z に改正（原則追加とガバナンス更新）`
 
-### 書式・スタイル
+## 成果物・検証
 
-- 見出しはテンプレートと同一（レベルを上げ下げしない）
-- 理由は 100 文字以内を目安に折り返すが、不自然な改行は避ける
-- セクション間は空行 1 行
-- 行末の空白を避ける
+- [ ] 説明のない角括弧トークンが残っていない
+- [ ] バージョン行が変更内容と一致
+- [ ] 日付は ISO `YYYY-MM-DD`
+- [ ] 原則は宣言的・テスト可能。曖昧な「should」は必要に応じ MUST/SHOULD と理由へ
 
-ユーザーが一部だけ更新（例: 1 原則の修正）を依頼した場合も、検証とバージョン決定は行う。
+ユーザーが一部だけ更新を依頼した場合も、検証とバージョン決定は行う。  
+欠けている重要情報（例: 批准日が本当に不明）は `TODO(<フィールド名>): 説明` を本文に挿入し、サマリでフォローアップを案内。  
+**新規テンプレは作らない**。常に **`docs/01_憲章/憲章.md`** を操作する。
 
-重要な情報が欠けている場合（例: 批准日が本当に不明）は `TODO(<フィールド名>): 説明` を本文に挿入し、ユーザーへのサマリでフォローアップを案内する。
+## 付録: 書式・スタイル
 
-新規テンプレートは作らない。常に **`docs/01_憲章/憲章.md`** を操作する。
+- 見出しはテンプレと同一（レベルを上げ下げしない）
+- 理由は 100 文字目安で折り返すが、不自然な改行は避ける
+- セクション間は空行 1 行、行末空白を避ける
 
 ---
-完了したら次のステップに進む。
+**次**: 完了後、次のステップへ進む。

package/templates/.spec-runner/steps//346/233/226/346/230/247/343/201/225/350/247/243/346/266/210.md

@@ -1,159 +1,99 @@
+---
+step_id: clarify
+phase: 3
+note: UC 仕様の前後で曖昧さを解消
+---
+
+# 曖昧さ解消（品質フロー）
 
-> **曖昧さ解消**（品質フロー）Phase 3（UC 仕様書）の前後で、曖昧な箇所を 1 問ずつ解消して文書に反映します。
+**やること**: Phase 3（UC 仕様）の曖昧さ・不足決定を検出し、**対話で 1 問ずつ**解消して仕様ファイルに反映する。
+
+| 項目 | 内容 |
+|------|------|
+| **タイミング** | 「実装計画」の**前**に完了想定。ユーザーがスキップする場合は警告のうえ進めてよい |
+| **仕様パス** | `FEATURE_SPEC` = `docs/02_ユースケース仕様/<カテゴリ>/UC-N-xxx.md` |
+| **判断ログ（任意）** | `FEATURE_DIR/判断記録/UC-N-MMDD-題名.md`。テンプレ: `.spec-runner/templates/UC-N-MMDD-判断記録テンプレ.md`。横断は `docs/04_アーキテクチャ/設計判断記録/` |
 
 ## ユーザー入力
 
+`$ARGUMENTS`（空でなければ必ず考慮）。優先付けの文脈にも使う。
+
 ```text
 $ARGUMENTS
 ```
 
-（空でない場合）処理を進める前にユーザー入力を**必ず**考慮すること。
-
-## 概要
-
-目的: 現在の機能仕様の曖昧さや不足している決定事項を検出し、解消した内容を仕様ファイルに直接記録する。
-
-注意: この曖昧さ解消は「実装計画」を実行する**前**に完了させる想定。ユーザーが明示的にスキップする場合（例: 探索的スパイク）は警告のうえ進めてよい。
-
-### 実行手順
-
-1. リポジトリルートから `.spec-runner/scripts/lib/uc-context.sh --json --paths-only` を**1回**実行する。現在ブランチが feature/UC-NNN-xxx であること。最小限の JSON から以下をパースする:
-   - `FEATURE_SPEC`（docs/05_ユースケース仕様/<カテゴリ>/UC-NNN-xxx.md）
-   - `FEATURE_DIR`（カテゴリフォルダ。実装方針・タスクは UC の .md の一番下に記載）
-   - JSON のパースに失敗したら中止し、「仕様策定」で UC ブランチを作成するか、feature/UC-NNN-xxx にチェックアウトするよう案内する
-   - 引数にシングルクォートを含む場合はエスケープ（例: 'I'\''m Groot'）またはダブルクォートを使う
-
-2. 現在の仕様ファイルを読み込む。以下の分類で曖昧さ・カバレッジをスキャンし、各カテゴリに Clear / Partial / Missing を付ける。優先度付け用の内部カバレッジマップを作成する（質問がない場合以外は生のマップは出力しない）。
-
-   **機能スコープと振る舞い**
-   - コアのユーザー目標と成功基準
-   - スコープ外の明示
-   - ユーザーロール・ペルソナの区別
-
-   **ドメインとデータモデル**
-   - エンティティ・属性・リレーション
-   - 識別子と一意性ルール
-   - ライフサイクル/状態遷移
-   - データ量・スケールの仮定
-
-   **インタラクションと UX フロー**
-   - 重要なユーザージャーニー/シーケンス
-   - エラー/空/ローディング状態
-   - アクセシビリティ・ローカライズの注記
-
-   **非機能品質属性**
-   - 性能（レイテンシ・スループット目標）
-   - スケーラビリティ（水平/垂直・上限）
-   - 信頼性・可用性（稼働率・復旧の期待）
-   - 観測性（ログ・メトリクス・トレース）
-   - セキュリティ・プライバシー（認証/認可・データ保護・脅威の仮定）
-   - コンプライアンス・規制（該当する場合）
-
-   **連携と外部依存**
-   - 外部サービス/API と障害モード
-   - データインポート/エクスポート形式
-   - プロトコル・バージョニングの仮定
-
-   **エッジケースと障害処理**
-   - ネガティブシナリオ
-   - レート制限・スロットリング
-   - 競合解決（例: 同時編集）
-
-   **制約とトレードオフ**
-   - 技術的制約（言語・ストレージ・ホスティング）
-   - 明示的なトレードオフや却下した代替案
-
-   **用語と一貫性**
-   - 正規の用語集
-   - 避ける同義語・非推奨語
-
-   **完了のシグナル**
-   - 受入基準のテスト可能性
-   - 測定可能な Done の指標
-
-   **その他・プレースホルダ**
-   - TODO・未解決の決定
-   - 定量化されていない曖昧な形容詞（「堅牢」「直感的」など）
-
-   Partial または Missing のカテゴリには、次の場合を除き質問候補を追加する:
-   - 解消しても実装・検証戦略が大きく変わらない
-   - 情報は計画フェーズに回す方がよい（内部でメモ）
-
-3. 候補となる確認質問の優先キューを内部で生成する（最大 5 問）。一度に全部は出さない。制約:
-   - セッション全体で最大 5 問
-   - 各質問は「2〜5 個の択一選択」または「1 語/短いフレーズ（5 語以内）」で答えられること
-   - 回答がアーキテクチャ・データモデル・タスク分解・テスト設計・UX・運用準備・コンプライアンス検証に大きく影響する質問だけ含める
-   - カテゴリのバランスをとり、未解決の影響の大きい領域を優先する
-   - 既に答え済み・ trivial なスタイル・計画レベルの実行詳細は除外（正確性を阻害しない限り）
-   - 下流の手戻りリスクを減らす・受入テストのずれを防ぐ質問を優先
-   - 5 カテゴリ以上未解決なら、(影響 × 不確実性) で上位 5 つを選ぶ
-
-4. **逐次質問ループ（対話）**:
-   - 一度に**1 問だけ**提示する
-   - 択一形式の場合:
-     - 全選択肢を分析し、プロジェクトタイプのベストプラクティス・類似実装のパターン・リスク低減・仕様上の目標/制約に合う**最適な選択肢**を決める
-     - **推奨**を冒頭で理由付き（1〜2 文）で示す。形式: `**推奨:** 選択肢 [X] - <理由>`
-     - 続けてマークダウン表で全選択肢を表示する
-     - 表の後に「選択肢の文字（例: A）で返答するか、'yes' または 'recommended' で推奨を採用するか、独自の短い回答を入力できます」と書く
-   - 短答形式（意味のある離散選択肢がない場合）:
-     - ベストプラクティスと文脈に基づいて**提案回答**を出す。形式: `**提案:** <回答> - <簡潔な理由>`
-     - 「形式: 短答（5 語以内）。'yes' または 'suggested' で提案を採用するか、独自の回答を入力できます」と出力する
-   - ユーザーが回答したら:
-     - "yes" / "recommended" / "suggested" なら、先の推奨/提案を回答として採用する
-     - それ以外は、選択肢のいずれかに対応しているか、5 語以内かを確認する
-     - 曖昧なら同一質問内で簡潔に聞き直す（質問数は増やさない）
-     - 問題なければ作業用メモリに記録し（まだディスクには書かない）、キューから次の質問へ進む
-   - 次のいずれかで質問を打ち切る: 重要な曖昧さが早く解消された / ユーザーが「完了」「十分」「もういい」などと合図 / 5 問に達した
-   - 今後の質問を事前に明かさない
-   - 最初から有効な質問がなければ、重要な曖昧さは検出されなかったと報告する
-
-5. **回答ごとの反映（増分更新）**:
-   - 仕様のメモリ上の表現とファイル内容を保持する
-   - このセッションで最初に反映する回答のとき:
-     - `## 解消事項` セクションが存在するか確認し、なければ仕様テンプレートに従い最上位の文脈/概要セクションの直後に作成する
-     - その下に `### Session YYYY-MM-DD`（今日）の小見出しがなければ作成する
-   - 採用後すぐに箇条書きを追加: `- Q: <質問> → A: <確定した回答>`
-   - 解消内容を最も適切なセクションに反映する:
-     - 機能の曖昧さ → 機能要件の箇条書きを更新または追加
-     - ユーザー操作/アクターの区別 → ユーザーストーリーまたはアクターに役割・制約・シナリオを追記
-     - データ形状/エンティティ → データモデルを更新（フィールド・型・リレーションを順序を保って追加）、制約を簡潔に記載
-     - 非機能制約 → 非機能/品質属性セクションに測定可能な基準を追加・修正（曖昧な形容詞を指標や目標に変換）
-     - エッジケース/ネガティブフロー → エッジケース/エラー処理の下に箇条書きを追加（該当サブセクションがなければ作成）
-     - 用語の衝突 → 仕様全体で用語を統一し、必要なら元の表現は「(旧: "X")」と一度だけ残す
-   - 解消により以前の曖昧な記述が無効になる場合は、重複せずその記述を置き換え、矛盾する古い記述を残さない
-   - コンテキスト消失を防ぐため、**各反映の直後に**仕様ファイルを保存する（上書き）
-   - 書式を崩さず、無関係なセクションの順序や見出し階層を保つ
-   - 追記は最小限でテスト可能にし、叙述の拡散を避ける
-
-6. **検証（各書き込み後および最終）**:
-   - 解消セッションには採用した回答ごとに 1 箇条（重複なし）
+## 実行フロー
+
+1. **JSON**  
+   `.spec-runner/spec-runner.sh 次のステップ --json` を **1 回**。`feature/UC-N-xxx`。`FEATURE_SPEC`・`FEATURE_DIR` を使用。実装方針・タスクは **UC .md の一番下**。  
+   JSON パース失敗 → 中止。「仕様策定」で UC ブランチ作成または checkout を案内。  
+   シングルクォートはエスケープ（例: `'I'\''m Groot'`）。
+
+2. **スキャン**  
+   付録のカテゴリで曖昧さ・カバレッジをスキャンし各カテゴリに Clear / Partial / Missing。内部マップ作成（質問がない場合以外は生マップは出さない）。  
+   Partial/Missing は **付録「質問候補の除外」** に該当しなければ質問候補へ。
+
+3. **質問キュー（最大 5 問）**  
+   一度に全部は出さない。制約:
+   - セッション合計 **最大 5 問**
+   - 各問は **2〜5 択** または **短答（5 語以内）**
+   - アーキテクチャ・データモデル・タスク・テスト・UX・運用・コンプライアンスに**大きく影響**するものだけ
+   - カテゴリのバランス、影響の大きい領域優先
+   - 既答・trivial・計画レベルの実行詳細は除外
+   - 5 カテゴリ以上未解決なら (影響×不確実性) で上位 5 つ
+
+4. **逐次質問ループ**
+   - **1 問ずつ**提示
+   - **択一**: 最適肢を分析 → `**推奨:** 選択肢 [X] - <理由>` → 表で全選択肢 → 「A で返答 / yes・recommended で推奨採用 / 短い独自回答可」
+   - **短答**: `**提案:** <回答> - <理由>` → yes・suggested で採用可
+   - 回答処理: yes/recommended/suggested → 採用。それ以外は択一対応・5 語以内を確認。曖昧は同一問内で聞き直し（問数増やさない）。OK ならメモリに記録（まだディスクに全面反映しない）
+   - 打ち切り: 重要曖昧が早く解消 / ユーザー「完了」「十分」等 / 5 問到達。今後の問は事前に明かさない。有効な問が無ければ「重要な曖昧は検出されなかった」と報告
+
+5. **回答ごとの反映（増分）**
+   - メモリとファイル内容を保持
+   - 初回反映時: `## 解消事項` が無ければ概要直後に作成。`### Session YYYY-MM-DD` を今日で作成
+   - 採用直後: `- Q: <質問> → A: <回答>` を追記
+   - 内容を適切セクションへ（機能→機能要件、操作→ストーリー/アクター、データ→データモデル、非機能→測定可能な基準、エッジ→エッジケース、用語→統一・旧表記は一度だけ (旧: "X")）
+   - 古い曖昧記述は置換し矛盾を残さない。**各反映の直後にファイル保存**。見出し階層維持。新規見出しは **`## 解消事項`**, **`### Session YYYY-MM-DD`** のみ可
+
+6. **検証（各書き込み後・最終）**
+   - 解消セッションは採用回答ごと 1 箇条（重複なし）
    - 質問数（採用分）≤ 5
-   - 更新したセクションに、解消したはずの曖昧なプレースホルダが残っていない
-   - 無効になった選択肢を削除したうえで、矛盾する記述が残っていない
-   - マークダウン構造は有効。新規見出しは `## 解消事項`, `### Session YYYY-MM-DD` のみ可
-   - 用語の一貫性: 更新した全セクションで同じ正規用語を使う
-
-7. 更新した仕様を `FEATURE_SPEC` に書き戻す。
-
-8. 完了報告（質問ループ終了または早期終了後）:
-   - 質問数と回答数
-   - 更新した仕様のパス
-   - 変更したセクション名の一覧
-   - 各カテゴリのカバレッジ概要表（Resolved / Deferred / Clear / Outstanding）
-   - Outstanding または Deferred が残っている場合、「実装計画」に進むか、後で再度「曖昧さ解消」を実行するかを推奨する
-   - 推奨する次のコマンド
-
-### 動作ルール
-
-- 意味のある曖昧さがない（または潜在的な質問の影響が小さい）場合:「正式な解消に値する重要な曖昧さは検出されませんでした」と返し、次に進むよう提案する
-- 仕様ファイルがない場合: 先に「仕様策定」を実行するよう案内する（ここでは新規仕様を作成しない）
-- 質問は合計 5 問を超えない（同一質問の聞き直しは新規質問に数えない）
-- 機能の明確さを妨げない限り、技術スタックの推測質問は避ける
-- ユーザーの早期終了（「ストップ」「完了」「進めて」など）を尊重する
-- カバレッジが十分で質問が不要な場合は、簡潔なカバレッジ概要（全カテゴリ Clear）を出して次へ進むよう提案する
-- 5 問に達した時点で未解決の重要カテゴリが残っている場合は、Deferred に理由付きで明示する
-
-優先付けの文脈: $ARGUMENTS
+   - 更新セクションに解消済みの曖昧プレースホルダが残っていない
+   - 矛盾なし、Markdown 有効、用語一貫
+
+7. **書き戻し**  
+   `FEATURE_SPEC` に保存
+
+8. **完了報告**  
+   質問数・回答数・仕様パス・変更セクション一覧・カテゴリカバレッジ表（Resolved / Deferred / Clear / Outstanding）。Outstanding/Deferred 残りは「実装計画」か再「曖昧さ解消」を推奨。次コマンドを明示
+
+## 動作ルール
+
+- 意味のある曖昧がない: 「正式な解消に値する重要な曖昧さは検出されませんでした」と次へ
+- 仕様ファイルがない: 「仕様策定」を案内（ここでは新規仕様を作らない）
+- 質問は合計 5 を超えない（聞き直しは新規に数えない）
+- 機能の明確さを妨げない限り技術スタックの推測質問は避ける
+- 「ストップ」「完了」「進めて」等を尊重
+- 質問不要なら簡潔なカバレッジ概要（全 Clear）で次へ
+- 5 問で未解決が残る場合は Deferred を理由付きで明示
+
+## 付録: スキャンカテゴリ
+
+| カテゴリ | 見ること |
+|----------|----------|
+| 機能スコープと振る舞い | コア目標・成功基準、スコープ外、ロール・ペルソナ |
+| ドメインとデータモデル | エンティティ・属性・リレ、ID・一意性、ライフサイクル、データ量仮定 |
+| インタラクションと UX | ジャーニー、エラー/空/ローディング、a11y・i18n |
+| 非機能 | 性能、スケール、信頼性・可用性、観測性、セキュリティ・プライバシー、コンプライアンス |
+| 連携と外部依存 | 外部 API・障害モード、I/O 形式、プロトコル仮定 |
+| エッジと障害 | ネガティブ、レート制限、競合解決 |
+| 制約とトレードオフ | 技術制約、却下した代替案 |
+| 用語と一貫性 | 正規用語、避ける同義語 |
+| 完了のシグナル | 受入のテスト可能性、測定可能な Done |
+| その他 | TODO、未解決決定、曖昧形容詞（堅牢・直感的等） |
+
+**質問候補から外す場合**: 解消しても実装・検証戦略が大きく変わらない / 情報は計画フェーズに回す方がよい（内部メモ）
 
 ---
-完了したら次のステップに進む。
+**次**: 完了後、次のステップへ進む。

package/templates/.spec-runner/templates/UC-N-MMDD-/345/210/244/346/226/255/350/250/230/351/214/262/343/203/206/343/203/263/343/203/227/343/203/254.md

@@ -0,0 +1,33 @@
+# 判断記録（UCごと）
+
+> ファイル名: `UC-N-MMDD-題名.md`（例: `UC-1-0317-要件解釈.md`）  
+> 置き場所: `docs/02_ユースケース仕様/<カテゴリ>/判断記録/`
+
+## 結論（Decision）
+
+- [要確認: 決定内容を一文で]
+
+## 背景（Context）
+
+- [要確認: なぜこの判断が必要になったか]
+
+## 選択肢（Options）
+
+- **案A**: [要確認: 説明]
+- **案B**: [要確認: 説明]
+- （任意）**案C**: [要確認: 説明]
+
+## 判断理由（Rationale）
+
+- [要確認: 採用理由（制約・トレードオフ）]
+
+## 影響範囲（Impact）
+
+- **仕様書**: `docs/02_ユースケース仕様/<カテゴリ>/UC-N-題名.md` のどの節に反映したか
+- **ドメイン**: 影響がある場合は `docs/03_ドメイン設計/` の更新点
+- **アーキ**: 横断判断なら `docs/04_アーキテクチャ/設計判断記録/` へ
+
+## 未解決（Open Questions）
+
+- [要確認: 未解決事項があれば]
+

package/templates/.spec-runner/templates/{UC-NNN- → UC-N-}/343/203/246/343/203/274/343/202/271/343/202/261/343/203/274/343/202/271/345/220/215.md

@@ -1,6 +1,4 @@
-# UC-NNN: {ユースケース名}
-
-status: draft
+# UC-N: {ユースケース名}
 
 ## 概要
 

package/templates/.spec-runner/templates/grade-history.json

@@ -0,0 +1,5 @@
+{
+  "_comment": "グレード履歴。インストール時に .spec-runner/grade-history.json へコピーされる（既にある場合はスキップ）。",
+  "current_grade": "LOOP1",
+  "history": []
+}

package/templates/.spec-runner/templates/phase-locks.json

@@ -0,0 +1,29 @@
+{
+  "_comment": "フェーズ完了状態の単一ソース。初期状態ではすべて未完了。レビュー状態もここで管理する。インストール時に .spec-runner/phase-locks.json へコピーされる（既にある場合はスキップ）。",
+  "charter": {
+    "completed": false,
+    "locked_at": null,
+    "reviewed_by": null
+  },
+  "domain": {
+    "completed": false,
+    "locked_at": null,
+    "reviewed_by": null
+  },
+  "architecture": {
+    "completed": false,
+    "locked_at": null,
+    "reviewed_by": null
+  },
+  "infra": {
+    "completed": false,
+    "locked_at": null,
+    "reviewed_by": null
+  },
+  "test_design": {
+    "completed": false,
+    "locked_at": null,
+    "reviewed_by": null
+  },
+  "uc_reviewed": []
+}

package/templates/.spec-runner/templates//343/203/211/343/203/241/343/202/244/343/203/263/343/203/242/343/203/207/343/203/253.md

@@ -0,0 +1,21 @@
+# ドメインモデル
+
+## 境界づけられたコンテキスト（Bounded Context）
+
+- [CONTEXT_1]: [CONTEXT_1_DESC]
+
+## 主要概念（高レベル）
+
+- [CONCEPT_1]
+- [CONCEPT_2]
+
+## 関係（ざっくりでよい）
+
+- [RELATION_1]
+- [RELATION_2]
+
+## 不変条件（Invariants）
+
+- [INVARIANT_1]
+- [INVARIANT_2]
+

package/templates/.spec-runner/templates//343/203/246/343/203/223/343/202/255/343/202/277/343/202/271/350/250/200/350/252/236/350/276/236/346/233/270.md

@@ -0,0 +1,16 @@
+# ユビキタス言語辞書
+
+## 用語（Terms）
+
+| 用語 | 定義 | 同義語/別名 | 例 | 備考 |
+|------|------|-------------|----|------|
+| [TERM_1] | [DEFINITION_1] | [SYNONYM_1] | [EXAMPLE_1] | |
+| [TERM_2] | [DEFINITION_2] | [SYNONYM_2] | [EXAMPLE_2] | |
+
+## 禁止語（Forbidden）
+
+同義語の乱立や解釈ズレを防ぐため、以下の語は使わない（または、使う場合はこの辞書に登録してからにする）。
+
+- [FORBIDDEN_1]（代替: [PREFERRED_1]）
+- [FORBIDDEN_2]（代替: [PREFERRED_2]）
+

package/templates/.spec-runner/templates//346/206/262/347/253/240.md

@@ -0,0 +1,51 @@
+# 憲章（プロジェクト憲章）
+
+## 基本情報
+
+- プロジェクト名: [PROJECT_NAME]（不明なら `[要確認: PROJECT_NAME]`）
+- 概要（1〜3行）: [SUMMARY]（不明なら `[要確認: SUMMARY]`）
+- 批准日（YYYY-MM-DD）: [RATIFICATION_DATE]（不明なら `[要確認: RATIFICATION_DATE]`）
+- 最終改正日（YYYY-MM-DD）: [LAST_AMENDED_DATE]（不明なら `[要確認: LAST_AMENDED_DATE]`）
+- バージョン: [CONSTITUTION_VERSION]（不明なら `[要確認: CONSTITUTION_VERSION]`）
+
+## 目的・ビジョン
+
+[VISION]
+
+## 非交渉要件（守るべき原則）
+
+### 原則1: [PRINCIPLE_1_NAME]
+
+- MUST: [PRINCIPLE_1_RULES]
+- 理由: [PRINCIPLE_1_RATIONALE]
+
+### 原則2: [PRINCIPLE_2_NAME]
+
+- MUST: [PRINCIPLE_2_RULES]
+- 理由: [PRINCIPLE_2_RATIONALE]
+
+## スコープ
+
+### 対象（In scope）
+
+- [IN_SCOPE_1]
+- [IN_SCOPE_2]
+
+### 対象外（Out of scope）
+
+- [OUT_OF_SCOPE_1]
+- [OUT_OF_SCOPE_2]
+
+## 技術スタック（暫定でよい）
+
+- 言語/ランタイム: [LANG_RUNTIME]
+- 主要フレームワーク: [FRAMEWORK]
+- データストア: [DATASTORE]
+- インフラ: [INFRA]
+
+## ガバナンス
+
+- 変更提案: [CHANGE_PROCESS]
+- レビューと批准: [REVIEW_PROCESS]
+- バージョン運用: セマンティックバージョニング（MAJOR/MINOR/PATCH）
+

package/templates/.spec-runner/templates//351/233/206/347/264/204.md

@@ -0,0 +1,46 @@
+# 集約
+
+> 重要: 各集約に **対応テーブル**（`docs/05_インフラ設計/schema.dbml` との対応）を必ず書く。
+
+## 集約一覧
+
+- [AGGREGATE_1]
+- [AGGREGATE_2]
+
+---
+
+## [AGGREGATE_1]
+
+### 概要
+
+[AGGREGATE_1_DESC]
+
+### エンティティ/値オブジェクト
+
+- エンティティ: [ENTITY_1]
+- 値オブジェクト: [VO_1]
+
+### 不変条件
+
+- [INVARIANT_1]
+
+### 対応テーブル（schema.dbml）
+
+| テーブル | 役割 | 備考 |
+|----------|------|------|
+| `table_name_1` | [ROLE_1] | |
+
+---
+
+## [AGGREGATE_2]
+
+### 概要
+
+[AGGREGATE_2_DESC]
+
+### 対応テーブル（schema.dbml）
+
+| テーブル | 役割 | 備考 |
+|----------|------|------|
+| `table_name_2` | [ROLE_2] | |
+