@karmaniverous/jeeves-meta 0.16.3 → 0.18.0-0

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

@@ -1,173 +0,0 @@
-# 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.
-
-{{#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:
-
-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
-
-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.
-
-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.
-
-### 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.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. Limit output to \{{config.maxLines}} lines."
-
-## 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

@@ -1,104 +0,0 @@
-# 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.d.ts

@@ -1,10 +0,0 @@
-/**
- * Commander CLI for jeeves-meta service.
- *
- * Uses `createServiceCli` from the core SDK for standard commands
- * (start, status, config, init, service). Custom domain-specific
- * commands are registered via `descriptor.customCliCommands`.
- *
- * @module cli
- */
-export {};

package/dist/configHotReload.d.ts

@@ -1,30 +0,0 @@
-/**
- * Shared live config hot-reload support.
- *
- * Used by both file-watch reloads in bootstrap and POST /config/apply
- * via the component descriptor's onConfigApply callback.
- *
- * @module configHotReload
- */
-import type { Logger } from 'pino';
-import type { Scheduler } from './scheduler/index.js';
-import type { ServiceConfig } from './schema/config.js';
-/**
- * Fields that require a service restart to take effect.
- *
- * Shared between the descriptor's `onConfigApply` and the file-watcher
- * hot-reload in `bootstrap.ts`.
- */
-export declare const RESTART_REQUIRED_FIELDS: readonly ["port", "watcherUrl", "gatewayUrl", "gatewayApiKey"];
-interface ConfigHotReloadRuntime {
-    config: ServiceConfig;
-    logger: Logger;
-    scheduler: Scheduler | null;
-}
-/** Register the active service runtime for config-apply hot reload. */
-export declare function registerConfigHotReloadRuntime(nextRuntime: ConfigHotReloadRuntime): void;
-/** Clear the registered runtime. Primarily for tests. */
-export declare function clearConfigHotReloadRuntime(): void;
-/** Apply hot-reloadable config changes to the live shared config object. */
-export declare function applyHotReloadedConfig(newConfig: ServiceConfig): void;
-export {};

package/dist/configLoader.d.ts

@@ -1,36 +0,0 @@
-/**
- * Load and resolve jeeves-meta service config.
- *
- * Supports environment-variable substitution (dollar-brace pattern).
- *
- * @module configLoader
- */
-import { type ServiceConfig } from './schema/config.js';
-/**
- * Migrate legacy config path to the new canonical location.
- *
- * If the old path `{configRoot}/jeeves-meta.config.json` exists and the new
- * path `{configRoot}/jeeves-meta/config.json` does NOT exist, copies the file
- * to the new location and logs a warning.
- *
- * @param configRoot - Root directory for configuration files.
- * @param warn - Optional callback for logging the migration warning.
- */
-export declare function migrateConfigPath(configRoot: string, warn?: (msg: string) => void): void;
-/**
- * Resolve config path from --config flag or JEEVES_META_CONFIG env var.
- *
- * @param args - CLI arguments (process.argv.slice(2)).
- * @returns Resolved config path.
- * @throws If no config path found.
- */
-export declare function resolveConfigPath(args: string[]): string;
-/**
- * Load service config from a JSON file.
- *
- * Substitutes environment-variable placeholders throughout.
- *
- * @param configPath - Path to config JSON file.
- * @returns Validated ServiceConfig.
- */
-export declare function loadServiceConfig(configPath: string): ServiceConfig;

package/dist/constants.d.ts

@@ -1,13 +0,0 @@
-/**
- * Shared constants for the jeeves-meta service package.
- *
- * @module constants
- */
-/** Default HTTP port for the jeeves-meta service. */
-export declare const DEFAULT_PORT: 1938;
-/** Default port as a string (for Commander CLI defaults). */
-export declare const DEFAULT_PORT_STR: string;
-/** Service name identifier. */
-export declare const SERVICE_NAME = "jeeves-meta";
-/** Service version, read from package.json at startup. */
-export declare const SERVICE_VERSION: string;

package/dist/customCliCommands.d.ts

@@ -1,13 +0,0 @@
-/**
- * Custom CLI commands for the jeeves-meta service.
- *
- * Registered via `descriptor.customCliCommands` and added to the
- * standard service CLI produced by `createServiceCli`.
- *
- * @module customCliCommands
- */
-import { type Command } from 'commander';
-/** Build the full API URL for a given port string and path. */
-export declare function apiUrl(port: string, apiPath: string): string;
-/** Register all custom meta commands on the parent program. */
-export declare function registerCustomCliCommands(program: Command): void;

package/dist/descriptor.d.ts

@@ -1,19 +0,0 @@
-/**
- * Jeeves component descriptor for jeeves-meta.
- *
- * Single source of truth consumed by the service CLI, plugin writer, and
- * config-apply pipeline.
- *
- * @module descriptor
- */
-import { type JeevesComponentDescriptor } from '@karmaniverous/jeeves';
-import { RESTART_REQUIRED_FIELDS } from './configHotReload.js';
-import { loadServiceConfig } from './configLoader.js';
-import { type ServiceConfig } from './schema/config.js';
-export { RESTART_REQUIRED_FIELDS };
-/**
- * Parsed jeeves-meta component descriptor.
- */
-export declare const metaDescriptor: JeevesComponentDescriptor;
-export type { ServiceConfig };
-export { loadServiceConfig };

package/dist/discovery/buildMinimalNode.d.ts

@@ -1,22 +0,0 @@
-/**
- * Build a minimal MetaNode from a known meta path using watcher walk.
- *
- * Used for targeted synthesis (when a specific path is requested) to avoid
- * the full discovery + ownership tree build. Discovers only immediate child
- * `.meta/` directories.
- *
- * @module discovery/buildMinimalNode
- */
-import type { WatcherClient } from '../interfaces/index.js';
-import type { MetaNode } from './types.js';
-/**
- * Build a minimal MetaNode for a known meta path.
- *
- * Walks the owner directory for child `.meta/meta.json` files and constructs
- * a shallow ownership tree (self + direct children only).
- *
- * @param metaPath - Absolute path to the `.meta/` directory.
- * @param watcher - WatcherClient for filesystem enumeration.
- * @returns MetaNode with direct children wired.
- */
-export declare function buildMinimalNode(metaPath: string, watcher: WatcherClient): Promise<MetaNode>;

package/dist/discovery/computeSummary.d.ts

@@ -1,17 +0,0 @@
-/**
- * Compute summary statistics from an array of MetaEntry objects.
- *
- * Shared between listMetas() (full list) and route handlers (filtered lists).
- *
- * @module discovery/computeSummary
- */
-import type { MetaListSummary } from '@karmaniverous/jeeves-meta-core';
-import type { MetaEntry } from './listMetas.js';
-/**
- * Compute summary statistics from a list of meta entries.
- *
- * @param entries - Enriched meta entries (full or filtered).
- * @param depthWeight - Config depth weight for effective staleness calculation.
- * @returns Aggregated summary statistics.
- */
-export declare function computeSummary(entries: MetaEntry[], depthWeight: number): MetaListSummary;

package/dist/discovery/discoverMetas.d.ts

@@ -1,19 +0,0 @@
-/**
- * Discover .meta/ directories via watcher `/walk` endpoint.
- *
- * Uses filesystem enumeration through the watcher (not Qdrant) to find
- * all `.meta/meta.json` files and returns deduplicated meta directory paths.
- *
- * @module discovery/discoverMetas
- */
-import type { WatcherClient } from '../interfaces/index.js';
-/**
- * Discover all .meta/ directories via watcher walk.
- *
- * Uses the watcher's `/walk` endpoint to find all `.meta/meta.json` files
- * and returns deduplicated meta directory paths.
- *
- * @param watcher - WatcherClient for walk queries.
- * @returns Array of normalized .meta/ directory paths.
- */
-export declare function discoverMetas(watcher: WatcherClient): Promise<string[]>;

package/dist/discovery/getAncestorMeta.d.ts

@@ -1,16 +0,0 @@
-/**
- * Retrieve the nearest ancestor meta node from the ownership tree.
- *
- * @module discovery/getAncestorMeta
- */
-import type { MetaNode } from './types.js';
-/**
- * Get the nearest ancestor MetaNode for a given node.
- *
- * Walks up the ownership tree (via the parent pointer set by
- * buildOwnershipTree) to find the closest ancestor .meta/ directory.
- *
- * @param node - The meta node to find the ancestor for.
- * @returns The parent MetaNode, or null for root-level metas.
- */
-export declare function getAncestorMeta(node: MetaNode): MetaNode | null;

package/dist/discovery/index.d.ts

@@ -1,12 +0,0 @@
-/**
- * Discovery module — glob .meta/ directories and build ownership tree.
- *
- * @module discovery
- */
-export { computeSummary } from './computeSummary.js';
-export { discoverMetas } from './discoverMetas.js';
-export { getAncestorMeta } from './getAncestorMeta.js';
-export { listMetas, type MetaEntry, type MetaListResult, type MetaListSummary, } from './listMetas.js';
-export { buildOwnershipTree, findNode } from './ownershipTree.js';
-export { filterInScope, getDeltaFiles, getScopeFiles, getScopePrefix, } from './scope.js';
-export type { MetaNode, OwnershipTree } from './types.js';

package/dist/discovery/listMetas.d.ts

@@ -1,63 +0,0 @@
-/**
- * Unified meta listing: scan, dedup, enrich.
- *
- * Single source of truth for all consumers that need a list of metas
- * with enriched metadata. Replaces duplicated scan+dedup logic in
- * plugin tools, CLI, and prompt injection.
- *
- * @module discovery/listMetas
- */
-import type { MetaListSummary } from '@karmaniverous/jeeves-meta-core';
-import type { WatcherClient } from '../interfaces/index.js';
-import type { MetaConfig, MetaJson } from '../schema/index.js';
-import type { MetaNode, OwnershipTree } from './types.js';
-/** Enriched meta entry returned by listMetas(). */
-export interface MetaEntry {
-    /** Normalized .meta/ directory path. */
-    path: string;
-    /** Tree depth (0 = leaf, higher = more abstract). */
-    depth: number;
-    /** Scheduling emphasis multiplier. */
-    emphasis: number;
-    /** Seconds since last synthesis, or Infinity if never synthesized. */
-    stalenessSeconds: number;
-    /** ISO timestamp of last synthesis, or null. */
-    lastSynthesized: string | null;
-    /** Whether the last synthesis had an error. */
-    hasError: boolean;
-    /** Whether this meta is currently locked. */
-    locked: boolean;
-    /** Whether this meta is disabled (skipped during staleness scheduling). */
-    disabled: boolean;
-    /** Cumulative architect tokens, or null if never run. */
-    architectTokens: number | null;
-    /** Cumulative builder tokens, or null if never run. */
-    builderTokens: number | null;
-    /** Cumulative critic tokens, or null if never run. */
-    criticTokens: number | null;
-    /** Number of direct children in the ownership tree. */
-    children: number;
-    /** The underlying MetaNode from the ownership tree. */
-    node: MetaNode;
-    /** The parsed meta.json content. */
-    meta: MetaJson;
-}
-export type { MetaListSummary };
-/** Full result from listMetas(). */
-export interface MetaListResult {
-    summary: MetaListSummary;
-    entries: MetaEntry[];
-    tree: OwnershipTree;
-}
-/**
- * Discover, deduplicate, and enrich all metas.
- *
- * This is the single consolidated function that replaces all duplicated
- * scan+dedup+enrich logic across the codebase. All enrichment comes from
- * reading meta.json on disk (the canonical source).
- *
- * @param config - Validated synthesis config.
- * @param watcher - Watcher HTTP client for discovery.
- * @returns Enriched meta list with summary statistics and ownership tree.
- */
-export declare function listMetas(config: MetaConfig, watcher: WatcherClient): Promise<MetaListResult>;

package/dist/discovery/ownershipTree.d.ts

@@ -1,25 +0,0 @@
-/**
- * Build the ownership tree from discovered .meta/ paths.
- *
- * Each .meta/ directory owns its parent directory and all descendants,
- * except subtrees that contain their own .meta/. For those subtrees,
- * the parent meta consumes the child meta's synthesis output.
- *
- * @module discovery/ownershipTree
- */
-import type { MetaNode, OwnershipTree } from './types.js';
-/**
- * Build an ownership tree from an array of .meta/ directory paths.
- *
- * @param metaPaths - Absolute paths to .meta/ directories.
- * @returns The ownership tree with parent/child relationships.
- */
-export declare function buildOwnershipTree(metaPaths: string[]): OwnershipTree;
-/**
- * Find a node in the ownership tree by meta path or owner path.
- *
- * @param tree - The ownership tree to search.
- * @param targetPath - Path to search for (meta path or owner path).
- * @returns The matching node, or undefined if not found.
- */
-export declare function findNode(tree: OwnershipTree, targetPath: string): MetaNode | undefined;

package/dist/discovery/scope.d.ts

@@ -1,47 +0,0 @@
-/**
- * Compute the file scope owned by a meta node.
- *
- * A meta owns: parent dir + all descendants, minus:
- * - Its own .meta/ subtree (outputs, not inputs)
- * - Child meta ownerPath subtrees (except their .meta/meta.json for rollups)
- *
- * All filesystem enumeration delegated to the watcher's `/walk` endpoint.
- *
- * @module discovery/scope
- */
-import type { WatcherClient } from '../interfaces/index.js';
-import type { MinimalLogger } from '../logger/index.js';
-import type { MetaNode } from './types.js';
-/**
- * Get the scope path prefix for a meta node.
- */
-export declare function getScopePrefix(node: MetaNode): string;
-/**
- * Filter a list of file paths to only those in scope for a meta node.
- *
- * Excludes:
- * - The node's own .meta/ subtree (synthesis outputs are not scope inputs)
- * - Child meta ownerPath subtrees (except child .meta/meta.json for rollups)
- *
- * Watcher walk returns normalized forward-slash paths.
- */
-export declare function filterInScope(node: MetaNode, files: string[]): string[];
-/** Result of getScopeFiles. */
-interface ScopeFilesResult {
-    /** Files directly owned by this meta (excluding child subtrees and own .meta/). */
-    scopeFiles: string[];
-    /** All files under the owner path (including child subtrees). */
-    allFiles: string[];
-}
-/**
- * Get all files in scope for a meta node via watcher walk.
- */
-export declare function getScopeFiles(node: MetaNode, watcher: WatcherClient, logger?: MinimalLogger): Promise<ScopeFilesResult>;
-/**
- * Get files modified since a given timestamp within a meta node's scope.
- *
- * If no generatedAt is provided (first run), returns all scope files.
- * Reuses scope files from getScopeFiles() and filters locally by mtime.
- */
-export declare function getDeltaFiles(generatedAt: string | undefined, scopeFiles: string[]): string[];
-export {};

package/dist/discovery/types.d.ts

@@ -1,25 +0,0 @@
-/**
- * Types for meta discovery and ownership tree.
- *
- * @module discovery/types
- */
-/** A discovered meta node in the ownership tree. */
-export interface MetaNode {
-    /** Absolute path to the .meta directory. */
-    metaPath: string;
-    /** Absolute path to the parent directory that this meta owns. */
-    ownerPath: string;
-    /** Depth in the ownership tree (root = 0). */
-    treeDepth: number;
-    /** Child meta nodes (subtrees with their own .meta/). */
-    children: MetaNode[];
-    /** Parent meta node, or null for roots. */
-    parent: MetaNode | null;
-}
-/** The full ownership tree discovered from watchPaths. */
-export interface OwnershipTree {
-    /** All discovered meta nodes, keyed by metaPath. */
-    nodes: Map<string, MetaNode>;
-    /** Root nodes (metas with no parent meta). */
-    roots: MetaNode[];
-}