@interf/compiler 0.2.5 → 0.3.1

package/README.md

@@ -1,39 +1,19 @@
 # Interf
 
-Interf is an eval-first knowledge compiler for agents such as Claude Code and Codex.
+Open-source knowledge compiler for your files.
 
-If you use OpenClaw, Hermes, or your own local retrieval workflow, the real problem is not opening a folder. It is getting the agent to work correctly on raw filesystem data without missing evidence, doing shallow analysis, or hallucinating once the task spans several files.
+Interf measures and improves how accurately local agents answer questions from your files.
 
-- your files stay on your machine
-- you choose the local agent
-- you decide what must be true
-
-Agents start missing things when a task spans PDFs, charts, and several files in one folder. That usually shows up when the job depends on:
-
-- reading reports and filings
-- extracting a number from a chart
-- understanding what is inside a folder before doing work
-- pulling context together across several files
-- checking the raw source when the answer has to be exact
-
-Raw filesystem data often looks fine until it is too late. The failure shows up as a missed number, a bad comparison, or an answer that sounds confident but is wrong.
-
-That is why compilation matters. Before the agent does the real job, the folder needs preparation.
+If you use Claude Code, Codex, OpenClaw, Hermes, or your own local agent setup on folders full of PDFs, docs, spreadsheets, and notes, the failure often shows up late: missed evidence, shallow analysis, bad comparisons, or answers that sound confident but are wrong.
 
-Interf Knowledge Compiler runs a local data pipeline with your agent as the executor. It produces a compiled workspace beside the raw files, with distilled notes and cross-file structure so the agent can understand what is in the folder, navigate it faster, and retrieve the right content without rediscovering everything from scratch.
+Interf lets you write a few questions and expected answers about your files, test the raw files first if you want a baseline, build a compiled workspace on top of those files, and see whether the result actually passes.
 
-Interf gives you a simple loop:
-
-- point Interf at a folder
-- say what must be true in `interf.config.json`
-- run `interf benchmark` to see how your agent does on the raw folder
-- compile a workspace beside the raw files
-- run the same evals again
-- keep the compiled workspace only if it performs better on your evals
-
-The first output is a shared compiled workspace for the whole folder.
+- your files stay on your machine
+- you choose the local agent
+- your raw files stay the source of truth
+- Interf adds a file-based layer on top
 
-Create an interface only when you want a second compiled workspace for one recurring job, with narrower retrieval, job-specific outputs, and extra evals for that job.
+It runs local data-processing pipelines with your agents as executors and produces a compiled workspace: a file-based layer on top of your raw files that agents can navigate, inspect, and work from.
 
 ## Quick Start
 
@@ -48,108 +28,110 @@ Install:
 npm install -g @interf/compiler
 ```
 
-Then run Interf in any folder:
+The quickest start is the wizard:
 
 ```bash
 cd ~/my-folder
-interf init
-interf benchmark
+interf
+```
+
+If you want to see the config shape first, this is what Interf writes:
+
+```json
+{
+  "workspaces": [
+    {
+      "name": "default",
+      "about": "General compiled workspace for the quarterly results folder.",
+      "checks": [
+        {
+          "question": "What full-year revenue range did the company maintain?",
+          "answer": "$4.8B to $5.0B in revenue."
+        },
+        {
+          "question": "Did gross margin improve or decline year over year?",
+          "answer": "Gross margin declined year over year."
+        }
+      ]
+    }
+  ]
+}
+```
+
+The root-level flow is:
+
+```bash
+interf
 interf compile
-interf benchmark
+interf test
 ```
 
-That is the whole first loop:
+The first guided run can:
 
-- point Interf at a folder you already have
-- let `interf init` write the first evals in `interf.config.json`
-- run `interf benchmark` on the raw folder first
+- save a few questions and expected answers for this folder
+- run a baseline test on the raw files
 - compile the workspace
-- run `interf benchmark` again to see pass/fail on raw vs compiled
+- run the same test against the compiled workspace
 
-`interf init` chooses your local agent, can draft `interf.config.json` if it is missing, and can attach the current folder right away. It does not move or replace your files.
+That gives you three concrete things:
 
-The compiled workspace is just a normal folder. Open it in your editor, in your agent, or in Obsidian if you want the graph view.
+- `interf/workspaces/default/` with the compiled workspace for your files
+- `interf/benchmarks/runs/...` with the saved test result
+- a pass/fail score on the same questions and expected answers you wrote
 
-If Interf cannot find your local agent or compile setup, run:
+If `interf.config.json` is missing, `interf` or `interf init` can draft it with you before the first compile. If Interf cannot find your local agent or compile setup, run:
 
 ```bash
 interf doctor
 ```
 
-Fastest sample loop:
-
-```bash
-cp -r examples/benchmark-demo /tmp/interf-demo
-cd /tmp/interf-demo
-interf init
-interf benchmark
-interf compile
-interf benchmark
-```
+The first flow is:
 
-If you want a second compiled workspace shaped for one recurring job, add an interface:
+- write down a few questions your agent should be able to answer from your files
+- let `interf` or `interf init` save those checks in `interf.config.json`
+- optionally run a baseline test on the raw files
+- run `interf compile` to build the compiled workspace
+- run `interf test` to test the raw files, the compiled workspace, or both
+- only create another workspace if you want a separate compiled setup with its own checks
+- if needed, rerun compile or use the advanced retry path until it is good enough
 
-```bash
-interf create interface
-interf compile
-interf benchmark
-```
+## Why This Approach
 
-An interface is useful when the shared workspace is still too broad and you want:
+Interf is built around a few simple design principles:
 
-- narrower retrieval for one job
-- job-specific outputs
-- extra evals on top of the shared baseline
+- `Explicit`: the output is visible and inspectable, not hidden memory
+- `Local`: your files stay on your machine
+- `File over app`: the output is just files, so you can use your editor, Unix tools, Obsidian, or your own software on top
+- `BYOAI`: use Claude Code, Codex, OpenClaw, Hermes, or your own model
 
-## Start With One Small Eval
+Interf does not replace your data with an opaque store. It keeps the raw files in place and adds a file-based layer on top for agents.
 
-`interf.config.json` is where you write what must be true.
+Sample flow:
 
-If the file is missing, `interf init` can draft it with you before the first compile. You can edit it any time.
+```bash
+cp -r examples/benchmark-demo /tmp/interf-demo
+cd /tmp/interf-demo
+interf
+interf compile
+interf test
+```
 
-Use it for:
+## Start With A Few Questions
 
-- top-level `evals` for shared baseline checks
-- `interfaces[].evals` for task-specific additional checks
+`interf.config.json` is where you write the questions and expected answers for a folder.
 
-Both live in the same root `interf.config.json`.
+That file uses one `workspaces` array:
 
-Example shape:
+- most folders only need one workspace
+- add another workspace only if you want a separate compiled setup with different checks
+- each workspace carries its own `checks`
 
-Top-level `evals` are shared baseline checks for the workspace and every interface. Each entry in `interfaces` adds extra checks for one dedicated job.
+If the file is missing, `interf init` can draft it with you before the first compile. You can edit it any time.
 
-```json
-{
-  "evals": [
-    {
-      "question": "What changed in full-year guidance?",
-      "answer": "Full-year guidance was maintained at $4.8B to $5.0B in revenue."
-    },
-    {
-      "question": "Did gross margin improve or decline year over year?",
-      "answer": "Gross margin declined year over year."
-    }
-  ],
-  "interfaces": [
-    {
-      "name": "operator-briefing",
-      "about": "Prepare tomorrow's operator briefing from the quarterly results folder.",
-      "evals": [
-        {
-          "question": "What revenue range did the company maintain for full-year guidance?",
-          "answer": "$4.8B to $5.0B in revenue."
-        },
-        {
-          "question": "What should the operator pay attention to next quarter?",
-          "answer": "Watch guidance, gross margin, and any demand changes mentioned in the report."
-        }
-      ]
-    }
-  ]
-}
-```
+That example is just `interf.config.json`.
+Advanced retry settings do not live there.
 
-Good first evals are small and practical:
+Good first checks are small and practical:
 
 - one exact number from a chart, table, or filing
 - one short statement that should be true or false
@@ -158,158 +140,181 @@ Good first evals are small and practical:
 Then run:
 
 ```bash
-interf benchmark
 interf compile
-interf benchmark
+interf test
 ```
 
-If the benchmark does not show an improvement over raw files, keep iterating on evals or workflow choice first. Use the experiment loop below only when you want the advanced automated path.
+## What `interf test` Compares
 
-## Compare Three Things
+`interf test` scores either the raw files, a compiled workspace, or both on the same saved questions and expected answers.
 
-Compare:
+It lets you answer a simple question:
 
-1. the raw folder
-2. the workspace
-3. an interface for one specific job
+- what is the current baseline on the raw files?
+- does this compiled workspace improve on that baseline?
+- which compiled workspace or workflow performs better on the same folder?
+- does a separate workspace with different checks work better for that job?
 
-`interf benchmark` runs the same evals against each one and saves a pass/fail report.
+By default it loads checks from `interf.config.json`, can run a raw baseline in an isolated raw-files sandbox, can test eligible compiled workspaces under `interf/workspaces/`, and saves the run under `interf/benchmarks/runs/`.
 
-That gives you one clear question:
+If you run `interf test` from inside a workspace, it uses that workspace's checks and tests that workspace. If you run it from the source folder, it lets you choose a saved workspace and then choose raw files, the compiled workspace, or both.
 
-- is the raw folder enough?
-- does the workspace retrieve better?
-- does a dedicated interface do better than both?
+Live test runs use an isolated sandbox. For raw baselines, Interf gives the agent sanitized raw files only. For compiled-workspace tests, it gives the agent a copied workspace plus sanitized raw files. The source-folder control plane, `interf.config.json`, and saved test runs are not part of those sandboxes.
 
-## What `interf compile` Actually Does
+If you need repeated isolated experiments across workflows or models, use the advanced eval-pack runner in [docs/eval-loop.md](./docs/eval-loop.md).
 
-`interf compile` runs a workflow over your folder.
+## What `interf compile` Does
 
-That workflow is the compilation pipeline:
+`interf compile` runs the Interf data-processing pipeline over your files.
 
-- read the files
-- write processed notes and navigation files
-- build the workspace your agent can use
-- optionally build an interface for one specific job
+By default, that means:
 
-The default workflow is built in. If you want a different method, you can define your own workflow package and benchmark it on the same folder.
+- summarize the source files into per-file evidence notes
+- structure the cross-file knowledge layer into entities, claims, and indexes
+- shape the final workspace around its saved focus and questions
 
-## Experiment Loop
+In other words, the built-in workflow is:
 
-Interf Knowledge Compiler also supports an advanced experiment loop above compile + benchmark.
+1. `summarize`
+2. `structure`
+3. `shape`
 
-This is the eval-first part of the product. You give Interf the folder and the evals that must pass. Interf keeps running controlled compile + benchmark attempts against that same truth surface until it either gets a working result or runs out of attempts.
+In public docs, `pipeline` is the thing Interf runs. `workflow` is the saved method that defines or customizes that pipeline.
 
-Each attempt reruns the compilation workflow, reruns the benchmark, and records what changed. It stops when:
+The default workflow is built in. If you want a different method, you can define your own workflow package and benchmark it on the same folder.
 
-- the evals pass
-- or the experiment budget is exhausted
+## What Gets Created
 
-In practice, that means:
+After compile, Interf writes into `./interf/` beside your source files.
 
-- `retry_policy.max_attempts_per_profile` controls how many experiment attempts each compile profile gets
-- stronger diagnostic profiles can be used only after the default ones fail
-- the loop is still judged on the same eval truth from your folder
-- failure summaries can be captured between attempts for diagnosis
+- `interf/workspaces/<name>/` is a compiled workspace over the folder
+- `interf/benchmarks/runs/...` stores saved test runs
 
-Today that advanced path is configured through eval packs and explained in the deeper docs. The workflow is the part that changes. The experiment loop is the controller that keeps trying workflows and profiles against the same evals with a fixed attempt budget.
+Inside those workspaces you will see things like:
 
-Use the simple loop first. Use the experiment loop when you want Interf to keep improving the local compilation workflow until the workspace is ready for your task or the attempt budget runs out.
+- summaries of source files
+- navigation notes and entrypoints for agents
+- cross-file knowledge notes
+- workspace-specific outputs when you define a separate job-focused workspace
 
-## Use It With Your Agent
+The compiled workspace is just a normal folder. Open it in your editor, in your agent, or in Obsidian if you want the graph view.
 
-If you already work through Claude Code, Codex, OpenClaw, or Hermes, the agent can run this loop for you.
+If you use Obsidian, open `interf/workspaces/<name>/` as the vault for the compiled workspace.
 
-Paste something like this into Claude Code, Codex, OpenClaw, or Hermes:
+## Terminology
 
-```text
-Install @interf/compiler, run `interf init` in this folder, and use the local agent executor.
+Public terms:
 
-If `interf.config.json` is missing, draft evals for what must be true for this task and ask me to confirm them.
+- `your files` = the source folder Interf reads from
+- `questions and expected answers` = the checks you want your agent to pass
+- `checks` = the pass/fail questions each workspace should satisfy
+- `test` = run the saved questions and get a score
+- `compiled workspace` = the output Interf produces on top of a folder
+- `workspace` = one compiled setup with its own checks
 
-Then run `interf benchmark`, `interf compile`, and `interf benchmark` again.
+Technical terms:
 
-Tell me whether the processed workspace beat raw files, and only recommend it if it did.
-```
+- `source folder` = the raw files Interf reads from
+- `benchmark` = the technical alias and saved-run layer behind `interf test`
+- `workflow` = the saved method that defines or customizes the pipeline
+- `.interf/` = runtime state, proofs, and health artifacts
 
-That is the basic loop:
+## Advanced: Separate Workspaces
 
-- the user or agent defines what must be true
-- benchmark the raw folder first
-- Interf prepares the compiled workspace
-- benchmark again and keep it only if it helped
+Most folders only need one workspace.
 
-## What Gets Created
+Create another only when you want a different compiled setup with different checks, for example:
 
-After compile, Interf writes into `./interf/` beside your source files.
+- general folder understanding
+- finance reporting
+- board prep
+- diligence review
 
-- `interf/<name>/` is the shared workspace over the folder
-- `interf/<name>/interfaces/<name>/` is a task-specific workspace for one job
-- `interf/benchmarks/runs/...` stores saved benchmark runs
+Why create another one:
 
-Inside those workspaces you will see things like:
+- it keeps a separate set of questions and expected answers
+- it gives that job its own compiled output under `interf/workspaces/<name>/`
+- it lets you test that job separately
 
-- summaries of source files
-- navigation notes and entrypoints for agents
-- task-specific outputs for one interface
-- benchmark artifacts you can inspect later
+## Advanced: Keep Improving Until It Passes
+
+Interf also supports an advanced experiment path above the normal build + test flow.
 
-In the CLI, the main Interf workspace is called a **knowledge base**. A task-specific workspace inside it is called an **interface**.
+Give it the same folder and the same checks. Interf can keep rerunning compile + test attempts until the test passes or the attempt budget runs out.
 
-Conceptually, the compiled workspace is a knowledge representation of the folder for agents. In the product and CLI, the concrete objects are the compiled workspace, the knowledge base, and the interface.
+In practice:
 
-If you use Obsidian, open `interf/<name>/` as the vault for the main compiled workspace. If you are working with interfaces, open the parent knowledge-base folder so links across summaries, knowledge notes, and interfaces keep resolving.
+- `retry_policy.max_attempts_per_profile` controls how many attempts each compile profile gets
+- stronger diagnostic profiles can be used only after the default ones fail
+- the checks stay the same across every attempt
+- each attempt records what changed
+
+Example eval-pack shape:
 
-## What An Interface Is
+```jsonc
+{
+  "workspaces": [
+    {
+      "name": "default",
+      "checks": [
+        {
+          "question": "What full-year revenue range did the company maintain?",
+          "answer": "$4.8B to $5.0B in revenue."
+        }
+      ]
+    }
+  ],
+  // Advanced only: retry settings live in eval packs, not in interf.config.json.
+  "retry_policy": {
+    "max_attempts_per_profile": 3
+  }
+}
+```
 
-Start with one workspace.
+Today this lives in the advanced eval-pack runner, not in `interf.config.json` and not in a top-level `interf compile --max-retries` flag.
 
-An interface is a second compiled workspace for one recurring job.
+Use the normal test flow first. Use this advanced path when you want Interf to keep improving the local preparation workflow until the workspace is good enough for your task or the attempt budget runs out. It spends more tokens, so use it when that extra spend is worth the accuracy target.
 
-The main compiled workspace is the shared layer for the whole folder. Use it for broad questions such as:
+## Use It With Your Agent
 
-- what is in this folder?
-- what changed?
-- where is the source evidence?
+If you already work through Claude Code, Codex, OpenClaw, or Hermes, the agent can run this process for you.
 
-Create an interface when that broad layer is no longer enough and the work becomes a repeatable job, for example:
+Paste something like this into your agent:
 
-- prepare tomorrow's operator briefing
-- run diligence on this deal room
-- extract chart values from this report set
-- answer one recurring research question set
+```text
+Install @interf/compiler, run `interf` in this folder, and use the local agent executor.
 
-Why create one:
+If `interf.config.json` is missing, draft one workspace with a few checks this agent should be able to answer from these files and add the expected answers for me to confirm.
 
-- it narrows what the agent should retrieve for that job
-- it writes job-specific outputs on top of the shared workspace
-- it lets you add extra task-specific evals on top of the shared evals
+Then run a raw baseline if helpful, compile the workspace, and run `interf test`.
 
-If the shared workspace is already enough for the job, do not create an interface yet.
+Tell me whether the compiled workspace passes the checks, and only recommend it if it does.
+```
 
 ## Custom Workflows
 
 Interf ships with a default workflow.
 
-If you want to change how compilation happens on your data, this is the part you customize:
+If you want to change how the data-processing pipeline runs on your files, this is the part you customize:
 
 ```bash
 interf create workflow
 interf verify workflow --path <path>
 ```
 
-Then benchmark that workflow on the same folder and the same evals.
+Then benchmark that workflow on the same folder and the same checks.
 
 Workflow package docs live in [docs/workflow-spec.md](./docs/workflow-spec.md).
 
 ## Core Commands
 
-- `interf init` = choose your local executor and optionally attach the current folder
-- `interf create knowledge-base` = create the shared processed workspace for this folder
-- `interf create interface` = create a task-specific workspace on top
+- `interf` = open the root-folder wizard
+- `interf init` = alias for the root-folder wizard
+- `interf create workspace` = create another compiled workspace when you need one
 - `interf create workflow` = create a reusable local workflow package
-- `interf compile` = build the current workspace
-- `interf benchmark` = compare raw files vs processed workspaces on your evals
+- `interf compile` = build a selected workspace for the current folder
+- `interf test` = test the raw files, a compiled workspace, or both on saved checks
+- `interf benchmark` = alias for `interf test`
 - `interf doctor` = check local executor setup
 - `interf verify <check>` = run deterministic checks on major workflow steps
 - `interf reset <scope>` = remove generated state while keeping source files
@@ -319,7 +324,7 @@ Workflow package docs live in [docs/workflow-spec.md](./docs/workflow-spec.md).
 - [docs/workflow-spec.md](./docs/workflow-spec.md) for custom workflow packages
 - [docs/runtime-contract.md](./docs/runtime-contract.md) for the exact on-disk contract
 - [docs/architecture.md](./docs/architecture.md) for the deeper system model
-- [docs/eval-loop.md](./docs/eval-loop.md) for the advanced benchmark and experiment loop
+- [docs/eval-loop.md](./docs/eval-loop.md) for advanced eval-pack experiments across workflows and models
 
 Maintainers should use [CONTRIBUTING.md](./CONTRIBUTING.md) for test and release gates.
 

package/dist/bin.js

@@ -4,7 +4,7 @@ import { hideBin } from "yargs/helpers";
 import { initCommand } from "./commands/init.js";
 import { createCommand } from "./commands/create.js";
 import { compileCommand } from "./commands/compile.js";
-import { benchmarkCommand } from "./commands/benchmark.js";
+import { testCommand } from "./commands/test.js";
 import { doctorCommand } from "./commands/doctor.js";
 import { listCommand } from "./commands/list.js";
 import { statusCommand } from "./commands/status.js";
@@ -15,9 +15,9 @@ yargs(hideBin(process.argv))
     .scriptName("interf")
     .command(defaultCommand)
     .command(initCommand)
-    .command(createCommand)
     .command(compileCommand)
-    .command(benchmarkCommand)
+    .command(testCommand)
+    .command(createCommand)
     .command(doctorCommand)
     .command(listCommand)
     .command(statusCommand)

package/dist/bin.js.map

@@ -1 +1 @@
-{"version":3,"file":"bin.js","sourceRoot":"","sources":["../src/bin.ts"],"names":[],"mappings":";AACA,OAAO,KAAK,MAAM,OAAO,CAAC;AAC1B,OAAO,EAAE,OAAO,EAAE,MAAM,eAAe,CAAC;AACxC,OAAO,EAAE,WAAW,EAAE,MAAM,oBAAoB,CAAC;AACjD,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AACrD,OAAO,EAAE,cAAc,EAAE,MAAM,uBAAuB,CAAC;AACvD,OAAO,EAAE,gBAAgB,EAAE,MAAM,yBAAyB,CAAC;AAC3D,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AACrD,OAAO,EAAE,WAAW,EAAE,MAAM,oBAAoB,CAAC;AACjD,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AACrD,OAAO,EAAE,YAAY,EAAE,MAAM,qBAAqB,CAAC;AACnD,OAAO,EAAE,cAAc,EAAE,MAAM,uBAAuB,CAAC;AACvD,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AAErD,KAAK,CAAC,OAAO,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC;KACzB,UAAU,CAAC,QAAQ,CAAC;KACpB,OAAO,CAAC,cAAc,CAAC;KACvB,OAAO,CAAC,WAAW,CAAC;KACpB,OAAO,CAAC,aAAa,CAAC;KACtB,OAAO,CAAC,cAAc,CAAC;KACvB,OAAO,CAAC,gBAAgB,CAAC;KACzB,OAAO,CAAC,aAAa,CAAC;KACtB,OAAO,CAAC,WAAW,CAAC;KACpB,OAAO,CAAC,aAAa,CAAC;KACtB,OAAO,CAAC,aAAa,CAAC;KACtB,OAAO,CAAC,YAAY,CAAC;KACrB,MAAM,EAAE;KACR,IAAI,EAAE;KACN,OAAO,EAAE;KACT,KAAK,EAAE,CAAC"}
+{"version":3,"file":"bin.js","sourceRoot":"","sources":["../src/bin.ts"],"names":[],"mappings":";AACA,OAAO,KAAK,MAAM,OAAO,CAAC;AAC1B,OAAO,EAAE,OAAO,EAAE,MAAM,eAAe,CAAC;AACxC,OAAO,EAAE,WAAW,EAAE,MAAM,oBAAoB,CAAC;AACjD,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AACrD,OAAO,EAAE,cAAc,EAAE,MAAM,uBAAuB,CAAC;AACvD,OAAO,EAAE,WAAW,EAAE,MAAM,oBAAoB,CAAC;AACjD,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AACrD,OAAO,EAAE,WAAW,EAAE,MAAM,oBAAoB,CAAC;AACjD,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AACrD,OAAO,EAAE,YAAY,EAAE,MAAM,qBAAqB,CAAC;AACnD,OAAO,EAAE,cAAc,EAAE,MAAM,uBAAuB,CAAC;AACvD,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AAErD,KAAK,CAAC,OAAO,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC;KACzB,UAAU,CAAC,QAAQ,CAAC;KACpB,OAAO,CAAC,cAAc,CAAC;KACvB,OAAO,CAAC,WAAW,CAAC;KACpB,OAAO,CAAC,cAAc,CAAC;KACvB,OAAO,CAAC,WAAW,CAAC;KACpB,OAAO,CAAC,aAAa,CAAC;KACtB,OAAO,CAAC,aAAa,CAAC;KACtB,OAAO,CAAC,WAAW,CAAC;KACpB,OAAO,CAAC,aAAa,CAAC;KACtB,OAAO,CAAC,aAAa,CAAC;KACtB,OAAO,CAAC,YAAY,CAAC;KACrB,MAAM,EAAE;KACR,IAAI,EAAE;KACN,OAAO,EAAE;KACT,KAAK,EAAE,CAAC"}

package/dist/commands/compile.d.ts

@@ -1,3 +1,4 @@
 import type { CommandModule } from "yargs";
 export declare const compileCommand: CommandModule;
+export declare function runCompileCommand(argv?: Record<string, unknown>): Promise<void>;
 //# sourceMappingURL=compile.d.ts.map

package/dist/commands/compile.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"compile.d.ts","sourceRoot":"","sources":["../../src/commands/compile.ts"],"names":[],"mappings":"AAoBA,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,OAAO,CAAC;AAO3C,eAAO,MAAM,cAAc,EAAE,aAiG5B,CAAC"}
+{"version":3,"file":"compile.d.ts","sourceRoot":"","sources":["../../src/commands/compile.ts"],"names":[],"mappings":"AAWA,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,OAAO,CAAC;AAY3C,eAAO,MAAM,cAAc,EAAE,aAO5B,CAAC;AAEF,wBAAsB,iBAAiB,CAAC,IAAI,GAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAwBzF"}