develop
master
jsc-sdlc
tools/wp-gate.sh
claim
owns
implement
maintain
references/branch.md
jsc-hooks
sdlc-gate.sh wp-claim
sdlc-gate.sh
skills/implement/SKILL.md
jsc-ask:ask
lock
--wp
jsc-gitea/tools/pr-watch.sh
skills/maintain/SKILL.md
description
jsc-meta
references/guidelines.md
references/stage-report.md
README.md
plugin.json
.claude-plugin/plugin.json
.codex-plugin/plugin.json
jsc-hooks/hooks/version-guard.sh
version-guard.sh
wp-gate.sh claim
wp-gate.sh lock
wp-gate.sh owns
status=foreign
pr-watch.sh
wp-gate.sh
jsc-git
jsc-git/tools/base-branch.sh --derive
JSC_WP_GATE=off
LOG_{HASH}
git log --oneline origin/master..origin/develop
plugins/sdlc#30
#29
git diff --stat origin/master origin/develop
plugins/sdlc#29
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 維護階段的人,以及事後查某個專案上次維護做了什麼的人。
What:`references/branch.md` 新增「分支階梯與 base 推導」一節(只寫拿到 `jsc-git/tools/base-branch.sh --derive` 回應之後要做什麼)與「工作包隔離」一節(歸屬依據、狀態檔欄位、誰寫誰讀、查無歸屬放行、逃生門),閘門分工那一表補上 `claim`、`lock`、`owns`。`references/stage-report.md` 改寫暫存那一節,講明本節只適用於「還沒完成任何任務就停下」的階段。README 的工具表、`implement` 與 `maintain` 兩段說明、參考文件表與相依技能清單同步更新。 Why:階梯表與歸屬狀態檔的正本各有其處——階梯在 `jsc-meta` 的 `references/guidelines.md`,狀態檔格式在 `jsc-hooks`。抄第二份就會有兩份互相打架的規則,但完全不提又會讓實作階段不知道拿到 `7` 或「已建立功能主幹」時該做什麼。 How:兩節都只寫本階段要做的事,並把唯一來源用連結指出去。`branch.md` 的階梯那一節寫成一張「腳本回應 → 這個階段要做的事」對照表,`7` 明寫成「中止並問使用者,不退回 `develop`」。`stage-report.md` 補一句「暫存不等於已寫入」,因為日誌改成一個任務一筆之後,做完事情的階段本來就有日誌可連。 Who:讀 `jsc-sdlc` 參考文件與 README 的人,以及跑實作與維護兩階段的工作階段。
What:`plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json` 的 `version` 由 0.1.8 改為 0.1.9。 Why:本次為 `wp-gate.sh` 新增兩個子命令,並改了 `implement` 與 `maintain` 兩支技能的步驟,屬於行為變更,版本要跟著往上走,各 CLI 才知道要更新。 How:三份只改 `version` 一個欄位,其餘內容不動,三份保持同一版號。 Who:`jsc-sdlc` 外掛的套件描述檔。
Reviewed-on: #29
No dependencies set.
The note is not visible to the blocked user.
摘要
jsc-sdlc0.1.9 從develop放行到master。內容是使用者 15 條規則第一群「SDLC 執行流程」六條在本存取庫的落實:tools/wp-gate.sh新增claim與owns,implement步驟 4 與步驟 11 改寫(歸屬比對、留言先取共識、盯 PR 到合併、每個任務一筆日誌),maintain加上日誌步驟,references/branch.md改成指標式、不再抄第二份階梯規則。變更內容
tools/wp-gate.shclaim(領包當下登錄歸屬,轉呼叫jsc-hooks的sdlc-gate.sh wp-claim)與owns(拿領取紀錄與鎖檔比對某支 PR 是不是自己這一包的)。狀態檔一律只讀不寫,寫入全部轉呼叫sdlc-gate.sh——兩邊各拼各的檔案格式,一改就對不上,而且誰寫壞了看不出來。skills/implement/SKILL.mdowns;留言先過jsc-ask:ask決策樹取得共識才修,不再自動修(同一句評語常允許兩種修法,靜靜挑一種就多賠一輪審查);每一輪留言修正結束就寫一筆工作日誌。步驟 6 領包時多跑一次claim。步驟 11 改寫:lock帶上--wp把 PR 掛到工作包名下,PR 開好先寫日誌,再用jsc-gitea/tools/pr-watch.sh盯到合併,並依退出碼 0、10、3、2 分四條路走。規則區新增「一個任務一筆工作日誌」。skills/maintain/SKILL.mddescription同步。references/branch.mdjsc-meta的references/guidelines.md,不抄第二份。新增「工作包隔離」一節,講清楚歸屬依據、狀態檔、誰寫誰讀、查無歸屬放行只提醒,以及逃生門。三層閘門表同步補上claim與owns。references/stage-report.mdREADME.mdplugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json設計重點
jsc-hooks/hooks/version-guard.sh都讀存取庫的預設分支master——version-guard.sh取 rawplugin.json時刻意不指定 ref,拿到的就是預設分支那一份。內容留在develop上再完整,已經安裝的 CLI 一律抓不到,版本檢查也照舊回報舊版本。階梯的前三級都已走完,這是最後一級,也是唯一會讓使用者端真的拿到新內容的一級。wp-gate.sh claim,把工作包代號登錄成歸屬;一個存取庫同時只持有一個領取。wp-gate.sh lock改帶--wp,把 PR 掛在該工作包名下;漏帶就等於誰都能動這支 PR。wp-gate.sh owns:status=foreign就放手,並指出是哪一包持有它。pr-watch.sh盯到合併:回 10 就把新留言接回步驟 4 那一輪流程,處理完重新盯。references/branch.md對階梯改成指標式,規則的唯一來源集中在jsc-meta。wp-gate.sh與sdlc-gate.sh之後,狀態檔不綁 session,開新對話照樣擋。jsc-git0.0.8):越級的 PR 會被擋下來。base 一律由jsc-git/tools/base-branch.sh --derive推導;退出碼 7 就中止並問使用者,不退回develop——退回develop就是讓子功能越級直接進主線。owns回status=foreign),查無歸屬才放行只提醒。實作階段開完 PR 之後會停在pr-watch.sh上等合併,不再順手開下一包。JSC_WP_GATE=off,設了就整體放行工作包閘門。LOG_{HASH}上就是六筆,各自帶自己的耗時與 token 數。測試結果
git log --oneline origin/master..origin/develop:7 個 commit,最上面是已合併的plugins/sdlc#30,其下是#29與五個實作提交,沒有夾帶別批的內容。git diff --stat origin/master origin/develop:9 個檔案、269 行新增、34 行刪除,與上表逐項對得上,沒有預期外的檔案。plugins/sdlc#29、plugins/sdlc#30完全相同。wp-gate.sh的claim與owns的測試在那兩支 PR 已經跑過,這支 PR 沒有重跑。claim、owns與jsc-hooks0.2.3 的狀態檔格式綁在一起,兩邊要一起放行才對得上;本批七個存取庫是同一批放行。前置 Push Request
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 維護階段的人,以及事後查某個專案上次維護做了什麼的人。