fix/sdlc-skill-check-compliance #5
@@ -1,75 +1,89 @@
|
|||||||
{
|
{
|
||||||
"name": "jsc",
|
"name": "jsc",
|
||||||
|
"description": "jsc 跨 AI 助理技能組的統一 marketplace(claude / codex / copilot / antigravity / kiro)。",
|
||||||
|
"owner": {
|
||||||
|
"name": "JSC"
|
||||||
|
},
|
||||||
"plugins": [
|
"plugins": [
|
||||||
{
|
{
|
||||||
"name": "jsc-ask",
|
"name": "jsc-ask",
|
||||||
"source": {
|
"source": {
|
||||||
"source": "url",
|
"source": "url",
|
||||||
"url": "https://gitea.jsc.idv.tw/plugins/ask.git"
|
"url": "https://gitea.jsc.idv.tw/plugins/ask.git"
|
||||||
}
|
},
|
||||||
|
"description": "決策樹問詢與問詢紀錄(QUESTION_* wiki 頁)"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"name": "jsc-cli",
|
"name": "jsc-cli",
|
||||||
"source": {
|
"source": {
|
||||||
"source": "url",
|
"source": "url",
|
||||||
"url": "https://gitea.jsc.idv.tw/plugins/cli.git"
|
"url": "https://gitea.jsc.idv.tw/plugins/cli.git"
|
||||||
}
|
},
|
||||||
|
"description": "CLI 偵測、模型能力標籤與技能庫批次部署"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"name": "jsc-git",
|
"name": "jsc-git",
|
||||||
"source": {
|
"source": {
|
||||||
"source": "url",
|
"source": "url",
|
||||||
"url": "https://gitea.jsc.idv.tw/plugins/git.git"
|
"url": "https://gitea.jsc.idv.tw/plugins/git.git"
|
||||||
}
|
},
|
||||||
|
"description": "Commit 分組認可與 Push Request 建立"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"name": "jsc-gitea",
|
"name": "jsc-gitea",
|
||||||
"source": {
|
"source": {
|
||||||
"source": "url",
|
"source": "url",
|
||||||
"url": "https://gitea.jsc.idv.tw/plugins/gitea.git"
|
"url": "https://gitea.jsc.idv.tw/plugins/gitea.git"
|
||||||
}
|
},
|
||||||
|
"description": "Gitea API 工具、Wiki 讀寫與存取庫批次同步"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"name": "jsc-hooks",
|
"name": "jsc-hooks",
|
||||||
"source": {
|
"source": {
|
||||||
"source": "url",
|
"source": "url",
|
||||||
"url": "https://gitea.jsc.idv.tw/plugins/hooks.git"
|
"url": "https://gitea.jsc.idv.tw/plugins/hooks.git"
|
||||||
}
|
},
|
||||||
|
"description": "跨 CLI hooks:STE100 語言強制、工時計時、技能用量記錄"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"name": "jsc-log",
|
"name": "jsc-log",
|
||||||
"source": {
|
"source": {
|
||||||
"source": "url",
|
"source": "url",
|
||||||
"url": "https://gitea.jsc.idv.tw/plugins/log.git"
|
"url": "https://gitea.jsc.idv.tw/plugins/log.git"
|
||||||
}
|
},
|
||||||
|
"description": "工作日誌(LOG_* wiki 頁)與技能使用統計"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"name": "jsc-meta",
|
"name": "jsc-meta",
|
||||||
"source": {
|
"source": {
|
||||||
"source": "url",
|
"source": "url",
|
||||||
"url": "https://gitea.jsc.idv.tw/plugins/meta.git"
|
"url": "https://gitea.jsc.idv.tw/plugins/meta.git"
|
||||||
}
|
},
|
||||||
|
"description": "技能組自我管理:新建、更新、刪除技能與技能準則"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"name": "jsc-pkg",
|
"name": "jsc-pkg",
|
||||||
"source": {
|
"source": {
|
||||||
"source": "url",
|
"source": "url",
|
||||||
"url": "https://gitea.jsc.idv.tw/plugins/pkg.git"
|
"url": "https://gitea.jsc.idv.tw/plugins/pkg.git"
|
||||||
}
|
},
|
||||||
|
"description": "套件批次更新(nodejs/python/dotnet),失敗還原"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"name": "jsc-review",
|
"name": "jsc-review",
|
||||||
"source": {
|
"source": {
|
||||||
"source": "url",
|
"source": "url",
|
||||||
"url": "https://gitea.jsc.idv.tw/plugins/review.git"
|
"url": "https://gitea.jsc.idv.tw/plugins/review.git"
|
||||||
}
|
},
|
||||||
|
"description": "程式碼審查:Refactoring 壞味道六組 + 註解規範 + 淺模組"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"name": "jsc-sdlc",
|
"name": "jsc-sdlc",
|
||||||
"source": {
|
"source": {
|
||||||
"source": "url",
|
"source": "url",
|
||||||
"url": "https://gitea.jsc.idv.tw/plugins/sdlc.git"
|
"url": "https://gitea.jsc.idv.tw/plugins/sdlc.git"
|
||||||
}
|
},
|
||||||
|
"description": "開發生命週期:規劃/分析/實作/維護(wiki 追蹤)"
|
||||||
}
|
}
|
||||||
]
|
]
|
||||||
}
|
}
|
||||||
|
|||||||
@@ -59,7 +59,7 @@
|
|||||||
"source": "url",
|
"source": "url",
|
||||||
"url": "https://gitea.jsc.idv.tw/plugins/meta.git"
|
"url": "https://gitea.jsc.idv.tw/plugins/meta.git"
|
||||||
},
|
},
|
||||||
"description": "技能組自我管理:新建/更新/刪除技能與技能準則"
|
"description": "技能組自我管理:新建、更新、刪除技能與技能準則"
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
"name": "jsc-pkg",
|
"name": "jsc-pkg",
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
{
|
{
|
||||||
"name": "jsc-sdlc",
|
"name": "jsc-sdlc",
|
||||||
"version": "0.0.3",
|
"version": "0.0.4",
|
||||||
"description": "開發生命週期:規劃/分析/實作/維護(wiki 追蹤)",
|
"description": "開發生命週期:規劃/分析/實作/維護(wiki 追蹤)",
|
||||||
"skills": "./skills",
|
"skills": "./skills",
|
||||||
"author": {
|
"author": {
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
{
|
{
|
||||||
"name": "jsc-sdlc",
|
"name": "jsc-sdlc",
|
||||||
"version": "0.0.3",
|
"version": "0.0.4",
|
||||||
"description": "開發生命週期:規劃/分析/實作/維護(wiki 追蹤)",
|
"description": "開發生命週期:規劃/分析/實作/維護(wiki 追蹤)",
|
||||||
"skills": "./skills"
|
"skills": "./skills"
|
||||||
}
|
}
|
||||||
|
|||||||
@@ -36,7 +36,7 @@ Marketplace 統一為 `jsc`(https://gitea.jsc.idv.tw/plugins/jsc.git),安
|
|||||||
|
|
||||||
### `maintain`
|
### `maintain`
|
||||||
|
|
||||||
維護:讀取維護期內的專案,每個專案一個 sub agent:切 develop/master → 至少五種建議維護方法 → commit / push / PR → 更新前次維護時間。
|
維護:讀取維護期內的專案,每個專案一個 sub agent:切 develop/master → 至少五種建議維護方法 → commit / push / PR → 更新前次維護時間。僅適用於維護期內已交付的專案;尚在實作中或未登記於 `MAINTAIN_CONTENTS` 的專案不適用。
|
||||||
|
|
||||||
<!-- JSC-SKILLS:END -->
|
<!-- JSC-SKILLS:END -->
|
||||||
|
|
||||||
@@ -55,7 +55,7 @@ Marketplace 統一為 `jsc`(https://gitea.jsc.idv.tw/plugins/jsc.git),安
|
|||||||
|
|
||||||
Wiki 位置:`PLAN_{HASH}` / `PLAN_CONTENTS` 只讀 `JSC_WIKI_REPO_PLAN`,再退回 `JSC_WIKI_REPO`;`ANALYZE_{HASH}` / `ANALYZE_CONTENTS` 只讀 `JSC_WIKI_REPO_ANALYZE`,再退回 `JSC_WIKI_REPO`;`REPO_{HASH}` / `REPO_CONTENTS` 只讀 `JSC_WIKI_REPO_REPO`,再退回 `JSC_WIKI_REPO`;`MAINTAIN_CONTENTS` 只讀 `JSC_WIKI_REPO_MAINTAIN`,再退回 `JSC_WIKI_REPO`。不同類型不可互相代用;兩者都未設定才詢問(見 `jsc-gitea`)。
|
Wiki 位置:`PLAN_{HASH}` / `PLAN_CONTENTS` 只讀 `JSC_WIKI_REPO_PLAN`,再退回 `JSC_WIKI_REPO`;`ANALYZE_{HASH}` / `ANALYZE_CONTENTS` 只讀 `JSC_WIKI_REPO_ANALYZE`,再退回 `JSC_WIKI_REPO`;`REPO_{HASH}` / `REPO_CONTENTS` 只讀 `JSC_WIKI_REPO_REPO`,再退回 `JSC_WIKI_REPO`;`MAINTAIN_CONTENTS` 只讀 `JSC_WIKI_REPO_MAINTAIN`,再退回 `JSC_WIKI_REPO`。不同類型不可互相代用;兩者都未設定才詢問(見 `jsc-gitea`)。
|
||||||
|
|
||||||
HASH 規則:一律先算 `{owner}/{repo}` 的 SHA-1 前 8 碼並轉大寫;若第一碼是數字,或 `A`、`B`、`C`,就改成 `H` 加上原 SHA-1 前 7 碼,總長維持 8 碼。
|
HASH 規則:`{owner}/{repo}` 的共用 wiki hash 一律由 `jsc-gitea/tools/hash-id` 計算(見 `jsc-gitea:wiki`),此 domain 不重複實作演算法。
|
||||||
|
|
||||||
## 相關 domain
|
## 相關 domain
|
||||||
|
|
||||||
|
|||||||
+1
-1
@@ -1,6 +1,6 @@
|
|||||||
{
|
{
|
||||||
"name": "jsc-sdlc",
|
"name": "jsc-sdlc",
|
||||||
"version": "0.0.3",
|
"version": "0.0.4",
|
||||||
"description": "開發生命週期:規劃/分析/實作/維護(wiki 追蹤)",
|
"description": "開發生命週期:規劃/分析/實作/維護(wiki 追蹤)",
|
||||||
"skills": "./skills/"
|
"skills": "./skills/"
|
||||||
}
|
}
|
||||||
|
|||||||
@@ -8,13 +8,13 @@ description: SDLC analysis stage. Gate on the designated model (model-config) or
|
|||||||
Goal: create or extend the wiki analysis page `ANALYZE_{HASH}`.
|
Goal: create or extend the wiki analysis page `ANALYZE_{HASH}`.
|
||||||
This skill is a **logic-only** stage: never output code, and **never modify any file**.
|
This skill is a **logic-only** stage: never output code, and **never modify any file**.
|
||||||
|
|
||||||
`{HASH}` = the shared wiki hash for `{owner}/{repo}`: take the first 8 uppercase hex chars of its SHA-1. If the first char is a digit, or `A`/`B`/`C`, replace it with `H` and keep the next 7 chars.
|
`{HASH}` = the shared wiki hash for `{owner}/{repo}` used to build the `ANALYZE_{HASH}` page name, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`).
|
||||||
All wiki reads and writes go through `jsc-gitea:wiki`.
|
All wiki reads and writes go through `jsc-gitea:wiki`.
|
||||||
|
|
||||||
## Steps
|
## Steps
|
||||||
|
|
||||||
1. **Model gate and stage lock**:
|
1. **Model gate and stage lock**:
|
||||||
1. Resolve the analyze stage's designated model chain: run `jsc-cli/tools/model-config.sh get analyze`. 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` (analysis requires the reasoning-high tag).
|
1. Run `jsc-cli/tools/model-config.sh resolve analyze` to get the required model; if it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (analysis requires the reasoning-high 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.
|
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 analyze {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`.
|
3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock analyze {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. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` for plans whose status is the literal 「未分析」 (name and HASH), and read `ANALYZE_CONTENTS` for existing analyses.
|
2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` for plans whose status is the literal 「未分析」 (name and HASH), and read `ANALYZE_CONTENTS` for existing analyses.
|
||||||
|
|||||||
@@ -11,18 +11,17 @@ All wiki reads and writes go through `jsc-gitea:wiki`.
|
|||||||
## Steps
|
## Steps
|
||||||
|
|
||||||
1. **Model gate and stage lock**:
|
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.
|
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`.
|
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.
|
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. **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).
|
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. 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. 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**:
|
||||||
6. 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).
|
- 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.
|
- 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.
|
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.
|
||||||
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.
|
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
|
## Rules
|
||||||
|
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
---
|
---
|
||||||
name: maintain
|
name: maintain
|
||||||
description: SDLC maintenance stage. Gate on the designated model (model-config) or capability tags for the maintenance stage, lock the model via sdlc-gate, read projects still inside their maintenance window from MAINTAIN_CONTENTS, then run one sub agent per project: switch to develop or master, propose at least five maintenance actions, commit to a new branch, push, and PR. Update the last-maintained timestamp afterward. Use for periodic upkeep of delivered projects.
|
description: SDLC maintenance stage. Gate on the designated model (model-config) or capability tags for the maintenance stage, lock the model via sdlc-gate, read projects still inside their maintenance window from MAINTAIN_CONTENTS, then run one sub agent per project: switch to develop or master, propose at least five maintenance actions, commit to a new branch, push, and PR. Update the last-maintained timestamp afterward. Use for periodic upkeep of delivered projects inside their maintenance window; not for projects still mid-implementation or not yet registered in MAINTAIN_CONTENTS.
|
||||||
---
|
---
|
||||||
|
|
||||||
# maintain
|
# maintain
|
||||||
@@ -11,7 +11,7 @@ All wiki reads and writes go through `jsc-gitea:wiki`.
|
|||||||
## Steps
|
## Steps
|
||||||
|
|
||||||
1. **Model gate and stage lock**:
|
1. **Model gate and stage lock**:
|
||||||
1. Resolve the maintain stage's designated model chain: run `jsc-cli/tools/model-config.sh get maintain`. 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 「SDLC 階段需求」 table from `jsc-cli:models` (any listed model qualifies for maintenance).
|
1. Run `jsc-cli/tools/model-config.sh resolve maintain` to get the required model; if it prints nothing, fall back to the 「SDLC 階段需求」 table from `jsc-cli:models` (any listed model qualifies for maintenance).
|
||||||
2. If the current model is not the required model, or is missing from the mapping table, block the flow and tell the user which model to switch to. Completion condition: the current model satisfies the gate.
|
2. If the current model is not the required model, or is missing from the mapping table, 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 maintain {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`.
|
3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock maintain {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`.
|
||||||
4. Run this gate only when the stage changes; inside the maintenance stage the lock already enforces the model, so never re-gate between projects.
|
4. Run this gate only when the stage changes; inside the maintenance stage the lock already enforces the model, so never re-gate between projects.
|
||||||
|
|||||||
@@ -8,13 +8,13 @@ description: SDLC planning stage. Gate on the designated model (model-config) or
|
|||||||
Goal: create or extend the wiki plan page `PLAN_{HASH}`.
|
Goal: create or extend the wiki plan page `PLAN_{HASH}`.
|
||||||
This skill is a **logic-only** stage: never output code, and **never modify any file**.
|
This skill is a **logic-only** stage: never output code, and **never modify any file**.
|
||||||
|
|
||||||
`{HASH}` = the shared wiki hash for `{owner}/{repo}`: take the first 8 uppercase hex chars of its SHA-1. If the first char is a digit, or `A`/`B`/`C`, replace it with `H` and keep the next 7 chars.
|
`{HASH}` = the shared wiki hash for `{owner}/{repo}` used to build the `PLAN_{HASH}` page name, computed by `jsc-gitea/tools/hash-id` (see `jsc-gitea:wiki`).
|
||||||
All wiki reads and writes go through `jsc-gitea:wiki`.
|
All wiki reads and writes go through `jsc-gitea:wiki`.
|
||||||
|
|
||||||
## Steps
|
## Steps
|
||||||
|
|
||||||
1. **Model gate and stage lock**:
|
1. **Model gate and stage lock**:
|
||||||
1. Resolve the plan stage's designated model chain: run `jsc-cli/tools/model-config.sh get plan`. 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` (planning requires the reasoning-high tag).
|
1. Run `jsc-cli/tools/model-config.sh resolve plan` to get the required model; if it prints nothing, fall back to the capability-tag check via `jsc-cli:models` (planning requires the reasoning-high 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.
|
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 plan {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`.
|
3. Lock the stage: run `jsc-hooks/hooks/sdlc-gate.sh lock plan {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. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` and list the plans whose status is the literal 「未分析」 (not analyzed), with names and HASH.
|
2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` and list the plans whose status is the literal 「未分析」 (not analyzed), with names and HASH.
|
||||||
|
|||||||
Reference in New Issue
Block a user