@interf/compiler 0.5.1 → 0.6.3

package/README.md

@@ -1,70 +1,94 @@
-# Interf Compiler
+# Interf
 
-Prepare local datasets for accurate agent use.
+Interf prepares task context for your agents.
 
-Interf Compiler runs a local data-processing workflow over your dataset to build a file-based layer on top of your raw files that gives agents the full picture they need to answer questions accurately.
+Start with the files behind a task and a few checks. Interf tests the files as-is first, shows what already works, and builds a local context folder when the current context is not good enough.
 
-Define truth checks for your dataset, measure a baseline on the raw files, then compile and retest the compiled dataset on the same checks.
+The result is a real folder your agent can open and work from. Interf retests it on the same checks, and self-improving loops can revise the workflow and try again until it passes or reaches the loop limit.
 
-If it still fails, self-improving loops can revise the workflow, rebuild the compiled dataset, and rerun the same checks until it passes or reaches the loop limit.
+Raw files stay the source of truth. The context folder adds task-specific structure on top of them.
 
-## Why Use It
-
-Interf Compiler is built around a few simple principles:
-
-- `Explicit`: the compiled dataset is a real folder you can inspect, review, and version.
-- `Yours`: the dataset, workflow, compiled dataset, and test runs stay on your machine and in your control.
-- `File over app`: the compiled dataset is normal files and folders, not hidden app state.
-- `Source-backed`: your raw files stay the source of truth; the compiled dataset is a layer on top, not a replacement database.
-- `Bring your own agent`: the same compiled dataset can be used with different local agents and tools.
-- `Self-improving`: when truth checks fail, Interf can retry the workflow or revise it, rebuild the compiled dataset, and rerun the same checks.
-
-## Example: Truth Checks
-
-Truth checks are just question-and-answer pairs you already know how to verify from the dataset.
-
-A maintained public test run in this repo uses checks like this:
-
-<!-- PUBLIC_TEST_CHECKS:START -->
-```jsonc
-{
-  "datasets": [
-    {
-      "name": "cbre-chart-sanity",
-      "about": "Bristol historical take-up and availability chart lookup.",
-      "checks": [
-        {
-          "question": "What were Bristol's annual take-up values in 2018 and 2016?",
-          "answer": "Around half a million sq ft in 2018, roughly 0.45 to 0.6 million sq ft, and about 0.7 to 0.8 million sq ft in 2016. These are approximate chart-derived reads."
-        },
-        {
-          "question": "What were Bristol's availability values in 2018 and 2016?",
-          "answer": "About 0.55 to 0.6 million sq ft in 2018 and about 1.2 to 1.3 million sq ft in 2016. These are approximate chart-derived reads."
-        }
-      ]
-    }
-  ]
-}
+```bash
+cd ~/my-project
+interf
+interf test
+interf compile
+interf test
 ```
-<!-- PUBLIC_TEST_CHECKS:END -->
 
-## Example: `interf test`
+The context folder Interf builds is rooted at:
 
-`interf test` compares files as-is and the compiled dataset on the same saved truth checks.
-That is the point of `interf test`: measure the same checks on both sides and keep the result honest on your own dataset, instead of relying on a frozen benchmark snapshot in the docs.
+```text
+interf/<dataset>/
+  AGENTS.md
+  CLAUDE.md
+  raw/
+  <workflow-declared compiled outputs>
+  .interf/
+    interf.json
+    workflow/
+    runtime/
+    tests/
+```
 
-A recent maintained internal run on the CBRE chart sanity dataset produced:
+A recent run in this repo on the CBRE chart sanity task produced:
 
 <!-- PUBLIC_BENCHMARK_TABLE:START -->
-| Agent | Files as-is | Compiled dataset |
+| Agent | Files as-is | Context folder |
 | --- | --- | --- |
 | Codex (GPT-5.4, xhigh) | `2/2` | `2/2` |
 | Claude Code (Claude Opus 4.6, max) | `0/2` | `2/2` |
 <!-- PUBLIC_BENCHMARK_TABLE:END -->
 
-Use `interf test` on your own dataset to measure files as-is versus the compiled dataset on the same checks.
+Those scores came from checks like:
+
+- `What were Bristol's annual take-up values in 2018 and 2016?`
+- `What were Bristol's availability values in 2018 and 2016?`
+
+Same task. Same checks. Same local setup.
+
+## How It Works
+
+1. Start with a task and the files relevant to it.
+2. Save a few checks that tell Interf what "ready" means for that task.
+3. Run a workflow that prepares a source-backed context folder for the task.
+4. Test the result on the same checks and keep it only if it helped.
+
+The raw baseline is still important. It shows what already works on the files as-is and which local agent performs best before you spend time improving anything.
+
+## Why It Exists
+
+Local agents can open raw files and still reason badly over them. Reports, decks, transcripts, exports, PDFs, notes, and mixed folders may all be present, but they are often missing the structure a real task needs.
+
+Interf takes the files behind a task, prepares them into a local context folder your agents can use, and then proves whether the result helped.
+
+Interf keeps the loop honest:
+
+- `Value first`: prepare the data for a specific task, not just dump files into another app.
+- `Proof-backed`: test raw files and the prepared result on the same checks.
+- `One folder`: the context folder is a real folder you can inspect, diff, review, and version.
+- `Source-backed`: raw files remain the source of truth.
+- `Bring your own agent`: use the context folder manually from other local agents too. Automated Interf runs currently support Claude Code and Codex.
+- `Self-improving`: when checks fail, Interf can inspect the failed run, edit the workflow, and retest new workflow variations on the same checks. Retries keep the same workflow variation; loops change the workflow itself.
+
+## What You Get
+
+A project with one saved setup stays simple:
+
+```text
+your-project/
+  task-files/
+    report.pdf
+    notes.md
+    exports/
+  interf.json
+  interf/
+    <dataset>/
+    tests/
+      <dataset>/
+```
 
-Each dataset keeps one latest comparison under `interf/tests/<dataset>/latest.json`. Target-specific runs stay under `interf/tests/<dataset>/file-as-is/runs/` and `interf/tests/<dataset>/compiled/runs/`.
+The context folder is the folder your agents should work from after Interf prepares the data for the task.
 
 ## Quick Start
 
@@ -79,161 +103,129 @@ Install:
 npm install -g @interf/compiler
 ```
 
-Start from a project folder that contains one or more dataset folders:
-
-```bash
-cd ~/my-interf-project
-interf
-interf test
-interf compile
-interf test
-```
+Start from a project folder that contains one or more source folders for the task.
 
 The first run can:
 
 - draft `interf.json`
-- auto-create a draft set of truth checks for a dataset folder, or let you add them manually
-- test your files as-is first on those same checks
-- build the compiled dataset
-- test the compiled dataset on the same truth checks
-
-## What Interf Compiler Creates
-
-After setup, the project root stays simple:
-
-- `interf.json` at the root holds your saved dataset entries and truth checks
-- `interf/` is created only when Interf has artifacts to save
-- `interf/<dataset>/` is the compiled dataset
-- `interf/tests/<dataset>/` is the saved comparison history for that dataset
+- let you choose the source folder for the task
+- default the dataset id from that folder name, then let you change it
+- help you create checks for the task, or let you add them manually
+- run a files-as-is baseline on those checks so you can see what already works
+- build the context folder that stores the compiled context
+- let you test the context folder on the same checks
 
-A compiled dataset is a folder on top of your dataset. It includes:
+If Interf cannot find your local executor setup, run:
 
-- a local `raw/` snapshot for direct evidence and verification
-- agent-readable summaries and cross-file notes
-- `AGENTS.md`, `CLAUDE.md`, and generated local query skills
-- workflow, test, and runtime state under `.interf/`
-
-The compiled dataset is the folder your agent should work from.
-
-## How It Works
+```bash
+interf doctor --live
+```
 
-1. Save a few truth checks for a dataset in `interf.json`.
-2. Optionally test the files as-is for a baseline.
-3. Build the compiled dataset for that dataset.
-4. Test the compiled dataset on the same truth checks.
-5. Optionally let Interf retry or improve the workflow until it passes or hits the configured limit.
+## Checks
 
-Truth checks are simple:
+Checks are the questions and expected answers Interf uses to prove whether the prepared result is good enough for this task.
 
-- one question
-- one expected answer
+They are just question-and-answer pairs you already know how to verify from the files behind the task.
 
-Good first truth checks 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
 - one simple comparison across years, files, or sections
 
-If `interf.json` is missing, `interf` or `interf init` can draft it with you before the first compile. If the compiler cannot find your local agent or compile setup, run:
+A maintained public test run in this repo uses checks like this:
 
-```bash
-interf doctor
+<!-- PUBLIC_TEST_CHECKS:START -->
+```jsonc
+{
+  "datasets": [
+    {
+      "name": "cbre-chart-sanity",
+      "path": "./task-files",
+      "about": "Bristol historical take-up and availability chart lookup.",
+      "checks": [
+        {
+          "question": "What were Bristol's annual take-up values in 2018 and 2016?",
+          "answer": "Around half a million sq ft in 2018, roughly 0.45 to 0.6 million sq ft, and about 0.7 to 0.8 million sq ft in 2016. These are approximate chart-derived reads."
+        },
+        {
+          "question": "What were Bristol's availability values in 2018 and 2016?",
+          "answer": "About 0.55 to 0.6 million sq ft in 2018 and about 1.2 to 1.3 million sq ft in 2016. These are approximate chart-derived reads."
+        }
+      ]
+    }
+  ]
+}
 ```
+<!-- PUBLIC_TEST_CHECKS:END -->
 
-## What `interf test` Does
+## What `interf test` Proves
 
-By default, if a compiled dataset exists, it runs both sides and saves one latest comparison under `interf/tests/<dataset>/latest.json`.
+`interf test` compares files as-is and the context folder on the same checks.
 
-You can also select one or more detected local agents in the CLI and compare them in one table.
+That comparison is the product record:
 
-For live runs:
+- same task
+- same checks
+- same local agent setup
+- raw files on one side
+- compiled context on the other
 
-- files-as-is tests execute from a sanitized raw-only shell built from the selected dataset folder
-- compiled-dataset tests execute from a copied compiled sandbox with embedded sanitized `raw/`
-- both sides use the same saved truth checks from `interf.json`
-- neither sandbox includes the project control plane
-- detailed dataset-visible runs are kept under `interf/tests/<dataset>/file-as-is/runs/` and `interf/tests/<dataset>/compiled/runs/`
-- local detailed target runs and preserved sandboxes stay under `.interf/tests/targets/`
-- failed test sandboxes are kept automatically
-- `interf test --keep-sandboxes` keeps every sandbox, even successful ones
+Use `interf test` on your own files instead of trusting a frozen benchmark snapshot in the docs.
 
-From inside a compiled dataset, `interf test` uses that dataset's `.interf/interf.json` directly. From the project root, `interf.json` bootstraps dataset selection and the same saved truth checks are mirrored into the compiled dataset runtime contract.
+Interf saves the latest comparison plus detailed raw-side and context-folder runs under `interf/tests/` in the same folder.
 
-Maintainers can use the internal repeated-test matrix runner in [docs/test-matrix.md](./docs/test-matrix.md) for controlled workflow or model comparisons. Normal users should stay on `interf test`.
+## The Core Loop
 
-## Advanced: Multiple Datasets
+1. Save a few checks for the task in `interf.json`.
+2. Optionally run `interf test` to see how the raw files do first.
+3. Run `interf compile` to prepare the data into a context folder.
+4. Run `interf test` again on the same checks.
+5. If loops are enabled, let Interf retry the same workflow variation or edit the workflow and test the new variation.
 
-Most projects only need one dataset entry.
+The project root stores the source-folder setup and checks. The context folder carries the local compiled context needed for repeat runs.
 
-Add another only when you want a different dataset folder, focus, or set of truth checks, for example:
+## Workflows
 
-- general folder understanding
-- finance reporting
-- board prep
-- diligence review
+A workflow tells Interf how to prepare and structure the files for a task before your agent uses them.
 
-Why add another:
+Interf ships with a built-in `interf` workflow for the common case. If you need a different method, create one locally:
 
-- it keeps a separate set of truth checks
-- it gives that dataset its own compiled output under `interf/<dataset>/`
-- it lets you test that dataset separately
+```bash
+interf create workflow
+```
+
+Workflow creation supports two paths:
 
-## Advanced: Compile Loops
+- draft a workflow from the current project with a local agent
+- copy an existing workflow and edit stage guidance directly
+
+After assignment, build the context folder with `interf compile` and run `interf test` on the same checks.
+
+## Compile Loops
 
 `max_attempts` is a retry budget for the same workflow variation.
 
 Retries keep the target fixed:
 
-- same dataset
+- same configured dataset
 - same workflow variation
-- same truth checks
+- same checks
 - same measurement
 
-`max_loops` enables the self-improving workflow loop in the normal `interf compile` path.
+`max_loops` enables self-improving workflow edits in the normal `interf compile` path.
 
 In that loop, the thing that changes is the workflow itself.
 
 Each loop can:
 
-- run the current workflow variation on the dataset
-- test it on the same truth checks
-- inspect the failed traces, preserved stage shells, and test artifacts
-- review the workflow and stage docs
-- create a new workflow variation for that dataset
-- test the new variation on the same truth checks
-
-- `max_attempts` retries the same workflow variation
-- a self-improving loop creates and tests workflow variations
-
-The workflow is the right surface for that kind of improvement because it is:
+- run the current workflow variation on the same configured dataset
+- test it on the same checks
+- inspect failed traces, preserved stage shells, and test artifacts
+- edit the workflow
+- build and test the next workflow variation
 
-- the reusable artifact
-- the human-reviewable method
-- the thing a future workflow-editing agent should inspect and change
-
-Interf Compiler preserves the workflow-improvement shell, the workflow-before / workflow-after snapshots, the failed stage shells, and the saved test runs from each loop so you can inspect exactly what the loop reviewed and changed.
-
-Example `interf.json`:
-
-```jsonc
-{
-  "datasets": [
-    {
-      "name": "cbre-chart-sanity",
-      "max_attempts": 3, // retry compile + test for the same workflow until this dataset passes or hits this limit
-      "max_loops": 2, // workflow-editing loops after retries fail
-      "checks": [
-        {
-          "question": "What were Bristol's annual take-up values in 2018 and 2016?",
-          "answer": "Around half a million sq ft in 2018, roughly 0.45 to 0.6 million sq ft, and about 0.7 to 0.8 million sq ft in 2016. These are approximate chart-derived reads."
-        }
-      ]
-    }
-  ]
-}
-```
-
-Use the normal retry and loop controls first. Maintainers can use the internal repeated-test runner when they want controlled comparisons across workflows, compile profiles, or models.
+Interf preserves workflow-improvement shells, workflow-before / workflow-after snapshots, failed stage shells, and test runs from each loop so you can inspect exactly what changed.
 
 ## Use It With Your Agent
 
@@ -242,54 +234,21 @@ If you already work through a local coding agent, it can run this process for yo
 Paste something like this into your agent:
 
 ```text
-Install @interf/compiler, run `interf` in this folder, and use the local agent executor.
-
-If `interf.json` is missing, draft one dataset entry with a few truth checks this agent should be able to answer from the selected dataset and add the expected answers for me to confirm.
-
-Then run a files-as-is baseline if helpful, compile the dataset, and run `interf test`.
-
-Tell me whether the compiled dataset passes the truth checks, and only recommend it if it does.
-```
-
-## Custom Workflows
+Install `@interf/compiler`, run `interf` in this folder, and use the local agent executor.
 
-Interf Compiler ships with a default workflow.
+If `interf.json` is missing, draft one dataset entry for this task with a few checks this agent should be able to answer from the selected files and add the expected answers for me to confirm.
 
-The built-in `interf` workflow runs three stages:
+Then run a files-as-is baseline if helpful, compile the context folder to prepare the data for that task, and run `interf test`.
 
-1. `summarize`
-2. `structure`
-3. `shape`
-
-If you want to change how the workflow runs on your dataset, this is the part you customize:
-
-```bash
-interf create workflow
-interf verify workflow --path <path>
+Tell me whether the context folder passes the checks, and only recommend it if it does.
 ```
 
-Then test that workflow on the same dataset and the same truth checks.
-
-Workflow docs live in [docs/workflow-spec.md](./docs/workflow-spec.md).
-
-## Core Commands
-
-- `interf` = open the project-root wizard
-- `interf init` = alias for the project-root wizard
-- `interf create dataset` = add another dataset entry when you need one
-- `interf create workflow` = create a reusable local seed workflow
-- `interf compile` = build a selected compiled dataset for the current project
-- `interf test` = compare files as-is and a compiled dataset on saved truth checks
-- `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
-
 ## More Docs
 
-- [docs/workflow-spec.md](./docs/workflow-spec.md) for custom workflows
-- [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/test-matrix.md](./docs/test-matrix.md) for the internal repeated-test matrix runner used in maintainer model/workflow comparisons
+- [src/packages/README.md](./src/packages/README.md) for the short system map
+- [src/packages/compiler/PACKAGE.md](./src/packages/compiler/PACKAGE.md) for compiler primitives and the runtime ABI
+- [src/packages/workflow-package/PACKAGE.md](./src/packages/workflow-package/PACKAGE.md) for the workflow package model
+- [src/packages/workflow-authoring/PACKAGE.md](./src/packages/workflow-authoring/PACKAGE.md) for workflow authoring and self-improving loops
 
 Maintainers should use [CONTRIBUTING.md](./CONTRIBUTING.md) for test and release gates.
 

package/builtin-workflows/interf/README.md

@@ -1,19 +1,31 @@
-# Interf Compiler (Recommended)
+# Interf (Built-in Workflow)
 
-Interf Compiler's default methodology: summarize source-grounded evidence, structure the cross-file layer, then shape the final compiled dataset around its focus and saved truth checks.
+Interf's built-in workflow: summarize source-grounded evidence, structure the cross-file layer, then shape the final context folder around its task focus and checks.
 
-## Package
+## Purpose
 
-- `workflow.json` = stage graph, compiler API target, and compile contract mapping
-- `compiled.schema.json` = deterministic compiled-dataset output shape
-- `improve/`, `compile/stages/`, and `use/query/` = human-readable authoring docs
-- Portable workflow packages are standalone: explicit stages, schema, and docs live together in this folder
-- Interf Compiler projects native agent shells from these docs for query use, stage execution, and workflow-improvement loops
+- General compiled context workflow for agent use
+- Compile mixed raw files into evidence-backed summaries, cross-file structure, and a usable entrypoint for agents answering the questions this task depends on.
+
+## Zones
+
+- `raw` — input directory at `raw`
+- `summaries` — working directory at `summaries`
+- `knowledge-entities` — output directory at `knowledge/entities`
+- `knowledge-claims` — output directory at `knowledge/claims`
+- `knowledge-indexes` — output directory at `knowledge/indexes`
+- `home` — output file at `home.md` used as the primary entrypoint for this workflow
+- `runtime` — runtime zone at `.interf/runtime`
 
 ## Stages
 
 - `summarize` — Turn source files into per-file summaries. (compiled-file-evidence; reads: raw, runtime; writes: summaries)
 - `structure` — Build the cross-file knowledge structure from the summaries. (compiled-knowledge-structure; reads: summaries, runtime; writes: knowledge-entities, knowledge-claims, knowledge-indexes)
-- `shape` — Shape the final compiled dataset around the saved focus and truth checks. (compiled-query-shape; reads: raw, summaries, knowledge-entities, knowledge-claims, knowledge-indexes, runtime; writes: knowledge-indexes, home)
+- `shape` — Shape the final context folder around the saved task focus and checks. (compiled-query-shape; reads: raw, summaries, knowledge-entities, knowledge-claims, knowledge-indexes, runtime; writes: knowledge-indexes, home)
+
+## Why `home.md` exists here
+
+This built-in workflow creates `home.md` as the main agent entrypoint for the context folder.
+That is behavior of the `interf` workflow, not a compiler-wide rule.
 
-This package is the built-in seed for `interf`. Interf Compiler copies or materializes it into `.interf/workflow/` and runs that local package directly.
+This package is the built-in seed for `interf`.

package/builtin-workflows/interf/compile/stages/shape/SKILL.md

@@ -1,13 +1,16 @@
 # Shape
 
-Shape the final compiled dataset around the saved focus and truth checks.
+Shape the final context folder around the saved task focus and checks.
 
 Contract type: `compiled-query-shape`
 
 ## Requirements
 
-- Use the compiled focus plus saved truth-check question text to shape `home.md` and retrieval routes.
+- Use the compiled task focus plus saved truth-check question 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.
+- 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 chart-derived value is approximate, use a bounded range instead of a pseudo-exact number.
 - Match the granularity of the visible axis labels or bands. Do not invent finer precision than the chart supports.
 - Keep the answer inside the visible tick band unless the chart supports a tighter bound.
@@ -15,12 +18,12 @@ Contract type: `compiled-query-shape`
 - If a mark touches or nearly touches a labeled gridline, anchor the answer at that gridline or the immediately adjacent half-band.
 - Do not widen a chart-derived range across multiple visible bands unless the chart genuinely supports that uncertainty.
 - When you settle on a bounded chart read, keep that same band consistent across `home.md`, focused indexes, and claim/entity notes for that metric and year.
-- Do not copy expected answers into the compiled dataset.
+- Do not copy expected answers into the context folder.
 
 ## Notes
 
-- Use the dataset focus and saved truth checks to bias the final compiled dataset toward the job it should be especially good at.
-- Do not copy expected answers into the final compiled dataset just because the checks imply them.
+- Use the saved task focus and checks to bias the final context folder toward the job it should be especially good at.
+- Do not copy expected answers into the final context folder 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 `raw/` 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.
 - If a saved truth check depends on chart-derived or table-derived values, carry the final bounded reads forward into focused notes with provenance instead of repeatedly recomputing them from raw.

package/builtin-workflows/interf/compile/stages/structure/SKILL.md

@@ -8,6 +8,8 @@ Contract type: `compiled-knowledge-structure`
 
 - Treat the knowledge layer as retrieval structure, not final truth.
 - Prefer durable entity, claim, and index notes over one giant catch-all file.
+- Keep structure-stage links stage-local: prefer linking only to summaries or knowledge notes that are already meaningful by the end of this stage. Avoid relying on `home.md` or other shape-stage routes as the main navigation surface.
+- Prefer direct file-reading and search tools over shell commands for routine file inspection.
 
 ## Notes
 
@@ -15,4 +17,5 @@ Contract type: `compiled-knowledge-structure`
 - Use taxonomy and ontology only as means to improve retrieval, navigation, and evidence tracking.
 - For small datasets, 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.
+- 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/builtin-workflows/interf/compile/stages/summarize/SKILL.md

@@ -6,8 +6,24 @@ Contract type: `compiled-file-evidence`
 
 ## Requirements
 
-- Each summary must use JSON frontmatter and include `source`, `source_kind`, `evidence_tier`, `truth_mode`, `state`, and a non-empty `abstract`.
-- Include a clear abstract block in the body so a human can skim the summary quickly.
+- Each summary must start with literal JSON frontmatter between `---` lines, not a fenced code block.
+- Required opening shape:
+- `---`
+- `{`
+- `  "source": "raw/example.md",`
+- `  "source_kind": "markdown",`
+- `  "evidence_tier": "primary",`
+- `  "truth_mode": "source-grounded",`
+- `  "state": "complete"`
+- `}`
+- `---`
+- Do not wrap that JSON in triple backticks or emit ```json anywhere in the summary file.
+- Prefer direct file-reading and search tools over shell commands for routine file inspection.
+- Include a clear abstract either in frontmatter or under a markdown `## Abstract` heading so a human can skim the summary quickly.
+- Valid abstract forms for deterministic validation are:
+- frontmatter key `"abstract"` with a real sentence, or
+- a markdown heading `## Abstract` followed by at least one sentence
+- A bare `Abstract` label without markdown heading syntax does not count.
 - Do not skip the abstract just because the overview section is present.
 
 ## Notes

package/builtin-workflows/interf/improve/SKILL.md

@@ -2,17 +2,17 @@
 
 Workflow: interf
 
-This file is the editable authoring source for Interf Compiler's generated native workflow-improver shell.
+This file is the editable authoring source for Interf's generated native workflow-improver shell.
 The improver edits this local package 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 workflow package for this compiled dataset to create a better workflow variation for this dataset.
-4. Keep `workflow.json`, `compiled.schema.json`, and any changed stage docs aligned.
+3. Edit only the local workflow package for this context folder to create a better workflow variation for this task.
+4. Keep `workflow.json`, `workflow.schema.json`, and any changed stage docs aligned.
 
 Guardrails:
-- do not edit truth checks, test specs, or raw dataset files
+- do not edit checks, test specs, or raw source files
 - do not hardcode expected answers into workflow docs
 - keep this package standalone; do not add or rely on runtime `extends` or fallback behavior
 - prefer small, defensible workflow changes over random churn

package/builtin-workflows/interf/use/query/SKILL.md

@@ -25,4 +25,4 @@ Answering rule:
 - if multiple compiled notes mention the same chart read, keep the answer consistent with the most focused compiled note rather than synthesizing a new midpoint or shifted band
 - when the compiled layer is insufficient, verify in `raw/` and then answer
 
-You can edit this file to bias manual question-answering behavior for this compiled dataset.
+You can edit this file to bias manual question-answering behavior for this context folder.