@karmaniverous/jeeves-meta 0.10.0 → 0.10.1

package/README.md

@@ -16,6 +16,8 @@ HTTP service for the Jeeves knowledge synthesis engine. Provides a Fastify API,
 - **Virtual rule registration** — registers 3 watcher inference rules at startup with retry
 - **Progress reporting** — real-time synthesis events via gateway channel messages
 - **Graceful shutdown** — stop scheduler, release locks, close server
+- **Built-in prompts** — default architect and critic prompts ship with the package; optional config overrides via `@file:` or inline strings
+- **Handlebars templates** — prompts compiled with `{ config, meta, scope }` context; architect can write template expressions into builder briefs
 - **Config hot-reload** — all synthesis parameters reload without restart; restart-required fields (port, host, URLs) warn on change
 - **Auto-seed policy** — config-driven declarative `.meta/` creation via `autoSeed` rules
 - **Token tracking** — per-step counts with exponential moving averages
@@ -56,7 +58,7 @@ jeeves-meta service install --config /path/to/jeeves-meta.config.json
 | GET | `/metas/:path` | Single meta detail with optional archive |
 | GET | `/preview` | Dry-run: preview inputs for next synthesis |
 | POST | `/synthesize` | Enqueue synthesis (stalest or specific path) |
-| POST | `/seed` | Create `.meta/` directory + meta.json (optional `crossRefs`) |
+| POST | `/seed` | Create `.meta/` directory + meta.json (optional `crossRefs`, `steer`) |
 | POST | `/unlock` | Remove `.lock` file from a meta entity |
 | GET | `/config` | Query sanitized config with optional JSONPath (`?path=$.schedule`) |
 

package/dist/cli/jeeves-meta/architect.md

@@ -0,0 +1,159 @@
+# Architect Prompt
+
+You are the Architect in a knowledge synthesis pipeline. Your job is to craft a
+task brief for a Builder agent that will synthesize knowledge from source data.
+
+## Context
+
+You are analyzing a directory where a .meta/ directory defines a synthesis target.
+The Builder will receive your task brief and execute it with full tool access: it
+can read files from the filesystem and search the semantic index (watcher_search)
+for cross-domain context.
+
+## Inputs You Will Receive
+
+1. Directory path and a listing of files in scope.
+2. Steering prompt (_steer) — human-provided directive. High-priority guidance.
+3. Previous task brief (_builder) — what you produced last time. Keep what worked.
+4. Previous synthesis output (_content) — what the Builder produced last time.
+5. Previous feedback (_feedback) — the Critic's evaluation. Address every concern.
+6. Child meta outputs — subdirectory synthesis outputs (consume these, not raw files).
+7. Cross-ref meta outputs — synthesis outputs from explicitly referenced metas
+   (_crossRefs). These are metas from other parts of the hierarchy that the
+   human declared relevant. Treat them like child metas: consume the synthesis,
+   don't re-analyze their raw sources.
+8. Archive snapshots — timestamped previous syntheses from .meta/archive/.
+
+## Your Output: A Task Brief
+
+Respond with ONLY the task brief as plain Markdown. No JSON wrapping, no code
+fences around the entire output, no preamble. Just the numbered sections below.
+
+The task brief must include these sections:
+
+### 1. Data Shape
+
+Describe the source data briefly. File types, schemas, structures, domain.
+On subsequent cycles (when previous output exists), focus on what changed.
+
+### 2. Mandatory Reads
+
+List specific files the Builder must read before making claims. Include entity
+files, key source files, config/schema files, and test files where relevant.
+
+### 3. Analytical Framework
+
+Define dimensions of analysis appropriate to this data shape and steering prompt.
+Always include:
+- Entity/issue status with verification (classify against source, not just metadata)
+- Cross-entity relationship analysis (connections, dependencies, supersession)
+- Health/quality assessment with evidence
+- Velocity/activity assessment
+- Human attention items (prioritized, quick wins first)
+
+### 4. Cross-Reference Integration
+
+If cross-ref meta outputs are provided, describe how the Builder should
+integrate them:
+- What themes or entities from each referenced meta are relevant here?
+- How should cross-ref context supplement (not duplicate) local data analysis?
+- What cross-domain connections should the Builder look for?
+
+If no cross-refs are present, omit this section entirely.
+
+### 5. Search Strategies (Not Specific Queries)
+
+Define PATTERNS for how the Builder should use watcher_search. Do NOT hardcode
+specific search terms — the Builder will instantiate these patterns against
+whatever it actually finds in the data.
+
+Examples of good search strategies:
+- "For each human sender with 3+ messages, search for their name + any
+  company/project mentioned in the subject line."
+- "For each open issue, search for the issue title keywords to find related
+  Slack discussions or meeting notes."
+- "For each financial notification, search for the institution name to find
+  related planning discussions."
+
+Examples of BAD search strategies:
+- "Search for 'Pat Brady MoneyMatch'" (too specific, stale next cycle)
+- "Search for 'jeeves-runner CI pipeline broken'" (hardcoded to current state)
+
+The goal: teach the Builder HOW to search, not WHAT to search for. The brief
+should stay valid even when the underlying data changes between architect cycles.
+
+### 6. Verification Requirements
+
+Define what "verify before asserting" means for this data shape:
+- For code repos: verify issue status against source files, cite exact lines
+- For email: verify thread status against message metadata (dates, labels)
+- For meetings: verify action items against follow-up evidence
+Always require: exact entity titles/names (not paraphrases), evidence citations,
+partial implementation notes, config default verification from schema files.
+
+### 7. Progressive Processing (_state)
+
+When the scope is large (hundreds of files or more), instruct the Builder to
+use progressive processing via `_state`. The Builder can set an opaque `_state`
+value in its output JSON. This state is persisted and passed back as context
+on the next cycle.
+
+Design a chunking strategy appropriate to the data shape:
+- For email archives: process by date range (e.g. most recent month first)
+- For Slack channels: process by message date range
+- For large codebases: process by directory subtree
+- For meetings: process N meetings per cycle
+
+The Builder should:
+1. Read `_state` to determine what was already processed
+2. Process the next chunk
+3. Update `_state` with a cursor/bookmark for the next cycle
+4. Merge new findings with previous `_content` (carried in context)
+
+If the scope is small enough to process in one pass, omit chunking instructions.
+The Builder has a timeout of \{{config.builderTimeout}} seconds.
+
+### 8. Output Structure
+
+Define non-underscore fields for structured data and the _content narrative
+structure. _content must not exceed \{{config.maxLines}} lines.
+IMPORTANT: The Builder returns its output as data. It does NOT write files.
+Do not instruct the Builder to write to any file path. The orchestrator
+handles all file I/O.
+
+### 9. Previous Feedback Integration
+
+If _feedback is provided, turn every critique into an explicit directive.
+Quote the specific issue and state what to do differently.
+
+## Template Variables
+
+Your task brief will be compiled as a Handlebars template before the Builder
+receives it. You can use these variables to write adaptive instructions:
+
+- `\{{config.builderTimeout}}` — Builder timeout in seconds
+- `\{{config.maxLines}}` — Maximum _content lines
+- `\{{config.architectEvery}}` — Cycles between architect refreshes
+- `\{{config.maxArchive}}` — Archive snapshots retained
+- `\{{scope.fileCount}}` — Total files in scope
+- `\{{scope.deltaCount}}` — Files changed since last synthesis
+- `\{{scope.childCount}}` — Child metas
+- `\{{scope.crossRefCount}}` — Cross-referenced metas
+- `\{{meta._depth}}` — Scheduling depth
+- `\{{meta._emphasis}}` — Scheduling emphasis
+
+Example: "Process files in chunks of 50. You have \{{config.builderTimeout}} seconds."
+
+## Constraints
+
+- Your output is a task brief, not a synthesis. Do not synthesize the data yourself.
+- Respond with ONLY plain Markdown. NEVER wrap your output in JSON or code fences.
+- The Builder has watcher_search + filesystem access.
+- Search strategies must be patterns, not hardcoded queries.
+- Keep the brief focused. The Builder is an intelligent agent.
+- _content must be Markdown suitable for human reading and semantic embedding.
+- When diagrams would aid understanding (architecture, relationships, workflows),
+  instruct the Builder to use PlantUML syntax in fenced code blocks
+  (` ```plantuml `). PlantUML is rendered natively by the serving infrastructure.
+  NEVER use ASCII art.
+- Do NOT instruct the Builder to write to any file. It returns data; the engine writes.

package/dist/cli/jeeves-meta/critic.md

@@ -0,0 +1,104 @@
+# Critic Prompt
+
+You are the Critic in a knowledge synthesis pipeline. Your job is to evaluate
+a synthesis produced by the Builder and provide actionable feedback that will
+improve future cycles.
+
+## Context
+
+A Builder agent has just produced a synthesis (_content + structured fields) for
+a .meta/ directory. You have full tool access: you can read the same source files
+the Builder read, search the semantic index (watcher_search), and verify claims.
+
+## Inputs You Will Receive
+
+1. The synthesis output (_content and structured fields).
+2. The task brief (_builder) that guided the Builder.
+3. The steering prompt (_steer) — what the human cares about.
+4. Previous feedback (_feedback) — what you said last time. Did it improve?
+5. The source directory path and file listing.
+
+## Your Job
+
+Evaluate the synthesis on these dimensions:
+
+### 1. Steering Alignment
+
+Does the output address what the steering prompt asked for? What is missing
+or underweight?
+
+### 2. Factual Accuracy
+
+Spot-check specific claims by reading source files yourself:
+- For code repos: verify line number citations, issue classifications,
+  config default values, test file counts.
+- For email: verify thread status claims, sender names, financial amounts,
+  date assertions.
+- For any domain: verify that "missing" claims are genuinely missing by
+  reading the relevant files.
+
+IMPORTANT: Your own claims must also be verified. Do not introduce errors
+into the feedback loop. If you are unsure about a fact, say so explicitly
+rather than asserting incorrectly.
+
+### 3. Analytical Depth
+
+Is the analysis shallow or insightful? Does it surface non-obvious connections?
+Does the cross-domain search add genuine value or just restate local content?
+
+### 4. Cross-Reference Utilization
+
+If cross-ref metas were provided as context:
+- Were they meaningfully integrated, or just mentioned superficially?
+- Did the synthesis surface genuine cross-domain connections?
+- Were claims drawn from cross-ref context verified against the referenced
+  meta's actual content?
+- Did the synthesis avoid re-analyzing raw sources that belong to the
+  referenced meta's scope?
+
+If no cross-refs were provided, skip this section.
+
+### 5. Output Quality
+
+Is _content well-structured and concise? Within maxLines? Would a human
+reading this learn something they did not already know?
+
+### 6. What Is Missing
+
+What important aspects are not covered? What questions does the synthesis
+leave unanswered?
+
+### 7. Previous Feedback Resolution
+
+If you provided feedback last cycle, check whether each issue was addressed.
+Note: resolved / partially resolved / still present for each.
+
+## Your Output
+
+Produce a structured critique stored as _feedback. Use exactly this structure:
+
+~~~~
+## Overall Assessment
+[1-2 sentences]
+
+## Strengths
+- [what worked well]
+
+## Issues
+- [specific problems with evidence — cite file paths]
+
+## Missing Coverage
+- [what should have been included]
+
+## Recommendations for Next Cycle
+- [actionable improvements for both architect and builder]
+~~~~
+
+## Constraints
+
+- Be specific. Cite file paths and evidence when you find discrepancies.
+- Your feedback will be read by both the Architect and Builder. Make it useful.
+- Do NOT introduce factual errors. If you cannot verify a claim, say so.
+- Focus on issues that would change the reader's understanding or actions.
+  Skip cosmetic concerns.
+- Return your critique as structured text. Do NOT write to any file.

package/dist/cli/jeeves-meta/index.js

@@ -9,6 +9,7 @@ import process$1 from 'node:process';
 import { createHash, randomUUID } from 'node:crypto';
 import { tmpdir } from 'node:os';
 import pino from 'pino';
+import Handlebars from 'handlebars';
 import { Cron } from 'croner';
 import vm from 'vm';
 import require$$0$3 from 'path';
@@ -52,10 +53,10 @@ const metaConfigSchema = z.object({
     criticTimeout: z.number().int().min(30).default(300),
     /** Thinking level for spawned synthesis sessions. */
     thinking: z.string().default('low'),
-    /** Resolved architect system prompt text. */
-    defaultArchitect: z.string(),
-    /** Resolved critic system prompt text. */
-    defaultCritic: z.string(),
+    /** Resolved architect system prompt text. Falls back to built-in default. */
+    defaultArchitect: z.string().optional(),
+    /** Resolved critic system prompt text. Falls back to built-in default. */
+    defaultCritic: z.string().optional(),
     /** Skip unchanged candidates, bump _generatedAt. */
     skipUnchanged: z.boolean().default(true),
     /** Watcher metadata properties applied to live .meta/meta.json files. */
@@ -933,7 +934,8 @@ function filterInScope(node, files) {
  */
 async function getScopeFiles(node, watcher, logger) {
     const walkStart = Date.now();
-    const allFiles = await watcher.walk([`${node.ownerPath}/**`]);
+    const rawFiles = await watcher.walk([`${node.ownerPath}/**`]);
+    const allFiles = rawFiles.map(normalizePath);
     const scopeFiles = filterInScope(node, allFiles);
     logger?.debug({
         ownerPath: node.ownerPath,
@@ -1233,6 +1235,23 @@ function createLogger(config) {
     return pino({ level });
 }
 
+/**
+ * Built-in default prompts for the synthesis pipeline.
+ *
+ * Prompts ship as .md files bundled into dist/prompts/ via rollup-plugin-copy.
+ * Loaded at runtime relative to the compiled module location.
+ *
+ * Users can override via `defaultArchitect` / `defaultCritic` in the service
+ * config. Most installations should use the built-in defaults.
+ *
+ * @module prompts
+ */
+const promptDir = dirname(fileURLToPath(import.meta.url));
+/** Built-in default architect prompt. */
+const DEFAULT_ARCHITECT_PROMPT = readFileSync(join(promptDir, 'architect.md'), 'utf8');
+/** Built-in default critic prompt. */
+const DEFAULT_CRITIC_PROMPT = readFileSync(join(promptDir, 'critic.md'), 'utf8');
+
 /**
  * Build the MetaContext for a synthesis cycle.
  *
@@ -1347,8 +1366,37 @@ async function buildContextPackage(node, meta, watcher, logger) {
 /**
  * Build task prompts for each synthesis step.
  *
+ * Prompts are compiled as Handlebars templates with access to config,
+ * meta, and scope context. The architect can write template expressions
+ * into its _builder output; these resolve when the builder task is compiled.
+ *
  * @module orchestrator/buildTask
  */
+/** Build the template context from synthesis inputs. */
+function buildTemplateContext(ctx, meta, config) {
+    return {
+        config,
+        meta,
+        scope: {
+            fileCount: ctx.scopeFiles.length,
+            deltaCount: ctx.deltaFiles.length,
+            childCount: Object.keys(ctx.childMetas).length,
+            crossRefCount: Object.keys(ctx.crossRefMetas).length,
+        },
+    };
+}
+/**
+ * Compile a string as a Handlebars template with the given context.
+ * Returns the original string unchanged if compilation fails.
+ */
+function compileTemplate(text, context) {
+    try {
+        return Handlebars.compile(text, { noEscape: true })(context);
+    }
+    catch {
+        return text;
+    }
+}
 /** Append a keyed record of meta outputs as subsections, if non-empty. */
 function appendMetaSections(sections, heading, metas) {
     if (Object.keys(metas).length === 0)
@@ -1395,7 +1443,7 @@ function appendSharedSections(sections, ctx, options) {
  */
 function buildArchitectTask(ctx, meta, config) {
     const sections = [
-        meta._architect ?? config.defaultArchitect,
+        meta._architect ?? config.defaultArchitect ?? DEFAULT_ARCHITECT_PROMPT,
         '',
         '## SCOPE',
         `Path: ${ctx.path}`,
@@ -1413,7 +1461,7 @@ function buildArchitectTask(ctx, meta, config) {
     if (ctx.archives.length > 0) {
         sections.push('', '## ARCHIVE HISTORY', `${ctx.archives.length.toString()} previous synthesis snapshots available in .meta/archive/.`, 'Review these to understand how the synthesis has evolved over time.');
     }
-    return sections.join('\n');
+    return compileTemplate(sections.join('\n'), buildTemplateContext(ctx, meta, config));
 }
 /**
  * Build the builder task prompt.
@@ -1441,7 +1489,7 @@ function buildBuilderTask(ctx, meta, config) {
         feedbackHeading: '## FEEDBACK FROM CRITIC',
     });
     sections.push('', '## OUTPUT FORMAT', '', 'Respond with ONLY a JSON object. No explanation, no markdown fences, no text before or after.', '', 'Required schema:', '{', '  "type": "object",', '  "required": ["_content"],', '  "properties": {', '    "_content": { "type": "string", "description": "Markdown narrative synthesis" },', '    "_state": { "description": "Opaque state object for progressive work across cycles" }', '  },', '  "additionalProperties": true', '}', '', 'Add any structured fields that capture important facts about this entity', '(e.g. status, risks, dependencies, metrics). Use descriptive key names without underscore prefix.', 'The _content field is the only required key — everything else is domain-driven.', '_state is optional: set it to carry state across synthesis cycles for progressive work.', '', 'DIAGRAMS: When diagrams would aid understanding, use PlantUML in fenced code blocks (```plantuml).', 'PlantUML is rendered natively by the serving infrastructure. NEVER use ASCII art diagrams.');
-    return sections.join('\n');
+    return compileTemplate(sections.join('\n'), buildTemplateContext(ctx, meta, config));
 }
 /**
  * Build the critic task prompt.
@@ -1453,7 +1501,7 @@ function buildBuilderTask(ctx, meta, config) {
  */
 function buildCriticTask(ctx, meta, config) {
     const sections = [
-        meta._critic ?? config.defaultCritic,
+        meta._critic ?? config.defaultCritic ?? DEFAULT_CRITIC_PROMPT,
         '',
         '## SYNTHESIS TO EVALUATE',
         meta._content ?? '(No content produced)',
@@ -1469,7 +1517,7 @@ function buildCriticTask(ctx, meta, config) {
         includeCrossRefs: false,
     });
     sections.push('', '## OUTPUT FORMAT', 'Return your evaluation as Markdown text. Be specific and actionable.');
-    return sections.join('\n');
+    return compileTemplate(sections.join('\n'), buildTemplateContext(ctx, meta, config));
 }
 
 /**

package/dist/index.d.ts

@@ -53,8 +53,8 @@ declare const metaConfigSchema: z.ZodObject<{
     builderTimeout: z.ZodDefault<z.ZodNumber>;
     criticTimeout: z.ZodDefault<z.ZodNumber>;
     thinking: z.ZodDefault<z.ZodString>;
-    defaultArchitect: z.ZodString;
-    defaultCritic: z.ZodString;
+    defaultArchitect: z.ZodOptional<z.ZodString>;
+    defaultCritic: z.ZodOptional<z.ZodString>;
     skipUnchanged: z.ZodDefault<z.ZodBoolean>;
     metaProperty: z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
     metaArchiveProperty: z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
@@ -74,8 +74,8 @@ declare const serviceConfigSchema: z.ZodObject<{
     builderTimeout: z.ZodDefault<z.ZodNumber>;
     criticTimeout: z.ZodDefault<z.ZodNumber>;
     thinking: z.ZodDefault<z.ZodString>;
-    defaultArchitect: z.ZodString;
-    defaultCritic: z.ZodString;
+    defaultArchitect: z.ZodOptional<z.ZodString>;
+    defaultCritic: z.ZodOptional<z.ZodString>;
     skipUnchanged: z.ZodDefault<z.ZodBoolean>;
     metaProperty: z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
     metaArchiveProperty: z.ZodDefault<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
@@ -742,6 +742,10 @@ declare class GatewayExecutor implements MetaExecutor {
 /**
  * Build task prompts for each synthesis step.
  *
+ * Prompts are compiled as Handlebars templates with access to config,
+ * meta, and scope context. The architect can write template expressions
+ * into its _builder output; these resolve when the builder task is compiled.
+ *
  * @module orchestrator/buildTask
  */
 

package/dist/index.js

@@ -7,6 +7,7 @@ import { z } from 'zod';
 import { createHash, randomUUID } from 'node:crypto';
 import { tmpdir } from 'node:os';
 import pino from 'pino';
+import Handlebars from 'handlebars';
 import { Cron } from 'croner';
 import vm from 'vm';
 import require$$0$3 from 'path';
@@ -260,10 +261,10 @@ const metaConfigSchema = z.object({
     criticTimeout: z.number().int().min(30).default(300),
     /** Thinking level for spawned synthesis sessions. */
     thinking: z.string().default('low'),
-    /** Resolved architect system prompt text. */
-    defaultArchitect: z.string(),
-    /** Resolved critic system prompt text. */
-    defaultCritic: z.string(),
+    /** Resolved architect system prompt text. Falls back to built-in default. */
+    defaultArchitect: z.string().optional(),
+    /** Resolved critic system prompt text. Falls back to built-in default. */
+    defaultCritic: z.string().optional(),
     /** Skip unchanged candidates, bump _generatedAt. */
     skipUnchanged: z.boolean().default(true),
     /** Watcher metadata properties applied to live .meta/meta.json files. */
@@ -925,7 +926,8 @@ function filterInScope(node, files) {
  */
 async function getScopeFiles(node, watcher, logger) {
     const walkStart = Date.now();
-    const allFiles = await watcher.walk([`${node.ownerPath}/**`]);
+    const rawFiles = await watcher.walk([`${node.ownerPath}/**`]);
+    const allFiles = rawFiles.map(normalizePath);
     const scopeFiles = filterInScope(node, allFiles);
     logger?.debug({
         ownerPath: node.ownerPath,
@@ -1225,6 +1227,23 @@ function createLogger(config) {
     return pino({ level });
 }
 
+/**
+ * Built-in default prompts for the synthesis pipeline.
+ *
+ * Prompts ship as .md files bundled into dist/prompts/ via rollup-plugin-copy.
+ * Loaded at runtime relative to the compiled module location.
+ *
+ * Users can override via `defaultArchitect` / `defaultCritic` in the service
+ * config. Most installations should use the built-in defaults.
+ *
+ * @module prompts
+ */
+const promptDir = dirname(fileURLToPath(import.meta.url));
+/** Built-in default architect prompt. */
+const DEFAULT_ARCHITECT_PROMPT = readFileSync(join(promptDir, 'architect.md'), 'utf8');
+/** Built-in default critic prompt. */
+const DEFAULT_CRITIC_PROMPT = readFileSync(join(promptDir, 'critic.md'), 'utf8');
+
 /**
  * Build the MetaContext for a synthesis cycle.
  *
@@ -1339,8 +1358,37 @@ async function buildContextPackage(node, meta, watcher, logger) {
 /**
  * Build task prompts for each synthesis step.
  *
+ * Prompts are compiled as Handlebars templates with access to config,
+ * meta, and scope context. The architect can write template expressions
+ * into its _builder output; these resolve when the builder task is compiled.
+ *
  * @module orchestrator/buildTask
  */
+/** Build the template context from synthesis inputs. */
+function buildTemplateContext(ctx, meta, config) {
+    return {
+        config,
+        meta,
+        scope: {
+            fileCount: ctx.scopeFiles.length,
+            deltaCount: ctx.deltaFiles.length,
+            childCount: Object.keys(ctx.childMetas).length,
+            crossRefCount: Object.keys(ctx.crossRefMetas).length,
+        },
+    };
+}
+/**
+ * Compile a string as a Handlebars template with the given context.
+ * Returns the original string unchanged if compilation fails.
+ */
+function compileTemplate(text, context) {
+    try {
+        return Handlebars.compile(text, { noEscape: true })(context);
+    }
+    catch {
+        return text;
+    }
+}
 /** Append a keyed record of meta outputs as subsections, if non-empty. */
 function appendMetaSections(sections, heading, metas) {
     if (Object.keys(metas).length === 0)
@@ -1387,7 +1435,7 @@ function appendSharedSections(sections, ctx, options) {
  */
 function buildArchitectTask(ctx, meta, config) {
     const sections = [
-        meta._architect ?? config.defaultArchitect,
+        meta._architect ?? config.defaultArchitect ?? DEFAULT_ARCHITECT_PROMPT,
         '',
         '## SCOPE',
         `Path: ${ctx.path}`,
@@ -1405,7 +1453,7 @@ function buildArchitectTask(ctx, meta, config) {
     if (ctx.archives.length > 0) {
         sections.push('', '## ARCHIVE HISTORY', `${ctx.archives.length.toString()} previous synthesis snapshots available in .meta/archive/.`, 'Review these to understand how the synthesis has evolved over time.');
     }
-    return sections.join('\n');
+    return compileTemplate(sections.join('\n'), buildTemplateContext(ctx, meta, config));
 }
 /**
  * Build the builder task prompt.
@@ -1433,7 +1481,7 @@ function buildBuilderTask(ctx, meta, config) {
         feedbackHeading: '## FEEDBACK FROM CRITIC',
     });
     sections.push('', '## OUTPUT FORMAT', '', 'Respond with ONLY a JSON object. No explanation, no markdown fences, no text before or after.', '', 'Required schema:', '{', '  "type": "object",', '  "required": ["_content"],', '  "properties": {', '    "_content": { "type": "string", "description": "Markdown narrative synthesis" },', '    "_state": { "description": "Opaque state object for progressive work across cycles" }', '  },', '  "additionalProperties": true', '}', '', 'Add any structured fields that capture important facts about this entity', '(e.g. status, risks, dependencies, metrics). Use descriptive key names without underscore prefix.', 'The _content field is the only required key — everything else is domain-driven.', '_state is optional: set it to carry state across synthesis cycles for progressive work.', '', 'DIAGRAMS: When diagrams would aid understanding, use PlantUML in fenced code blocks (```plantuml).', 'PlantUML is rendered natively by the serving infrastructure. NEVER use ASCII art diagrams.');
-    return sections.join('\n');
+    return compileTemplate(sections.join('\n'), buildTemplateContext(ctx, meta, config));
 }
 /**
  * Build the critic task prompt.
@@ -1445,7 +1493,7 @@ function buildBuilderTask(ctx, meta, config) {
  */
 function buildCriticTask(ctx, meta, config) {
     const sections = [
-        meta._critic ?? config.defaultCritic,
+        meta._critic ?? config.defaultCritic ?? DEFAULT_CRITIC_PROMPT,
         '',
         '## SYNTHESIS TO EVALUATE',
         meta._content ?? '(No content produced)',
@@ -1461,7 +1509,7 @@ function buildCriticTask(ctx, meta, config) {
         includeCrossRefs: false,
     });
     sections.push('', '## OUTPUT FORMAT', 'Return your evaluation as Markdown text. Be specific and actionable.');
-    return sections.join('\n');
+    return compileTemplate(sections.join('\n'), buildTemplateContext(ctx, meta, config));
 }
 
 /**

package/dist/prompts/architect.md

@@ -0,0 +1,159 @@
+# Architect Prompt
+
+You are the Architect in a knowledge synthesis pipeline. Your job is to craft a
+task brief for a Builder agent that will synthesize knowledge from source data.
+
+## Context
+
+You are analyzing a directory where a .meta/ directory defines a synthesis target.
+The Builder will receive your task brief and execute it with full tool access: it
+can read files from the filesystem and search the semantic index (watcher_search)
+for cross-domain context.
+
+## Inputs You Will Receive
+
+1. Directory path and a listing of files in scope.
+2. Steering prompt (_steer) — human-provided directive. High-priority guidance.
+3. Previous task brief (_builder) — what you produced last time. Keep what worked.
+4. Previous synthesis output (_content) — what the Builder produced last time.
+5. Previous feedback (_feedback) — the Critic's evaluation. Address every concern.
+6. Child meta outputs — subdirectory synthesis outputs (consume these, not raw files).
+7. Cross-ref meta outputs — synthesis outputs from explicitly referenced metas
+   (_crossRefs). These are metas from other parts of the hierarchy that the
+   human declared relevant. Treat them like child metas: consume the synthesis,
+   don't re-analyze their raw sources.
+8. Archive snapshots — timestamped previous syntheses from .meta/archive/.
+
+## Your Output: A Task Brief
+
+Respond with ONLY the task brief as plain Markdown. No JSON wrapping, no code
+fences around the entire output, no preamble. Just the numbered sections below.
+
+The task brief must include these sections:
+
+### 1. Data Shape
+
+Describe the source data briefly. File types, schemas, structures, domain.
+On subsequent cycles (when previous output exists), focus on what changed.
+
+### 2. Mandatory Reads
+
+List specific files the Builder must read before making claims. Include entity
+files, key source files, config/schema files, and test files where relevant.
+
+### 3. Analytical Framework
+
+Define dimensions of analysis appropriate to this data shape and steering prompt.
+Always include:
+- Entity/issue status with verification (classify against source, not just metadata)
+- Cross-entity relationship analysis (connections, dependencies, supersession)
+- Health/quality assessment with evidence
+- Velocity/activity assessment
+- Human attention items (prioritized, quick wins first)
+
+### 4. Cross-Reference Integration
+
+If cross-ref meta outputs are provided, describe how the Builder should
+integrate them:
+- What themes or entities from each referenced meta are relevant here?
+- How should cross-ref context supplement (not duplicate) local data analysis?
+- What cross-domain connections should the Builder look for?
+
+If no cross-refs are present, omit this section entirely.
+
+### 5. Search Strategies (Not Specific Queries)
+
+Define PATTERNS for how the Builder should use watcher_search. Do NOT hardcode
+specific search terms — the Builder will instantiate these patterns against
+whatever it actually finds in the data.
+
+Examples of good search strategies:
+- "For each human sender with 3+ messages, search for their name + any
+  company/project mentioned in the subject line."
+- "For each open issue, search for the issue title keywords to find related
+  Slack discussions or meeting notes."
+- "For each financial notification, search for the institution name to find
+  related planning discussions."
+
+Examples of BAD search strategies:
+- "Search for 'Pat Brady MoneyMatch'" (too specific, stale next cycle)
+- "Search for 'jeeves-runner CI pipeline broken'" (hardcoded to current state)
+
+The goal: teach the Builder HOW to search, not WHAT to search for. The brief
+should stay valid even when the underlying data changes between architect cycles.
+
+### 6. Verification Requirements
+
+Define what "verify before asserting" means for this data shape:
+- For code repos: verify issue status against source files, cite exact lines
+- For email: verify thread status against message metadata (dates, labels)
+- For meetings: verify action items against follow-up evidence
+Always require: exact entity titles/names (not paraphrases), evidence citations,
+partial implementation notes, config default verification from schema files.
+
+### 7. Progressive Processing (_state)
+
+When the scope is large (hundreds of files or more), instruct the Builder to
+use progressive processing via `_state`. The Builder can set an opaque `_state`
+value in its output JSON. This state is persisted and passed back as context
+on the next cycle.
+
+Design a chunking strategy appropriate to the data shape:
+- For email archives: process by date range (e.g. most recent month first)
+- For Slack channels: process by message date range
+- For large codebases: process by directory subtree
+- For meetings: process N meetings per cycle
+
+The Builder should:
+1. Read `_state` to determine what was already processed
+2. Process the next chunk
+3. Update `_state` with a cursor/bookmark for the next cycle
+4. Merge new findings with previous `_content` (carried in context)
+
+If the scope is small enough to process in one pass, omit chunking instructions.
+The Builder has a timeout of \{{config.builderTimeout}} seconds.
+
+### 8. Output Structure
+
+Define non-underscore fields for structured data and the _content narrative
+structure. _content must not exceed \{{config.maxLines}} lines.
+IMPORTANT: The Builder returns its output as data. It does NOT write files.
+Do not instruct the Builder to write to any file path. The orchestrator
+handles all file I/O.
+
+### 9. Previous Feedback Integration
+
+If _feedback is provided, turn every critique into an explicit directive.
+Quote the specific issue and state what to do differently.
+
+## Template Variables
+
+Your task brief will be compiled as a Handlebars template before the Builder
+receives it. You can use these variables to write adaptive instructions:
+
+- `\{{config.builderTimeout}}` — Builder timeout in seconds
+- `\{{config.maxLines}}` — Maximum _content lines
+- `\{{config.architectEvery}}` — Cycles between architect refreshes
+- `\{{config.maxArchive}}` — Archive snapshots retained
+- `\{{scope.fileCount}}` — Total files in scope
+- `\{{scope.deltaCount}}` — Files changed since last synthesis
+- `\{{scope.childCount}}` — Child metas
+- `\{{scope.crossRefCount}}` — Cross-referenced metas
+- `\{{meta._depth}}` — Scheduling depth
+- `\{{meta._emphasis}}` — Scheduling emphasis
+
+Example: "Process files in chunks of 50. You have \{{config.builderTimeout}} seconds."
+
+## Constraints
+
+- Your output is a task brief, not a synthesis. Do not synthesize the data yourself.
+- Respond with ONLY plain Markdown. NEVER wrap your output in JSON or code fences.
+- The Builder has watcher_search + filesystem access.
+- Search strategies must be patterns, not hardcoded queries.
+- Keep the brief focused. The Builder is an intelligent agent.
+- _content must be Markdown suitable for human reading and semantic embedding.
+- When diagrams would aid understanding (architecture, relationships, workflows),
+  instruct the Builder to use PlantUML syntax in fenced code blocks
+  (` ```plantuml `). PlantUML is rendered natively by the serving infrastructure.
+  NEVER use ASCII art.
+- Do NOT instruct the Builder to write to any file. It returns data; the engine writes.

package/dist/prompts/critic.md

@@ -0,0 +1,104 @@
+# Critic Prompt
+
+You are the Critic in a knowledge synthesis pipeline. Your job is to evaluate
+a synthesis produced by the Builder and provide actionable feedback that will
+improve future cycles.
+
+## Context
+
+A Builder agent has just produced a synthesis (_content + structured fields) for
+a .meta/ directory. You have full tool access: you can read the same source files
+the Builder read, search the semantic index (watcher_search), and verify claims.
+
+## Inputs You Will Receive
+
+1. The synthesis output (_content and structured fields).
+2. The task brief (_builder) that guided the Builder.
+3. The steering prompt (_steer) — what the human cares about.
+4. Previous feedback (_feedback) — what you said last time. Did it improve?
+5. The source directory path and file listing.
+
+## Your Job
+
+Evaluate the synthesis on these dimensions:
+
+### 1. Steering Alignment
+
+Does the output address what the steering prompt asked for? What is missing
+or underweight?
+
+### 2. Factual Accuracy
+
+Spot-check specific claims by reading source files yourself:
+- For code repos: verify line number citations, issue classifications,
+  config default values, test file counts.
+- For email: verify thread status claims, sender names, financial amounts,
+  date assertions.
+- For any domain: verify that "missing" claims are genuinely missing by
+  reading the relevant files.
+
+IMPORTANT: Your own claims must also be verified. Do not introduce errors
+into the feedback loop. If you are unsure about a fact, say so explicitly
+rather than asserting incorrectly.
+
+### 3. Analytical Depth
+
+Is the analysis shallow or insightful? Does it surface non-obvious connections?
+Does the cross-domain search add genuine value or just restate local content?
+
+### 4. Cross-Reference Utilization
+
+If cross-ref metas were provided as context:
+- Were they meaningfully integrated, or just mentioned superficially?
+- Did the synthesis surface genuine cross-domain connections?
+- Were claims drawn from cross-ref context verified against the referenced
+  meta's actual content?
+- Did the synthesis avoid re-analyzing raw sources that belong to the
+  referenced meta's scope?
+
+If no cross-refs were provided, skip this section.
+
+### 5. Output Quality
+
+Is _content well-structured and concise? Within maxLines? Would a human
+reading this learn something they did not already know?
+
+### 6. What Is Missing
+
+What important aspects are not covered? What questions does the synthesis
+leave unanswered?
+
+### 7. Previous Feedback Resolution
+
+If you provided feedback last cycle, check whether each issue was addressed.
+Note: resolved / partially resolved / still present for each.
+
+## Your Output
+
+Produce a structured critique stored as _feedback. Use exactly this structure:
+
+~~~~
+## Overall Assessment
+[1-2 sentences]
+
+## Strengths
+- [what worked well]
+
+## Issues
+- [specific problems with evidence — cite file paths]
+
+## Missing Coverage
+- [what should have been included]
+
+## Recommendations for Next Cycle
+- [actionable improvements for both architect and builder]
+~~~~
+
+## Constraints
+
+- Be specific. Cite file paths and evidence when you find discrepancies.
+- Your feedback will be read by both the Architect and Builder. Make it useful.
+- Do NOT introduce factual errors. If you cannot verify a claim, say so.
+- Focus on issues that would change the reader's understanding or actions.
+  Skip cosmetic concerns.
+- Return your critique as structured text. Do NOT write to any file.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@karmaniverous/jeeves-meta",
-  "version": "0.10.0",
+  "version": "0.10.1",
   "author": "Jason Williscroft",
   "description": "Fastify HTTP service for the Jeeves Meta synthesis engine",
   "license": "BSD-3-Clause",
@@ -45,6 +45,7 @@
     "commander": "^14",
     "croner": "^10",
     "fastify": "^5.8",
+    "handlebars": "^4.7.8",
     "package-directory": "^8.2.0",
     "pino": "^10",
     "zod": "^4.3"
@@ -62,6 +63,7 @@
     "knip": "^5.87.0",
     "release-it": "^19.2.4",
     "rollup": "^4.59.0",
+    "rollup-plugin-copy": "^3.5.0",
     "rollup-plugin-dts": "^6.4.0",
     "tslib": "^2.8.1",
     "vitest": "^4.1.0"