feat(交付與共識): 交付工作包獨立為 WP-01、新增交付內容型別與共識判定規則

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

skills/analyze/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: analyze
-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.
+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). Keep questioning until consensus per references/consensus.md, run WBS with the delivery/handover package as a standalone WP-01 that implementation packages depend on, 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
@@ -25,27 +25,28 @@ All wiki reads and writes go through `jsc-gitea:wiki`.
    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:
+5. Analyze the plan page's user stories one by one against the **current state**, **questioning until consensus** per `references/consensus.md` (the single authority for both planning and analysis): every answer produces the next question, and consensus needs both no output-changing unknown **and** the user's explicit confirmation. Never assume a missing detail, and never start the WBS while any item is still open. 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.
 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.
+7. **`WP-01` is always the delivery/handover work package** — see 「交付工作包最優先」 below. It stands alone, never merged into an implementation package, and every implementation package that consumes its spec depends on it.
 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）
+## 交付工作包最優先（delivery package is WP-01）
 
-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.
+A work package is a **delivery/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 delivery 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.
+- **`WP-01` is the delivery/handover package, always first, always standalone.** Pull every spec-shaped item out of the implementation packages and put it here. Never merge a spec into the package that implements it — merging removes the ability to hand the spec over early, which is the whole point.
+- **Implementation packages depend on `WP-01`** when they consume its spec, and they are the backup queue (實作候補): still numbered, still estimated, still on the page, just ranked after it.
+- Mark every work package as 交付 `是` / `否` in the WBS table, and record `WP-01`'s intended content type in the 交付型別 column when the user has already decided it (options in `references/deliver-formats.md`; the type is confirmed for real when `implement` starts that package).
+- Dependencies still win among the rest: never place a package before one it depends on. Within the same dependency level, delivery-shaped packages come first.
+- **When nothing is genuinely deliverable** (say, an internal refactor with no interface change), do not invent an empty `WP-01`: confirm with the user per `jsc-ask:ask` that this analysis has no handover output, then note the reason on the page and number the implementation packages from `WP-01`.
 
 ## 範例資料（sample data）
 
@@ -55,6 +56,7 @@ Every sample value on the analysis page — request and response payloads, field
 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.
+5. When `WP-01`'s content type is an API document, the required fields and the new-versus-existing parameter marking are defined in `references/deliver-formats.md`; follow it rather than inventing a layout.
 
 ## Hard limits