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

release: v0.1.7 develop 到 master #24

Merged
admin merged 7 commits from develop into master 2026-08-27 04:14:50 +00:00
Conversation 1 Commits 7 Files Changed 5
+11 -3
jiantw83 commented 2026-08-27 04:00:48 +00:00
Member
Copy Link
Copy Source

摘要

  • 需求描述：把 jsc-cli 0.1.7 從 develop 放行到 master。主要內容是使用者 15 條規則第一群「SDLC 執行流程」六條在本存取庫的落實：tools/config-spec.tsv 登錄 JSC_PR_WATCH_INTERVAL。本批同時把還沒放行過的 0.1.6 一起帶出去——tools/deploy.sh 的 codex 更新修正，develop 上比 master 多的那一段就包含它。
  • 計畫名稱：無
  • 計畫頁：無
  • 分析頁：無

變更內容

檔案 為什麼改
tools/config-spec.tsv 登錄 JSC_PR_WATCH_INTERVAL：全域環境變數、非必填、預設 60、型別 set、缺值時詢問使用者，說明指向實作 jsc-gitea/tools/pr-watch.sh。設定項一律要在規格表裡有一列，jsc-cli 的設定掃描與 doctor 才查得到。
tools/deploy.sh 0.1.6 那一批的修正，這次一併放行。codex 沒有 plugin update 子指令，而 marketplace upgrade 只重抓 marketplace 快照；jsc 的 marketplace.json 只列各網域的 git URL、不含版本，那份檔案內容不會變，codex 一律回「already up to date」並結束碼 0。已安裝外掛的版本是 plugin add 當下決定的，快取不會被連帶重抓——只跑 marketplace upgrade 的話，指令全部成功而版本一個都沒動，是最難察覺的那種失敗。所以 update 模式改成照樣逐網域跑 plugin add。
plugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json 三份 manifest 版本同步升到 0.1.7（中途經過 0.1.6）。

設計重點

  • 這一段才會讓已安裝的 CLI 抓到新內容。 marketplace 與 jsc-hooks/hooks/version-guard.sh 都讀存取庫的預設分支 master——version-guard.sh 取 raw plugin.json 時刻意不指定 ref，拿到的就是預設分支那一份。內容留在 develop 上再完整，已經安裝的 CLI 一律抓不到，版本檢查也照舊回報舊版本。階梯的前三級都已走完，這是最後一級，也是唯一會讓使用者端真的拿到新內容的一級。這一批放的又正好是部署腳本本身，更需要先進 master。
  • 行為變更清單。
    1. 設定規格表新增一列 JSC_PR_WATCH_INTERVAL，預設 60，控制 jsc-gitea/tools/pr-watch.sh 的輪詢間隔秒數。
    2. jsc-cli:deploy 的 update 模式對 codex 多跑一輪逐網域 plugin add；在此之前 codex 的更新是假成功——指令全綠，版本一個都沒動。
  • 升級後使用者會立刻感受到的差異。
    • codex 使用者：跑 jsc-cli:deploy 更新會真的把七個網域升上去，不再停在舊版本。這一項的價值也剛好說明了本 PR 為什麼要放行——修正待在 develop 上，codex 使用者還是升不動。
    • R3 分支階梯（jsc-git 0.0.8）：越級的 PR 會被擋下來。base 一律由 jsc-git/tools/base-branch.sh --derive 推導，推不出唯一合法基底就中止並問使用者，不退回 develop。
    • R4 工作包隔離（jsc-hooks 0.2.3、jsc-sdlc 0.1.9）：動一支 PR 之前先比對歸屬，不是自己領的那一包就擋，查無歸屬才放行只提醒。逃生門是 JSC_WP_GATE=off。
    • 想調整盯 PR 的節奏就設 JSC_PR_WATCH_INTERVAL，例如 JSC_PR_WATCH_INTERVAL=15 讓輪詢變密。
  • 相關紀錄：工作日誌在 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/cli#23、#22 與 config-spec 提交，其下三個是 0.1.6 那批的 plugins/cli#21 與 codex 更新修正——那一批合併進 develop 之後一直沒放行，這次一併帶出去。沒有夾帶其他批次的內容。
  • git diff --stat origin/master origin/develop：5 個檔案、11 行新增、3 行刪除，與上表逐項對得上，沒有預期外的檔案。
  • 本次放行不含任何新的變更，內容與已合併的 plugins/cli#21、#22、#23 完全相同。deploy.sh 對 codex 的實機驗證在 #21 已經做過，這支 PR 沒有重跑。

前置 Push Request

  • 無
## 摘要 - 需求描述：把 `jsc-cli` 0.1.7 從 `develop` 放行到 `master`。主要內容是使用者 15 條規則第一群「SDLC 執行流程」六條在本存取庫的落實：`tools/config-spec.tsv` 登錄 `JSC_PR_WATCH_INTERVAL`。本批同時把還沒放行過的 0.1.6 一起帶出去——`tools/deploy.sh` 的 codex 更新修正，`develop` 上比 `master` 多的那一段就包含它。 - 計畫名稱：無 - 計畫頁：無 - 分析頁：無 ## 變更內容 | 檔案 | 為什麼改 | | --- | --- | | `tools/config-spec.tsv` | 登錄 `JSC_PR_WATCH_INTERVAL`：全域環境變數、非必填、預設 60、型別 `set`、缺值時詢問使用者，說明指向實作 `jsc-gitea/tools/pr-watch.sh`。設定項一律要在規格表裡有一列，`jsc-cli` 的設定掃描與 `doctor` 才查得到。 | | `tools/deploy.sh` | 0.1.6 那一批的修正，這次一併放行。codex 沒有 `plugin update` 子指令，而 `marketplace upgrade` 只重抓 marketplace 快照；jsc 的 `marketplace.json` 只列各網域的 git URL、不含版本，那份檔案內容不會變，codex 一律回「already up to date」並結束碼 0。已安裝外掛的版本是 `plugin add` 當下決定的，快取不會被連帶重抓——只跑 `marketplace upgrade` 的話，指令全部成功而版本一個都沒動，是最難察覺的那種失敗。所以 `update` 模式改成照樣逐網域跑 `plugin add`。 | | `plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json` | 三份 manifest 版本同步升到 0.1.7（中途經過 0.1.6）。 | ## 設計重點 - **這一段才會讓已安裝的 CLI 抓到新內容。** marketplace 與 `jsc-hooks/hooks/version-guard.sh` 都讀存取庫的**預設分支** `master`——`version-guard.sh` 取 raw `plugin.json` 時刻意不指定 ref，拿到的就是預設分支那一份。內容留在 `develop` 上再完整，已經安裝的 CLI 一律抓不到，版本檢查也照舊回報舊版本。階梯的前三級都已走完，這是最後一級，也是唯一會讓使用者端真的拿到新內容的一級。這一批放的又正好是部署腳本本身，更需要先進 `master`。 - **行為變更清單。** 1. 設定規格表新增一列 `JSC_PR_WATCH_INTERVAL`，預設 60，控制 `jsc-gitea/tools/pr-watch.sh` 的輪詢間隔秒數。 2. `jsc-cli:deploy` 的 `update` 模式對 codex 多跑一輪逐網域 `plugin add`；在此之前 codex 的更新是假成功——指令全綠，版本一個都沒動。 - **升級後使用者會立刻感受到的差異。** - codex 使用者：跑 `jsc-cli:deploy` 更新會真的把七個網域升上去，不再停在舊版本。這一項的價值也剛好說明了本 PR 為什麼要放行——修正待在 `develop` 上，codex 使用者還是升不動。 - R3 分支階梯（`jsc-git` 0.0.8）：**越級的 PR 會被擋下來**。base 一律由 `jsc-git/tools/base-branch.sh --derive` 推導，推不出唯一合法基底就中止並問使用者，不退回 `develop`。 - R4 工作包隔離（`jsc-hooks` 0.2.3、`jsc-sdlc` 0.1.9）：動一支 PR 之前先比對歸屬，**不是自己領的那一包就擋**，查無歸屬才放行只提醒。逃生門是 `JSC_WP_GATE=off`。 - 想調整盯 PR 的節奏就設 `JSC_PR_WATCH_INTERVAL`，例如 `JSC_PR_WATCH_INTERVAL=15` 讓輪詢變密。 - 相關紀錄：工作日誌在 <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/cli#23`、`#22` 與 `config-spec` 提交，其下三個是 0.1.6 那批的 `plugins/cli#21` 與 codex 更新修正——那一批合併進 `develop` 之後一直沒放行，這次一併帶出去。沒有夾帶其他批次的內容。 - `git diff --stat origin/master origin/develop`：5 個檔案、11 行新增、3 行刪除，與上表逐項對得上，沒有預期外的檔案。 - 本次放行不含任何新的變更，內容與已合併的 `plugins/cli#21`、`#22`、`#23` 完全相同。`deploy.sh` 對 codex 的實機驗證在 `#21` 已經做過，**這支 PR 沒有重跑**。 ## 前置 Push Request - 無
jiantw83 added 7 commits 2026-08-27 04:00:48 +00:00
fix(deploy): codex 更新補上逐網域 plugin add 63d4185a40 
What：deploy_codex 的 update 分支在 marketplace upgrade 之後，補上逐網域的
plugin add，與 install 分支一致。

Why：codex 沒有 plugin update 子指令，只有 add、list、marketplace、remove。
marketplace upgrade 只重抓 marketplace 快照，而 jsc 的 marketplace.json 只列各
網域的 git URL、不含版本，內容不會變，codex 一律回「already up to date」並結束碼 0。
已安裝外掛的版本在 plugin add 當下決定，快取不會被連帶重抓。結果是十個網域裡八個
版本完全沒動，指令卻全部成功——只看結束碼會判定成功，是最難察覺的那種失敗。
實機驗證過：更新前 review 是 0.0.2，跑完 marketplace upgrade 仍是 0.0.2。

How：update 分支照 install 的寫法逐網域跑 plugin add。實測 codex 的 add 會就地
升級到快照裡的最新版（review 0.0.2 升到 0.0.5），不需要先 remove。同時在函式上方
寫明這個限制與理由，避免後人再把那一行當成多餘的重複而刪掉。

Who：跨 CLI 技能組批次部署。
fix(manifest): 三份 manifest 版本升到 0.1.6 9a7fbeb229 
What：三份 manifest 由 0.1.5 升到 0.1.6。

Why：codex 更新路徑的修正要能被 version-guard.sh 判定為落後，使用者才會收到更新
提示。不升版的話，帶著壞掉更新路徑的舊版會一直留在各 CLI 上。

How：以 jsc-meta 的 sync-skill-manifest.sh 統一 bump，三份同步成同一個值。

Who：跨 CLI 技能組批次部署。
Merge pull request 'fix/codex-update-plugin-add' (#21) from fix/codex-update-plugin-add into develop 7e6591e644 
Reviewed-on: #21
Reviewed-by: 系統管理員 <1+admin@noreply.localhost>
feat(config-spec): 登錄 JSC_PR_WATCH_INTERVAL 設定項 ffff2152c2 
What：`tools/config-spec.tsv` 新增一列 `JSC_PR_WATCH_INTERVAL`：型別 `env`、全域、非必填、預設 `60`、檢查方式 `set`、缺少時 `ask`，說明寫明它是 `pr-watch.sh` 輪詢 PR 狀態的間隔秒數，實作在 `jsc-gitea/tools/pr-watch.sh`。

Why：設定規格表是 jsc 環境變數的清單正本，`jsc-cli` 的部署與體檢都讀它。新變數沒登錄進來，體檢就看不到它，使用者也無從得知有這個旋鈕可以調。

How：只加一列，排在同為 `jsc-hooks` 系列旋鈕的 `JSC_VERSION_TTL` 之後，欄位順序與既有各列相同；說明點名實作位置，讀表的人才知道去哪裡查行為。

Who：`jsc-cli:deploy` 與環境體檢，以及要調整盯 PR 頻率的使用者。
chore(manifest): 三份 manifest 版本升到 0.1.7 bbd48b5d95 
What：`plugin.json`、`.claude-plugin/plugin.json`、`.codex-plugin/plugin.json` 的 `version` 由 0.1.6 改為 0.1.7。

Why：設定規格表新增一個環境變數，讀表的部署與體檢行為跟著變，版本要往上走，各 CLI 才知道要更新。

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

Who：`jsc-cli` 外掛的套件描述檔。
Merge pull request 'feat(cli): 設定規格登錄 PR 盯場輪詢間隔' (#22) from feat/sdlc-flow-rules/config-spec-pr-watch into feat/sdlc-flow-rules/main 96cd7bd14d 
Reviewed-on: #22
Merge pull request 'feat(cli): 設定規格登錄 PR 盯場輪詢間隔' (#23) from feat/sdlc-flow-rules/main into develop 1840af2ace
admin approved these changes 2026-08-27 04:14:47 +00:00
admin merged commit a97ae6e382 into master 2026-08-27 04:14:50 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
admin
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
admin (系統管理員) jiantw83 (Jeffery)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: plugins/cli#24