  jiantw83andClaude Opus 5
|
d3ce364727
|
docs(sdlc-feat): description 跟著改成「備妥工作樹、起錶」
轉接檔的一行說明是從這裡取的，順序寫錯會讓人以為錶還是在領取那一步起。
議題 #40
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 16:30:00 +08:00 |
|
|
jiantw83andClaude Opus 5
|
0154cf59d4
|
fix(claim): 被碼錶擋下時明說停錶不會動到既有的工作樹
議題 #38 的使用者故事第 30 條：使用者常以為停錶等於放棄那顆工作包，於是寧可
不停——工時就記到別顆議題去了。碼錶只管時間、工作樹只管檔案，兩者互不相干，
這件事要在擋下來的當下就講，不能指望使用者自己推論。
領取與起錶會撞到同一個擋路理由，訊息收進 lib 只寫一份。順手收掉 review 指出的
三處：planWorktree 沒用到的 repo 參數、與 path.resolve 同名而誤導的區域函式、
以及只有 lib 自己用得到卻對外 export 的兩支路徑函式。
回滾補上最後一道：git 清不掉時把目錄本身也刪掉。那條路徑在這次執行之前不存在
（不存在正是建立的前提），裡面不可能有使用者的東西，而留著它下一次重跑會直接
撞上 WORKTREE_PATH_TAKEN——一次失敗的建立不該讓人從此開不了工。
議題 #40
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 16:29:12 +08:00 |
|
|
jiantw83andClaude Opus 5
|
4583a5f210
|
docs(sdlc-feat): 第一段改成領取、備妥工作樹、最後起錶
正本跟著實作走：分支那一步改成工作樹，新增起錶那一步排在它後面，
並把三處「不要自己決定」寫明——來源分支不存在時不自己換一支、路徑被佔住時
不自己刪、工作樹建不起來時不退回原地切分支。工作區不乾淨的處置整段拿掉：
工作樹本來就是為了讓未提交的變更不再擋路。
AGENTS.md 補上兩條邊界。git worktree add 一定會在目標 repo 的 .git/worktrees/
底下寫中繼資料，這是 git 的機制，無法避免——「不改目標專案」指的是專案的內容檔，
把這件事明說，免得下一個人以為實作違規。
議題 #40
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 16:29:12 +08:00 |
|
|
jiantw83andClaude Opus 5
|
74b4ca130e
|
feat(timer): 碼錶移出領取，等工作樹建成之後才起
原本的順序是「放行 → 設 assignee 與標籤 → 起錶 → 處理分支」，而工作樹建立
失敗會中止整個領取——錶已經起了才失敗，使用者會被計一段什麼都沒做的時間，
而工時要準正是工時報表的立足點。
claim 只留領取鎖的兩件事（assignee 與標籤），起錶交給新的 timer.js，由流程
正本排在 branch-prep 之後。timer 已經跑在這顆議題上時什麼都不做：中斷後重跑
是它最常見的處境，重新起錶會把已經累積的時間切成兩段；跑在別顆上則照舊擋下，
不代勞停錶。
三支腳本讀碼錶的那段各留一份，趁這次收進 lib。
議題 #40
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 16:27:43 +08:00 |
|
|
jiantw83andClaude Opus 5
|
5b740c236b
|
feat(branch-prep): 一律在獨立的工作樹上開工，不在原地切換分支
同一份 clone 上同時持有多顆工作包時，原地切分支有三種損耗，一種比一種難查：
未提交的變更擋路、建置產物跨分支混淆，以及 agent 讀到不屬於它那顆工作包的
程式碼——agent 是非同步的，它可能在分支已經被切走之後才去讀檔，而且不會察覺，
產出看起來完全合理，只是接錯了上下文。前兩種人會當場發現，第三種不會，
所以工作樹一律建立，不是「有衝突才用」。
建不起來就中止，不退回原地切分支：靜默降級會讓使用者以為自己在隔離環境裡，
其實在原地改。
分支與工作樹合併為一個原子動作（fetch 後一次 worktree add），並補上回滾——
git 在 worktree add 失敗時仍會把分支留下來，那是最難查的半成品：下一次重跑
會走到「目標分支已存在」那條路，起點從此不再是遠端的來源分支。
起點一律取自 origin/{來源分支}，遠端沒有就中止，不退回本機同名分支；
本機分支可能落後好幾天，而這件事從輸出上完全看不出來。原「來源分支在遠端
已存在時 pull 而非重建」那條，用更強的方式達成同一個目的：根本不碰本機分支，
就沒有覆蓋他人進度的可能。
不設 upstream：此刻遠端還沒有這個新分支，--track 會把 upstream 指到來源分支，
之後 git pull 會把來源分支的提交拉進來。留給第一次 push -u 自然建立。
路徑由 owner/repo/分支名 正規化後取雜湊推導（lib 的 worktreePath），不查表、
不寫狀態檔，換機器算出來一樣。取雜湊而不是把斜線攤平成 -，是因為攤平會讓
feat/a-b/main 與 feat/a/b/main 撞成同一個目錄，而現行的分支命名規則恰好讓
這種形狀有機會出現。
議題 #40
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 16:27:43 +08:00 |
|