@anhth2/spec-driven-dev-plugin 0.10.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 +43 -8
- package/commands/define-product.md +43 -8
- package/commands/dev-gen-test.md +44 -9
- package/commands/dev-gen-test.tmpl +1 -1
- package/commands/dev-run-test.md +48 -10
- package/commands/dev-run-test.tmpl +5 -2
- package/commands/dev-smoke-test.md +43 -8
- package/commands/fix-bug.md +79 -14
- package/commands/fix-bug.tmpl +36 -6
- package/commands/generate-bdd.md +49 -10
- package/commands/generate-bdd.tmpl +6 -2
- package/commands/generate-code.md +44 -9
- package/commands/generate-code.tmpl +1 -1
- package/commands/generate-design-spec.md +43 -8
- package/commands/generate-prd.md +43 -8
- package/commands/generate-spec-manifest.md +43 -8
- package/commands/generate-tech-docs.md +43 -8
- package/commands/learn.md +43 -8
- package/commands/propose-scenario.md +74 -19
- package/commands/propose-scenario.tmpl +31 -11
- package/commands/qc-analyze.md +534 -0
- package/commands/qc-analyze.tmpl +86 -0
- package/commands/qc-design-test.md +515 -0
- package/commands/qc-design-test.tmpl +67 -0
- package/commands/qc-plan.md +497 -0
- package/commands/qc-plan.tmpl +49 -0
- package/commands/qc-report.md +508 -0
- package/commands/qc-report.tmpl +60 -0
- package/commands/qc-review.md +501 -0
- package/commands/qc-review.tmpl +53 -0
- package/commands/qc-run-test.md +549 -0
- package/commands/qc-run-test.tmpl +83 -0
- package/commands/refine-prd.md +43 -8
- package/commands/report-bug.md +59 -10
- package/commands/report-bug.tmpl +16 -2
- package/commands/review-code.md +43 -8
- package/commands/review-context.md +43 -8
- package/commands/review-tech-docs.md +43 -8
- package/commands/setup-ai-first.md +7 -0
- package/commands/sync.md +19 -9
- package/commands/sync.tmpl +12 -9
- package/commands/update-framework.md +7 -0
- package/commands/validate-traces.md +67 -12
- package/commands/validate-traces.tmpl +24 -4
- package/core/FRAMEWORK_VERSION +1 -1
- package/core/commands/debug.md +43 -8
- package/core/commands/define-product.md +43 -8
- package/core/commands/dev-gen-test.md +44 -9
- package/core/commands/dev-run-test.md +48 -10
- package/core/commands/dev-smoke-test.md +43 -8
- package/core/commands/fix-bug.md +79 -14
- package/core/commands/generate-bdd.md +49 -10
- package/core/commands/generate-code.md +44 -9
- package/core/commands/generate-design-spec.md +43 -8
- package/core/commands/generate-prd.md +43 -8
- package/core/commands/generate-spec-manifest.md +43 -8
- package/core/commands/generate-tech-docs.md +43 -8
- package/core/commands/learn.md +43 -8
- package/core/commands/propose-scenario.md +74 -19
- package/core/commands/qc-analyze.md +534 -0
- package/core/commands/qc-design-test.md +515 -0
- package/core/commands/qc-plan.md +497 -0
- package/core/commands/qc-report.md +508 -0
- package/core/commands/qc-review.md +501 -0
- package/core/commands/qc-run-test.md +549 -0
- package/core/commands/refine-prd.md +43 -8
- package/core/commands/report-bug.md +59 -10
- package/core/commands/review-code.md +43 -8
- package/core/commands/review-context.md +43 -8
- package/core/commands/review-tech-docs.md +43 -8
- package/core/commands/setup-ai-first.md +7 -0
- package/core/commands/sync.md +19 -9
- package/core/commands/update-framework.md +7 -0
- package/core/commands/validate-traces.md +67 -12
- package/core/modules/qc-playwright/stack-profile.yaml +65 -0
- package/core/skills/code/SKILL.md +50 -8
- package/core/skills/debug/SKILL.md +57 -8
- package/core/skills/design-spec/SKILL.md +43 -8
- package/core/skills/discovery/SKILL.md +43 -8
- package/core/skills/prd/SKILL.md +14 -0
- package/core/skills/qc/qa-analyst/DOC_GAPS.template.md +63 -0
- package/core/skills/qc/qa-analyst/acceptance-criteria.md +60 -0
- package/core/skills/qc/qa-analyst/business-rules.md +59 -0
- package/core/skills/qc/qa-analyst/data-flow.md +64 -0
- package/core/skills/qc/qa-analyst/spec-breakdown.md +61 -0
- package/core/skills/qc/qa-designer/e2e/journey.md +41 -0
- package/core/skills/qc/qa-designer/exploratory/charter.md +68 -0
- package/core/skills/qc/qa-designer/exploratory/explore-to-functional.md +43 -0
- package/core/skills/qc/qa-designer/functional/api.md +45 -0
- package/core/skills/qc/qa-designer/functional/gui-feature.md +46 -0
- package/core/skills/qc/qa-designer/functional/gui-screen.md +52 -0
- package/core/skills/qc/qa-designer/integration/api.md +42 -0
- package/core/skills/qc/qa-designer/integration/db.md +39 -0
- package/core/skills/qc/qa-designer/integration/gui.md +40 -0
- package/core/skills/qc/qa-designer/integration/kafka.md +40 -0
- package/core/skills/qc/qa-designer/non-functional.md +40 -0
- package/core/skills/qc/qa-planner/test-plan.md +120 -0
- package/core/skills/qc/qa-reviewer/script/e2e.md +87 -0
- package/core/skills/qc/qa-reviewer/script/exploratory.md +45 -0
- package/core/skills/qc/qa-reviewer/script/functional.md +101 -0
- package/core/skills/qc/qa-reviewer/script/integration.md +91 -0
- package/core/skills/qc/qa-reviewer/script/non-functional.md +126 -0
- package/core/skills/qc/qa-reviewer/test-case/e2e.md +73 -0
- package/core/skills/qc/qa-reviewer/test-case/exploratory.md +43 -0
- package/core/skills/qc/qa-reviewer/test-case/functional.md +76 -0
- package/core/skills/qc/qa-reviewer/test-case/integration.md +69 -0
- package/core/skills/qc/qa-reviewer/test-case/non-functional.md +73 -0
- package/core/skills/qc/qa-runner/e2e.md +49 -0
- package/core/skills/qc/qa-runner/exploratory/session.md +36 -0
- package/core/skills/qc/qa-runner/functional/api.md +35 -0
- package/core/skills/qc/qa-runner/functional/gui-feature.md +51 -0
- package/core/skills/qc/qa-runner/functional/gui-screen.md +55 -0
- package/core/skills/qc/qa-runner/integration.md +47 -0
- package/core/skills/qc/qa-runner/non-functional.md +49 -0
- package/core/skills/qc/qa-runner/report/report.md +37 -0
- package/core/skills/setup-ai-first/SKILL.md +7 -0
- package/core/skills/spec/SKILL.md +14 -0
- package/core/skills/test/SKILL.md +93 -16
- package/core/steps/context-loader.md +36 -8
- package/core/steps/report-footer.md +7 -0
- package/core/templates/project-context.yaml +27 -1
- package/docs/01-getting-started/README.md +19 -0
- package/docs/01-getting-started/core-concepts.md +102 -0
- package/docs/01-getting-started/installation.md +156 -0
- package/docs/01-getting-started/quickstart.md +85 -0
- package/docs/02-guides/README.md +27 -0
- package/docs/02-guides/developer/README.md +46 -0
- package/docs/02-guides/developer/bdd-and-trace.md +123 -0
- package/docs/02-guides/developer/commands.md +76 -0
- package/docs/02-guides/developer/pr-checklist.md +15 -0
- package/docs/02-guides/developer/scenarios.md +448 -0
- package/docs/02-guides/developer/workflow.md +61 -0
- package/docs/02-guides/product-owner/README.md +77 -0
- package/docs/02-guides/product-owner/commands.md +30 -0
- package/docs/02-guides/product-owner/handoff-checklist.md +42 -0
- package/docs/02-guides/product-owner/prd-writing-rules.md +45 -0
- package/docs/02-guides/product-owner/scenarios.md +357 -0
- package/docs/02-guides/qc-automation.md +157 -0
- package/docs/02-guides/tester/README.md +74 -0
- package/docs/02-guides/tester/bug-reporting.md +117 -0
- package/docs/02-guides/tester/reading-specs.md +79 -0
- package/docs/02-guides/tester/scenarios.md +186 -0
- package/docs/02-guides/tester/spec-manifest.md +124 -0
- package/docs/02-guides/tester/test-checklist.md +31 -0
- package/docs/02-guides/tester/workflow.md +80 -0
- package/docs/03-concepts/README.md +19 -0
- package/docs/03-concepts/architecture.md +245 -0
- package/docs/03-concepts/pipeline.md +262 -0
- package/docs/03-concepts/traceability.md +149 -0
- package/docs/04-operations/README.md +33 -0
- package/docs/04-operations/bug-flow.md +362 -0
- package/docs/04-operations/publishing.md +137 -0
- package/docs/04-operations/sync-and-update.md +365 -0
- package/docs/05-reference/README.md +29 -0
- package/docs/05-reference/commands.md +229 -0
- package/docs/05-reference/modules.md +110 -0
- package/docs/05-reference/trace-schema.md +152 -0
- package/docs/README.md +51 -0
- package/modules/qc-playwright/stack-profile.yaml +65 -0
- package/package.json +2 -2
- package/skills/code/SKILL.md +50 -8
- package/skills/debug/SKILL.md +57 -8
- package/skills/design-spec/SKILL.md +43 -8
- package/skills/discovery/SKILL.md +43 -8
- package/skills/prd/SKILL.md +14 -0
- package/skills/qc/qa-analyst/DOC_GAPS.template.md +63 -0
- package/skills/qc/qa-analyst/acceptance-criteria.md +60 -0
- package/skills/qc/qa-analyst/business-rules.md +59 -0
- package/skills/qc/qa-analyst/data-flow.md +64 -0
- package/skills/qc/qa-analyst/spec-breakdown.md +61 -0
- package/skills/qc/qa-designer/e2e/journey.md +41 -0
- package/skills/qc/qa-designer/exploratory/charter.md +68 -0
- package/skills/qc/qa-designer/exploratory/explore-to-functional.md +43 -0
- package/skills/qc/qa-designer/functional/api.md +45 -0
- package/skills/qc/qa-designer/functional/gui-feature.md +46 -0
- package/skills/qc/qa-designer/functional/gui-screen.md +52 -0
- package/skills/qc/qa-designer/integration/api.md +42 -0
- package/skills/qc/qa-designer/integration/db.md +39 -0
- package/skills/qc/qa-designer/integration/gui.md +40 -0
- package/skills/qc/qa-designer/integration/kafka.md +40 -0
- package/skills/qc/qa-designer/non-functional.md +40 -0
- package/skills/qc/qa-planner/test-plan.md +120 -0
- package/skills/qc/qa-reviewer/script/e2e.md +87 -0
- package/skills/qc/qa-reviewer/script/exploratory.md +45 -0
- package/skills/qc/qa-reviewer/script/functional.md +101 -0
- package/skills/qc/qa-reviewer/script/integration.md +91 -0
- package/skills/qc/qa-reviewer/script/non-functional.md +126 -0
- package/skills/qc/qa-reviewer/test-case/e2e.md +73 -0
- package/skills/qc/qa-reviewer/test-case/exploratory.md +43 -0
- package/skills/qc/qa-reviewer/test-case/functional.md +76 -0
- package/skills/qc/qa-reviewer/test-case/integration.md +69 -0
- package/skills/qc/qa-reviewer/test-case/non-functional.md +73 -0
- package/skills/qc/qa-runner/e2e.md +49 -0
- package/skills/qc/qa-runner/exploratory/session.md +36 -0
- package/skills/qc/qa-runner/functional/api.md +35 -0
- package/skills/qc/qa-runner/functional/gui-feature.md +51 -0
- package/skills/qc/qa-runner/functional/gui-screen.md +55 -0
- package/skills/qc/qa-runner/integration.md +47 -0
- package/skills/qc/qa-runner/non-functional.md +49 -0
- package/skills/qc/qa-runner/report/report.md +37 -0
- package/skills/setup-ai-first/SKILL.md +7 -0
- package/skills/spec/SKILL.md +14 -0
- package/skills/test/SKILL.md +93 -16
- package/steps/context-loader.md +36 -8
- package/steps/report-footer.md +7 -0
- package/templates/project-context.yaml +27 -1
- package/ARCHITECTURE.md +0 -258
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
|
|
|
@@ -221,19 +226,41 @@ If the file does not exist → skip silently.
|
|
|
221
226
|
|
|
222
227
|
---
|
|
223
228
|
|
|
224
|
-
## Step 3 — [CRITICAL] Load CLAUDE.md
|
|
229
|
+
## Step 3 — [CRITICAL] Load CLAUDE.md (layered: root + service overlay)
|
|
225
230
|
|
|
226
231
|
*This is the highest-priority context — it defines HOW to write code and documents for this project.*
|
|
227
232
|
|
|
228
|
-
|
|
233
|
+
CLAUDE.md is loaded in **two layers** so umbrella-wide rules and service-specific
|
|
234
|
+
architecture/coding standards compose correctly. The agent always sits at the umbrella
|
|
235
|
+
root, but the implementation code lives in a service submodule with its OWN stack,
|
|
236
|
+
architecture, and conventions — so the service's CLAUDE.md must win for code generation.
|
|
237
|
+
|
|
238
|
+
**Layer 1 — [BASE] Root CLAUDE.md (umbrella-wide).**
|
|
239
|
+
Read `CLAUDE.md` at the repo root. Treat its contents as the **shared baseline** for the
|
|
240
|
+
whole umbrella — git conventions, data-protection posture, cross-cutting rules, and (in
|
|
241
|
+
single-service mode) the project's only architecture + coding standards.
|
|
242
|
+
|
|
243
|
+
**Layer 2 — [OVERLAY] Service CLAUDE.md (umbrella mode only).**
|
|
244
|
+
*Run only if `service_root` was set in Step 1.6 (i.e. a real service was routed to).*
|
|
245
|
+
Read `{service_root}/CLAUDE.md`. This file defines the architecture + coding standards of
|
|
246
|
+
the **actual stack being implemented** (e.g. `user-service` = java-spring, `web` = nextjs).
|
|
247
|
+
Overlay it on top of Layer 1: **on any conflict, the service value WINS** for architecture,
|
|
248
|
+
coding standards, and error handling. Layer-1 values that the service does not redefine
|
|
249
|
+
(e.g. git conventions, banned patterns shared org-wide) remain in effect.
|
|
250
|
+
|
|
251
|
+
From the **merged** result, extract and store:
|
|
229
252
|
|
|
230
253
|
- **§1 Project Overview** → project name, language, framework, build/test commands, domains
|
|
231
|
-
- **§2 Architecture** → layer order (e.g., Controller → Facade → Service → Repository), architectural rules
|
|
232
|
-
- **§3 Coding Standards** → naming conventions (classes, methods), response wrapper type, forbidden patterns
|
|
233
|
-
- **§5 Error Handling** → exception types, HTTP status code mapping, not-found exception class name
|
|
234
|
-
- **§7 Git Conventions** → branch naming pattern, commit message format
|
|
254
|
+
- **§2 Architecture** → layer order (e.g., Controller → Facade → Service → Repository), architectural rules — *service overlay wins*
|
|
255
|
+
- **§3 Coding Standards** → naming conventions (classes, methods), response wrapper type, forbidden patterns — *service overlay wins*
|
|
256
|
+
- **§5 Error Handling** → exception types, HTTP status code mapping, not-found exception class name — *service overlay wins*
|
|
257
|
+
- **§7 Git Conventions** → branch naming pattern, commit message format — *root baseline unless service redefines*
|
|
235
258
|
|
|
236
|
-
|
|
259
|
+
**Resolution rules:**
|
|
260
|
+
- If both layers exist → merge as above; record `claude_md_source = root + {service_root}`.
|
|
261
|
+
- If only the service overlay exists (no root CLAUDE.md) → use the service file alone; `claude_md_source = {service_root}`.
|
|
262
|
+
- If `service_root` is set but `{service_root}/CLAUDE.md` is **missing** → fall back to root CLAUDE.md and flag ⚠️ in the Step 7 recap (the service has no architecture/coding-standards definition — code generation will use umbrella defaults, which may be the wrong stack).
|
|
263
|
+
- If neither exists → note CLAUDE.md as missing and continue with project-context.yaml data only.
|
|
237
264
|
|
|
238
265
|
---
|
|
239
266
|
|
|
@@ -333,7 +360,8 @@ Output exactly this block:
|
|
|
333
360
|
[CTX LOADED]
|
|
334
361
|
Stack : {language} / {framework} / {database}
|
|
335
362
|
Platform : {active_module} ({platform_type})
|
|
336
|
-
Layers : {layer order from CLAUDE.md §2, e.g., Controller → Facade → Service → Repository}
|
|
363
|
+
Layers : {layer order from merged CLAUDE.md §2, e.g., Controller → Facade → Service → Repository}
|
|
364
|
+
CLAUDE.md : {root + {service_root} | {service_root} only | root only | ⚠️ service overlay MISSING — using root | missing}
|
|
337
365
|
Ticket : {ticket_prefix}-
|
|
338
366
|
Dict : {loaded — N canonical terms, M banned terms | missing}
|
|
339
367
|
Entities : {loaded — EntityA, EntityB, EntityC | missing}
|
|
@@ -364,8 +392,9 @@ Proceed to the next step of the calling command.
|
|
|
364
392
|
---
|
|
365
393
|
|
|
366
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).
|
|
367
396
|
If ticket: fetch details (or ask user to paste).
|
|
368
|
-
If no ticket — CHECKPOINT:
|
|
397
|
+
If no ticket / BUG-ID — CHECKPOINT:
|
|
369
398
|
1. Where does the bug occur? (module, endpoint, flow)
|
|
370
399
|
2. Steps to reproduce?
|
|
371
400
|
3. Expected vs Actual?
|
|
@@ -438,7 +467,11 @@ Proceed? (Y/N)
|
|
|
438
467
|
```
|
|
439
468
|
|
|
440
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
|
+
|
|
441
473
|
```bash
|
|
474
|
+
cd {service_root} # umbrella: the service submodule; single-service: omit
|
|
442
475
|
git checkout -b fix/{TICKET_ID}-{description}
|
|
443
476
|
```
|
|
444
477
|
Apply fix. Add trace annotation if file has `@trace.implements`:
|
|
@@ -455,13 +488,37 @@ Test: "Regression {TICKET_ID}: {bug description}"
|
|
|
455
488
|
```
|
|
456
489
|
Run test. If fail → debug and fix (max 3 iterations).
|
|
457
490
|
|
|
458
|
-
## Phase 5 — Build & Commit
|
|
491
|
+
## Phase 5 — Build & Commit (2-layer push in umbrella mode)
|
|
459
492
|
```bash
|
|
460
|
-
{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):
|
|
461
495
|
git add {files}
|
|
462
496
|
git commit -m "fix({TICKET_ID}): {description}"
|
|
463
|
-
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
|
|
464
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).
|
|
465
522
|
|
|
466
523
|
## Phase 6 — Offer to Record a Lesson (optional)
|
|
467
524
|
|
|
@@ -596,6 +653,13 @@ Suggest the logical next command based on workflow phase:
|
|
|
596
653
|
| /generate-design-spec | Designer review → Figma links confirmed → PO + Designer sign-off → `/generate-bdd {prd-file}` |
|
|
597
654
|
| /generate-bdd | `/review-context {feature-file}` to verify coverage |
|
|
598
655
|
| /review-context (BDD) | `/generate-tech-docs {UC-ID}` if APPROVED; regenerate if NEEDS_FIX |
|
|
656
|
+
| /qc-analyze | `/qc-plan {UC-ID}` (resolve 🔴 blocker gaps first) |
|
|
657
|
+
| /qc-plan | `/qc-design-test {UC-ID}` |
|
|
658
|
+
| /qc-design-test | `/qc-review {UC-ID}` (test-case review) |
|
|
659
|
+
| /qc-review (test-case) | `/qc-run-test {UC-ID}` if APPROVED; fix TCs if NEEDS_FIX |
|
|
660
|
+
| /qc-run-test | `/qc-report {UC-ID}` then `/qc-review {UC-ID}` (script review) |
|
|
661
|
+
| /qc-review (script) | `/qc-report {UC-ID}` then create PR if APPROVED |
|
|
662
|
+
| /qc-report | `/validate-traces {UC-ID}` to refresh Living Docs (qc_status) |
|
|
599
663
|
| /generate-tech-docs | `/review-tech-docs {tech-design-file}` |
|
|
600
664
|
| /review-tech-docs | `/generate-code {feature-file}` if APPROVED; fix doc if NEEDS_FIX |
|
|
601
665
|
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/dev-gen-test {UC-ID}` |
|
|
@@ -627,7 +691,8 @@ Next : {suggested command with example arguments}
|
|
|
627
691
|
Root Cause: {analysis}
|
|
628
692
|
Changes: {list}
|
|
629
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}
|
|
630
695
|
{📝 Lesson L-NNN recorded (if captured)}
|
|
631
696
|
Branch: fix/{TICKET_ID}-{slug}
|
|
632
|
-
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}
|
|
633
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
|
|
|
@@ -219,19 +224,41 @@ If the file does not exist → skip silently.
|
|
|
219
224
|
|
|
220
225
|
---
|
|
221
226
|
|
|
222
|
-
## Step 3 — [CRITICAL] Load CLAUDE.md
|
|
227
|
+
## Step 3 — [CRITICAL] Load CLAUDE.md (layered: root + service overlay)
|
|
223
228
|
|
|
224
229
|
*This is the highest-priority context — it defines HOW to write code and documents for this project.*
|
|
225
230
|
|
|
226
|
-
|
|
231
|
+
CLAUDE.md is loaded in **two layers** so umbrella-wide rules and service-specific
|
|
232
|
+
architecture/coding standards compose correctly. The agent always sits at the umbrella
|
|
233
|
+
root, but the implementation code lives in a service submodule with its OWN stack,
|
|
234
|
+
architecture, and conventions — so the service's CLAUDE.md must win for code generation.
|
|
235
|
+
|
|
236
|
+
**Layer 1 — [BASE] Root CLAUDE.md (umbrella-wide).**
|
|
237
|
+
Read `CLAUDE.md` at the repo root. Treat its contents as the **shared baseline** for the
|
|
238
|
+
whole umbrella — git conventions, data-protection posture, cross-cutting rules, and (in
|
|
239
|
+
single-service mode) the project's only architecture + coding standards.
|
|
240
|
+
|
|
241
|
+
**Layer 2 — [OVERLAY] Service CLAUDE.md (umbrella mode only).**
|
|
242
|
+
*Run only if `service_root` was set in Step 1.6 (i.e. a real service was routed to).*
|
|
243
|
+
Read `{service_root}/CLAUDE.md`. This file defines the architecture + coding standards of
|
|
244
|
+
the **actual stack being implemented** (e.g. `user-service` = java-spring, `web` = nextjs).
|
|
245
|
+
Overlay it on top of Layer 1: **on any conflict, the service value WINS** for architecture,
|
|
246
|
+
coding standards, and error handling. Layer-1 values that the service does not redefine
|
|
247
|
+
(e.g. git conventions, banned patterns shared org-wide) remain in effect.
|
|
248
|
+
|
|
249
|
+
From the **merged** result, extract and store:
|
|
227
250
|
|
|
228
251
|
- **§1 Project Overview** → project name, language, framework, build/test commands, domains
|
|
229
|
-
- **§2 Architecture** → layer order (e.g., Controller → Facade → Service → Repository), architectural rules
|
|
230
|
-
- **§3 Coding Standards** → naming conventions (classes, methods), response wrapper type, forbidden patterns
|
|
231
|
-
- **§5 Error Handling** → exception types, HTTP status code mapping, not-found exception class name
|
|
232
|
-
- **§7 Git Conventions** → branch naming pattern, commit message format
|
|
252
|
+
- **§2 Architecture** → layer order (e.g., Controller → Facade → Service → Repository), architectural rules — *service overlay wins*
|
|
253
|
+
- **§3 Coding Standards** → naming conventions (classes, methods), response wrapper type, forbidden patterns — *service overlay wins*
|
|
254
|
+
- **§5 Error Handling** → exception types, HTTP status code mapping, not-found exception class name — *service overlay wins*
|
|
255
|
+
- **§7 Git Conventions** → branch naming pattern, commit message format — *root baseline unless service redefines*
|
|
233
256
|
|
|
234
|
-
|
|
257
|
+
**Resolution rules:**
|
|
258
|
+
- If both layers exist → merge as above; record `claude_md_source = root + {service_root}`.
|
|
259
|
+
- If only the service overlay exists (no root CLAUDE.md) → use the service file alone; `claude_md_source = {service_root}`.
|
|
260
|
+
- If `service_root` is set but `{service_root}/CLAUDE.md` is **missing** → fall back to root CLAUDE.md and flag ⚠️ in the Step 7 recap (the service has no architecture/coding-standards definition — code generation will use umbrella defaults, which may be the wrong stack).
|
|
261
|
+
- If neither exists → note CLAUDE.md as missing and continue with project-context.yaml data only.
|
|
235
262
|
|
|
236
263
|
---
|
|
237
264
|
|
|
@@ -331,7 +358,8 @@ Output exactly this block:
|
|
|
331
358
|
[CTX LOADED]
|
|
332
359
|
Stack : {language} / {framework} / {database}
|
|
333
360
|
Platform : {active_module} ({platform_type})
|
|
334
|
-
Layers : {layer order from CLAUDE.md §2, e.g., Controller → Facade → Service → Repository}
|
|
361
|
+
Layers : {layer order from merged CLAUDE.md §2, e.g., Controller → Facade → Service → Repository}
|
|
362
|
+
CLAUDE.md : {root + {service_root} | {service_root} only | root only | ⚠️ service overlay MISSING — using root | missing}
|
|
335
363
|
Ticket : {ticket_prefix}-
|
|
336
364
|
Dict : {loaded — N canonical terms, M banned terms | missing}
|
|
337
365
|
Entities : {loaded — EntityA, EntityB, EntityC | missing}
|
|
@@ -811,7 +839,7 @@ After generating all `.feature` files, create or update `{paths.trace_dir}/{UC-I
|
|
|
811
839
|
|
|
812
840
|
**TSV columns (tab-separated, one header row + one data row per scenario):**
|
|
813
841
|
```
|
|
814
|
-
sc_id\tsc_title\tspec_ver\tgen_ver\timplemented_by\ttest_count\ttest_classes\tdev_selftest\tdev_selftest_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
|
|
815
843
|
```
|
|
816
844
|
|
|
817
845
|
**Rules:**
|
|
@@ -819,7 +847,7 @@ sc_id\tsc_title\tspec_ver\tgen_ver\timplemented_by\ttest_count\ttest_classes\tde
|
|
|
819
847
|
- If file exists (re-generation) → for each SC in the new `.feature`:
|
|
820
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.
|
|
821
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.
|
|
822
|
-
- 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`, `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 `—`.
|
|
823
851
|
- SC no longer in `.feature` (removed) → delete its row.
|
|
824
852
|
|
|
825
853
|
**Values to write for each scenario:**
|
|
@@ -835,6 +863,10 @@ sc_id\tsc_title\tspec_ver\tgen_ver\timplemented_by\ttest_count\ttest_classes\tde
|
|
|
835
863
|
| `test_classes` | `—` |
|
|
836
864
|
| `dev_selftest` | `—` (no tests run yet) |
|
|
837
865
|
| `dev_selftest_at` | `—` |
|
|
866
|
+
| `qc_status` | `—` (official QC automation result — set by `/qc-run-test`) |
|
|
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`) |
|
|
838
870
|
| `prd_version` | `@trace.prd_version` from `.feature` header |
|
|
839
871
|
| `bdd_version` | `@trace.bdd_version` from `.feature` header |
|
|
840
872
|
| `tech_doc_revision` | `—` |
|
|
@@ -903,6 +935,13 @@ Suggest the logical next command based on workflow phase:
|
|
|
903
935
|
| /generate-design-spec | Designer review → Figma links confirmed → PO + Designer sign-off → `/generate-bdd {prd-file}` |
|
|
904
936
|
| /generate-bdd | `/review-context {feature-file}` to verify coverage |
|
|
905
937
|
| /review-context (BDD) | `/generate-tech-docs {UC-ID}` if APPROVED; regenerate if NEEDS_FIX |
|
|
938
|
+
| /qc-analyze | `/qc-plan {UC-ID}` (resolve 🔴 blocker gaps first) |
|
|
939
|
+
| /qc-plan | `/qc-design-test {UC-ID}` |
|
|
940
|
+
| /qc-design-test | `/qc-review {UC-ID}` (test-case review) |
|
|
941
|
+
| /qc-review (test-case) | `/qc-run-test {UC-ID}` if APPROVED; fix TCs if NEEDS_FIX |
|
|
942
|
+
| /qc-run-test | `/qc-report {UC-ID}` then `/qc-review {UC-ID}` (script review) |
|
|
943
|
+
| /qc-review (script) | `/qc-report {UC-ID}` then create PR if APPROVED |
|
|
944
|
+
| /qc-report | `/validate-traces {UC-ID}` to refresh Living Docs (qc_status) |
|
|
906
945
|
| /generate-tech-docs | `/review-tech-docs {tech-design-file}` |
|
|
907
946
|
| /review-tech-docs | `/generate-code {feature-file}` if APPROVED; fix doc if NEEDS_FIX |
|
|
908
947
|
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/dev-gen-test {UC-ID}` |
|
|
@@ -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\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`, `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:**
|
|
@@ -482,6 +482,10 @@ sc_id\tsc_title\tspec_ver\tgen_ver\timplemented_by\ttest_count\ttest_classes\tde
|
|
|
482
482
|
| `test_classes` | `—` |
|
|
483
483
|
| `dev_selftest` | `—` (no tests run yet) |
|
|
484
484
|
| `dev_selftest_at` | `—` |
|
|
485
|
+
| `qc_status` | `—` (official QC automation result — set by `/qc-run-test`) |
|
|
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`) |
|
|
485
489
|
| `prd_version` | `@trace.prd_version` from `.feature` header |
|
|
486
490
|
| `bdd_version` | `@trace.bdd_version` from `.feature` header |
|
|
487
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
|
|
|
@@ -221,19 +226,41 @@ If the file does not exist → skip silently.
|
|
|
221
226
|
|
|
222
227
|
---
|
|
223
228
|
|
|
224
|
-
## Step 3 — [CRITICAL] Load CLAUDE.md
|
|
229
|
+
## Step 3 — [CRITICAL] Load CLAUDE.md (layered: root + service overlay)
|
|
225
230
|
|
|
226
231
|
*This is the highest-priority context — it defines HOW to write code and documents for this project.*
|
|
227
232
|
|
|
228
|
-
|
|
233
|
+
CLAUDE.md is loaded in **two layers** so umbrella-wide rules and service-specific
|
|
234
|
+
architecture/coding standards compose correctly. The agent always sits at the umbrella
|
|
235
|
+
root, but the implementation code lives in a service submodule with its OWN stack,
|
|
236
|
+
architecture, and conventions — so the service's CLAUDE.md must win for code generation.
|
|
237
|
+
|
|
238
|
+
**Layer 1 — [BASE] Root CLAUDE.md (umbrella-wide).**
|
|
239
|
+
Read `CLAUDE.md` at the repo root. Treat its contents as the **shared baseline** for the
|
|
240
|
+
whole umbrella — git conventions, data-protection posture, cross-cutting rules, and (in
|
|
241
|
+
single-service mode) the project's only architecture + coding standards.
|
|
242
|
+
|
|
243
|
+
**Layer 2 — [OVERLAY] Service CLAUDE.md (umbrella mode only).**
|
|
244
|
+
*Run only if `service_root` was set in Step 1.6 (i.e. a real service was routed to).*
|
|
245
|
+
Read `{service_root}/CLAUDE.md`. This file defines the architecture + coding standards of
|
|
246
|
+
the **actual stack being implemented** (e.g. `user-service` = java-spring, `web` = nextjs).
|
|
247
|
+
Overlay it on top of Layer 1: **on any conflict, the service value WINS** for architecture,
|
|
248
|
+
coding standards, and error handling. Layer-1 values that the service does not redefine
|
|
249
|
+
(e.g. git conventions, banned patterns shared org-wide) remain in effect.
|
|
250
|
+
|
|
251
|
+
From the **merged** result, extract and store:
|
|
229
252
|
|
|
230
253
|
- **§1 Project Overview** → project name, language, framework, build/test commands, domains
|
|
231
|
-
- **§2 Architecture** → layer order (e.g., Controller → Facade → Service → Repository), architectural rules
|
|
232
|
-
- **§3 Coding Standards** → naming conventions (classes, methods), response wrapper type, forbidden patterns
|
|
233
|
-
- **§5 Error Handling** → exception types, HTTP status code mapping, not-found exception class name
|
|
234
|
-
- **§7 Git Conventions** → branch naming pattern, commit message format
|
|
254
|
+
- **§2 Architecture** → layer order (e.g., Controller → Facade → Service → Repository), architectural rules — *service overlay wins*
|
|
255
|
+
- **§3 Coding Standards** → naming conventions (classes, methods), response wrapper type, forbidden patterns — *service overlay wins*
|
|
256
|
+
- **§5 Error Handling** → exception types, HTTP status code mapping, not-found exception class name — *service overlay wins*
|
|
257
|
+
- **§7 Git Conventions** → branch naming pattern, commit message format — *root baseline unless service redefines*
|
|
235
258
|
|
|
236
|
-
|
|
259
|
+
**Resolution rules:**
|
|
260
|
+
- If both layers exist → merge as above; record `claude_md_source = root + {service_root}`.
|
|
261
|
+
- If only the service overlay exists (no root CLAUDE.md) → use the service file alone; `claude_md_source = {service_root}`.
|
|
262
|
+
- If `service_root` is set but `{service_root}/CLAUDE.md` is **missing** → fall back to root CLAUDE.md and flag ⚠️ in the Step 7 recap (the service has no architecture/coding-standards definition — code generation will use umbrella defaults, which may be the wrong stack).
|
|
263
|
+
- If neither exists → note CLAUDE.md as missing and continue with project-context.yaml data only.
|
|
237
264
|
|
|
238
265
|
---
|
|
239
266
|
|
|
@@ -333,7 +360,8 @@ Output exactly this block:
|
|
|
333
360
|
[CTX LOADED]
|
|
334
361
|
Stack : {language} / {framework} / {database}
|
|
335
362
|
Platform : {active_module} ({platform_type})
|
|
336
|
-
Layers : {layer order from CLAUDE.md §2, e.g., Controller → Facade → Service → Repository}
|
|
363
|
+
Layers : {layer order from merged CLAUDE.md §2, e.g., Controller → Facade → Service → Repository}
|
|
364
|
+
CLAUDE.md : {root + {service_root} | {service_root} only | root only | ⚠️ service overlay MISSING — using root | missing}
|
|
337
365
|
Ticket : {ticket_prefix}-
|
|
338
366
|
Dict : {loaded — N canonical terms, M banned terms | missing}
|
|
339
367
|
Entities : {loaded — EntityA, EntityB, EntityC | missing}
|
|
@@ -625,7 +653,7 @@ Update `{paths.trace_dir}/{UC-ID}.tsv` — for each implemented scenario, find t
|
|
|
625
653
|
| `fe_phase` | `ui` if `--phase=ui` \| `integrated` if `--phase=integration` \| `—` if no phase flag |
|
|
626
654
|
| `last_updated` | today `YYYY-MM-DD` |
|
|
627
655
|
|
|
628
|
-
Leave all other columns (`sc_title`, `spec_ver`, `prd_version`, `prd_status`, `uc_status`, `test_count`, `test_classes`, `dev_selftest`, `dev_selftest_at`) unchanged.
|
|
656
|
+
Leave all other columns (`sc_title`, `spec_ver`, `prd_version`, `prd_status`, `uc_status`, `test_count`, `test_classes`, `dev_selftest`, `dev_selftest_at`, `qc_status`, `qc_run_at`) unchanged.
|
|
629
657
|
`status` is computed by `/validate-traces` — do not set here.
|
|
630
658
|
|
|
631
659
|
## Refresh Panel Mirror
|
|
@@ -693,6 +721,13 @@ Suggest the logical next command based on workflow phase:
|
|
|
693
721
|
| /generate-design-spec | Designer review → Figma links confirmed → PO + Designer sign-off → `/generate-bdd {prd-file}` |
|
|
694
722
|
| /generate-bdd | `/review-context {feature-file}` to verify coverage |
|
|
695
723
|
| /review-context (BDD) | `/generate-tech-docs {UC-ID}` if APPROVED; regenerate if NEEDS_FIX |
|
|
724
|
+
| /qc-analyze | `/qc-plan {UC-ID}` (resolve 🔴 blocker gaps first) |
|
|
725
|
+
| /qc-plan | `/qc-design-test {UC-ID}` |
|
|
726
|
+
| /qc-design-test | `/qc-review {UC-ID}` (test-case review) |
|
|
727
|
+
| /qc-review (test-case) | `/qc-run-test {UC-ID}` if APPROVED; fix TCs if NEEDS_FIX |
|
|
728
|
+
| /qc-run-test | `/qc-report {UC-ID}` then `/qc-review {UC-ID}` (script review) |
|
|
729
|
+
| /qc-review (script) | `/qc-report {UC-ID}` then create PR if APPROVED |
|
|
730
|
+
| /qc-report | `/validate-traces {UC-ID}` to refresh Living Docs (qc_status) |
|
|
696
731
|
| /generate-tech-docs | `/review-tech-docs {tech-design-file}` |
|
|
697
732
|
| /review-tech-docs | `/generate-code {feature-file}` if APPROVED; fix doc if NEEDS_FIX |
|
|
698
733
|
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/dev-gen-test {UC-ID}` |
|
|
@@ -272,7 +272,7 @@ Update `{paths.trace_dir}/{UC-ID}.tsv` — for each implemented scenario, find t
|
|
|
272
272
|
| `fe_phase` | `ui` if `--phase=ui` \| `integrated` if `--phase=integration` \| `—` if no phase flag |
|
|
273
273
|
| `last_updated` | today `YYYY-MM-DD` |
|
|
274
274
|
|
|
275
|
-
Leave all other columns (`sc_title`, `spec_ver`, `prd_version`, `prd_status`, `uc_status`, `test_count`, `test_classes`, `dev_selftest`, `dev_selftest_at`) unchanged.
|
|
275
|
+
Leave all other columns (`sc_title`, `spec_ver`, `prd_version`, `prd_status`, `uc_status`, `test_count`, `test_classes`, `dev_selftest`, `dev_selftest_at`, `qc_status`, `qc_run_at`) unchanged.
|
|
276
276
|
`status` is computed by `/validate-traces` — do not set here.
|
|
277
277
|
|
|
278
278
|
## Refresh Panel Mirror
|
|
@@ -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
|
|
|
@@ -221,19 +226,41 @@ If the file does not exist → skip silently.
|
|
|
221
226
|
|
|
222
227
|
---
|
|
223
228
|
|
|
224
|
-
## Step 3 — [CRITICAL] Load CLAUDE.md
|
|
229
|
+
## Step 3 — [CRITICAL] Load CLAUDE.md (layered: root + service overlay)
|
|
225
230
|
|
|
226
231
|
*This is the highest-priority context — it defines HOW to write code and documents for this project.*
|
|
227
232
|
|
|
228
|
-
|
|
233
|
+
CLAUDE.md is loaded in **two layers** so umbrella-wide rules and service-specific
|
|
234
|
+
architecture/coding standards compose correctly. The agent always sits at the umbrella
|
|
235
|
+
root, but the implementation code lives in a service submodule with its OWN stack,
|
|
236
|
+
architecture, and conventions — so the service's CLAUDE.md must win for code generation.
|
|
237
|
+
|
|
238
|
+
**Layer 1 — [BASE] Root CLAUDE.md (umbrella-wide).**
|
|
239
|
+
Read `CLAUDE.md` at the repo root. Treat its contents as the **shared baseline** for the
|
|
240
|
+
whole umbrella — git conventions, data-protection posture, cross-cutting rules, and (in
|
|
241
|
+
single-service mode) the project's only architecture + coding standards.
|
|
242
|
+
|
|
243
|
+
**Layer 2 — [OVERLAY] Service CLAUDE.md (umbrella mode only).**
|
|
244
|
+
*Run only if `service_root` was set in Step 1.6 (i.e. a real service was routed to).*
|
|
245
|
+
Read `{service_root}/CLAUDE.md`. This file defines the architecture + coding standards of
|
|
246
|
+
the **actual stack being implemented** (e.g. `user-service` = java-spring, `web` = nextjs).
|
|
247
|
+
Overlay it on top of Layer 1: **on any conflict, the service value WINS** for architecture,
|
|
248
|
+
coding standards, and error handling. Layer-1 values that the service does not redefine
|
|
249
|
+
(e.g. git conventions, banned patterns shared org-wide) remain in effect.
|
|
250
|
+
|
|
251
|
+
From the **merged** result, extract and store:
|
|
229
252
|
|
|
230
253
|
- **§1 Project Overview** → project name, language, framework, build/test commands, domains
|
|
231
|
-
- **§2 Architecture** → layer order (e.g., Controller → Facade → Service → Repository), architectural rules
|
|
232
|
-
- **§3 Coding Standards** → naming conventions (classes, methods), response wrapper type, forbidden patterns
|
|
233
|
-
- **§5 Error Handling** → exception types, HTTP status code mapping, not-found exception class name
|
|
234
|
-
- **§7 Git Conventions** → branch naming pattern, commit message format
|
|
254
|
+
- **§2 Architecture** → layer order (e.g., Controller → Facade → Service → Repository), architectural rules — *service overlay wins*
|
|
255
|
+
- **§3 Coding Standards** → naming conventions (classes, methods), response wrapper type, forbidden patterns — *service overlay wins*
|
|
256
|
+
- **§5 Error Handling** → exception types, HTTP status code mapping, not-found exception class name — *service overlay wins*
|
|
257
|
+
- **§7 Git Conventions** → branch naming pattern, commit message format — *root baseline unless service redefines*
|
|
235
258
|
|
|
236
|
-
|
|
259
|
+
**Resolution rules:**
|
|
260
|
+
- If both layers exist → merge as above; record `claude_md_source = root + {service_root}`.
|
|
261
|
+
- If only the service overlay exists (no root CLAUDE.md) → use the service file alone; `claude_md_source = {service_root}`.
|
|
262
|
+
- If `service_root` is set but `{service_root}/CLAUDE.md` is **missing** → fall back to root CLAUDE.md and flag ⚠️ in the Step 7 recap (the service has no architecture/coding-standards definition — code generation will use umbrella defaults, which may be the wrong stack).
|
|
263
|
+
- If neither exists → note CLAUDE.md as missing and continue with project-context.yaml data only.
|
|
237
264
|
|
|
238
265
|
---
|
|
239
266
|
|
|
@@ -333,7 +360,8 @@ Output exactly this block:
|
|
|
333
360
|
[CTX LOADED]
|
|
334
361
|
Stack : {language} / {framework} / {database}
|
|
335
362
|
Platform : {active_module} ({platform_type})
|
|
336
|
-
Layers : {layer order from CLAUDE.md §2, e.g., Controller → Facade → Service → Repository}
|
|
363
|
+
Layers : {layer order from merged CLAUDE.md §2, e.g., Controller → Facade → Service → Repository}
|
|
364
|
+
CLAUDE.md : {root + {service_root} | {service_root} only | root only | ⚠️ service overlay MISSING — using root | missing}
|
|
337
365
|
Ticket : {ticket_prefix}-
|
|
338
366
|
Dict : {loaded — N canonical terms, M banned terms | missing}
|
|
339
367
|
Entities : {loaded — EntityA, EntityB, EntityC | missing}
|
|
@@ -827,6 +855,13 @@ Suggest the logical next command based on workflow phase:
|
|
|
827
855
|
| /generate-design-spec | Designer review → Figma links confirmed → PO + Designer sign-off → `/generate-bdd {prd-file}` |
|
|
828
856
|
| /generate-bdd | `/review-context {feature-file}` to verify coverage |
|
|
829
857
|
| /review-context (BDD) | `/generate-tech-docs {UC-ID}` if APPROVED; regenerate if NEEDS_FIX |
|
|
858
|
+
| /qc-analyze | `/qc-plan {UC-ID}` (resolve 🔴 blocker gaps first) |
|
|
859
|
+
| /qc-plan | `/qc-design-test {UC-ID}` |
|
|
860
|
+
| /qc-design-test | `/qc-review {UC-ID}` (test-case review) |
|
|
861
|
+
| /qc-review (test-case) | `/qc-run-test {UC-ID}` if APPROVED; fix TCs if NEEDS_FIX |
|
|
862
|
+
| /qc-run-test | `/qc-report {UC-ID}` then `/qc-review {UC-ID}` (script review) |
|
|
863
|
+
| /qc-review (script) | `/qc-report {UC-ID}` then create PR if APPROVED |
|
|
864
|
+
| /qc-report | `/validate-traces {UC-ID}` to refresh Living Docs (qc_status) |
|
|
830
865
|
| /generate-tech-docs | `/review-tech-docs {tech-design-file}` |
|
|
831
866
|
| /review-tech-docs | `/generate-code {feature-file}` if APPROVED; fix doc if NEEDS_FIX |
|
|
832
867
|
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/dev-gen-test {UC-ID}` |
|