@interf/compiler 0.33.0 → 0.50.0

package/public-repo/skills/interf/SKILL.md

@@ -5,10 +5,10 @@ description: "Use when an agent needs to operate Interf from natural language: c
 
 # Interf
 
-Interf prepares data for agents. It lets users' agents build a Context Graph
-from their files with source coverage summaries, task-aware knowledge, artifact
-handoffs, and links back to sources, so users can inspect what was covered
-before agents answer.
+Interf prepares data for agent tasks. It lets users' agents build a Context Graph
+from their files with source coverage
+summaries, task-aware knowledge, graph entrypoints, and links back to sources,
+so users can inspect what was covered before agents answer.
 
 Interf is not a search engine and not a general RAG index over every Project
 the instance has seen. Treat it as a data-preparation workflow for the user's
@@ -17,8 +17,9 @@ when they clearly bind the same Source and task-relevant Build Plan.
 
 Ask Claude to answer from a folder. With Interf, Claude builds a Context Graph
 from the files and the user can inspect what it covered. Interf runs locally,
-exposes Context Checks, Build evidence, traces, and ready / not ready status,
-and returns a Context Graph locator agents can read.
+exposes Graph Manifest metrics, Stage Manifest coverage, traces, and ready /
+not ready status, preserves stage execution shells for inspection, and returns
+a Context Graph locator agents can read.
 
 ## Core Model
 
@@ -28,46 +29,70 @@ and returns a Context Graph locator agents can read.
 - **Source** = input files or data. A local folder is the current binding
   shape; Source stays local and read-only, and Interf reads it by reference,
   not by copy.
-- **Project** = the durable workspace for one Source binding, selected
-  Build Plan, Project activity, execution agents, and the latest Context Graph.
-  The detailed intent, requested Artifact contract, stages, and Context Checks belong in the
-  Build Plan.
-- **Requested Artifact** = an output agents need Interf to build, such as a
-  source map, index, timeline, comparison note, extraction table, or custom file.
-- **Build Plan** = the reviewed plan for how Interf will build a Context Graph
-  and requested Artifacts from the Source. It owns intent, requested Artifacts,
-  user-visible Context Checks, Artifact diagnostics, Build instructions, and optional
-  Source context. It can be drafted, selected, saved, or improved. CLI
-  namespace: `interf plan`.
+- **Project** = the durable workspace for one Source binding, agent task
+  intent, selected Build Plan, Project activity, execution agents, and the
+  latest Context Graph.
+- **Build Plan** = the reviewed recipe for how Interf will build a Context
+  Graph from the Source for the Project intent. It owns requested outputs,
+  expected inputs, coverage metrics, graph entrypoints, Build instructions,
+  and optional Source context. It can be drafted, selected, saved, or improved.
+  CLI namespace: `interf plan`.
 - **Run** = one durable execution record. Build runs, benchmark runs,
   Build Plan draft runs, and Build Plan improvement runs are all Runs.
+- **execution shell** = the replayable workspace Interf creates for an
+  agent-executed stage. It contains stage-local `AGENTS.md` / `CLAUDE.md`, the
+  native skill, contract, expected inputs, Source Manifest, required prior
+  outputs, writable output mounts, prompt log, event/status logs, validator,
+  and validation attempts. Stage retries create a fresh shell with previous
+  attempts and validation feedback mounted under `runtime/`. Use it for
+  debugging and retry; do not present it as the product output.
 - **Build Context Graph** = the action that runs the selected Build Plan for a
   Project and produces one Context Graph. CLI: `interf build <project-id>`.
 - **Context Graph** = source-backed context built from files so agents can use
-  prepared context instead of partial file reads. It contains task handoffs,
-  summaries, knowledge notes, links back to sources, and traces. Current local
-  builds expose it as an inspectable folder agents can continue from.
+  prepared context instead of partial file reads. It contains `home.md`, graph
+  entrypoints, summaries, knowledge notes, links back to sources, and traces.
+  Current local builds expose it as an inspectable folder agents can continue
+  from.
 
-Agents should think in Build Plan contracts: "what Context Graph, requested
-Artifacts, checks, evidence, and traces need to exist before I can answer from
-this Source without partial file reads?"
+Agents should think in Build Plan contracts: "what Context Graph outputs,
+expected inputs, coverage metrics, entrypoints, and traces need to exist before
+I can answer from this Source without partial file reads?"
 
 ## Source Reference Contract
 
 The Context Graph is a knowledge map over the Source. It normally contains
-`artifacts/` task handoffs, `summaries/` coverage proof, `knowledge/`
-navigation/drilldown, traces, and source references. It does not duplicate the
-raw Source files.
+`home.md`, `artifacts/` graph entrypoints, `summaries/` coverage proof,
+`knowledge/` navigation/drilldown, traces, and source references. It does not
+duplicate the raw Source files.
+
+A built Context Graph has three fixed top-level layers and `home.md`:
+
+- `summaries/` — grounding: one folder per Source file, each linking back to its
+  Source. This is COVERAGE proof (every file was read; file-level, not a claim
+  that every fact was captured).
+- `knowledge/` — the knowledge web: claims, entities, timelines, tables, etc.
+  Every note links DOWN to its summary and carries raw `source_refs`, and notes
+  link to EACH OTHER. This is TRACEABILITY (every claim links a Source; no
+  orphaned summaries; no disconnected islands).
+- `artifacts/` — higher-level task outputs that reference summaries + knowledge
+  (+ raw source refs for exact claims).
+- `home.md` — start here; routes into all three.
+
+Readiness (`ready` / `not ready`) is backed by COVERAGE and TRACEABILITY — both
+provable and deterministic. A separate VERIFICATION pass (`interf benchmark`) is
+a fallible double-check: it flags claims a verifier could not confirm against the
+cited file. It is not proof of absence and does not gate readiness — for exact
+claims, always read the original Source via the note's `source_refs`.
 
 Use the Context Graph first to learn what exists, which files/pages/figures are
-relevant, which requested Artifacts were prepared, and where evidence lives in
-the original Source. Then follow the graph's source references when exact
-wording, table values, chart positions, visual ranges, or provenance matter.
+relevant, which graph outputs were prepared, and where evidence lives in the
+original Source. Then follow the graph's source references when exact wording,
+table values, chart positions, visual ranges, or provenance matter.
 
 "Answer from the Context Graph" means:
 
-- start from `artifacts/` task handoffs instead of rediscovering the Source ad hoc;
-- use `home.md` only as a graph index, not as the answer surface;
+- start from `home.md` as the primary graph entrypoint;
+- use generated `artifacts/` as task-specific graph entrypoints;
 - use `summaries/` for coverage proof and `knowledge/` for navigation/drilldown;
 - use the graph's source references and traces as backlinks to the source of
   truth;
@@ -140,40 +165,44 @@ inside that Source unless the user explicitly asks to narrow scope. If no
 usable Source locator is available, ask for one Source locator, usually a local
 folder path. Do not ask for a file-selection menu.
 
-1. **Propose checks and requested Artifacts first.**
+1. **Propose requested outputs and coverage first.**
 
-   Say what Interf needs to prepare before the answer can be trusted. The
-   output is a short in-chat review:
+   Say what Interf needs to prepare before the answer can be trusted. Requested
+   outputs are GRAPH AREAS — claim nodes, comparison nodes, a timeline, a
+   coverage index — the next agent will read and reason over. They are NOT
+   the answer itself, NOT a finished report, and NOT a summary document. Source
+   stays in the user's files; Interf builds the task-specific Context Graph
+   the agent traverses. The output is a short in-chat review:
 
    ```text
-   Before I answer, Interf should prepare this report for the question.
+   Before I answer, Interf should prepare this Context Graph for the question.
 
-   What Interf will check:
-   - <plain-English check>
-     Backed by: <requested Artifact>
-   - <plain-English check>
-     Backed by: <requested Artifact>
+   Context Graph outputs (graph areas, not the answer):
+   1. <output name> — <which claim nodes / comparison nodes / timeline Interf will prepare>
+   2. <output name> — <same, for the next area>
 
-   Requested Artifacts:
-   1. <artifact name> — <what it will export into the Context Graph>
-   2. <artifact name> — <what it will export into the Context Graph>
+   Coverage I will verify:
+   - files processed
+   - source units summarized
+   - knowledge reviewed and used
+   - graph entrypoints generated
 
-   Approve these checks and Artifacts, and I will draft the Build Plan.
+   Approve these outputs and coverage expectations, and I will draft the Build Plan.
    ```
 
    Stop here unless the user has already explicitly approved this exact set of
-   checks and Artifacts. Do not answer yet.
+   outputs and coverage expectations. Do not answer yet.
 
 2. **Draft the Build Plan after approval.**
 
    Create or reuse the Project, draft the Build Plan, then summarize it in
-   chat. Include the Project id, Build Plan id, checks, requested Artifacts,
-   stages, and what the Context Graph will contain. Include a review locator
-   when the connected Interf client provides one, but the user should be able
-   to review the plan in chat.
+   chat. Include the Project id, Build Plan id, requested outputs, stages,
+   expected inputs, graph entrypoints, and what the Context Graph will contain.
+   Include a review locator when the connected Interf client provides one, but
+   the user should be able to review the plan in chat.
 
    Stop here unless the user approves the Build Plan or already gave explicit
-   end-to-end autonomy after reviewing the checks.
+   end-to-end autonomy after reviewing the outputs and coverage expectations.
 
 3. **Build the Context Graph after Build Plan approval.**
 
@@ -189,15 +218,15 @@ folder path. Do not ask for a file-selection menu.
 
 4. **Answer only from the Context Graph.**
 
-   Read the task handoff notes under `artifacts/` first. Use them as the map
-   for what exists and where to look in the Source. Use `home.md` only as an
-   index, `summaries/` as coverage proof, and `knowledge/` as drilldown. For exact values,
+   Read `home.md` first. Use generated graph entrypoints under `artifacts/`
+   as task-specific starting points, `summaries/` as coverage proof, and
+   `knowledge/` as drilldown. For exact values,
    quotes, chart reads, tables, or provenance-sensitive claims, follow the
    graph's source references back to the cited Source evidence before answering.
    Answer with the values the Context Graph prepared plus any source-reference
-   verification you performed, and say which requested Artifact and source page
+   verification you performed, and say which graph entrypoint and source page
    the answer came from. If the Context Graph points to the right evidence but
-   the artifact is too coarse, under-extracted, or missing the required visual
+   the prepared graph output is too coarse, under-extracted, or missing the required visual
    semantics, say the Context Graph is not ready and improve the Build Plan.
 
 The public package path is CLI/runtime-first. MCP is how agent hosts talk to a
@@ -271,8 +300,8 @@ interf runtime start             # fallback: managed background service
 ### Review References
 
 When a Project, Build Plan, or Run is created, include the compact review
-summary in chat: Project id, Build Plan id, Run id, checks, requested
-Artifacts, and the Context Graph locator when ready.
+summary in chat: Project id, Build Plan id, Run id, requested outputs, primary
+metrics, and the Context Graph locator when ready.
 
 The local HTTP URL is an authorized service connection fallback, not a review
 UI. Do not present `127.0.0.1` links as the review surface for normal users.
@@ -309,7 +338,7 @@ UI. Do not present `127.0.0.1` links as the review surface for normal users.
    Treat `package_version`, CLI versions, and raw service metadata as internal
    diagnostics. Do not include them in normal user-facing replies.
 
-2. **Propose what Interf will check before mutating state**.
+2. **Propose what Interf will prepare before mutating state**.
 
    After confirming an Interf connection, inspect what you can about the
    Source: filenames, file types, obvious page counts, section names, and
@@ -317,8 +346,8 @@ UI. Do not present `127.0.0.1` links as the review surface for normal users.
    context, not evidence that Interf processed the files.
 
    If the user invoked `/interf` or explicitly asked to use Interf, that is
-   permission to inspect the Source and propose the checks Interf should run plus
-   the requested Artifacts that make those checks true. It is not permission to
+   permission to inspect the Source and propose the graph outputs and coverage
+   metrics Interf should prepare. It is not permission to
    answer from the Source. Follow the Required User-Visible Flow above.
 
    Keep the proposal compact:
@@ -330,19 +359,19 @@ UI. Do not present `127.0.0.1` links as the review surface for normal users.
    Interf should prepare data for the agent by building a Context Graph from
    the files.
 
-   What Interf will check:
-   - <Plain-English check>
-     Backed by: <requested Artifact name>
-   - <Plain-English check>
-     Backed by: <requested Artifact name>
-
-   Requested Artifacts:
-   1. **<Plain-English artifact name>**
+   Context Graph outputs:
+   1. **<Plain-English output name>**
       Why it helps: <short sentence>
-   2. **<Plain-English artifact name>**
+   2. **<Plain-English output name>**
       Why it helps: <short sentence>
 
-   Approve these checks and Artifacts, and I will draft the Build Plan.
+   Coverage metrics:
+   - files processed
+   - source units summarized
+   - knowledge reviewed and used
+   - graph entrypoints generated
+
+   Approve these outputs and coverage expectations, and I will draft the Build Plan.
    ```
 
    Do not show JSON to the user. Do not use markdown tables. Do not include
@@ -353,13 +382,13 @@ UI. Do not present `127.0.0.1` links as the review surface for normal users.
 3. **Create the Project after approval**.
 
    ```sh
-   interf project create <id> --source <path>
+   interf project create <id> --source <path> --intent "<agent task>"
    ```
 
    Create a fresh Project for the current Source unless the user explicitly
-   names an existing Project id. Store the approved proposal in the Build Plan
-   draft request, not on the Project. Store advisory source interpretation as
-   `source_context` when useful.
+   names an existing Project id. Store the durable agent task on the Project.
+   Store requested outputs and advisory source interpretation in the Build Plan
+   draft request, using `source_context` when useful.
 
 4. **Draft a Build Plan**.
 
@@ -369,12 +398,10 @@ UI. Do not present `127.0.0.1` links as the review surface for normal users.
 
    ```sh
    interf plan draft <project-id> \
-     --intent "<agent task>" \
+     --intent "<agent task override, optional>" \
      --requested-artifacts-json '<json-array>' \
-     --checks-json '<context-checks-json-array>' \
      --source-context-json '<json-object>' \
-     --artifacts "<optional extra requested Artifact notes or change request>" \
-     --ready-when "<plain-English Context Check the requested Artifacts should satisfy>"
+     --artifacts "<optional extra requested output notes or change request>"
    interf runs status <run-id>
    interf plan show <build-plan-id>
    ```
@@ -387,10 +414,11 @@ UI. Do not present `127.0.0.1` links as the review surface for normal users.
 
    After the Build Plan is drafted, selected, or materially changed, send the
    user a compact in-chat review: Project id, Build Plan id, what Interf will
-   check, which requested Artifacts back each check, stage names, and what each
+   prepare, stage names, expected inputs, graph entrypoints, and what each
    stage writes. Include a review locator when the connected Interf client
    provides one, but do not force the user to leave chat to approve. Unless the
-   user granted autonomy after reviewing the checks, pause here.
+   user granted autonomy after reviewing the outputs and coverage expectations,
+   pause here.
 
 6. **Build the Context Graph**.
 
@@ -403,9 +431,11 @@ UI. Do not present `127.0.0.1` links as the review surface for normal users.
    `--watch`, the CLI tails events until the Build reaches a terminal state.
 
    If the user asked for an answer in the same `/interf` request, answer from
-   the built Context Graph, requested Artifacts, and source references linked
-   from that graph. Do not bypass the graph by searching the original
-   PDF/report/source file directly.
+   the built Context Graph. Start from `home.md` and graph entrypoints under
+   `artifacts/`, then use `summaries/` for Source coverage proof,
+   `knowledge/` for drilldown, and traces/source references for exact claims.
+   Do not bypass the graph by searching the original PDF/report/source file
+   directly.
 
 7. **Inspect Project activity and optionally benchmark**.
 
@@ -421,15 +451,14 @@ UI. Do not present `127.0.0.1` links as the review surface for normal users.
    `interf benchmark` is a benchmark/evaluation run for Q&A / fact-check accuracy.
    Use it when the user wants a source-files baseline, a Context Graph
    evaluation, or a source-vs-Context Graph comparison. It is not the
-   Context Checks surface.
+   readiness surface.
 
 8. **On `not ready`, improve the Build Plan**.
 
    ```sh
    interf plan improve <project-id> \
-     --intent "<what needs to change>" \
-     --artifacts "<requested Artifact changes, if any>" \
-     --ready-when "<Context Check changes, if any>"
+     --intent "<what needs to change, optional>" \
+     --artifacts "<requested output changes, if any>"
    ```
 
 ## Agents
@@ -471,8 +500,8 @@ Build Plans may declare custom names; the Build runtime treats unknown roles as
 - If `/interf` was invoked and no connection exists, stop. Do not answer by
   reading raw source files.
 - Once a Context Graph exists, use it as the knowledge map. Source drilldown is
-  allowed only through graph-provided source references, traces, requested
-  Artifacts, or the Project's recorded Source Manifest.
+  allowed only through graph-provided source references, traces, graph
+  entrypoints, or the Project's recorded Source Manifest.
 - For long-running work, use the async default and check status by id. Use
   `--watch` only when the agent must wait inline.
 - Use MCP when available. Use the CLI only when it is
@@ -485,28 +514,29 @@ Build Plans may declare custom names; the Build runtime treats unknown roles as
   provides the local connection details or gives an API-integration task.
 - Never write helper files into the Source folder. The Source is read-only
   input.
-- Treat Context Checks plus requested Artifact review as the default
-  human trust gate.
-- Treat structural Artifact checks as necessary but not sufficient for
+- Treat Build Plan review plus Graph Manifest metrics as the default human
+  trust gate.
+- Treat structural output checks as necessary but not sufficient for
   precision. If a visual/table/chart answer needs range, axis, period, unit,
-  series, or provenance semantics that the artifact did not capture, mark the
-  Context Graph not ready and improve the Build Plan.
+  series, or provenance semantics that the graph output did not capture, mark
+  the Context Graph not ready and improve the Build Plan.
 - The first visible Interf response to a read-and-answer request is the
-  checks-and-Artifacts proposal. It is not a draft answer.
+  requested-outputs-and-coverage proposal. It is not a draft answer.
 - Separate proposal from evidence. Before a Build, you can say what Interf
-  plans to check, which requested Artifacts back that, and what evidence it
-  will produce. After a Build, you can say which files/pages were processed,
-  what evidence was produced, and whether the Context Graph is ready.
+  plans to prepare, which outputs and coverage metrics the Build Plan targets,
+  and what graph entrypoints it will produce. After a Build, you can say which
+  files/pages were processed, what graph resources were produced, and whether
+  the Context Graph is ready.
 - Ask one concise clarification only when the Source or agent goal is missing,
-  or when ambiguity makes the requested Artifacts impossible to draft. For
+  or when ambiguity makes the requested outputs impossible to draft. For
   normal domain ambiguity, state the assumption and make it a check.
 
 ## Show Your Work
 
-The Run record, Build evidence, checks, traces, and Context Graph locator are
-the user's verification surface. Whenever you start a Build, summarize the
-Project id, Build id, checks, and Context Graph locator in chat. If the
-connected Interf client returns a review locator, include it.
+The Run record, Stage Manifests, Graph Manifest, traces, and Context Graph locator show
+what the user can inspect. Whenever you start a Build, summarize the
+Project id, Build id, primary metrics, and Context Graph locator in chat. If
+the connected Interf client returns a review locator, include it.
 
 Do not present the local HTTP service URL as a review UI.
 
@@ -521,7 +551,7 @@ I'll check status in a moment with `interf runs status <run-id>`.
 ```
 
 When a Build finishes, report the final `ready` / `not ready` status, the
-Context Graph locator, and the requested Artifacts or validation failures that
+Context Graph locator, and the primary metrics or missing coverage that
 matter.
 
 ## Reading The Context Graph Locator
@@ -535,8 +565,8 @@ Context Graph: <local-path-returned-by-interf>
 ```
 
 For `local-path`, use the agent's filesystem tools to read the directory.
-Start from `artifacts/` task handoffs. Use `home.md` only if you need to find
-the right handoff. Follow source refs for exact claims.
+Start from `home.md`, then follow graph entrypoints under `artifacts/`. Follow
+source refs for exact claims.
 
 ## Interf Client Freeform Proposal Mode
 
@@ -553,7 +583,7 @@ Use these action types:
 - `build-plan-improvement`
 - `clarification`
 
-Use `build` when the user asks to prepare data, build artifacts, or refresh
+Use `build` when the user asks to prepare data, build graph outputs, or refresh
 the Context Graph for an agent task. Set `project` to the Project id. Do not set
 `build_plan` for a Build proposal; Build always runs the Project's selected
 Build Plan. If the request named a different Build Plan, select or draft that
@@ -571,18 +601,34 @@ Return this shape:
   "action_type": "build",
   "project": "project-id",
   "title": "short approval card title",
-  "summary": "one sentence describing which artifacts will be built",
+  "summary": "one sentence describing which graph outputs will be built",
   "assistant_message": "concise explanation for the user",
   "command_preview": "interf build project-id"
 }
 ```
 
-For Build Plan drafting proposals, keep user-facing checks in
-`values.checks[]`, requested Artifacts in `values.requested_artifacts[]`, and
-the advisory source summary in `values.source_context`:
-Use stable requested Artifact ids and connect each Context Check with
-`backed_by_artifact_ids`. These ids are implementation detail for the action
-payload; do not show them in the human proposal.
+For Build Plan drafting proposals, keep requested outputs and graph entrypoints
+in `values.requested_artifacts[]` for the current API shape, and put the
+advisory source summary in `values.source_context`. Use stable output ids.
+Treat `values.checks[]` as an optional developer-diagnostic field only when an
+Interf client explicitly asks for it; do not make checks the human-facing
+proposal.
+
+**Requested outputs are graph areas, not answers.** Each entry must describe a
+region of the Context Graph the next agent will traverse — claim nodes,
+entity nodes, comparison nodes, timelines, coverage indexes — NOT the user's
+answer or a finished report. Interf prepares structured context; the agent
+still does the reasoning.
+
+Good titles / purposes (graph-shaped):
+- `"London cost-and-take-up claim nodes"` — source-cited claim notes the agent can compare against South West claim nodes.
+- `"South West rent-growth signals timeline"` — dated decision/forecast signals extracted from the report.
+- `"Page-by-page guide of the report"` — coverage index so the agent knows where evidence for any claim lives.
+
+Bad titles / purposes (replace agent thinking — do NOT use):
+- `"NY rent growth answer"` — that is the agent's job, not Interf's.
+- `"Final report"` / `"Forecast summary"` — finished answer artifacts.
+- `"Recommended decision"` — Interf does not decide; it prepares the data the decider reads.
 
 ```json
 {
@@ -590,32 +636,25 @@ payload; do not show them in the human proposal.
   "project": "project-id",
   "build_plan": "project-id-build-plan",
   "title": "Draft Build Plan",
-  "summary": "Drafts the Build Plan for the requested Artifacts.",
+  "summary": "Drafts the Build Plan for the requested graph outputs.",
   "values": {
     "build_plan_id": "project-id-build-plan",
     "intent": "London versus South West annual take-up",
-    "checks": [
+    "requested_artifacts": [
       {
-        "label": "Every page is covered.",
-        "backed_by_artifact_ids": ["guide-to-report"]
+        "id": "page-guide",
+        "title": "Page-by-page guide of the report",
+        "purpose": "Short coverage note per page so the agent knows what evidence lives where."
       },
       {
-        "label": "The final comparison cites sources for every figure.",
-        "backed_by_artifact_ids": ["london-versus-south-west-comparison"]
-      }
-    ],
-    "requested_artifacts": [
-      {
-        "id": "guide-to-report",
-        "title": "Guide to the report",
-        "purpose": "A short note for each page, so the agent knows what is where.",
-        "checks": ["Every page is listed.", "Each page has a plain-English summary."]
+        "id": "london-claims",
+        "title": "London take-up claim nodes",
+        "purpose": "Source-cited claim notes (figures, source page, caveat) for London take-up — the agent compares these against the South West nodes."
       },
       {
-        "id": "london-versus-south-west-comparison",
-        "title": "London versus South West comparison",
-        "purpose": "A source-cited comparison note for the figures the agent task depends on.",
-        "checks": ["Every figure has a source citation.", "Ambiguous chart-derived values are bounded."]
+        "id": "south-west-claims",
+        "title": "South West take-up claim nodes",
+        "purpose": "Same shape as the London claim nodes, scoped to South West figures."
       }
     ],
     "source_context": {
@@ -653,5 +692,6 @@ interf traces show <trace-kind> --project <project-id>
 ```
 
 The UI link is for visual review. The CLI output is for agent-readable status,
-Build Plan review, requested Artifact status, Build errors, Checks, Build evidence,
-traces, benchmark results, and ready / not ready summaries.
+Build Plan review, graph output status, Build errors, Graph Manifest metrics,
+Stage Manifest coverage, stage execution sessions, traces, benchmark results,
+and ready / not ready summaries.

package/dist/packages/runtime/build/runtime-paths.d.ts

@@ -1,8 +0,0 @@
-export declare function runPath(dirPath: string): string;
-export declare function runHistoryPath(dirPath: string): string;
-export declare function stageContractPath(dirPath: string): string;
-export declare function archivedStageContractPath(dirPath: string, runId: string): string;
-export declare function logsDirPath(dirPath: string): string;
-export declare function promptLogPath(dirPath: string, runId: string): string;
-export declare function eventLogPath(dirPath: string, runId: string): string;
-export declare function statusLogPath(dirPath: string, runId: string): string;

package/dist/packages/runtime/build/runtime-paths.js

@@ -1,26 +0,0 @@
-import { join } from "node:path";
-import { contextGraphRuntimeArchivedStageContractPath, contextGraphRuntimeLogsRoot, contextGraphExecutionStageLedgerHistoryPath, contextGraphExecutionStageLedgerPath, contextGraphRuntimeStageContractPath, } from "./context-graph-paths.js";
-export function runPath(dirPath) {
-    return contextGraphExecutionStageLedgerPath(dirPath);
-}
-export function runHistoryPath(dirPath) {
-    return contextGraphExecutionStageLedgerHistoryPath(dirPath);
-}
-export function stageContractPath(dirPath) {
-    return contextGraphRuntimeStageContractPath(dirPath);
-}
-export function archivedStageContractPath(dirPath, runId) {
-    return contextGraphRuntimeArchivedStageContractPath(dirPath, runId);
-}
-export function logsDirPath(dirPath) {
-    return contextGraphRuntimeLogsRoot(dirPath);
-}
-export function promptLogPath(dirPath, runId) {
-    return join(logsDirPath(dirPath), `${runId}.prompt.txt`);
-}
-export function eventLogPath(dirPath, runId) {
-    return join(logsDirPath(dirPath), `${runId}.events.ndjson`);
-}
-export function statusLogPath(dirPath, runId) {
-    return join(logsDirPath(dirPath), `${runId}.status.log`);
-}

package/dist/packages/runtime/build/state-paths.d.ts

@@ -1,7 +0,0 @@
-export declare function statePath(dirPath: string): string;
-export declare function healthPath(dirPath: string): string;
-export declare function viewSpecPath(dirPath: string): string;
-export declare function sourceManifestPath(dirPath: string): string;
-export declare function sourceManifestAuditPath(dirPath: string): string;
-export declare function sourceFilesPath(dirPath: string): string;
-export declare function sourceStatePath(dirPath: string): string;

package/dist/packages/runtime/build/state-paths.js

@@ -1,22 +0,0 @@
-import { contextGraphRuntimeHealthPath, contextGraphRuntimeSourceManifestAuditPath, contextGraphRuntimeSourceManifestPath, contextGraphRuntimeSourceFilesPath, contextGraphRuntimeSourceStatePath, contextGraphRuntimeStatePath, contextGraphRuntimeViewSpecPath, } from "./context-graph-paths.js";
-export function statePath(dirPath) {
-    return contextGraphRuntimeStatePath(dirPath);
-}
-export function healthPath(dirPath) {
-    return contextGraphRuntimeHealthPath(dirPath);
-}
-export function viewSpecPath(dirPath) {
-    return contextGraphRuntimeViewSpecPath(dirPath);
-}
-export function sourceManifestPath(dirPath) {
-    return contextGraphRuntimeSourceManifestPath(dirPath);
-}
-export function sourceManifestAuditPath(dirPath) {
-    return contextGraphRuntimeSourceManifestAuditPath(dirPath);
-}
-export function sourceFilesPath(dirPath) {
-    return contextGraphRuntimeSourceFilesPath(dirPath);
-}
-export function sourceStatePath(dirPath) {
-    return contextGraphRuntimeSourceStatePath(dirPath);
-}

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

@@ -1,34 +0,0 @@
-# Shape
-
-Shape the task-specific Artifact handoff and final Context Graph index
-around the saved task focus and Checks.
-
-Contract type: `build-query-shape`
-
-## Requirements
-
-- Use the Build task focus plus saved Check text to shape `artifacts/` handoffs and supporting graph routes.
-- Write at least one task-specific handoff note under `artifacts/`.
-- Each Artifact handoff must start with JSON frontmatter containing non-empty `task`, `source_refs`, `handoff_type`, `truth_mode`, `verification_state`, and `caveats`.
-- `source_refs` must point to original Source locations, not just generated summaries or knowledge notes.
-- Artifact handoff notes should tell the downstream agent which original Source files, pages, figures, tables, sections, units, periods, series, and caveats matter for the task.
-- Artifact handoff notes should route the downstream agent to original Source refs for exact claims. Do not present generated summaries or knowledge notes as the dataset or source of truth.
-- Rewrite `home.md` into a real graph index note. Do not leave the scaffold `Not yet built.` placeholder in place, and do not make `home.md` the answer surface.
-- When you add wikilinks, target real Context Graph 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.
-- For unlabeled charts, screenshots, diagrams, or visual marks, either create a measurement note with source-grounded visual reference, calibration, method, and uncertainty, or tell the downstream agent to inspect the original Source before answering.
-- Keep approximate values consistent across `home.md`, focused indexes, and claim/entity notes.
-- Do not copy expected answers into the Context Graph.
-
-## Notes
-
-- Use the saved task focus and Checks to bias the final Context Graph toward the job it should be especially good at.
-- Do not copy benchmark expected answers into the final Context Graph.
-- Prefer the saved summary evidence and structured notes when they already preserve routing, source refs, and caveats.
-- Reopen source references during shaping when exact wording, table values, chart reads, or provenance-sensitive claims matter.
-- If a saved Check depends on source-derived values, route the handoff to source refs and preserve source granularity instead of fabricating precision.
-- Prefer better routing, prioritization, and focused navigation over speculative synthesis.
-- Any wikilinks you add to `home.md` or indexes must resolve to real Context Graph note basenames or explicit relative paths.