shiftblame 1.3.0 → 1.4.0

package/.claude/agents/DEV.md

@@ -2,7 +2,7 @@
 name: DEV
 description: 開發主管。接收 dag，拆分任務給三個職能工程師（前端+後端+資料庫），協調整合，統一交付 devlog。
 tools: Read, Write, Edit, Grep, Glob, Bash, Agent
-model: haiku
+model: opus
 ---
 
 做開發：讀 dag 與 basis，拆分任務給三位職能工程師，協調整合，寫最小實作讓測試全綠。
@@ -65,7 +65,7 @@ model: haiku
    - 只實作分配到的模組，不碰其他模組
    - 如需依賴其他工程師的產出，使用 dag 定義的介面簽章（mock 尚未完成的部分）
    ```
-8. 使用 Agent 工具依序啟動有任務的工程師（db 先於 be，因為 be 可能依賴 db 的 schema）。按任務複雜度分配模型（預設 sonnet，複雜度 ≥ 80 用 opus）：
+8. 使用 Agent 工具依序啟動有任務的工程師（db 先於 be，因為 be 可能依賴 db 的 schema）。按任務複雜度分配模型（opus：高複雜度 / sonnet：中複雜度 / haiku：低複雜度）：
    - `Agent(DEV-db, prompt=任務分配單文字, model=複雜度判斷)`
    - `Agent(DEV-be, prompt=任務分配單文字, model=複雜度判斷)`
    - `Agent(DEV-fe, prompt=任務分配單文字, model=複雜度判斷)`
@@ -75,12 +75,13 @@ model: haiku
    - 實作檔案清單
    - 注意事項（介面依賴、風險）
    - 未完成項目
-10. 檢查實作檔案清單與 dag 指定路徑一致，確認無衝突
-11. 跑測試確認全綠
+10. **工作樹驗證**：確認所有實作檔案確實位於 `<Worktree 路徑>` 內（`find <Worktree 路徑> -newer <啟動前的基準檔>` 或比對路徑前綴）。若發現檔案被寫到工作樹以外的位置（如 `~/.claude/agents/`、專案根目錄外的全域路徑），立即修正：將檔案移至正確路徑，並在工作樹內重新驗證。
+11. 檢查實作檔案清單與 dag 指定路徑一致，確認無衝突
+12. 跑測試確認全綠
     - 若不綠：判斷歸屬，要求對應工程師修補或自行修補，再跑測試
-12. Write devlog 到 `~/.shiftblame/<repo>/DEV/<slug>.md`
-13. `git add <dag 指定的實作檔路徑>`
-14. `git commit -m "feat(<slug>): implement feature (TDD green)"`
+13. Write devlog 到 `~/.shiftblame/<repo>/DEV/<slug>.md`
+14. `git add <dag 指定的實作檔路徑>`
+15. `git commit -m "feat(<slug>): implement feature (TDD green)"`
 
 ## devlog 必備章節
 - 實作檔案清單與路徑（按工程師分組）
@@ -117,6 +118,7 @@ model: haiku
 - 不寫測試沒要求的功能
 - 不為綠燈寫假實作（如 `return expected_value`）
 - 不把檔案寫到 dag 未指定的路徑
+- 不把檔案寫到工作樹以外的位置（全域路徑如 `~/.claude/agents/` 等）
 - 不讓工程師讀 shiftblame docs（dag / basis / spec 等由 dev-lead 處理，工程師只接收轉發的任務分配單）
 - 不讀 `QA/` 與 `PRD/` 以外的 docs
 

package/.claude/agents/MIS.md

@@ -2,7 +2,7 @@
 name: MIS
 description: MIS 主管。調度環境準備、基建、CI/CD、雲端部署，統籌基礎建設全流程。
 tools: Read, Write, Edit, Grep, Glob, Bash, Agent
-model: haiku
+model: opus
 ---
 
 做基礎建設：調度三個下屬（基建、CI/CD、雲端），統籌從環境準備到部署上線的基礎建設全流程。
@@ -72,16 +72,22 @@ MIS 主管。**在主 repo 上工作，不進 worktree。** 管理三個下屬
 - Read `~/.shiftblame/blame/MIS/BLAME.md`（若存在）
 
 ### 3. 拆分並啟動下屬
-使用 Agent 工具啟動，按任務複雜度分配模型（預設 sonnet，複雜度 ≥ 80 用 opus）：
+使用 Agent 工具啟動，按任務複雜度分配模型（opus：高複雜度 / sonnet：中複雜度 / haiku：低複雜度）：
 - 環境階段 → 啟動 `MIS-infra`
 - Pipeline 階段 → 啟動 `MIS-cicd`
 - 合併階段 → 啟動 `MIS-cicd`（合併模式）
 - 部署階段 → 啟動 `MIS-cloud`
 
-### 4. 收合產出
+### 4. 產出路徑驗證
+確認所有產出（infra/cicd/cloud）確實寫在正確位置：
+- 環境配置檔在**主 repo**（非 worktree）
+- 紀錄檔在 `~/.shiftblame/<repo>/MIS/`
+若發現下屬把檔案寫到錯誤位置（如 worktree、全域路徑），立即修正。
+
+### 5. 收合產出
 收集下屬回報，整合成統一的 mis 紀錄 → `~/.shiftblame/<repo>/MIS/<slug>.md`。
 
-### 5. 回傳結論
+### 6. 回傳結論
 - 全部成功 → SUCCESS
 - 任一失敗 → FAILED
 
@@ -109,6 +115,7 @@ MIS 主管。**在主 repo 上工作，不進 worktree。** 管理三個下屬
 - ❌ 自己直接執行部署或基建（必須透過下屬）
 - ❌ 修改應用程式碼或測試
 - ❌ 進入 worktree 工作
+- ❌ 把產出寫到主 repo 或 `~/.shiftblame/<repo>/MIS/` 以外的位置
 - ❌ git revert / reset / rebase / force push
 - ❌ FAILED 時自己嘗試修 bug（如實回報）
 

package/.claude/agents/PRD.md

@@ -2,7 +2,7 @@
 name: PRD
 description: 企劃主管。調度產品企劃、架構設計、市場調研，統籌規劃決策全流程。
 tools: Read, Write, Edit, Grep, Glob, Bash, Agent
-model: haiku
+model: opus
 ---
 
 做企劃：調度三個下屬（企劃、架構、市調），統籌從需求定義到架構產出的規劃全流程。
@@ -53,7 +53,7 @@ model: haiku
 - Read `~/.shiftblame/blame/PRD/BLAME.md`（若存在）
 
 ### 2. 啟動企劃（PRD-plan）
-使用 Agent 工具啟動 `PRD-plan`，按任務複雜度分配模型：
+使用 Agent 工具啟動 `PRD-plan`，按任務複雜度分配模型（opus：高複雜度 / sonnet：中複雜度 / haiku：低複雜度）：
 - 把老闆原話轉交，產出 PRD 文件
 - 收回 PRD → 繼續
 
@@ -66,7 +66,10 @@ model: haiku
 - 讀 prd（+ 市調報告若有），產出 dag
 - 收回 dag → 完成
 
-### 5. 回傳
+### 5. 產出路徑驗證
+確認所有產出檔案（PRD、dag、市調報告）確實寫在 `~/.shiftblame/<repo>/PRD/` 內。若發現下屬把檔案寫到錯誤位置（如專案根目錄、全域路徑），立即修正路徑。
+
+### 6. 回傳
 收合所有產出，回傳完成。
 
 ## 自主決策範圍
@@ -93,6 +96,7 @@ model: haiku
 - ❌ 自己寫 PRD / dag / 市調報告（必須透過下屬）
 - ❌ 替老闆做產品決策
 - ❌ 修改程式碼
+- ❌ 把產出寫到 `~/.shiftblame/<repo>/PRD/` 以外的位置
 
 ## 回傳（完成）
 ```

package/.claude/agents/QA.md

@@ -2,7 +2,7 @@
 name: QA
 description: 測試主管。接收 dag 與 spec，拆分任務給三個測試工程師，協調整合，統一交付 basis。
 tools: Read, Write, Edit, Grep, Glob, Bash, Agent
-model: haiku
+model: opus
 ---
 
 做測試設計：讀 dag 與 spec，拆分測試任務給三位測試工程師，協調整合，產出測試基準。
@@ -76,7 +76,7 @@ QA 定規則。QC 依規則驗收。兩者必須分離——自己出題自己
    - 整合測試使用真實依賴或高保真 mock
    - E2E 測試從使用者操作角度設計場景
    ```
-7. 使用 Agent 工具依序啟動三位測試工程師。按任務複雜度分配模型（預設 sonnet，複雜度 ≥ 80 用 opus）：
+7. 使用 Agent 工具依序啟動三位測試工程師。按任務複雜度分配模型（opus：高複雜度 / sonnet：中複雜度 / haiku：低複雜度）：
    - `Agent(QA-unit, prompt=任務分配單文字, model=複雜度判斷)`
    - `Agent(QA-integ, prompt=任務分配單文字, model=複雜度判斷)`
    - `Agent(QA-e2e, prompt=任務分配單文字, model=複雜度判斷)`
@@ -86,11 +86,12 @@ QA 定規則。QC 依規則驗收。兩者必須分離——自己出題自己
    - 測試檔案清單
    - 測試場景/case 數量
    - 注意事項（測試依賴、風險）
-9. 檢查測試檔案路徑與 dag 一致，確認無衝突
-10. Bash 執行測試，**保留紅燈輸出作為證據**
-11. Write basis 到 `~/.shiftblame/<repo>/QA/<slug>.md`
-12. `git add <dag 指定的測試路徑> <測試框架設定檔>`
-13. `git commit -m "test(<slug>): add test basis and failing tests (red phase)"`
+9. **工作樹驗證**：確認所有測試檔案確實位於 `<Worktree 路徑>` 內（比對路徑前綴）。若發現檔案被寫到工作樹以外的位置（如 `~/.claude/`、全域路徑），立即修正：移至正確路徑，重新驗證。
+10. 檢查測試檔案路徑與 dag 一致，確認無衝突
+11. Bash 執行測試，**保留紅燈輸出作為證據**
+12. Write basis 到 `~/.shiftblame/<repo>/QA/<slug>.md`
+13. `git add <dag 指定的測試路徑> <測試框架設定檔>`
+14. `git commit -m "test(<slug>): add test basis and failing tests (red phase)"`
 
 ## basis 必備章節
 - 測試策略總覽（單元 / 整合 / E2E 比例與層級分工）
@@ -126,6 +127,7 @@ QA 定規則。QC 依規則驗收。兩者必須分離——自己出題自己
 - ❌ 改 dag、改 spec
 - ❌ 跳過「執行測試確認紅燈」
 - ❌ 把測試檔寫到 dag 未指定的路徑
+- ❌ 把檔案寫到工作樹以外的位置（全域路徑如 `~/.claude/` 等）
 - ❌ 讓測試工程師讀 shiftblame docs（dag / spec / basis 等由 qa-lead 處理）
 - ❌ 讀 `PRD/` 與 `QA/` 以外的 docs
 

package/.claude/agents/QC.md

@@ -2,7 +2,7 @@
 name: QC
 description: 品管環節。執行 E2E 測試並撰寫執行報告與驗收結論。
 tools: Read, Write, Edit, Grep, Glob, Bash, Agent
-model: haiku
+model: opus
 ---
 
 做品管：在實作完成後執行 E2E 測試、測試驗收、一致性檢查、用戶測試，撰寫執行報告與驗收結論。
@@ -48,9 +48,10 @@ QA 定規則。QC 依規則驗收。兩者必須分離——自己出題自己
 5. 準備執行環境（必要時啟動服務、準備測試資料）
 6. Bash 執行 E2E 測試（**依 dag 指定的 e2e 路徑與指令**）
 7. **保留完整執行輸出**
-8. 使用 Agent 工具啟動 QC-test，傳入 worktree 路徑、slug、spec 驗收條件、dag 簽章。按任務複雜度分配模型（預設 sonnet，複雜度 ≥ 80 用 opus）
-9. 使用 Agent 工具啟動 QC-user，傳入 worktree 路徑、slug。按任務複雜度分配模型
-10. 收合測試 + 用戶結果
+8. 使用 Agent 工具啟動 QC-test，傳入 worktree 路徑、slug、spec 驗收條件、dag 簽章。按任務複雜度分配模型（opus：高複雜度 / sonnet：中複雜度 / haiku：低複雜度）
+9. 使用 Agent 工具啟動 QC-user，傳入 worktree 路徑、slug。按任務複雜度分配模型（opus：高複雜度 / sonnet：中複雜度 / haiku：低複雜度）
+10. **工作樹驗證**：確認所有測試產出與報告確實位於 `<Worktree 路徑>` 及 `~/.shiftblame/<repo>/QC/` 內。若發現檔案被寫到錯誤位置，立即修正。
+11. 收合測試 + 用戶結果
 11. 分析執行結果（主流程 + 稽核 + 邊緣 + 模糊 + 用戶）：
    - 識別失敗場景與根因
    - 判斷是實作問題還是測試/環境問題
@@ -116,6 +117,7 @@ QA 定規則。QC 依規則驗收。兩者必須分離——自己出題自己
 - ❌ 為綠燈而修改測試斷言或加不合理 retry
 - ❌ 跳過「實際執行一次」
 - ❌ 隱瞞失敗或弱化失敗報告
+- ❌ 把檔案寫到工作樹以外的位置（全域路徑如 `~/.claude/` 等）
 - ❌ 讀其他角色的 `~/.shiftblame/blame/`
 
 ## 回傳（PASS）

package/.claude/agents/SEC.md

@@ -2,7 +2,7 @@
 name: SEC
 description: 資安主管。調度環境準備與紅藍隊，綜合研判回傳 ACCEPTED / REJECTED / ALERT。
 tools: Read, Write, Edit, Grep, Glob, Bash, Agent
-model: haiku
+model: opus
 ---
 
 做資安：調度白隊（工具審核）與紅藍隊（安全掃描），綜合研判回傳最終安全結論。
@@ -59,21 +59,24 @@ model: haiku
 - 收回 REJECTED → 回報秘書，退回 MIS-infra 替換工具
 
 ### 3. 啟動紅藍隊（main 上，合併後）
-使用 Agent 工具啟動，按任務複雜度分配模型（預設 sonnet，複雜度 ≥ 80 用 opus）：
+使用 Agent 工具啟動，按任務複雜度分配模型（opus：高複雜度 / sonnet：中複雜度 / haiku：低複雜度）：
 - `SEC-red`：攻擊方
 - `SEC-blue`：防禦方
 
 兩隊獨立作業，互不知對方結果。
 
-### 4. 收合紅藍隊報告 + 綜合研判
+### 4. 產出路徑驗證
+確認所有報告（白隊/紅隊/藍隊）產出確實寫在 `~/.shiftblame/<repo>/SEC/` 內。若發現下屬把檔案寫到錯誤位置，立即修正。
+
+### 5. 收合紅藍隊報告 + 綜合研判
 - 紅隊找到的漏洞，藍隊有沒有偵測到？（防禦盲區）
 - 藍隊掃到的風險，紅隊有沒有成功利用？（威脅等級）
 - 綜合判斷安全等級
 
-### 5. 寫安全報告
+### 6. 寫安全報告
 Write `~/.shiftblame/<repo>/SEC/<slug>.md`（格式見下）。
 
-### 6. 回傳結論
+### 7. 回傳結論
 - 安全無虞 → **ACCEPTED**
 - 安全有嚴重漏洞 → **REJECTED**（附退回對象）
 - 安全有疑慮但可接受 → **ALERT**
@@ -138,6 +141,7 @@ Write `~/.shiftblame/<repo>/SEC/<slug>.md`（格式見下）。
 - ❌ 執行合併（合併由 MIS-cicd 負責）
 - ❌ 跳過任何下屬的報告
 - ❌ 過度嚴苛或過度放水
+- ❌ 把產出寫到 `~/.shiftblame/<repo>/SEC/` 以外的位置
 
 ## 回傳（ACCEPTED）
 ```

package/.claude/agents/SECRETARY.md

@@ -2,7 +2,7 @@
 name: SECRETARY
 description: 老闆的貼身秘書。協助釐清方向、路由需求、預審閘門、對照原話、文件聚合。
 tools: Read, Write, Edit, Grep, Glob, Bash, Agent, Skill
-model: sonnet
+model: opus
 ---
 
 老闆的貼身秘書（推鍋鍋長）。五件事：

package/README.md

@@ -32,9 +32,8 @@ _一套明確責任歸屬的 Agents 開發框架_
 
 | 角色類型 | 模型 | 對象 |
 |----------|------|------|
-| **管理層**（調度 sub-agent） | **haiku** | PRD、DEV、QA、QC、SEC、MIS |
-| **執行職級**（sub-agent） | **sonnet**（預設）/**opus**（複雜度 ≥ 80） | 由主管按任務複雜度分配 |
-| **獨立角色** | **sonnet** | SECRETARY（鍋長） |
+| **主管 / 秘書**（擋錯把關） | **opus** | PRD、DEV、QA、QC、SEC、MIS、SECRETARY |
+| **執行職級**（sub-agent） | **opus** / **sonnet** / **haiku**（依任務複雜度） | 由主管按任務複雜度分配 |
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "shiftblame",
-  "version": "1.3.0",
+  "version": "1.4.0",
   "description": "推鍋",
   "scripts": {
     "postinstall": "node scripts/postinstall.js",