@loviusc/sa-spec 0.1.0 → 0.2.0

package/package.json

@@ -1,7 +1,11 @@
 {
   "name": "@loviusc/sa-spec",
-  "version": "0.1.0",
+  "version": "0.2.0",
   "description": "Personal system analysis documentation workspace CLI",
+  "publishConfig": {
+    "access": "public",
+    "registry": "https://registry.npmjs.org/"
+  },
   "bin": {
     "sa-spec": "bin/sa-spec.js"
   },

package/readme.md

@@ -2,14 +2,14 @@
 
 `sa-spec` 是一個輕量的系統分析文件工作台，用固定流程把需求想法整理成可確認、可歸檔、可檢查的文件。
 
-AI 工作流只使用四個指令：
+AI 工作流只使用四個指令，並支援簡寫別名（兩者等價）：
 
-```text
-spec:init
-spec:propose
-spec:analyze
-spec:commit
-```
+| 標準指令 | 簡寫 | 說明 |
+|---|---|---|
+| `spec:init` | `sci` | 初始化專案與規則 |
+| `spec:propose` | `scp` | 提出需求並整理摘要 |
+| `spec:analyze` | `sca` | 衝突檢查與規格起草 |
+| `spec:commit` | `scc` | 確認歸檔並建立 Git commit |
 
 每個需求歸檔後固定包含：
 
@@ -17,7 +17,8 @@ spec:commit
 project/
   REQ-001-login/
     srs.md
-    uml.puml
+    uml/
+      main.puml
     openapi.yaml
     db-schema.md
     handoff.md
@@ -236,10 +237,13 @@ sa-spec init --full
 |---|---|
 | `sa-spec init` | 建立最小文件骨架。 |
 | `sa-spec init --full` | 建立文件骨架與完整規則文件。 |
-| `sa-spec new --id REQ-001 --name login` | 建立需求資料夾與空白文件模板，包含 SRS、UML、OpenAPI、DB Schema、handoff 與 history。 |
+| `sa-spec new [--id REQ-001] --name login [--branch]` | 建立需求資料夾與空白文件模板（未帶 `--id` 時啟用多人草稿模式，可選 `--branch` 自動建立並切換至 `feat/<name>` 分支）。 |
+| `sa-spec finalize --name login` | 將草稿需求定號歸檔為最新序號（自動計算最新號碼、重命名目錄、批次置換 `{{REQ_ID}}` 並重建索引）。 |
+| `sa-spec reindex` | 掃描 `project/REQ-*` 目錄，依序號重新生成乾淨無衝突的 `project/index.md`。 |
 | `sa-spec check` | 檢查基本文件是否存在。 |
 | `sa-spec status` | 顯示系統規格與需求索引狀態。 |
 | `sa-spec doctor` | 檢查必要檔案是否存在。 |
+| `sa-spec upgrade [--dry-run]` | 將既有專案升級為最新版本：同步最新 AGENTS 與規則文件，並將既有需求中的 `uml.puml` 自動遷移為 `uml/main.puml`。 |
 
 `sa-spec new` 是快速建空白模板的輔助工具。正式需求流程仍建議使用 `spec:init`、`spec:propose`、`spec:analyze`、`spec:commit`。
 
@@ -259,7 +263,7 @@ sa-spec init --full
 | AI 對話 | Claude Code 類型的 VS Code AI 套件或 CLI 整合 | 擇一 | 用 Claude 讀取工作區規則並協作產出需求文件。 |
 | AI 對話 | Gemini 類型的 VS Code AI 套件或 CLI 整合 | 擇一 | 用 Gemini 讀取工作區規則並協作產出需求文件。 |
 | Markdown | Markdown 預覽或 Markdown All in One 類型套件 | 選用 | 預覽 `srs.md`、`history.md`、`system-spec.md`。 |
-| UML | PlantUML 類型套件 | 選用 | 預覽 `uml.puml`。 |
+| UML | PlantUML 類型套件 | 選用 | 預覽需求內的 `uml/*.puml`。 |
 | YAML | YAML 類型套件 | 選用 | 編輯與檢查 `openapi.yaml`。 |
 | Git | GitLens 類型套件 | 選用 | 查看需求文件修改歷程。 |
 
@@ -280,10 +284,10 @@ Markdown、PlantUML、YAML、GitLens 這類套件可以提升閱讀與檢查體
 | CLI | `sa-spec init --full` | 終端機或 VS Code Terminal | 建立文件骨架與規則檔。 |
 | CLI | `sa-spec check` | 終端機或 VS Code Terminal | 檢查必要文件是否存在。 |
 | CLI | `sa-spec status` | 終端機或 VS Code Terminal | 查看系統規格與需求索引狀態。 |
-| AI 工作流程 | `spec:init` | VS Code AI 對話側邊欄 | 載入規則並確認工作區狀態。 |
-| AI 工作流程 | `spec:propose` | VS Code AI 對話側邊欄 | 整理使用者提出的需求。 |
-| AI 工作流程 | `spec:analyze` | VS Code AI 對話側邊欄 | 檢查衝突並產出待確認草稿。 |
-| AI 工作流程 | `spec:commit` | VS Code AI 對話側邊欄 | 歸檔已確認版本並建立本機 Git commit。 |
+| AI 工作流程 | `spec:init` / `sci` | VS Code AI 對話側邊欄 | 載入規則並確認工作區狀態。 |
+| AI 工作流程 | `spec:propose` / `scp` | VS Code AI 對話側邊欄 | 整理使用者提出的需求。 |
+| AI 工作流程 | `spec:analyze` / `sca` | VS Code AI 對話側邊欄 | 檢查衝突並產出待確認草稿。 |
+| AI 工作流程 | `spec:commit` / `scc` | VS Code AI 對話側邊欄 | 歸檔已確認版本並建立本機 Git commit。 |
 
 建議操作順序：
 
@@ -297,32 +301,32 @@ code .
 接著在 VS Code 的 AI 對話側邊欄輸入：
 
 ```text
-spec:init
-spec:propose
-spec:analyze
-spec:commit
+spec:init    # 或簡寫 sci
+spec:propose # 或簡寫 scp
+spec:analyze # 或簡寫 sca
+spec:commit  # 或簡寫 scc
 ```
 
 如果你有安裝 prompts 或 slash commands，可以用對應的快捷指令；沒有安裝也可以直接手動輸入上面的文字指令。
 
 ## AI 工作流程
 
-| 指令 | 用途 |
-|---|---|
-| `spec:init` | 初始化並載入 `AGENTS.md`、`skills/system-analysis/SKILL.md` 與必要規則。 |
-| `spec:propose` | 使用者提出需求後，整理需求摘要、目標、初步流程與待確認事項。 |
-| `spec:analyze` | 檢查是否與既有需求衝突；無衝突才產出 SRS、UML、OpenAPI、DB Schema 草稿。 |
-| `spec:commit` | 使用者確認無衝突版本後，將版本歸檔到 `project/`，並建立本機 Git commit。 |
+| 指令 | 簡寫 | 用途 |
+|---|---|---|
+| `spec:init` | `sci` | 初始化並載入 `AGENTS.md`、`skills/system-analysis/SKILL.md` 與必要規則。 |
+| `spec:propose` | `scp` | 使用者提出需求後，整理需求摘要、目標、初步流程與待確認事項。 |
+| `spec:analyze` | `sca` | 檢查是否與既有需求衝突；無衝突才產出 SRS、UML、OpenAPI、DB Schema 草稿。 |
+| `spec:commit` | `scc` | 使用者確認無衝突版本後，將版本歸檔到 `project/`，並建立本機 Git commit。 |
 
 狀態機：
 
 ```text
-init -> propose -> analyze
+init (sci) -> propose (scp) -> analyze (sca)
 
-analyze 無衝突 -> 產出待確認版本 -> commit
-analyze 有衝突 -> 釐清問題 -> analyze
+analyze 無衝突 -> 產出待確認版本 -> commit (scc)
+analyze 有衝突 -> 釐清問題 -> analyze (sca)
 
-commit -> 歸檔 -> 本機 Git commit
+commit (scc) -> 歸檔 -> 本機 Git commit
 ```
 
 `spec:analyze` 若發現衝突，只會列出衝突與待釐清問題，不會修改任何需求文件，也不會產出最終文件。釐清後應再次執行 `spec:analyze`，重新檢查並產出草稿。
@@ -334,7 +338,7 @@ commit -> 歸檔 -> 本機 Git commit
 ```text
 請先閱讀 project/REQ-001-pomodoro-timer/handoff.md。
 以 handoff.md 作為本次開發入口與限制摘要。
-如需完整需求細節，再查閱同資料夾內的 srs.md、uml.puml、openapi.yaml、db-schema.md 與 history.md。
+如需完整需求細節，再查閱同資料夾內的 srs.md、uml/、openapi.yaml、db-schema.md 與 history.md。
 不得自行新增 handoff.md 未確認的角色、權限、流程、狀態、API 或 DB 欄位。
 若發現 handoff.md 與既有程式或規格衝突，請停止開發並回報。
 ```
@@ -347,6 +351,64 @@ docs(REQ-001): 番茄時鐘 - 新增專注與休息計時需求
 
 只有在使用者明確要求推送 remote，或專案設定啟用 auto-push 時，才會執行 `git push`。如果 push 失敗，只回報認證或網路問題，不會回滾已完成的文件歸檔與本機 commit。
 
+## 多人協作解決方案（Git-Flow 與延遲綁定 ID）
+
+在單人開發時，循序流水號（`REQ-001`、`REQ-002`）簡單直覺；但在多人平行協作時，容易引發兩大痛點：
+1. **序號競爭撞車**：Alice 與 Bob 同時在各自的分支開發，雙方本機都取了 `REQ-003`，合併回主幹時發生目錄重名衝突。
+2. **中心化檔案衝突**：每次歸檔都要修改 `project/index.md`，導致頻繁的 Git merge conflict。
+
+`sa-spec v0.2.0` 引進 **「Feature Branch 隔離 + 延遲綁定序號（Late-Binding ID）」** 完整解決方案：
+
+```mermaid
+flowchart TD
+    A[開新需求: sa-spec new --name cart --branch] --> B[建立並切換至 feat/cart 分支<br/>以 project/cart/ 建立草稿目錄]
+    B --> C[AI 分析與起草: sca<br/>內部使用 {{REQ_ID}} 佔位<br/>自動同步 master 規格防護]
+    C --> D{使用者確認通過<br/>執行 scc 或 finalize}
+    D --> E[查詢 master 最新序號 N]
+    E --> F[重命名為 project/REQ-N+1-cart/<br/>批次置換 {{REQ_ID}} 為正式號碼]
+    F --> G[sa-spec reindex: 動態重構 index.md]
+    G --> H[合併回 master: 零衝突、序號永遠連續！]
+```
+
+### 多人協作四步流程
+
+#### 1. 提出需求（草稿與分支隔離）
+開需求時**不搶序號**，直接以語意名稱建立分支與草稿目錄：
+
+```bash
+# 自動建立並切換至 feat/cart-checkout 分支，建立 project/cart-checkout/ 草稿目錄
+sa-spec new --name cart-checkout --branch
+```
+在 VS Code 側邊欄輸入：
+```text
+scp 購物車結帳需求
+```
+* **特點**：目錄名稱為 `project/cart-checkout/`，內部所有檔案皆使用 `{{REQ_ID}}` 佔位符。多人同時提出需求互不干擾、零衝突。即使需求中途放棄，直接刪除分支即可，絕不留下幽靈跳號。
+
+#### 2. 分析與衝突檢查（規格基線同步）
+在分支上執行 `spec:analyze`（或 `sca`）前，工具會確認已取得 `master`（或 `origin/master`）的最新規格，確保是以全專案最新基準進行影響評估，避免因分支落後而漏檢權限、API 或資料表衝突。
+
+#### 3. 確認歸檔與延遲定號（Late-Binding）
+當需求規格確認無誤，準備歸檔時：
+
+```bash
+# 自動向 master 查詢最新可用序號（例如 REQ-006）
+sa-spec finalize --name cart-checkout
+```
+* **自動化執行**：
+  1. 取得最新序號（例如目前最大是 `REQ-005`，自動取得 `REQ-006`）。
+  2. 使用 `git mv` 將目錄重命名為 `project/REQ-006-cart-checkout`。
+  3. 自動掃描並將目錄內所有檔案的 `{{REQ_ID}}` 批次置換為 `REQ-006`。
+  4. 自動執行 `reindex` 重建需求總表。
+
+#### 4. 消除索引合併衝突（`sa-spec reindex`）
+`project/index.md` 改為由目錄動態生成的「衍生清單」，不再依賴脆弱的手動 append：
+
+```bash
+sa-spec reindex
+```
+* 任何時候若有 PR 合併產生 index 衝突，只要執行 `sa-spec reindex`，即可依序號重新排序生成乾淨的總表，無需人工手動解 conflict。
+
 ## 完整範例：番茄時鐘
 
 以下示範從空資料夾開始，建立一個「番茄時鐘」需求。
@@ -520,7 +582,8 @@ project/
   system-spec.md
   REQ-001-pomodoro-timer/
     srs.md
-    uml.puml
+    uml/
+      state.puml
     openapi.yaml
     db-schema.md
     handoff.md
@@ -591,3 +654,39 @@ git push origin master
 - `project/system-spec.md` 只能在 `spec:commit` 依使用者確認內容更新。
 - `spec:commit` 會自動建立本機 Git commit；remote push 需使用者明確要求或啟用 auto-push。
 - 一次最多問 3 個待確認問題，優先詢問會影響範圍、資料、權限、API、DB 或驗收的問題。
+
+## 更新紀錄
+
+### v0.2.0
+- **多人協作 Git-Flow 解決方案（延遲綁定序號與零衝突索引）**：
+  - **解決痛點**：多人平行開發時，傳統流水號（`REQ-001`）容易在各自分支撞車，且中心化的 `project/index.md` 容易造成 Git merge conflict。
+  - **延遲綁定序號（Late-Binding ID）**：開需求時不搶號，在 feature branch 上以語意名稱建立草稿需求（如 `project/cart`），內部使用 `{{REQ_ID}}` 佔位；只有在 `spec:commit` 最終歸檔時，才向 master/遠端確認最新可用序號並定號（如 `REQ-003`），自動批次置換佔位符，徹底避免幽靈跳號與序號競爭。
+  - **動態重建需求索引（`sa-spec reindex`）**：將 `project/index.md` 改為根據 `project/REQ-*` 目錄動態掃描並依序號排序生成，消除手動 append 造成的 Git 合併衝突。
+  - **CLI 指令升級**：
+    - `sa-spec new [--id REQ-001] --name login [--branch]`：支援草稿模式與自動切換 feature 分支。
+    - `sa-spec finalize --name login`：自動定號、重命名目錄、置換佔位符並重建索引。
+    - `sa-spec reindex`：一鍵掃描並重新排序生成乾淨的 `project/index.md`。
+  - **分析前防護**：`spec:analyze` 執行前確保取得 master/遠端最新規格，避免分支規格落後導致漏檢衝突。
+
+### v0.1.3
+- **支援指令簡寫別名（同時保留完整指令）**：
+  - `sci` ＝ `spec:init`
+  - `scp` ＝ `spec:propose`
+  - `sca` ＝ `spec:analyze`
+  - `scc` ＝ `spec:commit`
+  - 兩者完全等價，使用者可依輸入習慣自由選擇長指令或 3 字母縮寫。
+
+### v0.1.2
+- **新增 `sa-spec upgrade` 版本升級指令**：
+  - **工作區規則同步**：自動檢查並更新專案中的 `AGENTS.md`、`skills/system-analysis/SKILL.md` 以及 `rules/` 目錄下的規則文件至最新版本（自動保留既有的 memory context）。
+  - **既有需求自動遷移**：掃描 `project/REQ-*` 目錄，將舊版 `uml.puml` 自動重構移動為 `uml/main.puml`，並自動修復 `handoff.md` 中的來源引用路徑。
+  - **提供 `--dry-run` 模擬模式**：可加上 `--dry-run` 參數先行預覽哪些檔案會被更新或遷移，而不實際寫入檔案。
+
+### v0.1.1
+- **PlantUML 檔案架構重構（解決多圖渲染與預覽開不起來問題）**：
+  - **目錄化結構**：每個需求目錄下由原本單一檔案 `uml.puml` 改為 `uml/` 資料夾（預設提供 `uml/main.puml` 骨架）。
+  - **單檔單圖原則**：嚴格規範每個 `.puml` 檔案僅包含單一組 `@startuml` 與 `@enduml`，禁止在單一檔案內混放多張圖。
+  - **支援多面向拆分**：需求若涉及多個面向（如業務流程、循序互動、狀態轉換），必須拆分為獨立 `.puml` 檔案（例如 `uml/main.puml`、`uml/sequence.puml`、`uml/state.puml`），確保 PlantUML 預覽外掛能順暢開啟與渲染。
+  - **CLI 自動化**：`sa-spec new` 與 `sa-spec template req` 自動建立 `uml/` 資料夾並產出預設的 `uml/main.puml`。
+  - **全專案規範同步**：同步更新 `AGENTS.md`、`system-analysis` skill、`rules/uml-style.md`、`rules/file-style.md` 與 `handoff.md`。
+

package/src/cli.js

@@ -17,9 +17,18 @@ function main() {
     case "new":
       createReqTemplate(args.slice(1));
       return;
+    case "finalize":
+      finalizeReq(args.slice(1));
+      return;
+    case "reindex":
+      reindexProject();
+      return;
     case "check":
       runCheck();
       return;
+    case "upgrade":
+      upgradeProject(args.slice(1));
+      return;
     case "doctor":
       runDoctor();
       return;
@@ -29,6 +38,11 @@ function main() {
     case "template":
       runTemplate(args.slice(1));
       return;
+    case "version":
+    case "--version":
+    case "-v":
+      showVersion();
+      return;
     case "help":
     case "--help":
     case "-h":
@@ -212,18 +226,54 @@ function createReqTemplate(args, label = "new") {
   const id = getOption(args, "--id");
   const name = getOption(args, "--name");
 
-  if (!id || !name) {
-    fail("Usage: sa-spec template req --id REQ-001 --name login");
+  if (!name) {
+    fail("Usage: sa-spec new [--id REQ-001] --name login [--branch]");
     return;
   }
 
   const slug = slugify(name);
+
+  // 草稿模式（Git-Flow 多人協作）：未指定 id 時建立草稿目錄，以 {{REQ_ID}} 佔位
+  if (!id) {
+    if (args.includes("--branch")) {
+      const branchName = `feat/${slug}`;
+      const branchRes = spawnSync("git", ["checkout", "-b", branchName], { cwd, encoding: "utf8" });
+      if (branchRes.status === 0) {
+        console.log(`已建立並切換至分支: ${branchName}`);
+      } else {
+        console.log(`提示: 分支切換略過 (${(branchRes.stderr || "").trim() || "可能是已有同名分支或未在 git 目錄"})`);
+      }
+    }
+
+    const reqDir = path.join("project", slug);
+    const umlDir = path.join(reqDir, "uml");
+    const replacements = { REQ_ID: "{{REQ_ID}}", REQ_NAME: name };
+    const results = [
+      ensureDir(reqDir),
+      ensureDir(umlDir),
+      ensureFileFromTemplate(path.join("project", "req", "srs.md"), path.join(reqDir, "srs.md"), replacements),
+      ensureFileFromTemplate(path.join("project", "req", "uml", "main.puml"), path.join(umlDir, "main.puml"), replacements),
+      ensureFileFromTemplate(path.join("project", "req", "openapi.yaml"), path.join(reqDir, "openapi.yaml"), replacements),
+      ensureFileFromTemplate(path.join("project", "req", "db-schema.md"), path.join(reqDir, "db-schema.md"), replacements),
+      ensureFileFromTemplate(path.join("project", "req", "handoff.md"), path.join(reqDir, "handoff.md"), replacements),
+      ensureFileFromTemplate(path.join("project", "req", "history.md"), path.join(reqDir, "history.md"), replacements)
+    ];
+
+    printResultList(label, results);
+    console.log(`\n已建立草稿需求：${reqDir}（內部使用 {{REQ_ID}} 佔位符）`);
+    console.log(`分析確認後，可使用 sa-spec finalize --name ${slug} 定號歸檔。`);
+    return;
+  }
+
+  // 傳統模式：指定序號
   const reqDir = path.join("project", `${id}-${slug}`);
+  const umlDir = path.join(reqDir, "uml");
   const replacements = { REQ_ID: id, REQ_NAME: name };
   const results = [
     ensureDir(reqDir),
+    ensureDir(umlDir),
     ensureFileFromTemplate(path.join("project", "req", "srs.md"), path.join(reqDir, "srs.md"), replacements),
-    ensureFileFromTemplate(path.join("project", "req", "uml.puml"), path.join(reqDir, "uml.puml"), replacements),
+    ensureFileFromTemplate(path.join("project", "req", "uml", "main.puml"), path.join(umlDir, "main.puml"), replacements),
     ensureFileFromTemplate(path.join("project", "req", "openapi.yaml"), path.join(reqDir, "openapi.yaml"), replacements),
     ensureFileFromTemplate(path.join("project", "req", "db-schema.md"), path.join(reqDir, "db-schema.md"), replacements),
     ensureFileFromTemplate(path.join("project", "req", "handoff.md"), path.join(reqDir, "handoff.md"), replacements),
@@ -234,6 +284,166 @@ function createReqTemplate(args, label = "new") {
   printResultList(label, results);
 }
 
+function finalizeReq(args) {
+  const name = getOption(args, "--name") || getOption(args, "--draft") || args[0];
+  if (!name) {
+    fail("Usage: sa-spec finalize --name <name-or-slug>");
+    return;
+  }
+
+  const slug = slugify(name);
+  const projectDir = path.join(cwd, "project");
+  let draftRelDir = path.join("project", slug);
+  let draftAbsDir = path.join(cwd, draftRelDir);
+
+  if (!fs.existsSync(draftAbsDir)) {
+    const altRelDir = path.join("project", `draft-${slug}`);
+    if (fs.existsSync(path.join(cwd, altRelDir))) {
+      draftRelDir = altRelDir;
+      draftAbsDir = path.join(cwd, altRelDir);
+    } else {
+      fail(`找不到草稿需求目錄: ${draftRelDir}`);
+      return;
+    }
+  }
+
+  // 掃描既有最大 REQ 編號
+  let maxIdNum = 0;
+  if (fs.existsSync(projectDir)) {
+    const entries = fs.readdirSync(projectDir, { withFileTypes: true });
+    for (const entry of entries) {
+      if (entry.isDirectory() && entry.name.startsWith("REQ-")) {
+        const m = entry.name.match(/^REQ-(\d+)/i);
+        if (m) {
+          const num = parseInt(m[1], 10);
+          if (num > maxIdNum) {
+            maxIdNum = num;
+          }
+        }
+      }
+    }
+  }
+
+  const nextIdNum = maxIdNum + 1;
+  const nextId = `REQ-${String(nextIdNum).padStart(3, "0")}`;
+  const finalDirName = `${nextId}-${slug}`;
+  const finalRelDir = path.join("project", finalDirName);
+  const finalAbsDir = path.join(cwd, finalRelDir);
+
+  if (fs.existsSync(finalAbsDir)) {
+    fail(`目標目錄 ${finalRelDir} 已存在，請確認序號或目錄名稱。`);
+    return;
+  }
+
+  // 重命名目錄 (優先嘗試 git mv)
+  const gitMv = spawnSync("git", ["mv", draftRelDir, finalRelDir], { cwd, encoding: "utf8" });
+  if (gitMv.status === 0) {
+    console.log(`[Git] 已將目錄重命名為: ${finalRelDir}`);
+  } else {
+    fs.renameSync(draftAbsDir, finalAbsDir);
+    console.log(`已將目錄重命名為: ${finalRelDir}`);
+  }
+
+  // 替換目錄內檔案的 {{REQ_ID}} 佔位符
+  const files = listFilesRecursive(finalAbsDir);
+  for (const filePath of files) {
+    try {
+      const content = fs.readFileSync(filePath, "utf8");
+      if (content.includes("{{REQ_ID}}")) {
+        const updated = content.split("{{REQ_ID}}").join(nextId);
+        fs.writeFileSync(filePath, updated, "utf8");
+      }
+    } catch (_) {
+      // 略過無法以文字讀取之檔案
+    }
+  }
+
+  // 自動重新整理 index.md
+  reindexProject();
+
+  console.log(`\n 需求已成功定號歸檔為: ${nextId} (${finalDirName})`);
+  console.log(`建議接下來執行：`);
+  console.log(`  git add project/`);
+  console.log(`  git commit -m "docs(${nextId}): ${name} - 規格確認歸檔"`);
+}
+
+function reindexProject() {
+  const projectDir = path.join(cwd, "project");
+  const indexPath = path.join(projectDir, "index.md");
+  if (!fs.existsSync(projectDir)) {
+    fail("project/ directory not found.");
+    return;
+  }
+
+  // 讀取現有索引
+  const existingMap = new Map();
+  if (fs.existsSync(indexPath)) {
+    const existingRows = parseIndexRows(fs.readFileSync(indexPath, "utf8"));
+    for (const row of existingRows) {
+      existingMap.set(row.id, row);
+    }
+  }
+
+  const entries = fs.readdirSync(projectDir, { withFileTypes: true });
+  const reqDirs = entries.filter((e) => e.isDirectory() && e.name.startsWith("REQ-"));
+
+  const rows = [];
+  for (const entry of reqDirs) {
+    const dirName = entry.name;
+    const match = dirName.match(/^(REQ-\d+)(?:-(.*))?$/i);
+    if (!match) continue;
+    const id = match[1].toUpperCase();
+    const fallbackTitle = match[2] || dirName;
+
+    const reqDirPath = path.join(projectDir, dirName);
+    const srsPath = path.join(reqDirPath, "srs.md");
+
+    let title = fallbackTitle;
+    let description = "待補充";
+    let status = "待確認";
+    let createdAt = formatLocalDateTime(new Date());
+    let updatedAt = createdAt;
+
+    if (existingMap.has(id)) {
+      const prev = existingMap.get(id);
+      title = prev.title || title;
+      description = prev.description || description;
+      status = prev.status || status;
+      createdAt = prev.createdAt || createdAt;
+      updatedAt = prev.updatedAt || updatedAt;
+    }
+
+    if (fs.existsSync(srsPath)) {
+      const srsContent = fs.readFileSync(srsPath, "utf8");
+      const titleMatch = srsContent.match(/^# 需求規格[：:]\s*(?:REQ-\d+\s*)?(.*)$/m);
+      if (titleMatch && titleMatch[1].trim()) {
+        title = titleMatch[1].trim();
+      }
+      const statusMatch = srsContent.match(/^-\s*狀態[：:]\s*(.+)$/m);
+      if (statusMatch && statusMatch[1].trim()) {
+        status = statusMatch[1].trim();
+      }
+    }
+
+    const numMatch = id.match(/\d+/);
+    const num = numMatch ? parseInt(numMatch[0], 10) : 0;
+
+    rows.push({ num, id, title, description, status, createdAt, updatedAt });
+  }
+
+  // 依數字循序排序
+  rows.sort((a, b) => a.num - b.num);
+
+  const header = `# 需求索引\n\n| 編號 | 標題 | 敘述 | 狀態 | 建立時間 | 更新時間 |\n|---|---|---|---|---|---|\n`;
+  const tableRows = rows
+    .map((r) => `| ${r.id} | ${r.title} | ${r.description} | ${r.status} | ${r.createdAt} | ${r.updatedAt} |`)
+    .join("\n");
+  const nextContent = rows.length > 0 ? `${header}${tableRows}\n` : `${header}\n`;
+
+  fs.writeFileSync(indexPath, nextContent, "utf8");
+  console.log(`sa-spec reindex: 已重新索引 ${rows.length} 個需求至 project/index.md`);
+}
+
 function ensureIndexRow(id, name) {
   const indexPath = path.join(cwd, "project", "index.md");
   if (!fs.existsSync(indexPath)) {
@@ -319,7 +529,10 @@ function parseIndexRows(content) {
     .map((parts) => ({
       id: parts[1],
       title: parts[2],
-      status: parts[4]
+      description: parts[3],
+      status: parts[4],
+      createdAt: parts[5],
+      updatedAt: parts[6]
     }));
 }
 
@@ -336,10 +549,133 @@ function slugify(value) {
     .replace(/^-+|-+$/g, "");
 }
 
+function upgradeProject(args = []) {
+  const dryRun = args.includes("--dry-run");
+  const results = [];
+
+  results.push(ensureDir("skills"));
+  results.push(ensureDir(path.join("skills", "system-analysis")));
+
+  results.push(updateFileFromTemplate("AGENTS.md", "AGENTS.md", dryRun));
+  results.push(
+    updateFileFromTemplate(
+      path.join("skills", "system-analysis", "SKILL.md"),
+      path.join("skills", "system-analysis", "SKILL.md"),
+      dryRun
+    )
+  );
+
+  const rulesTargetDir = path.join(cwd, "rules");
+  if (fs.existsSync(rulesTargetDir)) {
+    const templateRulesDir = path.join(templatesDir, "rules");
+    for (const file of listFilesRecursive(templateRulesDir)) {
+      const relativePath = path.relative(templatesDir, file);
+      results.push(updateFileFromTemplate(relativePath, relativePath, dryRun));
+    }
+  }
+
+  const projectDir = path.join(cwd, "project");
+  if (fs.existsSync(projectDir)) {
+    const entries = fs.readdirSync(projectDir, { withFileTypes: true });
+    for (const entry of entries) {
+      if (entry.isDirectory() && entry.name.startsWith("REQ-")) {
+        const reqRelDir = path.join("project", entry.name);
+        const oldUmlRelPath = path.join(reqRelDir, "uml.puml");
+        const oldUmlAbsPath = path.join(cwd, oldUmlRelPath);
+        const newUmlRelDir = path.join(reqRelDir, "uml");
+        const newUmlAbsDir = path.join(cwd, newUmlRelDir);
+        const newMainUmlRelPath = path.join(newUmlRelDir, "main.puml");
+        const newMainUmlAbsPath = path.join(cwd, newMainUmlRelPath);
+
+        if (fs.existsSync(oldUmlAbsPath)) {
+          if (!fs.existsSync(newMainUmlAbsPath)) {
+            if (!dryRun) {
+              if (!fs.existsSync(newUmlAbsDir)) {
+                fs.mkdirSync(newUmlAbsDir, { recursive: true });
+              }
+              fs.renameSync(oldUmlAbsPath, newMainUmlAbsPath);
+            }
+            results.push({
+              action: "migrate",
+              target: `${oldUmlRelPath} -> ${newMainUmlRelPath}`
+            });
+          } else {
+            results.push({
+              action: "warn",
+              target: oldUmlRelPath,
+              message: `目標 ${newMainUmlRelPath} 已存在，請確認是否可手動移除舊檔。`
+            });
+          }
+        }
+
+        const handoffRelPath = path.join(reqRelDir, "handoff.md");
+        const handoffAbsPath = path.join(cwd, handoffRelPath);
+        if (fs.existsSync(handoffAbsPath)) {
+          const content = fs.readFileSync(handoffAbsPath, "utf8");
+          if (content.includes("uml.puml")) {
+            if (!dryRun) {
+              fs.writeFileSync(handoffAbsPath, content.replace(/uml\.puml/g, "uml/"), "utf8");
+            }
+            results.push({
+              action: "update",
+              target: handoffRelPath,
+              message: "更新來源參照 uml.puml -> uml/"
+            });
+          }
+        }
+      }
+    }
+  }
+
+  printResultList(dryRun ? "upgrade (dry-run)" : "upgrade", results);
+}
+
+function updateFileFromTemplate(templateRelativePath, targetRelativePath, dryRun = false) {
+  const targetAbsolutePath = path.join(cwd, targetRelativePath);
+  const templateAbsolutePath = path.join(templatesDir, templateRelativePath);
+  if (!fs.existsSync(templateAbsolutePath)) {
+    return { action: "skip", target: targetRelativePath };
+  }
+
+  let templateContent = readTemplate(templateRelativePath);
+  if (!fs.existsSync(targetAbsolutePath)) {
+    if (!dryRun) {
+      writeFileIfMissing(targetAbsolutePath, templateContent);
+    }
+    return { action: "create", target: targetRelativePath };
+  }
+
+  const currentContent = fs.readFileSync(targetAbsolutePath, "utf8");
+  if (currentContent.includes("<claude-mem-context>")) {
+    const memMatch = currentContent.match(/(<claude-mem-context>[\s\S]*?<\/claude-mem-context>)/);
+    if (memMatch && !templateContent.includes("<claude-mem-context>")) {
+      templateContent = `${templateContent.trimEnd()}\n\n\n${memMatch[1]}\n`;
+    }
+  }
+
+  if (currentContent.trim() === templateContent.trim()) {
+    return { action: "skip", target: targetRelativePath };
+  }
+
+  if (!dryRun) {
+    fs.writeFileSync(targetAbsolutePath, templateContent, "utf8");
+  }
+  return { action: "update", target: targetRelativePath };
+}
+
 function printResultList(label, results) {
   console.log(`sa-spec ${label}`);
   for (const result of results) {
-    const action = result.action === "create" ? "CREATED" : result.action === "update" ? "UPDATED" : result.action === "warn" ? "WARNING" : "SKIPPED";
+    const action =
+      result.action === "create"
+        ? "CREATED"
+        : result.action === "update"
+        ? "UPDATED"
+        : result.action === "migrate"
+        ? "MIGRATED"
+        : result.action === "warn"
+        ? "WARNING"
+        : "SKIPPED";
     console.log(`${action} ${result.target}${result.message ? ` - ${result.message}` : ""}`);
   }
 }
@@ -349,11 +685,20 @@ function showHelp() {
 
 Usage:
   sa-spec init [--full]
-  sa-spec new --id REQ-001 --name login
+  sa-spec new [--id REQ-001] --name login [--branch]
+  sa-spec finalize --name login
+  sa-spec reindex
   sa-spec check
+  sa-spec upgrade [--dry-run]
+  sa-spec --version
 `);
 }
 
+function showVersion() {
+  const pkg = JSON.parse(fs.readFileSync(path.join(rootDir, "package.json"), "utf8"));
+  console.log(pkg.version);
+}
+
 function fail(message) {
   console.error(message);
   process.exitCode = 1;

package/templates/AGENTS.md

@@ -7,7 +7,7 @@
 每個需求歸檔時固定包含：
 
 - `srs.md`：需求規格。
-- `uml.puml`：UML 圖。
+- `uml/`：UML 圖目錄（依面向拆分為獨立 `.puml` 檔，如 `main.puml`、`sequence.puml` 等，禁止單檔混放多圖）。
 - `openapi.yaml`：OpenAPI 草稿。
 - `db-schema.md`：DB Schema 草稿。
 - `handoff.md`：給 OpenSpec 或其他 AI 開發工具的開發交接摘要。
@@ -15,14 +15,14 @@
 
 # 指令流程
 
-只使用四個指令：
+使用四個指令，並支援簡寫別名（兩者等價）：
 
-| 指令 | 用途 | 規則 |
-|---|---|---|
-| `spec:init` | 初始化 | 載入並遵守 `AGENTS.md`、`skills/system-analysis/SKILL.md` 與必要規則，確認 `project/` 結構是否存在。 |
-| `spec:propose` | 提出需求 | 使用者提出需求後，先整理需求摘要、目標、初步流程與待確認事項，不歸檔、不修改既有需求。 |
-| `spec:analyze` | 分析與起草 | 先檢查新需求是否與 `project/` 內所有既有需求衝突；無衝突才產出 SRS、UML、OpenAPI、DB Schema 草稿；有衝突則只列出衝突與待釐清問題，待使用者釐清後再次執行 `spec:analyze`。 |
-| `spec:commit` | 確認歸檔 | 只把使用者已確認的版本歸檔到該需求資料夾，更新 `project/index.md`、`project/system-spec.md` 與 `history.md`，並建立本機 Git commit。 |
+| 指令 | 簡寫 | 用途 | 規則 |
+|---|---|---|---|
+| `spec:init` | `sci` | 初始化 | 載入並遵守 `AGENTS.md`、`skills/system-analysis/SKILL.md` 與必要規則，確認 `project/` 結構是否存在。 |
+| `spec:propose` | `scp` | 提出需求 | 使用者提出需求後，先整理需求摘要、目標、初步流程與待確認事項，不歸檔、不修改既有需求。 |
+| `spec:analyze` | `sca` | 分析與起草 | 先檢查新需求是否與 `project/` 內所有既有需求衝突；無衝突才產出 SRS、UML、OpenAPI、DB Schema 草稿；有衝突則只列出衝突與待釐清問題，待使用者釐清後再次執行 `spec:analyze`（或 `sca`）。 |
+| `spec:commit` | `scc` | 確認歸檔 | 只把使用者已確認的版本歸檔到該需求資料夾，更新 `project/index.md`、`project/system-spec.md` 與 `history.md`，並建立本機 Git commit。 |
 
 # 重要限制
 
@@ -39,8 +39,9 @@
 - 交給 OpenSpec 或其他 AI 開發工具時，必須指定它先閱讀 `handoff.md`，並以 `handoff.md` 作為開發入口與限制摘要；其他規格文件作為詳細來源。
 - `spec:commit` 完成文件歸檔後，必須自動建立本機 Git commit；commit message 以需求編號與需求名稱為主，並加上簡短需求說明，格式為 `docs(REQ-001): 需求名稱 - 簡短需求說明`。
 - `spec:commit` 只有在使用者明確要求推送 remote，或專案設定啟用 auto-push 時，才可執行 `git push`；push 失敗時只回報認證或網路問題，不得回滾已完成的文件歸檔與本機 commit。
+- 多人協作與 Git-Flow 模式（延遲綁定序號）：支援多人平行開發。提出需求時可於 feature branch（如 `feat/<name>`）建立草稿目錄，內部使用 `{{REQ_ID}}` 佔位；執行 `spec:analyze` 前應先確保取得 master 最新規格以防漏檢衝突；執行 `spec:commit` 歸檔時向 master 確認最新可用序號並定號，自動將目錄定名為正式 `REQ-xxx`、替換內部佔位符、重新生成 `project/index.md`，避免多人合併時的序號競爭與索引衝突。
 - 文件未經使用者確認，不得標示為 `已審核`。
-- `uml.puml` 不限單一 UML 圖型；`spec:analyze` 必須依需求選擇最能說明流程、互動、狀態或資料關係的 UML 圖，例如活動圖、循序圖、使用案例圖、狀態圖或類別圖，不可為了固定格式硬產生活動圖。需求複雜時，可在同一個 `uml.puml` 內放多張 PlantUML 圖並清楚分段。
+- `uml/` 內的 UML 圖不限單一 UML 圖型；`spec:analyze` 必須依需求選擇最能說明流程、互動、狀態或資料關係的 UML 圖，例如活動圖、循序圖、使用案例圖、狀態圖或類別圖，不可為了固定格式硬產生活動圖。**嚴禁將多張圖混在同一個檔案中**，必須在需求資料夾下的 `uml/` 目錄拆分成獨立的 `.puml` 檔案（例如 `uml/main.puml`、`uml/sequence.puml`、`uml/state.puml`），且每個檔案只能包含一組 `@startuml` 與 `@enduml`，以避免 PlantUML 渲染或預覽失敗。
 - 一次最多問 3 個待確認問題，優先詢問會影響範圍、資料、權限、API、DB 或驗收的問題。
 
 # 衝突檢查重點
@@ -67,12 +68,12 @@
 # 狀態機
 
 ```text
-init -> propose -> analyze
+init (sci) -> propose (scp) -> analyze (sca)
 
-analyze 無衝突 -> 產出待確認版本 -> commit
-analyze 有衝突 -> 釐清問題 -> analyze
+analyze 無衝突 -> 產出待確認版本 -> commit (scc)
+analyze 有衝突 -> 釐清問題 -> analyze (sca)
 
-commit -> 歸檔 -> 本機 Git commit
+commit (scc) -> 歸檔 -> 本機 Git commit
 ```
 
 # 歸檔結構
@@ -82,7 +83,8 @@ project/
   index.md
   REQ-001-name/
     srs.md
-    uml.puml
+    uml/
+      main.puml
     openapi.yaml
     db-schema.md
     handoff.md

package/templates/project/req/handoff.md

@@ -1,7 +1,7 @@
 # {{REQ_ID}} {{REQ_NAME}} Handoff
 
 - 狀態：待確認
-- 來源文件：`srs.md`、`uml.puml`、`openapi.yaml`、`db-schema.md`
+- 來源文件：`srs.md`、`uml/`、`openapi.yaml`、`db-schema.md`
 - 目標讀者：OpenSpec、Codex、Claude、Gemini 或其他 AI 開發工具
 
 ## 要開發什麼

package/templates/project/req/{uml.puml → uml/main.puml}

@@ -8,7 +8,7 @@ User -> System: 發起需求
 System --> User: 回傳結果
 
 note right of System
-待於 spec:exec 後補充流程細節。
+待於 spec:analyze 後補充流程細節。
 end note
 
 @enduml

package/templates/readme.md

@@ -2,14 +2,14 @@
 
 `sa-spec` 是一個輕量的系統分析文件工作台，用固定流程把需求想法整理成可確認、可歸檔、可檢查的文件。
 
-AI 工作流只使用四個指令：
+AI 工作流只使用四個指令，並支援簡寫別名（兩者等價）：
 
-```text
-spec:init
-spec:propose
-spec:analyze
-spec:commit
-```
+| 標準指令 | 簡寫 | 說明 |
+|---|---|---|
+| `spec:init` | `sci` | 初始化專案與規則 |
+| `spec:propose` | `scp` | 提出需求並整理摘要 |
+| `spec:analyze` | `sca` | 衝突檢查與規格起草 |
+| `spec:commit` | `scc` | 確認歸檔並建立 Git commit |
 
 每個需求歸檔後固定包含：
 
@@ -17,7 +17,8 @@ spec:commit
 project/
   REQ-001-login/
     srs.md
-    uml.puml
+    uml/
+      main.puml
     openapi.yaml
     db-schema.md
     handoff.md
@@ -236,10 +237,13 @@ sa-spec init --full
 |---|---|
 | `sa-spec init` | 建立最小文件骨架。 |
 | `sa-spec init --full` | 建立文件骨架與完整規則文件。 |
-| `sa-spec new --id REQ-001 --name login` | 建立需求資料夾與空白文件模板，包含 SRS、UML、OpenAPI、DB Schema、handoff 與 history。 |
+| `sa-spec new [--id REQ-001] --name login [--branch]` | 建立需求資料夾與空白文件模板（未帶 `--id` 時啟用多人草稿模式，可選 `--branch` 自動建立並切換至 `feat/<name>` 分支）。 |
+| `sa-spec finalize --name login` | 將草稿需求定號歸檔為最新序號（自動計算最新號碼、重命名目錄、批次置換 `{{REQ_ID}}` 並重建索引）。 |
+| `sa-spec reindex` | 掃描 `project/REQ-*` 目錄，依序號重新生成乾淨無衝突的 `project/index.md`。 |
 | `sa-spec check` | 檢查基本文件是否存在。 |
 | `sa-spec status` | 顯示系統規格與需求索引狀態。 |
 | `sa-spec doctor` | 檢查必要檔案是否存在。 |
+| `sa-spec upgrade [--dry-run]` | 將既有專案升級為最新版本：同步最新 AGENTS 與規則文件，並將既有需求中的 `uml.puml` 自動遷移為 `uml/main.puml`。 |
 
 `sa-spec new` 是快速建空白模板的輔助工具。正式需求流程仍建議使用 `spec:init`、`spec:propose`、`spec:analyze`、`spec:commit`。
 
@@ -259,7 +263,7 @@ sa-spec init --full
 | AI 對話 | Claude Code 類型的 VS Code AI 套件或 CLI 整合 | 擇一 | 用 Claude 讀取工作區規則並協作產出需求文件。 |
 | AI 對話 | Gemini 類型的 VS Code AI 套件或 CLI 整合 | 擇一 | 用 Gemini 讀取工作區規則並協作產出需求文件。 |
 | Markdown | Markdown 預覽或 Markdown All in One 類型套件 | 選用 | 預覽 `srs.md`、`history.md`、`system-spec.md`。 |
-| UML | PlantUML 類型套件 | 選用 | 預覽 `uml.puml`。 |
+| UML | PlantUML 類型套件 | 選用 | 預覽需求內的 `uml/*.puml`。 |
 | YAML | YAML 類型套件 | 選用 | 編輯與檢查 `openapi.yaml`。 |
 | Git | GitLens 類型套件 | 選用 | 查看需求文件修改歷程。 |
 
@@ -280,10 +284,10 @@ Markdown、PlantUML、YAML、GitLens 這類套件可以提升閱讀與檢查體
 | CLI | `sa-spec init --full` | 終端機或 VS Code Terminal | 建立文件骨架與規則檔。 |
 | CLI | `sa-spec check` | 終端機或 VS Code Terminal | 檢查必要文件是否存在。 |
 | CLI | `sa-spec status` | 終端機或 VS Code Terminal | 查看系統規格與需求索引狀態。 |
-| AI 工作流程 | `spec:init` | VS Code AI 對話側邊欄 | 載入規則並確認工作區狀態。 |
-| AI 工作流程 | `spec:propose` | VS Code AI 對話側邊欄 | 整理使用者提出的需求。 |
-| AI 工作流程 | `spec:analyze` | VS Code AI 對話側邊欄 | 檢查衝突並產出待確認草稿。 |
-| AI 工作流程 | `spec:commit` | VS Code AI 對話側邊欄 | 歸檔已確認版本並建立本機 Git commit。 |
+| AI 工作流程 | `spec:init` / `sci` | VS Code AI 對話側邊欄 | 載入規則並確認工作區狀態。 |
+| AI 工作流程 | `spec:propose` / `scp` | VS Code AI 對話側邊欄 | 整理使用者提出的需求。 |
+| AI 工作流程 | `spec:analyze` / `sca` | VS Code AI 對話側邊欄 | 檢查衝突並產出待確認草稿。 |
+| AI 工作流程 | `spec:commit` / `scc` | VS Code AI 對話側邊欄 | 歸檔已確認版本並建立本機 Git commit。 |
 
 建議操作順序：
 
@@ -297,32 +301,32 @@ code .
 接著在 VS Code 的 AI 對話側邊欄輸入：
 
 ```text
-spec:init
-spec:propose
-spec:analyze
-spec:commit
+spec:init    # 或簡寫 sci
+spec:propose # 或簡寫 scp
+spec:analyze # 或簡寫 sca
+spec:commit  # 或簡寫 scc
 ```
 
 如果你有安裝 prompts 或 slash commands，可以用對應的快捷指令；沒有安裝也可以直接手動輸入上面的文字指令。
 
 ## AI 工作流程
 
-| 指令 | 用途 |
-|---|---|
-| `spec:init` | 初始化並載入 `AGENTS.md`、`skills/system-analysis/SKILL.md` 與必要規則。 |
-| `spec:propose` | 使用者提出需求後，整理需求摘要、目標、初步流程與待確認事項。 |
-| `spec:analyze` | 檢查是否與既有需求衝突；無衝突才產出 SRS、UML、OpenAPI、DB Schema 草稿。 |
-| `spec:commit` | 使用者確認無衝突版本後，將版本歸檔到 `project/`，並建立本機 Git commit。 |
+| 指令 | 簡寫 | 用途 |
+|---|---|---|
+| `spec:init` | `sci` | 初始化並載入 `AGENTS.md`、`skills/system-analysis/SKILL.md` 與必要規則。 |
+| `spec:propose` | `scp` | 使用者提出需求後，整理需求摘要、目標、初步流程與待確認事項。 |
+| `spec:analyze` | `sca` | 檢查是否與既有需求衝突；無衝突才產出 SRS、UML、OpenAPI、DB Schema 草稿。 |
+| `spec:commit` | `scc` | 使用者確認無衝突版本後，將版本歸檔到 `project/`，並建立本機 Git commit。 |
 
 狀態機：
 
 ```text
-init -> propose -> analyze
+init (sci) -> propose (scp) -> analyze (sca)
 
-analyze 無衝突 -> 產出待確認版本 -> commit
-analyze 有衝突 -> 釐清問題 -> analyze
+analyze 無衝突 -> 產出待確認版本 -> commit (scc)
+analyze 有衝突 -> 釐清問題 -> analyze (sca)
 
-commit -> 歸檔 -> 本機 Git commit
+commit (scc) -> 歸檔 -> 本機 Git commit
 ```
 
 `spec:analyze` 若發現衝突，只會列出衝突與待釐清問題，不會修改任何需求文件，也不會產出最終文件。釐清後應再次執行 `spec:analyze`，重新檢查並產出草稿。
@@ -334,7 +338,7 @@ commit -> 歸檔 -> 本機 Git commit
 ```text
 請先閱讀 project/REQ-001-pomodoro-timer/handoff.md。
 以 handoff.md 作為本次開發入口與限制摘要。
-如需完整需求細節，再查閱同資料夾內的 srs.md、uml.puml、openapi.yaml、db-schema.md 與 history.md。
+如需完整需求細節，再查閱同資料夾內的 srs.md、uml/、openapi.yaml、db-schema.md 與 history.md。
 不得自行新增 handoff.md 未確認的角色、權限、流程、狀態、API 或 DB 欄位。
 若發現 handoff.md 與既有程式或規格衝突，請停止開發並回報。
 ```
@@ -347,6 +351,64 @@ docs(REQ-001): 番茄時鐘 - 新增專注與休息計時需求
 
 只有在使用者明確要求推送 remote，或專案設定啟用 auto-push 時，才會執行 `git push`。如果 push 失敗，只回報認證或網路問題，不會回滾已完成的文件歸檔與本機 commit。
 
+## 多人協作解決方案（Git-Flow 與延遲綁定 ID）
+
+在單人開發時，循序流水號（`REQ-001`、`REQ-002`）簡單直覺；但在多人平行協作時，容易引發兩大痛點：
+1. **序號競爭撞車**：Alice 與 Bob 同時在各自的分支開發，雙方本機都取了 `REQ-003`，合併回主幹時發生目錄重名衝突。
+2. **中心化檔案衝突**：每次歸檔都要修改 `project/index.md`，導致頻繁的 Git merge conflict。
+
+`sa-spec v0.2.0` 引進 **「Feature Branch 隔離 + 延遲綁定序號（Late-Binding ID）」** 完整解決方案：
+
+```mermaid
+flowchart TD
+    A[開新需求: sa-spec new --name cart --branch] --> B[建立並切換至 feat/cart 分支<br/>以 project/cart/ 建立草稿目錄]
+    B --> C[AI 分析與起草: sca<br/>內部使用 {{REQ_ID}} 佔位<br/>自動同步 master 規格防護]
+    C --> D{使用者確認通過<br/>執行 scc 或 finalize}
+    D --> E[查詢 master 最新序號 N]
+    E --> F[重命名為 project/REQ-N+1-cart/<br/>批次置換 {{REQ_ID}} 為正式號碼]
+    F --> G[sa-spec reindex: 動態重構 index.md]
+    G --> H[合併回 master: 零衝突、序號永遠連續！]
+```
+
+### 多人協作四步流程
+
+#### 1. 提出需求（草稿與分支隔離）
+開需求時**不搶序號**，直接以語意名稱建立分支與草稿目錄：
+
+```bash
+# 自動建立並切換至 feat/cart-checkout 分支，建立 project/cart-checkout/ 草稿目錄
+sa-spec new --name cart-checkout --branch
+```
+在 VS Code 側邊欄輸入：
+```text
+scp 購物車結帳需求
+```
+* **特點**：目錄名稱為 `project/cart-checkout/`，內部所有檔案皆使用 `{{REQ_ID}}` 佔位符。多人同時提出需求互不干擾、零衝突。即使需求中途放棄，直接刪除分支即可，絕不留下幽靈跳號。
+
+#### 2. 分析與衝突檢查（規格基線同步）
+在分支上執行 `spec:analyze`（或 `sca`）前，工具會確認已取得 `master`（或 `origin/master`）的最新規格，確保是以全專案最新基準進行影響評估，避免因分支落後而漏檢權限、API 或資料表衝突。
+
+#### 3. 確認歸檔與延遲定號（Late-Binding）
+當需求規格確認無誤，準備歸檔時：
+
+```bash
+# 自動向 master 查詢最新可用序號（例如 REQ-006）
+sa-spec finalize --name cart-checkout
+```
+* **自動化執行**：
+  1. 取得最新序號（例如目前最大是 `REQ-005`，自動取得 `REQ-006`）。
+  2. 使用 `git mv` 將目錄重命名為 `project/REQ-006-cart-checkout`。
+  3. 自動掃描並將目錄內所有檔案的 `{{REQ_ID}}` 批次置換為 `REQ-006`。
+  4. 自動執行 `reindex` 重建需求總表。
+
+#### 4. 消除索引合併衝突（`sa-spec reindex`）
+`project/index.md` 改為由目錄動態生成的「衍生清單」，不再依賴脆弱的手動 append：
+
+```bash
+sa-spec reindex
+```
+* 任何時候若有 PR 合併產生 index 衝突，只要執行 `sa-spec reindex`，即可依序號重新排序生成乾淨的總表，無需人工手動解 conflict。
+
 ## 完整範例：番茄時鐘
 
 以下示範從空資料夾開始，建立一個「番茄時鐘」需求。
@@ -520,7 +582,8 @@ project/
   system-spec.md
   REQ-001-pomodoro-timer/
     srs.md
-    uml.puml
+    uml/
+      state.puml
     openapi.yaml
     db-schema.md
     handoff.md
@@ -591,3 +654,39 @@ git push origin master
 - `project/system-spec.md` 只能在 `spec:commit` 依使用者確認內容更新。
 - `spec:commit` 會自動建立本機 Git commit；remote push 需使用者明確要求或啟用 auto-push。
 - 一次最多問 3 個待確認問題，優先詢問會影響範圍、資料、權限、API、DB 或驗收的問題。
+
+## 更新紀錄
+
+### v0.2.0
+- **多人協作 Git-Flow 解決方案（延遲綁定序號與零衝突索引）**：
+  - **解決痛點**：多人平行開發時，傳統流水號（`REQ-001`）容易在各自分支撞車，且中心化的 `project/index.md` 容易造成 Git merge conflict。
+  - **延遲綁定序號（Late-Binding ID）**：開需求時不搶號，在 feature branch 上以語意名稱建立草稿需求（如 `project/cart`），內部使用 `{{REQ_ID}}` 佔位；只有在 `spec:commit` 最終歸檔時，才向 master/遠端確認最新可用序號並定號（如 `REQ-003`），自動批次置換佔位符，徹底避免幽靈跳號與序號競爭。
+  - **動態重建需求索引（`sa-spec reindex`）**：將 `project/index.md` 改為根據 `project/REQ-*` 目錄動態掃描並依序號排序生成，消除手動 append 造成的 Git 合併衝突。
+  - **CLI 指令升級**：
+    - `sa-spec new [--id REQ-001] --name login [--branch]`：支援草稿模式與自動切換 feature 分支。
+    - `sa-spec finalize --name login`：自動定號、重命名目錄、置換佔位符並重建索引。
+    - `sa-spec reindex`：一鍵掃描並重新排序生成乾淨的 `project/index.md`。
+  - **分析前防護**：`spec:analyze` 執行前確保取得 master/遠端最新規格，避免分支規格落後導致漏檢衝突。
+
+### v0.1.3
+- **支援指令簡寫別名（同時保留完整指令）**：
+  - `sci` ＝ `spec:init`
+  - `scp` ＝ `spec:propose`
+  - `sca` ＝ `spec:analyze`
+  - `scc` ＝ `spec:commit`
+  - 兩者完全等價，使用者可依輸入習慣自由選擇長指令或 3 字母縮寫。
+
+### v0.1.2
+- **新增 `sa-spec upgrade` 版本升級指令**：
+  - **工作區規則同步**：自動檢查並更新專案中的 `AGENTS.md`、`skills/system-analysis/SKILL.md` 以及 `rules/` 目錄下的規則文件至最新版本（自動保留既有的 memory context）。
+  - **既有需求自動遷移**：掃描 `project/REQ-*` 目錄，將舊版 `uml.puml` 自動重構移動為 `uml/main.puml`，並自動修復 `handoff.md` 中的來源引用路徑。
+  - **提供 `--dry-run` 模擬模式**：可加上 `--dry-run` 參數先行預覽哪些檔案會被更新或遷移，而不實際寫入檔案。
+
+### v0.1.1
+- **PlantUML 檔案架構重構（解決多圖渲染與預覽開不起來問題）**：
+  - **目錄化結構**：每個需求目錄下由原本單一檔案 `uml.puml` 改為 `uml/` 資料夾（預設提供 `uml/main.puml` 骨架）。
+  - **單檔單圖原則**：嚴格規範每個 `.puml` 檔案僅包含單一組 `@startuml` 與 `@enduml`，禁止在單一檔案內混放多張圖。
+  - **支援多面向拆分**：需求若涉及多個面向（如業務流程、循序互動、狀態轉換），必須拆分為獨立 `.puml` 檔案（例如 `uml/main.puml`、`uml/sequence.puml`、`uml/state.puml`），確保 PlantUML 預覽外掛能順暢開啟與渲染。
+  - **CLI 自動化**：`sa-spec new` 與 `sa-spec template req` 自動建立 `uml/` 資料夾並產出預設的 `uml/main.puml`。
+  - **全專案規範同步**：同步更新 `AGENTS.md`、`system-analysis` skill、`rules/uml-style.md`、`rules/file-style.md` 與 `handoff.md`。
+

package/templates/rules/file-style.md

@@ -20,12 +20,11 @@
 - 每個需求資料夾至少包含：
   - `srs.md`：需求規格。
   - `history.md`：需求歷程。
-  - `uml.puml`：UML 圖。
+  - `uml/`：UML 圖目錄，依面向拆分為獨立 `.puml` 檔（如 `main.puml`、`sequence.puml` 等，單檔單圖，禁止單檔混放多圖）。
   - `openapi.yaml`：OpenAPI 草稿。
   - `db-schema.md`：DB Schema 草稿。
   - `handoff.md`：給 OpenSpec 或其他 AI 開發工具的開發交接摘要。
 - 若需求涉及畫面，使用 `wireframe.md`。
-- 若需求需要 UML，放入 `uml/` 資料夾。
 - 若需求需要 API 或資料模型，使用 `api.md` 或獨立資料模型文件。
 - 若需求需要 DB Table 設計，使用 `db-table.md`。
 
@@ -37,13 +36,12 @@ project/
     srs.md
     wireframe.md
     history.md
-    uml.puml
+    uml/
+      main.puml
+      sequence.puml
     openapi.yaml
     db-schema.md
     handoff.md
-    uml/
-      use-case.puml
-      sequence.puml
     api.md
     db-table.md
 ```

package/templates/rules/uml-style.md

@@ -2,7 +2,9 @@
 
 ## 格式
 - UML 圖一律使用 PlantUML。
-- PlantUML 檔案副檔名使用 `.puml`。
+- PlantUML 檔案副檔名使用 `.puml`，放置於需求的 `uml/` 資料夾中（例如 `uml/main.puml`、`uml/sequence.puml`）。
+- **嚴禁將多張圖混在同一個檔案中**：每個 `.puml` 檔案僅能包含單一組 `@startuml` 與 `@enduml`，避免 PlantUML 預覽或渲染工具解析失敗或無法開啟。
+- 若需求涉及多個面向（例如業務流程、循序互動、狀態轉換），必須依圖型或面向拆分成獨立的 `.puml` 檔案。
 - 圖表內容以繁體中文描述，並採用台灣常用語。
 
 ## 限制
@@ -10,6 +12,7 @@
 - 不明確的部分必須標示為「待確認」，並回到人工審核。
 - UML 必須能追溯到對應需求編號。
 - UML 內容不得超出已確認或已標示假設的需求範圍。
+- 單張圖應保持精簡清晰，避免過度龐大或單一圖節點過多導致渲染失敗。
 
 ## 圖表類型
 - Use Case Diagram：用於描述使用者、外部系統與系統功能邊界。

package/templates/skills/system-analysis/SKILL.md

@@ -8,7 +8,7 @@ description: 用 init、propose、analyze、commit 四段流程整理需求，
 ## 核心交付物
 
 - `srs.md`：需求規格。
-- `uml.puml`：UML 圖。
+- `uml/`：UML 圖目錄（依面向拆分為獨立 `.puml` 檔，如 `main.puml`、`sequence.puml` 等，禁止單檔混放多圖）。
 - `openapi.yaml`：OpenAPI 草稿。
 - `db-schema.md`：DB Schema 草稿。
 - `handoff.md`：給 OpenSpec 或其他 AI 開發工具的開發交接摘要。
@@ -16,12 +16,14 @@ description: 用 init、propose、analyze、commit 四段流程整理需求，
 
 ## 指令流程
 
-| 指令 | 用途 | 執行規則 |
-|---|---|---|
-| `spec:init` | 初始化 | 載入並遵守 `AGENTS.md`、本 skill 與必要規則，確認 `project/` 結構是否存在。 |
-| `spec:propose` | 提出需求 | 整理使用者需求為摘要、目標、初步流程與待確認事項；不歸檔、不修改既有需求。 |
-| `spec:analyze` | 分析與起草 | 先檢查新需求是否與 `project/` 內所有既有需求衝突；無衝突才產出 SRS、UML、OpenAPI、DB Schema 草稿；有衝突則只列出衝突與待釐清問題，待使用者釐清後再次執行 `spec:analyze`。 |
-| `spec:commit` | 確認歸檔 | 只把使用者已確認的版本歸檔到該需求資料夾，更新 `project/index.md`、`project/system-spec.md` 與 `history.md`，並建立本機 Git commit。 |
+使用四個核心指令，並支援簡寫別名（兩者等價）：
+
+| 指令 | 簡寫 | 用途 | 執行規則 |
+|---|---|---|---|
+| `spec:init` | `sci` | 初始化 | 載入並遵守 `AGENTS.md`、本 skill 與必要規則，確認 `project/` 結構是否存在。 |
+| `spec:propose` | `scp` | 提出需求 | 整理使用者需求為摘要、目標、初步流程與待確認事項；不歸檔、不修改既有需求。 |
+| `spec:analyze` | `sca` | 分析與起草 | 先檢查新需求是否與 `project/` 內所有既有需求衝突；無衝突才產出 SRS、UML、OpenAPI、DB Schema 草稿；有衝突則只列出衝突與待釐清問題，待使用者釐清後再次執行 `spec:analyze`（或 `sca`）。 |
+| `spec:commit` | `scc` | 確認歸檔 | 只把使用者已確認的版本歸檔到該需求資料夾，更新 `project/index.md`、`project/system-spec.md` 與 `history.md`，並建立本機 Git commit。 |
 
 ## 硬性限制
 
@@ -41,8 +43,9 @@ description: 用 init、propose、analyze、commit 四段流程整理需求，
 - 交給 OpenSpec 或其他 AI 開發工具時，必須指定它先閱讀 `handoff.md`，並以 `handoff.md` 作為開發入口與限制摘要；其他規格文件作為詳細來源。
 - `spec:commit` 完成文件歸檔後，必須自動建立本機 Git commit；commit message 以需求編號與需求名稱為主，並加上簡短需求說明，格式為 `docs(REQ-001): 需求名稱 - 簡短需求說明`。
 - `spec:commit` 只有在使用者明確要求推送 remote，或專案設定啟用 auto-push 時，才可執行 `git push`；push 失敗時只回報認證或網路問題，不得回滾已完成的文件歸檔與本機 commit。
+- 多人協作與 Git-Flow 模式（延遲綁定序號）：支援多人平行開發。提出需求時可於 feature branch（如 `feat/<name>`）建立草稿目錄，內部使用 `{{REQ_ID}}` 佔位；執行 `spec:analyze` 前應先確保取得 master 最新規格以防漏檢衝突；執行 `spec:commit` 歸檔時向 master 確認最新可用序號並定號，自動將目錄定名為正式 `REQ-xxx`、替換內部佔位符、重新生成 `project/index.md`，避免多人合併時的序號競爭與索引衝突。
 - 文件未經使用者確認，不得標示為 `已審核`。
-- `uml.puml` 不限單一 UML 圖型；`spec:analyze` 必須依需求選擇最能說明流程、互動、狀態或資料關係的 UML 圖，例如活動圖、循序圖、使用案例圖、狀態圖或類別圖，不可為了固定格式硬產生活動圖。需求複雜時，可在同一個 `uml.puml` 內放多張 PlantUML 圖並清楚分段。
+- `uml/` 內的 UML 圖不限單一 UML 圖型；`spec:analyze` 必須依需求選擇最能說明流程、互動、狀態或資料關係的 UML 圖，例如活動圖、循序圖、使用案例圖、狀態圖或類別圖，不可為了固定格式硬產生活動圖。**嚴禁將多張圖混在同一個檔案中**，必須在需求資料夾下的 `uml/` 目錄拆分成獨立的 `.puml` 檔案（例如 `uml/main.puml`、`uml/sequence.puml`、`uml/state.puml`），且每個檔案只能包含一組 `@startuml` 與 `@enduml`，以避免 PlantUML 渲染或預覽失敗。
 - 一次最多問 3 個待確認問題，優先詢問會影響範圍、資料、權限、API、DB 或驗收的問題。
 
 ## analyze 衝突檢查
@@ -55,7 +58,7 @@ description: 用 init、propose、analyze、commit 四段流程整理需求，
 - 所有 `project/REQ-*/openapi.yaml`
 - 所有 `project/REQ-*/db-schema.md`
 - 所有 `project/REQ-*/handoff.md`
-- 必要時讀取 `project/REQ-*/uml.puml`
+- 必要時讀取 `project/REQ-*/uml/*.puml`
 
 至少檢查：
 
@@ -81,7 +84,7 @@ description: 用 init、propose、analyze、commit 四段流程整理需求，
 無衝突時，輸出一個待確認版本，包含：
 
 - SRS 草稿。
-- UML PlantUML 草稿。
+- UML PlantUML 草稿（放置於 `uml/` 資料夾中，每張圖獨立檔案）。
 - OpenAPI YAML 草稿。
 - DB Schema 草稿。
 - Handoff 交接摘要草稿。
@@ -97,7 +100,8 @@ description: 用 init、propose、analyze、commit 四段流程整理需求，
 project/
   REQ-001-name/
     srs.md
-    uml.puml
+    uml/
+      main.puml
     openapi.yaml
     db-schema.md
     handoff.md
@@ -119,7 +123,7 @@ project/
 
 若需求不需要 API 或 DB，必須明確標示「無 API 需求」或「無 DB 需求」。不得在 `handoff.md` 中新增未經使用者確認的角色、權限、資料、流程、狀態、API 或 DB 欄位。
 
-交給 OpenSpec 或其他 AI 開發工具時，應要求它先閱讀 `handoff.md`，並以 `handoff.md` 作為本次開發入口與限制摘要。若需要完整細節，再查閱同需求資料夾內的 `srs.md`、`uml.puml`、`openapi.yaml`、`db-schema.md` 與 `history.md`。
+交給 OpenSpec 或其他 AI 開發工具時，應要求它先閱讀 `handoff.md`，並以 `handoff.md` 作為本次開發入口與限制摘要。若需要完整細節，再查閱同需求資料夾內的 `srs.md`、`uml/`、`openapi.yaml`、`db-schema.md` 與 `history.md`。
 
 歸檔完成後，必須只 stage 本次歸檔相關檔案，並建立本機 Git commit。commit message 格式：
 
@@ -132,10 +136,10 @@ docs(REQ-001): 需求名稱 - 簡短需求說明
 ## 狀態機
 
 ```text
-init -> propose -> analyze
+init (sci) -> propose (scp) -> analyze (sca)
 
-analyze 無衝突 -> 產出待確認版本 -> commit
-analyze 有衝突 -> 釐清問題 -> analyze
+analyze 無衝突 -> 產出待確認版本 -> commit (scc)
+analyze 有衝突 -> 釐清問題 -> analyze (sca)
 
-commit -> 歸檔 -> 本機 Git commit
+commit (scc) -> 歸檔 -> 本機 Git commit
 ```