  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
|
fff599d0f1
|
fix(pr-comments): 議題也讀得了，不再先打 PR 端點
每個 PR 都是議題，議題不一定是 PR——原本的註解把這句話講反了，程式也照著反過來寫：
先打 /pulls/{index}，對純議題回 404，於是 /sdlc-sync 在讀到第一則留言之前就斷了。
改成先讀 /issues/{index}（兩種都有），看它有沒有 pull_request 才決定要不要去翻 review。
輸出加上「類型」讓下游知道拿到的是議題還是 PR。
|
2026-09-17 09:08:05 +00:00 |
|
|
jiantw83
|
cc29b5bc21
|
feat(pr-comments): 讀 PR 上的三類留言
一般留言、review 總評、行內留言分散在三個端點，漏掉任何一類就會有意見沒被處理——
而那正是 /sdlc-fix 存在的理由。只讀不寫，必改／建議的分類由讀到內容的人判斷。
三類的「已處理」機制不同：一般留言與總評看自己打的 +1，行內留言看有沒有被 resolve。
總評的 reaction 掛在它在 issue comment 表裡那一份的 id 上，由 timeline 對應得出來；
拿 review 自己的 id 去打會 404，兩個 id 不同命名空間。
reaction 要是自己打的才算已處理：reviewer 對留言按讚是「我同意」，不是「這則處理過了」，
當成已處理會讓那一則被靜靜跳過。
行內留言的位置分兩側：新檔那側在 position，被刪掉的那行在 original_position，Gitea 只填
其中一個。輸出把兩者收斂成「行」與「側」，回覆時才知道該送哪個欄位。也帶出 commit，
讓回覆落在原留言的那個 commit 上。
三種清單都逐頁讀完：這個站台的預設頁大小是 30，沒分頁的話第 31 個 review 之後整批消失。
|
2026-09-17 08:46:33 +00:00 |
|