feat(overview-artifact): 產生可預覽總覽與截圖 fallback

docs/adr/0001-以集中式雜湊路徑的-worktree-隔離平行工作包.md

@@ -0,0 +1,21 @@
+---
+status: accepted
+---
+
+# 以集中式雜湊路徑的 worktree 隔離平行工作包
+
+`/sdlc-feat` 與 `/sdlc-fix` 一律在獨立的 worktree 上工作，而非在同一個工作目錄上切換分支；worktree 集中於 `~/.tea-sdlc/worktrees/{hash}`，`hash` 為正規化後 `owner/repo/分支名` 的 sha256 前 12 碼。這麼做的核心理由是 agent 非同步讀檔：它可能在分支被切走之後才去讀，而它不會察覺自己讀到的是別顆工作包的程式碼，產出看似合理卻接錯上下文——前兩種常見損耗（未提交變更擋路、建置產物跨分支混淆）人會當場發現，這一種不會，所以規則是「一律」而非「有衝突才用」。
+
+## Considered Options
+
+- **repo 內的 `.worktrees/`**：未被忽略時會出現在目標專案的 `git status`，而要它不出現就得改目標專案的忽略設定——本 plugin 明文不修改目標專案的檔案。
+- **目標 repo 的兄弟目錄**：不污染 repo，但會在使用者的專案父目錄長出一堆目錄，而那個目錄結構屬於使用者，不屬於這個工具。
+- **把分支名的斜線攤平成 `-` 當目錄名**：`feat/a-b/main` 與 `feat/a/b/main` 會撞成同一個名字，而既有的分支命名規則（`{類型}/{需求描述}/{功能描述}`）恰好讓這種形狀有機會出現。
+- **目錄名加可讀後綴**：被否決，因為 `git worktree list` 本來就會把分支名印在路徑旁邊，可讀性缺口有限。
+
+## Consequences
+
+- 路徑由工作包**純函式推導**，不需要任何本機對照表或狀態檔，因此換機器或換 agent 之後推導結果相同；推導不到就重建，這正是「不寫入任何本機狀態檔」這條既有約束所要求的接手方式。
+- `git worktree add` 仍會在目標 repo 的 `.git/worktrees/` 底下寫中繼資料。這是 git 的機制，無法避免。「不修改目標專案的檔案」指的是專案內容檔，不含 git 自身的內部中繼資料——這條界線是本決策劃定的。
+- 目錄名是雜湊，光看路徑字串認不出是哪顆工作包。緩解來自兩處：`git worktree list` 印出分支名，PR 檢查腳本回報推導出的路徑。
+- 正規化（小寫、去前後空白）是必要的：沒有它，同一棵 worktree 會因輸入大小寫或多一個空白而被推導成兩個不同路徑。

docs/adr/0002-以能力描述而非工具名表達委派.md

@@ -0,0 +1,18 @@
+---
+status: accepted
+---
+
+# 以能力描述而非工具名表達委派
+
+流程正本在只在意結果的步驟上標記 `〔可委派〕`，並以**能力描述**說明怎麼委派——「你的環境若能把工作交給子代理，就交出去，只把結果帶回來；不能就自己做」——而不指名任何平台的子代理工具。子代理是平台專屬能力（Claude Code 與 Codex 有，Copilot／Kiro／OpenCode 不一定），而流程正本必須保持平台中立：這是 #4 已交付並打勾的驗收標準，也是 `AGENTS.md` 的模組邊界之一。能力描述對不支援的平台是自然降級，同一份正本兩邊都讀得通，不需要維護兩份。
+
+## Considered Options
+
+- **正本直接寫平台工具名**：最精確、agent 最不會誤判，但直接違反「流程正本不含任何平台專屬語法」，並且要為七個平台維護分歧的正本——那正是這個專案立「流程正本只有一份」時要防的事。
+- **由 `install.js` 產生轉接檔時依平台注入**：轉接檔只有一行指回正本，塞不下步驟級的指示；而「哪些步驟可委派」是流程知識，搬進 `install.js` 會污染它「唯一知道各平台目錄結構」的單一職責。
+
+## Consequences
+
+- 這個寫法**刻意比它能做到的更模糊**。下一個讀到它的人第一反應很可能是「為什麼不直接寫工具名？」然後就把它改掉——這顆 ADR 存在的主要目的就是攔下那個修改。
+- 委派的判準（四條，見 `references/delegation.md`）與正本上的標記必須靠測試綁在一起：資產測試斷言「正本上被標記的步驟集合等於判準文件列出的集合」。沒有這條雙向斷言，兩邊會漂開，而漂開時不會有任何東西報錯。
+- 判準第二條（步驟中不會詢問使用者）與第四條（只產出草稿或唯讀結果，不直接寫入 Gitea 或 git）是硬排除，不是建議。前者因為子代理問不到使用者，後者因為子代理的失敗沒有人看著——備妥工作樹失敗會中止整個領取、實際提交失敗會留下半套 git 歷史，兩者都需要當場有人判斷下一步。