spec-runner 1.1.6 → 1.1.8

package/templates/.spec-runner/scripts/uc-next-start.sh

@@ -1,161 +0,0 @@
-#!/usr/bin/env bash
-# 次の UC 仕様のひな形を作成する（Git ブランチの作成・切替は行わない）。
-# 使用例:
-#   ./uc-next-start.sh "task-management" "タスク管理機能追加" "タスク管理"
-#   ./uc-next-start.sh UC-2 "order-cancel" "注文キャンセル" "注文"
-#   ./uc-next-start.sh --yes "task-management" "タスク管理機能追加" "タスク管理"
-# 引数仕様（位置引数）:
-#   [UC-ID] [SLUG] [TITLE] [CATEGORY]
-#   - UC-ID: 省略可（例: UC-2）
-#   - SLUG: 必須。識別用の短名（ASCII, kebab-case 推奨。ファイル名には使わず参考・一貫性のため）
-#   - TITLE: 必須。UC ファイル題名（日本語推奨）
-#   - CATEGORY: 必須。docs/02_ユースケース仕様/ 配下のカテゴリ名（日本語可）
-# 重要: 空欄の引数は禁止。SLUG/TITLE/CATEGORY は必ず指定する
-
-set -e
-REPO_ROOT="${REPO_ROOT:-$(git rev-parse --show-toplevel 2>/dev/null || echo ".")}"
-cd "$REPO_ROOT"
-
-git rev-parse --is-inside-work-tree >/dev/null 2>&1 || {
-  echo "Error: Git リポジトリ内で実行してください。" >&2
-  exit 1
-}
-
-YES_MODE=false
-ARGS=()
-for a in "$@"; do
-  case "$a" in
-    --yes|-y) YES_MODE=true ;;
-    *)
-      if [[ -z "$a" ]]; then
-        echo "Error: 空文字の引数は使用できません。UC-ID を省略する場合は引数自体を渡さないでください。" >&2
-        exit 1
-      fi
-      ARGS+=("$a")
-      ;;
-  esac
-done
-
-PROJECT_JSON="$REPO_ROOT/.spec-runner/project.json"
-[[ -f "$PROJECT_JSON" ]] || { echo "uc-next-start: project.json がありません: $PROJECT_JSON" >&2; exit 1; }
-command -v jq >/dev/null 2>&1 || { echo "uc-next-start: jq が必要です（brew install jq）" >&2; exit 1; }
-UC_ID_RE="$(jq -r '.naming.uc_id_pattern' "$PROJECT_JSON")"
-[[ -n "$UC_ID_RE" && "$UC_ID_RE" != "null" ]] || {
-  echo "uc-next-start: project.json の naming.uc_id_pattern が未設定です" >&2
-  exit 1
-}
-
-next_uc_id_for_category() {
-  local category="$1"
-  local dir="$REPO_ROOT/docs/02_ユースケース仕様/${category}"
-  mkdir -p "$dir"
-  local max=0
-  for f in "$dir"/UC-*.md; do
-    [[ -e "$f" ]] || continue
-    base=$(basename "$f" .md)
-    if [[ "$base" =~ ^(${UC_ID_RE})- ]]; then
-      uc_id="${BASH_REMATCH[1]}"
-      digits=$(echo "$uc_id" | tr -cd '0-9')
-      [[ -z "$digits" ]] && continue
-      n=$((10#$digits))
-      [[ $n -gt $max ]] && max=$n
-    fi
-  done
-  printf "UC-%d\n" $((max + 1))
-}
-
-NEXT_UC=""
-UC_ID_EXPLICIT=0
-SLUG=""
-TITLE=""
-CATEGORY=""
-if [[ ${#ARGS[@]} -ge 1 ]] && [[ "${ARGS[0]}" =~ ^${UC_ID_RE}$ ]]; then
-  [[ ${#ARGS[@]} -eq 4 ]] || {
-    echo "Usage: .spec-runner/scripts/uc-next-start.sh [UC-ID] \"SLUG\" \"TITLE\" \"CATEGORY\" [--yes]" >&2
-    echo "  - UC-ID を指定した場合は SLUG/TITLE/CATEGORY の3引数が必須です" >&2
-    exit 1
-  }
-  NEXT_UC="${ARGS[0]}"
-  UC_ID_EXPLICIT=1
-  SLUG="${ARGS[1]}"
-  TITLE="${ARGS[2]}"
-  CATEGORY="${ARGS[3]}"
-else
-  [[ ${#ARGS[@]} -eq 3 ]] || {
-    echo "Usage: .spec-runner/scripts/uc-next-start.sh [UC-ID] \"SLUG\" \"TITLE\" \"CATEGORY\" [--yes]" >&2
-    echo "  - UC-ID は任意、SLUG/TITLE/CATEGORY は必須です（空文字禁止）" >&2
-    exit 1
-  }
-  SLUG="${ARGS[0]}"
-  TITLE="${ARGS[1]}"
-  CATEGORY="${ARGS[2]}"
-fi
-
-if [[ -z "$SLUG" || -z "$TITLE" || -z "$CATEGORY" ]]; then
-  echo "Usage: .spec-runner/scripts/uc-next-start.sh [UC-ID] \"SLUG\" \"TITLE\" \"CATEGORY\" [--yes]" >&2
-  echo "  - UC-ID は任意、SLUG/TITLE/CATEGORY は必須です（空文字禁止）" >&2
-  exit 1
-fi
-
-SLUG=$(echo "$SLUG" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/--*/-/g' | sed 's/^-*//' | sed 's/-*$//')
-if [[ -z "$SLUG" ]]; then
-  echo "Error: SLUG は英数字・ハイフンへ正規化可能な値を指定してください（例: task-management）。" >&2
-  exit 1
-fi
-
-DOC_TITLE="$TITLE"
-DOC_TITLE=$(echo "$DOC_TITLE" | sed 's/[\\\\\\/\\:\\*\\?\\\"\\<\\>\\|]/ /g' | sed 's/[[:space:]]\\+/ /g' | sed 's/^ *//; s/ *$//')
-if [[ -z "$DOC_TITLE" ]]; then
-  echo "Error: TITLE が不正です（危険文字除去後に空になりました）。" >&2
-  exit 1
-fi
-
-CATEGORY=$(echo "$CATEGORY" | sed 's/[\\\/:\*\?"<>|]//g' | sed 's/[[:cntrl:]]//g' | sed 's/[[:space:]]\+/ /g' | sed 's/^ *//; s/ *$//')
-if [[ -z "$CATEGORY" ]]; then
-  echo "Error: CATEGORY は空にできません。" >&2
-  exit 1
-fi
-
-if [[ $UC_ID_EXPLICIT -eq 0 ]]; then
-  NEXT_UC="$(next_uc_id_for_category "$CATEGORY")"
-fi
-
-FEATURE_DIR="docs/02_ユースケース仕様/${CATEGORY}"
-UC_DOC="${FEATURE_DIR}/${NEXT_UC}-${DOC_TITLE}.md"
-
-if [[ -f "$UC_DOC" ]]; then
-  echo "Error: 既に存在します: $UC_DOC" >&2
-  exit 1
-fi
-
-UC_ID_PATTERN="^${UC_ID_RE}$"
-if ! echo "$NEXT_UC" | grep -qE "$UC_ID_PATTERN"; then
-  echo "Error: UC-ID が命名規則に合いません: $NEXT_UC（期待: $UC_ID_PATTERN）" >&2
-  exit 1
-fi
-
-if [[ "$YES_MODE" != true ]]; then
-  echo "次の UC 仕様のひな形を作成します（ブランチは作成しません）。"
-  echo "  → $UC_DOC"
-  echo -n "  実行してよろしいですか？ [y/N]: "
-  read -r ans
-  case "$ans" in
-    [yY]|[yY][eE][sS]) ;;
-    *) echo "キャンセルしました。"; exit 0 ;;
-  esac
-fi
-
-mkdir -p "$FEATURE_DIR"
-mkdir -p "${FEATURE_DIR}/判断記録"
-TEMPLATE="$REPO_ROOT/.spec-runner/templates/UC-N-ユースケース名.md"
-if [[ -f "$TEMPLATE" ]]; then
-  sed "s/UC-N/${NEXT_UC}/g; s/{ユースケース名}/${DOC_TITLE}/g" "$TEMPLATE" > "$UC_DOC"
-  echo "Created: $UC_DOC"
-else
-  touch "$UC_DOC"
-  echo "# ${NEXT_UC}: ${DOC_TITLE}" >> "$UC_DOC"
-  echo "Created: $UC_DOC"
-fi
-
-echo ""
-echo "UC 仕様の準備ができました（現在のブランチは変更していません）。次のステップに進んでください。"

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

@@ -1,29 +0,0 @@
-#!/usr/bin/env bash
-# spec-runner エントリポイント。次のステップ（現在フェーズ・やるべきステップ .md）を返す。
-# 使用: .spec-runner/spec-runner.sh [次のステップ] [--json|--lock]
-
-set -e
-REPO_ROOT="${REPO_ROOT:-$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)}"
-cd "$REPO_ROOT"
-SR="$REPO_ROOT/.spec-runner/scripts"
-
-cmd="${1:-}"
-shift || true
-
-case "$cmd" in
-  次のステップ|"")
-    if [[ "$cmd" == "" ]]; then
-      # 引数なしは「次のステップ」として扱う（/spec-runner スラッシュコマンド用）
-      :
-    fi
-    case "${1:-}" in
-      --lock)   exec "$SR/spec-runner-core.sh" --status ;;
-      *)        exec "$SR/spec-runner-core.sh" --phase "$@" ;;
-    esac
-    ;;
-  *)
-    echo "spec-runner: 引数なし、または「次のステップ」[--json|--lock] のみ対応しています。" >&2
-    echo "  使用例: .spec-runner/spec-runner.sh 次のステップ --json" >&2
-    exit 1
-    ;;
-esac

package/templates/.spec-runner/steps/steps.json

@@ -1,96 +0,0 @@
-{
-  "version": 2,
-  "note": "薄いオーケストレータ向け steps 定義。主線6本（実行フェーズ5本 + 憲章）+ 横断2本（clarify/analyze）。",
-  "common": {
-    "docs": {
-      "root": "docs",
-      "work_card": "docs/work.md",
-      "charter": "docs/01_憲章/憲章.md",
-      "uc_root": "docs/02_ユースケース仕様",
-      "domain_root": "docs/03_ドメイン設計",
-      "architecture_root": "docs/04_アーキテクチャ",
-      "infra_root": "docs/05_インフラ設計",
-      "api_root": "docs/06_API仕様",
-      "openapi": "docs/06_API仕様/openapi.yaml"
-    },
-    "commands": {
-      "check": ".spec-runner/scripts/check.sh",
-      "start_next_uc": ".spec-runner/scripts/uc-next-start.sh"
-    }
-  },
-  "steps": [
-    {
-      "id": "charter",
-      "name_ja": "憲章",
-      "phase": 0,
-      "md_file": "憲章.md",
-      "commands": [{ "id": "check", "command": ".spec-runner/scripts/check.sh" }],
-      "primary_outputs": ["docs/01_憲章/憲章.md", "docs/work.md"]
-    },
-    {
-      "id": "uc_spec",
-      "name_ja": "仕様策定",
-      "phase": 1,
-      "md_file": "仕様策定.md",
-      "commands": [
-        { "id": "start_uc_spec_scaffold", "command": ".spec-runner/scripts/uc-next-start.sh" },
-        { "id": "check", "command": ".spec-runner/scripts/check.sh" }
-      ],
-      "primary_outputs": ["docs/02_ユースケース仕様/<カテゴリ>/UC-<N>-<題名>.md", "docs/work.md"]
-    },
-    {
-      "id": "domain",
-      "name_ja": "ドメイン設計",
-      "phase": 2,
-      "md_file": "ドメイン設計.md",
-      "commands": [{ "id": "check", "command": ".spec-runner/scripts/check.sh" }],
-      "primary_outputs": [
-        "docs/03_ドメイン設計/ユビキタス言語辞書.md",
-        "docs/03_ドメイン設計/ドメインモデル.md",
-        "docs/03_ドメイン設計/集約.md",
-        "docs/work.md"
-      ]
-    },
-    {
-      "id": "architecture_plan",
-      "name_ja": "実装計画",
-      "phase": 3,
-      "md_file": "実装計画.md",
-      "commands": [{ "id": "check", "command": ".spec-runner/scripts/check.sh" }],
-      "primary_outputs": ["docs/04_アーキテクチャ/*", "docs/work.md"],
-      "secondary_outputs_optional": ["docs/06_API仕様/openapi.yaml"]
-    },
-    {
-      "id": "test_design",
-      "name_ja": "テスト設計",
-      "phase": 5,
-      "md_file": "テスト設計.md",
-      "commands": [{ "id": "check", "command": ".spec-runner/scripts/check.sh" }],
-      "primary_outputs": ["<test_design.dir>/**/*.spec.*", "docs/work.md"]
-    },
-    {
-      "id": "implement",
-      "name_ja": "実装",
-      "phase": 6,
-      "md_file": "実装.md",
-      "commands": [{ "id": "check", "command": ".spec-runner/scripts/check.sh" }],
-      "primary_outputs": ["src/**", "<tests green>", "docs/work.md"]
-    },
-    {
-      "id": "clarify",
-      "name_ja": "曖昧さ解消",
-      "phase": null,
-      "md_file": "曖昧さ解消.md",
-      "commands": [{ "id": "check", "command": ".spec-runner/scripts/check.sh" }],
-      "primary_outputs": ["(target spec update)", "docs/work.md"]
-    },
-    {
-      "id": "analyze",
-      "name_ja": "分析",
-      "phase": null,
-      "md_file": "分析.md",
-      "commands": [{ "id": "check", "command": ".spec-runner/scripts/check.sh" }],
-      "primary_outputs": ["(analysis report)", "docs/work.md"]
-    }
-  ]
-}

package/templates/.spec-runner/steps//343/203/206/343/202/271/343/203/210/350/250/255/350/250/210.md

@@ -1,58 +0,0 @@
----
-step_id: test_design
-phase: 5
-primary_output: project.json の test_design.dir（既定 tests）
----
-
-# テスト設計（Phase 5: TEST DESIGN）
-
-**やること**: UC 仕様と受入条件に基づき、**PENDING 状態のテストコード**を `test_design.dir`（既定 `tests`）に作成する。あわせて `docs/work.md` の実装タスク・検証結果を更新する。
-
-**機械的な前提**（`project.json` の `test_design.require_uc_prefixed_tests` が true のとき）: ファイル名は **`UC-N-<slug>.spec.<ext>`**（対象 UC の番号と一致）にすること。true の場合だけ、**命名が無いと「次のステップ」は実装フェーズに進みません**。
-
-| 項目 | 内容 |
-|------|------|
-| **出力先** | `.spec-runner/project.json` の `test_design.dir`（既定: `tests`）、パターンは `test_design.pattern`（既定: `*.spec.*`）。Python は `test_*.py` 等に変更可 |
-| **ドキュメント** | **読み取り専用**（test_design.dir への**追加のみ**）。UC 仕様の修正は「曖昧さ解消」等で別途 |
-| **命名** | （推奨） `UC-N-{ユースケース名}.spec.{拡張子}` 。`test_design.require_uc_prefixed_tests=true` のときだけ必須。 |
-| **ピラミッド** | spec セクション 14: Unit : Integration : E2E ≈ 70 : 20 : 10。E2E は UC 1 本あたり最大 2 本目安 |
-
-## ユーザー入力
-
-`$ARGUMENTS`（空でなければ必ず考慮）
-
-```text
-$ARGUMENTS
-```
-
-## 実行フロー
-
-1. **セットアップ**  
-   リポジトリルートで `.spec-runner/spec-runner.sh 次のステップ --json`。JSON の `feature_spec`・`feature_dir` を使用。
-
-2. **UC 仕様の読み込み**
-   - FEATURE_SPEC から受入条件・成功基準・ユーザーストーリーを抽出
-   - `docs/04_アーキテクチャ/命名規則.md` の SOURCE_EXTENSIONS でテスト拡張子（例: ts → `.spec.ts`）
-   - `feature_spec` のファイル名から UC 番号と識別名を決める（例: `UC-1-注文作成.md` → UC-1, order-placement）
-
-3. **配置と命名**
-   - ベース: **`project.json` の `test_design.dir`**、パターンは `test_design.pattern`
-- `test_design.require_uc_prefixed_tests=true` の場合:
-  - ユニット/UC: `{dir}/unit/UC-N-{名}.spec.{ext}`（例: `tests/unit/UC-1-order-placement.spec.ts`）
-  - E2E: `{dir}/e2e/UC-N-{名}.e2e.spec.{ext}`
-   - 集約不変条件: `{dir}/unit/{集約名}.invariants.spec.{ext}`
-- `false` の場合: `test_design.pattern` に合致するテストファイル名であれば任意（ディレクトリ構造は既存に合わせる）
-
-4. **PENDING で記述**
-   - 受入条件・成功基準ごとに **スキップ/TODO**（`it.todo` / `test.skip` / `@pending` 等）
-   - 説明文は UC の受入・成功基準と対応。アサーションは仮で可（Phase 6 でグリーン）
-   - **E2E**: 当該 UC のハッピーパスを 1 本以上 PENDING。Phase 6 完了時は**少なくとも 1 本グリーン**を目標
-
-5. **コンパイル・実行確認**  
-   プロジェクトのテストコマンドでコンパイル通過、PENDING がスキップされて実行できること。Gate 5 は「テストコード存在 + コンパイル通過」。
-
-6. **報告**  
-   作成ファイル一覧と UC・受入条件の対応表。続けて「分析」「チェックリスト」→ 人間承認後 **AI が phase-locks 更新** → Phase 6 へ、と案内。
-
----
-**次**: 完了後、次のステップへ進む。

package/templates/.spec-runner/steps//343/203/211/343/203/241/343/202/244/343/203/263/350/250/255/350/250/210.md

@@ -1,52 +0,0 @@
----
-step_id: domain
-phase: 1
-primary_output: docs/03_ドメイン設計/
----
-
-# ドメイン設計（Domain）
-
-**やること**: `docs/03_ドメイン設計/` にユビキタス言語・ドメインモデル・集約等を整備する。完了後、レビュー通過で `phase-locks.json` の `domain` に `completed: true`。あわせて `docs/work.md` の実装タスクを更新する。
-
-| 項目 | 内容 |
-|------|------|
-| **成果物** | `docs/03_ドメイン設計/` 配下の各ファイル |
-| **テンプレ** | 無い場合は `.spec-runner/templates/` から `ユビキタス言語辞書.md`, `ドメインモデル.md`, `集約.md` 等を生成してから編集 |
-| **ロック** | 設計書本文に `status: reviewed` は書かない（phase-locks のみ） |
-
-## ユーザー入力
-
-`$ARGUMENTS`（空でなければ必ず考慮）
-
-```text
-$ARGUMENTS
-```
-
-## 前提条件
-
-| 状況 | 行動 |
-|------|------|
-| `docs/03_ドメイン設計/` が無い | このフェーズで**新規作成**し、各ファイルを配置する（フェーズごとにフォルダを1つずつ作る想定） |
-| ファイルが無い | テンプレから生成してから編集 |
-
-## 実行フロー
-
-1. **成果物の確認**（spec.md Phase 1 に沿っているか）
-   - `ユビキタス言語辞書.md`（禁止語欄付き）
-   - `ドメインモデル.md`
-   - `集約.md`（各集約に**「対応テーブル」**欄）
-   - 必要に応じて `エンティティ.md`・`値オブジェクト.md`
-
-2. **編集・追記**  
-   ユーザー指示や UC で発見した新概念に基づき上記を更新。骨格（主要集約と境界）を確定し、必要に応じて後続で肉付けする。
-   不明は推測で確定せず **`[要確認: ...]`** を残す（例: `[要確認: 集約境界の決め手（更新頻度/整合性要件）]`）。
-
-3. **レビュー通過後**  
-   **AI が** `.spec-runner/phase-locks.json` の `domain` に `completed: true` と `locked_at` を設定。
-
-## 重要ルール
-
-- **集約.md** の各集約に **対応テーブル（schema.dbml との対応）** 欄を必ず含める（spec.md Phase 1 ゲート）。
-
----
-**次**: 完了後、次のステップへ進む。

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

@@ -1,210 +0,0 @@
----
-step_id: spec
-phase: 3
-primary_output: docs/02_ユースケース仕様/<カテゴリ>/UC-N-xxx.md
----
-
-# ユースケース仕様（UC 仕様書）
-
-**やること**: 機能説明（`$ARGUMENTS`）から UC 仕様書を作成（または更新）し、テンプレに沿って埋める。その後 quality フロー（clarify → analyze）を回し、必要に応じて checklist を実施して review-pass へ進む。あわせて `docs/work.md` の受入条件・実装タスクを同期する。
-
-| 項目 | 内容 |
-|------|------|
-| **成果物** | `docs/02_ユースケース仕様/<カテゴリ>/UC-N-xxx.md`（1 UC = 1 本） |
-| **Git** | **フェーズごとにブランチを切る必要はない。** 今いるブランチで仕様を書いてよい。**コミットしたくなったタイミング**で、AI に `project.json` の naming に沿った**ブランチ名・コミットメッセージを相談し、checkout / 作成・コミットまで一緒にやってもらう**運用でよい |
-| **品質フロー** | `phase-locks.json` の `quality` を使って **clarify → analyze** を自動進行。必要なら checklist を追加で実施 |
-| **判断ログ（任意）** | `docs/02_.../<カテゴリ>/判断記録/UC-N-MMDD-題名.md`。テンプレ: `.spec-runner/templates/UC-N-MMDD-判断記録テンプレ.md` |
-
-**補足（spec-runner コア）**: テスト設計・実装フェーズは、ブランチではなく **UC 仕様と lock 状態**で判定されます。`uc_discovery.completed=false` の間は UC 作成フェーズを継続し、未レビュー UC がある場合は `clarify/analyze` を優先します。`spec-runner` はブランチを作りません。
-
-## ユーザー入力
-
-`$ARGUMENTS` が機能説明。空でコマンドしていない限り、繰り返し入力を求めない。
-ただし **`$ARGUMENTS` が空** の場合は停止せず、AI 側で候補提案を行ってユーザー選択に進む。
-
-```text
-$ARGUMENTS
-```
-
-## フォルダの作成
-
-- **`docs/02_ユースケース仕様/`** が無ければ新規作成。**カテゴリごとにフォルダ**（例: タスク管理、認証）を切り、その中に **UC-N-xxx.md を複数本**作る（カテゴリは 1 UC で終わらせない）。
-- `uc-next-start.sh` でカテゴリ指定するとそのフォルダ内に作成される。
-- **CRUD は原則別 UC**（作成 / 編集 / 削除を分ける）。同一フロー・同一権限・同一受入条件で差分が小さい場合のみ統合可。
-- 目安: 1カテゴリにつき最低 2〜3 UC。MVP は最小 1 UC でも可だが、次に必ず細分化候補を洗い出す。
-
-## 実行フロー
-
-### 0. スコープ判定と UC 分解提案（先に実施）
-
-- 入力が広いテーマ（例: 「タスク管理基盤」「認証基盤」「決済基盤」）の場合、**そのまま 1 UC を作らない**。
-- 先に AI が UC 分解案を提案し、ユーザー合意を取ってから UC を作成する。
-- 提案フォーマット（簡潔）:
-  - 候補 UC 一覧（`UC-候補: 目的 / 範囲 / 非対象`）
-  - 優先順（MVP から）
-  - まず作る 1 件（最小価値）
-- 合意後は **1 件ずつ** UC を追加する。土台づくりに **`uc-next-start.sh`**（仕様ひな形のみ）を使っても、手動で `UC-N-xxx.md` を置いてもよい（CRUD は原則別 UC）。
-
-### 0.5. 引数なし時の候補提示（必須）
-
-- 条件: `$ARGUMENTS` が空。
-- 挙動:
-  1. AI がこのプロジェクト向けの機能案を **3〜5 件**提示する。
-  2. 各案は 1 行で、`案N: 目的 / 主な利用者 / 想定カテゴリ` の形式で簡潔に示す。
-  3. 「番号で選択」または「自由入力で別案指定」を案内する。
-  4. **ユーザーが選ぶまで `uc-next-start.sh` を実行しない**。
-- ユーザー回答後:
-  - 選択された案（または自由入力文）を今回の機能説明として扱い、以降のステップを通常どおり実行する。
-
-### 1. 短名 SLUG（2〜4 語）
-
-- 機能説明からキーワード抽出。`uc-next-start.sh` の**第1引数（UC-ID 省略時）または第2引数**として必須。**ASCII のみ**、kebab-case（例: order-placement, user-auth）。スクリプトはファイル名には使わず、**人間・AI がブランチ名を考えるときのタグ**として使う。
-- **UC ファイル名は TITLE を使用**（`UC-<N>-<TITLE>.md`）。
-- 技術略語（OAuth2, API, JWT）はそのまま。`TITLE` は日本語で記述する。
-- 例: 「ユーザー認証」→ user-auth / 「OAuth2 API」→ oauth2-api-integration 等。
-
-### 2. UC 仕様の作成
-
-- `docs/01_憲章/憲章.md` は先に確定する。未コミット差分がある場合は、**コミットしたくなったら AI に差分確認・メッセージ案・コミットを依頼**する（憲章と UC を同じコミットにまとめる必要はない）。
-- **ショートカット**: `.spec-runner/scripts/uc-next-start.sh [UC-ID] "$SLUG" "$TITLE" "$CATEGORY" [--yes]` — **UC 仕様のひな形ファイルだけ**を所定フォルダに作成する（**Git のブランチ作成・checkout は行わない**）。**使わず**手動で `UC-N-xxx.md` を置いてもよい。
-- UC-ID は省略可（省略時は自動採番）。**SLUG / TITLE / CATEGORY は必須**（空文字禁止）。
-- CATEGORY で配置先が決まる（カテゴリ名は日本語可）。**機能ごとに 1 回だけ**。
-- シングルクォートはエスケープ（例: `'I'\''m Groot'`）またはダブルクォート。
-- 引数の実例:
-  - `./.spec-runner/scripts/uc-next-start.sh "task-management" "タスク管理機能追加" "タスク管理" --yes`
-  - `./.spec-runner/scripts/uc-next-start.sh UC-2 "order-cancel" "注文キャンセル" "注文" --yes`
-  - `./.spec-runner/scripts/uc-next-start.sh UC-3 "task-import" "タスク一括登録" "タスク管理" --yes`
-
-### 3. テンプレ読込
-
-`.spec-runner/templates/UC-N-ユースケース名.md` で必須セクションを把握。
-
-### 4. 本文生成の内訳
-
-1. 入力パース。空なら「0.5 引数なし時の候補提示」を実施し、選択後に続行する（即 ERROR にしない）
-2. 重要概念（アクター・アクション・データ・制約）
-3. 不明点: **推測で確定しない** → **`[要確認: ...]`**。付けるのは影響大・解釈複数・デフォルト無しのときのみ。**上限 3 個**。優先: スコープ > セキュリティ > UX > 技術詳細
-4. 「ユーザーシナリオとテスト」を埋める。フロー特定できなければ ERROR
-5. 機能要件（テスト可能）。仮定は「仮定」セクションへ
-6. 成功基準（測定可能・技術非依存・定量+定性）
-7. データが関わる場合は主要エンティティ
-8. SUCCESS（計画の準備完了）
-
-### 5. 書き込み
-
-テンプレ構造を保ち、プレースホルダを具体内容で置換し **SPEC_FILE** に保存。
-
-### 6. 仕様品質検証
-
-**a. チェックリスト（任意）**  
-checklists を使う場合のみ `FEATURE_DIR/checklists/requirements.md` を生成。UC のみなら **checklists/ 不要**。作成例は **付録 A**。
-
-**b.** 各チェック項目で合格/不合格を判定し問題を記録。
-
-**c. 結果の扱い**
-
-- 全合格 → ステップ 7 へ
-- 不合格（[要確認] 以外）: 列挙→仕様更新→最大 3 回反復。残りは注記と警告
-- **[要確認] 残り**: 抽出→3 個超なら影響大 3 個に整理→ユーザーへ質問表（**付録 B** 形式）。Q1–Q3 まで一括提示→回答後に置換→再検証
-
-**d.** 反復ごとにチェックリストファイルを更新
-
-### 7. 完了報告
-
-仕様パス・チェックリスト結果・次フェーズ（曖昧さ解消 / 実装計画）の準備状況。
-
-※ 分解提案を経た場合は、採用された UC 分割案（採用順）も合わせて報告する。
-
-※ **UC 洗い出しが完了したら** `./.spec-runner/phase-locks.json` の `uc_discovery.completed` を `true` にする（以降 `domain` に進む）。
-
-**注**: `uc-next-start.sh` は仕様ファイルの生成のみ。現在のブランチは変わらない。
-
-## 付録 A: 仕様品質チェックリスト例
-
-```markdown
-# 仕様品質チェックリスト: [機能名]
-
-**目的**: 計画に進む前に仕様の完全性・品質を検証する
-**作成日**: [日付]
-**機能**: [spec.md へのリンク]
-
-## コンテンツ品質
-
-- [ ] 実装詳細（言語・フレームワーク・API）が含まれていない
-- [ ] ユーザー価値とビジネスニーズに焦点がある
-- [ ] 非技術のステークホルダー向けに書かれている
-- [ ] 必須セクションがすべて完了している
-
-## 要件の完全性
-
-- [ ] [要確認] マーカーが残っていない
-- [ ] 要件がテスト可能で曖昧でない
-- [ ] 成功基準が測定可能
-- [ ] 成功基準が技術に依存しない（実装詳細なし）
-- [ ] 受入シナリオがすべて定義されている
-- [ ] エッジケースが特定されている
-- [ ] スコープが明確に境界づけされている
-- [ ] 依存関係と仮定が特定されている
-
-## 機能の準備状況
-
-- [ ] 全機能要件に明確な受入基準がある
-- [ ] ユーザーシナリオが主要フローをカバーしている
-- [ ] 成功基準で定義した測定可能な結果を満たしている
-- [ ] 仕様に実装詳細が混入していない
-
-## 注記
-
-- 未完了の項目は「曖昧さ解消」または「実装計画」の前に仕様を更新すること
-```
-
-## 付録 B: [要確認] 用質問表フォーマット
-
-```markdown
-## 質問 [N]: [トピック]
-
-**文脈**: [該当仕様セクションの引用]
-
-**確認したいこと**: [要確認マーカーからの具体的な質問]
-
-**回答案**:
-
-| 選択肢 | 回答 | 影響 |
-|--------|------|------|
-| A | [第1案] | [機能への影響] |
-| B | [第2案] | [機能への影響] |
-| C | [第3案] | [機能への影響] |
-| 独自 | 自分で回答する | [独自入力の方法] |
-
-**選択**: _[ユーザー応答を待つ]_
-```
-
-表のパイプを揃え、区切りは `|--------|` 以上。**質問は Q1–Q3 を一度に出し**、全回答後に仕様を更新。
-
-## 付録 C: ガイドライン
-
-- **WHAT / WHY** に集中。**HOW（実装）**は書かない
-- ビジネス担当者向け。仕様に埋め込みチェックリストは作らない（別コマンド）
-- **必須セクション**は全機能で完了。**任意**は該当時のみ。N/A で残さず削除
-
-### AI 生成時
-
-1. 推測で確定しない → `[要確認]`
-2. 仮に進める場合のみ「仮定」に明示
-3. [要確認] は最大 3（スコープ・解釈・デフォルト無しの重要判断のみ）
-4. 優先: スコープ > セキュリティ > UX > 技術詳細
-5. テスター目線で曖昧要件は不合格にできるように
-
-**推測してよい例**（通常は質問しない）: データ保持の業界標準、一般 Web 性能目標、分かりやすいエラー表現、Web ならセッション/OAuth2、連携は REST/GraphQL 等プロジェクト準拠。
-
-### 成功基準
-
-- 測定可能（時間・割合・件数等）、技術非依存、ユーザー/ビジネス結果、実装を知らず検証可能
-- 受入条件は日本語フォーマット（`前提` / `操作` / `期待`）で記述する。複数件は表形式（`| 前提 | 操作 | 期待 |`）を使用する
-
-**良い例**: 「3 分以内にチェックアウト」「1 万同時ユーザー」「検索 95% が 1 秒以内」
-
-**悪い例**: API 200ms、DB TPS、React 描画、Redis ヒット率（実装寄り）
-
----
-**次**: 完了後、次のステップへ進む。