spec-runner 1.0.9 → 1.0.10

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "spec-runner",
3
- "version": "1.0.9",
3
+ "version": "1.0.10",
4
4
  "description": "フェーズ駆動で設計先行を強制。npx で .spec-runner を展開し、次のステップ .md に従って進める",
5
5
  "license": "MIT",
6
6
  "bin": {
@@ -267,6 +267,27 @@ run_phase() {
267
267
  check_command=""
268
268
  feature_dir=""
269
269
  feature_spec=""
270
+ charter_doc="$(get_steps_common_doc "charter")"
271
+ domain_root="$(get_steps_common_doc "domain_root")"
272
+ architecture_root="$(get_steps_common_doc "architecture_root")"
273
+
274
+ first_md_in_dir() {
275
+ local d="$1"
276
+ [[ -d "$d" ]] || return 1
277
+ find "$d" -type f -name "*.md" 2>/dev/null | sort | head -1
278
+ }
279
+
280
+ doc_key() {
281
+ local f="$1"
282
+ basename "$f" .md
283
+ }
284
+
285
+ quality_done() {
286
+ local kind="$1" # clarified | analyzed
287
+ local scope="$2" # charter | domain | architecture | uc
288
+ local key="$3"
289
+ jq -e --arg k "$key" --arg s "$scope" ".quality.${kind}[\$s][]? == \$k" "$LOCK_FILE" >/dev/null 2>&1
290
+ }
270
291
 
271
292
  resolve_step() {
272
293
  local sid="$1"
@@ -293,11 +314,52 @@ run_phase() {
293
314
  uc_count_total=${uc_count_total:-0}
294
315
 
295
316
  if [[ $has_charter_lock -eq 0 ]]; then
296
- phase=0; phase_name_ja="憲章策定"; resolve_step "charter"
317
+ if [[ -f "$charter_doc" ]]; then
318
+ ckey="$(doc_key "$charter_doc")"
319
+ feature_spec="$charter_doc"
320
+ feature_dir="$(dirname "$charter_doc")"
321
+ if ! quality_done "clarified" "charter" "$ckey"; then
322
+ phase=0; phase_name_ja="憲章(曖昧さ解消)"; resolve_step "clarify"
323
+ elif ! quality_done "analyzed" "charter" "$ckey"; then
324
+ phase=0; phase_name_ja="憲章(分析)"; resolve_step "analyze"
325
+ else
326
+ phase=0; phase_name_ja="憲章策定"; resolve_step "charter"
327
+ fi
328
+ else
329
+ phase=0; phase_name_ja="憲章策定"; resolve_step "charter"
330
+ fi
297
331
  elif [[ $has_domain_lock -eq 0 && ${uc_count_total} -gt 0 && $on_uc_branch -eq 0 ]]; then
298
- phase=2; phase_name_ja="ドメイン設計"; resolve_step "domain"
332
+ domain_spec="$(first_md_in_dir "$domain_root" || true)"
333
+ if [[ -n "$domain_spec" ]]; then
334
+ feature_spec="$domain_spec"
335
+ feature_dir="$(dirname "$domain_spec")"
336
+ dkey="$(doc_key "$domain_spec")"
337
+ if ! quality_done "clarified" "domain" "$dkey"; then
338
+ phase=2; phase_name_ja="ドメイン設計(曖昧さ解消)"; resolve_step "clarify"
339
+ elif ! quality_done "analyzed" "domain" "$dkey"; then
340
+ phase=2; phase_name_ja="ドメイン設計(分析)"; resolve_step "analyze"
341
+ else
342
+ phase=2; phase_name_ja="ドメイン設計"; resolve_step "domain"
343
+ fi
344
+ else
345
+ phase=2; phase_name_ja="ドメイン設計"; resolve_step "domain"
346
+ fi
299
347
  elif [[ $has_arch_lock -eq 0 && $has_domain_lock -eq 1 ]]; then
300
- phase=3; phase_name_ja="アーキテクチャ選択"; resolve_step "architecture_plan"
348
+ arch_spec="$(first_md_in_dir "$architecture_root" || true)"
349
+ if [[ -n "$arch_spec" ]]; then
350
+ feature_spec="$arch_spec"
351
+ feature_dir="$(dirname "$arch_spec")"
352
+ akey="$(doc_key "$arch_spec")"
353
+ if ! quality_done "clarified" "architecture" "$akey"; then
354
+ phase=3; phase_name_ja="アーキテクチャ選択(曖昧さ解消)"; resolve_step "clarify"
355
+ elif ! quality_done "analyzed" "architecture" "$akey"; then
356
+ phase=3; phase_name_ja="アーキテクチャ選択(分析)"; resolve_step "analyze"
357
+ else
358
+ phase=3; phase_name_ja="アーキテクチャ選択"; resolve_step "architecture_plan"
359
+ fi
360
+ else
361
+ phase=3; phase_name_ja="アーキテクチャ選択"; resolve_step "architecture_plan"
362
+ fi
301
363
  elif [[ $on_uc_branch -eq 1 ]]; then
302
364
  uc_spec=""
303
365
  if [[ -n "$current_uc_id" ]]; then
@@ -312,7 +374,13 @@ run_phase() {
312
374
  reviewed=0
313
375
  jq -e --arg u "$uc_dir" '.uc_reviewed[]? == $u' "$LOCK_FILE" 2>/dev/null | grep -q true && reviewed=1
314
376
  if [[ $reviewed -eq 0 ]]; then
315
- phase=1; phase_name_ja="ユースケース仕様(レビュー通過まで)"; resolve_step "clarify"
377
+ if ! quality_done "clarified" "uc" "$uc_dir"; then
378
+ phase=1; phase_name_ja="ユースケース仕様(曖昧さ解消)"; resolve_step "clarify"
379
+ elif ! quality_done "analyzed" "uc" "$uc_dir"; then
380
+ phase=1; phase_name_ja="ユースケース仕様(分析)"; resolve_step "analyze"
381
+ else
382
+ phase=1; phase_name_ja="ユースケース仕様(レビュー通過まで)"; resolve_step "clarify"
383
+ fi
316
384
  else
317
385
  if [[ "$grade" == "A" ]] && [[ $has_infra_lock -eq 0 ]]; then
318
386
  phase=4; phase_name_ja="インフラ詳細設計"; resolve_step "infra_plan"
@@ -88,6 +88,7 @@ $ARGUMENTS
88
88
  - CRITICAL あり → 「実装」の前に解消推奨
89
89
  - LOW/MEDIUM のみ → 改善案のうえ進行可
90
90
  - 次コマンドを明示(仕様修正・実装方針追記・実装計画調整等)
91
+ - 完了時に `.spec-runner/phase-locks.json` の `quality.analyzed.<scope>` に対象ドキュメントのベース名を追加する(scope: `charter` / `domain` / `architecture` / `uc`)
91
92
 
92
93
  ### 8. 修正案オファー
93
94
 
@@ -6,12 +6,12 @@ note: 任意フェーズで曖昧さを解消
6
6
 
7
7
  # 曖昧さ解消(品質フロー)
8
8
 
9
- **やること**: 任意フェーズで UC 仕様の曖昧さ・不足決定を検出し、**対話で 1 問ずつ**解消して仕様ファイルに反映する。
9
+ **やること**: 任意フェーズで対象仕様(憲章 / UC 仕様 / ドメイン設計 / アーキテクチャ)の曖昧さ・不足決定を検出し、**対話で 1 問ずつ**解消して仕様ファイルに反映する。
10
10
 
11
11
  | 項目 | 内容 |
12
12
  |------|------|
13
13
  | **タイミング** | 任意フェーズで実行可能。必要に応じて複数回実行してよい |
14
- | **仕様パス** | `FEATURE_SPEC` = `docs/02_ユースケース仕様/<カテゴリ>/UC-N-xxx.md` |
14
+ | **仕様パス** | `FEATURE_SPEC`(憲章: `docs/01_憲章/憲章.md`、UC: `docs/02_ユースケース仕様/.../UC-N-xxx.md`、ドメイン: `docs/03_ドメイン設計/*.md`、アーキ: `docs/04_アーキテクチャ/*.md`) |
15
15
  | **判断ログ(任意)** | `FEATURE_DIR/判断記録/UC-N-MMDD-題名.md`。テンプレ: `.spec-runner/templates/UC-N-MMDD-判断記録テンプレ.md`。横断は `docs/04_アーキテクチャ/設計判断記録/` |
16
16
 
17
17
  ## ユーザー入力
@@ -25,8 +25,11 @@ $ARGUMENTS
25
25
  ## 実行フロー
26
26
 
27
27
  1. **JSON**
28
- `.spec-runner/spec-runner.sh 次のステップ --json` を **1 回**。`feature/UC-N-xxx`。`FEATURE_SPEC`・`FEATURE_DIR` を使用。実装方針・タスクは **UC .md の一番下**。
29
- JSON パース失敗 中止。「仕様策定」で UC ブランチ作成または checkout を案内。
28
+ `.spec-runner/spec-runner.sh 次のステップ --json` を **1 回**。`FEATURE_SPEC`・`FEATURE_DIR` を使用。
29
+ - UC 仕様を対象とする場合: 実装方針・タスクは **UC .md の一番下**。
30
+ - 憲章を対象とする場合: 憲章本文の原則・定義・用語を対象にする。
31
+ - ドメイン/アーキを対象とする場合: 現在の `FEATURE_SPEC`(対象 `.md`)の曖昧さを解消する。
32
+ JSON パース失敗 → 中止。`FEATURE_SPEC` が空なら対象仕様が未作成なので先に作成を案内。
30
33
  シングルクォートはエスケープ(例: `'I'\''m Groot'`)。
31
34
 
32
35
  2. **スキャン**
@@ -71,7 +74,10 @@ $ARGUMENTS
71
74
  ## 動作ルール
72
75
 
73
76
  - 意味のある曖昧がない: 「正式な解消に値する重要な曖昧さは検出されませんでした」と次へ
74
- - 仕様ファイルがない: 「仕様策定」を案内(ここでは新規仕様を作らない)
77
+ - 仕様ファイルがない: 対象仕様(憲章 / UC / ドメイン / アーキ)の作成を案内(ここでは新規作成しない)
78
+ - `[要確認: ...]` が残っている項目を優先して質問対象にする
79
+ - `[要確認: ...]` が無くても、文脈から曖昧・未決定な表現を検出して質問対象に含める
80
+ - 完了時に `.spec-runner/phase-locks.json` の `quality.clarified.<scope>` に対象ドキュメントのベース名を追加する(scope: `charter` / `domain` / `architecture` / `uc`)
75
81
  - 質問は合計 5 を超えない(聞き直しは新規に数えない)
76
82
  - 機能の明確さを妨げない限り技術スタックの推測質問は避ける
77
83
  - 「ストップ」「完了」「進めて」等を尊重
@@ -25,5 +25,20 @@
25
25
  "locked_at": null,
26
26
  "reviewed_by": null
27
27
  },
28
- "uc_reviewed": []
28
+ "uc_reviewed": [],
29
+ "quality": {
30
+ "_comment": "clarify/analyze の実行済み管理(対象ドキュメントのベース名)",
31
+ "clarified": {
32
+ "charter": [],
33
+ "domain": [],
34
+ "architecture": [],
35
+ "uc": []
36
+ },
37
+ "analyzed": {
38
+ "charter": [],
39
+ "domain": [],
40
+ "architecture": [],
41
+ "uc": []
42
+ }
43
+ }
29
44
  }