spec-runner 1.0.9 → 1.0.11

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "spec-runner",
-  "version": "1.0.9",
+  "version": "1.0.11",
   "description": "フェーズ駆動で設計先行を強制。npx で .spec-runner を展開し、次のステップ .md に従って進める",
   "license": "MIT",
   "bin": {

package/templates/.spec-runner/scripts/spec-runner-core.sh

@@ -267,6 +267,27 @@ run_phase() {
   check_command=""
   feature_dir=""
   feature_spec=""
+  charter_doc="$(get_steps_common_doc "charter")"
+  domain_root="$(get_steps_common_doc "domain_root")"
+  architecture_root="$(get_steps_common_doc "architecture_root")"
+
+  first_md_in_dir() {
+    local d="$1"
+    [[ -d "$d" ]] || return 1
+    find "$d" -type f -name "*.md" 2>/dev/null | sort | head -1
+  }
+
+  doc_key() {
+    local f="$1"
+    basename "$f" .md
+  }
+
+  quality_done() {
+    local kind="$1"   # clarified | analyzed
+    local scope="$2"  # charter | domain | architecture | uc
+    local key="$3"
+    jq -e --arg k "$key" --arg s "$scope" ".quality.${kind}[\$s][]? == \$k" "$LOCK_FILE" >/dev/null 2>&1
+  }
 
   resolve_step() {
     local sid="$1"
@@ -293,11 +314,52 @@ run_phase() {
   uc_count_total=${uc_count_total:-0}
 
   if [[ $has_charter_lock -eq 0 ]]; then
-    phase=0; phase_name_ja="憲章策定"; resolve_step "charter"
+    if [[ -f "$charter_doc" ]]; then
+      ckey="$(doc_key "$charter_doc")"
+      feature_spec="$charter_doc"
+      feature_dir="$(dirname "$charter_doc")"
+      if ! quality_done "clarified" "charter" "$ckey"; then
+        phase=0; phase_name_ja="憲章（曖昧さ解消）"; resolve_step "clarify"
+      elif ! quality_done "analyzed" "charter" "$ckey"; then
+        phase=0; phase_name_ja="憲章（分析）"; resolve_step "analyze"
+      else
+        phase=0; phase_name_ja="憲章策定"; resolve_step "charter"
+      fi
+    else
+      phase=0; phase_name_ja="憲章策定"; resolve_step "charter"
+    fi
   elif [[ $has_domain_lock -eq 0 && ${uc_count_total} -gt 0 && $on_uc_branch -eq 0 ]]; then
-    phase=2; phase_name_ja="ドメイン設計"; resolve_step "domain"
+    domain_spec="$(first_md_in_dir "$domain_root" || true)"
+    if [[ -n "$domain_spec" ]]; then
+      feature_spec="$domain_spec"
+      feature_dir="$(dirname "$domain_spec")"
+      dkey="$(doc_key "$domain_spec")"
+      if ! quality_done "clarified" "domain" "$dkey"; then
+        phase=2; phase_name_ja="ドメイン設計（曖昧さ解消）"; resolve_step "clarify"
+      elif ! quality_done "analyzed" "domain" "$dkey"; then
+        phase=2; phase_name_ja="ドメイン設計（分析）"; resolve_step "analyze"
+      else
+        phase=2; phase_name_ja="ドメイン設計"; resolve_step "domain"
+      fi
+    else
+      phase=2; phase_name_ja="ドメイン設計"; resolve_step "domain"
+    fi
   elif [[ $has_arch_lock -eq 0 && $has_domain_lock -eq 1 ]]; then
-    phase=3; phase_name_ja="アーキテクチャ選択"; resolve_step "architecture_plan"
+    arch_spec="$(first_md_in_dir "$architecture_root" || true)"
+    if [[ -n "$arch_spec" ]]; then
+      feature_spec="$arch_spec"
+      feature_dir="$(dirname "$arch_spec")"
+      akey="$(doc_key "$arch_spec")"
+      if ! quality_done "clarified" "architecture" "$akey"; then
+        phase=3; phase_name_ja="アーキテクチャ選択（曖昧さ解消）"; resolve_step "clarify"
+      elif ! quality_done "analyzed" "architecture" "$akey"; then
+        phase=3; phase_name_ja="アーキテクチャ選択（分析）"; resolve_step "analyze"
+      else
+        phase=3; phase_name_ja="アーキテクチャ選択"; resolve_step "architecture_plan"
+      fi
+    else
+      phase=3; phase_name_ja="アーキテクチャ選択"; resolve_step "architecture_plan"
+    fi
   elif [[ $on_uc_branch -eq 1 ]]; then
     uc_spec=""
     if [[ -n "$current_uc_id" ]]; then
@@ -312,7 +374,13 @@ run_phase() {
       reviewed=0
       jq -e --arg u "$uc_dir" '.uc_reviewed[]? == $u' "$LOCK_FILE" 2>/dev/null | grep -q true && reviewed=1
       if [[ $reviewed -eq 0 ]]; then
-        phase=1; phase_name_ja="ユースケース仕様（レビュー通過まで）"; resolve_step "clarify"
+        if ! quality_done "clarified" "uc" "$uc_dir"; then
+          phase=1; phase_name_ja="ユースケース仕様（曖昧さ解消）"; resolve_step "clarify"
+        elif ! quality_done "analyzed" "uc" "$uc_dir"; then
+          phase=1; phase_name_ja="ユースケース仕様（分析）"; resolve_step "analyze"
+        else
+          phase=1; phase_name_ja="ユースケース仕様（レビュー通過まで）"; resolve_step "clarify"
+        fi
       else
         if [[ "$grade" == "A" ]] && [[ $has_infra_lock -eq 0 ]]; then
           phase=4; phase_name_ja="インフラ詳細設計"; resolve_step "infra_plan"

package/templates/.spec-runner/steps//343/203/201/343/202/247/343/203/203/343/202/257/343/203/252/343/202/271/343/203/210.md

@@ -1,6 +1,6 @@
 ---
 step_id: checklist
-phase: quality
+phase: null
 ---
 
 # チェックリスト（品質フロー）

package/templates/.spec-runner/steps//344/273/225/346/247/230/347/255/226/345/256/232.md

@@ -6,13 +6,13 @@ primary_output: docs/02_ユースケース仕様/<カテゴリ>/UC-N-xxx.md
 
 # ユースケース仕様（UC 仕様書）
 
-**やること**: 機能説明（`$ARGUMENTS`）から UC ブランチと UC 仕様書を作成し、テンプレに沿って埋める。その後 clarify → analyze / checklist → review-pass。
+**やること**: 機能説明（`$ARGUMENTS`）から UC ブランチと UC 仕様書を作成し、テンプレに沿って埋める。その後 quality フロー（clarify → analyze）を回し、必要に応じて checklist を実施して review-pass へ進む。
 
 | 項目 | 内容 |
 |------|------|
 | **成果物** | `docs/02_ユースケース仕様/<カテゴリ>/UC-N-xxx.md`（1 UC = 1 本） |
 | **main** | **必ず UC 用ブランチを作成してから**仕様を書く。main で直接編集しない |
-| **品質フロー** | clarify → analyze / checklist → review-pass |
+| **品質フロー** | `phase-locks.json` の `quality` を使って **clarify → analyze** を自動進行。必要なら checklist を追加で実施 |
 | **判断ログ（任意）** | `docs/02_.../<カテゴリ>/判断記録/UC-N-MMDD-題名.md`。テンプレ: `.spec-runner/templates/UC-N-MMDD-判断記録テンプレ.md` |
 
 ## ユーザー入力

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

@@ -88,6 +88,7 @@ $ARGUMENTS
 - CRITICAL あり → 「実装」の前に解消推奨
 - LOW/MEDIUM のみ → 改善案のうえ進行可
 - 次コマンドを明示（仕様修正・実装方針追記・実装計画調整等）
+- 完了時に `.spec-runner/phase-locks.json` の `quality.analyzed.<scope>` に対象ドキュメントのベース名を追加する（scope: `charter` / `domain` / `architecture` / `uc`）
 
 ### 8. 修正案オファー
 

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

@@ -6,12 +6,12 @@ note: 任意フェーズで曖昧さを解消
 
 # 曖昧さ解消（品質フロー）
 
-**やること**: 任意フェーズで UC 仕様の曖昧さ・不足決定を検出し、**対話で 1 問ずつ**解消して仕様ファイルに反映する。
+**やること**: 任意フェーズで対象仕様（憲章 / UC 仕様 / ドメイン設計 / アーキテクチャ）の曖昧さ・不足決定を検出し、**対話で 1 問ずつ**解消して仕様ファイルに反映する。
 
 | 項目 | 内容 |
 |------|------|
 | **タイミング** | 任意フェーズで実行可能。必要に応じて複数回実行してよい |
-| **仕様パス** | `FEATURE_SPEC` = `docs/02_ユースケース仕様/<カテゴリ>/UC-N-xxx.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_アーキテクチャ/設計判断記録/` |
 
 ## ユーザー入力
@@ -25,8 +25,11 @@ $ARGUMENTS
 ## 実行フロー
 
 1. **JSON**  
-   `.spec-runner/spec-runner.sh 次のステップ --json` を **1 回**。`feature/UC-N-xxx`。`FEATURE_SPEC`・`FEATURE_DIR` を使用。実装方針・タスクは **UC .md の一番下**。  
-   JSON パース失敗 → 中止。「仕様策定」で UC ブランチ作成または checkout を案内。  
+   `.spec-runner/spec-runner.sh 次のステップ --json` を **1 回**。`FEATURE_SPEC`・`FEATURE_DIR` を使用。  
+   - UC 仕様を対象とする場合: 実装方針・タスクは **UC .md の一番下**。  
+   - 憲章を対象とする場合: 憲章本文の原則・定義・用語を対象にする。  
+   - ドメイン/アーキを対象とする場合: 現在の `FEATURE_SPEC`（対象 `.md`）の曖昧さを解消する。  
+   JSON パース失敗 → 中止。`FEATURE_SPEC` が空なら対象仕様が未作成なので先に作成を案内。  
    シングルクォートはエスケープ（例: `'I'\''m Groot'`）。
 
 2. **スキャン**  
@@ -51,13 +54,17 @@ $ARGUMENTS
 
 5. **回答ごとの反映（増分）**
    - メモリとファイル内容を保持
-   - 初回反映時: `## 解消事項` が無ければ概要直後に作成。`### Session YYYY-MM-DD` を今日で作成
-   - 採用直後: `- Q: <質問> → A: <回答>` を追記
-   - 内容を適切セクションへ（機能→機能要件、操作→ストーリー/アクター、データ→データモデル、非機能→測定可能な基準、エッジ→エッジケース、用語→統一・旧表記は一度だけ (旧: "X")）
-   - 古い曖昧記述は置換し矛盾を残さない。**各反映の直後にファイル保存**。見出し階層維持。新規見出しは **`## 解消事項`**, **`### Session YYYY-MM-DD`** のみ可
+   - **本文更新を必須**: 採用回答を必ず該当セクションへ反映（機能→機能要件、操作→ストーリー/アクター、データ→データモデル、非機能→測定可能な基準、エッジ→エッジケース、用語→統一・旧表記は一度だけ (旧: "X")）
+   - `## 解消事項` は任意。必要な場合のみ最小限を残す（本文の代替にしない）
+   - 記録する場合は次の改行形式:
+     ```markdown
+     - Q: <質問>
+       A: <回答>
+     ```
+   - 古い曖昧記述は置換し矛盾を残さない。**各反映の直後にファイル保存**。見出し階層維持。新規見出しは **`## 解消事項`** のみ可
 
 6. **検証（各書き込み後・最終）**
-   - 解消セッションは採用回答ごと 1 箇条（重複なし）
+   - 本文に解消済み内容が反映され、本文だけ読めば仕様が確定している
    - 質問数（採用分）≤ 5
    - 更新セクションに解消済みの曖昧プレースホルダが残っていない
    - 矛盾なし、Markdown 有効、用語一貫
@@ -71,7 +78,11 @@ $ARGUMENTS
 ## 動作ルール
 
 - 意味のある曖昧がない: 「正式な解消に値する重要な曖昧さは検出されませんでした」と次へ
-- 仕様ファイルがない: 「仕様策定」を案内（ここでは新規仕様を作らない）
+- 仕様ファイルがない: 対象仕様（憲章 / UC / ドメイン / アーキ）の作成を案内（ここでは新規作成しない）
+- `[要確認: ...]` が残っている項目を優先して質問対象にする
+- `[要確認: ...]` が無くても、文脈から曖昧・未決定な表現を検出して質問対象に含める
+- 実行状態は `.spec-runner/phase-locks.json` の `quality.clarified.<scope>` で管理し、本文に余計な状態メタ情報は残さない
+- `## 解消事項` を残す場合も最小限にし、判断の正本は常に本文とする
 - 質問は合計 5 を超えない（聞き直しは新規に数えない）
 - 機能の明確さを妨げない限り技術スタックの推測質問は避ける
 - 「ストップ」「完了」「進めて」等を尊重

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

@@ -25,5 +25,20 @@
     "locked_at": null,
     "reviewed_by": null
   },
-  "uc_reviewed": []
+  "uc_reviewed": [],
+  "quality": {
+    "_comment": "clarify/analyze の実行済み管理（対象ドキュメントのベース名）",
+    "clarified": {
+      "charter": [],
+      "domain": [],
+      "architecture": [],
+      "uc": []
+    },
+    "analyzed": {
+      "charter": [],
+      "domain": [],
+      "architecture": [],
+      "uc": []
+    }
+  }
 }