@anhth2/spec-driven-dev-plugin 0.9.2 → 0.10.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/ARCHITECTURE.md +20 -9
- package/commands/debug.md +12 -12
- package/commands/define-product.md +11 -11
- package/commands/{generate-tests.md → dev-gen-test.md} +47 -15
- package/commands/{generate-tests.tmpl → dev-gen-test.tmpl} +18 -4
- package/{core/commands/run-tests.md → commands/dev-run-test.md} +61 -13
- package/commands/{run-tests.tmpl → dev-run-test.tmpl} +32 -2
- package/{core/commands/smoke-test.md → commands/dev-smoke-test.md} +16 -16
- package/commands/{smoke-test.tmpl → dev-smoke-test.tmpl} +5 -5
- package/commands/fix-bug.md +12 -12
- package/commands/generate-bdd.md +38 -13
- package/commands/generate-bdd.tmpl +9 -2
- package/commands/generate-code.md +85 -15
- package/commands/generate-code.tmpl +56 -4
- package/commands/generate-design-spec.md +104 -39
- package/commands/generate-design-spec.tmpl +93 -28
- package/commands/generate-prd.md +11 -11
- package/commands/generate-spec-manifest.md +11 -11
- package/commands/generate-tech-docs.md +12 -12
- package/commands/generate-tech-docs.tmpl +1 -1
- package/commands/learn.md +12 -12
- package/commands/propose-scenario.md +12 -12
- package/commands/propose-scenario.tmpl +1 -1
- package/commands/refine-prd.md +165 -16
- package/commands/refine-prd.tmpl +16 -5
- package/commands/report-bug.md +11 -11
- package/commands/review-code.md +13 -13
- package/commands/review-code.tmpl +1 -1
- package/commands/review-context.md +160 -12
- package/commands/review-context.tmpl +11 -1
- package/commands/review-tech-docs.md +11 -11
- package/commands/setup-ai-first.md +7 -7
- package/commands/sync.md +23 -20
- package/commands/sync.tmpl +16 -13
- package/commands/update-framework.md +7 -7
- package/commands/validate-traces.md +56 -37
- package/commands/validate-traces.tmpl +45 -26
- package/core/FRAMEWORK_VERSION +1 -1
- package/core/commands/debug.md +12 -12
- package/core/commands/define-product.md +11 -11
- package/core/commands/{generate-tests.md → dev-gen-test.md} +47 -15
- package/{commands/run-tests.md → core/commands/dev-run-test.md} +61 -13
- package/{commands/smoke-test.md → core/commands/dev-smoke-test.md} +16 -16
- package/core/commands/fix-bug.md +12 -12
- package/core/commands/generate-bdd.md +38 -13
- package/core/commands/generate-code.md +85 -15
- package/core/commands/generate-design-spec.md +104 -39
- package/core/commands/generate-prd.md +11 -11
- package/core/commands/generate-spec-manifest.md +11 -11
- package/core/commands/generate-tech-docs.md +12 -12
- package/core/commands/learn.md +12 -12
- package/core/commands/propose-scenario.md +12 -12
- package/core/commands/refine-prd.md +165 -16
- package/core/commands/report-bug.md +11 -11
- package/core/commands/review-code.md +13 -13
- package/core/commands/review-context.md +160 -12
- package/core/commands/review-tech-docs.md +11 -11
- package/core/commands/setup-ai-first.md +7 -7
- package/core/commands/sync.md +23 -20
- package/core/commands/update-framework.md +7 -7
- package/core/commands/validate-traces.md +56 -37
- package/core/skills/code/SKILL.md +18 -18
- package/core/skills/debug/SKILL.md +26 -26
- package/core/skills/design-spec/SKILL.md +11 -11
- package/core/skills/discovery/SKILL.md +11 -11
- package/core/skills/prd/SKILL.md +14 -14
- package/core/skills/setup-ai-first/SKILL.md +7 -7
- package/core/skills/spec/SKILL.md +14 -14
- package/core/skills/test/SKILL.md +38 -38
- package/core/steps/capture-lesson.md +1 -1
- package/core/steps/context-loader.md +4 -4
- package/core/steps/report-footer.md +7 -7
- package/core/steps/review-fanout.md +138 -0
- package/core/steps/spawn-agent.md +1 -1
- package/core/steps/trace-mirror.md +18 -0
- package/core/templates/design-spec.template.md +16 -8
- package/package.json +1 -1
- package/skills/code/SKILL.md +18 -18
- package/skills/debug/SKILL.md +26 -26
- package/skills/debug/SKILL.tmpl +1 -1
- package/skills/design-spec/SKILL.md +11 -11
- package/skills/discovery/SKILL.md +11 -11
- package/skills/prd/SKILL.md +14 -14
- package/skills/setup-ai-first/SKILL.md +7 -7
- package/skills/spec/SKILL.md +14 -14
- package/skills/test/SKILL.md +38 -38
- package/skills/test/SKILL.tmpl +9 -9
- package/steps/capture-lesson.md +1 -1
- package/steps/context-loader.md +4 -4
- package/steps/report-footer.md +7 -7
- package/steps/review-fanout.md +138 -0
- package/steps/spawn-agent.md +1 -1
- package/steps/trace-mirror.md +18 -0
- package/templates/design-spec.template.md +16 -8
package/commands/review-code.md
CHANGED
|
@@ -165,7 +165,7 @@ If `services` section is present:
|
|
|
165
165
|
|
|
166
166
|
**2. Route to service** — if active domain matches a key in `services`:
|
|
167
167
|
- Override `paths.specs_dir` → `services.{domain}.specs_dir`
|
|
168
|
-
- Override `paths.tech_docs_dir` → `services.{domain}.tech_docs_dir`
|
|
168
|
+
- Override `paths.tech_docs_dir` → `services.{domain}.tech_docs_dir` — **only if `setup.spec_source` is NOT set.** When `spec_source` IS set, the tech-design (API contract) is a cross-team artifact and must live in the shared spec repo (handled in step 4), so leave `tech_docs_dir` for step 4 to route — do NOT pin it per-service here.
|
|
169
169
|
- Store `active_service` = `services.{domain}.path`
|
|
170
170
|
- Store `active_service_module` = `services.{domain}.module`
|
|
171
171
|
- If service has its own `module` → use it as `active_module` (overrides `tech_stack.module`)
|
|
@@ -177,7 +177,7 @@ If `services` section is present:
|
|
|
177
177
|
**4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
|
|
178
178
|
- Override `paths.prd_dir` → `{spec_source}/specs/prd`
|
|
179
179
|
- Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
|
|
180
|
-
- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **
|
|
180
|
+
- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **always when `spec_source` is set** (step 2 no longer pins tech-docs per-service in this case). The tech-design IS the cross-team API contract: BE authors it here, and FE/App read it from the same spec submodule at `/generate-code --phase=integration`. *(Per-service tech-docs only happen when there is no `spec_source` — a pure multi-service BE repo with no shared spec module.)*
|
|
181
181
|
- Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
|
|
182
182
|
- Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
|
|
183
183
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
@@ -208,7 +208,7 @@ When `active_service` has been resolved to a real path in Step 1.5 (e.g., `user-
|
|
|
208
208
|
| `paths.specs_dir` | `{active_service}/{service paths.specs_dir}` (if set in service config, else keep Step 1.5 override) |
|
|
209
209
|
|
|
210
210
|
**3. Store** `service_root = {active_service}` as the working directory anchor for all downstream commands:
|
|
211
|
-
- Shell commands (`/run-
|
|
211
|
+
- Shell commands (`/dev-run-test`, `/dev-gen-test`) run **from within** `service_root`
|
|
212
212
|
- File write operations (test files, trace TSVs) use paths **relative to** `service_root`
|
|
213
213
|
|
|
214
214
|
**4. If service config not found** — keep umbrella defaults, still set `service_root = {active_service}` (path anchor is always needed even without a config override).
|
|
@@ -301,7 +301,7 @@ active_module = tech_stack.module (e.g. "java-spring", "react", "flutter")
|
|
|
301
301
|
|
|
302
302
|
If `tech_stack.module` is blank or not recognized → set `platform_type = "unknown"` and flag as ⚠️ in the Step 7 recap.
|
|
303
303
|
|
|
304
|
-
These two variables (`active_module`, `platform_type`) are the canonical source for all branching logic in commands that need platform-specific behavior (
|
|
304
|
+
These two variables (`active_module`, `platform_type`) are the canonical source for all branching logic in commands that need platform-specific behavior (dev-gen-test, debug, fix-bug, dev-smoke-test).
|
|
305
305
|
|
|
306
306
|
---
|
|
307
307
|
|
|
@@ -449,13 +449,13 @@ Suggest the logical next command based on workflow phase:
|
|
|
449
449
|
| /review-context (BDD) | `/generate-tech-docs {UC-ID}` if APPROVED; regenerate if NEEDS_FIX |
|
|
450
450
|
| /generate-tech-docs | `/review-tech-docs {tech-design-file}` |
|
|
451
451
|
| /review-tech-docs | `/generate-code {feature-file}` if APPROVED; fix doc if NEEDS_FIX |
|
|
452
|
-
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/
|
|
453
|
-
| /
|
|
454
|
-
| /run-
|
|
455
|
-
| /run-
|
|
456
|
-
| /review-code | `/smoke-test {UC-ID}` or create PR |
|
|
457
|
-
| /smoke-test | Create PR and link to ticket |
|
|
458
|
-
| /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/
|
|
452
|
+
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/dev-gen-test {UC-ID}` |
|
|
453
|
+
| /dev-gen-test | `/dev-run-test {UC-ID}` |
|
|
454
|
+
| /dev-run-test (passing) | `/review-code {UC-ID}` |
|
|
455
|
+
| /dev-run-test (failing) | `/fix-bug {ticket-id}` or `/debug {error}` |
|
|
456
|
+
| /review-code | `/dev-smoke-test {UC-ID}` or create PR |
|
|
457
|
+
| /dev-smoke-test | Create PR and link to ticket |
|
|
458
|
+
| /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/dev-gen-test {UC-ID}`; all OK → create PR |
|
|
459
459
|
| /fix-bug | Create PR and link to ticket |
|
|
460
460
|
| /debug | `/fix-bug {ticket-id}` if fix needed |
|
|
461
461
|
| /report-bug | Send to dev (`/fix-bug {BUG-ID}`); if coverage gap → `/propose-scenario {UC-ID}` |
|
|
@@ -491,7 +491,7 @@ Output Artifacts: none (read-only)
|
|
|
491
491
|
Verdict: APPROVED ✅ | NEEDS_FIX ❌
|
|
492
492
|
|
|
493
493
|
If APPROVED ✅:
|
|
494
|
-
Next: /
|
|
494
|
+
Next: /dev-gen-test {UC-ID}
|
|
495
495
|
|
|
496
496
|
If NEEDS_FIX ❌:
|
|
497
497
|
- Small fix (1–3 lines, no logic change) → fix inline → re-run /review-code {UC-ID}
|
|
@@ -570,7 +570,7 @@ If `lessons_path` does not exist, create it with this header first:
|
|
|
570
570
|
| code-gen | /generate-code output |
|
|
571
571
|
| bdd | /generate-bdd output |
|
|
572
572
|
| tech-docs | /generate-tech-docs output |
|
|
573
|
-
| tests | /
|
|
573
|
+
| tests | /dev-gen-test output |
|
|
574
574
|
| prd | /generate-prd, /refine-prd output |
|
|
575
575
|
| general | every command |
|
|
576
576
|
|
|
@@ -78,7 +78,7 @@ Output Artifacts: none (read-only)
|
|
|
78
78
|
Verdict: APPROVED ✅ | NEEDS_FIX ❌
|
|
79
79
|
|
|
80
80
|
If APPROVED ✅:
|
|
81
|
-
Next: /
|
|
81
|
+
Next: /dev-gen-test {UC-ID}
|
|
82
82
|
|
|
83
83
|
If NEEDS_FIX ❌:
|
|
84
84
|
- Small fix (1–3 lines, no logic change) → fix inline → re-run /review-code {UC-ID}
|
|
@@ -170,7 +170,7 @@ If `services` section is present:
|
|
|
170
170
|
|
|
171
171
|
**2. Route to service** — if active domain matches a key in `services`:
|
|
172
172
|
- Override `paths.specs_dir` → `services.{domain}.specs_dir`
|
|
173
|
-
- Override `paths.tech_docs_dir` → `services.{domain}.tech_docs_dir`
|
|
173
|
+
- Override `paths.tech_docs_dir` → `services.{domain}.tech_docs_dir` — **only if `setup.spec_source` is NOT set.** When `spec_source` IS set, the tech-design (API contract) is a cross-team artifact and must live in the shared spec repo (handled in step 4), so leave `tech_docs_dir` for step 4 to route — do NOT pin it per-service here.
|
|
174
174
|
- Store `active_service` = `services.{domain}.path`
|
|
175
175
|
- Store `active_service_module` = `services.{domain}.module`
|
|
176
176
|
- If service has its own `module` → use it as `active_module` (overrides `tech_stack.module`)
|
|
@@ -182,7 +182,7 @@ If `services` section is present:
|
|
|
182
182
|
**4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
|
|
183
183
|
- Override `paths.prd_dir` → `{spec_source}/specs/prd`
|
|
184
184
|
- Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
|
|
185
|
-
- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **
|
|
185
|
+
- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **always when `spec_source` is set** (step 2 no longer pins tech-docs per-service in this case). The tech-design IS the cross-team API contract: BE authors it here, and FE/App read it from the same spec submodule at `/generate-code --phase=integration`. *(Per-service tech-docs only happen when there is no `spec_source` — a pure multi-service BE repo with no shared spec module.)*
|
|
186
186
|
- Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
|
|
187
187
|
- Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
|
|
188
188
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
@@ -213,7 +213,7 @@ When `active_service` has been resolved to a real path in Step 1.5 (e.g., `user-
|
|
|
213
213
|
| `paths.specs_dir` | `{active_service}/{service paths.specs_dir}` (if set in service config, else keep Step 1.5 override) |
|
|
214
214
|
|
|
215
215
|
**3. Store** `service_root = {active_service}` as the working directory anchor for all downstream commands:
|
|
216
|
-
- Shell commands (`/run-
|
|
216
|
+
- Shell commands (`/dev-run-test`, `/dev-gen-test`) run **from within** `service_root`
|
|
217
217
|
- File write operations (test files, trace TSVs) use paths **relative to** `service_root`
|
|
218
218
|
|
|
219
219
|
**4. If service config not found** — keep umbrella defaults, still set `service_root = {active_service}` (path anchor is always needed even without a config override).
|
|
@@ -306,7 +306,7 @@ active_module = tech_stack.module (e.g. "java-spring", "react", "flutter")
|
|
|
306
306
|
|
|
307
307
|
If `tech_stack.module` is blank or not recognized → set `platform_type = "unknown"` and flag as ⚠️ in the Step 7 recap.
|
|
308
308
|
|
|
309
|
-
These two variables (`active_module`, `platform_type`) are the canonical source for all branching logic in commands that need platform-specific behavior (
|
|
309
|
+
These two variables (`active_module`, `platform_type`) are the canonical source for all branching logic in commands that need platform-specific behavior (dev-gen-test, debug, fix-bug, dev-smoke-test).
|
|
310
310
|
|
|
311
311
|
---
|
|
312
312
|
|
|
@@ -387,6 +387,154 @@ Derive the output findings filename:
|
|
|
387
387
|
|
|
388
388
|
---
|
|
389
389
|
|
|
390
|
+
## Review Procedure
|
|
391
|
+
# Exhaustive Review Fan-Out + Completeness Convergence
|
|
392
|
+
|
|
393
|
+
**Why this exists:** A single-pass review never lists every issue at once — the model
|
|
394
|
+
stops at "enough" findings, so each later review round surfaces *new* problems
|
|
395
|
+
(whack-a-mole). This procedure forces the review to **converge in one command run**:
|
|
396
|
+
fan out across review dimensions in parallel, then loop a completeness critic until a
|
|
397
|
+
round produces nothing new, *before* writing the findings file.
|
|
398
|
+
|
|
399
|
+
The calling command supplies two things:
|
|
400
|
+
- **DIMENSIONS** — the list of review dimensions to fan out over
|
|
401
|
+
(`/refine-prd` → the 4 lenses; `/review-context` → the P-checks or B-checks).
|
|
402
|
+
- **FINDINGS SCHEMA** — the YAML shape each finding must follow (defined in the command).
|
|
403
|
+
|
|
404
|
+
> **Sub-agent mode bypass:** If Gate Step 0 set `_agent_mode: true`, this whole
|
|
405
|
+
> procedure is **skipped** — the orchestrator is already running one dimension/UC per
|
|
406
|
+
> sub-agent. Run the command's checks directly on the scoped section and return findings.
|
|
407
|
+
|
|
408
|
+
---
|
|
409
|
+
|
|
410
|
+
## Phase 1 — Parallel dimension scan
|
|
411
|
+
|
|
412
|
+
**How many sub-agents:** the agent *count* is not the completeness lever — breadth is
|
|
413
|
+
fixed by the DIMENSION taxonomy (adding agents to the same dimension just re-finds the
|
|
414
|
+
same issues), and *depth* is owned by the Phase 2 critic loop. Pick the **fan-out
|
|
415
|
+
granularity** by target size, reusing the `steps/spawn-agent.md` thresholds:
|
|
416
|
+
|
|
417
|
+
| Target size | Granularity | Agent count |
|
|
418
|
+
|-------------|-------------|-------------|
|
|
419
|
+
| ≤ 3 UCs **and** ≤ 300 lines | one agent per DIMENSION over the whole file | = number of dimensions |
|
|
420
|
+
| > 3 UCs **or** > 300 lines | one agent per **DIMENSION × UC-scope** (UCs + a PRD-global scope), batched to fit the agent cap | `dimensions × (UCs + 1)`, capped (see below) |
|
|
421
|
+
|
|
422
|
+
The larger granularity keeps each sub-agent's context small and its scan exhaustive on a
|
|
423
|
+
single UC — which is what prevents misses on big PRDs.
|
|
424
|
+
|
|
425
|
+
> **Global (non-UC) sections — required in `DIMENSION × UC` mode.** Per-UC agents only
|
|
426
|
+
> see one UC each, so PRD-wide sections that belong to no UC (scope, success metrics,
|
|
427
|
+
> problem statement, terminology, glossary, changelog) would go unscanned. Whenever you
|
|
428
|
+
> fan out per UC, also include a **"PRD-global"** scope (the non-UC sections, findings get
|
|
429
|
+
> `uc_id: ""`) alongside the UC list. So the natural agent count is `dimensions × (UCs + 1)`.
|
|
430
|
+
> (Not needed in the whole-file mode — there each agent already sees the global sections.)
|
|
431
|
+
|
|
432
|
+
### Agent cap — batch UCs when the fan-out gets too wide
|
|
433
|
+
|
|
434
|
+
`dimensions × (UCs + 1)` can explode on large PRDs (e.g. 6 checks × (8 UCs + 1) = 54
|
|
435
|
+
agents). Cap the wave at **`AGENT_CAP = 12`** agents and batch UC scopes to fit:
|
|
436
|
+
|
|
437
|
+
1. Build the scope list = `[UC1, UC2, …, UCn, PRD-global]` (length `UCs + 1`).
|
|
438
|
+
2. Compute scopes-per-agent-bucket: `groups = max(1, floor(AGENT_CAP / dimensions))`.
|
|
439
|
+
- If `groups ≥ UCs + 1` → no batching needed, run one agent per `DIMENSION × scope`.
|
|
440
|
+
- Else split the scope list into `groups` contiguous buckets of roughly equal size
|
|
441
|
+
(keep `PRD-global` in its own bucket if it fits; otherwise append it to the last
|
|
442
|
+
bucket). Each agent then handles **one DIMENSION over one bucket of UCs**.
|
|
443
|
+
3. Resulting wave size = `dimensions × groups ≤ AGENT_CAP`.
|
|
444
|
+
|
|
445
|
+
A batched agent reviews several UCs at once — still scoped far tighter than the whole
|
|
446
|
+
file, so coverage stays high. `AGENT_CAP` is the only knob; raise it if the host allows
|
|
447
|
+
more concurrency, lower it to save tokens. Whole-file mode (≤ 3 UCs) never hits the cap.
|
|
448
|
+
|
|
449
|
+
Spawn the chosen sub-agents using the Agent tool (send them in a single message so they
|
|
450
|
+
run concurrently). Each sub-agent gets a **fresh context window** and scans its scope
|
|
451
|
+
through its **one** dimension only — deeper coverage than one session juggling every
|
|
452
|
+
dimension at once (avoids lost-in-the-middle).
|
|
453
|
+
|
|
454
|
+
Sub-agent prompt template (fill the braces):
|
|
455
|
+
|
|
456
|
+
```
|
|
457
|
+
You are a {DIMENSION_NAME} reviewer. Read the full target file at {target_file}.
|
|
458
|
+
Scope: review ONLY through the {DIMENSION_NAME} lens/check — {DIMENSION_DESCRIPTION}.
|
|
459
|
+
Be exhaustive: scan every section, every UC, every AC/BR/scenario. Do not stop early.
|
|
460
|
+
Project context (terminology, entities, architecture):
|
|
461
|
+
{slim_context — banned terms, canonical entities, layer order, domains}
|
|
462
|
+
|
|
463
|
+
Return a JSON array of findings, each:
|
|
464
|
+
{ "dimension": "{DIMENSION_NAME}", "severity": "critical|major|minor",
|
|
465
|
+
"section": "...", "uc_id": "...", "quote": "<verbatim ≤120 chars>",
|
|
466
|
+
"finding": "...", "suggestion": "...", "auto_fixable": true|false }
|
|
467
|
+
Return [] if this dimension is clean. Return ONLY the JSON array.
|
|
468
|
+
```
|
|
469
|
+
|
|
470
|
+
Collect every sub-agent's array into one consolidated list `ALL_FINDINGS`.
|
|
471
|
+
|
|
472
|
+
---
|
|
473
|
+
|
|
474
|
+
## Phase 2 — Completeness-critic convergence loop
|
|
475
|
+
|
|
476
|
+
This is the anti-whack-a-mole step. Repeat until **two consecutive rounds add zero new
|
|
477
|
+
findings**, or a hard cap of **3 rounds**, whichever comes first:
|
|
478
|
+
|
|
479
|
+
1. Spawn one **completeness-critic** sub-agent with the Agent tool. Give it:
|
|
480
|
+
- the full target file (`{target_file}`),
|
|
481
|
+
- the current `ALL_FINDINGS` list (so it knows what is already captured),
|
|
482
|
+
- the same slim context.
|
|
483
|
+
Prompt it:
|
|
484
|
+
```
|
|
485
|
+
Here is a document and a list of issues already found. Read the WHOLE document.
|
|
486
|
+
List ONLY real, additional issues NOT already in the list — gaps, ambiguities,
|
|
487
|
+
contradictions, missing edge/negative paths, coverage holes, terminology drift,
|
|
488
|
+
structural omissions, and any issue that a fix to an existing finding would expose.
|
|
489
|
+
Do NOT repeat anything already listed. Return the same finding JSON shape, or [] if
|
|
490
|
+
nothing new.
|
|
491
|
+
```
|
|
492
|
+
2. Append any genuinely new findings (not already in `ALL_FINDINGS`) to the list.
|
|
493
|
+
3. If this round returned 0 new → increment the dry-round counter; else reset it to 0.
|
|
494
|
+
4. Stop when dry-round counter reaches 2, or after 3 rounds total.
|
|
495
|
+
|
|
496
|
+
Record `convergence_rounds` (how many critic rounds ran) for the report.
|
|
497
|
+
|
|
498
|
+
---
|
|
499
|
+
|
|
500
|
+
## Phase 3 — Dedup, resolve conflicts, merge
|
|
501
|
+
|
|
502
|
+
Sub-agents run **blind to each other** (independence = diverse coverage). They never
|
|
503
|
+
talk or reconcile among themselves — all duplicate/conflict resolution happens **here in
|
|
504
|
+
the orchestrator**, where the full set is visible.
|
|
505
|
+
|
|
506
|
+
1. **Deduplicate** `ALL_FINDINGS`: two findings are duplicates if they target the same
|
|
507
|
+
`section` + `uc_id` and describe the same underlying issue. Keep the one with the
|
|
508
|
+
richer `suggestion`; if they differ on severity, keep the **higher** severity.
|
|
509
|
+
2. **Resolve conflicts** — group remaining findings by `section` + `uc_id` and check for
|
|
510
|
+
contradictions (two findings whose `suggestion`s cannot both be applied, or that
|
|
511
|
+
propose opposite fixes for the same spot):
|
|
512
|
+
- If the two suggestions can be **merged** into one coherent fix → merge them into a
|
|
513
|
+
single finding.
|
|
514
|
+
- If they are **mutually exclusive** → emit **one** finding that states both options
|
|
515
|
+
and set `auto_fixable: false` with `status: "needs_discussion"` (PRD) /
|
|
516
|
+
`status: "pending"` (review) so a human picks — never silently drop one side.
|
|
517
|
+
- If a finding is **invalidated** by another (e.g. a structural finding says a section
|
|
518
|
+
is missing, but another quotes content from it) → drop the invalid one.
|
|
519
|
+
3. **Sort** by severity (critical → major → minor), then by `section` order in the file.
|
|
520
|
+
4. **Assign stable IDs** `F001, F002, …` in that sorted order.
|
|
521
|
+
5. Map each finding's `dimension` into the command's schema field
|
|
522
|
+
(`lens` for `/refine-prd`; `check_id` for `/review-context`).
|
|
523
|
+
6. Write the **single** findings file in the FINDINGS SCHEMA the command defines.
|
|
524
|
+
|
|
525
|
+
In the command's final report, add one line:
|
|
526
|
+
```
|
|
527
|
+
Convergence: {convergence_rounds} critic round(s) — findings file is complete; re-running should surface 0 new issues.
|
|
528
|
+
```
|
|
529
|
+
|
|
530
|
+
|
|
531
|
+
**How the checks below map onto the procedure:**
|
|
532
|
+
- **DIMENSIONS** = the check groups for the detected mode — PRD: `P1, P2, P4, P5`; BDD: `B1, B2, B3, B4, B5, B6`. Fan out one sub-agent per check group, each scanning the full target file for just that group.
|
|
533
|
+
- **Orchestrator-run checks (not fanned out):** `P0` (umbrella routing) and `P3` (cross-PRD conflict) need config / other-PRD context — the orchestrator runs these itself **before** the fan-out and adds their results to `ALL_FINDINGS`.
|
|
534
|
+
- The completeness-critic loop (Phase 2) guarantees the findings file is complete in one run — re-running `/review-context` should surface **0 new** findings. Map each dimension into the `check_id` field of the schema below.
|
|
535
|
+
|
|
536
|
+
---
|
|
537
|
+
|
|
390
538
|
## PRD Review Mode
|
|
391
539
|
|
|
392
540
|
### P0 — Umbrella Routing Check (umbrella mode only)
|
|
@@ -633,13 +781,13 @@ Suggest the logical next command based on workflow phase:
|
|
|
633
781
|
| /review-context (BDD) | `/generate-tech-docs {UC-ID}` if APPROVED; regenerate if NEEDS_FIX |
|
|
634
782
|
| /generate-tech-docs | `/review-tech-docs {tech-design-file}` |
|
|
635
783
|
| /review-tech-docs | `/generate-code {feature-file}` if APPROVED; fix doc if NEEDS_FIX |
|
|
636
|
-
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/
|
|
637
|
-
| /
|
|
638
|
-
| /run-
|
|
639
|
-
| /run-
|
|
640
|
-
| /review-code | `/smoke-test {UC-ID}` or create PR |
|
|
641
|
-
| /smoke-test | Create PR and link to ticket |
|
|
642
|
-
| /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/
|
|
784
|
+
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/dev-gen-test {UC-ID}` |
|
|
785
|
+
| /dev-gen-test | `/dev-run-test {UC-ID}` |
|
|
786
|
+
| /dev-run-test (passing) | `/review-code {UC-ID}` |
|
|
787
|
+
| /dev-run-test (failing) | `/fix-bug {ticket-id}` or `/debug {error}` |
|
|
788
|
+
| /review-code | `/dev-smoke-test {UC-ID}` or create PR |
|
|
789
|
+
| /dev-smoke-test | Create PR and link to ticket |
|
|
790
|
+
| /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/dev-gen-test {UC-ID}`; all OK → create PR |
|
|
643
791
|
| /fix-bug | Create PR and link to ticket |
|
|
644
792
|
| /debug | `/fix-bug {ticket-id}` if fix needed |
|
|
645
793
|
| /report-bug | Send to dev (`/fix-bug {BUG-ID}`); if coverage gap → `/propose-scenario {UC-ID}` |
|
|
@@ -690,7 +838,7 @@ to the findings file as usual and left `status: pending`.
|
|
|
690
838
|
|
|
691
839
|
### Phase 1 — Run analysis
|
|
692
840
|
|
|
693
|
-
Run all checks (
|
|
841
|
+
Run all checks via the **Review Procedure** (fan-out + completeness loop) exactly as in the default mode.
|
|
694
842
|
Write the findings file with all `status: "pending"` as usual.
|
|
695
843
|
|
|
696
844
|
### Phase 2 — Apply auto-fixable findings
|
|
@@ -34,6 +34,16 @@ Derive the output findings filename:
|
|
|
34
34
|
|
|
35
35
|
---
|
|
36
36
|
|
|
37
|
+
## Review Procedure
|
|
38
|
+
{{include:steps/review-fanout.md}}
|
|
39
|
+
|
|
40
|
+
**How the checks below map onto the procedure:**
|
|
41
|
+
- **DIMENSIONS** = the check groups for the detected mode — PRD: `P1, P2, P4, P5`; BDD: `B1, B2, B3, B4, B5, B6`. Fan out one sub-agent per check group, each scanning the full target file for just that group.
|
|
42
|
+
- **Orchestrator-run checks (not fanned out):** `P0` (umbrella routing) and `P3` (cross-PRD conflict) need config / other-PRD context — the orchestrator runs these itself **before** the fan-out and adds their results to `ALL_FINDINGS`.
|
|
43
|
+
- The completeness-critic loop (Phase 2) guarantees the findings file is complete in one run — re-running `/review-context` should surface **0 new** findings. Map each dimension into the `check_id` field of the schema below.
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
37
47
|
## PRD Review Mode
|
|
38
48
|
|
|
39
49
|
### P0 — Umbrella Routing Check (umbrella mode only)
|
|
@@ -277,7 +287,7 @@ to the findings file as usual and left `status: pending`.
|
|
|
277
287
|
|
|
278
288
|
### Phase 1 — Run analysis
|
|
279
289
|
|
|
280
|
-
Run all checks (
|
|
290
|
+
Run all checks via the **Review Procedure** (fan-out + completeness loop) exactly as in the default mode.
|
|
281
291
|
Write the findings file with all `status: "pending"` as usual.
|
|
282
292
|
|
|
283
293
|
### Phase 2 — Apply auto-fixable findings
|
|
@@ -167,7 +167,7 @@ If `services` section is present:
|
|
|
167
167
|
|
|
168
168
|
**2. Route to service** — if active domain matches a key in `services`:
|
|
169
169
|
- Override `paths.specs_dir` → `services.{domain}.specs_dir`
|
|
170
|
-
- Override `paths.tech_docs_dir` → `services.{domain}.tech_docs_dir`
|
|
170
|
+
- Override `paths.tech_docs_dir` → `services.{domain}.tech_docs_dir` — **only if `setup.spec_source` is NOT set.** When `spec_source` IS set, the tech-design (API contract) is a cross-team artifact and must live in the shared spec repo (handled in step 4), so leave `tech_docs_dir` for step 4 to route — do NOT pin it per-service here.
|
|
171
171
|
- Store `active_service` = `services.{domain}.path`
|
|
172
172
|
- Store `active_service_module` = `services.{domain}.module`
|
|
173
173
|
- If service has its own `module` → use it as `active_module` (overrides `tech_stack.module`)
|
|
@@ -179,7 +179,7 @@ If `services` section is present:
|
|
|
179
179
|
**4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
|
|
180
180
|
- Override `paths.prd_dir` → `{spec_source}/specs/prd`
|
|
181
181
|
- Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
|
|
182
|
-
- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **
|
|
182
|
+
- Override `paths.tech_docs_dir` → `{spec_source}/specs/tech-docs` — **always when `spec_source` is set** (step 2 no longer pins tech-docs per-service in this case). The tech-design IS the cross-team API contract: BE authors it here, and FE/App read it from the same spec submodule at `/generate-code --phase=integration`. *(Per-service tech-docs only happen when there is no `spec_source` — a pure multi-service BE repo with no shared spec module.)*
|
|
183
183
|
- Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
|
|
184
184
|
- Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
|
|
185
185
|
- Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
|
|
@@ -210,7 +210,7 @@ When `active_service` has been resolved to a real path in Step 1.5 (e.g., `user-
|
|
|
210
210
|
| `paths.specs_dir` | `{active_service}/{service paths.specs_dir}` (if set in service config, else keep Step 1.5 override) |
|
|
211
211
|
|
|
212
212
|
**3. Store** `service_root = {active_service}` as the working directory anchor for all downstream commands:
|
|
213
|
-
- Shell commands (`/run-
|
|
213
|
+
- Shell commands (`/dev-run-test`, `/dev-gen-test`) run **from within** `service_root`
|
|
214
214
|
- File write operations (test files, trace TSVs) use paths **relative to** `service_root`
|
|
215
215
|
|
|
216
216
|
**4. If service config not found** — keep umbrella defaults, still set `service_root = {active_service}` (path anchor is always needed even without a config override).
|
|
@@ -303,7 +303,7 @@ active_module = tech_stack.module (e.g. "java-spring", "react", "flutter")
|
|
|
303
303
|
|
|
304
304
|
If `tech_stack.module` is blank or not recognized → set `platform_type = "unknown"` and flag as ⚠️ in the Step 7 recap.
|
|
305
305
|
|
|
306
|
-
These two variables (`active_module`, `platform_type`) are the canonical source for all branching logic in commands that need platform-specific behavior (
|
|
306
|
+
These two variables (`active_module`, `platform_type`) are the canonical source for all branching logic in commands that need platform-specific behavior (dev-gen-test, debug, fix-bug, dev-smoke-test).
|
|
307
307
|
|
|
308
308
|
---
|
|
309
309
|
|
|
@@ -616,13 +616,13 @@ Suggest the logical next command based on workflow phase:
|
|
|
616
616
|
| /review-context (BDD) | `/generate-tech-docs {UC-ID}` if APPROVED; regenerate if NEEDS_FIX |
|
|
617
617
|
| /generate-tech-docs | `/review-tech-docs {tech-design-file}` |
|
|
618
618
|
| /review-tech-docs | `/generate-code {feature-file}` if APPROVED; fix doc if NEEDS_FIX |
|
|
619
|
-
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/
|
|
620
|
-
| /
|
|
621
|
-
| /run-
|
|
622
|
-
| /run-
|
|
623
|
-
| /review-code | `/smoke-test {UC-ID}` or create PR |
|
|
624
|
-
| /smoke-test | Create PR and link to ticket |
|
|
625
|
-
| /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/
|
|
619
|
+
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/dev-gen-test {UC-ID}` |
|
|
620
|
+
| /dev-gen-test | `/dev-run-test {UC-ID}` |
|
|
621
|
+
| /dev-run-test (passing) | `/review-code {UC-ID}` |
|
|
622
|
+
| /dev-run-test (failing) | `/fix-bug {ticket-id}` or `/debug {error}` |
|
|
623
|
+
| /review-code | `/dev-smoke-test {UC-ID}` or create PR |
|
|
624
|
+
| /dev-smoke-test | Create PR and link to ticket |
|
|
625
|
+
| /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/dev-gen-test {UC-ID}`; all OK → create PR |
|
|
626
626
|
| /fix-bug | Create PR and link to ticket |
|
|
627
627
|
| /debug | `/fix-bug {ticket-id}` if fix needed |
|
|
628
628
|
| /report-bug | Send to dev (`/fix-bug {BUG-ID}`); if coverage gap → `/propose-scenario {UC-ID}` |
|
|
@@ -408,13 +408,13 @@ Suggest the logical next command based on workflow phase:
|
|
|
408
408
|
| /review-context (BDD) | `/generate-tech-docs {UC-ID}` if APPROVED; regenerate if NEEDS_FIX |
|
|
409
409
|
| /generate-tech-docs | `/review-tech-docs {tech-design-file}` |
|
|
410
410
|
| /review-tech-docs | `/generate-code {feature-file}` if APPROVED; fix doc if NEEDS_FIX |
|
|
411
|
-
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/
|
|
412
|
-
| /
|
|
413
|
-
| /run-
|
|
414
|
-
| /run-
|
|
415
|
-
| /review-code | `/smoke-test {UC-ID}` or create PR |
|
|
416
|
-
| /smoke-test | Create PR and link to ticket |
|
|
417
|
-
| /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/
|
|
411
|
+
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/dev-gen-test {UC-ID}` |
|
|
412
|
+
| /dev-gen-test | `/dev-run-test {UC-ID}` |
|
|
413
|
+
| /dev-run-test (passing) | `/review-code {UC-ID}` |
|
|
414
|
+
| /dev-run-test (failing) | `/fix-bug {ticket-id}` or `/debug {error}` |
|
|
415
|
+
| /review-code | `/dev-smoke-test {UC-ID}` or create PR |
|
|
416
|
+
| /dev-smoke-test | Create PR and link to ticket |
|
|
417
|
+
| /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/dev-gen-test {UC-ID}`; all OK → create PR |
|
|
418
418
|
| /fix-bug | Create PR and link to ticket |
|
|
419
419
|
| /debug | `/fix-bug {ticket-id}` if fix needed |
|
|
420
420
|
| /report-bug | Send to dev (`/fix-bug {BUG-ID}`); if coverage gap → `/propose-scenario {UC-ID}` |
|
package/commands/sync.md
CHANGED
|
@@ -248,13 +248,15 @@ For each entry in `services[]`:
|
|
|
248
248
|
|
|
249
249
|
## Step 4 — Check `.gitignore`
|
|
250
250
|
|
|
251
|
-
Check
|
|
251
|
+
Check the generated Living Docs mirrors are gitignored:
|
|
252
|
+
- `.trace/` in the current repo's `.gitignore` (or `.git/info/exclude`)
|
|
253
|
+
- `.living-docs/` in the **specs module's** `.gitignore` (when `setup.spec_source` is set)
|
|
252
254
|
|
|
253
|
-
If missing:
|
|
255
|
+
If either is missing:
|
|
254
256
|
```
|
|
255
|
-
⚠️
|
|
256
|
-
Add it to prevent accidentally committing generated trace artifacts:
|
|
257
|
+
⚠️ Living Docs mirrors not gitignored — they are generated, never commit them:
|
|
257
258
|
echo ".trace/" >> .gitignore
|
|
259
|
+
echo ".living-docs/" >> {spec_source}/.gitignore # specs module (if spec_source set)
|
|
258
260
|
```
|
|
259
261
|
|
|
260
262
|
---
|
|
@@ -263,20 +265,21 @@ If missing:
|
|
|
263
265
|
|
|
264
266
|
*Skip if `services` is empty.*
|
|
265
267
|
|
|
266
|
-
|
|
267
|
-
|
|
268
|
-
|
|
268
|
+
**Resolve the Living Docs home (same rule as `/validate-traces`):**
|
|
269
|
+
- `living_docs_dir` = `{spec_source}/.living-docs` if `setup.spec_source` is set, else `.living-docs` at umbrella root. *(The specs module is mounted inside every service workspace, so the panel resolves it even when a dev opens a single service submodule.)*
|
|
270
|
+
- `panel_mirror` = `./.trace` at the current workspace root.
|
|
269
271
|
|
|
270
|
-
|
|
271
|
-
|
|
272
|
-
-
|
|
273
|
-
-
|
|
272
|
+
1. For each service in `services[]`: if `{service.path}/.trace/` has `.tsv` files → copy them to `{living_docs_dir}/{service-name}/` (create dir if needed).
|
|
273
|
+
2. Write merged `{living_docs_dir}/trace-report.json`:
|
|
274
|
+
- Aggregate each service's `.trace/` TSVs, add `"service"` field per row, recalc summary totals.
|
|
275
|
+
3. **Mirror to the panel location:** copy `{living_docs_dir}/trace-report.json` (+ namespaced TSVs) → `{panel_mirror}/` so the panel in the currently-open repo is non-empty. Skip if `panel_mirror` already equals `living_docs_dir`.
|
|
274
276
|
|
|
275
277
|
Print sync result:
|
|
276
278
|
```
|
|
277
|
-
Living Docs →
|
|
279
|
+
Living Docs → {living_docs_dir}/ synced (canonical, specs module)
|
|
278
280
|
{service-name}: {N} TSVs
|
|
279
281
|
trace-report.json: {total} scenarios across {S} services
|
|
282
|
+
Panel mirror → {panel_mirror}/ (current workspace)
|
|
280
283
|
```
|
|
281
284
|
|
|
282
285
|
If no `.trace/` dirs found → `Living Docs: no trace data yet — run /generate-bdd then /generate-code first.`
|
|
@@ -334,13 +337,13 @@ Suggest the logical next command based on workflow phase:
|
|
|
334
337
|
| /review-context (BDD) | `/generate-tech-docs {UC-ID}` if APPROVED; regenerate if NEEDS_FIX |
|
|
335
338
|
| /generate-tech-docs | `/review-tech-docs {tech-design-file}` |
|
|
336
339
|
| /review-tech-docs | `/generate-code {feature-file}` if APPROVED; fix doc if NEEDS_FIX |
|
|
337
|
-
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/
|
|
338
|
-
| /
|
|
339
|
-
| /run-
|
|
340
|
-
| /run-
|
|
341
|
-
| /review-code | `/smoke-test {UC-ID}` or create PR |
|
|
342
|
-
| /smoke-test | Create PR and link to ticket |
|
|
343
|
-
| /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/
|
|
340
|
+
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/dev-gen-test {UC-ID}` |
|
|
341
|
+
| /dev-gen-test | `/dev-run-test {UC-ID}` |
|
|
342
|
+
| /dev-run-test (passing) | `/review-code {UC-ID}` |
|
|
343
|
+
| /dev-run-test (failing) | `/fix-bug {ticket-id}` or `/debug {error}` |
|
|
344
|
+
| /review-code | `/dev-smoke-test {UC-ID}` or create PR |
|
|
345
|
+
| /dev-smoke-test | Create PR and link to ticket |
|
|
346
|
+
| /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/dev-gen-test {UC-ID}`; all OK → create PR |
|
|
344
347
|
| /fix-bug | Create PR and link to ticket |
|
|
345
348
|
| /debug | `/fix-bug {ticket-id}` if fix needed |
|
|
346
349
|
| /report-bug | Send to dev (`/fix-bug {BUG-ID}`); if coverage gap → `/propose-scenario {UC-ID}` |
|
|
@@ -385,7 +388,7 @@ Service Configs
|
|
|
385
388
|
✅ user-service — test: mvn test | build: mvn compile
|
|
386
389
|
✅ order-service — test: mvn test | build: mvn compile
|
|
387
390
|
⚠️ payment-service — .agent/project-context.yaml missing
|
|
388
|
-
→ create it so /run-
|
|
391
|
+
→ create it so /dev-run-test works correctly
|
|
389
392
|
|
|
390
393
|
.gitignore
|
|
391
394
|
✅ .trace/ is gitignored
|
package/commands/sync.tmpl
CHANGED
|
@@ -248,13 +248,15 @@ For each entry in `services[]`:
|
|
|
248
248
|
|
|
249
249
|
## Step 4 — Check `.gitignore`
|
|
250
250
|
|
|
251
|
-
Check
|
|
251
|
+
Check the generated Living Docs mirrors are gitignored:
|
|
252
|
+
- `.trace/` in the current repo's `.gitignore` (or `.git/info/exclude`)
|
|
253
|
+
- `.living-docs/` in the **specs module's** `.gitignore` (when `setup.spec_source` is set)
|
|
252
254
|
|
|
253
|
-
If missing:
|
|
255
|
+
If either is missing:
|
|
254
256
|
```
|
|
255
|
-
⚠️
|
|
256
|
-
Add it to prevent accidentally committing generated trace artifacts:
|
|
257
|
+
⚠️ Living Docs mirrors not gitignored — they are generated, never commit them:
|
|
257
258
|
echo ".trace/" >> .gitignore
|
|
259
|
+
echo ".living-docs/" >> {spec_source}/.gitignore # specs module (if spec_source set)
|
|
258
260
|
```
|
|
259
261
|
|
|
260
262
|
---
|
|
@@ -263,20 +265,21 @@ If missing:
|
|
|
263
265
|
|
|
264
266
|
*Skip if `services` is empty.*
|
|
265
267
|
|
|
266
|
-
|
|
267
|
-
|
|
268
|
-
|
|
268
|
+
**Resolve the Living Docs home (same rule as `/validate-traces`):**
|
|
269
|
+
- `living_docs_dir` = `{spec_source}/.living-docs` if `setup.spec_source` is set, else `.living-docs` at umbrella root. *(The specs module is mounted inside every service workspace, so the panel resolves it even when a dev opens a single service submodule.)*
|
|
270
|
+
- `panel_mirror` = `./.trace` at the current workspace root.
|
|
269
271
|
|
|
270
|
-
|
|
271
|
-
|
|
272
|
-
-
|
|
273
|
-
-
|
|
272
|
+
1. For each service in `services[]`: if `{service.path}/.trace/` has `.tsv` files → copy them to `{living_docs_dir}/{service-name}/` (create dir if needed).
|
|
273
|
+
2. Write merged `{living_docs_dir}/trace-report.json`:
|
|
274
|
+
- Aggregate each service's `.trace/` TSVs, add `"service"` field per row, recalc summary totals.
|
|
275
|
+
3. **Mirror to the panel location:** copy `{living_docs_dir}/trace-report.json` (+ namespaced TSVs) → `{panel_mirror}/` so the panel in the currently-open repo is non-empty. Skip if `panel_mirror` already equals `living_docs_dir`.
|
|
274
276
|
|
|
275
277
|
Print sync result:
|
|
276
278
|
```
|
|
277
|
-
Living Docs →
|
|
279
|
+
Living Docs → {living_docs_dir}/ synced (canonical, specs module)
|
|
278
280
|
{service-name}: {N} TSVs
|
|
279
281
|
trace-report.json: {total} scenarios across {S} services
|
|
282
|
+
Panel mirror → {panel_mirror}/ (current workspace)
|
|
280
283
|
```
|
|
281
284
|
|
|
282
285
|
If no `.trace/` dirs found → `Living Docs: no trace data yet — run /generate-bdd then /generate-code first.`
|
|
@@ -325,7 +328,7 @@ Service Configs
|
|
|
325
328
|
✅ user-service — test: mvn test | build: mvn compile
|
|
326
329
|
✅ order-service — test: mvn test | build: mvn compile
|
|
327
330
|
⚠️ payment-service — .agent/project-context.yaml missing
|
|
328
|
-
→ create it so /run-
|
|
331
|
+
→ create it so /dev-run-test works correctly
|
|
329
332
|
|
|
330
333
|
.gitignore
|
|
331
334
|
✅ .trace/ is gitignored
|
|
@@ -163,13 +163,13 @@ Suggest the logical next command based on workflow phase:
|
|
|
163
163
|
| /review-context (BDD) | `/generate-tech-docs {UC-ID}` if APPROVED; regenerate if NEEDS_FIX |
|
|
164
164
|
| /generate-tech-docs | `/review-tech-docs {tech-design-file}` |
|
|
165
165
|
| /review-tech-docs | `/generate-code {feature-file}` if APPROVED; fix doc if NEEDS_FIX |
|
|
166
|
-
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/
|
|
167
|
-
| /
|
|
168
|
-
| /run-
|
|
169
|
-
| /run-
|
|
170
|
-
| /review-code | `/smoke-test {UC-ID}` or create PR |
|
|
171
|
-
| /smoke-test | Create PR and link to ticket |
|
|
172
|
-
| /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/
|
|
166
|
+
| /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/dev-gen-test {UC-ID}` |
|
|
167
|
+
| /dev-gen-test | `/dev-run-test {UC-ID}` |
|
|
168
|
+
| /dev-run-test (passing) | `/review-code {UC-ID}` |
|
|
169
|
+
| /dev-run-test (failing) | `/fix-bug {ticket-id}` or `/debug {error}` |
|
|
170
|
+
| /review-code | `/dev-smoke-test {UC-ID}` or create PR |
|
|
171
|
+
| /dev-smoke-test | Create PR and link to ticket |
|
|
172
|
+
| /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/dev-gen-test {UC-ID}`; all OK → create PR |
|
|
173
173
|
| /fix-bug | Create PR and link to ticket |
|
|
174
174
|
| /debug | `/fix-bug {ticket-id}` if fix needed |
|
|
175
175
|
| /report-bug | Send to dev (`/fix-bug {BUG-ID}`); if coverage gap → `/propose-scenario {UC-ID}` |
|