  jiantw83andClaude Opus 5
|
ceb723c63e
|
test(流程正本): 新增 sdlc-sync，並讓另外兩份正本整併完自動接回
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:19:11 +00:00 |
|
|
jiantw83andClaude Opus 5
|
f85fabb758
|
feat(流程正本): 新增 sdlc-sync，並讓另外兩份正本整併完自動接回
挑出哪些留言真的是決策、寫回去之前讓使用者點頭、略過的保持未標記——三件都只有正本做得到。
analyze 與 feat 原本寫「建議先執行 /sdlc-sync，再回來」，那等於要使用者重打指令。改成直接走
sync 的流程、做完自動接回，並在接回前重新抽取一次——接著用舊的那一份做事，這一整段就白做了。
略過的留言會讓未處理留言數停在大於 0，於是 analyze 與 feat 每次都會再停一次。這是驗收標準
本身的兩條放在一起的結果，正本把它講明白，讓使用者分得出「沒整併乾淨」與「我選了略過」。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:19:10 +00:00 |
|
|
jiantw83andClaude Opus 5
|
3ad08be14f
|
test(comments-merge): 把留言裡的決策整併回議題描述並標記
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:19:10 +00:00 |
|
|
jiantw83andClaude Opus 5
|
16f93f6e8b
|
feat(comments-merge): 把留言裡的決策整併回議題描述並標記
判斷「哪幾則有決策、該併進哪一段」是讀得懂內容的人的事；這一支只負責把結果安全地寫回去。
先寫描述再標記，描述寫失敗就不標記：反過來的話，那幾則已經被標成處理過，再也不會被提出來。
--merged 只收真的併進去的那幾則，略過的保持未標記。標記之前先核對那幾則確實在這顆議題上——
打錯 id 的 reaction 會落在別顆議題的留言上，而那幾乎不會有人發現。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:19:09 +00:00 |
|
|
jiantw83andClaude Opus 5
|
5ef25d3ee9
|
test(抽取契約): 未整併的判定改成只認自己打的 +1
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:19:08 +00:00 |
|
|
jiantw83andClaude Opus 5
|
c1ab712afd
|
feat(議題解析): 換掉一個段落的內容，標題與其餘段落一字不動
整併留言裡的決策時用它。不整份重寫的理由跟 upsertLineInSection 一樣，只是代價更大：
重寫會把別人在其他段落的編輯一起蓋掉，而議題的編輯紀錄沒有人會去比對。
三件事照著同檔既有的規矩做：圍欄裡的假標題不算段落；同名標題出現不只一次時交回 ambiguous
而不賭第一個（蓋掉的是一整段，猜錯的代價比 tickLine 更高）；換行沿用 body 原本的那一種，
CRLF 的 body 裡混進 LF 會讓抽取契約交出的 raw 對不上原文，之後就勾不動那幾行。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:19:08 +00:00 |
|
|
jiantw83andClaude Opus 5
|
3b7e3bdfc7
|
test(pr-comments): 議題也讀得了，不再先打 PR 端點
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:19:07 +00:00 |
|
|
jiantw83andClaude Opus 5
|
051fe0ded4
|
fix(pr-comments): 議題也讀得了，不再先打 PR 端點
每個 PR 都是議題，議題不一定是 PR——原本的註解把這句話講反了，程式也照著反過來寫：
先打 /pulls/{index}，對純議題回 404，於是 /sdlc-sync 在讀到第一則留言之前就斷了。
改成先讀 /issues/{index}（兩種都有），看它有沒有 pull_request 才決定要不要去翻 review。
輸出加上「類型」讓下游知道拿到的是議題還是 PR。
讀取的共用結構沿用 pr-threads（#48 為了讓 pr-watch 數同一件事而抽出來的）：readGeneral
改名 readGeneralComments 並導出，純議題只叫它；pr-threads 自己那份 markedByMe 拿掉，
改用 lib 的 mergedByMe。#48 的檔頭擔心「規則寫兩份遲早會各自演化」，現在三處共用一份。
試跑改印 commonRequests：pr-comments 收得下兩種輸入，而試跑階段還沒讀過議題、不知道是
哪一種。與其假設是 PR 而列出五個（對純議題有三個根本不會發），不如只列一定會發的。
pr-watch 的輸入一定是 PR，繼續用 plannedRequests。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:19:06 +00:00 |
|
|
jiantw83andClaude Opus 5
|
b263915afc
|
test(pr-create): 讀檔與列留言收進 lib，並讓已整併只認自己打的 +1
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:19:05 +00:00 |
|
|
jiantw83andClaude Opus 5
|
ee474d0439
|
refactor(lib): 讀檔與列留言收進 lib，並讓已整併只認自己打的 +1
「讀一個 --xxx-file 或直接失敗」原本在四支腳本各寫一份，錯誤碼還有三種拼法
（BODY_FILE_NOT_FOUND／BODY_FILE_MISSING／CONTENT_FILE_NOT_FOUND）。同一種情況要有同一個
碼，呼叫端才分辨得出是哪一步壞了。留言分頁的那段咒語也是第三份，一併收成 listIssueComments。
countUnmergedComments 原本接受任何人的 +1，而讀留言那邊只認自己的——兩端對「已整併」的
定義不一致。後果是隊友對決策留言按個讚，未處理留言數就掉到 0，analyze 與 feat 再也不提示，
那則決策永遠不會被收進描述。統一成只認自己打的：別人按讚是「我同意」，不是「已經收進去了」。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:19:05 +00:00 |
|