release: v0.1.9 develop 到 master #31

Merged
admin merged 7 commits from develop into master 2026-08-27 04:15:00 +00:00
Member

摘要

  • 需求描述:把 jsc-sdlc 0.1.9 從 develop 放行到 master。內容是使用者 15 條規則第一群「SDLC 執行流程」六條在本存取庫的落實:tools/wp-gate.sh 新增 claim 與 owns,implement 步驟 4 與步驟 11 改寫(歸屬比對、留言先取共識、盯 PR 到合併、每個任務一筆日誌),maintain 加上日誌步驟,references/branch.md 改成指標式、不再抄第二份階梯規則。
  • 計畫名稱:無
  • 計畫頁:無
  • 分析頁:無

變更內容

檔案 為什麼改
tools/wp-gate.sh 新增 claim(領包當下登錄歸屬,轉呼叫 jsc-hooks 的 sdlc-gate.sh wp-claim)與 owns(拿領取紀錄與鎖檔比對某支 PR 是不是自己這一包的)。狀態檔一律只讀不寫,寫入全部轉呼叫 sdlc-gate.sh——兩邊各拼各的檔案格式,一改就對不上,而且誰寫壞了看不出來。
skills/implement/SKILL.md 步驟 4 改寫:動別人的 PR 之前先跑 owns;留言先過 jsc-ask:ask 決策樹取得共識才修,不再自動修(同一句評語常允許兩種修法,靜靜挑一種就多賠一輪審查);每一輪留言修正結束就寫一筆工作日誌。步驟 6 領包時多跑一次 claim。步驟 11 改寫:lock 帶上 --wp 把 PR 掛到工作包名下,PR 開好先寫日誌,再用 jsc-gitea/tools/pr-watch.sh 盯到合併,並依退出碼 0、10、3、2 分四條路走。規則區新增「一個任務一筆工作日誌」。
skills/maintain/SKILL.md 每個專案開完 PR 就寫一筆工作日誌,description 同步。
references/branch.md 新增「分支階梯與 base 推導」一節,但只寫拿到腳本回應之後要做什麼,階梯表本身指回 jsc-meta 的 references/guidelines.md,不抄第二份。新增「工作包隔離」一節,講清楚歸屬依據、狀態檔、誰寫誰讀、查無歸屬放行只提醒,以及逃生門。三層閘門表同步補上 claim 與 owns。
references/stage-report.md 「沒寫工作日誌就暫存」改成只涵蓋「還沒完成任何任務就停下」的階段,並點明暫存不等於已寫入。
README.md 同步階梯、工作包隔離與日誌粒度。
plugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json 三份 manifest 版本同步升到 0.1.9。

設計重點

  • 這一段才會讓已安裝的 CLI 抓到新內容。 marketplace 與 jsc-hooks/hooks/version-guard.sh 都讀存取庫的預設分支 master——version-guard.sh 取 raw plugin.json 時刻意不指定 ref,拿到的就是預設分支那一份。內容留在 develop 上再完整,已經安裝的 CLI 一律抓不到,版本檢查也照舊回報舊版本。階梯的前三級都已走完,這是最後一級,也是唯一會讓使用者端真的拿到新內容的一級。
  • 行為變更清單。
    1. 領包時多一步 wp-gate.sh claim,把工作包代號登錄成歸屬;一個存取庫同時只持有一個領取。
    2. wp-gate.sh lock 改帶 --wp,把 PR 掛在該工作包名下;漏帶就等於誰都能動這支 PR。
    3. 動任何一支 PR 之前先跑 wp-gate.sh owns:status=foreign 就放手,並指出是哪一包持有它。
    4. PR 留言先取得共識才修,一則留言一組選項,每個選項要講清楚影響範圍。
    5. 開完 PR 不再直接停下,改用 pr-watch.sh 盯到合併:回 10 就把新留言接回步驟 4 那一輪流程,處理完重新盯。
    6. 每完成一個任務就寫一筆工作日誌,任務有三種:一個工作包、一輪 PR 留言修正、一個獨立的修正提交。
    7. references/branch.md 對階梯改成指標式,規則的唯一來源集中在 jsc-meta。
  • 為什麼判定要搬到程式層。 這些規則原本只寫在技能內文裡,靠模型自律遵守。內文靠不住——換一個工作階段、換一個模型,或只是上下文被截掉,規則就跟著消失,而且沒有任何徵兆看得出來。搬到 wp-gate.sh 與 sdlc-gate.sh 之後,狀態檔不綁 session,開新對話照樣擋。
  • 升級後使用者會立刻感受到的差異。
    • R3 分支階梯(jsc-git 0.0.8):越級的 PR 會被擋下來。base 一律由 jsc-git/tools/base-branch.sh --derive 推導;退出碼 7 就中止並問使用者,不退回 develop——退回 develop 就是讓子功能越級直接進主線。
    • R4 工作包隔離:不是自己領的那一包的 PR 會被擋(owns 回 status=foreign),查無歸屬才放行只提醒。實作階段開完 PR 之後會停在 pr-watch.sh 上等合併,不再順手開下一包。
    • 逃生門是 JSC_WP_GATE=off,設了就整體放行工作包閘門。
    • 工作日誌變密:一個工作包加五輪留言修正,LOG_{HASH} 上就是六筆,各自帶自己的耗時與 token 數。
  • 相關紀錄:工作日誌在 https://gitea.jsc.idv.tw/knowledges/LOG/wiki/LOG_FB8DF0B5,決策紀錄在 https://gitea.jsc.idv.tw/knowledges/QUESTION/wiki/QUESTION_FB8DF0B5 的 2026-08-27 一節。

測試結果

  • 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-hooks 0.2.3 的狀態檔格式綁在一起,兩邊要一起放行才對得上;本批七個存取庫是同一批放行。

前置 Push Request

  • 無
## 摘要 - 需求描述:把 `jsc-sdlc` 0.1.9 從 `develop` 放行到 `master`。內容是使用者 15 條規則第一群「SDLC 執行流程」六條在本存取庫的落實:`tools/wp-gate.sh` 新增 `claim` 與 `owns`,`implement` 步驟 4 與步驟 11 改寫(歸屬比對、留言先取共識、盯 PR 到合併、每個任務一筆日誌),`maintain` 加上日誌步驟,`references/branch.md` 改成指標式、不再抄第二份階梯規則。 - 計畫名稱:無 - 計畫頁:無 - 分析頁:無 ## 變更內容 | 檔案 | 為什麼改 | | --- | --- | | `tools/wp-gate.sh` | 新增 `claim`(領包當下登錄歸屬,轉呼叫 `jsc-hooks` 的 `sdlc-gate.sh wp-claim`)與 `owns`(拿領取紀錄與鎖檔比對某支 PR 是不是自己這一包的)。狀態檔一律只讀不寫,寫入全部轉呼叫 `sdlc-gate.sh`——兩邊各拼各的檔案格式,一改就對不上,而且誰寫壞了看不出來。 | | `skills/implement/SKILL.md` | 步驟 4 改寫:動別人的 PR 之前先跑 `owns`;留言先過 `jsc-ask:ask` 決策樹取得共識才修,不再自動修(同一句評語常允許兩種修法,靜靜挑一種就多賠一輪審查);每一輪留言修正結束就寫一筆工作日誌。步驟 6 領包時多跑一次 `claim`。步驟 11 改寫:`lock` 帶上 `--wp` 把 PR 掛到工作包名下,PR 開好先寫日誌,再用 `jsc-gitea/tools/pr-watch.sh` 盯到合併,並依退出碼 0、10、3、2 分四條路走。規則區新增「一個任務一筆工作日誌」。 | | `skills/maintain/SKILL.md` | 每個專案開完 PR 就寫一筆工作日誌,`description` 同步。 | | `references/branch.md` | 新增「分支階梯與 base 推導」一節,但**只寫拿到腳本回應之後要做什麼**,階梯表本身指回 `jsc-meta` 的 `references/guidelines.md`,不抄第二份。新增「工作包隔離」一節,講清楚歸屬依據、狀態檔、誰寫誰讀、查無歸屬放行只提醒,以及逃生門。三層閘門表同步補上 `claim` 與 `owns`。 | | `references/stage-report.md` | 「沒寫工作日誌就暫存」改成只涵蓋「還沒完成任何任務就停下」的階段,並點明暫存不等於已寫入。 | | `README.md` | 同步階梯、工作包隔離與日誌粒度。 | | `plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json` | 三份 manifest 版本同步升到 0.1.9。 | ## 設計重點 - **這一段才會讓已安裝的 CLI 抓到新內容。** marketplace 與 `jsc-hooks/hooks/version-guard.sh` 都讀存取庫的**預設分支** `master`——`version-guard.sh` 取 raw `plugin.json` 時刻意不指定 ref,拿到的就是預設分支那一份。內容留在 `develop` 上再完整,已經安裝的 CLI 一律抓不到,版本檢查也照舊回報舊版本。階梯的前三級都已走完,這是最後一級,也是唯一會讓使用者端真的拿到新內容的一級。 - **行為變更清單。** 1. 領包時多一步 `wp-gate.sh claim`,把工作包代號登錄成歸屬;一個存取庫同時只持有一個領取。 2. `wp-gate.sh lock` 改帶 `--wp`,把 PR 掛在該工作包名下;漏帶就等於誰都能動這支 PR。 3. 動任何一支 PR 之前先跑 `wp-gate.sh owns`:`status=foreign` 就放手,並指出是哪一包持有它。 4. PR 留言**先取得共識才修**,一則留言一組選項,每個選項要講清楚影響範圍。 5. 開完 PR 不再直接停下,改用 `pr-watch.sh` 盯到合併:回 10 就把新留言接回步驟 4 那一輪流程,處理完重新盯。 6. 每完成一個任務就寫一筆工作日誌,任務有三種:一個工作包、一輪 PR 留言修正、一個獨立的修正提交。 7. `references/branch.md` 對階梯改成指標式,規則的唯一來源集中在 `jsc-meta`。 - **為什麼判定要搬到程式層。** 這些規則原本只寫在技能內文裡,靠模型自律遵守。內文靠不住——換一個工作階段、換一個模型,或只是上下文被截掉,規則就跟著消失,而且沒有任何徵兆看得出來。搬到 `wp-gate.sh` 與 `sdlc-gate.sh` 之後,狀態檔不綁 session,開新對話照樣擋。 - **升級後使用者會立刻感受到的差異。** - R3 分支階梯(`jsc-git` 0.0.8):**越級的 PR 會被擋下來**。base 一律由 `jsc-git/tools/base-branch.sh --derive` 推導;退出碼 7 就中止並問使用者,不退回 `develop`——退回 `develop` 就是讓子功能越級直接進主線。 - R4 工作包隔離:**不是自己領的那一包的 PR 會被擋**(`owns` 回 `status=foreign`),查無歸屬才放行只提醒。實作階段開完 PR 之後會停在 `pr-watch.sh` 上等合併,不再順手開下一包。 - 逃生門是 `JSC_WP_GATE=off`,設了就整體放行工作包閘門。 - 工作日誌變密:一個工作包加五輪留言修正,`LOG_{HASH}` 上就是六筆,各自帶自己的耗時與 token 數。 - 相關紀錄:工作日誌在 <https://gitea.jsc.idv.tw/knowledges/LOG/wiki/LOG_FB8DF0B5>,決策紀錄在 <https://gitea.jsc.idv.tw/knowledges/QUESTION/wiki/QUESTION_FB8DF0B5> 的 2026-08-27 一節。 ## 測試結果 - `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-hooks` 0.2.3 的狀態檔格式綁在一起,兩邊要一起放行才對得上;本批七個存取庫是同一批放行。 ## 前置 Push Request - 無
jiantw83 added 7 commits 2026-08-27 04:00:49 +00:00
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
admin approved these changes 2026-08-27 04:14:56 +00:00
admin merged commit dfef4949fd into master 2026-08-27 04:15:00 +00:00
Sign in to join this conversation.
No Reviewers
No labels
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: plugins/sdlc#31