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

釋出 jsc-hooks 0.3.6：頁面編號偵測補齊型別與 smoke 斷言修正 #64

Merged
admin merged 5 commits from develop into master 2026-09-01 04:45:04 +00:00
Conversation 1 Commits 5 Files Changed 5
+57 -15
jiantw83 commented 2026-09-01 04:44:23 +00:00
Member
Copy Link
Copy Source

摘要

  • 需求描述：把 develop 併進預設分支，讓改動真的到各 CLI 手上。這是 PR 分支階梯的最後一級——marketplace 與 version-guard.sh 都讀預設分支，停在 develop 的內容 jsc-cli:deploy 看不到。
  • 計畫名稱：無
  • 計畫頁：無
  • 分析頁：無

變更內容

這一批的來源是助理 domain 落地與 MONITOR wiki 頁型別，跨四個存放庫：

存放庫 這一批改了什麼
assist 樣板改成獨立的 jsc-assist domain、唯讀技能 status、技能行為清單、監控頁兩份範本、marketplace 副本
gitea MONITOR 進 resolve_wiki_repo() 白名單與 check-wiki-rules.sh 的 TYPES，README、wiki 技能、行為清單一併更新
meta 命名總表新增 MONITOR 一列，補雜湊來源與寫入語意說明，修掉「CHECK 是唯一例外」這句不再成立的敘述
hooks comment-scope.sh 的頁面編號偵測補上 SKILLSET、TOOLING、MONITOR；另含已合併的 smoke 擋人斷言修正

設計重點

  • 合併順序要留意。 gitea 是型別的解析端。它沒跟上而其餘先進預設分支，會出現準則說有 MONITOR、註解掃描認得 MONITOR，但 gitea.sh wiki-repo MONITOR 仍回 unknown wiki type 的狀態。不會壞事，但那段期間型別還不能用。
  • assist 的版本會從預設分支上的數字往下走。 預設分支原本的號碼是樣板殘留，名稱還是 jsc-template，從沒以 jsc-assist 發佈過。合併後整份內容由 develop 取代，版本是這個 domain 的真實起算值。plugin 名不同，不會與任何已安裝的東西混淆。
  • 雜湊來源比照 CHECK 取主機名與登入帳號；監控頁一律附加、不覆寫。兩點都與 TOOLING 相反，準則裡各自寫明白了。

測試結果

  • 子功能與功能主幹兩級都跑過檢核，四個存放庫的 lint-scripts.sh、lint-frontmatter.sh、check-behaviors.sh、ste100-lint.sh 全綠（assist 的 lint-scripts.sh 是 exit 3，因為它確實沒有 tools/ 也沒有 hooks/）。
  • gitea.sh wiki-repo MONITOR 在工作樹上印出 knowledges/MONITOR；跨型別代用的防護仍在。
  • comment-scope.sh 的偵測樣式實測三種型別各自都攔得下來。
  • 五支 CLI 的 hook smoke 全部 status=ok。
  • 這一級合併之後才驗得了的兩件事：跑 /jsc-cli:deploy 更新，然後在新的工作階段叫 /jsc-assist:status（目前沒有心跳檔，預期輸出「助理未運行」而不是報錯）；以及實際往 knowledges/MONITOR 寫一頁，確認該存放庫的 wiki 功能是開的（目前 wiki-list 回 404，第一次寫入才會生出來）。

前置 Push Request

  • 無
## 摘要 - 需求描述：把 `develop` 併進預設分支，讓改動真的到各 CLI 手上。這是 PR 分支階梯的最後一級——marketplace 與 `version-guard.sh` 都讀預設分支，停在 `develop` 的內容 `jsc-cli:deploy` 看不到。 - 計畫名稱：無 - 計畫頁：無 - 分析頁：無 ## 變更內容 這一批的來源是助理 domain 落地與 `MONITOR` wiki 頁型別，跨四個存放庫： | 存放庫 | 這一批改了什麼 | | --- | --- | | `assist` | 樣板改成獨立的 `jsc-assist` domain、唯讀技能 `status`、技能行為清單、監控頁兩份範本、marketplace 副本 | | `gitea` | `MONITOR` 進 `resolve_wiki_repo()` 白名單與 `check-wiki-rules.sh` 的 `TYPES`，README、`wiki` 技能、行為清單一併更新 | | `meta` | 命名總表新增 `MONITOR` 一列，補雜湊來源與寫入語意說明，修掉「`CHECK` 是唯一例外」這句不再成立的敘述 | | `hooks` | `comment-scope.sh` 的頁面編號偵測補上 `SKILLSET`、`TOOLING`、`MONITOR`；另含已合併的 smoke 擋人斷言修正 | ## 設計重點 - **合併順序要留意。** `gitea` 是型別的解析端。它沒跟上而其餘先進預設分支，會出現準則說有 `MONITOR`、註解掃描認得 `MONITOR`，但 `gitea.sh wiki-repo MONITOR` 仍回 `unknown wiki type` 的狀態。不會壞事，但那段期間型別還不能用。 - **`assist` 的版本會從預設分支上的數字往下走。** 預設分支原本的號碼是樣板殘留，名稱還是 `jsc-template`，從沒以 `jsc-assist` 發佈過。合併後整份內容由 `develop` 取代，版本是這個 domain 的真實起算值。plugin 名不同，不會與任何已安裝的東西混淆。 - 雜湊來源比照 `CHECK` 取主機名與登入帳號；監控頁一律附加、不覆寫。兩點都與 `TOOLING` 相反，準則裡各自寫明白了。 ## 測試結果 - 子功能與功能主幹兩級都跑過檢核，四個存放庫的 `lint-scripts.sh`、`lint-frontmatter.sh`、`check-behaviors.sh`、`ste100-lint.sh` 全綠（`assist` 的 `lint-scripts.sh` 是 exit 3，因為它確實沒有 `tools/` 也沒有 `hooks/`）。 - `gitea.sh wiki-repo MONITOR` 在工作樹上印出 `knowledges/MONITOR`；跨型別代用的防護仍在。 - `comment-scope.sh` 的偵測樣式實測三種型別各自都攔得下來。 - 五支 CLI 的 hook smoke 全部 `status=ok`。 - **這一級合併之後才驗得了的兩件事**：跑 `/jsc-cli:deploy` 更新，然後**在新的工作階段**叫 `/jsc-assist:status`（目前沒有心跳檔，預期輸出「助理未運行」而不是報錯）；以及實際往 `knowledges/MONITOR` 寫一頁，確認該存放庫的 wiki 功能是開的（目前 `wiki-list` 回 404，第一次寫入才會生出來）。 ## 前置 Push Request - 無
jiantw83 added 5 commits 2026-09-01 04:44:23 +00:00
fix(smoke): 擋人斷言改依各 CLI 的形態判定 fbf0aec9f7 
What：
- wire-cli.sh 的 smoke 區段新增四個共用小函式：smoke_deny_rc 給結束碼、smoke_deny_mark 給擋人標記、smoke_deny_ok 做判定、smoke_deny_desc 產生失敗訊息。
- smoke_rs_case 與 smoke_vg_case 的判定改走 smoke_deny_ok，五個呼叫點的預期值由結束碼 2 改成字面值 deny。
- 三份 manifest 的版本一起提升，由 sync-skill-manifest.sh 同步。

Why：
- 兩個函式把「擋下」寫死成結束碼 2，但擋下的形態是由 deny.sh 依 CLI 決定的。claude、codex、copilot 與認不得的代號走 stderr 加結束碼 2；antigravity 改印一行 stdout 的 deny JSON，kiro 只能注入警告，這兩支的結束碼都固定 0。
- 結果是這兩支的 smoke 各有五條判定失敗，回報成執行期錯誤。但擋人訊息其實都正確印出來了，配套的訊息斷言也全部通過，壞的只有結束碼那一項比對——是斷言認錯形態，不是 hook 失效。
- 不能改成一律放寬到 0。那兩支上放行也是 0，放寬之後「該擋沒擋」與「正確擋下」完全同形，這道斷言等於作廢。

How：
- 形態表在 smoke 這側鏡射一份，事實來源仍是 deny.sh 的 case。表只有一份，改一支不會忘了另一支。
- 判定同時比結束碼與擋人標記；預期放行的案例反過來要求標記不得出現，所以「該擋沒擋」與「不該擋卻擋了」兩個方向都守得住。
- 走 stderr 的三支標記為空字串，判定行為與原本完全相同，不產生回歸。
- 斷言條數不增不減，兩個預期條數常數都不必動。
- 反向測試確認斷言仍然有效：拿掉 deny.sh 裡 antigravity 的 deny JSON 輸出，做出該擋卻靜靜放行的情境，smoke 正確判失敗。結束碼相同，靠擋人標記才分得出來。

Who：
接線後的冒煙測試在 antigravity 與 kiro 上判定失敗，追出來的是斷言本身的缺陷。
Merge pull request 'fix/smoke-deny-assertion-per-cli' (#60) from fix/smoke-deny-assertion-per-cli into develop 417fe1a413 
Reviewed-on: #60
fix(comment-scope): 頁面編號偵測補齊三種缺漏的型別 113df37808 
What：
- wiki 頁面編號的偵測樣式補上 SKILLSET、TOOLING 與 MONITOR 三種型別。
- 三份 manifest 的版本一起提升。

Why：
- 這支 hook 的職責是擋住把文件追蹤資訊寫進程式碼註解，wiki 頁面編號正是禁止項之一。
- 樣式只列到 REPORT，但實際的頁型清單早就有 SKILLSET 與 TOOLING，現在再加 MONITOR。清單漏掉的那幾種，頁面編號寫進註解就攔不到，等於這條規則對它們不存在。
- SKILLSET 與 TOOLING 的缺漏是既有落差，不是這次新增型別才產生的，一併補齊比較省事，也不會留下第二個要記得的地方。

How：
- 型別的排列順序照 gitea.sh 的 resolve_wiki_repo 走，兩邊一致才看得出有沒有漏。
- 規則正文的唯一來源仍是 jsc-review 的註解範圍文件，這裡只補偵測樣式，不重述規則清單。
- 實測過三種型別各自都攔得下來，命中的說明都是「jsc wiki 頁面編號」，不是旁邊那條前綴加流水號的樣式誤撿。

Who：
技能助理落地帶出來的頁型別需求，四個存放庫同一批改。
Merge pull request 'feat/monitor-wiki-page-type/page-id-regex' (#62) from feat/monitor-wiki-page-type/page-id-regex into feat/monitor-wiki-page-type/main 3cf8d82ffd 
Reviewed-on: #62
Merge pull request '釋出 jsc-hooks 0.3.6：頁面編號偵測補齊型別' (#63) from feat/monitor-wiki-page-type/main into develop ea50b7d915 
Reviewed-on: #63
admin approved these changes 2026-09-01 04:45:02 +00:00
admin merged commit c6bf5a9b03 into master 2026-09-01 04:45:04 +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/hooks#64