spec-runner 1.0.24 → 1.1.2

package/README.md

@@ -22,7 +22,6 @@ curl -sSL https://raw.githubusercontent.com/TEEE88/spec-runner/main/install.sh |
 
 - `mkdocs.yml` / `requirements-docs.txt`
 - `docs/index.md`（サイトのホーム）
-- `docs/spec-runner-フロー.md`（`spec-runner` パッケージ同梱の手順書）
 
 `.spec-runner/` がすでにあり **2 回目以降はエラーで止まる** 場合も、**その手前**で上記 MkDocs 用ファイルの不足分だけ補完される（初回導入以前のリポジトリで MkDocs だけ足したいときに便利）。
 
@@ -42,12 +41,21 @@ curl -sSL https://raw.githubusercontent.com/TEEE88/spec-runner/main/install.sh |
 
 AI から使う場合は、`/spec-runner` のように「spec-runner を実行する」と伝えればよい。フェーズやコマンド名を覚える必要はない。
 
+**Git**: フェーズごとにブランチを切る必要はない。**コミットしたくなったとき**に、AI と `project.json` の命名に沿ってブランチ名・メッセージを相談し、一緒にコミットする運用でよい（詳細は同梱の `docs/flow.md` と `.spec-runner/steps/仕様策定.md`）。
+
 ---
 
 ## フロー（全体像）
 
 設計書（`docs/01..06`）と UC 仕様（`docs/02_ユースケース仕様/`）をどんな順で作っていくかは `docs/flow.md` にまとめています。
 
+## Skills テンプレート（任意）
+
+- `templates/skills/uc-k1-work-card-init/SKILL.md`（`docs/work.md` 初期化）
+- `templates/skills/uc-k2-pre-commit-check/SKILL.md`（コミット前チェック案内）
+- `templates/skills/uc-k3-spec-impl-diff-review/SKILL.md`（仕様-実装差分レビュー）
+- `npx spec-runner` 実行時に、不足分のみ `.claude/skills/` へ自動コピーされます（既存ファイルは上書きしない）。
+
 ---
 
 ## ドキュメントサイト（MkDocs + Material）
@@ -59,13 +67,13 @@ AI から使う場合は、`/spec-runner` のように「spec-runner を実行
 プレビュー起動（Python 3 必須・仮想環境 `.venv-docs/` を使用）:
 
 ```bash
-./.spec-runner/scripts/docs-serve.sh
+python3 -m venv .venv-docs && ./.venv-docs/bin/pip install -q -r requirements-docs.txt && ./.venv-docs/bin/mkdocs serve --dev-addr 127.0.0.1:8000
 ```
 
 `8000` が使用中のとき:
 
 ```bash
-DOCS_PORT=8001 ./.spec-runner/scripts/docs-serve.sh
+python3 -m venv .venv-docs && ./.venv-docs/bin/pip install -q -r requirements-docs.txt && ./.venv-docs/bin/mkdocs serve --dev-addr 127.0.0.1:8001
 ```
 
 ## 導入後にできるもの
@@ -76,14 +84,14 @@ DOCS_PORT=8001 ./.spec-runner/scripts/docs-serve.sh
 │   ├── spec-runner.sh          # 入口（次のステップ --json）
 │   ├── project.json            # 設定（ブランチ命名・必須ドキュメント・テストコマンド等）
 │   ├── phase-locks.json        # フェーズの通過状態
-│   ├── grade-history.json      # グレード（LOOP1 / A / B / C）
-│   ├── scripts/                # spec-runner-core.sh, check, branch, docs-serve.sh 等
+│   ├── scripts/                # spec-runner-core.sh, check, branch 等
 │   ├── steps/                  # 憲章・ドメイン設計・仕様策定・曖昧さ解消・テスト設計・実装 等の .md
 │   └── templates/              # UC 仕様書ひな形
 ├── .claude/commands/spec-runner.md   # Claude 用コマンド定義（/spec-runner）
+├── .claude/skills/                   # Skills テンプレート（不足分のみ自動配置）
 ├── mkdocs.yml                 # MkDocs（未有効時のみ配置）
 ├── requirements-docs.txt      # mkdocs / mkdocs-material（未有効時のみ配置）
-├── docs/                      # 設計書（01..06）＋ index.md 等。MkDocs の文書ルート
+├── docs/                      # 設計書（01..06）＋ work.md ＋ index.md 等。MkDocs の文書ルート
 └── （AI は Claude Code 前提）
 ```
 
@@ -95,7 +103,7 @@ DOCS_PORT=8001 ./.spec-runner/scripts/docs-serve.sh
 - jq
 - git
 - bash 4.0+
-- 設計書の MkDocs プレビュー: Python 3（`docs-serve.sh` が `python3` と venv を使用）
+- 設計書の MkDocs プレビュー: Python 3（venv + mkdocs コマンドを直接実行）
 
 ---
 

package/bin/spec-runner.js

@@ -18,12 +18,10 @@
  * 必須テンプレ（パッケージ内）:
  * - templates/.spec-runner/project.json.example
  * - templates/.spec-runner/templates/phase-locks.json
- * - templates/.spec-runner/templates/grade-history.json
  *
  * MkDocs（任意・プロジェクトルート）:
  * - templates/mkdocs-scaffold/ の mkdocs.yml / requirements-docs.txt / docs/index.md を
  *   未有効時のみコピー（憲章・設計書は既存の docs/01..06 をそのまま閲覧）
- * - パッケージ同梱の docs/flow.md を docs/spec-runner-フロー.md としてコピー（未存在時のみ）
  */
 
 const fs = require("fs");
@@ -35,15 +33,13 @@ const TEMPLATE_SPEC_RUNNER_DIR = path.join(PKG_DIR, "templates", ".spec-runner")
 const DEST_DIR = path.join(CWD, ".spec-runner");
 const TEMPLATES_DIR = path.join(TEMPLATE_SPEC_RUNNER_DIR, "templates");
 const PHASE_LOCKS_TEMPLATE = path.join(TEMPLATES_DIR, "phase-locks.json");
-const GRADE_HISTORY_TEMPLATE = path.join(TEMPLATES_DIR, "grade-history.json");
 const MKDOCS_SCAFFOLD_DIR = path.join(PKG_DIR, "templates", "mkdocs-scaffold");
-const FLOW_DOC_SRC = path.join(PKG_DIR, "docs", "flow.md");
+const SKILLS_TEMPLATE_DIR = path.join(PKG_DIR, "templates", "skills");
 
 /** コピー時はスキップし、FORCE 時は消さない（ユーザー状態を保持） */
 const USER_STATE_BASENAMES = new Set([
   "project.json",
   "phase-locks.json",
-  "grade-history.json",
 ]);
 
 function log(msg) {
@@ -84,10 +80,6 @@ function ensureTemplateDirOrExit() {
     error("必須テンプレ templates/phase-locks.json が見つかりません。");
     process.exit(1);
   }
-  if (!exists(GRADE_HISTORY_TEMPLATE)) {
-    error("必須テンプレ templates/grade-history.json が見つかりません。");
-    process.exit(1);
-  }
 }
 
 function assertDestInstallableOrExit() {
@@ -154,18 +146,12 @@ function bootstrapProjectJson() {
  * フェーズ用 JSON は templates/.spec-runner/templates/*.json を正とする。
  * .spec-runner/ 直下に無いときだけコピー（既存のロックは上書きしない）。
  */
-function writeInitialLocksAndGrade() {
+function writeInitialLocks() {
   const locksDest = path.join(DEST_DIR, "phase-locks.json");
   if (!exists(locksDest)) {
     fs.copyFileSync(PHASE_LOCKS_TEMPLATE, locksDest);
     ok(path.relative(CWD, locksDest));
   }
-
-  const gradeDest = path.join(DEST_DIR, "grade-history.json");
-  if (!exists(gradeDest)) {
-    fs.copyFileSync(GRADE_HISTORY_TEMPLATE, gradeDest);
-    ok(path.relative(CWD, gradeDest));
-  }
 }
 
 function installClaudeCommandIfPresent() {
@@ -177,6 +163,30 @@ function installClaudeCommandIfPresent() {
   ok(path.relative(CWD, claudeCmd));
 }
 
+function installClaudeSkillsTemplatesIfPresent() {
+  if (!exists(SKILLS_TEMPLATE_DIR)) return;
+  const destRoot = path.join(CWD, ".claude", "skills");
+  info("Skills テンプレート（不足分のみ）を .claude/skills に配置します...");
+
+  function walk(srcDir, rel = "") {
+    for (const entry of fs.readdirSync(srcDir, { withFileTypes: true })) {
+      const srcPath = path.join(srcDir, entry.name);
+      const relPath = path.join(rel, entry.name);
+      const destPath = path.join(destRoot, relPath);
+      if (entry.isDirectory()) {
+        walk(srcPath, relPath);
+      } else {
+        if (exists(destPath)) continue;
+        fs.mkdirSync(path.dirname(destPath), { recursive: true });
+        fs.copyFileSync(srcPath, destPath);
+        ok(path.relative(CWD, destPath));
+      }
+    }
+  }
+
+  walk(SKILLS_TEMPLATE_DIR);
+}
+
 /**
  * MkDocs + Material 用のファイルをプロジェクトルートに配置（未存在時のみ）。
  * 設計書本体は steps.json どおり docs/01..06 に置かれ、mkdocs の docs_dir でそのまま掲載する。
@@ -222,9 +232,6 @@ function installMkdocsScaffold() {
     path.join(MKDOCS_SCAFFOLD_DIR, "docs", "index.md"),
     path.join(CWD, "docs", "index.md"),
   );
-  if (exists(FLOW_DOC_SRC)) {
-    copyFileIfMissing(FLOW_DOC_SRC, path.join(CWD, "docs", "spec-runner-フロー.md"));
-  }
   appendGitignoreVenvDocsIfNeeded();
 }
 
@@ -238,9 +245,6 @@ function printBanner() {
 }
 
 function printFooter() {
-  log("");
-  log("設計書プレビュー（MkDocs + Material・プロジェクトルートの docs/）:");
-  log("  ./.spec-runner/scripts/docs-serve.sh");
   log("");
   log("次のステップ（Claude Code 専用）:");
   log("  /spec-runner を実行して");
@@ -257,8 +261,9 @@ function main() {
   wipeDestExceptUserState();
   expandTemplateTree();
   bootstrapProjectJson();
-  writeInitialLocksAndGrade();
+  writeInitialLocks();
   installClaudeCommandIfPresent();
+  installClaudeSkillsTemplatesIfPresent();
   printFooter();
 }
 

package/docs/flow.md

@@ -1,213 +1,71 @@
-# spec-runner の進め方（実装準拠）
+# spec-runner フロー（シンプル版）
 
-このドキュメントは **リポジトリ内の実装**（`templates/.spec-runner/scripts/spec-runner-core.sh`、`steps/steps.json` 等）に沿って書いています。  
-「次のステップ」は **1 本のコマンド**が返す **1 つの `command_file`（`.spec-runner/steps/*.md`）** だけです。
+このドキュメントは、`templates/.spec-runner/scripts/spec-runner-core.sh` と `templates/.spec-runner/steps/steps.json` に合わせた最新フローを説明する。
 
----
+## 入口コマンド
 
-## 入口コマンド（毎回）
+| 用途 | コマンド |
+|---|---|
+| 次のステップ | `./.spec-runner/spec-runner.sh 次のステップ --json` |
+| lock 状態表示 | `./.spec-runner/spec-runner.sh 次のステップ --lock` |
 
-| 用途 | コマンド（プロジェクトルート） |
-|------|-------------------------------|
-| 次のステップ（人間向けテキスト） | `./.spec-runner/spec-runner.sh` または `./.spec-runner/spec-runner.sh 次のステップ` |
-| 次のステップ（JSON） | `./.spec-runner/spec-runner.sh 次のステップ --json` |
-| Lock 一覧 | `./.spec-runner/spec-runner.sh 次のステップ --lock`（内部では `--status`） |
-| グレード判定ガイド | `./.spec-runner/spec-runner.sh 次のステップ --グレード` |
+## 設計方針
 
-- **やること**: 出力の `command_file` を開き、その `.md` の指示どおりに作業する。
-- **毎回の検証**: `steps.json` の `common.commands.check` → 既定は `.spec-runner/scripts/check.sh`。
+- `spec-runner` は **薄いオーケストレータ**（次の一手を返す）
+- 正本は `docs/work.md`
+- 主線は 6 ステップ（実行フェーズは5本 + 憲章）、横断は 2 ステップ
+- ブランチ運用やグレード判定は強制しない
 
-### `--json` の主なフィールド（実装どおり）
+## 主線 6 ステップ
 
-| フィールド | 意味 |
-|------------|------|
-| `phase` | 数値（`steps.json` の各 step の `phase` と概ね対応） |
-| `phase_name_ja` | 表示用ラベル（コアが付与） |
-| `step_id` | `steps.json` の `id`（例: `charter`, `uc_spec`, `clarify`） |
-| `command` | ステップの日本語名（`name_ja`） |
-| `command_file` | 絶対パス想定の `.spec-runner/steps/<md_file>` |
-| `grade` | `grade-history.json` の `current_grade` |
-| `check_command` | 毎回のチェック用シェルコマンド |
-| `step_commands` | そのステップ用のコマンド配列（JSON） |
-| `feature_dir` / `feature_spec` | UC ブランチ時、該当 UC のディレクトリ・仕様書パス（取れれば） |
+1. `charter`（憲章）
+2. `uc_spec`（仕様策定）
+3. `domain`（ドメイン設計）
+4. `architecture_plan`（実装計画）
+5. `test_design`（テスト設計）
+6. `implement`（実装）
 
----
+※ 運用上は「実行フェーズ5本（仕様→ドメイン→計画→テスト→実装）+ 憲章」で扱う。
 
-## 状態の単一ソース
-
-### `.spec-runner/phase-locks.json`
-
-実際のキーは次のとおり（各オブジェクトに `completed`, `locked_at`, `reviewed_by` 等）。
-
-| キー | 意味 |
-|------|------|
-| `charter` | 憲章フェーズ完了。ゲートでは `reviewed_by` も参照（LOOP1 時） |
-| `domain` | ドメイン設計フェーズ完了 |
-| `architecture` | アーキ（実装計画）フェーズ完了 |
-| `infra` | インフラ詳細（Grade A）完了 |
-| `test_design` | テスト設計ロック（ゲート側で参照） |
-| `uc_discovery` | UC 洗い出し完了（`false` の間は domain に進まない） |
-| `uc_reviewed` | **文字列の配列**。UC 仕様ファイルの **ベース名（拡張子なし）** が入ると「レビュー通過」とみなす（例: `UC-1-foo`） |
-
-### `.spec-runner/grade-history.json`
-
-- `current_grade`: `LOOP1` / `A` / `B` / `C` など（**ブランチ名には含めない**）
-- Grade A のとき、UC レビュー通過後は **インフラ詳細（`infra_plan`）** が先に出る（`infra.completed` が付くまで）
-
-### `.spec-runner/project.json`
-
-- `naming`: ブランチ接頭辞 `branch_prefix`（既定 `feature`）、`uc_id_pattern`、`other_work_prefixes`（例: `work`, `infra`, `cicd`）
-- `required_docs`: ゲート確認時の必須パス（`steps:charter` 形式で `steps.json` の `common.docs` を参照）
-- `test_design.dir` / `test_design.pattern`（既定: `tests`, `*.spec.*`）
-- `test_design.require_uc_prefixed_tests`（既定: キー省略時 **true**）: **TDD 前提**。UC ブランチでは **`UC-N-` で始まり `pattern` に合致するテストファイル**が `test_design.dir` 内に無い限り **`test_design` のまま**（`implement` に進めない）。`false` にすると従来どおり「任意の spec が1つでもあれば実装」。
-- `test_command.run`: **`require-tests-green.sh` が実行するテストコマンド**（実装完了の機械的条件）
-
----
-
-## 「次のステップ」の分岐（`spec-runner-core.sh` の実際）
-
-ブランチ種別・ロック・UC 有無・`uc_reviewed`・グレード・テストファイル有無で決まります。**紙の上の「常に UC→ドメイン→アーキ」の直線とは一致しません。**
-
-### 1) UC ブランチ上（`feature/<UC-N>-<slug>` 形式）
-
-1. 該当 `UC-N-*.md` が **まだ無い** → **`uc_spec`**（仕様策定）
-2. 仕様はあるが **`uc_reviewed` にベース名が無い** → **`clarify`**（曖昧さ解消・レビュー通過まで）
-3. レビュー済みかつ **`uc_discovery.completed` が false** → **`uc_spec`**（次UC作成）
-4. レビュー済みかつ **Grade A かつ `infra.completed` でない** → **`infra_plan`**
-5. それ以外で **当該 UC 用テストが未準備**（`require_uc_prefixed_tests` が true のときは **`UC-N-*.spec.*` 形式が1つ以上**）→ **`test_design`**
-6. 上記を満たす → **`implement`**（あわせて **テストがグリーン**になるまで完了とみなさないのは `require-tests-green.sh` 側）
-
-※ **ドメイン・アーキのロック未完了でも**、上記 UC ブランチ上では 3〜6 に進めます（コア実装どおり）。
-
-### 2) UC ブランチではない（main 等）
-
-実装では **次の順で最初に当てはまる分岐**が選ばれます（UC ブランチでも `other_work` ブランチでもない場合）。
-
-1. **`charter.completed` でない**
-   - `docs/01_憲章/憲章.md` が無い → **`charter`**
-   - `docs/01_憲章/憲章.md` があり、`quality.clarified.charter` 未記録 → **`clarify`**（憲章の曖昧さ解消）
-   - `docs/01_憲章/憲章.md` があり、`quality.analyzed.charter` 未記録 → **`analyze`**（憲章の分析）
-   - 上記が記録済み → **`charter`**
-2. **ドメイン未ロックかつ `uc_discovery.completed` が false** → **`uc_spec`**（次UC作成）
-3. **ドメイン未ロックかつ `uc_discovery.completed` が true かつ `docs/02_...` に UC が 1 件以上**
-   - `docs/03_ドメイン設計/` に `.md` があり、`quality.clarified.domain` 未記録 → **`clarify`**
-   - `docs/03_ドメイン設計/` に `.md` があり、`quality.analyzed.domain` 未記録 → **`analyze`**
-   - 上記が記録済み、または `.md` が無い → **`domain`**
-4. **ドメイン済みかつアーキ未ロック**
-   - `docs/04_アーキテクチャ/` に `.md` があり、`quality.clarified.architecture` 未記録 → **`clarify`**
-   - `docs/04_アーキテクチャ/` に `.md` があり、`quality.analyzed.architecture` 未記録 → **`analyze`**
-   - 上記が記録済み、または `.md` が無い → **`architecture_plan`**
-5. **`other_work` 用ブランチ**（`feature/<other_work_prefix>/...`）かつ **2〜4 を通過済み** → **`other_work`**
-6. **ドメイン未ロック**（この時点では UC が 0 件）→ **`uc_spec`**
-7. **ドメイン・アーキともロック済み** → **`uc_spec`**（次の UC 開始）
-
-要点:
-
-- **初回**: main で UC がまだ無いと **6** で **`uc_spec`**。
-- **UC がリポジトリに既にあるのにドメイン未ロック**（main で作業）→ `uc_discovery.completed=false` の間は **`uc_spec`** が先（`true` になってから **`domain`**）。
-- **アーキ**は **ドメイン完了後**に **4** で出る。
-
-### 3) 自動では選ばれないステップ（`steps.json` にのみ存在）
-
-次の `id` は **コアの `run_phase` では返しません**。各 `.md`（仕様策定・テスト設計等）の **手順の中で**使う想定です。
+## 横断 2 ステップ
 
+- `clarify`（曖昧さ解消）
 - `analyze`（分析）
-- `checklist`（チェックリスト）
-- `task_list`（タスク一覧）
-
----
-
-## 成果物の置き場所（`steps.json` の `common.docs` と一致）
-
-| キー | パス（既定） |
-|------|----------------|
-| 憲章 | `docs/01_憲章/憲章.md` |
-| UC ルート | `docs/02_ユースケース仕様/<カテゴリ>/UC-N-<slug>.md` |
-| ドメイン | `docs/03_ドメイン設計/`（ユビキタス言語辞書・ドメインモデル・集約 等） |
-| アーキ | `docs/04_アーキテクチャ/` |
-| インフラ | `docs/05_インフラ設計/`（例: `schema.dbml`） |
-| API | `docs/06_API仕様/openapi.yaml` |
-
-- UC ファイル名は **`UC-<N>-<slug>.md`**（`slug` は英数字・ハイフンが無難。ブランチ名も ASCII）。
-- カテゴリフォルダ名は日本語可。
-
----
-
-## ディレクトリ構成（パッケージテンプレに近い形）
-
-```
-<プロジェクトルート>/
-├── .spec-runner/
-│   ├── spec-runner.sh
-│   ├── project.json              # 初回は project.json.example から
-│   ├── phase-locks.json          # 初回は templates/phase-locks.json から
-│   ├── grade-history.json
-│   ├── scripts/
-│   │   ├── spec-runner-core.sh
-│   │   ├── check.sh              # --every / --full
-│   │   ├── branch/uc-next-start.sh
-│   │   └── test/require-tests-green.sh
-│   ├── steps/                    # *.md + steps.json
-│   ├── templates/                # 憲章・UC・ドメイン雛形等
-│   └── hooks/                    # pre-commit / pre-push（任意）
-├── docs/01_憲章/ … 06_API仕様/
-├── tests/                        # project.json の test_design.dir
-└── src/
-```
-
-- **`npx spec-runner`**: `.spec-runner/` を展開し、**`.claude/commands/spec-runner.md` を配置**（テンプレに存在する場合）。`.cursor/` への自動配置は **インストーラでは行っていない**。
-
----
-
-## フェーズ番号とステップ（`steps.json`）
-
-| phase | step_id（代表） | 内容 |
-|-------|-----------------|------|
-| 0 | `charter` | 憲章 |
-| 1 | `uc_spec` / `other_work` | UC 仕様・その他ブランチ |
-| 2 | `domain` | ドメイン設計 |
-| 3 | `architecture_plan` | 実装計画（アーキ） |
-| 4 | `infra_plan` | インフラ詳細（Grade A） |
-| 5 | `test_design` | PENDING テスト |
-| 6 | `implement` | 実装・テストグリーン |
-
-`clarify`（曖昧さ解消）と `analyze`（分析）は `phase: null` の任意ステップとして扱い、必要なタイミングで実行できます。
-
-補足: `clarify` / `analyze` の自動実行は `.spec-runner/phase-locks.json` の `quality` によって 1 度ずつ管理します。  
-（UC は `uc_reviewed` 未登録の間、`clarify -> analyze -> clarify ...` の品質ループを回せます）
-
-### 実装完了（Phase 6）の機械的条件
-
-- **手動または CI で** `.spec-runner/scripts/test/require-tests-green.sh` が **exit 0** であること。
-- 中身は `project.json` の **`test_command.run`** のみを `eval` 実行（例: `npm test`）。
-
-### ゲート（`spec-runner-core.sh --gate`）のメモ
-
-ゲートログ上の「Phase 1/2」表現は **ドメイン=Phase 1、アーキ=Phase 2** のように **steps.json の phase 番号と一致しません**。ロック対象は `phase-locks.json` のキーで判断してください。
-
----
-
-## TDD が「どこまで」強制されるか
-
-| レベル | 内容 |
-|--------|------|
-| **ゲート（次のステップ）** | 上記どおり **先に当該 UC の spec ファイルを置く**まで `implement` を出さない（`require_uc_prefixed_tests: true` 時）。 |
-| **レッド→グリーンの順序** | **コミット順や「本番コードより先にアサーションを書いたか」は機械検査していない**。Phase 5 で PENDING/skip、Phase 6 で実装・グリーン、という **フェーズ順**での強制。 |
-| **完了条件** | `require-tests-green.sh`（`test_command.run` 全通過）。 |
-
----
-
-## 理想運用 vs コードのギャップ（把握用）
-
-| 観点 | よく言われる理想 | 実コード |
-|------|------------------|----------|
-| UC とドメインの順序 | 常に UC 全部 → ドメイン | `uc_discovery.completed=false` の間は次UC（`uc_spec`）→ `true` になってから domain |
-| UC 実装前にアーキ必須 | あり | **UC ブランチ上では**ドメイン・アーキ未ロックでもテスト設計・実装に進む |
-
-運用で「必ずドメイン→アーキ→UC 実装」にしたい場合は、**ロックを先に済ませてから** UC ブランチに入る、またはコアの分岐変更が必要です。
-
----
-
-## 日本語ドキュメント
 
-`docs/` 配下の設計書は日本語で問題ありません。**Git 上はブランチ名・UC ファイルの slug は ASCII（kebab-case）推奨**です。
+これらは任意タイミングで使う補助ステップ。主線フェーズを増やさない。
+
+## 次ステップ判定（概要）
+
+`spec-runner-core.sh` は lock と成果物から次を返す。
+
+1. `charter.completed` が false  
+   - 憲章が未整備なら `charter`
+   - 憲章があるなら `clarify` / `analyze` を先に返すことがある
+2. `uc_discovery.completed` が false  
+   - 未レビュー UC があれば `clarify` / `analyze`（UC 整合性チェック）
+   - すべてレビュー済みなら `uc_spec`（次 UC 作成）
+3. `domain.completed` が false  
+   - 未レビュー UC が 1 件でも残っていれば先に `clarify` / `analyze`
+   - 全 UC レビュー済みなら `domain`（必要に応じ `clarify` / `analyze`）
+4. `architecture.completed` が false  
+   - `architecture_plan`（必要に応じ `clarify` / `analyze`）
+   - lock が true でも、設計成果物（`docs/03` / `docs/04` の `.md`）が無い場合は該当設計フェーズに戻る
+5. 最新 UC がレビュー済みかつテスト準備済み  
+   - `implement`  
+   それ以外は `test_design`
+
+## 正本（Single Source）
+
+- フロー定義: `.spec-runner/steps/steps.json`
+- 進行状態: `.spec-runner/phase-locks.json`
+- 作業正本: `docs/work.md`
+- 仕様本文: `docs/01..06`, `docs/02_ユースケース仕様/**`
+- 実装検証: `tests/**`, `test_command.run`
+
+## 運用ルール（最小）
+
+1. 実装前に `docs/work.md` の受入条件を埋める
+2. 作業中は `docs/work.md` のタスクを更新する
+3. コミット前に `docs/work.md` の `- [ ]` を確認する
+4. 完了時に `docs/work.md` の検証結果を更新する
+5. UC を十分に作ってレビュー完了したら `uc_discovery.completed` を `true` にする

package/package.json

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

package/templates/.spec-runner/project.json.example

@@ -19,7 +19,7 @@
   "test_design": {
     "dir": "tests",
     "pattern": "*.spec.*",
-    "require_uc_prefixed_tests": true
+    "require_uc_prefixed_tests": false
   },
   "test_command": {
     "run": "npm test"

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

@@ -41,14 +41,10 @@ run_steps_json_check() {
     "uc_spec"
     "domain"
     "architecture_plan"
-    "infra_plan"
     "test_design"
     "implement"
     "clarify"
     "analyze"
-    "checklist"
-    "task_list"
-    "other_work"
   )
 
   dup_ids=$(jq -r '.steps[]?.id // empty' "$sj" | sort | uniq -d || true)
@@ -94,29 +90,6 @@ run_steps_json_check() {
 run_naming_check() {
   local errors=0
 
-  # ブランチ名
-  local branch
-  branch=$(git branch --show-current 2>/dev/null || echo "")
-  if [[ -n "$branch" ]]; then
-    local pj valid bp uc_id_pat other_work
-    pj="$REPO_ROOT/.spec-runner/project.json"
-    [[ -f "$pj" ]] || { echo "NAMING: project.json がありません: $pj" >&2; return 1; }
-    command -v jq >/dev/null 2>&1 || { echo "NAMING: jq が必要です（brew install jq）" >&2; return 1; }
-    bp="$(jq -r '.naming.branch_prefix' "$pj")"
-    uc_id_pat="$(jq -r '.naming.uc_id_pattern' "$pj")"
-    other_work="$(jq -r '.naming.other_work_prefixes[] | . + "/.+"' "$pj" | tr '\n' '|' | sed 's/|$//')"
-    if [[ -z "$bp" || "$bp" == "null" || -z "$uc_id_pat" || "$uc_id_pat" == "null" || -z "$other_work" ]]; then
-      echo "NAMING: project.json の naming.branch_prefix / uc_id_pattern / other_work_prefixes が不正です" >&2
-      errors=$((errors+1))
-    else
-      valid="^(main|develop|${bp}/(${uc_id_pat}-.+|${other_work})|fix/${uc_id_pat}-.+|release/[0-9]+\\.[0-9]+\\.[0-9]+.*|hotfix/[0-9]+\\.[0-9]+\\.[0-9]+-.+)$"
-      if ! echo "$branch" | grep -qE "$valid"; then
-        echo "NAMING: ブランチ名「$branch」が規則違反" >&2
-        errors=$((errors+1))
-      fi
-    fi
-  fi
-
   # src フォルダ命名（存在する場合のみ）
   if [[ -d "src" ]]; then
     while IFS= read -r dir; do
@@ -130,7 +103,7 @@ run_naming_check() {
   fi
 
   if [[ $errors -eq 0 ]]; then
-    ok "✅ 命名規則チェック: 問題なし"
+    ok "✅ 命名規則チェック（src 配下フォルダ）: 問題なし"
     return 0
   else
     return 1
@@ -350,16 +323,7 @@ run_health_check() {
     fi
   fi
 
-  if [[ ! -f ".spec-runner/grade-history.json" ]]; then
-    drifts+=(".spec-runner/grade-history.json がありません")
-  elif command -v jq >/dev/null 2>&1; then
-    grade=$(jq -r '.current_grade' .spec-runner/grade-history.json)
-    [[ -n "$grade" && "$grade" != "null" ]] || drifts+=("grade-history.json の current_grade が未設定です")
-    if [[ "$grade" == "A" && "$current_phase" -ge 4 && "$is_quality_step" -eq 0 ]]; then
-      [[ ! -f "$INFRA_ROOT/schema.dbml" ]] && drifts+=("Grade A 必須: schema.dbml が存在しません")
-      schema_sync_check >/dev/null 2>&1 || drifts+=("Prisma と schema.dbml のテーブルが一致していません（スキーマ同期チェック）")
-    fi
-  fi
+  # grade ベースの強制は行わない（薄いオーケストレータ方針）
 
   if [[ "$current_phase" -ge 3 && "$is_quality_step" -eq 0 ]]; then
     [[ ! -f "$OPENAPI_PATH" ]] && drifts+=("openapi.yaml が存在しません")