release: v0.0.8 develop 到 master #13
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: plugins/git#13
Reference in New Issue
Block a user
摘要
jsc-git0.0.8 從develop放行到master。內容是使用者 15 條規則第一群「SDLC 執行流程」六條在本存取庫的落實：tools/base-branch.sh新增--derive階梯推導與功能主幹自動建立，pr技能改成先組階梯形狀的分支名再推導 base，並對既有 PR 改採三項校準而不重開，commit技能補上校準的觸發點。變更內容
tools/base-branch.sh--derive模式：從分支名推出唯一合法的上一階基底，禁止越級。feat、docs、style、refactor、perf、test、chore、revert走{類型}/{功能}/{子功能}→{類型}/{功能}/main→develop→master，fix走fix/{修改}→develop→master。功能主幹不在 origin 時自動從origin/develop建立並推上去，再把建了哪一條印到 stderr。新增退出碼 7（推不出唯一合法基底）、8（推導出的基底不在遠端又不能自動建立）、9（自動建立功能主幹失敗）。skills/pr/SKILL.mdslugify.sh依類型呼叫一次或兩次），再推導 base。呼叫端有傳 base 時兩邊都算一次，算出來不一樣就代表越級，停下來問使用者，不再靜靜改指目標。新增步驟 6 查目標分支有沒有既有的開啟中 PR，有就跳到步驟 9 校準標題、描述、前置 PR 依賴三項，只送出有差異那幾項的 API 呼叫。skills/commit/SKILL.mdjsc-git:pr步驟 9 做同樣的三項校準。規則第 3 條同步收緊為「不 push、也不建立 PR」，把校準與建立分清楚。README.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 一律抓不到，版本檢查也照舊回報舊版本。階梯的前三級都已走完，這是最後一級，也是唯一會讓使用者端真的拿到新內容的一級。這一批本身就是把階梯寫進程式，最後一級更不能自己省掉。base-branch.sh --derive推導；越級推不出唯一合法基底就中止。develop——退回develop就是讓子功能越級直接進主線，正是這支腳本要擋的事。{類型}/{功能}/main不存在時自動建立並推上去，收尾要回報建了哪一條。fix呼叫slugify.sh一次，其他類型呼叫兩次（先出{類型}/{功能}，再把結果當類型餵回去出{類型}/{功能}/{子功能}）。feat/a/b直接對develop開 PR 是可行的，升級後--derive只會給feat/a/main，對不上就停下來問。呼叫端傳進來的 base 與推導結果不一致時同樣停下來，不再靜靜改指目標。jsc-hooks0.2.3、jsc-sdlc0.1.9）：不是自己領的那一包的 PR 會被擋，查無歸屬才放行只提醒。JSC_WP_GATE=off，設了就整體放行工作包閘門。分支階梯沒有逃生門，推不出來一律問使用者。測試結果
git log --oneline origin/master..origin/develop：6 個 commit，最上面是已合併的plugins/git#12，其下是#11與四個實作提交，沒有夾帶別批的內容。git diff --stat origin/master origin/develop：7 個檔案、189 行新增、40 行刪除，與上表逐項對得上，沒有預期外的檔案。plugins/git#11、plugins/git#12完全相同。base-branch.sh的測試在那兩支 PR 已經跑過，這支 PR 沒有重跑。前置 Push Request
What：`tools/base-branch.sh` 新增 `--derive [分支]` 模式，從分支名推出唯一合法的上一階基底。`feat` 這一類走 `{類型}/{功能}/{子功能}` → `{類型}/{功能}/main` → `develop` → `master`，`fix` 走 `fix/{修改}` → `develop` → `master`。新增退出碼 `7`（推不出唯一合法基底）、`8`（推導出的基底不在遠端又不能自動建立）、`9`（自動建立功能主幹失敗）。既有的呼叫方模式一字未改。 Why：PR 階梯禁止越級，但基底原本靠呼叫端自己挑，挑錯就是把一個子功能直接併進 `develop`，中間那層功能主幹整個被跳過。判斷寫進程式，越級就不會發生在「這次剛好沒注意」的時候。 How：`{子功能}` 可以多層，推導一律把最後一段換成 `main`。推不出唯一合法基底就中止並回 `7`，由呼叫端問使用者，不猜、也不退回 `develop`——退回 `develop` 正是這支腳本要擋的那件事。功能主幹不在 origin 時，直接把 `origin/develop` 推成新分支自動補一條，不動本機工作區，再把建立了哪一條分支印到 stderr。分支名只收 ASCII 小寫、數字、連字號與斜線，中文簡述請先過 `tools/slugify.sh`。 Who：`jsc-git:pr` 決定 PR base 的那一步，以及所有經由它開 PR 的技能。What：`pr` 技能新增「PR ladder」一節與階梯形狀的分支命名（`fix` 叫一次 `slugify.sh`，其餘型別叫兩次組出 `{類型}/{功能}/{子功能}`），base 一律由 `base-branch.sh --derive` 推導；新增步驟 6 查目標分支有沒有開啟中的 PR，有就跳到新的步驟 9 比對標題、描述、前置 PR 依賴三項，只有不一樣的那幾項才送 API。`commit` 技能新增步驟 5：認可完成後，目前分支已有 PR 就交給 `pr` 校準。 Why：越級開 PR 與「同一條分支重開第二支 PR」是同一個病灶的兩面——base 與 PR 現況都靠人記。改成先推導、先比對之後，base 由腳本決定，PR 只在真的有差時才更新。 How：呼叫方傳入的 base 仍然照收，但要與推導結果一致；不一致就當成越級擋下，說明正確階梯再問使用者，不會悄悄改目標。校準走 `jsc-gitea` 的 `pr-get` 讀現況、`pr-edit` 一次帶標題與描述、`pr-depend` 補依賴；三項都相同就什麼都不做——每一次多餘的編修都會通知所有審查者，安靜才是對的結果。 Who：`jsc-git:pr` 與 `jsc-git:commit` 兩支技能，以及呼叫它們的 `jsc-sdlc:implement`、`jsc-sdlc:maintain` 與 `jsc-meta` 各技能。