refactor(sdlc): 消除四個 SDLC skill 間重複邏輯,改為委派唯一權威來源
What(做了什麼):
1. 移除 plan、analyze、implement 三個 skill 及 README.md 中各自重述的 wiki hash 演算法說明(原本各處都各自寫一遍「取 SHA-1 前 8 碼大寫十六進位,開頭若為數字或 A/B/C 則替換為 H 加後 7 碼」),改為統一指向唯一權威工具 jsc-gitea/tools/hash-id(透過 jsc-gitea:wiki 使用)。
2. 移除 plan、analyze、implement、maintain 四個 skill 中重複的 model chain fallback 選擇邏輯說明(原本各自描述「執行 jsc-cli/tools/model-config.sh get {stage},若印出 chain 則取目前 CLI 可用的第一個,fallback 依 chain 順序套用」),改為統一呼叫新的共用子指令 jsc-cli/tools/model-config.sh resolve {stage},由該子指令自行封裝解析邏輯(此 resolve 子指令由另一位 agent 同時在 sibling repo jsc-cli 開的配套 PR 新增,本 PR 依賴該 PR)。
3. implement/SKILL.md 移除自身多餘的「先解析環境變數」步驟(原第 2 步,手動檢查 JSC_WIKI_REPO_ANALYZE、JSC_WIKI_REPO、JSC_WIKI_REPO_QUESTION、GITEA_HOST、GITEA_TOKEN 後才詢問使用者),因為此解析已由 implement 其他步驟委派的 jsc-gitea:wiki 正確處理,屬於死重複邏輯;後續步驟由 2-8 重新編號為 2-7。
4. maintain/SKILL.md 在 frontmatter description 欄位加入明確的負向觸發說明,釐清此 skill 僅用於已交付、仍在維護窗口內的專案,「不適用於仍在實作中或尚未登錄於 MAINTAIN_CONTENTS 的專案」。
5. plugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json 三份版本號檔案,由 0.0.3 升版至 0.0.4。
Why(為什麼改):
四個 SDLC skill 各自重述相同的 hash 演算法與 model chain fallback 邏輯,違反 jsc-meta:skill-check 稽核準則中「單一權威來源」的要求,日後維護容易改一處漏一處;implement 的環境變數解析步驟與其他步驟委派的 jsc-gitea:wiki 功能重疊,屬死碼;maintain 的觸發時機描述不夠明確,容易被誤用在尚未進入維護窗口的專案上。
How(怎麼改的):
將重複邏輯抽離,改為指向或呼叫唯一權威工具/skill(jsc-gitea/tools/hash-id、jsc-cli/tools/model-config.sh resolve、jsc-gitea:wiki),移除 implement 中的死步驟並重新編號,於 maintain frontmatter 補上負向觸發描述,並同步升版三份 plugin.json。全程不改變任何對外行為,純屬重構。
Who(誰/哪個需求):
jsc-meta:skill-check 對 plan、analyze、implement、maintain 四個 SDLC skill 的例行合規稽核修正。
This commit is contained in:
@@ -11,18 +11,17 @@ All wiki reads and writes go through `jsc-gitea:wiki`.
|
||||
## Steps
|
||||
|
||||
1. **Model gate and stage lock**:
|
||||
1. Resolve the implement stage's designated model chain: run `jsc-cli/tools/model-config.sh get implement`. If it prints a chain, the required model is the first entry of the chain the current CLI can use (fallbacks apply in chain order). If it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (implementation requires the coding tag).
|
||||
1. Run `jsc-cli/tools/model-config.sh resolve implement` to get the required model; if it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (implementation requires the coding tag).
|
||||
2. If the current model is not the required model, or fails the tag check, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate.
|
||||
3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock implement {current-model}`. From now until the next SDLC stage's gate runs, the sdlc-gate hook enforces this model on every prompt; switching models mid-stage gets blocked. Completion condition: the lock file is written, verified with `sdlc-gate.sh report`.
|
||||
2. **Resolve environment first**: inspect `JSC_WIKI_REPO_ANALYZE`, `JSC_WIKI_REPO`, `JSC_WIKI_REPO_QUESTION`, `GITEA_HOST`, and `GITEA_TOKEN` before asking the user anything. Use inherited shell values first. If the env vars are present but the tool cannot read them, check the current shell environment before asking.
|
||||
3. **Generate a work ticket**: format `TICKET_{yyyyMMdd}_{HHmmss}_{HASH}`. Use the shared wiki hash for `{owner}/{repo}` for `{HASH}`: take the first 8 uppercase hex chars of its SHA-1, then replace a leading digit or `A`/`B`/`C` with `H` plus the next 7 chars. Try to rename the current session to the ticket name (skip when the CLI does not support it).
|
||||
4. Read `ANALYZE_CONTENTS` via `jsc-gitea:wiki` and list what is unfinished: plan name, HASH, work package number, count of open items. A selectable work package must satisfy all three: **unfinished, dependency-free (or all dependencies done), and not holding a work ticket**.
|
||||
5. Let the user pick a work package per `jsc-ask:ask` rules (options state open-item count and estimated effort). Write the ticket into that work package's ticket column (the zh-TW field 「工作證」) on the analysis page and save it back to the wiki. **Only after the ticket is saved successfully may you proceed.**
|
||||
6. List every open item of the work package and implement them **one at a time**:
|
||||
2. **Generate a work ticket**: format `TICKET_{yyyyMMdd}_{HHmmss}_{HASH}`. `{HASH}` = the shared wiki hash for `{owner}/{repo}`, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`). Try to rename the current session to the ticket name (skip when the CLI does not support it).
|
||||
3. Read `ANALYZE_CONTENTS` via `jsc-gitea:wiki` and list what is unfinished: plan name, HASH, work package number, count of open items. A selectable work package must satisfy all three: **unfinished, dependency-free (or all dependencies done), and not holding a work ticket**.
|
||||
4. Let the user pick a work package per `jsc-ask:ask` rules (options state open-item count and estimated effort). Write the ticket into that work package's ticket column (the zh-TW field 「工作證」) on the analysis page and save it back to the wiki. **Only after the ticket is saved successfully may you proceed.**
|
||||
5. List every open item of the work package and implement them **one at a time**:
|
||||
- Follow the TDD loop: red before green, one slice at a time; rules and anti-patterns in `references/tdd.md` (refactoring belongs to the review stage).
|
||||
- After each item, flip its `[ ]` to `[x]` on the analysis page and save to the wiki before starting the next item.
|
||||
7. When all items are done, call `jsc-review:code-review` and wait for the review; on failure, fix and re-review until it passes.
|
||||
8. Ask per `jsc-ask:ask` rules whether to register this project for maintenance: append to `MAINTAIN_CONTENTS` with `templates/maintain-contents.md`. Required: repository `{owner}/{repo}`, maintenance method, start date. Optional: end date (NULL = maintain forever), last-maintained time.
|
||||
6. When all items are done, call `jsc-review:code-review` and wait for the review; on failure, fix and re-review until it passes.
|
||||
7. Ask per `jsc-ask:ask` rules whether to register this project for maintenance: append to `MAINTAIN_CONTENTS` with `templates/maintain-contents.md`. Required: repository `{owner}/{repo}`, maintenance method, start date. Optional: end date (NULL = maintain forever), last-maintained time.
|
||||
|
||||
## Rules
|
||||
|
||||
|
||||
Reference in New Issue
Block a user