@anhth2/spec-driven-dev-plugin 0.11.0 → 0.12.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/commands/debug.md +5 -0
- package/commands/define-product.md +5 -0
- package/commands/dev-gen-test.md +5 -0
- package/commands/dev-run-test.md +5 -0
- package/commands/dev-smoke-test.md +5 -0
- package/commands/fix-bug.md +41 -6
- package/commands/fix-bug.tmpl +36 -6
- package/commands/generate-bdd.md +9 -2
- package/commands/generate-bdd.tmpl +4 -2
- package/commands/generate-code.md +5 -0
- package/commands/generate-design-spec.md +5 -0
- package/commands/generate-prd.md +5 -0
- package/commands/generate-spec-manifest.md +5 -0
- package/commands/generate-tech-docs.md +5 -0
- package/commands/learn.md +5 -0
- package/commands/propose-scenario.md +36 -11
- package/commands/propose-scenario.tmpl +31 -11
- package/commands/qc-analyze.md +25 -5
- package/commands/qc-analyze.tmpl +20 -5
- package/commands/qc-design-test.md +8 -3
- package/commands/qc-design-test.tmpl +3 -3
- package/commands/qc-plan.md +8 -3
- package/commands/qc-plan.tmpl +3 -3
- package/commands/qc-report.md +18 -1
- package/commands/qc-report.tmpl +13 -1
- package/commands/qc-review.md +7 -2
- package/commands/qc-review.tmpl +2 -2
- package/commands/qc-run-test.md +13 -2
- package/commands/qc-run-test.tmpl +8 -2
- package/commands/refine-prd.md +5 -0
- package/commands/report-bug.md +21 -2
- package/commands/report-bug.tmpl +16 -2
- package/commands/review-code.md +5 -0
- package/commands/review-context.md +5 -0
- package/commands/review-tech-docs.md +5 -0
- package/commands/sync.md +12 -9
- package/commands/sync.tmpl +12 -9
- package/commands/validate-traces.md +15 -2
- package/commands/validate-traces.tmpl +10 -2
- package/core/FRAMEWORK_VERSION +1 -1
- package/core/commands/debug.md +5 -0
- package/core/commands/define-product.md +5 -0
- package/core/commands/dev-gen-test.md +5 -0
- package/core/commands/dev-run-test.md +5 -0
- package/core/commands/dev-smoke-test.md +5 -0
- package/core/commands/fix-bug.md +41 -6
- package/core/commands/generate-bdd.md +9 -2
- package/core/commands/generate-code.md +5 -0
- package/core/commands/generate-design-spec.md +5 -0
- package/core/commands/generate-prd.md +5 -0
- package/core/commands/generate-spec-manifest.md +5 -0
- package/core/commands/generate-tech-docs.md +5 -0
- package/core/commands/learn.md +5 -0
- package/core/commands/propose-scenario.md +36 -11
- package/core/commands/qc-analyze.md +25 -5
- package/core/commands/qc-design-test.md +8 -3
- package/core/commands/qc-plan.md +8 -3
- package/core/commands/qc-report.md +18 -1
- package/core/commands/qc-review.md +7 -2
- package/core/commands/qc-run-test.md +13 -2
- package/core/commands/refine-prd.md +5 -0
- package/core/commands/report-bug.md +21 -2
- package/core/commands/review-code.md +5 -0
- package/core/commands/review-context.md +5 -0
- package/core/commands/review-tech-docs.md +5 -0
- package/core/commands/sync.md +12 -9
- package/core/commands/validate-traces.md +15 -2
- package/core/modules/qc-playwright/stack-profile.yaml +3 -3
- package/core/skills/code/SKILL.md +5 -0
- package/core/skills/debug/SKILL.md +5 -0
- package/core/skills/design-spec/SKILL.md +5 -0
- package/core/skills/discovery/SKILL.md +5 -0
- package/core/skills/qc/qa-analyst/acceptance-criteria.md +5 -1
- package/core/skills/qc/qa-analyst/business-rules.md +6 -2
- package/core/skills/qc/qa-analyst/data-flow.md +6 -2
- package/core/skills/qc/qa-analyst/spec-breakdown.md +7 -3
- package/core/skills/qc/qa-designer/e2e/journey.md +1 -1
- package/core/skills/qc/qa-designer/exploratory/charter.md +2 -2
- package/core/skills/qc/qa-designer/exploratory/explore-to-functional.md +1 -1
- package/core/skills/qc/qa-designer/functional/api.md +1 -1
- package/core/skills/qc/qa-designer/functional/gui-feature.md +1 -1
- package/core/skills/qc/qa-designer/functional/gui-screen.md +1 -1
- package/core/skills/qc/qa-designer/integration/api.md +1 -1
- package/core/skills/qc/qa-designer/integration/db.md +1 -1
- package/core/skills/qc/qa-designer/integration/gui.md +1 -1
- package/core/skills/qc/qa-designer/integration/kafka.md +1 -1
- package/core/skills/qc/qa-designer/non-functional.md +1 -1
- package/core/skills/qc/qa-planner/test-plan.md +4 -4
- package/core/skills/qc/qa-runner/exploratory/session.md +2 -2
- package/core/skills/test/SKILL.md +10 -0
- package/core/steps/context-loader.md +5 -0
- package/core/templates/project-context.yaml +19 -1
- package/docs/01-getting-started/installation.md +3 -1
- package/docs/02-guides/developer/commands.md +1 -1
- package/docs/02-guides/developer/workflow.md +2 -0
- package/docs/02-guides/qc-automation.md +66 -1
- package/docs/02-guides/tester/README.md +2 -0
- package/docs/02-guides/tester/bug-reporting.md +1 -1
- package/docs/02-guides/tester/workflow.md +4 -3
- package/docs/03-concepts/architecture.md +2 -0
- package/docs/03-concepts/pipeline.md +19 -6
- package/docs/03-concepts/traceability.md +2 -1
- package/docs/04-operations/bug-flow.md +45 -4
- package/docs/04-operations/sync-and-update.md +38 -1
- package/docs/05-reference/commands.md +11 -11
- package/docs/05-reference/modules.md +2 -2
- package/docs/05-reference/trace-schema.md +18 -12
- package/modules/qc-playwright/stack-profile.yaml +3 -3
- package/package.json +1 -1
- package/skills/code/SKILL.md +5 -0
- package/skills/debug/SKILL.md +5 -0
- package/skills/design-spec/SKILL.md +5 -0
- package/skills/discovery/SKILL.md +5 -0
- package/skills/qc/qa-analyst/acceptance-criteria.md +5 -1
- package/skills/qc/qa-analyst/business-rules.md +6 -2
- package/skills/qc/qa-analyst/data-flow.md +6 -2
- package/skills/qc/qa-analyst/spec-breakdown.md +7 -3
- package/skills/qc/qa-designer/e2e/journey.md +1 -1
- package/skills/qc/qa-designer/exploratory/charter.md +2 -2
- package/skills/qc/qa-designer/exploratory/explore-to-functional.md +1 -1
- package/skills/qc/qa-designer/functional/api.md +1 -1
- package/skills/qc/qa-designer/functional/gui-feature.md +1 -1
- package/skills/qc/qa-designer/functional/gui-screen.md +1 -1
- package/skills/qc/qa-designer/integration/api.md +1 -1
- package/skills/qc/qa-designer/integration/db.md +1 -1
- package/skills/qc/qa-designer/integration/gui.md +1 -1
- package/skills/qc/qa-designer/integration/kafka.md +1 -1
- package/skills/qc/qa-designer/non-functional.md +1 -1
- package/skills/qc/qa-planner/test-plan.md +4 -4
- package/skills/qc/qa-runner/exploratory/session.md +2 -2
- package/skills/test/SKILL.md +10 -0
- package/steps/context-loader.md +5 -0
- package/templates/project-context.yaml +19 -1
package/commands/debug.md
CHANGED
|
@@ -128,6 +128,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
128
128
|
- `paths.specs_dir` → BDD specs root
|
|
129
129
|
- `paths.prd_dir` → PRD documents root
|
|
130
130
|
- `paths.refinement_dir` → findings/review output dir
|
|
131
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
132
|
+
- `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)
|
|
131
133
|
- `paths.product_definitions_dir` → product definitions root
|
|
132
134
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
133
135
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -140,6 +142,8 @@ If `paths` section is absent, use these defaults:
|
|
|
140
142
|
- `specs_dir` = `specs/bdd`
|
|
141
143
|
- `prd_dir` = `specs/prd`
|
|
142
144
|
- `refinement_dir` = `.agent/review`
|
|
145
|
+
- `qc_dir` = `docs`
|
|
146
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
143
147
|
- `product_definitions_dir` = `specs/product-definition`
|
|
144
148
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
145
149
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -184,6 +188,7 @@ If `services` section is present:
|
|
|
184
188
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
185
189
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
186
190
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
191
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
187
192
|
|
|
188
193
|
> **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.
|
|
189
194
|
|
|
@@ -125,6 +125,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
125
125
|
- `paths.specs_dir` → BDD specs root
|
|
126
126
|
- `paths.prd_dir` → PRD documents root
|
|
127
127
|
- `paths.refinement_dir` → findings/review output dir
|
|
128
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
129
|
+
- `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)
|
|
128
130
|
- `paths.product_definitions_dir` → product definitions root
|
|
129
131
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
130
132
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -137,6 +139,8 @@ If `paths` section is absent, use these defaults:
|
|
|
137
139
|
- `specs_dir` = `specs/bdd`
|
|
138
140
|
- `prd_dir` = `specs/prd`
|
|
139
141
|
- `refinement_dir` = `.agent/review`
|
|
142
|
+
- `qc_dir` = `docs`
|
|
143
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
140
144
|
- `product_definitions_dir` = `specs/product-definition`
|
|
141
145
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
142
146
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -181,6 +185,7 @@ If `services` section is present:
|
|
|
181
185
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
182
186
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
183
187
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
188
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
184
189
|
|
|
185
190
|
> **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.
|
|
186
191
|
|
package/commands/dev-gen-test.md
CHANGED
|
@@ -131,6 +131,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
131
131
|
- `paths.specs_dir` → BDD specs root
|
|
132
132
|
- `paths.prd_dir` → PRD documents root
|
|
133
133
|
- `paths.refinement_dir` → findings/review output dir
|
|
134
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
135
|
+
- `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)
|
|
134
136
|
- `paths.product_definitions_dir` → product definitions root
|
|
135
137
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
136
138
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -143,6 +145,8 @@ If `paths` section is absent, use these defaults:
|
|
|
143
145
|
- `specs_dir` = `specs/bdd`
|
|
144
146
|
- `prd_dir` = `specs/prd`
|
|
145
147
|
- `refinement_dir` = `.agent/review`
|
|
148
|
+
- `qc_dir` = `docs`
|
|
149
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
146
150
|
- `product_definitions_dir` = `specs/product-definition`
|
|
147
151
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
148
152
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -187,6 +191,7 @@ If `services` section is present:
|
|
|
187
191
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
188
192
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
189
193
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
194
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
190
195
|
|
|
191
196
|
> **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.
|
|
192
197
|
|
package/commands/dev-run-test.md
CHANGED
|
@@ -131,6 +131,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
131
131
|
- `paths.specs_dir` → BDD specs root
|
|
132
132
|
- `paths.prd_dir` → PRD documents root
|
|
133
133
|
- `paths.refinement_dir` → findings/review output dir
|
|
134
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
135
|
+
- `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)
|
|
134
136
|
- `paths.product_definitions_dir` → product definitions root
|
|
135
137
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
136
138
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -143,6 +145,8 @@ If `paths` section is absent, use these defaults:
|
|
|
143
145
|
- `specs_dir` = `specs/bdd`
|
|
144
146
|
- `prd_dir` = `specs/prd`
|
|
145
147
|
- `refinement_dir` = `.agent/review`
|
|
148
|
+
- `qc_dir` = `docs`
|
|
149
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
146
150
|
- `product_definitions_dir` = `specs/product-definition`
|
|
147
151
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
148
152
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -187,6 +191,7 @@ If `services` section is present:
|
|
|
187
191
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
188
192
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
189
193
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
194
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
190
195
|
|
|
191
196
|
> **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.
|
|
192
197
|
|
|
@@ -127,6 +127,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
127
127
|
- `paths.specs_dir` → BDD specs root
|
|
128
128
|
- `paths.prd_dir` → PRD documents root
|
|
129
129
|
- `paths.refinement_dir` → findings/review output dir
|
|
130
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
131
|
+
- `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)
|
|
130
132
|
- `paths.product_definitions_dir` → product definitions root
|
|
131
133
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
132
134
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -139,6 +141,8 @@ If `paths` section is absent, use these defaults:
|
|
|
139
141
|
- `specs_dir` = `specs/bdd`
|
|
140
142
|
- `prd_dir` = `specs/prd`
|
|
141
143
|
- `refinement_dir` = `.agent/review`
|
|
144
|
+
- `qc_dir` = `docs`
|
|
145
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
142
146
|
- `product_definitions_dir` = `specs/product-definition`
|
|
143
147
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
144
148
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -183,6 +187,7 @@ If `services` section is present:
|
|
|
183
187
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
184
188
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
185
189
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
190
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
186
191
|
|
|
187
192
|
> **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.
|
|
188
193
|
|
package/commands/fix-bug.md
CHANGED
|
@@ -84,7 +84,7 @@ Wait for explicit "Y" or "N" from the user before continuing.
|
|
|
84
84
|
- "N" → stop and ask what the user wants to change.
|
|
85
85
|
|
|
86
86
|
|
|
87
|
-
*Note: For this command, the target in Step 1 is a ticket ID (e.g., `PROJ-123`) or bug description from `$ARGUMENTS`.
|
|
87
|
+
*Note: For this command, the target in Step 1 is a ticket ID (e.g., `PROJ-123`), a **filed bug `{BUG-ID}`** (a `{paths.bug_reports_dir}/{BUG-ID}.md` from `/report-bug` — e.g. a QC product-gap), or a bug description from `$ARGUMENTS`. If a `{BUG-ID}` is given, resolve & read that report for spec context; otherwise proceed to context loading.*
|
|
88
88
|
|
|
89
89
|
## Context
|
|
90
90
|
# Context Loader — Load All Project Context
|
|
@@ -125,6 +125,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
125
125
|
- `paths.specs_dir` → BDD specs root
|
|
126
126
|
- `paths.prd_dir` → PRD documents root
|
|
127
127
|
- `paths.refinement_dir` → findings/review output dir
|
|
128
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
129
|
+
- `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)
|
|
128
130
|
- `paths.product_definitions_dir` → product definitions root
|
|
129
131
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
130
132
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -137,6 +139,8 @@ If `paths` section is absent, use these defaults:
|
|
|
137
139
|
- `specs_dir` = `specs/bdd`
|
|
138
140
|
- `prd_dir` = `specs/prd`
|
|
139
141
|
- `refinement_dir` = `.agent/review`
|
|
142
|
+
- `qc_dir` = `docs`
|
|
143
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
140
144
|
- `product_definitions_dir` = `specs/product-definition`
|
|
141
145
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
142
146
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -181,6 +185,7 @@ If `services` section is present:
|
|
|
181
185
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
182
186
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
183
187
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
188
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
184
189
|
|
|
185
190
|
> **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.
|
|
186
191
|
|
|
@@ -387,8 +392,9 @@ Proceed to the next step of the calling command.
|
|
|
387
392
|
---
|
|
388
393
|
|
|
389
394
|
## Phase 1 — Gather Info
|
|
395
|
+
If a `{BUG-ID}` was given: read `{paths.bug_reports_dir}/{BUG-ID}.md` for the spec context, AC violated, expected-vs-actual, and the suggested layer — use it as the bug details (no need to re-ask).
|
|
390
396
|
If ticket: fetch details (or ask user to paste).
|
|
391
|
-
If no ticket — CHECKPOINT:
|
|
397
|
+
If no ticket / BUG-ID — CHECKPOINT:
|
|
392
398
|
1. Where does the bug occur? (module, endpoint, flow)
|
|
393
399
|
2. Steps to reproduce?
|
|
394
400
|
3. Expected vs Actual?
|
|
@@ -461,7 +467,11 @@ Proceed? (Y/N)
|
|
|
461
467
|
```
|
|
462
468
|
|
|
463
469
|
## Phase 3 — Fix
|
|
470
|
+
|
|
471
|
+
*Umbrella mode: the buggy code lives in the **service submodule** resolved at context-loader Step 1.6 — create the branch and run every git/build step from **inside** `{service_root}`. Single-service: omit the `cd`.*
|
|
472
|
+
|
|
464
473
|
```bash
|
|
474
|
+
cd {service_root} # umbrella: the service submodule; single-service: omit
|
|
465
475
|
git checkout -b fix/{TICKET_ID}-{description}
|
|
466
476
|
```
|
|
467
477
|
Apply fix. Add trace annotation if file has `@trace.implements`:
|
|
@@ -478,13 +488,37 @@ Test: "Regression {TICKET_ID}: {bug description}"
|
|
|
478
488
|
```
|
|
479
489
|
Run test. If fail → debug and fix (max 3 iterations).
|
|
480
490
|
|
|
481
|
-
## Phase 5 — Build & Commit
|
|
491
|
+
## Phase 5 — Build & Commit (2-layer push in umbrella mode)
|
|
482
492
|
```bash
|
|
483
|
-
{conventions.build_command} # max 3 retries
|
|
493
|
+
{conventions.build_command} # max 3 retries — runs inside {service_root} in umbrella mode
|
|
494
|
+
# Tầng 1 — push the fix branch in the service submodule (where the code lives):
|
|
484
495
|
git add {files}
|
|
485
496
|
git commit -m "fix({TICKET_ID}): {description}"
|
|
486
|
-
git push -u origin fix/{TICKET_ID}-{slug}
|
|
497
|
+
git push -u origin fix/{TICKET_ID}-{slug} # then open a PR into the service's tracked branch
|
|
487
498
|
```
|
|
499
|
+
> **Umbrella mode — Tầng 2 (bump umbrella pointer):** the umbrella records a *commit* of the service
|
|
500
|
+
> submodule, not a branch. After the fix-branch PR **merges** into the service's tracked branch, bump
|
|
501
|
+
> the pointer so teammates pulling the umbrella don't hit "commit not found":
|
|
502
|
+
> ```bash
|
|
503
|
+
> cd - # back to umbrella root
|
|
504
|
+
> git add {service_root} && git commit -m "chore: bump {service_root} pointer (fix {TICKET_ID})"
|
|
505
|
+
> git push
|
|
506
|
+
> ```
|
|
507
|
+
> Single-service mode: no umbrella pointer — Tầng 1 is the whole push. Full rule: Sync & Update §4.4 (commit 2 tầng).
|
|
508
|
+
|
|
509
|
+
## Phase 5.5 — Close the bug report (if fixing a filed `{BUG-ID}`)
|
|
510
|
+
|
|
511
|
+
*Skip if the target was a plain ticket/description (no `{BUG-ID}` file).*
|
|
512
|
+
|
|
513
|
+
After the fix is committed, update `{paths.bug_reports_dir}/{BUG-ID}.md`:
|
|
514
|
+
- Set `State` → `🟡 Fixed` and append a short **Resolution** (root cause + commit/PR link).
|
|
515
|
+
- It is **not** `Closed` yet — QC owns verification: when `/qc-run-test` re-runs and `qc_status`
|
|
516
|
+
for the linked SC flips to `pass`, it becomes `🟢 Closed` (and `qc_owner`/`qc_blocked_by` clear).
|
|
517
|
+
- Commit the updated report to the spec repo (same 2-layer push as `/report-bug`) so the PO/PM
|
|
518
|
+
"waiting-on" view reflects it on `/sync`.
|
|
519
|
+
|
|
520
|
+
This is the only write `/fix-bug` makes to the feedback area — it still fixes **code** only,
|
|
521
|
+
never edits PRD/BDD (spec changes are PO/Dev per BUG_FLOW Case 2–4).
|
|
488
522
|
|
|
489
523
|
## Phase 6 — Offer to Record a Lesson (optional)
|
|
490
524
|
|
|
@@ -657,7 +691,8 @@ Next : {suggested command with example arguments}
|
|
|
657
691
|
Root Cause: {analysis}
|
|
658
692
|
Changes: {list}
|
|
659
693
|
✅ Regression test added | ✅ Build: SUCCESS
|
|
694
|
+
{🐞 BUG-{id} → State: Fixed (pushed) — Closed after /qc-run-test re-verify pass | if fixing a filed bug}
|
|
660
695
|
{📝 Lesson L-NNN recorded (if captured)}
|
|
661
696
|
Branch: fix/{TICKET_ID}-{slug}
|
|
662
|
-
Next: Create PR and link to ticket.
|
|
697
|
+
Next: Create PR and link to ticket. {QC: re-run /qc-run-test {UC-ID} to verify + close the bug | if applicable}
|
|
663
698
|
```
|
package/commands/fix-bug.tmpl
CHANGED
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
## Gate
|
|
4
4
|
{{include:steps/gate.md}}
|
|
5
5
|
|
|
6
|
-
*Note: For this command, the target in Step 1 is a ticket ID (e.g., `PROJ-123`) or bug description from `$ARGUMENTS`.
|
|
6
|
+
*Note: For this command, the target in Step 1 is a ticket ID (e.g., `PROJ-123`), a **filed bug `{BUG-ID}`** (a `{paths.bug_reports_dir}/{BUG-ID}.md` from `/report-bug` — e.g. a QC product-gap), or a bug description from `$ARGUMENTS`. If a `{BUG-ID}` is given, resolve & read that report for spec context; otherwise proceed to context loading.*
|
|
7
7
|
|
|
8
8
|
## Context
|
|
9
9
|
{{include:steps/context-loader.md}}
|
|
@@ -11,8 +11,9 @@
|
|
|
11
11
|
---
|
|
12
12
|
|
|
13
13
|
## Phase 1 — Gather Info
|
|
14
|
+
If a `{BUG-ID}` was given: read `{paths.bug_reports_dir}/{BUG-ID}.md` for the spec context, AC violated, expected-vs-actual, and the suggested layer — use it as the bug details (no need to re-ask).
|
|
14
15
|
If ticket: fetch details (or ask user to paste).
|
|
15
|
-
If no ticket — CHECKPOINT:
|
|
16
|
+
If no ticket / BUG-ID — CHECKPOINT:
|
|
16
17
|
1. Where does the bug occur? (module, endpoint, flow)
|
|
17
18
|
2. Steps to reproduce?
|
|
18
19
|
3. Expected vs Actual?
|
|
@@ -85,7 +86,11 @@ Proceed? (Y/N)
|
|
|
85
86
|
```
|
|
86
87
|
|
|
87
88
|
## Phase 3 — Fix
|
|
89
|
+
|
|
90
|
+
*Umbrella mode: the buggy code lives in the **service submodule** resolved at context-loader Step 1.6 — create the branch and run every git/build step from **inside** `{service_root}`. Single-service: omit the `cd`.*
|
|
91
|
+
|
|
88
92
|
```bash
|
|
93
|
+
cd {service_root} # umbrella: the service submodule; single-service: omit
|
|
89
94
|
git checkout -b fix/{TICKET_ID}-{description}
|
|
90
95
|
```
|
|
91
96
|
Apply fix. Add trace annotation if file has `@trace.implements`:
|
|
@@ -102,13 +107,37 @@ Test: "Regression {TICKET_ID}: {bug description}"
|
|
|
102
107
|
```
|
|
103
108
|
Run test. If fail → debug and fix (max 3 iterations).
|
|
104
109
|
|
|
105
|
-
## Phase 5 — Build & Commit
|
|
110
|
+
## Phase 5 — Build & Commit (2-layer push in umbrella mode)
|
|
106
111
|
```bash
|
|
107
|
-
{conventions.build_command} # max 3 retries
|
|
112
|
+
{conventions.build_command} # max 3 retries — runs inside {service_root} in umbrella mode
|
|
113
|
+
# Tầng 1 — push the fix branch in the service submodule (where the code lives):
|
|
108
114
|
git add {files}
|
|
109
115
|
git commit -m "fix({TICKET_ID}): {description}"
|
|
110
|
-
git push -u origin fix/{TICKET_ID}-{slug}
|
|
116
|
+
git push -u origin fix/{TICKET_ID}-{slug} # then open a PR into the service's tracked branch
|
|
111
117
|
```
|
|
118
|
+
> **Umbrella mode — Tầng 2 (bump umbrella pointer):** the umbrella records a *commit* of the service
|
|
119
|
+
> submodule, not a branch. After the fix-branch PR **merges** into the service's tracked branch, bump
|
|
120
|
+
> the pointer so teammates pulling the umbrella don't hit "commit not found":
|
|
121
|
+
> ```bash
|
|
122
|
+
> cd - # back to umbrella root
|
|
123
|
+
> git add {service_root} && git commit -m "chore: bump {service_root} pointer (fix {TICKET_ID})"
|
|
124
|
+
> git push
|
|
125
|
+
> ```
|
|
126
|
+
> Single-service mode: no umbrella pointer — Tầng 1 is the whole push. Full rule: Sync & Update §4.4 (commit 2 tầng).
|
|
127
|
+
|
|
128
|
+
## Phase 5.5 — Close the bug report (if fixing a filed `{BUG-ID}`)
|
|
129
|
+
|
|
130
|
+
*Skip if the target was a plain ticket/description (no `{BUG-ID}` file).*
|
|
131
|
+
|
|
132
|
+
After the fix is committed, update `{paths.bug_reports_dir}/{BUG-ID}.md`:
|
|
133
|
+
- Set `State` → `🟡 Fixed` and append a short **Resolution** (root cause + commit/PR link).
|
|
134
|
+
- It is **not** `Closed` yet — QC owns verification: when `/qc-run-test` re-runs and `qc_status`
|
|
135
|
+
for the linked SC flips to `pass`, it becomes `🟢 Closed` (and `qc_owner`/`qc_blocked_by` clear).
|
|
136
|
+
- Commit the updated report to the spec repo (same 2-layer push as `/report-bug`) so the PO/PM
|
|
137
|
+
"waiting-on" view reflects it on `/sync`.
|
|
138
|
+
|
|
139
|
+
This is the only write `/fix-bug` makes to the feedback area — it still fixes **code** only,
|
|
140
|
+
never edits PRD/BDD (spec changes are PO/Dev per BUG_FLOW Case 2–4).
|
|
112
141
|
|
|
113
142
|
## Phase 6 — Offer to Record a Lesson (optional)
|
|
114
143
|
|
|
@@ -135,7 +164,8 @@ If `Y` → run the capture procedure below with `source=/fix-bug {TICKET_ID}`, a
|
|
|
135
164
|
Root Cause: {analysis}
|
|
136
165
|
Changes: {list}
|
|
137
166
|
✅ Regression test added | ✅ Build: SUCCESS
|
|
167
|
+
{🐞 BUG-{id} → State: Fixed (pushed) — Closed after /qc-run-test re-verify pass | if fixing a filed bug}
|
|
138
168
|
{📝 Lesson L-NNN recorded (if captured)}
|
|
139
169
|
Branch: fix/{TICKET_ID}-{slug}
|
|
140
|
-
Next: Create PR and link to ticket.
|
|
170
|
+
Next: Create PR and link to ticket. {QC: re-run /qc-run-test {UC-ID} to verify + close the bug | if applicable}
|
|
141
171
|
```
|
package/commands/generate-bdd.md
CHANGED
|
@@ -123,6 +123,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
123
123
|
- `paths.specs_dir` → BDD specs root
|
|
124
124
|
- `paths.prd_dir` → PRD documents root
|
|
125
125
|
- `paths.refinement_dir` → findings/review output dir
|
|
126
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
127
|
+
- `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)
|
|
126
128
|
- `paths.product_definitions_dir` → product definitions root
|
|
127
129
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
128
130
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -135,6 +137,8 @@ If `paths` section is absent, use these defaults:
|
|
|
135
137
|
- `specs_dir` = `specs/bdd`
|
|
136
138
|
- `prd_dir` = `specs/prd`
|
|
137
139
|
- `refinement_dir` = `.agent/review`
|
|
140
|
+
- `qc_dir` = `docs`
|
|
141
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
138
142
|
- `product_definitions_dir` = `specs/product-definition`
|
|
139
143
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
140
144
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -179,6 +183,7 @@ If `services` section is present:
|
|
|
179
183
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
180
184
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
181
185
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
186
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
182
187
|
|
|
183
188
|
> **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.
|
|
184
189
|
|
|
@@ -834,7 +839,7 @@ After generating all `.feature` files, create or update `{paths.trace_dir}/{UC-I
|
|
|
834
839
|
|
|
835
840
|
**TSV columns (tab-separated, one header row + one data row per scenario):**
|
|
836
841
|
```
|
|
837
|
-
sc_id\tsc_title\tspec_ver\tgen_ver\timplemented_by\ttest_count\ttest_classes\tdev_selftest\tdev_selftest_at\tqc_status\tqc_run_at\tprd_version\tbdd_version\ttech_doc_revision\tprd_status\tuc_status\tfe_phase\tstatus\tlast_updated
|
|
842
|
+
sc_id\tsc_title\tspec_ver\tgen_ver\timplemented_by\ttest_count\ttest_classes\tdev_selftest\tdev_selftest_at\tqc_status\tqc_run_at\tqc_owner\tqc_blocked_by\tprd_version\tbdd_version\ttech_doc_revision\tprd_status\tuc_status\tfe_phase\tstatus\tlast_updated
|
|
838
843
|
```
|
|
839
844
|
|
|
840
845
|
**Rules:**
|
|
@@ -842,7 +847,7 @@ sc_id\tsc_title\tspec_ver\tgen_ver\timplemented_by\ttest_count\ttest_classes\tde
|
|
|
842
847
|
- If file exists (re-generation) → for each SC in the new `.feature`:
|
|
843
848
|
- SC already in `.tsv` AND `spec_ver` is unchanged → update only: `sc_title`, `prd_version`, `bdd_version`, `prd_status`, `uc_status`, `last_updated`. Leave all other columns unchanged.
|
|
844
849
|
- SC already in `.tsv` AND `spec_ver` changed (scenario was modified) → update: `sc_title`, `spec_ver`, `prd_version`, `bdd_version`, `prd_status`, `uc_status`, `last_updated` AND set `status = DRIFT` immediately (so the TSV reflects drift without waiting for `/validate-traces`). Leave `gen_ver`, `implemented_by`, `test_count`, `test_classes`, `tech_doc_revision` unchanged.
|
|
845
|
-
- SC is new (added in this re-gen) → append new row with `gen_ver`, `implemented_by`, `test_count`, `test_classes`, `dev_selftest`, `dev_selftest_at`, `qc_status`, `qc_run_at`, `tech_doc_revision` all set to `—`.
|
|
850
|
+
- SC is new (added in this re-gen) → append new row with `gen_ver`, `implemented_by`, `test_count`, `test_classes`, `dev_selftest`, `dev_selftest_at`, `qc_status`, `qc_run_at`, `qc_owner`, `qc_blocked_by`, `tech_doc_revision` all set to `—`.
|
|
846
851
|
- SC no longer in `.feature` (removed) → delete its row.
|
|
847
852
|
|
|
848
853
|
**Values to write for each scenario:**
|
|
@@ -860,6 +865,8 @@ sc_id\tsc_title\tspec_ver\tgen_ver\timplemented_by\ttest_count\ttest_classes\tde
|
|
|
860
865
|
| `dev_selftest_at` | `—` |
|
|
861
866
|
| `qc_status` | `—` (official QC automation result — set by `/qc-run-test`) |
|
|
862
867
|
| `qc_run_at` | `—` |
|
|
868
|
+
| `qc_owner` | `—` (who a non-passing SC waits on: `dev` / `po` — set by `/qc-run-test` + `/report-bug`) |
|
|
869
|
+
| `qc_blocked_by` | `—` (linked `BUG-{id}` / `GAP-{id}` — set by `/qc-run-test` + `/report-bug`) |
|
|
863
870
|
| `prd_version` | `@trace.prd_version` from `.feature` header |
|
|
864
871
|
| `bdd_version` | `@trace.bdd_version` from `.feature` header |
|
|
865
872
|
| `tech_doc_revision` | `—` |
|
|
@@ -458,7 +458,7 @@ After generating all `.feature` files, create or update `{paths.trace_dir}/{UC-I
|
|
|
458
458
|
|
|
459
459
|
**TSV columns (tab-separated, one header row + one data row per scenario):**
|
|
460
460
|
```
|
|
461
|
-
sc_id\tsc_title\tspec_ver\tgen_ver\timplemented_by\ttest_count\ttest_classes\tdev_selftest\tdev_selftest_at\tqc_status\tqc_run_at\tprd_version\tbdd_version\ttech_doc_revision\tprd_status\tuc_status\tfe_phase\tstatus\tlast_updated
|
|
461
|
+
sc_id\tsc_title\tspec_ver\tgen_ver\timplemented_by\ttest_count\ttest_classes\tdev_selftest\tdev_selftest_at\tqc_status\tqc_run_at\tqc_owner\tqc_blocked_by\tprd_version\tbdd_version\ttech_doc_revision\tprd_status\tuc_status\tfe_phase\tstatus\tlast_updated
|
|
462
462
|
```
|
|
463
463
|
|
|
464
464
|
**Rules:**
|
|
@@ -466,7 +466,7 @@ sc_id\tsc_title\tspec_ver\tgen_ver\timplemented_by\ttest_count\ttest_classes\tde
|
|
|
466
466
|
- If file exists (re-generation) → for each SC in the new `.feature`:
|
|
467
467
|
- SC already in `.tsv` AND `spec_ver` is unchanged → update only: `sc_title`, `prd_version`, `bdd_version`, `prd_status`, `uc_status`, `last_updated`. Leave all other columns unchanged.
|
|
468
468
|
- SC already in `.tsv` AND `spec_ver` changed (scenario was modified) → update: `sc_title`, `spec_ver`, `prd_version`, `bdd_version`, `prd_status`, `uc_status`, `last_updated` AND set `status = DRIFT` immediately (so the TSV reflects drift without waiting for `/validate-traces`). Leave `gen_ver`, `implemented_by`, `test_count`, `test_classes`, `tech_doc_revision` unchanged.
|
|
469
|
-
- SC is new (added in this re-gen) → append new row with `gen_ver`, `implemented_by`, `test_count`, `test_classes`, `dev_selftest`, `dev_selftest_at`, `qc_status`, `qc_run_at`, `tech_doc_revision` all set to `—`.
|
|
469
|
+
- SC is new (added in this re-gen) → append new row with `gen_ver`, `implemented_by`, `test_count`, `test_classes`, `dev_selftest`, `dev_selftest_at`, `qc_status`, `qc_run_at`, `qc_owner`, `qc_blocked_by`, `tech_doc_revision` all set to `—`.
|
|
470
470
|
- SC no longer in `.feature` (removed) → delete its row.
|
|
471
471
|
|
|
472
472
|
**Values to write for each scenario:**
|
|
@@ -484,6 +484,8 @@ sc_id\tsc_title\tspec_ver\tgen_ver\timplemented_by\ttest_count\ttest_classes\tde
|
|
|
484
484
|
| `dev_selftest_at` | `—` |
|
|
485
485
|
| `qc_status` | `—` (official QC automation result — set by `/qc-run-test`) |
|
|
486
486
|
| `qc_run_at` | `—` |
|
|
487
|
+
| `qc_owner` | `—` (who a non-passing SC waits on: `dev` / `po` — set by `/qc-run-test` + `/report-bug`) |
|
|
488
|
+
| `qc_blocked_by` | `—` (linked `BUG-{id}` / `GAP-{id}` — set by `/qc-run-test` + `/report-bug`) |
|
|
487
489
|
| `prd_version` | `@trace.prd_version` from `.feature` header |
|
|
488
490
|
| `bdd_version` | `@trace.bdd_version` from `.feature` header |
|
|
489
491
|
| `tech_doc_revision` | `—` |
|
|
@@ -125,6 +125,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
125
125
|
- `paths.specs_dir` → BDD specs root
|
|
126
126
|
- `paths.prd_dir` → PRD documents root
|
|
127
127
|
- `paths.refinement_dir` → findings/review output dir
|
|
128
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
129
|
+
- `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)
|
|
128
130
|
- `paths.product_definitions_dir` → product definitions root
|
|
129
131
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
130
132
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -137,6 +139,8 @@ If `paths` section is absent, use these defaults:
|
|
|
137
139
|
- `specs_dir` = `specs/bdd`
|
|
138
140
|
- `prd_dir` = `specs/prd`
|
|
139
141
|
- `refinement_dir` = `.agent/review`
|
|
142
|
+
- `qc_dir` = `docs`
|
|
143
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
140
144
|
- `product_definitions_dir` = `specs/product-definition`
|
|
141
145
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
142
146
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -181,6 +185,7 @@ If `services` section is present:
|
|
|
181
185
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
182
186
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
183
187
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
188
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
184
189
|
|
|
185
190
|
> **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.
|
|
186
191
|
|
|
@@ -125,6 +125,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
125
125
|
- `paths.specs_dir` → BDD specs root
|
|
126
126
|
- `paths.prd_dir` → PRD documents root
|
|
127
127
|
- `paths.refinement_dir` → findings/review output dir
|
|
128
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
129
|
+
- `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)
|
|
128
130
|
- `paths.product_definitions_dir` → product definitions root
|
|
129
131
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
130
132
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -137,6 +139,8 @@ If `paths` section is absent, use these defaults:
|
|
|
137
139
|
- `specs_dir` = `specs/bdd`
|
|
138
140
|
- `prd_dir` = `specs/prd`
|
|
139
141
|
- `refinement_dir` = `.agent/review`
|
|
142
|
+
- `qc_dir` = `docs`
|
|
143
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
140
144
|
- `product_definitions_dir` = `specs/product-definition`
|
|
141
145
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
142
146
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -181,6 +185,7 @@ If `services` section is present:
|
|
|
181
185
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
182
186
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
183
187
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
188
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
184
189
|
|
|
185
190
|
> **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.
|
|
186
191
|
|
package/commands/generate-prd.md
CHANGED
|
@@ -125,6 +125,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
125
125
|
- `paths.specs_dir` → BDD specs root
|
|
126
126
|
- `paths.prd_dir` → PRD documents root
|
|
127
127
|
- `paths.refinement_dir` → findings/review output dir
|
|
128
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
129
|
+
- `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)
|
|
128
130
|
- `paths.product_definitions_dir` → product definitions root
|
|
129
131
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
130
132
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -137,6 +139,8 @@ If `paths` section is absent, use these defaults:
|
|
|
137
139
|
- `specs_dir` = `specs/bdd`
|
|
138
140
|
- `prd_dir` = `specs/prd`
|
|
139
141
|
- `refinement_dir` = `.agent/review`
|
|
142
|
+
- `qc_dir` = `docs`
|
|
143
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
140
144
|
- `product_definitions_dir` = `specs/product-definition`
|
|
141
145
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
142
146
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -181,6 +185,7 @@ If `services` section is present:
|
|
|
181
185
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
182
186
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
183
187
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
188
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
184
189
|
|
|
185
190
|
> **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.
|
|
186
191
|
|
|
@@ -130,6 +130,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
130
130
|
- `paths.specs_dir` → BDD specs root
|
|
131
131
|
- `paths.prd_dir` → PRD documents root
|
|
132
132
|
- `paths.refinement_dir` → findings/review output dir
|
|
133
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
134
|
+
- `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)
|
|
133
135
|
- `paths.product_definitions_dir` → product definitions root
|
|
134
136
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
135
137
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -142,6 +144,8 @@ If `paths` section is absent, use these defaults:
|
|
|
142
144
|
- `specs_dir` = `specs/bdd`
|
|
143
145
|
- `prd_dir` = `specs/prd`
|
|
144
146
|
- `refinement_dir` = `.agent/review`
|
|
147
|
+
- `qc_dir` = `docs`
|
|
148
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
145
149
|
- `product_definitions_dir` = `specs/product-definition`
|
|
146
150
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
147
151
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -186,6 +190,7 @@ If `services` section is present:
|
|
|
186
190
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
187
191
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
188
192
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
193
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
189
194
|
|
|
190
195
|
> **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.
|
|
191
196
|
|
|
@@ -146,6 +146,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
146
146
|
- `paths.specs_dir` → BDD specs root
|
|
147
147
|
- `paths.prd_dir` → PRD documents root
|
|
148
148
|
- `paths.refinement_dir` → findings/review output dir
|
|
149
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
150
|
+
- `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)
|
|
149
151
|
- `paths.product_definitions_dir` → product definitions root
|
|
150
152
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
151
153
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -158,6 +160,8 @@ If `paths` section is absent, use these defaults:
|
|
|
158
160
|
- `specs_dir` = `specs/bdd`
|
|
159
161
|
- `prd_dir` = `specs/prd`
|
|
160
162
|
- `refinement_dir` = `.agent/review`
|
|
163
|
+
- `qc_dir` = `docs`
|
|
164
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
161
165
|
- `product_definitions_dir` = `specs/product-definition`
|
|
162
166
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
163
167
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -202,6 +206,7 @@ If `services` section is present:
|
|
|
202
206
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
203
207
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
204
208
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
209
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
205
210
|
|
|
206
211
|
> **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.
|
|
207
212
|
|
package/commands/learn.md
CHANGED
|
@@ -134,6 +134,8 @@ Read `.agent/project-context.yaml`. Extract and store:
|
|
|
134
134
|
- `paths.specs_dir` → BDD specs root
|
|
135
135
|
- `paths.prd_dir` → PRD documents root
|
|
136
136
|
- `paths.refinement_dir` → findings/review output dir
|
|
137
|
+
- `paths.qc_dir` → QC automation artifacts root (visible top-level, one subfolder per UC: `{qc_dir}/{UC-ID}/`)
|
|
138
|
+
- `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)
|
|
137
139
|
- `paths.product_definitions_dir` → product definitions root
|
|
138
140
|
- `paths.domain_knowledge_dir` → domain knowledge root
|
|
139
141
|
- `paths.business_dictionary` → path to business-dictionary.md
|
|
@@ -146,6 +148,8 @@ If `paths` section is absent, use these defaults:
|
|
|
146
148
|
- `specs_dir` = `specs/bdd`
|
|
147
149
|
- `prd_dir` = `specs/prd`
|
|
148
150
|
- `refinement_dir` = `.agent/review`
|
|
151
|
+
- `qc_dir` = `docs`
|
|
152
|
+
- `qc_skills_dir` = `.agent/skills/qc`
|
|
149
153
|
- `product_definitions_dir` = `specs/product-definition`
|
|
150
154
|
- `domain_knowledge_dir` = `specs/domain-knowledge`
|
|
151
155
|
- `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
|
|
@@ -190,6 +194,7 @@ If `services` section is present:
|
|
|
190
194
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
191
195
|
- Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
|
|
192
196
|
- Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
|
|
197
|
+
- Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
|
|
193
198
|
|
|
194
199
|
> **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.
|
|
195
200
|
|