  jiantw83andClaude Opus 5
|
42f5b86299
|
merge(pr-留言): 把議題支援套到 pr-threads 的共用結構上
#48 把留言讀取抽成 pr-threads 給 pr-watch 與 pr-comments 共用，本分支則在修「純議題讀不了」
與「已處理的判定有兩份」。兩邊動到同一塊，但要的其實是同一件事——#48 的檔頭就寫著
「規則寫兩份遲早會各自演化，一邊認自己打的 +1、另一邊認任何人的」，而那正是本分支在
lib 與 pr-comments 之間發現的那個 bug。
合併的方向是保留 pr-threads 的結構，把修正套進去：
- readGeneral 改名 readGeneralComments 並導出，pr-comments 判斷出是純議題時只叫它。
先讀 /issues/{index} 再決定要不要翻 review——每個 PR 都是議題，反過來不成立。
- pr-threads 自己那份 markedByMe 拿掉，改用 lib 的 mergedByMe。抽取契約數未整併則數
用的是同一條規則，現在三處共用一份，#48 擔心的分歧不會再發生。
- pr-comments 的試跑改印 commonRequests：它收得下兩種輸入，而試跑階段還沒讀過議題、
不知道是哪一種。與其假設是 PR 而列出五個（對純議題有三個根本不會發），不如只列一定
會發的，其餘交給 note。pr-watch 的輸入一定是 PR，繼續用 plannedRequests。
lib.js 與 sdlc-feat.md 兩邊改的是不同區域，三方合併無衝突。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:16:34 +00:00 |
|
|
jiantw83
|
781963c9d1
|
feat(流程正本): 新增 sdlc-sync，並讓另外兩份正本整併完自動接回
挑出哪些留言真的是決策、寫回去之前讓使用者點頭、略過的保持未標記——三件都只有正本做得到。
analyze 與 feat 原本寫「建議先執行 /sdlc-sync，再回來」，那等於要使用者重打指令。改成直接走
sync 的流程、做完自動接回，並在接回前重新抽取一次——接著用舊的那一份做事，這一整段就白做了。
略過的留言會讓未處理留言數停在大於 0，於是 analyze 與 feat 每次都會再停一次。這是驗收標準
本身的兩條放在一起的結果，正本把它講明白，讓使用者分得出「沒整併乾淨」與「我選了略過」。
|
2026-09-17 09:08:09 +00:00 |
|
|
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 |
|
|
jiantw83
|
997d4ec280
|
docs(sdlc-feat): 第三段補上兩個 repo 的區別與重跑的行為
說明 --repo 與 --issue-repo 的差別、--base 要明講不讓腳本猜、重跑不會開出第二顆 PR，
以及提交中途失敗時不要自己回捲歷史。
|
2026-09-17 08:23:28 +00:00 |
|
|
jiantw83
|
0b728ca270
|
feat(sdlc-feat): 加入第三段「提交與開立 PR」
PR 描述的八個段落與順序寫在正本裡，由 pr-create 擋；正本負責的是腳本擋不住的事：
測試結果要貼實際輸出而不是改寫成一句話、被擋下來時補真的內容而不是為了通過而拼湊、
以及跨兩個功能時用 --files 分兩次跑。
先開 PR 再停錶的理由也寫進去了：工時要記在真的有做事的那段時間上。
|
2026-09-17 08:23:22 +00:00 |
|
|
jiantw83andClaude Opus 5
|
a45e981c95
|
feat(流程正本): sdlc-feat 加入第二段「逐項實作」
一項一項做完並即時勾選，讓議題頁的進度條隨時反映真實狀態。
過程不打斷：二十項待辦不按二十次同意，只印進度；也不為了勾選留留言——勾選改的是 body，
進度條自己會動，逐項留言會把議題洗版，reviewer 得從一堆「已完成第 N 項」裡找真正的討論。
真正該停下來問的只有三種，列出來了。
規則正本指名讀取，不在這裡複述——抄過來就會有兩份各自演化的規則。
中斷後重跑從 Gitea 的勾選狀態接續，不看任何本機檔案；重複勾選是安靜的 no-op，
所以不確定某一項有沒有勾到時直接再勾一次即可，不必先查。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 07:39:48 +00:00 |
|
|
jiantw83andClaude Opus 5
|
d55f1682b7
|
feat(流程正本): 新增 sdlc-feat 與它的第一段「領取與開工準備」
第一段把工作包安全地認領下來、起錶、備妥分支，不改任何一行程式碼——它只負責讓後面的
實作有個乾淨的起點。
正本負責三件腳本做不到的事：讀完工作包後，未處理留言不是 0 就先停下來建議整併；
新分支從哪裡長出來要問過使用者，一次一題、附理由、永遠留手動輸入；議題標題翻成英文
kebab 也是 agent 的事，腳本只驗格式。
領取鎖的四種狀態連同放行那一種都列在表上，缺標籤則另外交代——它是 repo 的前置條件，
不是鎖的第五種狀態，混在一起會讓決策表說不清楚。
工作包跨多個 repo 時逐一確認要在哪幾個開分支，分支名在每個 repo 都相同。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 07:07:01 +00:00 |
|