spec-runner 1.1.7 → 1.1.8

package/templates/.spec-runner/steps//345/210/206/346/236/220.md

@@ -1,106 +0,0 @@
----
-step_id: analyze
-phase: null
-readonly: true
-note: 任意フェーズで実行可能（読み取り専用）
----
-
-# 分析（品質フロー）
-
-**やること**: 任意フェーズで、**読み取り専用**で UC 仕様・憲章の一貫性・矛盾・カバレッジを分析し、構造化レポートを出力する（ファイルは変更しない）。必要に応じて `docs/work.md` の未解決更新を提案する。
-
-| 項目 | 内容 |
-|------|------|
-| **対象** | UC 仕様（## 実装方針・## タスク含む）、`docs/01_憲章/憲章.md` |
-| **憲章** | **非交渉**。憲章矛盾は **CRITICAL**。原則の無視・勝手な解釈変更は禁止。原則変更は憲章更新手続きで |
-
-## ユーザー入力
-
-`$ARGUMENTS`（空でなければ必ず考慮）。文末「文脈」にも。
-
-```text
-$ARGUMENTS
-```
-
-## 実行フロー
-
-### 1. コンテキスト初期化
-
-`.spec-runner/spec-runner.sh 次のステップ --json` を 1 回。`feature_spec`・`feature_dir` を使用。  
-**SPEC** = FEATURE_SPEC（**必須**）。実装方針・タスクは UC の「## 実装方針」「## タスク」。  
-無ければエラー中止。引数のシングルクォートはエスケープ。
-
-### 2. 段階的読み込み
-
-| ソース | 読む範囲 |
-|--------|----------|
-| UC 仕様 | 概要、機能/非機能要件、ユーザーストーリー、エッジケース |
-| ## 実装方針 | アーキテクチャ、データ参照、フェーズ、技術制約 |
-| ## タスク | タスク ID、説明、フェーズ、[P]、参照パス |
-| 憲章 | 原則検証用に全文 |
-
-### 3. 内部モデル（出力に生データを含めない）
-
-- 要件一覧（安定キー付与）
-- ユーザーストーリー/アクション一覧
-- タスク→要件/ストーリーのマッピング
-- 憲章ルールセット（MUST/SHOULD）
-
-### 4. 検出パス（所見は合計 **50 件まで**、残りはオーバーフロー要約）
-
-| ID | 内容 |
-|----|------|
-| A | 重複（ほぼ同一要件、統合候補） |
-| B | 曖昧さ（測定なし形容詞、TODO/TKTK/???/placeholder） |
-| C | 仕様不足（動詞のみ、受入なしストーリー、未定義ファイル参照タスク） |
-| D | 憲章整合（MUST 違反、ゲート欠落） |
-| E | カバレッジ（要件にタスク 0、孤児タスク、非機能のタスク漏れ） |
-| F | 不整合（用語ずれ、エンティティの有無矛盾、タスク順序矛盾、要件矛盾） |
-
-### 5. 重要度
-
-| レベル | 目安 |
-|--------|------|
-| CRITICAL | 憲章 MUST 違反、コア成果物欠落、基本機能を阻害するカバレッジゼロ |
-| HIGH | 重複・矛盾要件、曖昧なセキュリティ/性能、テスト不可能な受入 |
-| MEDIUM | 用語ずれ、非機能のタスク不足、エッジ仕様不足 |
-| LOW | 文体、軽微な重複 |
-
-### 6. レポート出力（ファイルに書かない）
-
-```markdown
-## 仕様分析レポート
-
-| ID | カテゴリ | 重要度 | 場所 | 概要 | 推奨対応 |
-|----|----------|--------|------|------|----------|
-```
-
-所見 1 行 1 件。ID はカテゴリ頭文字+連番。
-
-**カバレッジ概要表** | 要件キー | タスクあり | タスクID | 注記 |
-
-**憲章整合性の問題** / **未マッピングのタスク**（あれば）
-
-**メトリクス**: 要件数、タスク数、カバレッジ%、曖昧さ件数、重複件数、CRITICAL 件数
-
-### 7. 次のアクション
-
-- CRITICAL あり → 「実装」の前に解消推奨
-- LOW/MEDIUM のみ → 改善案のうえ進行可
-- 次コマンドを明示（仕様修正・実装方針追記・実装計画調整等）
-- 完了時に `.spec-runner/phase-locks.json` の `quality.analyzed.<scope>` に対象ドキュメントのベース名を追加する（scope: `charter` / `domain` / `architecture` / `uc`）
-
-### 8. 修正案オファー
-
-「上位 N 件について具体的な修正案を出しましょうか？」と尋ねる（自動適用しない）。
-
-## 運用原則
-
-- 高シグナル・最小トークン、段階的開示、所見表 50 行、再実行で同じ ID・件数
-
-## 文脈
-
-`$ARGUMENTS`
-
----
-**次**: 完了後、次のステップへ進む。

package/templates/.spec-runner/steps//345/256/237/350/243/205.md

@@ -1,80 +0,0 @@
----
-step_id: implement
-phase: 6
----
-
-# 実装（Phase 6: IMPLEMENTATION）
-
-**やること**: Phase 5 の **PENDING テストをグリーン**にする。**完了**はコードだけでなく **起動確認**（dev で `/` と主要画面）と **可能なら E2E 1 本グリーン**。あわせて `docs/work.md` のチェックボックスと検証結果を確定する。
-
-| 項目 | 内容 |
-|------|------|
-| **UC 配置** | カテゴリ内 **UC-N-xxx.md 1 本**。**## 実装方針**・**## タスク**（または **## タスク一覧**）は **一番下** |
-| **検証** | 完了は check.sh。テストは **`project.json` の `test_command.run`** が **exit 0** まで「完了」報告しない |
-
-## フォルダ構造
-
-| 種別 | ルール |
-|------|--------|
-| docs | リポジトリルート直下のみ |
-| アプリコード | **src/** 下（domain / infrastructure / application / app）。docs 隣に domain を置かない |
-| paths 例 | `"@/*": ["./src/*"]` |
-
-## ユーザー入力
-
-`$ARGUMENTS`（空でなければ必ず考慮）
-
-```text
-$ARGUMENTS
-```
-
-## 実行前チェック: hooks.before_implement
-
-- `extensions.yml` の `hooks.before_implement`（無ければスキップ、YAML 不正もスキップ）
-- `enabled: true` のみ。condition は評価しない
-- 任意: 表示のみ。必須: 実行して待つ
-
-## 実行フロー
-
-1. **JSON**  
-   `次のステップ --json`。`feature_dir`・`feature_spec`。
-
-2. **チェックリスト（FEATURE_DIR/checklists/ がある場合）**  
-   `- [ ]` / `- [x]` を数え表化。未完了 0 → PASS。未完了あり → 「このまま進めますか？ yes/no」で待つ。no で停止。yes で続行。
-
-3. **読込**  
-   FEATURE_SPEC **必須**。実装方針・タスクは UC 一番下。
-
-4. **プロジェクトセットアップ確認**
-   - **test_command.run** が無い/不適なら `project.json` を更新（1 本のコマンド）
-   - git なら .gitignore。Docker/ESLint/Prettier/Terraform/Helm 等に応じ ignore を確認・不足のみ追加
-   - 技術スタックは実装方針または package.json 等から
-
-5. **実装範囲**  
-   ## タスク と受入・フローから項目列挙。
-
-6. **実行**  
-   タスク順。UC のみなら受入・フローに沿い **テスト→コア→統合** 推奨。同一ファイルは順次。
-
-7. **ルールの目安**  
-   セットアップ →（必要なら）テスト先行 → モデル・サービス・EP → 統合 → 仕上げ
-
-8. **進捗・エラー**  
-   タスクごと報告。非並列失敗で停止。[P] は成功分続行。UC タスクの完了は `[x]`。
-
-9. **完了検証**
-   - 必須タスク完了・仕様一致
-   - **`test_command.run` の実行結果** が 0 になるまで完了報告禁止
-   - **起動確認（必須）**: dev で `/` と当該 UC の主要画面が 200 等。不可なら修正まで
-   - **E2E（推奨）**: `tests/e2e/` に該当 UC があればハッピーパス 1 本グリーンを目標。無ければユニット+起動で可
-
-10. **hooks.after_implement**  
-    あれば同様に表示/実行。
-
-## 次の UC・履歴整理
-
-次 UC やマージのタイミングはプロジェクト次第。**コミット・ブランチが欲しくなったら** AI に相談する。  
-**任意**: `.spec-runner/scripts/uc-next-start.sh`（`--yes` で確認省略）— **次 UC 用の仕様ひな形 `.md` のみ**作成（ブランチは作らない）。
-
----
-**次**: 完了後、次のステップへ。

package/templates/.spec-runner/steps//345/256/237/350/243/205/350/250/210/347/224/273.md

@@ -1,96 +0,0 @@
----
-step_id: implementation_plan
-phase: 3
-note: アーキテクチャ設計
----
-
-# 実装計画（アーキテクチャ）
-
-**やること**: `docs/04_アーキテクチャ/` に設計を置き、最新の UC 仕様に **実装方針を UC の .md の一番下（## 実装方針）** として反映する。あわせて `docs/work.md` の実装タスクを更新する。
-
-| 項目 | 内容 |
-|------|------|
-| **docs/02** | カテゴリフォルダ内に **UC-N-xxx.md を 1 本ずつ**。実装方針・タスクは **各 UC .md の一番下** |
-| **動的設定** | 必須ドキュメント・命名規則は **`.spec-runner/project.json` を AI が直接編集** |
-| **補足（任意）** | 必要に応じて `docs/05_インフラ設計`（schema.dbml 等）を作成 |
-
-## ユーザー入力
-
-`$ARGUMENTS`（空でなければ必ず考慮）
-
-```text
-$ARGUMENTS
-```
-
-## フォルダの作成
-
-| フェーズ | パス | 内容の例 |
-|----------|------|----------|
-| Phase 2 | `docs/04_アーキテクチャ/` | パターン選定・インフラ方針・命名・設計判断（`MMDD-題名.md`。年はフォルダ分け可） |
-| 任意 | `docs/05_インフラ設計/` | クラウド・ネットワーク・**schema.dbml**（必要時のみ） |
-| API 公開時 | `docs/06_API仕様/` | openapi.yaml（Gate 3 で参照） |
-
-## API 仕様（openapi.yaml）
-
-- **単一ソース**: `docs/06_API仕様/openapi.yaml`。型・クライアントはここから生成すると設計と一致。`tags` で分類、`$ref` 分割可。
-- **生成手段**: プロジェクト標準（openapi-generator / openapi-typescript / orval 等）。spec-runner は固定しない。
-
-## Phase 2（main/develop など）
-
-`docs/01_憲章/憲章.md` と `docs/03_ドメイン設計/` を読み、**`docs/04_アーキテクチャ/`** にパターン選定・インフラ方針・命名・設計判断記録を作成。フォルダが無ければこのフェーズで作成。
-
-## UC 上での計画（実装方針セクション）
-
-以下 1–4 を実行。
-
-1. **セットアップ**  
-   `.spec-runner/spec-runner.sh 次のステップ --json`。`feature_spec`・`feature_dir`。
-
-2. **文脈**  
-   FEATURE_SPEC（**必須**）、`docs/01_憲章/憲章.md`、UC の「## 実装方針」。UC 1 本で計画。
-
-3. **計画ワークフロー**
-   - 技術コンテキスト（不明は「要確認」）
-   - 憲章チェックを憲章から埋める
-   - ゲート評価（正当化されない違反は ERROR）
-   - **ファイル構成**: docs はルート直下。アプリコードは **src/**（憲章・アーキで決まっていれば従う）
-   - Phase 0: research.md は任意（要確認がある場合のみ）
-   - Phase 1: **data-model.md / contracts/ は任意**。正は 集約.md・schema.dbml・コード。API は openapi.yaml。必要なら FEATURE_DIR や docs/04 に追加可
-   - 設計後に憲章チェックを再評価
-
-4. **停止と報告**  
-   コマンドは Phase 2 計画の後で終了。FEATURE_SPEC・生成物を報告。
-
-## サブフェーズ詳細
-
-### Phase 0: 概要とリサーチ
-
-1. 技術コンテキストの「要確認」→ リサーチタスク、依存→ベストプラクティス、連携→パターンタスク
-2. リサーチタスク例:
-
-   ```text
-   技術コンテキストの各不明点について:
-     タスク: 「{機能文脈} 向けに {不明点} をリサーチする」
-   各技術選択について:
-     タスク: 「{ドメイン} における {技術} のベストプラクティスを調べる」
-   ```
-
-3. **research.md** に集約: 決定 / 理由 / 検討した代替案  
-   **成果物**: 要確認が解消された research.md
-
-### Phase 1: 設計と契約
-
-**前提**: research.md 完了（使う場合）
-
-1. 機能仕様からエンティティ抽出 → `data-model.md`（フィールド・リレ・バリデ・状態遷移）
-2. 外部 IF がある場合 → `/contracts/`（公開 API・CLI・Web 等）。純内部はスキップ可
-
-**成果物**: data-model / contracts / quickstart は**任意**。コードと 集約.md・openapi で足りなければ作る。
-
-## 重要ルール
-
-- 絶対パスを使用する
-- ゲート違反・未解消の確認事項は ERROR
-
----
-**次**: 完了後、次のステップへ進む。

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

@@ -1,95 +0,0 @@
----
-step_id: charter
-phase: 0
-primary_output: docs/01_憲章/憲章.md
----
-
-# 憲章策定（Phase 0: CHARTER）
-
-**やること**: `docs/01_憲章/憲章.md` のプロジェクト憲章を作成・更新する。spec.md セクション 2（Phase 0）に準拠する。あわせて `docs/work.md` の目的・受入条件・実装タスクを更新する。
-
-| 項目 | 内容 |
-|------|------|
-| **成果物** | `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/03_ドメイン設計/` 等）が既にあっても、**その既存ドキュメントからプロジェクト内容を推測しない**。憲章は**ユーザー入力と対話のみ**で策定し、既存ドキュメントに合わせて書き換えない。
-
-## 概要
-
-- 角括弧プレースホルダ（例: `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`）を (a) 収集・導出 (b) テンプレを正確に埋める (c) 依存成果物へ反映、の三つで進める。
-- まだ無い場合は spec.md Phase 0 テンプレ（目的・ビジョン、非交渉要件、技術スタック、投資判断、スコープ外、ガバナンス）に沿って新規作成する。
-
-## 実行フロー
-
-1. **既存憲章の読み込み**  
-   `docs/01_憲章/憲章.md` が**ある場合のみ**読み、`[ALL_CAPS_IDENTIFIER]` 形式のプレースホルダをすべて特定。**無い場合**は Phase 0 テンプレに沿って新規作成（フォルダ作成ルールに従う）。  
-   **重要**: ユーザーがテンプレより少ない/多い原則を求める場合がある。数が指定されていればそれに従い、一般的なテンプレに沿って更新する。
-
-2. **プレースホルダへの値の収集・導出**
-   - ユーザー入力（会話）で与えられていればそれを使う
-   - 不明は **推測で確定しない**。本文に **`[要確認: ...]`**（例: `[要確認: PROJECT_NAME（正式名称）]`）
-   - ガバナンス日付: `RATIFICATION_DATE` は採択日（不明なら質問か TODO）、`LAST_AMENDED_DATE` は変更があれば今日、なければ前回のまま
-   - `CONSTITUTION_VERSION` はセマンティック:
-     - **MAJOR**: 後方互換のないガバナンス/原則の削除・再定義
-     - **MINOR**: 新規原則/セクション追加または重要な拡張
-     - **PATCH**: 明確化・表現・誤字・意味を変えない調整
-   - 種類が曖昧なら確定前に理由を提示
-
-3. **更新後の憲章文案**
-   - プレースホルダは具体テキストで置換（意図的スロット以外は角括弧を残さない。残す場合は理由を明記）
-   - 見出し階層はテンプレと同一。コメントは置換後削除可（説明になっていれば残す）
-   - 各原則: 簡潔な名前・非交渉ルールの段落/箇条書き・理由が自明でなければ明示
-   - ガバナンス: 改正手続き・バージョン方針・準拠レビューの期待
-
-4. **整合性の伝播**（該当フォルダが**既に存在する場合のみ**）
-   - `docs/03_ドメイン設計/` や `docs/04_アーキテクチャ/` があれば、憲章原則と矛盾がないか確認。存在しないフェーズは無視
-   - README / spec-runner ガイダンスで原則参照の更新が必要なら案内
-
-5. **最終検証**（成果物・検証も参照）
-
-6. **書き込み**  
-   完成した憲章を **`docs/01_憲章/憲章.md`** に上書き。**憲章先頭に HTML コメントの「同期影響レポート」や `status: reviewed` は付けない**（`.spec-runner/phase-locks.json` のみで管理）。
-
-7. **ユーザーへの最終サマリ**
-   - 新バージョンと上げた理由
-   - 手動フォローアップが必要なファイル
-   - 推奨コミットメッセージ例: `docs: 憲章を vX.Y.Z に改正（原則追加とガバナンス更新）`
-
-## 成果物・検証
-
-- [ ] 説明のない角括弧トークンが残っていない
-- [ ] バージョン行が変更内容と一致
-- [ ] 日付は ISO `YYYY-MM-DD`
-- [ ] 原則は宣言的・テスト可能。曖昧な「should」は必要に応じ MUST/SHOULD と理由へ
-
-ユーザーが一部だけ更新を依頼した場合も、検証とバージョン決定は行う。  
-欠けている重要情報（例: 批准日が本当に不明）は `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,110 +0,0 @@
----
-step_id: clarify
-phase: null
-note: 任意フェーズで曖昧さを解消
----
-
-# 曖昧さ解消（品質フロー）
-
-**やること**: 任意フェーズで対象仕様（憲章 / UC 仕様 / ドメイン設計 / アーキテクチャ）の曖昧さ・不足決定を検出し、**対話で 1 問ずつ**解消して仕様ファイルに反映する。必要なら `docs/work.md` の受入条件・未解決も更新する。
-
-| 項目 | 内容 |
-|------|------|
-| **タイミング** | 任意フェーズで実行可能。必要に応じて複数回実行してよい |
-| **仕様パス** | `FEATURE_SPEC`（憲章: `docs/01_憲章/憲章.md`、UC: `docs/02_ユースケース仕様/.../UC-N-xxx.md`、ドメイン: `docs/03_ドメイン設計/*.md`、アーキ: `docs/04_アーキテクチャ/*.md`） |
-| **判断ログ（任意）** | `FEATURE_DIR/判断記録/UC-N-MMDD-題名.md`。テンプレ: `.spec-runner/templates/UC-N-MMDD-判断記録テンプレ.md`。横断は `docs/04_アーキテクチャ/設計判断記録/` |
-
-## ユーザー入力
-
-`$ARGUMENTS`（空でなければ必ず考慮）。優先付けの文脈にも使う。
-
-```text
-$ARGUMENTS
-```
-
-## 実行フロー
-
-1. **JSON**  
-   `.spec-runner/spec-runner.sh 次のステップ --json` を **1 回**。`FEATURE_SPEC`・`FEATURE_DIR` を使用。  
-   - UC 仕様を対象とする場合: 実装方針・タスクは **UC .md の一番下**。  
-   - 憲章を対象とする場合: 憲章本文の原則・定義・用語を対象にする。  
-   - ドメイン/アーキを対象とする場合: 現在の `FEATURE_SPEC`（対象 `.md`）の曖昧さを解消する。  
-   JSON パース失敗 → 中止。`FEATURE_SPEC` が空なら対象仕様が未作成なので先に作成を案内。  
-   シングルクォートはエスケープ（例: `'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. **回答ごとの反映（増分）**
-   - メモリとファイル内容を保持
-   - **本文更新を必須**: 採用回答を必ず該当セクションへ反映（機能→機能要件、操作→ストーリー/アクター、データ→データモデル、非機能→測定可能な基準、エッジ→エッジケース、用語→統一・旧表記は一度だけ (旧: "X")）
-   - `## 解消事項` は任意。必要な場合のみ最小限を残す（本文の代替にしない）
-   - 記録する場合は次の改行形式:
-     ```markdown
-     - Q: <質問>
-       A: <回答>
-     ```
-   - 古い曖昧記述は置換し矛盾を残さない。**各反映の直後にファイル保存**。見出し階層維持。新規見出しは **`## 解消事項`** のみ可
-
-6. **検証（各書き込み後・最終）**
-   - 本文に解消済み内容が反映され、本文だけ読めば仕様が確定している
-   - 質問数（採用分）≤ 5
-   - 更新セクションに解消済みの曖昧プレースホルダが残っていない
-   - 矛盾なし、Markdown 有効、用語一貫
-
-7. **書き戻し**  
-   `FEATURE_SPEC` に保存
-
-8. **完了報告**  
-   質問数・回答数・仕様パス・変更セクション一覧・カテゴリカバレッジ表（Resolved / Deferred / Clear / Outstanding）。Outstanding/Deferred 残りは「実装計画」か再「曖昧さ解消」を推奨。次コマンドを明示
-
-## 動作ルール
-
-- 意味のある曖昧がない: 「正式な解消に値する重要な曖昧さは検出されませんでした」と次へ
-- 仕様ファイルがない: 対象仕様（憲章 / UC / ドメイン / アーキ）の作成を案内（ここでは新規作成しない）
-- `[要確認: ...]` が残っている項目を優先して質問対象にする
-- `[要確認: ...]` が無くても、文脈から曖昧・未決定な表現を検出して質問対象に含める
-- 実行状態は `.spec-runner/phase-locks.json` の `quality.clarified.<scope>` で管理し、本文に余計な状態メタ情報は残さない
-- `## 解消事項` を残す場合も最小限にし、判断の正本は常に本文とする
-- 質問は合計 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

@@ -1,33 +0,0 @@
-# 判断記録（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-N-/343/203/246/343/203/274/343/202/271/343/202/261/343/203/274/343/202/271/345/220/215.md

@@ -1,26 +0,0 @@
-# UC-N: {ユースケース名}
-
-> 原則: 1 UC = 1 操作。CRUD は作成 / 編集 / 削除を別 UC に分ける。
-
-## 概要
-
-## アクター
-
-## 事前条件
-
-## 基本フロー
-
-## 代替フロー
-
-## 例外
-
-## 事後条件
-
-## 受入条件
-
-| 前提 | 操作 | 期待 |
-|------|------|------|
-| <条件・前提状態> | <ユーザー操作・イベント> | <測定可能な結果> |
-
-## 備考
-

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

@@ -1,49 +0,0 @@
-{
-  "_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_discovery": {
-    "completed": false,
-    "locked_at": null,
-    "reviewed_by": null
-  },
-  "uc_reviewed": [],
-  "quality": {
-    "_comment": "clarify/analyze の実行済み管理（対象ドキュメントのベース名）",
-    "clarified": {
-      "charter": [],
-      "domain": [],
-      "architecture": [],
-      "uc": []
-    },
-    "analyzed": {
-      "charter": [],
-      "domain": [],
-      "architecture": [],
-      "uc": []
-    }
-  }
-}

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

@@ -1,21 +0,0 @@
-# ドメインモデル
-
-## 境界づけられたコンテキスト（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

@@ -1,16 +0,0 @@
-# ユビキタス言語辞書
-
-## 用語（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]）
-