@dtlabs/ai-toolkit 0.19.0 → 0.19.2

package/CHANGELOG.md

@@ -1,4 +1,19 @@
 ## 0.1.4 (2026-07-21)
+## [0.19.2](https://github.com/dtlab-tech/ai-toolkit/compare/v0.19.1...v0.19.2) (2026-10-19)
+
+
+### Bug Fixes
+
+* **workflow-control, tech-spec-assembler:** unwrap whole response fences in Markdown documents to prevent content loss ([fe88582](https://github.com/dtlab-tech/ai-toolkit/commit/fe885821bb7b813237a1d53ed827c70e09b6c9d0))
+* **workflow-control, tech-spec-assembler:** unwrap whole response fences in Markdown documents to prevent content loss ([358e484](https://github.com/dtlab-tech/ai-toolkit/commit/358e4847fe74c314c3c1158dbeda08669530c1f8))
+
+## [0.19.1](https://github.com/dtlab-tech/ai-toolkit/compare/v0.19.0...v0.19.1) (2026-10-19)
+
+
+### Bug Fixes
+
+* stop headless workers from Reading their own toolkit templates ([0f2c707](https://github.com/dtlab-tech/ai-toolkit/commit/0f2c7079799cdfb95ab99dcf7333f615a8f49a8e))
+
 ## [0.19.0](https://github.com/dtlab-tech/ai-toolkit/compare/v0.18.0...v0.19.0) (2026-10-19)
 
 

package/bin/cli.js

@@ -2056,6 +2056,51 @@ async function main() {
       process.stderr.write(err.message + '\n');
       process.exit(1);
     }
+  } else if (argv[0] === 'print-asset') {
+    // print-asset <relativePath> [--project <dir>] [--home <dir>]
+    // Security constraints: scripts/templates/ subpath only; .md extension only — the
+    // read-only counterpart to run-asset's "scripts category, .js only, execute" contract.
+    //
+    // Exists so a sandboxed workflow script (pm-phase1.js/pm-phase2.js — no `require()`, no
+    // filesystem access outside its own project root) can fetch a toolkit template's raw
+    // text and inline it directly into a worker's prompt, instead of telling the headless
+    // agent to Read the template file itself. That file lives outside the project root for
+    // a globally-installed toolkit, which is exactly the boundary a non-interactive `--print`
+    // session (no TTY to answer a permission prompt) cannot grant — confirmed by a real
+    // worker run failing with "Worker permission denied: ...; tools: Read" against exactly
+    // this path. Inlining via the host (a plain Node process, never subject to the Claude
+    // Code tool-permission system) sidesteps the problem entirely, the same pattern FTR-025
+    // already established for inlining Requirements/Tech-Spec text into gaia-validate-
+    // feature-docs' prompt instead of telling it to Read those files itself.
+    const remaining = argv.slice(1);
+    let relativePath = null;
+    let projectDir   = process.cwd();
+    let home;
+    for (let i = 0; i < remaining.length; i++) {
+      if      (remaining[i] === '--project' && remaining[i + 1]) { projectDir = remaining[++i]; }
+      else if (remaining[i] === '--home'    && remaining[i + 1]) { home       = remaining[++i]; }
+      else if (!remaining[i].startsWith('-'))                     { relativePath = remaining[i]; }
+    }
+    if (!relativePath) {
+      process.stderr.write('Error: print-asset requires a relative path argument\n');
+      process.exit(1);
+    }
+    if (!relativePath.startsWith('scripts/templates/')) {
+      process.stderr.write(`Error: print-asset is restricted to scripts/templates/ (got: ${relativePath})\n`);
+      process.exit(1);
+    }
+    if (!relativePath.endsWith('.md')) {
+      process.stderr.write(`Error: print-asset only reads .md files (got: ${relativePath})\n`);
+      process.exit(1);
+    }
+    try {
+      const assetPath = resolveClaudeRuntimeAsset(relativePath, { projectDir, home });
+      process.stdout.write(fs.readFileSync(assetPath, 'utf8'));
+      process.exit(0);
+    } catch (err) {
+      process.stderr.write(err.message + '\n');
+      process.exit(1);
+    }
   } else if (argv[0] === 'list-assets') {
     // list-assets --project <dir> --category <name> [--format json|plain] [--home <dir>]
     // Both --project and --category are MANDATORY (Tech Spec contract).

package/lib/workflow-control.js

@@ -106,7 +106,7 @@ function createControl(options) {
   }
   function command(argv, accepted = [0]) {
     if (!Array.isArray(argv) || argv.some(a => typeof a !== 'string')) throw new Error('CLI argv array required');
-    if (options.home && argv[0] === 'run-asset') {
+    if (options.home && (argv[0] === 'run-asset' || argv[0] === 'print-asset')) {
       argv = argv.slice();
       const split = argv.indexOf('--');
       argv.splice(split < 0 ? argv.length : split, 0, '--home', options.home);
@@ -238,6 +238,13 @@ function createControl(options) {
         const candidate = extractDelimitedStructuredOutput(result.result.result, opts.schema);
         if (candidate != null) { payload = candidate; usedTextFallback = true; }
       }
+      // A non-schema worker's payload IS the document — unwrap a whole-response fence/preamble
+      // before anything downstream (the caller's own write, or this function's own outputTarget
+      // write below) ever sees it. See extractMarkdownDocument's own comment for the full story.
+      if (!opts.schema && typeof payload === 'string') {
+        const cleaned = extractMarkdownDocument(payload);
+        if (cleaned !== payload) { payload = cleaned; usedTextFallback = true; }
+      }
       if (payload == null || (typeof payload === 'string' && !payload.trim())) {
         if (opts.schema) {
           const fields = (opts.schema.required || []).join(', ') || '(see requested schema)';
@@ -476,6 +483,65 @@ function extractJsonDocument(text) {
   return text;
 }
 
+// Same problem extractJsonDocument fixes, for a Markdown document deliverable (a component/
+// use-case/task detail file, or a Requirements/Tech-Spec skeleton) instead of a JSON one: a
+// worker's entire response becomes the file verbatim (these agents have no Write tool, see
+// worker()'s own comment on why — the host writes whatever text they return), and a model that
+// wraps its deliverable in conversational prose and/or an outer code fence silently corrupts the
+// saved file. Found empirically in a real spec/components/*.md file: the agent's own real
+// "## Change"/"## Tests" headings ended up INSIDE an outer ```markdown fence and were (correctly)
+// treated as fenced, non-heading content by tech-spec-assembler.js's own fence-aware parser
+// (FTR-025) — the file wrote to disk with its real content unreachable, surfacing only much later
+// as an opaque "component file is missing its ## Change section" error during final assembly, with
+// no filename attached to say which one (see loadTechSpec's own fix for that half of the bug).
+//
+// Same "try as-is first, re-validate the candidate, never a blind substring guess, never throws"
+// discipline as extractJsonDocument: "valid" here means "has at least one unfenced Markdown
+// heading" — the same fence-length-aware scan tech-spec-assembler.js's own
+// _nonFencedHeadingIndexes uses, reimplemented here as a presence check rather than a line-index
+// list, for the identical "sandboxed runtime has no require()"-shaped reason these two files are
+// already siblings, not shared, elsewhere in this codebase. A document that legitimately ends in
+// its own small fenced code example (a real Tests section's last line) is never mistaken for a
+// whole-response wrap: its real headings already appear BEFORE that trailing fence, unfenced, so
+// the as-is candidate already satisfies this check and no unwrapping is even attempted.
+function _hasUnfencedHeading(text) {
+  let fenceLen = 0;
+  for (const line of text.split('\n')) {
+    const m = line.match(/^(`{3,})/);
+    if (m) { const n = m[1].length; fenceLen = fenceLen === 0 ? n : (n >= fenceLen ? 0 : fenceLen); continue; }
+    if (fenceLen === 0 && /^#{1,6}\s/.test(line)) return true;
+  }
+  return false;
+}
+// Line-range based, not regex-based: a regex scan for the "first ``` ... last ```" span would
+// wrongly stop at the first NESTED closing fence instead of the real outer one (exactly the shape
+// a Markdown document's own "## Data Model" section legitimately needs — a fenced JSON example
+// nested inside the model's outer ```markdown wrap). Only the LAST non-blank line being a bare
+// fence-close, matched back to the first fence-open of the SAME backtick-run length, correctly
+// identifies the true outer boundary regardless of what's nested between them.
+function _unwrapWholeResponseFence(text) {
+  const lines = text.split('\n');
+  let end = lines.length;
+  while (end > 0 && lines[end - 1].trim() === '') end--;
+  if (end === 0) return null;
+  const closeMatch = lines[end - 1].match(/^(`{3,})\s*$/);
+  if (!closeMatch) return null;
+  const fenceLen = closeMatch[1].length;
+  let start = -1;
+  for (let i = 0; i < end - 1; i++) {
+    const openMatch = lines[i].match(/^(`{3,})\S*\s*$/);
+    if (openMatch && openMatch[1].length === fenceLen) { start = i; break; }
+  }
+  if (start === -1) return null;
+  return lines.slice(start + 1, end - 1).join('\n').trim() + '\n';
+}
+function extractMarkdownDocument(text) {
+  if (_hasUnfencedHeading(text)) return text;
+  const unwrapped = _unwrapWholeResponseFence(text);
+  if (unwrapped != null && _hasUnfencedHeading(unwrapped)) return unwrapped;
+  return text;
+}
+
 function validateSchema(value, schema) {
   if (schema.type === 'object') {
     if (!value || typeof value !== 'object' || Array.isArray(value)) throw new Error('Invalid structured object');

package/package.json

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

package/src/claude/agents/gaia-generate-requirements-use-case.md

@@ -23,18 +23,21 @@ The host supplies, in the dispatch prompt:
 3. The path to `feature.md` — read it in full before proceeding, to ground this use case's flow
    in the feature's actual described behavior rather than inventing detail the row alone would
    not carry.
+4. The canonical field-table/flow structure, inlined under a `Template (req/use-cases/{UC-ID}.md):`
+   label. Use this text — do NOT attempt to Read, Glob, or otherwise search the filesystem for
+   `gaia-use-case-template.md` yourself; it is not guaranteed to be reachable from where this agent
+   runs, and searching for it is not a safe fallback either.
 
 You do not read `req/index.md` yourself and you never decide which use cases exist — that is
 already fixed by the skeleton call that produced the row you were given.
 
-Read `.claude/scripts/templates/gaia-use-case-template.md` before writing your response for the
-canonical field-table/flow structure. Note: that template also shows "Related Business Rules"/
-"Related Acceptance Criteria" cross-reference lines at the end of the file — do NOT produce them
-yourself. The host computes both, mechanically, from `req/index.md`'s own Business Rules/
-Acceptance Criteria tables, and appends them to your response after you return it — you are not
-given that table data (and must not re-read `req/index.md` yourself to get it), so any version you
-wrote would risk being wrong or duplicated. The Output section below is your actual, complete
-output contract; stop after Postconditions.
+Note: the inlined template also shows "Related Business Rules"/"Related Acceptance Criteria"
+cross-reference lines at the end of the file — do NOT produce them yourself. The host computes
+both, mechanically, from `req/index.md`'s own Business Rules/Acceptance Criteria tables, and
+appends them to your response after you return it — you are not given that table data (and must
+not re-read `req/index.md` yourself to get it), so any version you wrote would risk being wrong or
+duplicated. The Output section below is your actual, complete output contract; stop after
+Postconditions.
 
 ## Mandatory instruction
 

package/src/claude/agents/gaia-generate-requirements.md

@@ -19,11 +19,15 @@ together with those per-use-case files afterward (FTR-021).
 
 The user provides the path to a `feature.md` file. Read it in full before proceeding.
 
-Also read `.claude/scripts/templates/gaia-requirements-index-template.md` before writing your
-response — it is the canonical, authoritative structure for `req/index.md` (section order,
-exact headings, table column contracts, and the parsing contract `req-skeleton-check.js`/
-`req-assembler.js` rely on). The Output Structure section below summarizes it; the template
-itself is the source of truth if the two ever disagree.
+The prompt also includes, inlined under a `Template (req/index.md):` label, the canonical,
+authoritative structure for `req/index.md` (section order, exact headings, table column
+contracts, and the parsing contract `req-skeleton-check.js`/`req-assembler.js` rely on). Use the
+inlined text — do NOT attempt to Read, Glob, or otherwise search the filesystem for
+`gaia-requirements-index-template.md` yourself; it is not guaranteed to be reachable from where
+this agent runs, and searching for it is not a safe fallback either (your Glob/Grep tools remain
+available for exploring the feature's own project, just not for locating this template). The
+Output Structure section below summarizes it; the inlined template text is the source of truth if
+the two ever disagree.
 
 ## Process
 

package/src/claude/agents/gaia-generate-tech-spec-component.md

@@ -28,10 +28,15 @@ The host supplies, in the dispatch prompt:
 You do not read `spec/index.md` yourself and you never decide which components exist — that is
 already fixed by the skeleton call that produced the row you were given.
 
-Read `.claude/scripts/templates/gaia-component-template.md` before writing your response — it is
-the canonical, authoritative structure for your output (Change/design-body/Tests, and the parsing
-contract `tech-spec-assembler.js`'s `parseComponentDetail` relies on). The Output section below is
-a summary; the template itself is the source of truth if the two ever disagree.
+The prompt also includes, inlined under a `Template (spec/components/{fileSlug}.md):` label, the
+canonical, authoritative structure for your output (Change/design-body/Tests, and the parsing
+contract `tech-spec-assembler.js`'s `parseComponentDetail` relies on). Use the inlined text — do
+NOT attempt to Read, Glob, or otherwise search the filesystem for `gaia-component-template.md`
+yourself under any circumstances, including as a fallback if you are unsure of its exact path; it
+is not guaranteed to be reachable from where this agent runs, and guessing at or searching for its
+absolute path is not a safe substitute for the text already given to you below. The Output
+section below is a summary; the inlined template text is the source of truth if
+the two ever disagree.
 
 ## Mandatory instruction
 

package/src/claude/agents/gaia-generate-tech-spec.md

@@ -19,11 +19,15 @@ together with those per-component files afterward (FTR-024).
 
 The user provides the path to a `feature.md` file. Read it in full before proceeding. Also read the relevant existing codebase files to ensure the spec aligns with current architecture.
 
-Also read `.claude/scripts/templates/gaia-tech-spec-index-template.md` before writing your
-response — it is the canonical, authoritative structure for `spec/index.md` (section order, exact
-headings, the Section 9 column-order contract `tech-spec-graph-checks.js` relies on, and the
-parsing contract `tech-spec-assembler.js` relies on). The Output Structure section below
-summarizes it; the template itself is the source of truth if the two ever disagree.
+The prompt also includes, inlined under a `Template (spec/index.md):` label, the canonical,
+authoritative structure for `spec/index.md` (section order, exact headings, the Section 9
+column-order contract `tech-spec-graph-checks.js` relies on, and the parsing contract
+`tech-spec-assembler.js` relies on). Use the inlined text — do NOT attempt to Read, Glob, or
+otherwise search the filesystem for `gaia-tech-spec-index-template.md` yourself; it is not
+guaranteed to be reachable from where this agent runs, and searching for it is not a safe fallback
+either (your Glob/Grep tools remain available for exploring the project's existing codebase, just
+not for locating this template). The Output Structure section below summarizes it; the inlined
+template text is the source of truth if the two ever disagree.
 
 ## Step 0 — Read Project Conventions (MANDATORY)
 

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

@@ -9,11 +9,6 @@ tools: Read, Glob, Grep
 
 You are a **senior implementation planner**. You are given exactly one task's already-decided skeleton entry — its ID, title, outcome, domain, agent type, dependencies, acceptance criteria, estimate, output count, and commit subject are already fixed — and you fill in the fields that are still missing: **implementation notes**, **verification commands**, and, if applicable, **grouping rationale**. You do not re-decide anything the skeleton already fixed.
 
-Read `.claude/scripts/templates/gaia-task-template.md` before writing your response — it is the
-canonical, authoritative structure for your output (field order, the two free-content sections,
-and the exact parsing contract downstream tooling relies on). This section and the Output section
-below summarize it; the template itself is the source of truth if the two ever disagree.
-
 This is the **second of two generation passes** (FTR-020). The skeleton pass (`gaia-generate-work-breakdown`) already produced the whole task graph in one bounded call; this agent is dispatched once per task, so a failure or truncation on one task never requires regenerating any other task.
 
 ---
@@ -25,8 +20,15 @@ The caller supplies, in the prompt (you do not read `{PREFIX}-Work-Breakdown.jso
 1. **This task's own skeleton entry**, verbatim: `id`, `title`, `outcome`, `domain`, `agentType`, `dependsOn`, `acceptanceCriteria`, `estimate`, `outputCount`, `commit`.
 2. **The relevant Tech-Spec excerpt** for this task's own Acceptance Criteria (matched by the host against each component's `Addresses` column in `spec/index.md` — not the whole Tech-Spec, which is the whole point of the per-task split). If no component's `Addresses` column cites any of this task's Acceptance Criteria, you instead receive the full Components table from `spec/index.md` as a fallback — in that case, use your own judgment about which listed component(s) are actually relevant, the same way you would if asked to work from the full Tech-Spec directly.
 3. **The compact full-skeleton task list**: every task's `id` + `title` + `outcome` only (no detail), so you can tell whether another task already built the behavior this one would otherwise duplicate.
+4. **The canonical output template**, inlined under a `Template (tasks/{TASK_ID}.md):` label — the
+   authoritative structure for your output (field order, the two free-content sections, and the
+   exact parsing contract downstream tooling relies on). Use the inlined text — do NOT attempt to
+   Read, Glob, or otherwise search the filesystem for `gaia-task-template.md` yourself; it is not
+   guaranteed to be reachable from where this agent runs, and searching for it is not a safe
+   fallback either. This section and the Output section below summarize it; the inlined template
+   text is the source of truth if the two ever disagree.
 
-If the prompt is missing any of these three, stop and report exactly what is missing — do not guess at a skeleton entry you were not given.
+If the prompt is missing any of these four, stop and report exactly what is missing — do not guess at a skeleton entry you were not given.
 
 ---
 
@@ -142,9 +144,9 @@ Return exactly this block as your final response, and nothing else (no preamble,
 ```
 
 This is the same format already rendered today inside a Work Breakdown's "Task Details"
-section — canonical reference: `.claude/scripts/templates/gaia-task-template.md` (you have a Read
-tool; read it directly rather than relying only on this summary). That template's parsing-contract
-note applies to your own output too: a naive parser reads only the field lines immediately
+section — canonical reference: the `Template (tasks/{TASK_ID}.md):`-labeled text inlined in your
+own prompt (see Input §4 above; rely on that, not just this summary). That template's
+parsing-contract note applies to your own output too: a naive parser reads only the field lines immediately
 following the heading, and the *last* `**Implementation notes:**`/`**Verification commands:**`
 occurrence — so if you need to illustrate this format inside a longer explanation (e.g. showing
 another agent's expected output shape), make sure your own real sections remain the last

package/src/claude/scripts/tech-spec-assembler.js

@@ -148,7 +148,18 @@ function loadTechSpec(inputPath) {
   for (const c of components) {
     const compPath = path.join(inputPath, 'components', c.fileSlug)
     if (!fs.existsSync(compPath)) throw new AssemblyError(`component "${c.filePath}" has no detail file at ${compPath}`)
-    detailByPath[c.filePath] = parseComponentDetail(fs.readFileSync(compPath, 'utf8'))
+    try {
+      detailByPath[c.filePath] = parseComponentDetail(fs.readFileSync(compPath, 'utf8'))
+    } catch (err) {
+      // parseComponentDetail's own error names only the symptom ("missing its ## Change
+      // section"), never which file — a real diagnosability bug, found when exactly this error
+      // surfaced during final assembly with nothing identifying which of ~60 component files was
+      // actually malformed (the real culprit here was a whole-response-wrapped-in-a-fence worker
+      // reply — see lib/workflow-control.js's extractMarkdownDocument for the fix to that other
+      // half of this same incident). Re-thrown with the file identified, never silently swallowed.
+      if (err instanceof AssemblyError) throw new AssemblyError(`${err.message} (component "${c.filePath}" at ${compPath})`)
+      throw err
+    }
   }
 
   let doc = rewriteSection9(indexContent, components)

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

@@ -36,6 +36,21 @@ return c.run(meta.name, featureDir, prefix, async () => {
   const valId = 'gaia.agent.planner.validate-feature-docs'
   const output = (suffix, inputs = [featurePath]) => ({ path: file(suffix), inputs })
 
+  // Templates live under the toolkit's own installed scripts/templates/ — outside this project
+  // for a globally-installed toolkit, which a non-interactive `--print` worker invocation has no
+  // way to get permission for (no TTY to answer a prompt; confirmed by a real run failing with
+  // "Worker permission denied: ...; tools: Read" against exactly this kind of path). The host
+  // reads the template itself (a plain Node process, never subject to the Claude Code
+  // tool-permission system) via the dedicated print-asset CLI command, and inlines its text
+  // directly into the prompt — the agent is never asked to Read it. Same pattern FTR-025 already
+  // established for inlining Requirements/Tech-Spec text into gaia-validate-feature-docs' prompt.
+  function readTemplate(templateFile) {
+    return c.command(['print-asset', `scripts/templates/${templateFile}`, '--project', c.root]).stdout
+  }
+  function withTemplate(prompt, label, templateFile) {
+    return `${prompt}\n\nTemplate (${label}):\n${readTemplate(templateFile)}`
+  }
+
   // Deliberately NOT file('req') — same reasoning as FTR-020's wbsDir: this is a directory
   // nested inside the feature's own already-prefixed folder, so a second prefix would be
   // redundant.
@@ -109,11 +124,12 @@ return c.run(meta.name, featureDir, prefix, async () => {
       (relatedACs.length ? relatedACs.join(', ') : '—') + ' (see [index.md](../index.md#7-acceptance-criteria))\n'
   }
 
-  function buildUcPrompt(row, ucTable, featurePathArg) {
+  function buildUcPrompt(row, ucTable, featurePathArg, ucTemplate) {
     const compactIndex = ucTable.map(r => `${r.id}: ${r.title} (${r.actor})`).join('\n')
-    return `${featurePathArg}\n\nGenerate the full detail for this use case:\n` +
+    const base = `${featurePathArg}\n\nGenerate the full detail for this use case:\n` +
       `UC ID: ${row.id}\nTitle: ${row.title}\nActor: ${row.actor}\nPriority: ${row.priority}\n\n` +
       `Full use-case index (for cross-UC awareness, do not restate):\n${compactIndex}`
+    return `${base}\n\nTemplate (req/use-cases/{UC-ID}.md):\n${ucTemplate}`
   }
 
   // forceAll: bypasses resume-by-existence entirely, re-dispatching the skeleton and every
@@ -144,7 +160,7 @@ return c.run(meta.name, featureDir, prefix, async () => {
     // 1. Skeleton (no declared worker() output — host writes it itself, mirroring FTR-020's
     // skeleton step)
     if (regenSkeleton) {
-      const skeleton = await c.worker(reqId, featurePath)
+      const skeleton = await c.worker(reqId, withTemplate(featurePath, 'req/index.md', 'gaia-requirements-index-template.md'))
       c.writeOutput(reqIndexPath, skeleton)
     }
 
@@ -162,13 +178,15 @@ return c.run(meta.name, featureDir, prefix, async () => {
 
     // 3. Per-use-case generation, resume-by-existence, sequential
     const ucTable = parseUseCaseIndexTable(c.read(reqIndexPath))
+    // Read once, outside the loop — the template is identical for every use case in this run.
+    const ucTemplate = ucTable.length ? readTemplate('gaia-use-case-template.md') : null
     for (const row of ucTable) {
       const ucPath = `${reqDir}/${row.file}`
       // If the skeleton itself was just (re)generated, every use case must regenerate too —
       // an existing use-case file would have been written against the OLD skeleton's row
       // (title/actor/priority may have changed) and cannot be trusted as-is.
       if (!regenSkeleton && c.exists(ucPath)) continue // resume: skip, no dispatch
-      const detail = await c.worker(reqUcId, buildUcPrompt(row, ucTable, featurePath),
+      const detail = await c.worker(reqUcId, buildUcPrompt(row, ucTable, featurePath, ucTemplate),
         { label: `requirements-use-case:${row.id}` })
       c.writeOutput(ucPath, detail.trimEnd() + ucCrossReferences(c.read(reqIndexPath), row.id))
     }
@@ -223,11 +241,12 @@ return c.run(meta.name, featureDir, prefix, async () => {
     return entries
   }
 
-  function buildComponentPrompt(row, components, featurePathArg) {
+  function buildComponentPrompt(row, components, featurePathArg, componentTemplate) {
     const compactIndex = components.map(c => `${c.filePath} (${c.domain})`).join('\n')
-    return `${featurePathArg}\n\nGenerate the full technical design for this component:\n` +
+    const base = `${featurePathArg}\n\nGenerate the full technical design for this component:\n` +
       `Path: ${row.filePath}\nChange: ${row.changeType}\nDomain: ${row.domain}\nAddresses: ${row.addresses}\n\n` +
       `Full component index (for cross-component awareness, do not restate):\n${compactIndex}`
+    return `${base}\n\nTemplate (spec/components/{fileSlug}.md):\n${componentTemplate}`
   }
 
   // Deterministic, host-computed — never asks the model to pick unique names (same principle
@@ -279,7 +298,7 @@ return c.run(meta.name, featureDir, prefix, async () => {
 
     // 1. Skeleton (no declared worker() output — host writes it itself)
     if (regenSkeleton) {
-      const skeleton = await c.worker(specId, featurePath)
+      const skeleton = await c.worker(specId, withTemplate(featurePath, 'spec/index.md', 'gaia-tech-spec-index-template.md'))
       c.writeOutput(specIndexPath, disambiguateFileSlugs(skeleton))
     }
 
@@ -298,10 +317,12 @@ return c.run(meta.name, featureDir, prefix, async () => {
 
     // 3. Per-component generation, resume-by-existence, sequential
     const components = parseComponentsTable(c.read(specIndexPath))
+    // Read once, outside the loop — the template is identical for every component in this run.
+    const componentTemplate = components.length ? readTemplate('gaia-component-template.md') : null
     for (const comp of components) {
       const compPath = `${specDir}/components/${comp.fileSlug}`
       if (!regenSkeleton && c.exists(compPath)) continue // resume: skip, no dispatch
-      const detail = await c.worker(specComponentId, buildComponentPrompt(comp, components, featurePath),
+      const detail = await c.worker(specComponentId, buildComponentPrompt(comp, components, featurePath, componentTemplate),
         { label: `tech-spec-component:${comp.fileSlug}` })
       c.writeOutput(compPath, detail)
     }

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

@@ -239,7 +239,7 @@ function buildTaskTechSpecExcerpt(components, task, specDir, specIndexContent) {
 // implementation awareness), and the Tech-Spec excerpt (FTR-026: already pre-sliced to this
 // task's own relevant component(s) by buildTaskTechSpecExcerpt, or the full legacy Tech-Spec
 // text for a feature with no spec/ directory).
-function buildTaskPrompt(index, taskId, techSpecText) {
+function buildTaskPrompt(index, taskId, techSpecText, taskTemplate) {
   const task = index.tasks[taskId]
   const siblingList = Object.entries(index.tasks)
     .map(([id, t]) => `- ${id}: ${t.title} — ${t.outcome}`).join('\n')
@@ -247,6 +247,7 @@ function buildTaskPrompt(index, taskId, techSpecText) {
     `Task skeleton entry (restate these fields verbatim; do not re-derive them):\n${JSON.stringify({ id: taskId, ...task }, null, 2)}`,
     `Tech-Spec:\n${techSpecText}`,
     `All tasks in this feature (for duplicate-implementation awareness):\n${siblingList}`,
+    `Template (tasks/{TASK_ID}.md):\n${taskTemplate}`,
   ].join('\n\n')
 }
 
@@ -339,6 +340,13 @@ return c.run(meta.name, featureDir, prefix, async () => {
   // own Acceptance Criteria, not the entire assembled spec — computed once, before the loop, by
   // matching each task's acceptanceCriteria against spec/index.md's own Addresses column.
   const components = hasSpec ? parseComponentsTableLocal(c.read(specIndexPath)) : []
+  // The template lives under the toolkit's own installed scripts/templates/ — outside the
+  // project for a globally-installed toolkit, which a non-interactive worker invocation has no
+  // way to get Read permission for. Read once via print-asset, inline into every task's prompt,
+  // instead of telling the agent to Read it itself (same reasoning as pm-phase1.js's
+  // readTemplate/withTemplate — this runtime duplicates the primitive, not requires it, for the
+  // same "no `require`" reason as every other duplicated helper in this file).
+  const taskTemplate = c.command(['print-asset', 'scripts/templates/gaia-task-template.md', '--project', c.root]).stdout
   for (const phase of index.phases) {
     for (const taskId of phase.taskIds) {
       const task = index.tasks[taskId]
@@ -348,7 +356,7 @@ return c.run(meta.name, featureDir, prefix, async () => {
         ? buildTaskTechSpecExcerpt(components, task, specDir, c.read(specIndexPath))
         : c.read(file('Tech-Spec.md')) // legacy fallback: unchanged, full text
       const detail = await c.worker('gaia.agent.planner.work-breakdown-task',
-        buildTaskPrompt(index, taskId, techSpecExcerpt), { label: `work-breakdown-task:${taskId}` })
+        buildTaskPrompt(index, taskId, techSpecExcerpt, taskTemplate), { label: `work-breakdown-task:${taskId}` })
       c.writeOutput(detailPath, detail)
       task.status = 'generated'
       c.writeOutput(indexPath, JSON.stringify(index, null, 2)) // persist status after each task