@karmaniverous/jeeves-meta 0.17.0 → 0.18.0-0

package/dist/prompts/architect.md

@@ -1,14 +1,10 @@
 # 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.
+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.
+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
 
@@ -18,33 +14,27 @@ for cross-domain context.
 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.
+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.
+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.
+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.
+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:
+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
@@ -53,8 +43,8 @@ Always include:
 
 ### 4. Cross-Reference Integration
 
-If cross-ref meta outputs are provided, describe how the Builder should
-integrate them:
+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?
@@ -63,88 +53,73 @@ 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.
+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."
+
+- "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.
+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.
+- 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.
 
 {{#if (gt scope.fileCount 500)}}
 ## LARGE SCOPE — SAMPLING MODE
 
-This entity has {{scope.fileCount}} files. Do NOT attempt to read or
-explore the full scope. Instead:
+This entity has {{scope.fileCount}} files. Do NOT attempt to read or explore the full scope. Instead:
 
-1. Read _state and _content from previous cycles to understand existing
-   data shape knowledge
-2. Sample at most 5–10 representative files to verify the data shape
-   hasn't fundamentally changed
+1. Read _state and _content from previous cycles to understand existing data shape knowledge
+2. Sample at most 5–10 representative files to verify the data shape hasn't fundamentally changed
 3. Focus your brief updates on what the _feedback says needs improving
-4. Preserve the existing progressive processing strategy unless the
-   data shape has materially changed
+4. Preserve the existing progressive processing strategy unless the data shape has materially changed
 
 Your job on re-runs is refinement, not rediscovery.
 {{/if}}
 
 ### 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.
+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.
+
 ### 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.
+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.
+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:
+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.maxLines}}` — Maximum _content lines
 - `\{{config.architectEvery}}` — Cycles between architect refreshes
@@ -166,8 +141,5 @@ Example: "Process files in chunks of 50. Limit output to \{{config.maxLines}} li
 - 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.
+- 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

@@ -1,14 +1,10 @@
 # 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.
+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.
+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
 
@@ -24,60 +20,50 @@ Evaluate the synthesis on these dimensions:
 
 ### 1. Steering Alignment
 
-Does the output address what the steering prompt asked for? What is missing
-or underweight?
+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.
+- 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?
+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?
+- 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?
+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?
+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.
+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]
 
@@ -92,13 +78,12 @@ Produce a structured critique stored as _feedback. Use exactly this structure:
 
 ## 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.
+- 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

@@ -7,41 +7,35 @@
     "url": "https://github.com/karmaniverous/jeeves-meta/issues"
   },
   "dependencies": {
-    "@karmaniverous/jeeves": "^0.5.12",
+    "@karmaniverous/jeeves": "0.6.0-7",
     "@karmaniverous/jeeves-meta-core": "^0.2.2",
-    "commander": "^14",
+    "commander": "^15",
     "croner": "^10",
-    "fastify": "^5.8",
+    "fastify": "^5.12",
     "handlebars": "^4.7.9",
     "package-directory": "^8.2.0",
     "pino": "^10",
-    "zod": "^4.4"
+    "zod": "^4.6"
   },
   "description": "Fastify HTTP service for the Jeeves Meta synthesis engine",
   "devDependencies": {
-    "@dotenvx/dotenvx": "^1.69.1",
-    "@rollup/plugin-commonjs": "^29.0.2",
+    "@dotenvx/dotenvx": "^2.30.0",
+    "@rollup/plugin-commonjs": "^29.0.3",
     "@rollup/plugin-json": "^6.1.0",
     "@rollup/plugin-node-resolve": "^16.0.3",
     "@rollup/plugin-typescript": "^12.3.0",
-    "@types/node": "^25.9.1",
-    "@vitest/coverage-v8": "^4.1.7",
+    "@types/node": "^26.6.3",
+    "@vitest/coverage-v8": "^5.0.2",
     "cross-env": "^10.1.0",
-    "release-it": "^20.0.1",
-    "rollup": "^4.60.4",
+    "release-it": "^21.1.0",
+    "rollup": "^4.63.5",
     "rollup-plugin-copy": "^3.5.0",
     "tslib": "^2.8.1",
-    "vitest": "^4.1.7"
+    "vitest": "^5.0.2"
   },
   "engines": {
     "node": ">=22"
   },
-  "exports": {
-    ".": {
-      "types": "./dist/index.d.ts",
-      "default": "./dist/index.js"
-    }
-  },
   "files": [
     "dist"
   ],
@@ -56,7 +50,6 @@
     "typescript"
   ],
   "license": "BSD-3-Clause",
-  "module": "dist/index.js",
   "name": "@karmaniverous/jeeves-meta",
   "publishConfig": {
     "access": "public"
@@ -98,17 +91,16 @@
     "url": "git+https://github.com/karmaniverous/jeeves-meta.git"
   },
   "scripts": {
-    "build": "rimraf dist && cross-env NO_COLOR=1 rollup --config rollup.config.ts --configPlugin \"@rollup/plugin-typescript={outputToFilesystem:true}\"",
+    "build": "rimraf dist && cross-env NO_COLOR=1 rollup --config rollup.config.ts --configPlugin \"@rollup/plugin-typescript={outputToFilesystem:true,paths:{}}\"",
     "changelog": "git-cliff -o CHANGELOG.md",
     "knip": "knip",
     "lint": "eslint .",
     "lint:fix": "eslint --fix .",
     "release": "dotenvx run -f .env.local -- release-it",
-    "release:pre": "dotenvx run -f .env.local -- release-it --no-git.requireBranch --github.prerelease --preRelease",
+    "release:pre": "dotenvx run -f .env.local -- release-it --no-git.requireBranch --github.preRelease --preRelease",
     "test": "vitest run",
     "typecheck": "tsc"
   },
   "type": "module",
-  "types": "dist/index.d.ts",
-  "version": "0.17.0"
+  "version": "0.18.0-0"
 }

package/dist/archive/index.d.ts

@@ -1,10 +0,0 @@
-/**
- * Archive module — snapshot creation, pruning, and reading.
- *
- * @module archive
- */
-export { listArchiveFiles } from './listArchive.js';
-export { pruneArchive } from './prune.js';
-export { readArchiveFromDisk, readArchiveFromWatcher } from './readArchive.js';
-export { readLatestArchive } from './readLatest.js';
-export { createSnapshot } from './snapshot.js';

package/dist/archive/listArchive.d.ts

@@ -1,12 +0,0 @@
-/**
- * List archive snapshot files in chronological order.
- *
- * @module archive/listArchive
- */
-/**
- * List archive .json files sorted chronologically (oldest first).
- *
- * @param metaPath - Absolute path to the .meta directory.
- * @returns Array of absolute paths to archive files, or empty if none.
- */
-export declare function listArchiveFiles(metaPath: string): string[];

package/dist/archive/prune.d.ts

@@ -1,14 +0,0 @@
-/**
- * Prune old archive snapshots beyond maxArchive.
- *
- * @module archive/prune
- */
-/**
- * Prune archive directory to keep at most maxArchive snapshots.
- * Removes the oldest files.
- *
- * @param metaPath - Absolute path to the .meta directory.
- * @param maxArchive - Maximum snapshots to retain.
- * @returns Number of files pruned.
- */
-export declare function pruneArchive(metaPath: string, maxArchive: number): Promise<number>;

package/dist/archive/readArchive.d.ts

@@ -1,30 +0,0 @@
-/**
- * Archive reading helpers — watcher scan with filesystem fallback.
- *
- * Used by the GET /metas/:path route to retrieve archive history.
- * Prefers watcher scan for performance; falls back to disk reads
- * when the watcher is unavailable.
- *
- * @module archive/readArchive
- */
-import type { WatcherClient } from '../interfaces/index.js';
-/**
- * Read archive history via watcher scan.
- *
- * @param watcher - WatcherClient with scan support.
- * @param metaPath - Absolute path to the .meta/ directory.
- * @param metaArchiveProperty - Additional filter properties for archive points.
- * @param limit - Max entries to return (newest first). Undefined = all.
- * @param projectMeta - Field projection function.
- * @returns Array of projected archive entries, newest first.
- */
-export declare function readArchiveFromWatcher(watcher: WatcherClient, metaPath: string, metaArchiveProperty: Record<string, unknown>, limit: number | undefined, projectMeta: (m: Record<string, unknown>) => Record<string, unknown>): Promise<Array<Record<string, unknown>>>;
-/**
- * Read archive history from disk (fallback).
- *
- * @param metaPath - Absolute path to the .meta/ directory.
- * @param limit - Max entries to return (newest first). Undefined = all.
- * @param projectMeta - Field projection function.
- * @returns Array of projected archive entries, newest first.
- */
-export declare function readArchiveFromDisk(metaPath: string, limit: number | undefined, projectMeta: (m: Record<string, unknown>) => Record<string, unknown>): Promise<Array<Record<string, unknown>>>;

package/dist/archive/readLatest.d.ts

@@ -1,13 +0,0 @@
-/**
- * Read the latest archive snapshot for steer change detection.
- *
- * @module archive/readLatest
- */
-import type { MetaJson } from '../schema/index.js';
-/**
- * Read the most recent archive snapshot.
- *
- * @param metaPath - Absolute path to the .meta directory.
- * @returns The latest archived meta, or null if no archives exist.
- */
-export declare function readLatestArchive(metaPath: string): Promise<MetaJson | null>;

package/dist/archive/snapshot.d.ts

@@ -1,17 +0,0 @@
-/**
- * Create archive snapshots of meta.json.
- *
- * Copies current meta.json to archive/\{ISO-timestamp\}.json with
- * _archived: true and _archivedAt added.
- *
- * @module archive/snapshot
- */
-import type { MetaJson } from '../schema/index.js';
-/**
- * Create an archive snapshot of the current meta.json.
- *
- * @param metaPath - Absolute path to the .meta directory.
- * @param meta - Current meta.json content.
- * @returns The archive file path.
- */
-export declare function createSnapshot(metaPath: string, meta: MetaJson): Promise<string>;

package/dist/bootstrap.d.ts

@@ -1,26 +0,0 @@
-/**
- * Service bootstrap — wire up all components and start listening.
- *
- * @module bootstrap
- */
-import { type ServiceConfig } from './schema/config.js';
-/**
- * Compute per-cycle token total from a completed meta.
- *
- * Exported for testing.
- *
- * Uses `_synthesisCount` as a discriminator: after increment by `runCritic`,
- * a value of 1 means architect ran this cycle (was 0 pre-increment),
- * so all three phase token fields are summed. A value \> 1 means architect
- * was skipped (cached brief reused), so only builder + critic are summed.
- */
-export declare function computeCycleTokens(meta: Record<string, unknown>): number;
-/**
- * Bootstrap the service: create logger, build server, start listening,
- * wire scheduler, queue processing, rule registration, config hot-reload,
- * startup lock cleanup, and shutdown.
- *
- * @param config - Validated service configuration.
- * @param configPath - Optional path to config file for hot-reload.
- */
-export declare function startService(config: ServiceConfig, configPath?: string): Promise<void>;

package/dist/cache.d.ts

@@ -1,22 +0,0 @@
-/**
- * In-memory cache for listMetas results with TTL and concurrent refresh guard.
- *
- * @module cache
- */
-import { type MetaListResult } from './discovery/index.js';
-import type { WatcherClient } from './interfaces/index.js';
-import type { ServiceConfig } from './schema/config.js';
-/**
- * Caches listMetas results to avoid expensive repeated filesystem walks.
- * Supports concurrent refresh coalescing and manual invalidation.
- */
-export declare class MetaCache {
-    private result;
-    private updatedAt;
-    private refreshPromise;
-    /** Get cached result or refresh if stale. */
-    get(config: ServiceConfig, watcher: WatcherClient): Promise<MetaListResult>;
-    /** Force-expire the cache so next get() triggers a refresh. */
-    invalidate(): void;
-    private refresh;
-}