@interf/compiler 0.21.0 → 0.22.2

package/public-repo/README.md

@@ -1,19 +1,21 @@
 # Interf
 
-**Context compiler for agents.**
+**Data preparation for agents.**
 
-Interf prepares data for agent work by compiling source files into verifiable Artifacts and writing portable context that agents can read, so agents work from a verified full picture instead of guessing.
+Agents miss things in files.
 
-**Hallucinations aren't an agent problem. They're a data preparation problem.**
+Interf builds verifiable context for agents from your files.
 
-When agents start from source files, they have to discover the full picture while they work. That discovery is hidden: you cannot see which files were processed, which evidence was used, or which connections were found.
+It turns hidden file discovery into traceable artifacts with proof of how they were built.
 
-Interf replaces that hidden discovery with visible compilation. Your agent can ask for the Artifacts it needs — an atlas, index, timeline, summaries, or a custom file — and Interf drafts a Build Plan for you to review before compile. The draft says what should be built; the compile run proves what was actually processed. Under the hood, Interf saves that request as a Preparation, runs a Build Plan locally, records source references, and writes verifiable Artifacts agents can read. Today a Build Plan is implemented by a Method package.
+When agents answer from your files, they first have to discover what is in them. That context-building step is hidden, inconsistent, and hard to verify: you cannot see which files were checked, what was extracted, or what the agent skipped. When the agent misses a file or page, the output can sound confident but be wrong.
+
+Source discovery should be separate from agent work. Interf separates that step, builds verifiable context, and lets your agent work from traceable artifacts instead of rediscovering the files during the job.
 
 ```text
-Source files                        Portable context agents read
+Source files                        Verifiable context agents use
 
-bristol-office-market/              <portable-context-locator>/
+bristol-office-market/              <context-locator>/
   q4-market-report.pdf                AGENTS.md
   lease-comps.xlsx                    .interf/runtime/source-snapshot.json
   planning-notes.md                   home.md
@@ -21,25 +23,25 @@ bristol-office-market/              <portable-context-locator>/
                                       knowledge/
 ```
 
-## What a Compile Run Produces
+## What a Build Run Produces
 
-A compile run produces portable context plus proof of work. The portable context is the folder agents read. The proof shows which source files were assigned, which Build Plan stages ran, what each stage wrote, and whether required artifacts exist.
+A Build run produces verifiable context plus proof of work. Verifiable context is what agents use. The proof shows which source files were assigned, which Build Plan stages ran, what each stage wrote, and whether required artifacts exist.
 
-For the built-in `interf-default` Build Plan, a compile run looks like this:
+For the built-in `interf-default` Build Plan, a Build run looks like this:
 
 ```text
 Source: bristol-office-market
 Build Plan: interf-default
 Requested Artifacts: atlas, summaries, knowledge, claims, indexes
 
-compile run
+Build run
   record source references
   summarize -> summaries/
   structure -> knowledge/
   shape -> home.md and agent entrypoints
   record proof -> processed files, stage outputs, required artifacts
 
-portable context
+verifiable context
   locator -> { kind: "local-path", value: "<local-path-returned-by-interf>" }
 ```
 
@@ -51,14 +53,14 @@ The output is not an answer. It is a prepared local folder with routes, artifact
 - `Deterministic`: Interf runs each stage, an ordered phase of a Build Plan, and shows stage-by-stage proof of work: which files were processed, what each stage produced, and whether required outputs exist. Agents do not have to rebuild the full picture while they work.
 - `Local-first and private`: your files, readiness checks, and agent runs stay on your machine. No cloud, no uploads, no telemetry.
 - `Bring your own AI`: use Claude Code, Codex, or another local agent.
-- `File over app`: the portable context is a local folder owned by the instance — no hidden store, no hidden index. Inspect it, diff it, version it.
-- `Readiness checks you control`: every build can be checked against gates you wrote from the files. If the portable context is `not ready`, `interf test` shows the readiness evidence behind that status.
+- `File over app`: verifiable context is exposed as a local folder owned by the instance — no hidden store, no hidden index. Inspect it, diff it, version it.
+- `Readiness checks you control`: every build can be checked against gates you wrote from the files. If the context is `not ready`, `interf test` shows the readiness evidence behind that status.
 
 ## Why Not Just Ask Your Agent?
 
-You can. Interf can use Claude Code, Codex, or another local agent while it builds the portable context.
+You can. Interf can use Claude Code, Codex, or another local agent while it builds verifiable context.
 
-A one-off preprocessing prompt gives you another agent answer to trust. Interf puts that work inside a Build Plan you can inspect: requested artifacts, declared stages, stage-by-stage proof of work, and readiness checks that decide whether the portable context is `ready` or `not ready`.
+A one-off preprocessing prompt gives you another agent answer to trust. Interf puts that work inside a Build Plan you can inspect: requested artifacts, declared stages, stage-by-stage proof of work, and readiness checks that decide whether the context is `ready` or `not ready`.
 
 The agent can still execute the stages. Interf shows what ran, which files were processed, what artifacts and evidence were produced, and whether the result is ready for the agent work.
 
@@ -79,9 +81,9 @@ interf prep create bristol \                    # terminal 2: save the source +
   --source ./bristol-office-market \
   --about "Bristol annual take-up and availability chart lookup" \
   --requested-artifacts-json '[{"title":"Guide to the report","checks":["Every page or file is listed.","Pages about Bristol and annual take-up are marked."]},{"title":"Annual take-up figures","checks":["Every figure has a source reference."]}]'
-interf method draft bristol \                   # draft the Build Plan for review
+interf build-plan draft bristol \                 # draft the Build Plan for review
   --task "Bristol annual take-up and availability chart lookup"
-interf compile bristol                          # build portable context, returns the locator
+interf build bristol                            # build verifiable context, returns the locator
 interf test bristol                             # check readiness
 ```
 
@@ -93,21 +95,21 @@ auto-start an engine — if no instance is connected, they exit with a hint
 pointing at `interf web` / `interf web start` (local) or `interf login`
 (future cloud).
 
-`interf compile` returns the artifact locator on success — for a local
+`interf build` returns the artifact locator on success — for a local
 engine that's a `local-path` you can open with any tool. Point your agent at
 that path. There's no `--out` flag, no implicit copy, no hidden store: the
 instance owns the bytes and the API tells you where they are.
 
-If you want a baseline before compile, run `interf test bristol --target source-files`. It is optional proof, not the main path.
+If you want a baseline before building verifiable context, run `interf test bristol --target source-files`. It is optional proof, not the main path.
 
-## Portable Context
+## Verifiable Context
 
-The portable context is the local folder Interf writes from your files. Do not hardcode its location. The API returns a typed locator (`{ kind: "local-path" | "remote-url", value }`); your agent reads from there.
+Verifiable context is the output Interf builds from your files for agents. The current local engine exposes it as a local folder. Do not hardcode its location. The API returns a typed locator (`{ kind: "local-path" | "remote-url", value }`); your agent reads from there.
 
 It gives agents evidence, structure, and cross-file connections for navigating the files. It is not a replacement for your files. For the built-in `interf-default`, it includes:
 
 ```text
-<portable-context-locator>/
+<context-locator>/
   AGENTS.md       # agent-facing entry point and source-checking rules
   CLAUDE.md       # same guidance for Claude Code
   .interf/
@@ -119,52 +121,52 @@ It gives agents evidence, structure, and cross-file connections for navigating t
   knowledge/      # linked notes built from the files
 ```
 
-The source files stay the source of truth. Interf writes portable context inside the instance's data dir; it does not modify the source.
+The source files stay the source of truth. Interf writes verifiable context inside the instance's data dir; it does not modify the source.
 
-`AGENTS.md` tells agents how to use the portable context: start from the prepared outputs, follow the prepared routes, and use the recorded source references when exact source evidence matters.
+`AGENTS.md` tells agents how to use the verifiable context: start from the prepared outputs, follow the prepared routes, and use the recorded source references when exact source evidence matters.
 
 Interf also records stage-by-stage proof of work: which files were processed, what each stage produced, and whether required outputs were created.
 
-The portable context carries source references, not a mandatory copy of every source file. The source files remain where you keep them; Interf records which sources were assigned and what artifacts were produced from them.
+The returned local folder carries source references, not a mandatory copy of every source file. The source files remain where you keep them; Interf records which sources were assigned and what artifacts were produced from them.
 
-## Build Plans and Method Packages
+## Build Plans
 
-A Build Plan tells Interf how to compile requested Artifacts from your source files for the job agents need to do. It can start as a draft inside one Preparation, based on the user's instructions, the agent goal, and the described Source. If it works, save it as a Method package and reuse it on another Source.
+A Build Plan tells Interf how to build requested Artifacts from your source files for the job agents need to do. It can start as a draft inside one Preparation, based on the user's instructions, the agent goal, and the described Source. If it works, save it and reuse it on another Source.
 
-Today saved Build Plans are implemented as Method packages. The built-in `interf-default` Method package ships with `@interf/compiler`. Install your own with `interf method install <path>`; draft new ones with `interf method draft <prep-id>`.
+The built-in `interf-default` Build Plan ships with `interf`. Save your own local Build Plan with `interf build-plan save <path>`; draft new ones with `interf build-plan draft <prep-id>`.
 
 ```text
-<method-package>/
-  method.json         # Build Plan: artifacts, stages, compile rules
-  method.schema.json  # output contract: required portable-context files and folders
+<build-plan-folder>/
+  build-plan.json         # Build Plan definition: artifacts, stages, build rules
+  build-plan.schema.json  # output contract: required verifiable-context files and folders
   README.md             # what this Build Plan is for
-  compile/
+  build/
     stages/
-      summarize/        # stage instructions Interf runs during compile
+      summarize/        # stage instructions Interf runs during the Build run
       structure/
       shape/
   use/
-    query/              # how agents read the portable context
+    query/              # how agents read the verifiable context
   improve/              # how Interf revises this plan if readiness checks still fail
 ```
 
-- `method.json` describes the Build Plan: source data, requested artifacts, stages, and how the files should be compiled.
-- `method.schema.json` describes the output contract: what the portable context must contain. Interf enforces it when you run `interf compile`.
-- `compile/stages/<stage>/` is where you author one folder per stage — a small, specific phase like `summarize` or `structure`. You write the instructions; Interf runs them during compile.
-- `use/query/` holds the instructions agents follow when they read the portable context for live agent work.
+- `build-plan.json` is the current technical filename for the Build Plan definition: source data, requested artifacts, stages, and how the files should be built.
+- `build-plan.schema.json` describes the output contract: what the verifiable context must contain. Interf enforces it when you run `interf build`.
+- `build/stages/<stage>/` is where you author one folder per stage — a small, specific phase like `summarize` or `structure`. You write the instructions; Interf runs them during the Build run.
+- `use/query/` holds the instructions agents follow when they read the verifiable context for live agent work.
 - `improve/` holds the instructions Interf follows when the first build misses and the Build Plan itself needs editing.
 
-A Build Plan defines the stages, output contract, proof requirements, and improvement instructions Interf runs on your files. Technically, a saved/reusable Build Plan is stored as a Method package with `method.json` and `method.schema.json`. The result is portable context your agents can read.
+A Build Plan defines the stages, output contract, proof requirements, and improvement instructions Interf runs on your files. The result is verifiable context your agents can read.
 
 ## Build Plan Improvement
 
-When the first compile run still misses readiness checks, Interf edits the Build Plan and compiles again. Same files, same checks, improved plan and portable context. Run `interf method improve <prep-id>` to invoke that loop manually.
+When the first Build run still misses readiness checks, Interf edits the Build Plan and builds again. Same files, same checks, improved plan and verifiable context. Run `interf build-plan improve <prep-id>` to invoke that loop manually.
 
-Interf saves every readiness-check run inside the preparation's portable context under `.interf/tests/`. You can inspect what changed and why a later compile run did better.
+Interf saves every readiness-check run inside the returned local folder under `.interf/tests/`. You can inspect what changed and why a later Build run did better.
 
-## How Interf Compiles
+## How Interf Builds
 
-You don't need to think about roles. By default Interf uses your active agent for every stage of every compile run, the same way 0.14 did. Roles are available for advanced users who want different agents per stage; defaults are good and stable.
+You don't need to think about roles. By default Interf uses your active agent for every stage of every Build run. Roles are available for advanced users who want different agents per stage; defaults are good and stable.
 
 Interf treats connected agents as a first-class primitive and uses a small role taxonomy internally to route stages between them. The default behavior is single-active-agent — one installed agent runs everything — but you can opt into per-role specialization without changing any Build Plan.
 
@@ -176,7 +178,7 @@ Connected agents             Role map (per-instance)
                                verifier    → claude-code
                                general     → claude-code
 
-A Build Plan compile run
+A Build run
   for each stage in the Build Plan
     look up the stage's role in the role map
     invoke the mapped agent on the prepared shell
@@ -195,19 +197,19 @@ interf agents use claude-code   # set the active agent
 interf agents unmap structurer  # fall back to active
 ```
 
-Or use the **Agents** tab in Interf Compiler UI. Either surface mutates the same instance agent settings through the local service.
+Or use the **Agents** tab in Interf UI. Either surface mutates the same instance agent settings through the local service.
 
 Readiness-check runs always resolve to the `verifier` role. Build Plan authoring runs ask the authoring agent to propose a `role` per stage based on the prompt content; missing roles default to `general`.
 
 ## How the Pieces Fit
 
-The instance owns preparation state. A preparation declares a source binding (`{ kind: "local-folder", locator: <path> }`), requested artifacts, and a selected Build Plan. The current local engine still stores the selected Build Plan as `method_id` while the schema catches up. It stores preparation state and generated bytes in the instance data directory. A compile run processes the selected source files and produces the artifact locator the API returns. `interf test` checks source files and portable context against the same readiness checks.
+The instance owns preparation state. A preparation declares a source binding (`{ kind: "local-folder", locator: <path> }`), requested artifacts, and a selected Build Plan. It stores preparation state and generated bytes in the instance data directory. A Build run processes the selected source files and produces the artifact locator the API returns. `interf test` checks source files and verifiable context against the same readiness checks.
 
 Readiness is one `ready` / `not ready` status, not a separate score. Interf builds it from evidence primitives: Build Plan Artifact checks, proof records, file coverage, artifact validation, and readiness checks.
 
-`interf web` runs the local Interf instance and serves Interf Compiler UI. The UI reads local-service resources: Source, Preparations, Build Plans, Method packages, compile runs, stages, proof, artifacts, readiness checks, and whether portable context is `ready` or `not ready`. It renders local instance state; it does not own compiler, Build Plan, Method-package, or readiness semantics.
+`interf web` runs the local Interf instance and serves Interf UI. The UI reads local-service resources: Source, Preparations, Build Plans, Build runs, stages, proof, artifacts, readiness checks, and whether verifiable context is `ready` or `not ready`. It renders local instance state; it does not own Build Plan, proof, or readiness semantics.
 
-Everywhere Interf shows a resource — Source, portable context, Build Plan files, run artifacts — the API returns a single locator shape: `{ kind, value }`. `local-path` means the engine has filesystem access to the same host as the user; `remote-url` is a signed URL the UI opens in a browser tab; `api-served` is a relative API route the UI fetches and renders inline. Local engines today return `local-path`; the same shape carries forward unchanged when a remote instance fronts the API.
+Everywhere Interf shows a resource — Source, context output, Build Plan files, run artifacts — the API returns a single locator shape: `{ kind, value }`. `local-path` means the engine has filesystem access to the same host as the user; `remote-url` is a signed URL the UI opens in a browser tab; `api-served` is a relative API route the UI fetches and renders inline. Local engines today return `local-path`; the same shape carries forward unchanged when a remote instance fronts the API.
 
 ## CLI Connection
 
@@ -235,28 +237,28 @@ There is no implicit auto-start. There is no per-folder pointer file. One mental
 
 There are two checks in the system, and they answer different questions.
 
-Build Plan Artifact checks check the build: did the plan produce the files, folders, Artifacts, and stage outputs it promised? Interf checks those while it compiles.
+Build Plan Artifact checks check the build: did the plan produce the files, folders, Artifacts, and stage outputs it promised? Interf checks those while it builds.
 
-Readiness checks check the portable context: is this Preparation good enough for the specific agent work? They are the confidence layer on top of the portable context, not the product output.
+Readiness checks check the verifiable context: is this Preparation good enough for the specific agent work? They are the confidence layer on top of the context, not the product output.
 
-In the setup flow, readiness checks often look like plain question-and-answer pairs. On the API, they live under each preparation's `checks[]`. They help define whether the portable context is `ready` or `not ready`. A check should be a small, verifiable fact or condition you already know from the files:
+In the setup flow, readiness checks often look like plain question-and-answer pairs. On the API, they live under each preparation's `checks[]`. They help define whether the context is `ready` or `not ready`. A check should be a small, verifiable fact or condition you already know from the files:
 
 - one exact number from a chart, table, or filing
 - one short statement that should be true or false
 - one comparison across years, files, or sections
 
-Interf proposes an initial set from the files and the description of the job agents need to do. You confirm, edit, or replace them. `interf test` runs those checks through the configured local agent against source files, portable context, or both. The portable context itself does not answer; the agent answers while using it.
+Interf proposes an initial set from the files and the description of the job agents need to do. You confirm, edit, or replace them. `interf test` runs those checks through the configured local agent against source files, verifiable context, or both. The context itself does not answer; the agent answers while using it.
 
 A maintained readiness example in this repo uses one market report, two readiness checks, and two agents:
 
 <!-- PUBLIC_BENCHMARK_TABLE:START -->
-| Agent | Source files | Portable context |
+| Agent | Source files | Verifiable context |
 | --- | --- | --- |
 | Codex (GPT-5.4, xhigh) | `2/2` | `2/2` |
 | Claude Code (Claude Opus 4.6, max) | `0/2` | `2/2` |
 <!-- PUBLIC_BENCHMARK_TABLE:END -->
 
-Codex passed from the source files; Claude Code only passed when working from Interf's portable context. Both numbers come from the same readiness-check pass. That is evidence about whether this portable context is `ready` for this agent work.
+Codex passed from the source files; Claude Code only passed when working from Interf's verifiable context. Both numbers come from the same readiness-check pass. That is evidence about whether this context is `ready` for this agent work.
 
 A maintained public test example uses this preparation:
 
@@ -265,7 +267,7 @@ A maintained public test example uses this preparation:
 {
   "id": "cbre-chart-sanity",
   "source": { "kind": "local-folder", "locator": "./task-files" },
-  "method_id": "interf-default",
+  "build_plan_id": "interf-default",
   "about": "Bristol historical take-up and availability chart lookup.",
   "requested_artifacts": [
     {
@@ -294,19 +296,19 @@ A maintained public test example uses this preparation:
 ## What Interf Is Not
 
 - Not a second brain or memory product. One preparation per agent job; nothing global.
-- Not a vector store or RAG server. The portable context is plain files.
+- Not a vector store or RAG server. The context output is plain files.
 - Not a hosted data platform. The local instance runs on your machine; your bytes never leave it.
-- Not an agent harness. Interf compiles the context; your existing agent reads the portable context.
+- Not an agent harness. Interf builds verifiable context; your existing agent reads it.
 
 ## Useful Commands
 
-- `interf web` — run the local engine in the foreground (Compiler UI + API)
+- `interf web` — run the local engine in the foreground (Interf UI + API)
 - `interf web start` — start a managed background local engine for agent sessions
 - `interf web stop` — kill the running local engine
 - `interf prep ls / create / show / rm` — manage preparations
-- `interf compile <prep-id>` — build portable context, returns the artifact locator
-- `interf test <prep-id>` — run readiness checks against source files and/or portable context
-- `interf method ls / show / install / draft / improve` — manage Build Plans / Method packages
+- `interf build <prep-id>` — build verifiable context, returns the artifact locator
+- `interf test <prep-id>` — run readiness checks against source files and/or verifiable context
+- `interf build-plan list / show / save / draft / select / improve` — manage Build Plans
 - `interf agents ls / use / register / unregister / map / unmap` — manage connected agents and the role map
 - `interf runs ls / status / cancel / fetch` — inspect runs
 - `interf login / logout` — manage the active connection record (remote backend ships in a future release)
@@ -317,7 +319,7 @@ A maintained public test example uses this preparation:
 
 - [skills/interf](./skills/interf/) — bundled agent Skill for Interf.
 - [plugins/interf](./plugins/interf/) — local MCP host bundle for agents that support local MCP servers.
-- [methods/interf-default](./methods/interf-default/) — default Method package that ships with `@interf/compiler`.
+- [build-plans/interf-default](./build-plans/interf-default/) — default Build Plan that ships with `interf`.
 
 Contributors: see [CONTRIBUTING.md](./CONTRIBUTING.md).
 

package/public-repo/SECURITY.md

@@ -4,7 +4,7 @@ We take security issues seriously. Thank you for helping keep Interf safe for th
 
 ## Supported Versions
 
-Only the latest published release of `@interf/compiler` on npm and the current `main` branch of [`interf-labs/compiler`](https://github.com/interf-labs/compiler) receive security fixes.
+Only the latest published release of `@interf/compiler` on npm and the current `main` branch of [`interf-labs/interf`](https://github.com/interf-labs/interf) receive security fixes.
 
 ## Reporting a Vulnerability
 
@@ -13,7 +13,7 @@ Only the latest published release of `@interf/compiler` on npm and the current `
 Preferred disclosure paths, in order:
 
 1. **Email**: [security@interf.com](mailto:security@interf.com) — primary contact for any security report
-2. **GitHub Security Advisories**: use [private vulnerability reporting](https://github.com/interf-labs/compiler/security/advisories/new) on the `interf-labs/compiler` repository
+2. **GitHub Security Advisories**: use [private vulnerability reporting](https://github.com/interf-labs/interf/security/advisories/new) on the `interf-labs/interf` repository
 3. **PGP**: encrypted reports accepted on request via the email above
 
 Please include:
@@ -47,7 +47,7 @@ Security reports are especially relevant for:
 - command execution boundaries (subprocess, agent shell-out)
 - accidental leakage of private local files or runtime artifacts
 - authentication or authorization bypasses on `interf web` / `/v1/*` endpoints
-- test or workflow files causing unintended code execution
+- test or Build Plan files causing unintended code execution
 - supply-chain risks in dependencies
 
 ## Bug Bounty Program

package/public-repo/build-plans/interf-default/README.md

@@ -0,0 +1,33 @@
+# Built-in Interf Build Plan
+
+Built-in file-processing Build Plan: build traceable artifacts with proof by summarizing source-grounded evidence, structuring cross-file connections, and shaping verifiable context around the saved readiness checks.
+
+## Purpose
+
+- General Build Plan implementation for building verifiable context agents can use.
+- Build mixed source files into evidence-backed summaries, cross-file structure, and a usable entrypoint for agents running the readiness checks this agent work depends on.
+
+## Artifacts
+
+- `summaries` — output directory at `summaries`
+- `knowledge-entities` — output directory at `knowledge/entities`
+- `knowledge-claims` — output directory at `knowledge/claims`
+- `knowledge-indexes` — output directory at `knowledge/indexes`
+- `atlas` — output file at `home.md` used as the primary entrypoint for this Build Plan
+
+## Stages
+
+Each stage is a folder with a `SKILL.md` file. Interf creates the stage shell,
+attaches source references and runtime context, runs the agent against that
+plain-text Skill, and records proof of what the stage wrote.
+
+- `summarize` — Turn source files into per-file summaries. (build-file-evidence; reads: none; writes: summaries)
+- `structure` — Build the cross-file knowledge structure from the summaries. (build-knowledge-structure; reads: summaries; writes: knowledge-entities, knowledge-claims, knowledge-indexes)
+- `shape` — Shape the final verifiable context around the saved task focus and readiness checks. (build-query-shape; reads: summaries, knowledge-entities, knowledge-claims, knowledge-indexes; writes: knowledge-indexes, atlas)
+
+## Why `home.md` exists here
+
+This built-in Build Plan creates `home.md` as the main agent entrypoint for the verifiable context.
+That is behavior of the `interf-default` Build Plan implementation, not a local-engine rule.
+
+This package is the built-in seed for `interf-default`.

package/public-repo/{methods/interf-default/compile → build-plans/interf-default/build}/stages/shape/SKILL.md

@@ -1,27 +1,27 @@
 # Shape
 
-Shape the final portable context around the saved task focus and readiness checks.
+Shape the final verifiable context around the saved task focus and readiness checks.
 
-Contract type: `compiled-query-shape`
+Contract type: `build-query-shape`
 
 ## Requirements
 
-- Use the compiled task focus plus saved readiness-check text to shape `home.md` and retrieval routes.
-- Rewrite `home.md` into a real entrypoint note. Do not leave the scaffold `Not yet compiled.` placeholder in place.
-- When you add wikilinks, target real compiled notes by exact basename or explicit relative path.
+- Use the Build run task focus plus saved readiness-check text to shape `home.md` and retrieval routes.
+- Rewrite `home.md` into a real entrypoint note. Do not leave the scaffold `Not yet built.` placeholder in place.
+- When you add wikilinks, target real verifiable-context notes by exact basename or explicit relative path.
 - If you introduce a new note name in `home.md` or another shaped output, the same stage must also create that note file.
 - Prefer direct file-reading and search tools over shell commands for routine file inspection.
 - When a source value is approximate, preserve it as a bounded range and say why it is approximate.
 - Do not invent finer precision than the source supports.
 - Keep approximate values consistent across `home.md`, focused indexes, and claim/entity notes.
-- Do not copy expected answers into the portable context.
+- Do not copy expected answers into the verifiable context.
 
 ## Notes
 
-- Use the saved task focus and readiness checks to bias the final portable context toward the job it should be especially good at.
-- Do not copy expected answers into the final portable context just because the checks imply them.
+- Use the saved task focus and readiness checks to bias the final verifiable context toward the job it should be especially good at.
+- Do not copy expected answers into the final verifiable context just because the checks imply them.
 - Prefer the saved summary evidence and structured notes when they already preserve the bounded chart/table reads plus provenance you need.
-- Reopen source references during shaping only when the compiled layer is missing the needed value, the metric family is ambiguous, or the earlier bounded read is clearly inconsistent.
+- Reopen source references during shaping only when the verifiable context is missing the needed value, the metric family is ambiguous, or the earlier bounded read is clearly inconsistent.
 - If a saved readiness check depends on source-derived values, carry the final bounded values into focused notes with provenance instead of repeatedly recomputing them from source files.
 - Prefer better routing, prioritization, and focused navigation over speculative synthesis.
-- Any wikilinks you add to `home.md` or indexes must resolve to real compiled note basenames or explicit relative paths.
+- Any wikilinks you add to `home.md` or indexes must resolve to real verifiable-context note basenames or explicit relative paths.

package/public-repo/{methods/interf-default/compile → build-plans/interf-default/build}/stages/structure/SKILL.md

@@ -2,7 +2,7 @@
 
 Build the cross-file knowledge structure from the summaries.
 
-Contract type: `compiled-knowledge-structure`
+Contract type: `build-knowledge-structure`
 
 ## Requirements
 
@@ -16,6 +16,6 @@ Contract type: `compiled-knowledge-structure`
 - Bias structure toward canonical entities, claims, timelines, and stable indexes.
 - Use taxonomy and ontology only as means to improve retrieval, navigation, and evidence tracking.
 - For small source folders, prefer a minimal stable substrate over exhaustive graph sprawl.
-- When you add wikilinks, target real compiled notes by exact basename or explicit relative path. Do not invent title-style links unless that exact title is also a declared note label or alias.
+- When you add wikilinks, target real verifiable-context notes by exact basename or explicit relative path. Do not invent title-style links unless that exact title is also a declared note label or alias.
 - Do not add wikilinks in structure outputs to files that the shape stage creates later. If a route belongs in `home.md` or a later shaped note, leave plain text now and let the later stage add the link.
 - For summary references, prefer explicit links like `[[summaries/<file-stem>]]` or plain code paths. For knowledge notes, prefer the final filename stem under `knowledge/`.

package/public-repo/{methods/interf-default/compile → build-plans/interf-default/build}/stages/summarize/SKILL.md

@@ -2,7 +2,7 @@
 
 Turn source files into per-file summaries.
 
-Contract type: `compiled-file-evidence`
+Contract type: `build-file-evidence`
 
 ## Requirements
 

package/public-repo/{methods/interf-default/method.json → build-plans/interf-default/build-plan.json}

@@ -1,13 +1,13 @@
 {
   "id": "interf-default",
-  "type": "compiled",
-  "compiler_api": {
-    "kind": "compiled",
+  "type": "build-plan",
+  "engine_api": {
+    "kind": "build",
     "version": 1
   },
   "purpose": {
-    "label": "Built-in portable-context Method for agent use",
-    "task_hint": "Compile mixed source files into evidence-backed summaries, cross-file structure, and a usable entrypoint for agents running the readiness checks this task depends on."
+    "label": "Built-in Build Plan for verifiable context",
+    "task_hint": "Build mixed source files into evidence-backed summaries, cross-file structure, and a usable entrypoint for agents running the readiness checks this agent work depends on."
   },
   "inputs": [
     {
@@ -17,14 +17,14 @@
       "required": true
     }
   ],
-  "label": "Built-in Interf Method",
-  "hint": "Built-in file-processing Method: summarize source-grounded evidence, structure cross-file connections, and shape portable context around the saved readiness checks.",
+  "label": "Built-in Interf Build Plan",
+  "hint": "Built-in file-processing Build Plan: build traceable artifacts with proof by summarizing source-grounded evidence, structuring cross-file connections, and shaping verifiable context around the saved readiness checks.",
   "stages": [
     {
       "id": "summarize",
       "label": "Summarize",
       "description": "Turn source files into per-file summaries.",
-      "contract_type": "compiled-file-evidence",
+      "contract_type": "build-file-evidence",
       "skill_dir": "summarize",
       "reads": [],
       "writes": [
@@ -35,7 +35,7 @@
       "id": "structure",
       "label": "Structure",
       "description": "Build the cross-file knowledge structure from the summaries.",
-      "contract_type": "compiled-knowledge-structure",
+      "contract_type": "build-knowledge-structure",
       "skill_dir": "structure",
       "reads": [
         "summaries"
@@ -49,8 +49,8 @@
     {
       "id": "shape",
       "label": "Shape",
-      "description": "Shape the final portable context around the saved task focus and readiness checks.",
-      "contract_type": "compiled-query-shape",
+      "description": "Shape the final verifiable context around the saved task focus and readiness checks.",
+      "contract_type": "build-query-shape",
       "skill_dir": "shape",
       "reads": [
         "summaries",
@@ -75,16 +75,16 @@
       "Bias structure toward canonical entities, claims, timelines, and stable indexes.",
       "Use taxonomy and ontology only as means to improve retrieval, navigation, and evidence tracking.",
       "For small Source Folders, prefer a minimal stable substrate over exhaustive graph sprawl.",
-      "When you add wikilinks, target real compiled notes by exact basename or explicit relative path. Do not invent title-style links unless that exact title is also a declared note label or alias.",
+      "When you add wikilinks, target real verifiable-context notes by exact basename or explicit relative path. Do not invent title-style links unless that exact title is also a declared note label or alias.",
       "Do not add wikilinks in structure outputs to files that the shape stage creates later. If a route belongs in `home.md` or a later shaped note, leave plain text now and let the later stage add the link.",
       "For summary references, prefer explicit links like `[[summaries/<file-stem>]]` or plain code paths. For knowledge notes, prefer the final filename stem under `knowledge/`."
     ],
     "shape": [
-      "Use the saved task focus and readiness checks to bias the final portable context toward the job it should be especially good at.",
-      "Do not copy expected answers into the final portable context just because the checks imply them.",
+      "Use the saved task focus and readiness checks to bias the final verifiable context toward the job it should be especially good at.",
+      "Do not copy expected answers into the final verifiable context just because the checks imply them.",
       "If a saved readiness check depends on source-derived values that may be approximate, preserve the stated range, limits, and provenance.",
       "Prefer better routing, prioritization, and focused navigation over speculative synthesis.",
-      "Any wikilinks you add to `home.md` or indexes must resolve to real compiled note basenames or explicit relative paths."
+      "Any wikilinks you add to `home.md` or indexes must resolve to real verifiable-context note basenames or explicit relative paths."
     ]
   }
 }

package/public-repo/{methods/interf-default/method.schema.json → build-plans/interf-default/build-plan.schema.json}

@@ -1,8 +1,8 @@
 {
-  "kind": "method-schema",
+  "kind": "build-plan-schema",
   "version": 1,
-  "target_type": "compiled",
-  "label": "Interf built-in Method schema",
+  "target_type": "verifiable-context",
+  "label": "Interf built-in Build Plan schema",
   "artifacts": [
     {
       "id": "atlas",
@@ -14,7 +14,7 @@
           "id": "no-placeholder",
           "kind": "must_not_contain",
           "required": true,
-          "params": { "phrases": ["Not yet compiled."] }
+          "params": { "phrases": ["Not yet built."] }
         },
         { "id": "wikilinks", "kind": "wikilinks_valid", "required": true }
       ],

package/public-repo/build-plans/interf-default/improve/SKILL.md

@@ -0,0 +1,18 @@
+# Build Plan Improvement
+
+Build Plan: interf-default
+
+This file is the editable authoring source for Interf's generated native Build Plan improver shell.
+The improver edits this local Build Plan directly.
+
+Default loop:
+1. Read the loop context first.
+2. Review preserved stage shells, runtime logs, and saved test runs from failed attempts.
+3. Edit only the local Build Plan for this verifiable context to create a better implementation for this agent work.
+4. Keep `build-plan.json`, `build-plan.schema.json`, and any changed stage docs aligned.
+
+Guardrails:
+- do not edit checks, test specs, or source files
+- do not hardcode expected answers into Build Plan docs
+- keep this package standalone; do not rely on runtime inheritance
+- prefer small, defensible Build Plan changes over random churn

package/public-repo/{methods → build-plans}/interf-default/use/query/SKILL.md

@@ -11,13 +11,13 @@ Default loop:
 Answering rule:
 - do not modify source files while answering
 - when a number is approximate or source-derived from a visual, say that explicitly
-- if the compiled layer already contains a bounded value for the exact metric and period the user asked about, answer from that compiled value first
-- use source references to confirm the source page, metric family, or provenance, not to replace a good compiled bounded read with a mismatched range
-- when the compiled layer preserves a bounded range, keep that bounded range in the answer instead of collapsing it to a midpoint or pseudo-exact single value
+- if the verifiable context already contains a bounded value for the exact metric and period the user asked about, answer from that value first
+- use source references to confirm the source page, metric family, or provenance, not to replace a good bounded read with a mismatched range
+- when the verifiable context preserves a bounded range, keep that bounded range in the answer instead of collapsing it to a midpoint or pseudo-exact single value
 - match the source granularity and do not invent finer precision than the source supports
 - when reading visuals, verify you are on the correct metric family and period before answering
 - keep annual, quarterly, sector, and snapshot metrics separate unless the source explicitly connects them
-- if multiple compiled notes mention the same value, keep the answer consistent with the most focused compiled note rather than synthesizing a new midpoint or shifted range
-- when the compiled layer is insufficient, verify against source references and then answer
+- if multiple notes mention the same value, keep the answer consistent with the most focused note rather than synthesizing a new midpoint or shifted range
+- when the verifiable context is insufficient, verify against source references and then answer
 
-You can edit this file to bias manual question-answering behavior for this portable context.
+You can edit this file to bias manual question-answering behavior for this verifiable context.

package/public-repo/plugins/README.md

@@ -6,4 +6,4 @@ This directory is the source of truth for package-shipped plugin assets.
 
 Each plugin should stay thin: a host manifest, the canonical Interf Skill, and
 configuration that starts `interf mcp`. The MCP server itself ships inside
-`@interf/compiler`.
+`interf`.

package/public-repo/plugins/interf/.claude-plugin/plugin.json

@@ -2,19 +2,19 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "interf",
   "version": "0.1.0",
-  "description": "Prepare source files for agent work with Interf Compiler.",
+  "description": "Build verifiable context for agents from source files with Interf.",
   "author": {
     "name": "Interf Inc.",
     "url": "https://interf.com"
   },
   "homepage": "https://interf.com",
-  "repository": "https://github.com/interf-labs/compiler",
+  "repository": "https://github.com/interf-labs/interf",
   "license": "SEE LICENSE IN LICENSE.md",
   "keywords": [
     "interf",
     "agents",
     "data-preparation",
-    "portable-context"
+    "verifiable-context"
   ],
   "skills": "./skills/",
   "mcpServers": "./.mcp.json"