/** * Local `tenx @apps/mcp` runner — feeds a caller-supplied pipeline config and * optional JS modules to the local dev CLI, pipes sample log lines in via * stdin, captures stdout/stderr, and returns the lot as structured JSON. * * Designed so an MCP caller (typically an agent preparing a pipeline-config * change) can test-drive the behavior before deploying: mount a candidate * object constructor / filter function / module override, pipe a few * representative events through, read back the templates and emitted events, * and any TenXConsole.log output. * * Requires: * - a local Log10x engine: `tenx` on PATH (install for macOS/Linux/Windows: * https://doc.log10x.com/install/) or a local Docker container * (LOG10X_TENX_MODE=docker) * - the workspace config + modules tree already on disk. By default we * point at `LOG10X_TENX_CONFIG_ROOT` / `LOG10X_TENX_MODULES_ROOT`; fall * back to opinionated paths that match the shipped repo layout. * * What we do NOT do: * - generate sample events ourselves. Callers pass `input_lines` — it is * the caller's responsibility to synthesize realistic shapes (the agent * using its own LLM context is better at that than any templating we * could bake in). * - persist anything. Mounted files go into a temp dir; temp dir is * deleted on exit (even if the CLI fails). */ export interface ValidateRunResult { /** Process exit code. 0 = pipeline ran cleanly. */ exitCode: number; /** Wall time in ms, from spawn to exit. */ wallTimeMs: number; /** CLI version string, captured via `tenx --version`. */ cliVersion?: string; /** Raw stdout output, as a single string. */ stdout: string; /** Raw stderr output, as a single string. */ stderr: string; /** * Parsed encoded-event lines from stdout (one entry per `~...` line). * Each entry is the tilde-prefixed tokens split into `[templateHash, ...tokens]`. * Empty when the pipeline emits no events (e.g. all filtered). */ events: Array<{ templateHash: string; tokens: string[]; }>; /** * Parsed template JSON lines from stdout (one entry per `{"templateHash":...}` line). */ templates: Array<{ templateHash: string; template: string; }>; /** * Lines from stdout that are NOT encoded events, NOT templates, and NOT * known CLI banners. This is where caller-side TenXConsole.log lines * surface — the only way the caller sees assertions the mounted JS made. */ consoleLines: string[]; } export interface ValidateRunOptions { /** * Sample input lines, one event per line. Piped to tenx via stdin. * Caller generates these (agent-side) from natural-language intent. */ input_lines: string[]; /** * Map of relative path → file contents. Each entry is materialized into * the temp config overlay rooted at the same directory layout as the * shipped config repo (e.g., `pipelines/run/initialize/custom/debug.js` * or `apps/cloud/streamer/stream/my-filter.js`). Included files are * picked up by the pipeline's existing include globs — so a JS file * placed under `pipelines/run/initialize/custom/` auto-loads without * any further wiring. */ extra_files?: Record; /** * Which launch config to invoke. Default `@apps/mcp` (stdin/stdout * scaffold shipped alongside this tool). */ pipeline_app?: string; /** * Additional positional CLI args appended to the `tenx` invocation. * Useful for passing runtime config like `symbolPaths ` or * `stdoutWriteObjects false`. Each [key, value] pair is two args. */ extra_args?: Array<[string, string]>; /** * Hard cap on wall time. Default 60s. The CLI is killed if it exceeds. */ timeout_ms?: number; } /** * Run the local tenx CLI against the provided pipeline + mounted files + * sample stdin input. Single-call: spawn → pipe → wait → kill-on-timeout → * clean up temp dir → return structured result. */ export declare function runValidate(opts: ValidateRunOptions): Promise;