feat(SDLC 階段): 閘門改為能力標籤程式判定，分析與實作先確認分支，交接工作包優先
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Opus 5
+40
-14
@@ -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.
|
||||
|
||||
+19
-11
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -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）
|
||||
|
||||
|
||||
Reference in New Issue
Block a user