@dtlabs/ai-toolkit 0.16.1 → 0.16.3

package/CHANGELOG.md

@@ -1,4 +1,20 @@
 ## 0.1.4 (2026-07-21)
+## [0.16.3](https://github.com/dtlab-tech/ai-toolkit/compare/v0.16.2...v0.16.3) (2026-10-02)
+
+
+### Bug Fixes
+
+* **gaia-generate-work-breakdown:** forbid duplicate tasks and spannin… ([575a9d7](https://github.com/dtlab-tech/ai-toolkit/commit/575a9d702785b31f6d607e90e271fd179c20f58a))
+* **gaia-generate-work-breakdown:** forbid duplicate tasks and spanning test phases ([05a2510](https://github.com/dtlab-tech/ai-toolkit/commit/05a25103fb935e260df7740c6e4436e64f471ea4))
+
+## [0.16.2](https://github.com/dtlab-tech/ai-toolkit/compare/v0.16.1...v0.16.2) (2026-10-02)
+
+
+### Bug Fixes
+
+* **gaia-generate-work-breakdown:** forbid citing an AC outside its owning phase ([525e2ce](https://github.com/dtlab-tech/ai-toolkit/commit/525e2cef928dafb8b80470b572d214b85aecb1dc))
+* **gaia-generate-work-breakdown:** forbid citing an AC outside its owning phase ([5376d67](https://github.com/dtlab-tech/ai-toolkit/commit/5376d67a67140d5b46e507f2092e389d362ce723))
+
 ## [0.16.1](https://github.com/dtlab-tech/ai-toolkit/compare/v0.16.0...v0.16.1) (2026-10-02)
 
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dtlabs/ai-toolkit",
-  "version": "0.16.1",
+  "version": "0.16.3",
   "description": "AI Toolkit — reusable agents and procedures for developers to build AI-powered applications.",
   "files": [
     "docs/",

package/src/claude/agents/gaia-generate-work-breakdown.md

@@ -71,6 +71,8 @@ Every task must be the **smallest independently implementable, verifiable, and c
 - Titles or outcomes containing "N types", "all adapters", "complete CRUD", "implement and test" — these indicate hidden multiplicity.
 - Bundling two independently verifiable activities (e.g., "add endpoint and write tests") — split into separate tasks.
 - Scope misalignment: a task in US-02 that implements a behavior belonging to US-03.
+- **Duplicate implementation**: a later phase re-describing, as a new `BE`/`FE`/`DB` task, an outcome or file already fully produced by an earlier task (e.g., a controller task that already built audience-claim validation inline, followed by a later phase's task claiming to "implement" that same validation again). Check every earlier task's `outcome` before writing a new one for the same file or behavior. If the behavior already exists, the later phase's task must be `domain: TEST` (`developer-testing`), verifying it with `dependsOn` pointing at the task(s) that built it — never a second implementation task.
+- **Domain mismatch on verification-only tasks**: a task whose outcome is a confirmation of already-built behavior (title starting with "Verify", "Confirm", or similar) and whose verification commands are read-only (`grep`, `test -f`, build-only, no new file created) must be `domain: TEST` / `agentType: developer-testing` — never `BE`/`FE`/`DB` with an implementation agent type.
 
 ---
 
@@ -97,6 +99,8 @@ For each US, derive:
 - **Phase commit** — a phase-level commit object: `{ "type": "feat", "subject": "implement US-NN title" }` — the subject must not contain `|`, CR, or LF characters; `wb-render.js` prepends the conventional prefix automatically
 - **Acceptance Criteria** — the AC-XX IDs from the Requirements document that apply to this US
 
+**Do not create an additional phase for end-to-end, integration, or overall verification.** Every phase traces to exactly one UC (plus the single `INFRA` phase for shared setup) — never a synthesized "Testing and verification", "Integration tests", or similarly feature-spanning phase. An integration/E2E test still belongs to the US phase of the UC it most directly verifies, as a `domain: TEST` task citing only that phase's own AC(s) — not a phase of its own, and not a grab-bag of ACs borrowed from across the feature.
+
 ### Step 3 — Decompose into Tasks
 
 For each User Story (and for shared infrastructure), analyze the Tech-Spec to identify all concrete implementation tasks following the Atomicity Contract above.
@@ -128,7 +132,7 @@ Decomposition strategy by domain:
 | `domain` | string | One of: `BE`, `FE`, `DB`, `DevOps`, `INFRA`, `TEST` |
 | `agentType` | string | One of: `developer-backend`, `developer-frontend`, `developer-testing`, `review-solution` (deprecated: `developer-database` — maps to `developer-backend`) |
 | `dependsOn` | array of strings | Task IDs this task depends on; may be empty `[]`; all IDs must be defined within this same JSON |
-| `acceptanceCriteria` | array of strings | AC IDs from Requirements that this task covers; may be empty `[]` |
+| `acceptanceCriteria` | array of strings | AC IDs from Requirements scoped to this task's own phase that this task covers; may be empty `[]`. Never an AC owned by a different phase (see Guidelines) |
 | `verification` | object | `{ "commands": ["..."] }` — one or more shell commands that verify the task output; array must be non-empty |
 | `estimate` | object | `{ "agentMinutes": N, "tokens": N }` — target ≤ 15 minutes; positive integers |
 | `outputCount` | integer | Number of distinct outputs; must be ≥ 1 |
@@ -339,7 +343,7 @@ Do NOT guess or invent task decompositions when the source is unclear. Ask first
 - **Cross-phase dependencies are expected** — US tasks may depend on INFRA tasks; cross-US task dependencies are also valid
 - **INFRA phase first** (if present), then US phases in priority order (Must before Should before Could)
 - **Within a phase, order tasks by layer dependency** (DB → BE → FE → TEST); independent tasks within the same layer may be listed in any order
-- **acceptanceCriteria** must list AC IDs from the Requirements that this task covers; leave empty `[]` if the task covers no AC directly (e.g., pure infrastructure setup)
+- **acceptanceCriteria** must list only AC IDs whose Requirements AC-table scope ("Related UC") matches this task's own phase, or that are marked cross-cutting ("All UCs"/multiple UCs including this phase's). **Never cite an AC owned by a different phase on this task, even when this task is prerequisite or contributing work for it** — an INFRA task that lays groundwork for an AC verified in a later US does not "cover" that AC; leave `acceptanceCriteria` empty `[]` on that task instead (e.g., pure infrastructure setup, or groundwork for an AC owned elsewhere). If an AC is genuinely cross-cutting, reflect that in the AC's own "Related UC" column, not by citing it from an unrelated task.
 - **schemaVersion must be exactly 2** — do not omit it, do not use any other value
 - **No pipes, CR, or LF** in `phase.title`, `task.title`, or `commit.subject` — these characters break CSV generation
-- **Traceability**: every UC must map to a US phase; every Must-priority AC must be covered by at least one task's `acceptanceCriteria`
+- **Traceability**: every UC must map to a US phase; every Must-priority AC must be covered by at least one task's `acceptanceCriteria` **within that AC's own owning US phase** (per its "Related UC" scope) — not by a task in an earlier or later phase, even one that contributes toward satisfying it eventually