@dtlabs/ai-toolkit 0.16.2 → 0.16.3
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/CHANGELOG.md
CHANGED
|
@@ -1,4 +1,12 @@
|
|
|
1
1
|
## 0.1.4 (2026-07-21)
|
|
2
|
+
## [0.16.3](https://github.com/dtlab-tech/ai-toolkit/compare/v0.16.2...v0.16.3) (2026-10-02)
|
|
3
|
+
|
|
4
|
+
|
|
5
|
+
### Bug Fixes
|
|
6
|
+
|
|
7
|
+
* **gaia-generate-work-breakdown:** forbid duplicate tasks and spannin… ([575a9d7](https://github.com/dtlab-tech/ai-toolkit/commit/575a9d702785b31f6d607e90e271fd179c20f58a))
|
|
8
|
+
* **gaia-generate-work-breakdown:** forbid duplicate tasks and spanning test phases ([05a2510](https://github.com/dtlab-tech/ai-toolkit/commit/05a25103fb935e260df7740c6e4436e64f471ea4))
|
|
9
|
+
|
|
2
10
|
## [0.16.2](https://github.com/dtlab-tech/ai-toolkit/compare/v0.16.1...v0.16.2) (2026-10-02)
|
|
3
11
|
|
|
4
12
|
|
package/package.json
CHANGED
|
@@ -71,6 +71,8 @@ Every task must be the **smallest independently implementable, verifiable, and c
|
|
|
71
71
|
- Titles or outcomes containing "N types", "all adapters", "complete CRUD", "implement and test" — these indicate hidden multiplicity.
|
|
72
72
|
- Bundling two independently verifiable activities (e.g., "add endpoint and write tests") — split into separate tasks.
|
|
73
73
|
- Scope misalignment: a task in US-02 that implements a behavior belonging to US-03.
|
|
74
|
+
- **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.
|
|
75
|
+
- **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.
|
|
74
76
|
|
|
75
77
|
---
|
|
76
78
|
|
|
@@ -97,6 +99,8 @@ For each US, derive:
|
|
|
97
99
|
- **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
|
|
98
100
|
- **Acceptance Criteria** — the AC-XX IDs from the Requirements document that apply to this US
|
|
99
101
|
|
|
102
|
+
**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.
|
|
103
|
+
|
|
100
104
|
### Step 3 — Decompose into Tasks
|
|
101
105
|
|
|
102
106
|
For each User Story (and for shared infrastructure), analyze the Tech-Spec to identify all concrete implementation tasks following the Atomicity Contract above.
|