spec-runner 1.0.10 → 1.0.11

package/package.json

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

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//346/233/226/346/230/247/343/201/225/350/247/243/346/266/210.md

@@ -54,13 +54,17 @@ $ARGUMENTS
 
 5. **回答ごとの反映（増分）**
    - メモリとファイル内容を保持
-   - 初回反映時: `## 解消事項` が無ければ概要直後に作成。`### Session YYYY-MM-DD` を今日で作成
-   - 採用直後: `- Q: <質問> → A: <回答>` を追記
-   - 内容を適切セクションへ（機能→機能要件、操作→ストーリー/アクター、データ→データモデル、非機能→測定可能な基準、エッジ→エッジケース、用語→統一・旧表記は一度だけ (旧: "X")）
-   - 古い曖昧記述は置換し矛盾を残さない。**各反映の直後にファイル保存**。見出し階層維持。新規見出しは **`## 解消事項`**, **`### Session YYYY-MM-DD`** のみ可
+   - **本文更新を必須**: 採用回答を必ず該当セクションへ反映（機能→機能要件、操作→ストーリー/アクター、データ→データモデル、非機能→測定可能な基準、エッジ→エッジケース、用語→統一・旧表記は一度だけ (旧: "X")）
+   - `## 解消事項` は任意。必要な場合のみ最小限を残す（本文の代替にしない）
+   - 記録する場合は次の改行形式:
+     ```markdown
+     - Q: <質問>
+       A: <回答>
+     ```
+   - 古い曖昧記述は置換し矛盾を残さない。**各反映の直後にファイル保存**。見出し階層維持。新規見出しは **`## 解消事項`** のみ可
 
 6. **検証（各書き込み後・最終）**
-   - 解消セッションは採用回答ごと 1 箇条（重複なし）
+   - 本文に解消済み内容が反映され、本文だけ読めば仕様が確定している
    - 質問数（採用分）≤ 5
    - 更新セクションに解消済みの曖昧プレースホルダが残っていない
    - 矛盾なし、Markdown 有効、用語一貫
@@ -77,7 +81,8 @@ $ARGUMENTS
 - 仕様ファイルがない: 対象仕様（憲章 / UC / ドメイン / アーキ）の作成を案内（ここでは新規作成しない）
 - `[要確認: ...]` が残っている項目を優先して質問対象にする
 - `[要確認: ...]` が無くても、文脈から曖昧・未決定な表現を検出して質問対象に含める
-- 完了時に `.spec-runner/phase-locks.json` の `quality.clarified.<scope>` に対象ドキュメントのベース名を追加する（scope: `charter` / `domain` / `architecture` / `uc`）
+- 実行状態は `.spec-runner/phase-locks.json` の `quality.clarified.<scope>` で管理し、本文に余計な状態メタ情報は残さない
+- `## 解消事項` を残す場合も最小限にし、判断の正本は常に本文とする
 - 質問は合計 5 を超えない（聞き直しは新規に数えない）
 - 機能の明確さを妨げない限り技術スタックの推測質問は避ける
 - 「ストップ」「完了」「進めて」等を尊重