@anhth2/spec-driven-dev-plugin 0.10.0 → 0.12.0

package/core/commands/propose-scenario.md

@@ -1,7 +1,8 @@
-# /propose-scenario — Propose a New BDD Scenario (Tester-Facing)
+# /propose-scenario — Propose a New BDD Scenario (Tester & QC-Facing)
 
-For **testers** who discover an edge case not covered by existing BDD. Drafts a Gherkin scenario
-into a **proposals area** for PO/Dev to review and promote.
+For **testers and QC** who discover an edge case not covered by existing BDD (e.g. a `DOC_GAPS`
+missing-coverage gap from `/qc-analyze`). Drafts a Gherkin scenario into a **proposals area** for
+PO/Dev to review and promote.
 
 **Does NOT edit the canonical `.feature` file.** BDD is owned by PO/Dev — this command only writes
 a proposal. Promotion into the real BDD is a PO/Dev action.
@@ -134,6 +135,8 @@ Read `.agent/project-context.yaml`. Extract and store:
 - `paths.specs_dir` → BDD specs root
 - `paths.prd_dir` → PRD documents root
 - `paths.refinement_dir` → findings/review output dir
+- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
+- `paths.qc_skills_dir` → where qc-* commands load QC skills from (default bundled `.agent/skills/qc`; override to the QC team's own repo/submodule so framework upgrade won't overwrite them)
 - `paths.product_definitions_dir` → product definitions root
 - `paths.domain_knowledge_dir` → domain knowledge root
 - `paths.business_dictionary` → path to business-dictionary.md
@@ -146,6 +149,8 @@ If `paths` section is absent, use these defaults:
 - `specs_dir` = `specs/bdd`
 - `prd_dir` = `specs/prd`
 - `refinement_dir` = `.agent/review`
+- `qc_dir` = `docs`
+- `qc_skills_dir` = `.agent/skills/qc`
 - `product_definitions_dir` = `specs/product-definition`
 - `domain_knowledge_dir` = `specs/domain-knowledge`
 - `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
@@ -190,6 +195,7 @@ If `services` section is present:
 - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
+- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
 
 > **Why under `spec_source`:** PRD, design-spec, domain knowledge, the **API contract (tech-docs)**, and tester feedback are all **cross-team artifacts** — they must live in the **shared spec repo** so every umbrella (FE/App/BE) reads the same source via `/sync`. Tech-docs specifically: BE authors the tech-design (API contract), commits + pushes it into the spec submodule (2-layer commit), and FE/App pull it on their next `/sync` to wire the real API in `/generate-code --phase=integration`. In single-service mode (no `spec_source`), these default under the repo root — still shared, same repo.
 
@@ -230,19 +236,41 @@ If the file does not exist → skip silently.
 
 ---
 
-## Step 3 — [CRITICAL] Load CLAUDE.md
+## Step 3 — [CRITICAL] Load CLAUDE.md (layered: root + service overlay)
 
 *This is the highest-priority context — it defines HOW to write code and documents for this project.*
 
-Read `CLAUDE.md`. Extract and store:
+CLAUDE.md is loaded in **two layers** so umbrella-wide rules and service-specific
+architecture/coding standards compose correctly. The agent always sits at the umbrella
+root, but the implementation code lives in a service submodule with its OWN stack,
+architecture, and conventions — so the service's CLAUDE.md must win for code generation.
+
+**Layer 1 — [BASE] Root CLAUDE.md (umbrella-wide).**
+Read `CLAUDE.md` at the repo root. Treat its contents as the **shared baseline** for the
+whole umbrella — git conventions, data-protection posture, cross-cutting rules, and (in
+single-service mode) the project's only architecture + coding standards.
+
+**Layer 2 — [OVERLAY] Service CLAUDE.md (umbrella mode only).**
+*Run only if `service_root` was set in Step 1.6 (i.e. a real service was routed to).*
+Read `{service_root}/CLAUDE.md`. This file defines the architecture + coding standards of
+the **actual stack being implemented** (e.g. `user-service` = java-spring, `web` = nextjs).
+Overlay it on top of Layer 1: **on any conflict, the service value WINS** for architecture,
+coding standards, and error handling. Layer-1 values that the service does not redefine
+(e.g. git conventions, banned patterns shared org-wide) remain in effect.
+
+From the **merged** result, extract and store:
 
 - **§1 Project Overview** → project name, language, framework, build/test commands, domains
-- **§2 Architecture** → layer order (e.g., Controller → Facade → Service → Repository), architectural rules
-- **§3 Coding Standards** → naming conventions (classes, methods), response wrapper type, forbidden patterns
-- **§5 Error Handling** → exception types, HTTP status code mapping, not-found exception class name
-- **§7 Git Conventions** → branch naming pattern, commit message format
+- **§2 Architecture** → layer order (e.g., Controller → Facade → Service → Repository), architectural rules — *service overlay wins*
+- **§3 Coding Standards** → naming conventions (classes, methods), response wrapper type, forbidden patterns — *service overlay wins*
+- **§5 Error Handling** → exception types, HTTP status code mapping, not-found exception class name — *service overlay wins*
+- **§7 Git Conventions** → branch naming pattern, commit message format — *root baseline unless service redefines*
 
-If `CLAUDE.md` does not exist → note it as missing and continue with project-context.yaml data only.
+**Resolution rules:**
+- If both layers exist → merge as above; record `claude_md_source = root + {service_root}`.
+- If only the service overlay exists (no root CLAUDE.md) → use the service file alone; `claude_md_source = {service_root}`.
+- If `service_root` is set but `{service_root}/CLAUDE.md` is **missing** → fall back to root CLAUDE.md and flag ⚠️ in the Step 7 recap (the service has no architecture/coding-standards definition — code generation will use umbrella defaults, which may be the wrong stack).
+- If neither exists → note CLAUDE.md as missing and continue with project-context.yaml data only.
 
 ---
 
@@ -342,7 +370,8 @@ Output exactly this block:
 [CTX LOADED]
 Stack     : {language} / {framework} / {database}
 Platform  : {active_module} ({platform_type})
-Layers    : {layer order from CLAUDE.md §2, e.g., Controller → Facade → Service → Repository}
+Layers    : {layer order from merged CLAUDE.md §2, e.g., Controller → Facade → Service → Repository}
+CLAUDE.md : {root + {service_root} | {service_root} only | root only | ⚠️ service overlay MISSING — using root | missing}
 Ticket    : {ticket_prefix}-
 Dict      : {loaded — N canonical terms, M banned terms | missing}
 Entities  : {loaded — EntityA, EntityB, EntityC | missing}
@@ -387,15 +416,28 @@ A BDD scenario must trace to a PRD acceptance criterion. Determine which case ap
 → This is a coverage gap. Proceed to draft the scenario (Step 3), mapped to that AC.
 
 **Case B — behavior is NOT in any AC** (genuinely new requirement):
-→ STOP. A scenario here would have nothing to trace to. Do **not** draft it as a BDD proposal.
-Instead output a **PRD change request** for the PO:
+→ Do **not** draft a BDD proposal (a scenario would have nothing to trace to). Instead **write a
+PRD change request file** so the PO actually sees it on `/sync` (do not just print it):
+
+Write to `{paths.prd_change_requests_dir}/{UC-ID}-{slug}.md` (resolved to
+`{spec_source}/feedback/prd-change-requests/` in umbrella mode; create dir if needed):
 ```
-⚠️ Not covered by any PRD AC — this is a new requirement, not a coverage gap.
-   Route to PO: add/extend an AC in {prd_path}, then re-run /generate-bdd.
-   Requested behavior: {description}
-   Suggested AC: "{draft AC text}"
+# PRD Change Request — {UC-ID}: {short title}
+
+> ⚠️ New requirement found in test — NOT covered by any PRD AC (not a coverage gap).
+| Field | Value |
+|---|---|
+| UC / Ticket | {UC-ID} |
+| PRD | {prd_path} (v{prd_version}) |
+| Source | {BUG-ID if any | tester/QC observation} |
+| Requested by | tester/QC |
+| Status | Open |
+
+**Requested behavior:** {description}
+**Suggested AC (draft for PO):** "{draft AC text}"
+**Route to PO:** add/extend an AC in {prd_path} → `/refine-prd` → re-run `/generate-bdd` → dev `/generate-code`.
 ```
-Then end (no proposal file written for BDD).
+Then go to Step 5 (handoff applies to this file too). Skip Step 3–4 (no BDD scenario for Case B).
 
 If unsure which case → show the AC list and ask the tester which AC this maps to, or confirm it's new.
 
@@ -424,7 +466,13 @@ git push                      # → PO/Dev see it on their next /sync
 ```
 
 - No push rights to the spec repo → open a PR / MR instead. Print this fallback.
-- For a **PRD change request** (Case B), the same handoff applies — commit the request doc so the PO sees it.
+- For a **PRD change request** (Case B), commit the request file instead:
+  ```bash
+  cd {spec_source}
+  git add feedback/prd-change-requests/{UC-ID}-{slug}.md
+  git commit -m "qa(prd-change): {UC-ID} — {title}"
+  git push
+  ```
 
 > PO/Dev are notified through their normal routine: `/sync` lists newly-pulled proposals.
 
@@ -468,6 +516,13 @@ Suggest the logical next command based on workflow phase:
 | /generate-design-spec   | Designer review → Figma links confirmed → PO + Designer sign-off → `/generate-bdd {prd-file}` |
 | /generate-bdd           | `/review-context {feature-file}` to verify coverage |
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` if APPROVED; regenerate if NEEDS_FIX |
+| /qc-analyze             | `/qc-plan {UC-ID}` (resolve 🔴 blocker gaps first) |
+| /qc-plan                | `/qc-design-test {UC-ID}`                     |
+| /qc-design-test         | `/qc-review {UC-ID}` (test-case review)       |
+| /qc-review (test-case)  | `/qc-run-test {UC-ID}` if APPROVED; fix TCs if NEEDS_FIX |
+| /qc-run-test            | `/qc-report {UC-ID}` then `/qc-review {UC-ID}` (script review) |
+| /qc-review (script)     | `/qc-report {UC-ID}` then create PR if APPROVED |
+| /qc-report              | `/validate-traces {UC-ID}` to refresh Living Docs (qc_status) |
 | /generate-tech-docs     | `/review-tech-docs {tech-design-file}`        |
 | /review-tech-docs       | `/generate-code {feature-file}` if APPROVED; fix doc if NEEDS_FIX |
 | /generate-code          | First gen → `/review-code {UC-ID}`; re-gen → `/dev-gen-test {UC-ID}` |