plugins/meta
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(meta): 技能準則新增 PR 分支階梯與盯場輪詢間隔 #23

Merged
jiantw83 merged 3 commits from feat/sdlc-flow-rules/main into develop 2026-08-27 03:39:39 +00:00
Conversation 0 Commits 3 Files Changed 4
+21 -3
jiantw83 commented 2026-08-27 03:38:55 +00:00
Member
Copy Link
Copy Source

PR 描述

摘要

  • 需求描述：把功能主幹 feat/sdlc-flow-rules/main 累積的內容整批推上 develop。本存取庫是技能準則的正本，負責使用者 15 條規則第一群「SDLC 執行流程」裡 R3 的成文化：PR 一律照分支階梯逐級上推，禁止越級。階梯先前只散在各技能的內文裡，沒有一份共同依據，於是同一件事在不同 domain 有不同寫法。這裡把階梯寫成準則的一節，同時把新的環境變數登進變數表、把「base 有沒有越級」加進審核清單。
  • 計畫名稱：無
  • 計畫頁：無
  • 分析頁：無

本 PR 併入 3 個 commit，來自已合併的子功能 PR plugins/meta#22。

變更內容

檔案 為什麼改
references/guidelines.md 新增「PR 分支階梯」一節（含兩張階梯表與六條規則）；環境變數表補上 JSC_PR_WATCH_INTERVAL；審核清單加一項「PR 的 base 符合分支階梯，沒有越級」。準則是各 domain 共同的依據，規則不寫在這裡就等於沒有規則
plugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json 三份 manifest 版本同步升到 0.1.3

設計重點

  • 階梯分兩種走法。feat、docs、style、refactor、perf、test、chore、revert 走 {類型}/{子功能} → {類型}/{功能}/main → develop → master；fix 只走 fix/{修改} → develop → master。修 bug 通常是單點，硬要它先開一條功能主幹只是多繞一圈。
  • {子功能} 可以多層，寫成 {功能}/{子功能}/{再下一層}，推導一律「去掉最後一段後接 /main」。層數不設限，規則本身不必因為巢狀變深而改寫。
  • base 一律由 jsc-git/tools/base-branch.sh --derive 推導，不靠人記。推不出唯一合法基底就中止並詢問使用者，不猜、也不退回 develop——退回 develop 就是預設允許越級，跟這條規則的目的正好相反。
  • 功能主幹 {類型}/{功能}/main 不在 origin 上時，自動從 develop 建立並推上去，收尾要回報建立了哪一條分支。決策紀錄見 wiki QUESTION_FB8DF0B5 的 2026-08-27 那一節 Q3。停下來問的話，每個新功能都要多一輪問答。
  • 階梯最後一級寫成明文不能省：develop 併進 master 才會生效，marketplace 與 version-guard.sh 都讀存取庫的預設分支。少了這一級，改動看起來合併了，實際上沒有人拿得到。
  • 中文簡述先交給 jsc-git/tools/slugify.sh 轉成 ASCII slug 再組分支名，銜接既有的「分支名只允許 ASCII」那一條，不另立新規則。
  • 審核清單多的那一項讓 jsc-meta:skill-check 這類例行稽核查得到越級，規則才不會只停在文件上。

測試結果

  • 子功能 PR plugins/meta#22 已完成該層的驗證並合併，本 PR 不再重跑一次。
  • 主幹整合後複驗：tools/ste100-lint.sh 掃整個存取庫全綠，另外也對其餘六個 domain 各掃一次，全數全綠。
  • 本 PR 只動文件與 manifest，沒有可執行的程式碼變更，因此沒有另外的單元測試。

前置 Push Request

  • 無
# PR 描述 ## 摘要 - 需求描述：把功能主幹 `feat/sdlc-flow-rules/main` 累積的內容整批推上 `develop`。本存取庫是技能準則的正本，負責使用者 15 條規則第一群「SDLC 執行流程」裡 R3 的成文化：PR 一律照分支階梯逐級上推，禁止越級。階梯先前只散在各技能的內文裡，沒有一份共同依據，於是同一件事在不同 domain 有不同寫法。這裡把階梯寫成準則的一節，同時把新的環境變數登進變數表、把「base 有沒有越級」加進審核清單。 - 計畫名稱：無 - 計畫頁：無 - 分析頁：無 本 PR 併入 3 個 commit，來自已合併的子功能 PR [plugins/meta#22](https://gitea.jsc.idv.tw/plugins/meta/pulls/22)。 ## 變更內容 | 檔案 | 為什麼改 | | --- | --- | | `references/guidelines.md` | 新增「PR 分支階梯」一節（含兩張階梯表與六條規則）；環境變數表補上 `JSC_PR_WATCH_INTERVAL`；審核清單加一項「PR 的 base 符合分支階梯，沒有越級」。準則是各 domain 共同的依據，規則不寫在這裡就等於沒有規則 | | `plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json` | 三份 manifest 版本同步升到 `0.1.3` | ## 設計重點 - 階梯分兩種走法。`feat`、`docs`、`style`、`refactor`、`perf`、`test`、`chore`、`revert` 走 `{類型}/{子功能}` → `{類型}/{功能}/main` → `develop` → `master`；`fix` 只走 `fix/{修改}` → `develop` → `master`。修 bug 通常是單點，硬要它先開一條功能主幹只是多繞一圈。 - `{子功能}` 可以多層，寫成 `{功能}/{子功能}/{再下一層}`，推導一律「去掉最後一段後接 `/main`」。層數不設限，規則本身不必因為巢狀變深而改寫。 - base **一律由 `jsc-git/tools/base-branch.sh --derive` 推導**，不靠人記。推不出唯一合法基底就中止並詢問使用者，不猜、也不退回 `develop`——退回 `develop` 就是預設允許越級，跟這條規則的目的正好相反。 - 功能主幹 `{類型}/{功能}/main` 不在 origin 上時，**自動從 `develop` 建立並推上去**，收尾要回報建立了哪一條分支。決策紀錄見 wiki [QUESTION_FB8DF0B5](https://gitea.jsc.idv.tw/knowledges/QUESTION/wiki/QUESTION_FB8DF0B5) 的 2026-08-27 那一節 Q3。停下來問的話，每個新功能都要多一輪問答。 - 階梯最後一級寫成明文不能省：`develop` 併進 `master` 才會生效，marketplace 與 `version-guard.sh` 都讀存取庫的**預設分支**。少了這一級，改動看起來合併了，實際上沒有人拿得到。 - 中文簡述先交給 `jsc-git/tools/slugify.sh` 轉成 ASCII slug 再組分支名，銜接既有的「分支名只允許 ASCII」那一條，不另立新規則。 - 審核清單多的那一項讓 `jsc-meta:skill-check` 這類例行稽核查得到越級，規則才不會只停在文件上。 ## 測試結果 - 子功能 PR [plugins/meta#22](https://gitea.jsc.idv.tw/plugins/meta/pulls/22) 已完成該層的驗證並合併，本 PR 不再重跑一次。 - 主幹整合後複驗：`tools/ste100-lint.sh` 掃整個存取庫全綠，另外也對其餘六個 domain 各掃一次，全數全綠。 - 本 PR 只動文件與 manifest，沒有可執行的程式碼變更，因此沒有另外的單元測試。 ## 前置 Push Request - 無
jiantw83 added 3 commits 2026-08-27 03:38:55 +00:00
docs(guidelines): 準則新增 PR 分支階梯與盯場輪詢間隔 769d8f3f33 
What：`references/guidelines.md` 新增「PR 分支階梯」一節，列出兩種型別的階梯、多層子功能的組法、base 一律由 `jsc-git/tools/base-branch.sh --derive` 推導、功能主幹自動建立，以及最後一級不能省；環境變數表補上 `JSC_PR_WATCH_INTERVAL`；稽核檢查清單新增一項「PR 的 base 符合 PR 分支階梯，沒有越級」。

Why：階梯要對所有存取庫成立，就必須有一份正本。放在技能準則裡，各 domain 的 README 與參考文件才能只寫摘要並指回來，不會養出好幾份互相打架的規則；稽核清單少了這一項，越級開的 PR 也沒有任何一關會發現。

How：階梯只寫表與六條說明，不寫實作細節，推導行為的正本仍在 `jsc-git/tools/base-branch.sh`。特別寫明第 4 條「推不出唯一合法基底就中止並詢問使用者，不猜，也不退回 `develop`」與第 6 條「`develop` 併進 `master` 才會生效」——marketplace 與 `version-guard.sh` 讀的都是存取庫的預設分支，階梯最後一級省掉就等於沒有發布。

Who：所有 jsc domain 存取庫的 PR，以及跑 `jsc-meta:skill-check` 稽核的人。
chore(manifest): 三份 manifest 版本升到 0.1.3 02b36a315c 
What：`plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json` 的 `version` 由 0.1.2 改為 0.1.3。

Why：技能準則新增了一節規則與一項稽核檢查，準則有異動就要 bump 版本，安裝端才拿得到新版。

How：三份只改 `version` 一個欄位，其餘內容不動，三份保持同一版號。

Who：`jsc-meta` 外掛的套件描述檔。
Merge pull request 'docs(meta): 技能準則新增 PR 分支階梯與盯場輪詢間隔' (#22) from feat/sdlc-flow-rules/pr-ladder-guideline into feat/sdlc-flow-rules/main 07d8583937 
Reviewed-on: #22
jiantw83 merged commit 47c479d65c into develop 2026-08-27 03:39:39 +00:00
jiantw83 deleted branch feat/sdlc-flow-rules/main 2026-08-27 03:39:39 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
admin (系統管理員) jiantw83 (Jeffery)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: plugins/meta#23