@anhth2/spec-driven-dev-plugin 0.11.0 → 0.14.0

package/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`
@@ -171,7 +176,7 @@ If `services` section is present:
 - If `$ARGUMENTS` contains a path, extract the segment after `prd_dir`
 
 **2. Route to service** — if active domain matches a key in `services`:
-- Override `paths.specs_dir` → `services.{domain}.specs_dir`
+- Override `paths.specs_dir` → `services.{domain}.specs_dir` — **only if `setup.spec_source` is NOT set.** When `spec_source` IS set, ALL BDD (web/app/**system**) is a shared cross-team artifact → leave `specs_dir` for step 4 to route to the spec repo; do NOT pin it per-service here.
 - Override `paths.tech_docs_dir` → `services.{domain}.tech_docs_dir` — **only if `setup.spec_source` is NOT set.** When `spec_source` IS set, the tech-design (API contract) is a cross-team artifact and must live in the shared spec repo (handled in step 4), so leave `tech_docs_dir` for step 4 to route — do NOT pin it per-service here.
 - Store `active_service` = `services.{domain}.path`
 - Store `active_service_module` = `services.{domain}.module`
@@ -182,6 +187,7 @@ If `services` section is present:
 - Set `active_service = unresolved`
 
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
+- Override `paths.specs_dir` → `{spec_source}/specs/bdd` — **always when `spec_source` is set.** All BDD (web/app/**system**) lives in the shared spec repo so every umbrella (FE/App/BE) reads the same scenarios; the FE tech-design gate + `/generate-code --phase=ui`/`--phase=integration` resolve the `system/` BDD here. *(Per-service `specs/bdd` only when there is no `spec_source`.)*
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
 - Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **always when `spec_source` is set** (step 2 no longer pins tech-docs per-service in this case). The tech-design IS the cross-team API contract: BE authors it here, and FE/App read it from the same spec submodule at `/generate-code --phase=integration`. *(Per-service tech-docs only happen when there is no `spec_source` — a pure multi-service BE repo with no shared spec module.)*
@@ -190,8 +196,10 @@ 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`
+- Override `paths.trace_dir` → `{spec_source}/.trace` — **always when `spec_source` is set.** Trace TSVs are consolidated in the spec repo (single authoritative location, no per-service split) so the PM/PO has one place to manage status. Code-side commands (`/generate-code`, `/dev-run-test`, `/qc-run-test`) run from `service_root` but **write their trace row into `{spec_source}/.trace`** — like they already push `feedback/` there. *(Per-service `.trace` only when there is no `spec_source`.)*
 
-> **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.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, **all BDD (web/app/system)**, the **API contract (tech-docs)**, tester feedback, **and the `.trace/` coverage state** are all **cross-team artifacts** — they live in the **shared spec repo** so every umbrella (FE/App/BE) and the PM read one source via `/sync`. The service submodule holds only **code** (+ build/test tooling). `.trace/` and `feedback/` are the dev/QC **write areas** in the spec repo (the PRD/BDD/design-spec/tech-docs there stay read-only for dev/QC — only PO edits those). In single-service mode (no `spec_source`), everything defaults under the repo root — still one repo.
 
 ---
 
@@ -211,12 +219,12 @@ When `active_service` has been resolved to a real path in Step 1.5 (e.g., `user-
 |----------|--------|
 | `conventions.test_command` | service's `conventions.test_command` |
 | `conventions.build_command` | service's `conventions.build_command` |
-| `paths.trace_dir` | `{active_service}/{service paths.trace_dir}` — default: `{active_service}/.trace` |
-| `paths.specs_dir` | `{active_service}/{service paths.specs_dir}` (if set in service config, else keep Step 1.5 override) |
+| `paths.trace_dir` | **If `spec_source` is set → keep the Step 4 spec-repo route (`{spec_source}/.trace`); ignore any service-level `trace_dir`.** Only when there is no `spec_source`: `{active_service}/{service paths.trace_dir}` (default `{active_service}/.trace`). |
+| `paths.specs_dir` | **If `spec_source` is set → keep the Step 4 spec-repo route (`{spec_source}/specs/bdd`); ignore any service-level `specs_dir`** (BDD is cross-team, never per-service in this mode). Only when there is no `spec_source`: `{active_service}/{service paths.specs_dir}` if set, else the Step 1.5 override. |
 
 **3. Store** `service_root = {active_service}` as the working directory anchor for all downstream commands:
 - Shell commands (`/dev-run-test`, `/dev-gen-test`) run **from within** `service_root`
-- File write operations (test files, trace TSVs) use paths **relative to** `service_root`
+- **Source/test files** are written relative to `service_root`; **trace TSVs** are written to `{paths.trace_dir}` (the spec repo when `spec_source` is set — a cross-repo write, committed/pushed to the spec submodule like `feedback/`).
 
 **4. If service config not found** — keep umbrella defaults, still set `service_root = {active_service}` (path anchor is always needed even without a config override).
 
@@ -410,15 +418,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.
 
@@ -447,7 +468,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.
 
@@ -477,6 +504,36 @@ Output Artifacts:
 
 If no files were written (e.g., review or analysis commands) → write `Output Artifacts: none (read-only)`.
 
+## Pipeline Position
+
+Print a one-line map of the pipeline with the CURRENT command's phase marked `◀ bạn ở đây`,
+so the user always sees where this command sits in the end-to-end flow:
+
+```
+Discovery → PRD → [Design Spec] → BDD → Tech Design → Code → Dev Self-Check → QC → Trace Audit
+```
+
+Find the current command in this phase legend and mark **its** phase in the map above:
+
+| Phase | Commands |
+|-------|----------|
+| Discovery | `/define-product` |
+| PRD | `/generate-prd` · `/refine-prd` · `/review-context` (PRD) |
+| Design Spec | `/generate-design-spec` |
+| BDD | `/generate-bdd` · `/review-context` (BDD) |
+| Tech Design | `/generate-tech-docs` · `/map-testids` · `/review-tech-docs` |
+| Code | `/generate-code` · `/review-code` |
+| Dev Self-Check | `/dev-gen-test` · `/dev-run-test` · `/dev-smoke-test` |
+| QC | `/qc-analyze` · `/qc-plan` · `/qc-design-test` · `/qc-review` · `/qc-run-test` · `/qc-report` |
+| Trace Audit | `/validate-traces` |
+
+For a **review command**, also append the 3-step review loop with the current step marked, e.g.:
+`Vòng review: [① phân tích ◀] → ② Review Board → ③ --resume`.
+
+**Cross-cutting commands** (`/sync`, `/update-framework`, `/fix-bug`, `/debug`, `/learn`,
+`/report-bug`, `/propose-scenario`, `/generate-spec-manifest`) sit outside the linear pipeline —
+**omit the Pipeline line entirely** for these (do not force-fit them onto the map).
+
 ## Next Command Suggestion
 
 Suggest the logical next command based on workflow phase:
@@ -518,10 +575,13 @@ Suggest the logical next command based on workflow phase:
 Format the footer as:
 ```
 ---
-Status : {badge}
+Status   : {badge}
 {Output Artifacts block}
-Next   : {suggested command with example arguments}
+Pipeline : Discovery → PRD → [BDD ◀ bạn ở đây] → Tech Design → Code → Dev Self-Check → QC → Trace Audit
+           (review cmd) Vòng review: [① phân tích ◀] → ② Review Board → ③ --resume
+Next     : {suggested command with example arguments}
 ```
+*(Omit the `Pipeline` line for cross-cutting commands listed above.)*
 
 
 ```

package/commands/propose-scenario.tmpl

@@ -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.
@@ -34,15 +35,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.
 
@@ -71,7 +85,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.
 

package/commands/qc-analyze.md

@@ -133,6 +133,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
@@ -145,6 +147,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`
@@ -170,7 +174,7 @@ If `services` section is present:
 - If `$ARGUMENTS` contains a path, extract the segment after `prd_dir`
 
 **2. Route to service** — if active domain matches a key in `services`:
-- Override `paths.specs_dir` → `services.{domain}.specs_dir`
+- Override `paths.specs_dir` → `services.{domain}.specs_dir` — **only if `setup.spec_source` is NOT set.** When `spec_source` IS set, ALL BDD (web/app/**system**) is a shared cross-team artifact → leave `specs_dir` for step 4 to route to the spec repo; do NOT pin it per-service here.
 - Override `paths.tech_docs_dir` → `services.{domain}.tech_docs_dir` — **only if `setup.spec_source` is NOT set.** When `spec_source` IS set, the tech-design (API contract) is a cross-team artifact and must live in the shared spec repo (handled in step 4), so leave `tech_docs_dir` for step 4 to route — do NOT pin it per-service here.
 - Store `active_service` = `services.{domain}.path`
 - Store `active_service_module` = `services.{domain}.module`
@@ -181,6 +185,7 @@ If `services` section is present:
 - Set `active_service = unresolved`
 
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
+- Override `paths.specs_dir` → `{spec_source}/specs/bdd` — **always when `spec_source` is set.** All BDD (web/app/**system**) lives in the shared spec repo so every umbrella (FE/App/BE) reads the same scenarios; the FE tech-design gate + `/generate-code --phase=ui`/`--phase=integration` resolve the `system/` BDD here. *(Per-service `specs/bdd` only when there is no `spec_source`.)*
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
 - Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **always when `spec_source` is set** (step 2 no longer pins tech-docs per-service in this case). The tech-design IS the cross-team API contract: BE authors it here, and FE/App read it from the same spec submodule at `/generate-code --phase=integration`. *(Per-service tech-docs only happen when there is no `spec_source` — a pure multi-service BE repo with no shared spec module.)*
@@ -189,8 +194,10 @@ 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`
+- Override `paths.trace_dir` → `{spec_source}/.trace` — **always when `spec_source` is set.** Trace TSVs are consolidated in the spec repo (single authoritative location, no per-service split) so the PM/PO has one place to manage status. Code-side commands (`/generate-code`, `/dev-run-test`, `/qc-run-test`) run from `service_root` but **write their trace row into `{spec_source}/.trace`** — like they already push `feedback/` there. *(Per-service `.trace` only when there is no `spec_source`.)*
 
-> **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.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, **all BDD (web/app/system)**, the **API contract (tech-docs)**, tester feedback, **and the `.trace/` coverage state** are all **cross-team artifacts** — they live in the **shared spec repo** so every umbrella (FE/App/BE) and the PM read one source via `/sync`. The service submodule holds only **code** (+ build/test tooling). `.trace/` and `feedback/` are the dev/QC **write areas** in the spec repo (the PRD/BDD/design-spec/tech-docs there stay read-only for dev/QC — only PO edits those). In single-service mode (no `spec_source`), everything defaults under the repo root — still one repo.
 
 ---
 
@@ -210,12 +217,12 @@ When `active_service` has been resolved to a real path in Step 1.5 (e.g., `user-
 |----------|--------|
 | `conventions.test_command` | service's `conventions.test_command` |
 | `conventions.build_command` | service's `conventions.build_command` |
-| `paths.trace_dir` | `{active_service}/{service paths.trace_dir}` — default: `{active_service}/.trace` |
-| `paths.specs_dir` | `{active_service}/{service paths.specs_dir}` (if set in service config, else keep Step 1.5 override) |
+| `paths.trace_dir` | **If `spec_source` is set → keep the Step 4 spec-repo route (`{spec_source}/.trace`); ignore any service-level `trace_dir`.** Only when there is no `spec_source`: `{active_service}/{service paths.trace_dir}` (default `{active_service}/.trace`). |
+| `paths.specs_dir` | **If `spec_source` is set → keep the Step 4 spec-repo route (`{spec_source}/specs/bdd`); ignore any service-level `specs_dir`** (BDD is cross-team, never per-service in this mode). Only when there is no `spec_source`: `{active_service}/{service paths.specs_dir}` if set, else the Step 1.5 override. |
 
 **3. Store** `service_root = {active_service}` as the working directory anchor for all downstream commands:
 - Shell commands (`/dev-run-test`, `/dev-gen-test`) run **from within** `service_root`
-- File write operations (test files, trace TSVs) use paths **relative to** `service_root`
+- **Source/test files** are written relative to `service_root`; **trace TSVs** are written to `{paths.trace_dir}` (the spec repo when `spec_source` is set — a cross-repo write, committed/pushed to the spec submodule like `feedback/`).
 
 **4. If service config not found** — keep umbrella defaults, still set `service_root = {active_service}` (path anchor is always needed even without a config override).
 
@@ -405,7 +412,7 @@ Boundary vs `/qc-plan`: you answer *"what is the requirement?"*; qc-plan answers
 the risk, what to ask dev?"*. When something is ambiguous/missing, record it as a gap and
 hand off to qc-plan — never invent an answer.
 
-## Skills (`skills/qc/qa-analyst/`)
+## Skills (`{paths.qc_skills_dir}/qa-analyst/`)
 
 Load only the file for the step you are doing (each is self-contained):
 - `spec-breakdown.md` — break a spec/PRD/user story into structure.
@@ -424,15 +431,29 @@ tests with `@trace.verifies` and write `qc_status` per scenario.
 
 ## DOC_GAPS (mandatory)
 
-Always produce a gaps file following `skills/qc/qa-analyst/DOC_GAPS.template.md`:
+Always produce a gaps file following `{paths.qc_skills_dir}/qa-analyst/DOC_GAPS.template.md`:
 - Each gap `GAP-xx`, classified MISSING / AMBIGUOUS / CONTRADICTORY / ASSUMPTION / OPEN QUESTION, with severity (🔴 Blocker → 🟢 Low) and the affected function/BR/AC.
 - Never fabricate answers; mark assumptions as `ASSUMPTION` for PO/dev to confirm.
 - Any `🔴 Blocker` still `Open` ⇒ the UC is not ready for qc-design-test — hand off to qc-plan.
+- **Push genuine SPEC defects to the PO (not just keep them local).** A blocker that is a real
+  flaw in the official spec — `AMBIGUOUS` / `CONTRADICTORY` / `MISSING` in PRD/BDD — must reach
+  the PO via the feedback flow, not sit only in `DOC_GAPS.md`: file `/report-bug {UC-ID} {desc}`
+  (its BUG_FLOW classifies PRD vs BDD), or `/propose-scenario {UC-ID}` if the gap is missing test
+  coverage. `ASSUMPTION` / `OPEN QUESTION` gaps are confirmed via qc-plan's questions-for-dev — not filed as bugs.
 
 ## Output
 
-Write the analysis artifacts under `{paths.refinement_dir}/qc/{UC-ID}/` (requirement
-breakdown, BR table, data-flow, AC list with SC mapping, and `DOC_GAPS.md`).
+Write **exactly TWO files** under `{paths.qc_dir}/{UC-ID}/` — do **not** split the analysis
+into one-file-per-step (no separate spec-breakdown / business-rules / data-flow / AC files):
+
+1. **`{paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.md`** — the single consolidated analysis.
+   Sections in order: requirement breakdown → business-rule table (`BR-xx`) → data-flow →
+   acceptance-criteria (`AC-xx`), each `BR`/`AC` mapped to its owning `{UC-ID}-SC{N}`.
+2. **`{paths.qc_dir}/{UC-ID}/DOC_GAPS.md`** — the gaps file (per `{paths.qc_skills_dir}/qa-analyst/DOC_GAPS.template.md`).
+
+`{paths.qc_dir}` is a VISIBLE top-level folder in the QC repo (default `docs/`, **not** the
+hidden `.agent/review/`) so the QC team can open and process the output easily. The official
+spec stays in the PO spec submodule — do not write analysis there.
 
 ## Report
 
@@ -458,6 +479,36 @@ Output Artifacts:
 
 If no files were written (e.g., review or analysis commands) → write `Output Artifacts: none (read-only)`.
 
+## Pipeline Position
+
+Print a one-line map of the pipeline with the CURRENT command's phase marked `◀ bạn ở đây`,
+so the user always sees where this command sits in the end-to-end flow:
+
+```
+Discovery → PRD → [Design Spec] → BDD → Tech Design → Code → Dev Self-Check → QC → Trace Audit
+```
+
+Find the current command in this phase legend and mark **its** phase in the map above:
+
+| Phase | Commands |
+|-------|----------|
+| Discovery | `/define-product` |
+| PRD | `/generate-prd` · `/refine-prd` · `/review-context` (PRD) |
+| Design Spec | `/generate-design-spec` |
+| BDD | `/generate-bdd` · `/review-context` (BDD) |
+| Tech Design | `/generate-tech-docs` · `/map-testids` · `/review-tech-docs` |
+| Code | `/generate-code` · `/review-code` |
+| Dev Self-Check | `/dev-gen-test` · `/dev-run-test` · `/dev-smoke-test` |
+| QC | `/qc-analyze` · `/qc-plan` · `/qc-design-test` · `/qc-review` · `/qc-run-test` · `/qc-report` |
+| Trace Audit | `/validate-traces` |
+
+For a **review command**, also append the 3-step review loop with the current step marked, e.g.:
+`Vòng review: [① phân tích ◀] → ② Review Board → ③ --resume`.
+
+**Cross-cutting commands** (`/sync`, `/update-framework`, `/fix-bug`, `/debug`, `/learn`,
+`/report-bug`, `/propose-scenario`, `/generate-spec-manifest`) sit outside the linear pipeline —
+**omit the Pipeline line entirely** for these (do not force-fit them onto the map).
+
 ## Next Command Suggestion
 
 Suggest the logical next command based on workflow phase:
@@ -499,15 +550,19 @@ Suggest the logical next command based on workflow phase:
 Format the footer as:
 ```
 ---
-Status : {badge}
+Status   : {badge}
 {Output Artifacts block}
-Next   : {suggested command with example arguments}
+Pipeline : Discovery → PRD → [BDD ◀ bạn ở đây] → Tech Design → Code → Dev Self-Check → QC → Trace Audit
+           (review cmd) Vòng review: [① phân tích ◀] → ② Review Board → ③ --resume
+Next     : {suggested command with example arguments}
 ```
+*(Omit the `Pipeline` line for cross-cutting commands listed above.)*
 
 
 ```
 /qc-analyze Complete — {UC-ID}
-Gaps: {N} ({blockers} blocker)
+Files: {paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.md + DOC_GAPS.md   (2 files)
+Gaps: {N} ({blockers} blocker)   ← spec-defect blocker? → /report-bug {UC-ID}  | coverage gap → /propose-scenario {UC-ID}
 SC mapping: {M} BR/AC mapped to {K} scenarios
 Next: /qc-plan {UC-ID}   ← risk / what-if / questions-for-dev
       (resolve 🔴 Blocker gaps with PO/Dev first)

package/commands/qc-analyze.tmpl

@@ -29,7 +29,7 @@ Boundary vs `/qc-plan`: you answer *"what is the requirement?"*; qc-plan answers
 the risk, what to ask dev?"*. When something is ambiguous/missing, record it as a gap and
 hand off to qc-plan — never invent an answer.
 
-## Skills (`skills/qc/qa-analyst/`)
+## Skills (`{paths.qc_skills_dir}/qa-analyst/`)
 
 Load only the file for the step you are doing (each is self-contained):
 - `spec-breakdown.md` — break a spec/PRD/user story into structure.
@@ -48,15 +48,29 @@ tests with `@trace.verifies` and write `qc_status` per scenario.
 
 ## DOC_GAPS (mandatory)
 
-Always produce a gaps file following `skills/qc/qa-analyst/DOC_GAPS.template.md`:
+Always produce a gaps file following `{paths.qc_skills_dir}/qa-analyst/DOC_GAPS.template.md`:
 - Each gap `GAP-xx`, classified MISSING / AMBIGUOUS / CONTRADICTORY / ASSUMPTION / OPEN QUESTION, with severity (🔴 Blocker → 🟢 Low) and the affected function/BR/AC.
 - Never fabricate answers; mark assumptions as `ASSUMPTION` for PO/dev to confirm.
 - Any `🔴 Blocker` still `Open` ⇒ the UC is not ready for qc-design-test — hand off to qc-plan.
+- **Push genuine SPEC defects to the PO (not just keep them local).** A blocker that is a real
+  flaw in the official spec — `AMBIGUOUS` / `CONTRADICTORY` / `MISSING` in PRD/BDD — must reach
+  the PO via the feedback flow, not sit only in `DOC_GAPS.md`: file `/report-bug {UC-ID} {desc}`
+  (its BUG_FLOW classifies PRD vs BDD), or `/propose-scenario {UC-ID}` if the gap is missing test
+  coverage. `ASSUMPTION` / `OPEN QUESTION` gaps are confirmed via qc-plan's questions-for-dev — not filed as bugs.
 
 ## Output
 
-Write the analysis artifacts under `{paths.refinement_dir}/qc/{UC-ID}/` (requirement
-breakdown, BR table, data-flow, AC list with SC mapping, and `DOC_GAPS.md`).
+Write **exactly TWO files** under `{paths.qc_dir}/{UC-ID}/` — do **not** split the analysis
+into one-file-per-step (no separate spec-breakdown / business-rules / data-flow / AC files):
+
+1. **`{paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.md`** — the single consolidated analysis.
+   Sections in order: requirement breakdown → business-rule table (`BR-xx`) → data-flow →
+   acceptance-criteria (`AC-xx`), each `BR`/`AC` mapped to its owning `{UC-ID}-SC{N}`.
+2. **`{paths.qc_dir}/{UC-ID}/DOC_GAPS.md`** — the gaps file (per `{paths.qc_skills_dir}/qa-analyst/DOC_GAPS.template.md`).
+
+`{paths.qc_dir}` is a VISIBLE top-level folder in the QC repo (default `docs/`, **not** the
+hidden `.agent/review/`) so the QC team can open and process the output easily. The official
+spec stays in the PO spec submodule — do not write analysis there.
 
 ## Report
 
@@ -64,7 +78,8 @@ breakdown, BR table, data-flow, AC list with SC mapping, and `DOC_GAPS.md`).
 
 ```
 /qc-analyze Complete — {UC-ID}
-Gaps: {N} ({blockers} blocker)
+Files: {paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.md + DOC_GAPS.md   (2 files)
+Gaps: {N} ({blockers} blocker)   ← spec-defect blocker? → /report-bug {UC-ID}  | coverage gap → /propose-scenario {UC-ID}
 SC mapping: {M} BR/AC mapped to {K} scenarios
 Next: /qc-plan {UC-ID}   ← risk / what-if / questions-for-dev
       (resolve 🔴 Blocker gaps with PO/Dev first)

package/commands/qc-design-test.md

@@ -92,7 +92,7 @@ Wait for explicit "Y" or "N" from the user before continuing.
 - "N" → stop and ask what the user wants to change.
 
 
-*Note: For this command, the target in Step 1 is a UC-ID. Read the qc-analyze + qc-plan outputs from `{paths.refinement_dir}/qc/{UC-ID}/` and the official `.feature` (with `@trace.scenario` per scenario).*
+*Note: For this command, the target in Step 1 is a UC-ID. Read the qc-analyze + qc-plan outputs (`REQUIREMENT_ANALYSIS.md`, `DOC_GAPS.md`, `TEST_PLAN.md`) from `{paths.qc_dir}/{UC-ID}/` and the official `.feature` (with `@trace.scenario` per scenario). For GUI layers, also read the FE tech-design §2b **Test Selectors** table at `{paths.tech_docs_dir}/{domain}/{UC-ID}-tech-design-{platform}.md` (if present) — the stable test-ids QC will locate by.*
 
 ## Context
 # Context Loader — Load All Project Context
@@ -133,6 +133,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
@@ -145,6 +147,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`
@@ -170,7 +174,7 @@ If `services` section is present:
 - If `$ARGUMENTS` contains a path, extract the segment after `prd_dir`
 
 **2. Route to service** — if active domain matches a key in `services`:
-- Override `paths.specs_dir` → `services.{domain}.specs_dir`
+- Override `paths.specs_dir` → `services.{domain}.specs_dir` — **only if `setup.spec_source` is NOT set.** When `spec_source` IS set, ALL BDD (web/app/**system**) is a shared cross-team artifact → leave `specs_dir` for step 4 to route to the spec repo; do NOT pin it per-service here.
 - Override `paths.tech_docs_dir` → `services.{domain}.tech_docs_dir` — **only if `setup.spec_source` is NOT set.** When `spec_source` IS set, the tech-design (API contract) is a cross-team artifact and must live in the shared spec repo (handled in step 4), so leave `tech_docs_dir` for step 4 to route — do NOT pin it per-service here.
 - Store `active_service` = `services.{domain}.path`
 - Store `active_service_module` = `services.{domain}.module`
@@ -181,6 +185,7 @@ If `services` section is present:
 - Set `active_service = unresolved`
 
 **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
+- Override `paths.specs_dir` → `{spec_source}/specs/bdd` — **always when `spec_source` is set.** All BDD (web/app/**system**) lives in the shared spec repo so every umbrella (FE/App/BE) reads the same scenarios; the FE tech-design gate + `/generate-code --phase=ui`/`--phase=integration` resolve the `system/` BDD here. *(Per-service `specs/bdd` only when there is no `spec_source`.)*
 - Override `paths.prd_dir` → `{spec_source}/specs/prd`
 - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
 - Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **always when `spec_source` is set** (step 2 no longer pins tech-docs per-service in this case). The tech-design IS the cross-team API contract: BE authors it here, and FE/App read it from the same spec submodule at `/generate-code --phase=integration`. *(Per-service tech-docs only happen when there is no `spec_source` — a pure multi-service BE repo with no shared spec module.)*
@@ -189,8 +194,10 @@ 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`
+- Override `paths.trace_dir` → `{spec_source}/.trace` — **always when `spec_source` is set.** Trace TSVs are consolidated in the spec repo (single authoritative location, no per-service split) so the PM/PO has one place to manage status. Code-side commands (`/generate-code`, `/dev-run-test`, `/qc-run-test`) run from `service_root` but **write their trace row into `{spec_source}/.trace`** — like they already push `feedback/` there. *(Per-service `.trace` only when there is no `spec_source`.)*
 
-> **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.
+> **Why under `spec_source`:** PRD, design-spec, domain knowledge, **all BDD (web/app/system)**, the **API contract (tech-docs)**, tester feedback, **and the `.trace/` coverage state** are all **cross-team artifacts** — they live in the **shared spec repo** so every umbrella (FE/App/BE) and the PM read one source via `/sync`. The service submodule holds only **code** (+ build/test tooling). `.trace/` and `feedback/` are the dev/QC **write areas** in the spec repo (the PRD/BDD/design-spec/tech-docs there stay read-only for dev/QC — only PO edits those). In single-service mode (no `spec_source`), everything defaults under the repo root — still one repo.
 
 ---
 
@@ -210,12 +217,12 @@ When `active_service` has been resolved to a real path in Step 1.5 (e.g., `user-
 |----------|--------|
 | `conventions.test_command` | service's `conventions.test_command` |
 | `conventions.build_command` | service's `conventions.build_command` |
-| `paths.trace_dir` | `{active_service}/{service paths.trace_dir}` — default: `{active_service}/.trace` |
-| `paths.specs_dir` | `{active_service}/{service paths.specs_dir}` (if set in service config, else keep Step 1.5 override) |
+| `paths.trace_dir` | **If `spec_source` is set → keep the Step 4 spec-repo route (`{spec_source}/.trace`); ignore any service-level `trace_dir`.** Only when there is no `spec_source`: `{active_service}/{service paths.trace_dir}` (default `{active_service}/.trace`). |
+| `paths.specs_dir` | **If `spec_source` is set → keep the Step 4 spec-repo route (`{spec_source}/specs/bdd`); ignore any service-level `specs_dir`** (BDD is cross-team, never per-service in this mode). Only when there is no `spec_source`: `{active_service}/{service paths.specs_dir}` if set, else the Step 1.5 override. |
 
 **3. Store** `service_root = {active_service}` as the working directory anchor for all downstream commands:
 - Shell commands (`/dev-run-test`, `/dev-gen-test`) run **from within** `service_root`
-- File write operations (test files, trace TSVs) use paths **relative to** `service_root`
+- **Source/test files** are written relative to `service_root`; **trace TSVs** are written to `{paths.trace_dir}` (the spec repo when `spec_source` is set — a cross-repo write, committed/pushed to the spec submodule like `feedback/`).
 
 **4. If service config not found** — keep umbrella defaults, still set `service_root = {active_service}` (path anchor is always needed even without a config override).
 
@@ -400,7 +407,7 @@ You are the **QC Designer** — stage 3. Produce/maintain test-case Markdown fil
 (`.Test.md`) from the analyzed requirement + plan. Output feeds qc-run-test (Python) and
 qc-review. You do **not** write Python.
 
-## Skills — pick the layer, load ONE file (`skills/qc/qa-designer/`)
+## Skills — pick the layer, load ONE file (`{paths.qc_skills_dir}/qa-designer/`)
 
 | Layer | File |
 |---|---|
@@ -418,6 +425,7 @@ qc-review. You do **not** write Python.
 - TC ID `TC_<FEATURE>_<NNN>`; split happy/negative; one assertion concern per TC; concrete expected values.
 - Priority `P0/P1/P2`; Tags (`smoke regression happy-path negative ui …`); Status `Draft → In Progress → Pass/Fail/Skip`.
 - A TC blocked by a gap is still written + marked `🚫 Block: GAP-xx`.
+- **Reference test-ids, not visual cues.** For each GUI step that acts on an element, cite the stable test-id from the FE tech-design §2b table (e.g. "click `ft001-login-submit-btn`") so qc-run-test builds the locator from the contract. If an actionable element has no test-id in §2b, note it (qc-run-test will fall back to a slower role/text locator).
 - End-of-file: Trace matrix + blocked-TC table.
 
 ## Trace mapping (mandatory)
@@ -429,7 +437,7 @@ qc-run-test write `qc_status` per scenario.
 
 ## Output
 
-Write `.Test.md` files under `{paths.refinement_dir}/qc/{UC-ID}/test-cases/`.
+Write `.Test.md` files under `{paths.qc_dir}/{UC-ID}/test-cases/`.
 
 ## Report
 
@@ -455,6 +463,36 @@ Output Artifacts:
 
 If no files were written (e.g., review or analysis commands) → write `Output Artifacts: none (read-only)`.
 
+## Pipeline Position
+
+Print a one-line map of the pipeline with the CURRENT command's phase marked `◀ bạn ở đây`,
+so the user always sees where this command sits in the end-to-end flow:
+
+```
+Discovery → PRD → [Design Spec] → BDD → Tech Design → Code → Dev Self-Check → QC → Trace Audit
+```
+
+Find the current command in this phase legend and mark **its** phase in the map above:
+
+| Phase | Commands |
+|-------|----------|
+| Discovery | `/define-product` |
+| PRD | `/generate-prd` · `/refine-prd` · `/review-context` (PRD) |
+| Design Spec | `/generate-design-spec` |
+| BDD | `/generate-bdd` · `/review-context` (BDD) |
+| Tech Design | `/generate-tech-docs` · `/map-testids` · `/review-tech-docs` |
+| Code | `/generate-code` · `/review-code` |
+| Dev Self-Check | `/dev-gen-test` · `/dev-run-test` · `/dev-smoke-test` |
+| QC | `/qc-analyze` · `/qc-plan` · `/qc-design-test` · `/qc-review` · `/qc-run-test` · `/qc-report` |
+| Trace Audit | `/validate-traces` |
+
+For a **review command**, also append the 3-step review loop with the current step marked, e.g.:
+`Vòng review: [① phân tích ◀] → ② Review Board → ③ --resume`.
+
+**Cross-cutting commands** (`/sync`, `/update-framework`, `/fix-bug`, `/debug`, `/learn`,
+`/report-bug`, `/propose-scenario`, `/generate-spec-manifest`) sit outside the linear pipeline —
+**omit the Pipeline line entirely** for these (do not force-fit them onto the map).
+
 ## Next Command Suggestion
 
 Suggest the logical next command based on workflow phase:
@@ -496,10 +534,13 @@ Suggest the logical next command based on workflow phase:
 Format the footer as:
 ```
 ---
-Status : {badge}
+Status   : {badge}
 {Output Artifacts block}
-Next   : {suggested command with example arguments}
+Pipeline : Discovery → PRD → [BDD ◀ bạn ở đây] → Tech Design → Code → Dev Self-Check → QC → Trace Audit
+           (review cmd) Vòng review: [① phân tích ◀] → ② Review Board → ③ --resume
+Next     : {suggested command with example arguments}
 ```
+*(Omit the `Pipeline` line for cross-cutting commands listed above.)*
 
 
 ```