From 8df6948c5c48c133ac833aa1cbf8fb52f8812010 Mon Sep 17 00:00:00 2001 From: Jeffery Date: Mon, 24 Aug 2026 16:05:18 +0800 Subject: [PATCH 1/3] =?UTF-8?q?feat(SDLC=20=E9=9A=8E=E6=AE=B5):=20?= =?UTF-8?q?=E9=96=98=E9=96=80=E6=94=B9=E7=82=BA=E8=83=BD=E5=8A=9B=E6=A8=99?= =?UTF-8?q?=E7=B1=A4=E7=A8=8B=E5=BC=8F=E5=88=A4=E5=AE=9A=EF=BC=8C=E5=88=86?= =?UTF-8?q?=E6=9E=90=E8=88=87=E5=AF=A6=E4=BD=9C=E5=85=88=E7=A2=BA=E8=AA=8D?= =?UTF-8?q?=E5=88=86=E6=94=AF=EF=BC=8C=E4=BA=A4=E6=8E=A5=E5=B7=A5=E4=BD=9C?= =?UTF-8?q?=E5=8C=85=E5=84=AA=E5=85=88?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 (1M context) --- skills/analyze/SKILL.md | 54 +++++++++++++++++++++++++++++---------- skills/implement/SKILL.md | 30 ++++++++++++++-------- skills/maintain/SKILL.md | 12 ++++----- skills/plan/SKILL.md | 11 ++++---- templates/analyze-page.md | 16 ++++++++---- 5 files changed, 82 insertions(+), 41 deletions(-) diff --git a/skills/analyze/SKILL.md b/skills/analyze/SKILL.md index 0bc991c..f1a5919 100644 --- a/skills/analyze/SKILL.md +++ b/skills/analyze/SKILL.md @@ -1,6 +1,6 @@ --- name: analyze -description: SDLC analysis stage. Gate on the designated model (model-config) or capability tags, lock the model for the stage via sdlc-gate, pick a plan from PLAN_CONTENTS, analyze user stories against the current state (working directory plus REPO_{HASH} inventory for reuse). Run WBS to produce numbered work packages, estimate them with CPM, split each into TDD todos, and write wiki page ANALYZE_{HASH}. Logic only - never write code or modify files. Use after planning and before implementation. +description: SDLC analysis stage. Gate on capability tags enforced in code by sdlc-gate (analyze requires reasoning-max, verified against the transcript's actual model id), confirm the source branch with the user, pick a plan from PLAN_CONTENTS, analyze user stories against the current state (working directory plus REPO_{HASH} inventory for reuse). Run WBS with handover work packages ranked first (spec before implementation), estimate them with CPM, split each into TDD todos, and write wiki page ANALYZE_{HASH} with real sample data. Logic only - never write code or modify files. Use after planning and before implementation. --- # analyze @@ -13,25 +13,51 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps -1. **Model gate and stage lock**: - 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. - 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. -3. Let the user choose per `jsc-ask:ask` rules: **extend an existing analysis** or **analyze a new plan**. State the impact scope on every option. -4. Analyze the plan page's user stories one by one against the **current state**, questioning via the `jsc-ask:ask` decision tree until no doubt remains; keep asking while consensus is missing. Current state means: - 1. Every file in the working directory. +1. **Model gate and stage lock** (capability tags, enforced in code — never self-assessed): + 1. Run `jsc-cli/tools/model-tags.sh sync` to refresh `$JSC_HOME/model-tags.tsv` from `jsc-cli/references/model-tags.md`. + 2. Run `jsc-hooks/hooks/sdlc-gate.sh lock analyze`. The script reads the **actual** model id from the transcript, compares it against this stage's required tags (`reasoning-max`), and locks the stage only when they match. + 3. **Never claim a capability tag you have not verified with that script**, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run `unlock` to get past the gate; only the user may decide that. + 4. Exit 0 means the stage is locked. From now until the next stage's gate runs, the sdlc-gate hook blocks every prompt whose model stops satisfying the tags. +2. **Confirm the source branch** — the branch whose code counts as the current state: + 1. Report the working directory's current branch, plus the remote branches available (`git branch -r`) and whether the working tree is clean. + 2. Ask per `jsc-ask:ask` rules which branch the analysis reads from; state the impact scope on every option (analysing the wrong branch produces work packages for code that does not exist). + 3. When the chosen branch is not the current one, **stop and ask the user to switch**. This stage never switches branches, never stashes, and never touches the working tree — see `/jsc-shared:spec-git-safety`. + 4. Record the confirmed branch and its head sha on the analysis page. Completion condition: the user has confirmed the branch explicitly; never infer it from the current checkout alone. +3. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` for plans whose status is the literal 「未分析」 (name and HASH), and read `ANALYZE_CONTENTS` for existing analyses. +4. Let the user choose per `jsc-ask:ask` rules: **extend an existing analysis** or **analyze a new plan**. State the impact scope on every option. +5. Analyze the plan page's user stories one by one against the **current state**, questioning via the `jsc-ask:ask` decision tree until no doubt remains; keep asking while consensus is missing. Current state means: + 1. Every file in the working directory, on the branch confirmed in step 2. 2. **Reuse existing methods and endpoints whenever possible**: - Check the `REPO_{HASH}` inventory page first. Re-inventory when the feature or endpoint is missing, or when the recorded commit sha differs from the current one. - Re-inventory **MUST run as a sub agent**: analyze the repository's features and endpoints, attach the current commit sha, write back to `REPO_{HASH}` with `templates/repo-page.md`, and update `REPO_CONTENTS` per `templates/repo-contents.md`. - For each reuse candidate, confirm the file path and method name first, then analyze whether its logic fits the requirement. -5. Run a **Work Breakdown Structure (WBS)**: split the user stories into work packages, number them sequentially (`WP-01`, `WP-02`, ...) and mark dependencies. -6. Estimate every work package's effort in hours and days with the **Critical Path Method (CPM)**, and mark the critical path. -7. Split every work package into todos with **Test-Driven Development (TDD)**, formatted `[ ]` (open) / `[x]` (done). Each todo is one vertical slice: one seam, one test, one minimal implementation. Seams and anti-patterns: `references/tdd.md`. -8. Apply `templates/analyze-page.md` to create or update the analysis page and write it back via `jsc-gitea:wiki`. The page content is Traditional Chinese, exactly as the template dictates. -9. If the analysis page is new: add it to `ANALYZE_CONTENTS` per `templates/analyze-contents.md`, and flip the plan's status in `PLAN_CONTENTS` to the literal 「已分析」. +6. Run a **Work Breakdown Structure (WBS)**: split the user stories into work packages, number them sequentially (`WP-01`, `WP-02`, ...) and mark dependencies. +7. **Rank handover work packages first** — see 「交接優先」 below. Spec-shaped packages ship before implementation-shaped ones. +8. Estimate every work package's effort in hours and days with the **Critical Path Method (CPM)**, and mark the critical path. +9. Split every work package into todos with **Test-Driven Development (TDD)**, formatted `[ ]` (open) / `[x]` (done). Each todo is one vertical slice: one seam, one test, one minimal implementation. Seams and anti-patterns: `references/tdd.md`. +10. Apply `templates/analyze-page.md` to create or update the analysis page and write it back via `jsc-gitea:wiki`. The page content is Traditional Chinese, exactly as the template dictates. +11. If the analysis page is new: add it to `ANALYZE_CONTENTS` per `templates/analyze-contents.md`, and flip the plan's status in `PLAN_CONTENTS` to the literal 「已分析」. + +## 交接優先（handover first） + +A work package is a **handover package** when someone else — another person, another CLI, another team — has to act on its output. Interfaces, schemas, spec documents, acceptance criteria and sample payloads are handover output; endpoint bodies and UI wiring are not. + +- Mark every work package as 交接 `是` / `否` in the WBS table. +- **Order handover packages before implementation packages**, so the receiving side gets the spec while implementation is still open. Implementation packages are the backup queue (實作候補): they are still numbered, estimated and kept on the page, just ranked later. +- Dependencies still win: never place a package before one it depends on. Within the same dependency level, handover packages come first. +- Do not merge a spec and its implementation into one package — that removes the ability to hand the spec over early. Split them. + +## 範例資料（sample data） + +Every sample value on the analysis page — request and response payloads, field values, config snippets, test fixtures — follows this order: + +1. **Real data first.** Take values from an actual source: the database schema and rows, a real API response, an existing config or fixture file, logs. Record where each sample came from in the WBS table's 資料來源 column (for example `真實：dbo.Member`). +2. **Only when no source exists**, derive the value by reasoning from the surrounding logic — and label it as inferred (for example `推論：無來源`), so the receiving side knows it is unverified. +3. Never invent a plausible-looking value and present it as real, and never leave the origin of a sample unstated. +4. Real data goes on the page as **structure and format only**: field names, types, shapes. Never copy personal data onto the wiki — mask any personal identifier, and prefer describing the format over pasting the value. ## Hard limits - Never output a code snippet (file paths and method names are allowed). - Never modify any file in the working directory. +- Never switch, create or clean branches in this stage; ask the user to do it. diff --git a/skills/implement/SKILL.md b/skills/implement/SKILL.md index 9fa2a66..82f7b4d 100644 --- a/skills/implement/SKILL.md +++ b/skills/implement/SKILL.md @@ -1,6 +1,6 @@ --- name: implement -description: SDLC implementation stage. Gate on the designated model (model-config) or capability tags, lock the model for the stage via sdlc-gate, claim a ready work package from ANALYZE_CONTENTS with a work ticket, then complete its TDD todos one by one, updating the wiki after every item. Ends with jsc-review code-review and an optional MAINTAIN_CONTENTS entry. Use when analysis is done and code must be written; not for planning or analysis. +description: SDLC implementation stage. Gate on capability tags enforced in code by sdlc-gate (implement requires coding, verified against the transcript's actual model id), confirm the target branch with the user before writing any file, then claim a ready work package from ANALYZE_CONTENTS with a work ticket and complete its TDD todos one by one, updating the wiki after every item. Ends with jsc-review code-review and an optional MAINTAIN_CONTENTS entry. Use when analysis is done and code must be written; not for planning or analysis. --- # implement @@ -10,21 +10,29 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps -1. **Model gate and stage lock**: - 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. **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**: +1. **Model gate and stage lock** (capability tags, enforced in code — never self-assessed): + 1. Run `jsc-cli/tools/model-tags.sh sync` to refresh `$JSC_HOME/model-tags.tsv` from `jsc-cli/references/model-tags.md`. + 2. Run `jsc-hooks/hooks/sdlc-gate.sh lock implement`. The script reads the **actual** model id from the transcript, compares it against this stage's required tags (`coding`), and locks the stage only when they match. + 3. **Never claim a capability tag you have not verified with that script**, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run `unlock` to get past the gate; only the user may decide that. + 4. Exit 0 means the stage is locked. From now until the next stage's gate runs, the sdlc-gate hook blocks every prompt whose model stops satisfying the tags. +2. **Confirm the target branch** — do this **before writing any file**: + 1. Report the current branch, whether the working tree is clean, and which of `origin/develop` / `origin/master` exist, plus the remote default branch resolved per `/jsc-shared:spec-git-safety`. + 2. Ask per `jsc-ask:ask` rules which branch this work merges into; state the impact scope on every option (the answer decides the PR target and, when it collides with the current branch, forces a new working branch). + 3. Uncommitted changes in the working tree → warn first and let the user commit or back them up; never discard them. + 4. Apply `/jsc-shared:spec-git-safety` to the confirmed target: source branch and target branch sharing a name means creating a new working branch instead of committing on the target; report the resulting branch name. + 5. Record the confirmed target branch on the analysis page next to the work ticket, and reuse it as the PR target in `jsc-git:pr`. Completion condition: the user has confirmed the target branch explicitly; never fall back to `develop` silently. +3. **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). +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). **List handover packages (交接 `是`) first** — the analysis page ranks spec delivery ahead of implementation, so keep that order in the options. 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**: - 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. -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. +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. ## Rules - The work ticket is a mutex: always skip work packages that already hold a ticket; never take one over. - Never batch wiki updates across items; one item, one update. +- Sample data written into code or fixtures follows the analysis page's 資料來源 column: real data where a source exists, reasoned values labelled as inferred where none does. Never invent a value and present it as real, and never copy personal data into fixtures — keep the format, drop the identity. - Everything the skill writes out (wiki content, commit messages, PR descriptions) stays Traditional Chinese per the STE100 rule. diff --git a/skills/maintain/SKILL.md b/skills/maintain/SKILL.md index 6083262..92404e3 100644 --- a/skills/maintain/SKILL.md +++ b/skills/maintain/SKILL.md @@ -1,6 +1,6 @@ --- 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 inside their maintenance window; not for projects still mid-implementation or not yet registered in MAINTAIN_CONTENTS. +description: SDLC maintenance stage. Gate on capability tags enforced in code by sdlc-gate (maintenance requires no specific tag, but the actual model id must be determinable from the transcript), 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 @@ -10,11 +10,11 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps -1. **Model gate and stage lock**: - 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. - 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. +1. **Model gate and stage lock** (capability tags, enforced in code — never self-assessed): + 1. Run `jsc-cli/tools/model-tags.sh sync` to refresh `$JSC_HOME/model-tags.tsv` from `jsc-cli/references/model-tags.md`. + 2. Run `jsc-hooks/hooks/sdlc-gate.sh lock maintain`. The script reads the **actual** model id from the transcript and checks it against this stage's required tags — maintenance requires no specific tag, so the gate passes as long as the actual model can be determined at all. + 3. **Never claim a capability tag you have not verified with that script**, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run `unlock` to get past the gate; only the user may decide that. + 4. Exit 0 means the stage is locked. Run this gate only when the stage changes; inside the maintenance stage the lock already covers every project, so never re-gate between projects. 2. Read `MAINTAIN_CONTENTS` via `jsc-gitea:wiki` and filter projects **still inside their maintenance window**: start date ≤ today, and (end date is NULL or ≥ today). 3. Every project **MUST run as a sub agent** with this flow: 1. Switch the project to the `develop` branch, falling back to `master`, and pull to latest. diff --git a/skills/plan/SKILL.md b/skills/plan/SKILL.md index 59d57d2..a2e1b59 100644 --- a/skills/plan/SKILL.md +++ b/skills/plan/SKILL.md @@ -1,6 +1,6 @@ --- name: plan -description: SDLC planning stage. Gate on the designated model (model-config) or capability tags, lock the model for the stage via sdlc-gate, pick or create a plan from PLAN_CONTENTS, then run a decision tree until goal, scope, and feasibility reach consensus. Produce user stories into wiki page PLAN_{HASH}. Logic only - never write code or modify files. Use when the user wants to start or refine a plan; not for analysis or implementation. +description: SDLC planning stage. Gate on capability tags enforced in code by sdlc-gate (plan requires reasoning-max, verified against the transcript's actual model id), pick or create a plan from PLAN_CONTENTS, then run a decision tree until goal, scope, and feasibility reach consensus. Produce user stories into wiki page PLAN_{HASH}. Logic only - never write code or modify files. Use when the user wants to start or refine a plan; not for analysis or implementation. --- # plan @@ -13,10 +13,11 @@ All wiki reads and writes go through `jsc-gitea:wiki`. ## Steps -1. **Model gate and stage lock**: - 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. - 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`. +1. **Model gate and stage lock** (capability tags, enforced in code — never self-assessed): + 1. Run `jsc-cli/tools/model-tags.sh sync` to refresh `$JSC_HOME/model-tags.tsv` from `jsc-cli/references/model-tags.md`. + 2. Run `jsc-hooks/hooks/sdlc-gate.sh lock plan`. The script reads the **actual** model id from the transcript, compares it against this stage's required tags (`reasoning-max`), and locks the stage only when they match. + 3. **Never claim a capability tag you have not verified with that script**, and never substitute your own judgement for its verdict. Non-zero exit = blocked: relay the script's message verbatim, stop the skill, do nothing else this turn. Do not run `unlock` to get past the gate; only the user may decide that. + 4. Exit 0 means the stage is locked. From now until the next stage's gate runs, the sdlc-gate hook blocks every prompt whose model stops satisfying the tags. 2. Read `PLAN_CONTENTS` via `jsc-gitea:wiki` and list the plans whose status is the literal 「未分析」 (not analyzed), with names and HASH. 3. Let the user choose per `jsc-ask:ask` rules: **extend an existing plan** (list the not-analyzed plans as options) or **create a new plan**. State the impact scope on every option. 4. Question via the `jsc-ask:ask` decision tree until no doubt remains on all three items; keep asking while consensus is missing: diff --git a/templates/analyze-page.md b/templates/analyze-page.md index a0639e8..3ea0e87 100644 --- a/templates/analyze-page.md +++ b/templates/analyze-page.md @@ -4,6 +4,7 @@ - HASH：`{HASH}` - 對應計畫：[[PLAN_{HASH}]] - 存取庫：`{owner}/{repo}` +- 來源分支：`{使用者確認的分支}`（head sha：`{sha}`） - 狀態：未完成 - 建立時間：{yyyy-MM-dd HH:mm:ss} @@ -15,12 +16,17 @@ ## 工作分解結構（WBS） -| 編號 | 工作包名稱 | 相依 | 工時(h) | 天數 | 工作證 | 狀態 | -| --- | --- | --- | --- | --- | --- | --- | -| WP-01 | {名稱} | - | {h} | {d} | | 未完成 | -| WP-02 | {名稱} | WP-01 | {h} | {d} | | 未完成 | +交接工作包（規格、介面、驗收條件）排在實作工作包之前；實作為候補。相依關係優先於交接排序。 +資料來源欄記錄範例資料的出處：`真實：{來源}` 或 `推論：無來源`。 -- 關鍵路徑：{WP-01 → WP-02 → ⋯⋯}，總天數 {d} +| 編號 | 工作包名稱 | 交接 | 相依 | 工時(h) | 天數 | 資料來源 | 工作證 | 狀態 | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | +| WP-01 | {規格類名稱} | 是 | - | {h} | {d} | 真實：{來源} | | 未完成 | +| WP-02 | {交接文件名稱} | 是 | WP-01 | {h} | {d} | 真實：{來源} | | 未完成 | +| WP-03 | {實作類名稱} | 否 | WP-01 | {h} | {d} | 推論：無來源 | | 未完成 | + +- 關鍵路徑：{WP-01 → WP-03 → ⋯⋯}，總天數 {d} +- 交接批次：{WP-01、WP-02}；實作候補：{WP-03、⋯⋯} ## 待辦事項（TDD） -- 2.53.0 From ef4cbc8f8890d7f23b0da74ed2adf8695b056365 Mon Sep 17 00:00:00 2001 From: Jeffery Date: Mon, 24 Aug 2026 16:05:19 +0800 Subject: [PATCH 2/3] =?UTF-8?q?docs(README):=20=E6=9B=B4=E6=96=B0=E9=9A=8E?= =?UTF-8?q?=E6=AE=B5=E9=96=98=E9=96=80=E5=88=A4=E5=AE=9A=E8=88=87=E5=88=86?= =?UTF-8?q?=E6=94=AF=E7=A2=BA=E8=AA=8D=E8=AA=AA=E6=98=8E?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 (1M context) --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 8961b8f..63532e7 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # jsc-sdlc — 開發生命週期 -jsc 技能組的 sdlc domain：規劃 → 分析 → 實作 → 維護四個階段，全程以 wiki 頁追蹤（`PLAN_CONTENTS`、`PLAN_{HASH}`、`ANALYZE_CONTENTS`、`ANALYZE_{HASH}`、`REPO_CONTENTS`、`REPO_{HASH}`、`MAINTAIN_CONTENTS`）。另有異常頁（`ERROR_CONTENTS`、`ERROR_{HASH}`）記錄 hook 或流程失敗。每次切換階段先解析該階段的指定模型鏈（`jsc-cli/tools/model-config.sh get {stage}`，專案 `.jsc/models` 優先於 `$JSC_HOME/models.conf`）；沒有設定才退回模型能力標籤檢查。通過閘門後由 `jsc-hooks` 的 sdlc-gate hook 鎖定模型，直到下一階段的閘門重新上鎖；同一階段內換模型會被擋下。 +jsc 技能組的 sdlc domain：規劃 → 分析 → 實作 → 維護四個階段，全程以 wiki 頁追蹤（`PLAN_CONTENTS`、`PLAN_{HASH}`、`ANALYZE_CONTENTS`、`ANALYZE_{HASH}`、`REPO_CONTENTS`、`REPO_{HASH}`、`MAINTAIN_CONTENTS`）。另有異常頁（`ERROR_CONTENTS`、`ERROR_{HASH}`）記錄 hook 或流程失敗。每次切換階段先過模型閘門：由 `jsc-hooks/hooks/sdlc-gate.sh lock {stage}` 從 transcript 讀出**實際**模型 id，比對該階段的必要能力標籤（plan、analyze 需 `reasoning-max`；implement 需 `coding`；maintain 任意），不符就拒絕上鎖、該階段不得執行。判定全在程式層，模型不得自評標籤。通過後鎖定到下一階段的閘門重新上鎖；同一階段內把模型換成不合格的，下一輪提示會被 hook 以 exit 2 擋下。分析前先與使用者確認來源分支，寫檔前先確認目標分支。 ## 安裝、更新、移除 @@ -59,7 +59,7 @@ HASH 規則：`{owner}/{repo}` 的共用 wiki hash 一律由 `jsc-gitea/tools/ha ## 相關 domain -- [`jsc-cli`](https://gitea.jsc.idv.tw/plugins/cli)：指定模型鏈（`tools/model-config.sh`）與模型能力標籤（`jsc-cli:models`） +- [`jsc-cli`](https://gitea.jsc.idv.tw/plugins/cli)：模型能力標籤與階段閘門判定（`tools/model-tags.sh`、`references/model-tags.md`、`jsc-cli:models`）、偏好模型鏈（`tools/model-config.sh`） - [`jsc-hooks`](https://gitea.jsc.idv.tw/plugins/hooks)：sdlc-gate 階段模型鎖定 - [`jsc-gitea`](https://gitea.jsc.idv.tw/plugins/gitea)：wiki 讀寫 - [`jsc-review`](https://gitea.jsc.idv.tw/plugins/review)：實作完成後的程式碼審查 -- 2.53.0 From 9a6ca0f9ee21bfe20b5fd873c2c4d3bdfd856d5f Mon Sep 17 00:00:00 2001 From: Jeffery Date: Mon, 24 Aug 2026 16:05:19 +0800 Subject: [PATCH 3/3] =?UTF-8?q?chore(plugin=20=E7=89=88=E6=9C=AC):=20?= =?UTF-8?q?=E4=B8=89=E4=BB=BD=20manifest=20=E5=8D=87=E7=89=88=E8=87=B3=200?= =?UTF-8?q?.0.5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 (1M context) --- .claude-plugin/plugin.json | 2 +- .codex-plugin/plugin.json | 2 +- plugin.json | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index 4a6d966..620cf13 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "jsc-sdlc", - "version": "0.0.4", + "version": "0.0.5", "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）", "skills": "./skills", "author": { diff --git a/.codex-plugin/plugin.json b/.codex-plugin/plugin.json index 039436f..73ee9a9 100644 --- a/.codex-plugin/plugin.json +++ b/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "jsc-sdlc", - "version": "0.0.4", + "version": "0.0.5", "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）", "skills": "./skills" } diff --git a/plugin.json b/plugin.json index a0ca998..f6ed278 100644 --- a/plugin.json +++ b/plugin.json @@ -1,6 +1,6 @@ { "name": "jsc-sdlc", - "version": "0.0.4", + "version": "0.0.5", "description": "開發生命週期：規劃/分析/實作/維護（wiki 追蹤）", "skills": "./skills/" } -- 2.53.0