@dtlabs/ai-toolkit 0.19.0 → 0.19.1

package/CHANGELOG.md

@@ -1,4 +1,11 @@
 ## 0.1.4 (2026-07-21)
+## [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);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dtlabs/ai-toolkit",
-  "version": "0.19.0",
+  "version": "0.19.1",
   "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/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