@dtlabs/ai-toolkit 0.24.3 → 0.24.5

package/CHANGELOG.md

@@ -1,4 +1,20 @@
 ## 0.1.4 (2026-07-21)
+## [0.24.5](https://github.com/dtlab-tech/ai-toolkit/compare/v0.24.4...v0.24.5) (2026-10-27)
+
+
+### Bug Fixes
+
+* **pm-phase2:** run the semantic WB validator per phase ([3f279e6](https://github.com/dtlab-tech/ai-toolkit/commit/3f279e6e386eee6c86cea90caec7e5d64b6aa756))
+* **pm-phase2:** run the semantic WB validator per phase, not once over the whole breakdown ([62389cb](https://github.com/dtlab-tech/ai-toolkit/commit/62389cbb8fcf70f4019ee83ed9f8a5a99a96dd23))
+
+## [0.24.4](https://github.com/dtlab-tech/ai-toolkit/compare/v0.24.3...v0.24.4) (2026-10-27)
+
+
+### Bug Fixes
+
+* **pm-phase2:** regenerate a task whose Estimate is stale, not just missing verification commands ([a772767](https://github.com/dtlab-tech/ai-toolkit/commit/a772767a9d960bfe468829651e7ca2cbc7c6a17e))
+* regenerate a task whose Estimate is stale, not just missing verification commands ([e9d794b](https://github.com/dtlab-tech/ai-toolkit/commit/e9d794b81575c49e95d0291174964058fafd009b))
+
 ## [0.24.3](https://github.com/dtlab-tech/ai-toolkit/compare/v0.24.2...v0.24.3) (2026-10-27)
 
 

package/package.json

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

package/src/claude/agents/gaia-validate-work-breakdown-semantic.md

@@ -1,8 +1,8 @@
 ---
 name: gaia-validate-work-breakdown-semantic
-description: "Semantic validator for Work Breakdown JSON — analyzes task coherence, scope alignment, and estimate realism. Runs after wb-validate.js exits 0. Input: path to {PREFIX}-Work-Breakdown.json"
+description: "Semantic validator for one phase of a Work Breakdown — analyzes task coherence, scope alignment, and estimate realism. Runs once per phase after wb-validate.js exits 0. Input: the phase's inlined task details, a scoped Requirements excerpt, and an index of other tasks"
 model: sonnet
-tools: Read, Glob, Grep
+tools: Read
 ---
 
 # Validate Work Breakdown — Semantic
@@ -15,17 +15,16 @@ You do NOT repeat structural checks (schema conformance, required fields, ID for
 
 ## Input
 
-The prompt gives you two paths, one per line, in this order:
+Your prompt directly inlines everything you need — you review ONE phase per call:
 
-1. The Work Breakdown directory (the split format, FTR-020) — contains `index.json` (the
-   validated skeleton, schema v2) plus `user-stories/*.md`/`tasks/*.md` detail files. Use Glob/Read
-   to explore it as needed; do not expect a single `{PREFIX}-Work-Breakdown.json` file.
-2. The Requirements source — `req/index.md` for a feature using the split Requirements format
-   (FTR-021; User Story descriptions and Acceptance Criteria text live in its own tables there,
-   unaffected by the per-UC split), or a legacy `{PREFIX}-Requirements.md` file otherwise. Read
-   whichever path is actually given — do not assume either shape.
+1. **Requirements source path** and a **scoped Requirements excerpt** — feature-wide sections in full, plus only the use case(s) this phase realizes.
+2. **The phase under review** — its id, type, title, and `sourceUC`.
+3. **Task details for THIS phase only** — the full detail file of every task in the phase. These are what you review.
+4. **Other tasks in the feature** — a one-line index (id — title — outcome) of every task outside this phase. Use it only to recognize a duplicate of work another phase already owns; do not review those tasks.
 
-Derive the prefix from the Work Breakdown directory's own `index.json`'s `feature` field.
+Do **not** read any file yourself. Do **not** explore the filesystem. Everything you need is in your prompt, and another call reviews every other phase.
+
+Because each call sees only one phase, cross-phase concerns are out of scope for you. Judge the tasks in front of you.
 
 ---
 
@@ -98,4 +97,4 @@ Or when issues are found:
 
 ## Tool use
 
-Use `Read` to load both files. Do not write any files. Do not produce any output other than the single JSON object described above.
+None needed — everything is inlined. Do not write any files. Do not produce any output other than the single JSON object described above.

package/src/claude/workflows/pm-phase2.js

@@ -375,6 +375,21 @@ function buildAgentsConventions(root) {
   return kept.length ? kept.join('\n').trim() : null
 }
 
+// Per-phase semantic validation prompt. The whole-WB validator used to receive a directory path and
+// explore it itself with Read/Glob/Grep — on a 123-task feature that single unbounded turn hit the
+// 30-minute worker ceiling, the same failure mode FTR-033 removed from skeleton generation. Each
+// call now sees only its own phase's task details, a one-line index of every OTHER task (for
+// duplicate-across-phases awareness), and that phase's scoped Requirements excerpt.
+function buildSemanticPhasePrompt(phase, taskDetailsText, otherTasksText, requirementsExcerpt, reqIndexPath) {
+  return [
+    `Requirements source: ${reqIndexPath}`,
+    `Phase under review:\n${JSON.stringify({ id: phase.id, type: phase.type, title: phase.title, sourceUC: phase.sourceUC }, null, 2)}`,
+    `Requirements (scoped to this phase's own sourceUC, plus feature-wide sections):\n${requirementsExcerpt}`,
+    `Task details for THIS phase (review these):\n${taskDetailsText}`,
+    `Other tasks in the feature (id — title — outcome; for cross-phase duplicate awareness only, do not review them):\n${otherTasksText || '(none)'}`,
+  ].join('\n\n')
+}
+
 // Compact prompt for the per-phase task-generation worker: this phase's own skeleton entry, its
 // scoped Requirements excerpt, the Tech-Spec skeleton, and every prior phase's own tasks as a
 // lightweight id/title/outcome/domain projection (never a later phase's tasks, which do not exist
@@ -440,6 +455,21 @@ function hasVerificationCommands(content) {
   return FENCE_RE_LOCAL.test(verifPart)
 }
 
+// Same resume-validity role as hasVerificationCommands, for the OTHER field this agent's own
+// prompt once asked it to merely restate (removed from "already given" wording in a prior fix —
+// see gaia-generate-work-breakdown-task.md's own Estimate section) but which a task file
+// generated BEFORE that fix can still carry as a literal "—" or explanatory prose instead of a
+// number: wbs-assembler.js's own _numberOrNull throws on exactly that shape at assembly time,
+// well after the dispatch loop below would have skipped regenerating it. A task file whose
+// Estimate fields are not both plain integers is treated the same as one with zero verification
+// commands — regenerated, not skipped forever — so a stale pre-fix file self-heals on the very
+// next resume instead of requiring a hand-fix or a one-off repair script.
+function hasValidEstimate(content) {
+  const minutes = content.match(/^- \*\*Estimate — agent minutes:\*\*\s*(.*)$/m)
+  const tokens = content.match(/^- \*\*Estimate — tokens:\*\*\s*(.*)$/m)
+  return !!minutes && !!tokens && /^\d+$/.test(minutes[1].trim()) && /^\d+$/.test(tokens[1].trim())
+}
+
 // Compact prompt for the per-task detail-generation worker: this task's own skeleton entry,
 // a sibling task list (id + title + outcome only, for duplicate-implementation awareness), and
 // the Tech-Spec excerpt (FTR-026: already pre-sliced to this task's own relevant component(s) by
@@ -637,7 +667,10 @@ return c.run(meta.name, featureDir, prefix, async () => {
     for (const taskId of phase.taskIds) {
       const task = index.tasks[taskId]
       const detailPath = `${wbsDir}/${task.detailFile}`
-      if (task.status === 'generated' && c.exists(detailPath) && hasVerificationCommands(c.read(detailPath))) continue // resume: skip, no dispatch
+      if (task.status === 'generated' && c.exists(detailPath)) {
+        const existing = c.read(detailPath)
+        if (hasVerificationCommands(existing) && hasValidEstimate(existing)) continue // resume: skip, no dispatch
+      }
       const techSpecExcerpt = hasSpec
         ? buildTaskTechSpecExcerpt(components, task, specDir, c.read(specIndexPath))
         : c.read(file('Tech-Spec.md')) // legacy fallback: unchanged, full text
@@ -660,11 +693,35 @@ return c.run(meta.name, featureDir, prefix, async () => {
     if (!parsed.valid || parsed.errors.length) throw new Error('Work breakdown structural validation failed: ' + res.stdout)
     return parsed
   })
-  const semantic = await c.worker('gaia.agent.planner.validate-work-breakdown',
-    `${wbsDir}\n${reqIndexPath}`, { schema: {
-      type: 'object', properties: { valid: { type: 'boolean' }, findings: { type: 'array' } }, required: ['valid', 'findings'],
-    } })
-  if (!semantic.valid || semantic.findings.some(f => f.blocking)) throw new Error('Work breakdown semantic validation failed')
+  // Every phase is reviewed even after one fails, so a single run surfaces every blocking finding
+  // at once instead of making the operator fix them one resume at a time.
+  const semanticSchema = {
+    type: 'object', properties: { valid: { type: 'boolean' }, findings: { type: 'array' } }, required: ['valid', 'findings'],
+  }
+  const reqIndexForSemantic = c.read(reqIndexPath)
+  const allFindings = []
+  let semanticValid = true
+  for (const phase of index.phases) {
+    const phaseTaskIds = phase.taskIds
+    const taskDetailsText = phaseTaskIds
+      .map(taskId => `### ${taskId}\n\n${c.read(`${wbsDir}/${index.tasks[taskId].detailFile}`)}`).join('\n\n---\n\n')
+    const otherTasksText = Object.entries(index.tasks)
+      .filter(([id]) => !phaseTaskIds.includes(id))
+      .map(([id, t]) => `- ${id} — ${t.title} — ${t.outcome}`).join('\n')
+    const requirementsExcerpt = hasReq
+      ? buildPhaseRequirementsExcerpt(reqIndexForSemantic, phase.sourceUC, reqDir)
+      : reqIndexForSemantic
+    const verdict = await c.worker('gaia.agent.planner.validate-work-breakdown',
+      buildSemanticPhasePrompt(phase, taskDetailsText, otherTasksText, requirementsExcerpt, reqIndexPath),
+      { schema: semanticSchema, label: `validate-work-breakdown:${phase.id}` })
+    if (!verdict.valid) semanticValid = false
+    for (const finding of verdict.findings) allFindings.push({ ...finding, phaseId: phase.id })
+  }
+  const semantic = { valid: semanticValid, findings: allFindings }
+  if (!semantic.valid || semantic.findings.some(f => f.blocking)) {
+    const blocking = semantic.findings.filter(f => f.blocking).map(f => `[${f.phaseId}] ${f.taskId}: ${f.description}`)
+    throw new Error('Work breakdown semantic validation failed' + (blocking.length ? ':\n' + blocking.join('\n') : ''))
+  }
   // FTR-025: wb-render.js is no longer called automatically here — nothing downstream ever read
   // {PREFIX}-Work-Breakdown.md/.csv (every real consumer already reads wbs/ directly via
   // wbs-assembler.js's loadWorkBreakdown()), so this view is now produced only on demand, via