feat(sdlc): 工作包隔離、留言先取共識、盯 PR 到合併與每任務一筆日誌 #30
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: plugins/sdlc#30
Reference in New Issue
Block a user
PR 描述
摘要
feat/sdlc-flow-rules/main累積的內容整批推上develop。本存取庫是使用者 15 條規則第一群「SDLC 執行流程」的匯流處，六條規則有四條在這裡收斂成技能流程：R4 工作包隔離、R11 PR 留言修正先走決策樹取得共識、R10 等待合併改用pr-watch.sh輪詢、R1 每完成一個任務就寫一筆工作日誌。R3 的分支階梯則反映在參考文件上，改成指標式，指回jsc-meta的準則正本。本 PR 併入 6 個 commit，來自已合併的子功能 PR plugins/sdlc#29。
變更內容
tools/wp-gate.shclaim（領包當下登錄歸屬）與owns（比對這支 PR 是不是自己這一包的）兩個子指令，把工作包歸屬併進閘門。R4 原本只寫在技能內文裡靠模型自律，換一個工作階段就消失skills/implement/SKILL.mdpr-watch.sh盯場、抓到留言先跑決策樹取得共識再修、每完成一個任務就寫一筆日誌skills/maintain/SKILL.mdreferences/branch.mdjsc-meta/references/guidelines.md的「PR 分支階梯」。同一份規則抄兩地，遲早只有一邊被更新references/stage-report.mdREADME.mdplugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json0.1.9設計重點
claim在領包當下就登錄，此時還沒有 PR，PR 欄留空，等lock再補。jsc-hooks的sdlc-gate.sh寫、本存取庫的wp-gate.sh只讀。分工單向：hook 那半不打網路，只注入提醒並擋掉別的階段技能；wp-gate.sh是唯一會去問 Gitea 的一方，也是唯一有權解鎖的一方。兩邊都能改狀態的話，鎖為什麼不見了就沒有人說得清。check-deps活抓分析頁 WBS 表的相依欄逐一核對，不吃 implement 技能自己讀到的任何快取或判斷。相依欄指到別份計畫或別頁分析的文字項目查不了，照樣放行但會列出來要求人工確認。pr-watch.sh只負責偵測與回報，退出碼10就停下來交給jsc-ask:ask取得共識，共識到手才 commit、push。留言修正這一段必須以 sub agent 執行（Q8），否則主 agent 的上下文會被留言細節塞滿。LOG_{HASH}（Q6），耗時與 token 用量可以逐輪回溯。jsc-gitea/tools/pr-watch.sh，本存取庫只呼叫、不重寫一份。測試結果
sh -n tools/wp-gate.sh通過。jsc-meta/tools/ste100-lint.sh掃整個存取庫全綠。jsc-sdlc:implement，由後續的工作包驗收。前置 Push Request
jsc-gitea的tools/pr-watch.sh、gitea.sh pr-get與pr-edit，工作包歸屬狀態檔則由jsc-hooks的sdlc-gate.sh產生。這些依賴已分別隨 plugins/gitea#22 與 plugins/hooks#30 合併進各自的功能主幹，沒有未結清的前置 PR，不需要掛gitea.sh pr-depend。What：`tools/wp-gate.sh` 新增 `claim {owner}/{repo} {wp-number} [--analyze {分析頁頁名}]` 登錄領取、`owns {owner}/{repo} {index} [--wp {wp-number}]` 比對某支 PR 是不是自己這一包的；`lock` 新增 `--wp` 把 PR 掛到工作包名下；`check` 判定已合併時一併交回領取紀錄。新增狀態 `claimed`、`owned`、`foreign`、`unowned`，`foreign` 回 `1`，`owned` 與 `unowned` 回 `0`。 Why：同一份分析常有好幾包平行進行，每包各自的 worktree 與 PR。動任何一支 PR 之前要先確認它是自己這一包的，靠的必須是狀態檔而不是記憶——記憶跨不了工作階段。 How：歸屬一律以分析頁的工作包代號為準，不看分支名、不看 worktree 目錄名，那兩個都可能被改，改了也沒有徵兆。`WP-03`、`WP-3`、`3` 比對前先正規化成 `WP-03`，不然同一包的兩種寫法會被當成兩包。狀態檔的寫入一律轉呼叫 `jsc-hooks` 的 `sdlc-gate.sh`，本檔只讀不寫：兩邊各拼各的檔案，格式一改就對不上。查無歸屬（沒有領取紀錄、工作包還沒掛上 PR）一律 `unowned` 並放行只提醒，這與「查不到就擋」不衝突——那條講的是查得到卻查失敗，這條講的是根本還沒有歸屬可查。擋人時要講得出對方是誰，所以 `foreign` 會指出那支 PR 掛在哪一包名下。合併後交回領取紀錄前先確認領取檔登記的正是這一包，中途改領別包時直接交回會把還在進行的那一包的歸屬清掉。 Who：`jsc-sdlc:implement` 領包、開 PR 與處理留言的每一步，以及跨工作階段接手同一份分析的人。What：`implement` 步驟 4 的留言處理拆細：動手前先跑 `wp-gate.sh owns` 確認 PR 是自己這一包的，接著走 `jsc-ask:ask` 決策樹對每一則留言取得共識才修，一輪修完立刻寫一筆工作日誌。步驟 6 領到包就跑 `wp-gate.sh claim`，步驟 11 的 `lock` 帶 `--wp`，開完 PR 先寫日誌再用 `jsc-gitea/tools/pr-watch.sh` 盯到合併，並依退出碼 `0`、`10`、`3`、`2` 分四條路走。Rules 新增「一個任務一筆日誌」一條，步驟 14 的日誌參數改為指向步驟 11 寫的那一筆。 Why：三件事原本都靠模型自己記。留言直接開修，等於把審查者的一句話自行解讀成一種改法，猜錯就多一輪審查；別包的 PR 沒人擋，跨工作階段就會互相踩；日誌等到階段結束才補一次，那時花費時間、token 用量與困難都已經散掉了。 How：留言文本留在 sub agent 裡，主代理只留決策與帳務。`pr-watch.sh` 收到 `10` 就回頭跑同一套留言流程（歸屬、共識、sub agent 修正、逐則結果、時間戳、日誌），跑完再盯一次，審查者要幾輪就幾輪；收到 `0` 再用 `wp-gate.sh check` 分辨已合併與被關掉沒合併，後者回報後停下，不算完成。時間戳一律寫回分析頁**既有**的 PR 欄，不加新欄，分析頁的欄位屬於 `analyze`。日誌一律附加到同一頁 `LOG_{HASH}`，`--pending-file` 暫存的內容併進同一次寫入，寫成功才清除——暫存不等於已寫入。 Who：跑 SDLC 實作階段的每個工作階段，以及接手同一份分析的下一個人。What：`maintain` 步驟 3 新增 3.5「一個專案的維護就是一個完成的任務」，PR 一開好就呼叫 `jsc-log:worklog` 寫一筆，原 3.5 順延為 3.6；步驟 5 的階段回報改成指向 3.5 寫的那幾筆，`--pending-file` 降級為「一個任務都沒完成就停下」時的備援。 Why：維護階段一次跑好幾個專案，原本整個階段結束才補一筆日誌。等到那時候，每個專案各自花掉多少時間、遇到什麼困難都已經混在一起，補出來的是一段概述而不是紀錄。 How：一個專案一筆，下一個專案的 sub agent 開工前要先寫完。條目一律附加到同一頁 `LOG_{HASH}`，`stage-report.sh --pending-file` 暫存的內容併進同一次寫入，寫成功才清除；暫存過的內容不算已寫入的日誌。 Who：跑 SDLC 維護階段的人，以及事後查某個專案上次維護做了什麼的人。