@interf/compiler 0.2.5 → 0.3.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +192 -187
- package/dist/bin.js +3 -3
- package/dist/bin.js.map +1 -1
- package/dist/commands/compile.d.ts +1 -0
- package/dist/commands/compile.d.ts.map +1 -1
- package/dist/commands/compile.js +45 -138
- package/dist/commands/compile.js.map +1 -1
- package/dist/commands/create-workflow-wizard.d.ts +4 -25
- package/dist/commands/create-workflow-wizard.d.ts.map +1 -1
- package/dist/commands/create-workflow-wizard.js +46 -222
- package/dist/commands/create-workflow-wizard.js.map +1 -1
- package/dist/commands/create.d.ts +2 -11
- package/dist/commands/create.d.ts.map +1 -1
- package/dist/commands/create.js +78 -477
- package/dist/commands/create.js.map +1 -1
- package/dist/commands/default.d.ts.map +1 -1
- package/dist/commands/default.js +27 -43
- package/dist/commands/default.js.map +1 -1
- package/dist/commands/doctor.js +2 -2
- package/dist/commands/doctor.js.map +1 -1
- package/dist/commands/executor-flow.d.ts +9 -0
- package/dist/commands/executor-flow.d.ts.map +1 -0
- package/dist/commands/executor-flow.js +55 -0
- package/dist/commands/executor-flow.js.map +1 -0
- package/dist/commands/init.d.ts +1 -0
- package/dist/commands/init.d.ts.map +1 -1
- package/dist/commands/init.js +320 -321
- package/dist/commands/init.js.map +1 -1
- package/dist/commands/list.d.ts.map +1 -1
- package/dist/commands/list.js +12 -22
- package/dist/commands/list.js.map +1 -1
- package/dist/commands/reset.d.ts.map +1 -1
- package/dist/commands/reset.js +27 -124
- package/dist/commands/reset.js.map +1 -1
- package/dist/commands/source-config-wizard.d.ts +10 -11
- package/dist/commands/source-config-wizard.d.ts.map +1 -1
- package/dist/commands/source-config-wizard.js +100 -97
- package/dist/commands/source-config-wizard.js.map +1 -1
- package/dist/commands/status.d.ts.map +1 -1
- package/dist/commands/status.js +60 -56
- package/dist/commands/status.js.map +1 -1
- package/dist/commands/test-flow.d.ts +21 -0
- package/dist/commands/test-flow.d.ts.map +1 -0
- package/dist/commands/test-flow.js +106 -0
- package/dist/commands/test-flow.js.map +1 -0
- package/dist/commands/test.d.ts +4 -0
- package/dist/commands/test.d.ts.map +1 -0
- package/dist/commands/test.js +131 -0
- package/dist/commands/test.js.map +1 -0
- package/dist/commands/verify.d.ts.map +1 -1
- package/dist/commands/verify.js +63 -98
- package/dist/commands/verify.js.map +1 -1
- package/dist/commands/workspace-flow.d.ts +21 -0
- package/dist/commands/workspace-flow.d.ts.map +1 -0
- package/dist/commands/workspace-flow.js +90 -0
- package/dist/commands/workspace-flow.js.map +1 -0
- package/dist/index.d.ts +8 -8
- package/dist/index.d.ts.map +1 -1
- package/dist/index.js +5 -7
- package/dist/index.js.map +1 -1
- package/dist/lib/agent-constants.js +1 -1
- package/dist/lib/agent-constants.js.map +1 -1
- package/dist/lib/agent-detection.js +4 -4
- package/dist/lib/agent-detection.js.map +1 -1
- package/dist/lib/agent-skills.js +6 -6
- package/dist/lib/agent-skills.js.map +1 -1
- package/dist/lib/benchmark-execution.d.ts.map +1 -1
- package/dist/lib/benchmark-execution.js +32 -19
- package/dist/lib/benchmark-execution.js.map +1 -1
- package/dist/lib/benchmark-sandbox.d.ts +10 -0
- package/dist/lib/benchmark-sandbox.d.ts.map +1 -0
- package/dist/lib/benchmark-sandbox.js +75 -0
- package/dist/lib/benchmark-sandbox.js.map +1 -0
- package/dist/lib/benchmark-targets.d.ts +4 -4
- package/dist/lib/benchmark-targets.d.ts.map +1 -1
- package/dist/lib/benchmark-targets.js +20 -54
- package/dist/lib/benchmark-targets.js.map +1 -1
- package/dist/lib/benchmark-types.d.ts +2 -3
- package/dist/lib/benchmark-types.d.ts.map +1 -1
- package/dist/lib/benchmark.d.ts +1 -1
- package/dist/lib/benchmark.d.ts.map +1 -1
- package/dist/lib/benchmark.js +1 -1
- package/dist/lib/benchmark.js.map +1 -1
- package/dist/lib/config.d.ts +1 -2
- package/dist/lib/config.d.ts.map +1 -1
- package/dist/lib/config.js +2 -4
- package/dist/lib/config.js.map +1 -1
- package/dist/lib/discovery.d.ts +1 -1
- package/dist/lib/discovery.d.ts.map +1 -1
- package/dist/lib/discovery.js +7 -2
- package/dist/lib/discovery.js.map +1 -1
- package/dist/lib/eval-packs.d.ts +6 -52
- package/dist/lib/eval-packs.d.ts.map +1 -1
- package/dist/lib/eval-packs.js +11 -39
- package/dist/lib/eval-packs.js.map +1 -1
- package/dist/lib/interf-bootstrap.d.ts +3 -5
- package/dist/lib/interf-bootstrap.d.ts.map +1 -1
- package/dist/lib/interf-bootstrap.js +10 -57
- package/dist/lib/interf-bootstrap.js.map +1 -1
- package/dist/lib/interf-detect.d.ts +13 -11
- package/dist/lib/interf-detect.d.ts.map +1 -1
- package/dist/lib/interf-detect.js +59 -45
- package/dist/lib/interf-detect.js.map +1 -1
- package/dist/lib/interf-scaffold.d.ts +2 -5
- package/dist/lib/interf-scaffold.d.ts.map +1 -1
- package/dist/lib/interf-scaffold.js +99 -235
- package/dist/lib/interf-scaffold.js.map +1 -1
- package/dist/lib/interf-workflow-package.d.ts +1 -2
- package/dist/lib/interf-workflow-package.d.ts.map +1 -1
- package/dist/lib/interf-workflow-package.js +99 -90
- package/dist/lib/interf-workflow-package.js.map +1 -1
- package/dist/lib/interf.d.ts +4 -5
- package/dist/lib/interf.d.ts.map +1 -1
- package/dist/lib/interf.js +3 -6
- package/dist/lib/interf.js.map +1 -1
- package/dist/lib/local-workflows.d.ts +9 -8
- package/dist/lib/local-workflows.d.ts.map +1 -1
- package/dist/lib/local-workflows.js +56 -92
- package/dist/lib/local-workflows.js.map +1 -1
- package/dist/lib/obsidian.d.ts +1 -3
- package/dist/lib/obsidian.d.ts.map +1 -1
- package/dist/lib/obsidian.js +10 -81
- package/dist/lib/obsidian.js.map +1 -1
- package/dist/lib/registry.d.ts +6 -17
- package/dist/lib/registry.d.ts.map +1 -1
- package/dist/lib/registry.js +36 -50
- package/dist/lib/registry.js.map +1 -1
- package/dist/lib/runtime-contracts.d.ts +4 -3
- package/dist/lib/runtime-contracts.d.ts.map +1 -1
- package/dist/lib/runtime-contracts.js +125 -9
- package/dist/lib/runtime-contracts.js.map +1 -1
- package/dist/lib/runtime-reconcile.d.ts +3 -5
- package/dist/lib/runtime-reconcile.d.ts.map +1 -1
- package/dist/lib/runtime-reconcile.js +70 -167
- package/dist/lib/runtime-reconcile.js.map +1 -1
- package/dist/lib/runtime-runs.d.ts.map +1 -1
- package/dist/lib/runtime-runs.js +61 -57
- package/dist/lib/runtime-runs.js.map +1 -1
- package/dist/lib/runtime-types.d.ts +16 -6
- package/dist/lib/runtime-types.d.ts.map +1 -1
- package/dist/lib/runtime.d.ts +2 -2
- package/dist/lib/runtime.d.ts.map +1 -1
- package/dist/lib/runtime.js +1 -1
- package/dist/lib/runtime.js.map +1 -1
- package/dist/lib/schema.d.ts +69 -311
- package/dist/lib/schema.d.ts.map +1 -1
- package/dist/lib/schema.js +49 -210
- package/dist/lib/schema.js.map +1 -1
- package/dist/lib/source-config.d.ts +8 -7
- package/dist/lib/source-config.d.ts.map +1 -1
- package/dist/lib/source-config.js +59 -63
- package/dist/lib/source-config.js.map +1 -1
- package/dist/lib/state-artifacts.d.ts +5 -11
- package/dist/lib/state-artifacts.d.ts.map +1 -1
- package/dist/lib/state-artifacts.js +8 -18
- package/dist/lib/state-artifacts.js.map +1 -1
- package/dist/lib/state-health.d.ts +4 -8
- package/dist/lib/state-health.d.ts.map +1 -1
- package/dist/lib/state-health.js +52 -233
- package/dist/lib/state-health.js.map +1 -1
- package/dist/lib/state-io.d.ts +7 -12
- package/dist/lib/state-io.d.ts.map +1 -1
- package/dist/lib/state-io.js +32 -93
- package/dist/lib/state-io.js.map +1 -1
- package/dist/lib/state-view.d.ts +4 -6
- package/dist/lib/state-view.d.ts.map +1 -1
- package/dist/lib/state-view.js +62 -101
- package/dist/lib/state-view.js.map +1 -1
- package/dist/lib/state.d.ts +5 -5
- package/dist/lib/state.d.ts.map +1 -1
- package/dist/lib/state.js +4 -4
- package/dist/lib/state.js.map +1 -1
- package/dist/lib/summarize-plan.d.ts +2 -2
- package/dist/lib/summarize-plan.d.ts.map +1 -1
- package/dist/lib/summarize-plan.js +13 -13
- package/dist/lib/summarize-plan.js.map +1 -1
- package/dist/lib/{validate-kb.d.ts → validate-workspace.d.ts} +49 -8
- package/dist/lib/validate-workspace.d.ts.map +1 -0
- package/dist/lib/validate-workspace.js +398 -0
- package/dist/lib/validate-workspace.js.map +1 -0
- package/dist/lib/validate.d.ts +5 -7
- package/dist/lib/validate.d.ts.map +1 -1
- package/dist/lib/validate.js +22 -20
- package/dist/lib/validate.js.map +1 -1
- package/dist/lib/workflow-definitions.d.ts +14 -50
- package/dist/lib/workflow-definitions.d.ts.map +1 -1
- package/dist/lib/workflow-definitions.js +100 -353
- package/dist/lib/workflow-definitions.js.map +1 -1
- package/dist/lib/workflow-helpers.d.ts +3 -4
- package/dist/lib/workflow-helpers.d.ts.map +1 -1
- package/dist/lib/workflow-helpers.js +17 -49
- package/dist/lib/workflow-helpers.js.map +1 -1
- package/dist/lib/workflow-stage-runner.d.ts +1 -2
- package/dist/lib/workflow-stage-runner.d.ts.map +1 -1
- package/dist/lib/workflow-stage-runner.js +4 -6
- package/dist/lib/workflow-stage-runner.js.map +1 -1
- package/dist/lib/workflow-starter-docs.d.ts +3 -5
- package/dist/lib/workflow-starter-docs.d.ts.map +1 -1
- package/dist/lib/workflow-starter-docs.js +2 -17
- package/dist/lib/workflow-starter-docs.js.map +1 -1
- package/dist/lib/workflows.d.ts +9 -14
- package/dist/lib/workflows.d.ts.map +1 -1
- package/dist/lib/workflows.js +15 -30
- package/dist/lib/workflows.js.map +1 -1
- package/dist/lib/workspace-compile.d.ts +51 -0
- package/dist/lib/workspace-compile.d.ts.map +1 -0
- package/dist/lib/workspace-compile.js +397 -0
- package/dist/lib/workspace-compile.js.map +1 -0
- package/package.json +9 -9
- package/skills/benchmark/SKILL.md +20 -27
- package/skills/workflow/create/SKILL.md +10 -14
- package/skills/workspace/shape/SKILL.md +15 -0
- package/skills/workspace/structure/SKILL.md +15 -0
- package/skills/workspace/summarize/SKILL.md +15 -0
- package/templates/workspace/README.md +23 -0
- package/templates/workspace/interfignore +2 -0
- package/dist/commands/benchmark.d.ts +0 -3
- package/dist/commands/benchmark.d.ts.map +0 -1
- package/dist/commands/benchmark.js +0 -374
- package/dist/commands/benchmark.js.map +0 -1
- package/dist/lib/bundled-templates.d.ts +0 -5
- package/dist/lib/bundled-templates.d.ts.map +0 -1
- package/dist/lib/bundled-templates.js +0 -23
- package/dist/lib/bundled-templates.js.map +0 -1
- package/dist/lib/interf-compile-plan.d.ts +0 -12
- package/dist/lib/interf-compile-plan.d.ts.map +0 -1
- package/dist/lib/interf-compile-plan.js +0 -143
- package/dist/lib/interf-compile-plan.js.map +0 -1
- package/dist/lib/validate-interface.d.ts +0 -79
- package/dist/lib/validate-interface.d.ts.map +0 -1
- package/dist/lib/validate-interface.js +0 -535
- package/dist/lib/validate-interface.js.map +0 -1
- package/dist/lib/validate-kb.d.ts.map +0 -1
- package/dist/lib/validate-kb.js +0 -252
- package/dist/lib/validate-kb.js.map +0 -1
- package/dist/lib/workflows-interface-contracts.d.ts +0 -24
- package/dist/lib/workflows-interface-contracts.d.ts.map +0 -1
- package/dist/lib/workflows-interface-contracts.js +0 -304
- package/dist/lib/workflows-interface-contracts.js.map +0 -1
- package/dist/lib/workflows-interface.d.ts +0 -72
- package/dist/lib/workflows-interface.d.ts.map +0 -1
- package/dist/lib/workflows-interface.js +0 -377
- package/dist/lib/workflows-interface.js.map +0 -1
- package/dist/lib/workflows-kb.d.ts +0 -50
- package/dist/lib/workflows-kb.d.ts.map +0 -1
- package/dist/lib/workflows-kb.js +0 -306
- package/dist/lib/workflows-kb.js.map +0 -1
- package/skills/interface/analyze/SKILL.md +0 -191
- package/skills/interface/compile/SKILL.md +0 -152
- package/skills/interface/compile/references/output-format.md +0 -48
- package/skills/interface/create/SKILL.md +0 -87
- package/skills/interface/create/references/compile-plan-format.md +0 -109
- package/skills/interface/create/references/workflows.md +0 -35
- package/skills/interface/query/SKILL.md +0 -48
- package/skills/interface/retrieve/SKILL.md +0 -133
- package/skills/knowledge-base/compile/SKILL.md +0 -196
- package/skills/knowledge-base/compile/references/output-format.md +0 -48
- package/skills/knowledge-base/compile/references/stage-claims.md +0 -60
- package/skills/knowledge-base/compile/references/stage-entities.md +0 -46
- package/skills/knowledge-base/query/SKILL.md +0 -45
- package/skills/knowledge-base/summarize/SKILL.md +0 -152
- package/templates/interface/README.md +0 -159
- package/templates/interface/interfaces.md +0 -102
- package/templates/knowledge-base/README.md +0 -137
- package/templates/knowledge-base/interfignore +0 -19
- package/templates/knowledge-base/registry.md +0 -118
- package/templates/workflow-package/README.md +0 -16
- package/templates/workflow-package/create/SKILL.md +0 -8
- package/templates/workflow-package/interface-query/SKILL.md +0 -29
- package/templates/workflow-package/interface-stage/SKILL.md +0 -13
- package/templates/workflow-package/knowledge-base-query/SKILL.md +0 -36
- package/templates/workflow-package/knowledge-base-stage/SKILL.md +0 -13
- package/templates/workflow-starters/interface/interf/README.md +0 -13
- package/templates/workflow-starters/interface/interf/create/SKILL.md +0 -15
- package/templates/workflow-starters/knowledge-base/interf/README.md +0 -13
- package/templates/workflow-starters/knowledge-base/karpathy/README.md +0 -13
|
@@ -1,152 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
{
|
|
3
|
-
"name": "interface/compile",
|
|
4
|
-
"description": "Interface output contract. Creates or updates local output files from the analysis. Writes knowledge/, briefs/, and home.md with evidence-linked notes. Use when asked to compile outputs, create notes, or run an output stage inside interface compile."
|
|
5
|
-
}
|
|
6
|
-
---
|
|
7
|
-
|
|
8
|
-
# Interface Compile — Output
|
|
9
|
-
|
|
10
|
-
Read `interf.json` for output definitions and `compile-plan.md` Stage 3 for output specs.
|
|
11
|
-
|
|
12
|
-
Local runtime reference:
|
|
13
|
-
- active stage contract: `.interf/stage-contract.json`
|
|
14
|
-
- active run ledger: `.interf/run.json`
|
|
15
|
-
- local config: `interf.json`
|
|
16
|
-
- local plan: `compile-plan.md`
|
|
17
|
-
- local instruction docs: the files listed by `.interf/stage-contract.json`
|
|
18
|
-
|
|
19
|
-
When this skill is embedded into a generated interface, do not try to open SDK repo docs or source files outside the current workspace. The local contract and local docs are the source of truth for this run.
|
|
20
|
-
|
|
21
|
-
This skill creates the actual files that make the interface queryable. All outputs are LOCAL — do not write to the knowledge base. The interface should become a local context shell that future agents can enter and navigate easily.
|
|
22
|
-
If `../../.interf/source-access.json` exists, use it as the quick check for whether raw paths are actually reachable from this session before assuming raw fallback will work.
|
|
23
|
-
If local docs are listed by the stage contract, read them before compiling. They may `extend` or `override` the bundled workflow instructions for this stage, but they do not bypass coverage proof or the stage contract.
|
|
24
|
-
|
|
25
|
-
Harness role:
|
|
26
|
-
- This skill is an internal harness step normally invoked by `interf compile` from inside an interface.
|
|
27
|
-
- For standard operation, prefer the CLI or another higher-level tool over calling this skill directly.
|
|
28
|
-
|
|
29
|
-
## Runtime contract
|
|
30
|
-
|
|
31
|
-
When invoked by the CLI, honor any explicit execution instructions in the prompt. In particular:
|
|
32
|
-
- if `.interf/stage-contract.json` exists, treat it as the authoritative stage contract for this run
|
|
33
|
-
- if the prompt gives a retrieved set size, use it for progress framing
|
|
34
|
-
- do not create or edit `.interf/view-spec.json`; the CLI refreshes it after stage completion
|
|
35
|
-
- only emit user-facing lines that start with `STATUS:`, `DONE:`, `BLOCKED:`, or `ERROR:`
|
|
36
|
-
- the CLI reconciles `.interf/state.json`, refreshes `.interf/health.json`, and refreshes `.interf/view-spec.json` after validation; do not treat those files as stage-owned write targets for compile
|
|
37
|
-
|
|
38
|
-
## Prerequisites
|
|
39
|
-
|
|
40
|
-
If `.interf/analysis.json` is missing or unreadable: emit `BLOCKED: missing analysis handoff (.interf/analysis.json)` and stop.
|
|
41
|
-
|
|
42
|
-
Before compiling, prefer running:
|
|
43
|
-
|
|
44
|
-
```bash
|
|
45
|
-
interf verify retrieve --json
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
If it fails, stop and fix the retrieval proof instead of continuing.
|
|
49
|
-
|
|
50
|
-
Read `.interf/analysis.json` for the extracted entities, claims, and relationships from the preceding analysis stage.
|
|
51
|
-
|
|
52
|
-
## Steps
|
|
53
|
-
|
|
54
|
-
```
|
|
55
|
-
Compile:
|
|
56
|
-
- [ ] 1. Read analysis results and output spec
|
|
57
|
-
- [ ] 2. Compile entities
|
|
58
|
-
- [ ] 3. Compile claims
|
|
59
|
-
- [ ] 4. Compile interface-specific outputs
|
|
60
|
-
- [ ] 5. Compile navigation
|
|
61
|
-
- [ ] 6. Validate
|
|
62
|
-
- [ ] 7. Clean up
|
|
63
|
-
```
|
|
64
|
-
|
|
65
|
-
### 1. Read analysis results and output spec
|
|
66
|
-
|
|
67
|
-
- `.interf/analysis.json` → extracted entities, claims, relationships, runtime refinements
|
|
68
|
-
- `compile-plan.md` → this stage's section: what files to create, in what format
|
|
69
|
-
- Existing `knowledge/` → what already exists (for delta: update, don't recreate)
|
|
70
|
-
- `../../.interf/source-access.json` → sample raw paths and suggested access checks when raw fallback is needed
|
|
71
|
-
- local instruction docs listed by the stage contract
|
|
72
|
-
- if the plan asked for exact values from PDFs, charts, or tables, check whether `.interf/analysis.json` includes a raw extraction ledger or equivalent method notes before treating approximations as closed findings
|
|
73
|
-
|
|
74
|
-
### 2. Compile entities
|
|
75
|
-
|
|
76
|
-
Create/update `knowledge/entities/` notes. Each entity gets:
|
|
77
|
-
- Summary, evidence links, related entities
|
|
78
|
-
- Properties for filtering (entity_type, status, confidence)
|
|
79
|
-
- Tags for Obsidian surfacing
|
|
80
|
-
- Clear wikilinks back to supporting parent summaries so an agent can move entity -> evidence -> source trail without guessing
|
|
81
|
-
|
|
82
|
-
### 3. Compile claims
|
|
83
|
-
|
|
84
|
-
Create/update `knowledge/claims/` notes. Prose-as-title: filename IS the claim.
|
|
85
|
-
- The claim, why it matters, evidence links
|
|
86
|
-
- 2+ sources required for broad synthesis work
|
|
87
|
-
- single-source claims are allowed for bounded audit or extraction workflows when provenance includes source path/page, extraction method, and precision (`exact`, `approximate`, or `unresolved`)
|
|
88
|
-
- Link claims to related entities, briefs, and parent summaries so backlinks become a real navigation surface
|
|
89
|
-
|
|
90
|
-
### 4. Compile interface-specific outputs
|
|
91
|
-
|
|
92
|
-
From `compile-plan.md`: create whatever this output stage defines.
|
|
93
|
-
- Treat `compile-plan.md` Stage 3 as the output contract. Follow the exact filenames and folders named there.
|
|
94
|
-
- briefs/ hero documents
|
|
95
|
-
- summaries/ interface-local temporal views when needed
|
|
96
|
-
- Any other outputs defined in the compile plan
|
|
97
|
-
- if this is a bounded audit, prefer one focused hero brief plus the smallest supporting note set that makes the target answers easy to retrieve
|
|
98
|
-
- do not mirror the whole parent report into the interface unless the compile plan explicitly asks for full-report coverage
|
|
99
|
-
- if the plan includes a target ledger, the hero brief must cover every requested target explicitly and unresolved targets must stay unresolved instead of being replaced by nearby exact figures
|
|
100
|
-
- Preserve `value_display`, `bin_choice`, `precision`, `source_kind`, and page metadata from `.interf/analysis.json`. Compile is a render pass, not a second chart-reading pass.
|
|
101
|
-
- If an approximate chart-derived target includes both `value_display` and `bin_choice`, prefer the conservative answer-grade value for the main hero surface unless the notes explicitly justify a finer display. Keep extra granularity in supporting prose, `scale_band`, or notes rather than upgrading the main answer.
|
|
102
|
-
- Do not invent fixed hero-brief filenames or generic claim-folder patterns unless the compile plan explicitly asks for them.
|
|
103
|
-
|
|
104
|
-
For delta compiles: update existing files surgically. Do NOT regenerate everything.
|
|
105
|
-
|
|
106
|
-
When a local output cites evidence from the main knowledge base, use the parent knowledge-base summary path (`../../summaries/...`). Do not point `source:` or evidence links at the interface-local `summaries/` folder unless that interface actually created the cited file.
|
|
107
|
-
When an output depends on exact numbers from PDFs, tables, or charts, say whether the value was text-derived, table-derived, or chart-derived. Do not present chart-extracted values as if they were already explicit in the compiled summaries.
|
|
108
|
-
Do not write `data unavailable` or `gap` when the real state is `not yet extracted from the raw source`.
|
|
109
|
-
If the analysis only opened raw pages but did not log a machine-readable extraction attempt for an exact-value task, keep the result unresolved instead of upgrading it to a verified finding.
|
|
110
|
-
If the analysis logged anchor cross-checks with material drift, keep the finding approximate or unresolved instead of presenting it as settled.
|
|
111
|
-
If the question asked for exact values and you only recovered a visual estimate, say `approximate` explicitly and keep the remaining precision gap in the output.
|
|
112
|
-
Do not substitute a requested `annual`, `quarterly`, `trailing-12-month`, `availability`, `take-up`, or similar target with another metric or period just because the substitute is exact and easier to quote.
|
|
113
|
-
|
|
114
|
-
### 5. Compile navigation
|
|
115
|
-
|
|
116
|
-
- `home.md` — links to all key outputs, counts, last compile
|
|
117
|
-
- `knowledge/indexes/` or equivalent local maps when the interface needs better navigation
|
|
118
|
-
- make the order of use obvious: AGENTS.md -> home.md -> local knowledge/briefs/summaries -> knowledge-base summaries -> raw if needed
|
|
119
|
-
- make upward navigation obvious too: local outputs should link out to parent summaries so an agent can follow backlinks and climb toward stronger evidence
|
|
120
|
-
- if Obsidian is mentioned, assume the interface is being browsed from the parent knowledge-base vault rather than as a standalone vault
|
|
121
|
-
- Update every compile run
|
|
122
|
-
|
|
123
|
-
### 6. Runtime reconciliation
|
|
124
|
-
|
|
125
|
-
Do not reset retrieve/analyze coverage markers manually. The CLI reconciles `.interf/state.json`, refreshes `.interf/health.json`, and refreshes `.interf/view-spec.json` after stage validation so viewers keep a stable presentation contract.
|
|
126
|
-
|
|
127
|
-
### 7. Validate
|
|
128
|
-
|
|
129
|
-
- [ ] All outputs from compile-plan.md exist and are non-empty
|
|
130
|
-
- [ ] Entity notes have evidence links
|
|
131
|
-
- [ ] Claims meet the workflow provenance rule: either 2+ sources or a bounded-audit single-source record with explicit provenance
|
|
132
|
-
- [ ] No broken wikilinks
|
|
133
|
-
- [ ] home.md is current
|
|
134
|
-
|
|
135
|
-
### 8. Clean up
|
|
136
|
-
|
|
137
|
-
Delete `.interf/analysis.json` — it was temporary between stages.
|
|
138
|
-
|
|
139
|
-
Report with status-style lines:
|
|
140
|
-
```
|
|
141
|
-
STATUS: loaded compile plan N relevant files.
|
|
142
|
-
STATUS: wrote entities E
|
|
143
|
-
STATUS: wrote claims C
|
|
144
|
-
STATUS: wrote interface outputs
|
|
145
|
-
DONE: compile complete
|
|
146
|
-
```
|
|
147
|
-
|
|
148
|
-
When the required outputs are written, emit the required `DONE:` line and stop. The CLI reconciles `.interf/state.json` and refreshes `.interf/health.json` after validation. Do not keep exploring after the compile contract is satisfied.
|
|
149
|
-
|
|
150
|
-
## Key principle
|
|
151
|
-
|
|
152
|
-
**Local outputs only.** Everything this skill creates lives in this interface. The connected knowledge base (at `knowledge_base.path`) is read-only. The interface graph is distilled and focused, not a mirror of the knowledge base. The goal is to make future agent navigation easier, not just to dump another layer of summaries.
|
|
@@ -1,48 +0,0 @@
|
|
|
1
|
-
# Output Format Guide
|
|
2
|
-
|
|
3
|
-
All outputs are plain markdown. They work standalone for any agent and render well in Obsidian. Obsidian is supported but not required.
|
|
4
|
-
|
|
5
|
-
## Properties (JSON frontmatter)
|
|
6
|
-
|
|
7
|
-
Use Obsidian-compatible properties for filtering:
|
|
8
|
-
|
|
9
|
-
```md
|
|
10
|
-
---
|
|
11
|
-
{
|
|
12
|
-
"entity_type": "person",
|
|
13
|
-
"status": "active",
|
|
14
|
-
"confidence": "high",
|
|
15
|
-
"tags": ["type/entity", "entity/person"]
|
|
16
|
-
}
|
|
17
|
-
---
|
|
18
|
-
```
|
|
19
|
-
|
|
20
|
-
Properties = machine filtering. Tags = human browsing.
|
|
21
|
-
|
|
22
|
-
## Wikilinks
|
|
23
|
-
|
|
24
|
-
Use `[[wikilinks]]` for all internal references. Never raw file paths.
|
|
25
|
-
|
|
26
|
-
## Wiki-link-as-prose
|
|
27
|
-
|
|
28
|
-
Links read as sentences:
|
|
29
|
-
> This note is where [[readiness assessment language first appears in the knowledge base]]
|
|
30
|
-
|
|
31
|
-
## home.md
|
|
32
|
-
|
|
33
|
-
Entry point. Links to key sections, current counts, last compile date. Update every compile.
|
|
34
|
-
|
|
35
|
-
## .base files
|
|
36
|
-
|
|
37
|
-
Optional Obsidian-specific JSON files for filterable table/card views. The interface works without them.
|
|
38
|
-
|
|
39
|
-
## Graph optimization
|
|
40
|
-
|
|
41
|
-
- Wikilinks consistently (every link = edge)
|
|
42
|
-
- One canonical note per entity (no duplicates)
|
|
43
|
-
- Home.md and indexes as high-connectivity hubs
|
|
44
|
-
- Tags for color-coding in graph view
|
|
45
|
-
|
|
46
|
-
## Independence
|
|
47
|
-
|
|
48
|
-
Everything works without Obsidian. Wikilinks are `[[plain text]]`. Properties use JSON frontmatter. Tags are strings. Any agent can read the files directly.
|
|
@@ -1,87 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
{
|
|
3
|
-
"name": "interface/create",
|
|
4
|
-
"description": "Create a new Interf interface. Analyzes a knowledge base to generate an interf.json config and execution plan (compile-plan.md). Use when asked to create an interface, new interface, or build a task-specific view."
|
|
5
|
-
}
|
|
6
|
-
---
|
|
7
|
-
|
|
8
|
-
# Create Interface
|
|
9
|
-
|
|
10
|
-
This stage drafts the initial interface runtime hypothesis from the parent knowledge base.
|
|
11
|
-
|
|
12
|
-
## Stage role
|
|
13
|
-
|
|
14
|
-
- planning only
|
|
15
|
-
- no raw-source inspection
|
|
16
|
-
- no chart/table extraction
|
|
17
|
-
- no registry edits
|
|
18
|
-
|
|
19
|
-
Read `.interf/stage-contract.json` first and treat it as authoritative.
|
|
20
|
-
|
|
21
|
-
## Minimal completion target
|
|
22
|
-
|
|
23
|
-
For automated runs, the primary deliverable is a correct `compile-plan.md`.
|
|
24
|
-
|
|
25
|
-
- If scaffolded `interf.json` already matches the stage contract, leave it unchanged.
|
|
26
|
-
- If scaffolded `AGENTS.md` already preserves the router, checklist, and parent handoff, leave it unchanged.
|
|
27
|
-
- Do not spend the run rewriting scaffold files that already validate.
|
|
28
|
-
- After the knowledge-base review, the next action should usually be to rewrite `compile-plan.md` in one full write and stop.
|
|
29
|
-
|
|
30
|
-
## Bounded analysis
|
|
31
|
-
|
|
32
|
-
Build the plan from the parent knowledge-base surface only:
|
|
33
|
-
|
|
34
|
-
- `../../home.md`
|
|
35
|
-
- `../../knowledge/`
|
|
36
|
-
- `../../summaries/`
|
|
37
|
-
|
|
38
|
-
Read only enough to plan the interface:
|
|
39
|
-
|
|
40
|
-
- the primary summary or summaries that anchor the task
|
|
41
|
-
- the highest-signal parent knowledge notes that clarify scope
|
|
42
|
-
- the local scaffold files you may update
|
|
43
|
-
|
|
44
|
-
Do not widen into broad research. If later stages need raw/chart work, encode that in `compile-plan.md` and leave the actual extraction to retrieve/analyze.
|
|
45
|
-
|
|
46
|
-
## Plan requirements
|
|
47
|
-
|
|
48
|
-
`compile-plan.md` must:
|
|
49
|
-
|
|
50
|
-
- preserve the exact requested use case line in `## Interface Goal`
|
|
51
|
-
- keep the existing workflow stage headings and required subsection labels
|
|
52
|
-
- translate the task into a concrete target ledger when the task names specific values, periods, entities, metrics, units, or chart/table families
|
|
53
|
-
- keep different time cuts and metric families separate, and say when later stages must inspect raw visuals
|
|
54
|
-
- require a concrete local extraction path plus exact/approximate/unresolved labeling when precision matters
|
|
55
|
-
- require a durable output surface, usually one focused hero brief for bounded audits
|
|
56
|
-
|
|
57
|
-
## AGENTS handling
|
|
58
|
-
|
|
59
|
-
`AGENTS.md` is a scaffold router for later agents, not the main output of this stage.
|
|
60
|
-
|
|
61
|
-
- Preserve the scaffold router and checklist.
|
|
62
|
-
- preserve the `## Manual access checklist`, raw-source gate, and parent knowledge-base handoff
|
|
63
|
-
- preserve the router to `workflow/use/query/` and later compile-stage docs
|
|
64
|
-
- do not execute those instructions during create
|
|
65
|
-
- only rewrite `AGENTS.md` if the existing scaffold is materially wrong for this interface
|
|
66
|
-
|
|
67
|
-
## Finish rule
|
|
68
|
-
|
|
69
|
-
Once `compile-plan.md` is correct and the scaffold still validates:
|
|
70
|
-
|
|
71
|
-
1. update `interf.json` only if needed
|
|
72
|
-
2. update `AGENTS.md` only if needed
|
|
73
|
-
3. emit the required status lines
|
|
74
|
-
4. stop
|
|
75
|
-
|
|
76
|
-
Do not keep researching after the durable plan is written.
|
|
77
|
-
|
|
78
|
-
## Status contract
|
|
79
|
-
|
|
80
|
-
For automated runs, these canonical `STATUS:` lines are mandatory and must appear verbatim on their own lines:
|
|
81
|
-
|
|
82
|
-
- `STATUS: loaded interface creation contract.`
|
|
83
|
-
- `STATUS: analyzed knowledge-base.`
|
|
84
|
-
- `STATUS: wrote compile plan.`
|
|
85
|
-
|
|
86
|
-
You may emit `DONE: interface create complete.` as a final progress line, but the CLI validates completion from the scaffold files rather than trusting that line.
|
|
87
|
-
Additional `STATUS:` lines are allowed between them, but do not replace or rewrite these canonical markers.
|
|
@@ -1,109 +0,0 @@
|
|
|
1
|
-
# Interface Compile Plan Format
|
|
2
|
-
|
|
3
|
-
When creating an interface, generate a `compile-plan.md` that follows the selected workflow's stage graph. The examples below show the built-in `Retrieve -> Analyze -> Compile` shape. For custom workflows, repeat the same section pattern for each workflow-defined stage label and contract type. This file lives in the interface root and is git-tracked.
|
|
4
|
-
|
|
5
|
-
## Format
|
|
6
|
-
|
|
7
|
-
```markdown
|
|
8
|
-
# {Interface Name} — Compile Plan
|
|
9
|
-
|
|
10
|
-
## Stage 1: Retrieve
|
|
11
|
-
|
|
12
|
-
Filter criteria for knowledge-base summaries/:
|
|
13
|
-
- Categories: {list of relevant categories}
|
|
14
|
-
- Priority evidence tiers: {which source/evidence tiers matter most}
|
|
15
|
-
- Truth modes to prioritize or downweight: {fact vs proposal vs brainstorm etc.}
|
|
16
|
-
- Key entities: {people/companies to prioritize}
|
|
17
|
-
- Date range: {if relevant}
|
|
18
|
-
|
|
19
|
-
Expected relevant file count: ~{estimate}
|
|
20
|
-
Coverage loop:
|
|
21
|
-
- scan all summary frontmatter
|
|
22
|
-
- read abstracts for every candidate file
|
|
23
|
-
- expand through links until the selected set is stable
|
|
24
|
-
- persist selected and rejected files with reasons
|
|
25
|
-
|
|
26
|
-
## Stage 2: Analyze
|
|
27
|
-
|
|
28
|
-
For each relevant summary, extract:
|
|
29
|
-
- {entity type 1}: {what to look for}
|
|
30
|
-
- {entity type 2}: {what to look for}
|
|
31
|
-
- Claims: {what patterns/decisions/risks to detect}
|
|
32
|
-
- Runtime refinements: {when to add missing ontology/taxonomy/relationship structure}
|
|
33
|
-
|
|
34
|
-
Working-set budget: ~{fraction or token budget} of model context window per batch.
|
|
35
|
-
Subagent instruction: "{what each subagent should return}"
|
|
36
|
-
|
|
37
|
-
## Stage 3: Compile
|
|
38
|
-
|
|
39
|
-
Output files to create/update:
|
|
40
|
-
|
|
41
|
-
### {Output 1, e.g., briefs/Company.md}
|
|
42
|
-
Purpose: {what question this answers}
|
|
43
|
-
Sections: {structure}
|
|
44
|
-
Evidence: {what sources to cite}
|
|
45
|
-
|
|
46
|
-
### {Output 2, e.g., knowledge/entities/*.md}
|
|
47
|
-
{same format}
|
|
48
|
-
|
|
49
|
-
### home.md
|
|
50
|
-
Links to: {key outputs}
|
|
51
|
-
Status: {counts, last compile}
|
|
52
|
-
Agent navigation: {how an agent should move from AGENTS.md into the rest of this interface}
|
|
53
|
-
```
|
|
54
|
-
|
|
55
|
-
## Example: Task-Specific interface
|
|
56
|
-
|
|
57
|
-
```markdown
|
|
58
|
-
# {Interface Name} — Compile Plan
|
|
59
|
-
|
|
60
|
-
## Stage 1: Retrieve
|
|
61
|
-
|
|
62
|
-
Filter criteria for knowledge-base summaries/:
|
|
63
|
-
- Categories: {documents, notes, datasets, reports, experiments, or other relevant categories}
|
|
64
|
-
- Priority evidence tiers: {which evidence tiers matter most for this task}
|
|
65
|
-
- Truth modes to prioritize or downweight: {which truth modes to favor or downweight}
|
|
66
|
-
- Key entities: {entities, systems, products, markets, or themes to prioritize}
|
|
67
|
-
- Date range: {all time, a recent window, or another task-specific cutoff}
|
|
68
|
-
|
|
69
|
-
Expected relevant file count: ~{estimate} of {knowledge_base_summary_total}
|
|
70
|
-
Coverage loop:
|
|
71
|
-
- scan all {knowledge_base_summary_total} summary frontmatter blocks
|
|
72
|
-
- read abstracts for the full candidate set
|
|
73
|
-
- follow adjacency links for the relevant clusters until retrieval closure
|
|
74
|
-
- persist selected and rejected files with reasons in coverage proof
|
|
75
|
-
|
|
76
|
-
## Stage 2: Analyze
|
|
77
|
-
|
|
78
|
-
For each relevant summary, extract:
|
|
79
|
-
- {Entity type 1}: {what to extract}
|
|
80
|
-
- {Entity type 2}: {what to extract}
|
|
81
|
-
- Claims: {what is being asserted and with what level of support}
|
|
82
|
-
- Contradictions: {what disagreements matter}
|
|
83
|
-
- Open questions: {what remains unresolved}
|
|
84
|
-
- Runtime refinements: {what missing structure to add when evidence supports it}
|
|
85
|
-
|
|
86
|
-
Working-set budget: ~{fraction} of model context window per batch.
|
|
87
|
-
Subagent instruction: "{what each subagent should extract and return}"
|
|
88
|
-
|
|
89
|
-
## Stage 3: Compile
|
|
90
|
-
|
|
91
|
-
### briefs/{Primary Brief}.md
|
|
92
|
-
Purpose: "{what question this brief answers}"
|
|
93
|
-
Sections: {section structure}
|
|
94
|
-
Evidence: {what evidence to prefer}
|
|
95
|
-
|
|
96
|
-
### briefs/{Secondary Brief}.md
|
|
97
|
-
Purpose: "{what this note clarifies}"
|
|
98
|
-
Sections: {section structure}
|
|
99
|
-
Evidence: {what evidence to cite}
|
|
100
|
-
|
|
101
|
-
### briefs/{Follow-up Brief}.md
|
|
102
|
-
Purpose: "{what should be checked next}"
|
|
103
|
-
Sections: {section structure}
|
|
104
|
-
Evidence: {how to link back to gaps or follow-up needs}
|
|
105
|
-
|
|
106
|
-
### home.md
|
|
107
|
-
Links to: {key briefs and local outputs}
|
|
108
|
-
Agent navigation: AGENTS.md -> home.md -> briefs/ -> knowledge/ -> knowledge-base summaries
|
|
109
|
-
```
|
|
@@ -1,35 +0,0 @@
|
|
|
1
|
-
# Interface Workflows
|
|
2
|
-
|
|
3
|
-
Interf now ships one built-in interface workflow: `interf`.
|
|
4
|
-
|
|
5
|
-
Use it as the default task-specific method on top of a knowledge base. If you need a different bias, create a reusable local workflow under `interf/workflows/interface/` and benchmark it.
|
|
6
|
-
|
|
7
|
-
## interf
|
|
8
|
-
|
|
9
|
-
Task-specific evidence distillation. Best when the agent needs a bounded workspace that:
|
|
10
|
-
- proves what was scanned and selected
|
|
11
|
-
- preserves the exact task nouns the user cares about
|
|
12
|
-
- compiles minimal answer-ready artifacts for later retrieval
|
|
13
|
-
|
|
14
|
-
**Questions it answers:**
|
|
15
|
-
- What exactly is this interface trying to help an agent do?
|
|
16
|
-
- Which entities, periods, metrics, comparators, or source families matter?
|
|
17
|
-
- What compiled brief or notes should a weaker model rely on instead of rediscovering the raw data?
|
|
18
|
-
|
|
19
|
-
**Default bias:**
|
|
20
|
-
- narrow retrieval to the requested task before widening scope
|
|
21
|
-
- turn the request into a target ledger when the task is bounded
|
|
22
|
-
- preserve time periods, units, metric families, and provenance
|
|
23
|
-
- when exact values matter, inspect the raw source and classify the result as text-derived, table-derived, or chart-derived
|
|
24
|
-
- compile one concise hero brief plus the minimum supporting notes needed for reliable retrieval
|
|
25
|
-
|
|
26
|
-
## Create new workflow
|
|
27
|
-
|
|
28
|
-
Create a reusable local interface workflow when the built-in `interf` method is not enough.
|
|
29
|
-
|
|
30
|
-
The wizard asks:
|
|
31
|
-
1. What questions should this interface answer?
|
|
32
|
-
2. What categories or entities matter?
|
|
33
|
-
3. What output documents should it maintain?
|
|
34
|
-
|
|
35
|
-
Then it saves a named local workflow under `interf/workflows/interface/` and generates `interf.json` plus `compile-plan.md` from knowledge-base analysis.
|
|
@@ -1,48 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
{
|
|
3
|
-
"name": "interface/query",
|
|
4
|
-
"description": "Manual-use skill for answering questions from inside an interface. Navigates AGENTS.md, home.md, local knowledge/briefs/summaries, parent knowledge-base summaries, backlinks, and raw sources only when reachable. Use when a user opens an agent inside an interface and asks questions against it."
|
|
5
|
-
}
|
|
6
|
-
---
|
|
7
|
-
|
|
8
|
-
# Interface Query
|
|
9
|
-
|
|
10
|
-
Use this skill in manual agent sessions inside a compiled interface.
|
|
11
|
-
|
|
12
|
-
Start with:
|
|
13
|
-
- `AGENTS.md`
|
|
14
|
-
- `home.md`
|
|
15
|
-
- local `knowledge/`
|
|
16
|
-
- `briefs/`
|
|
17
|
-
- local `summaries/`
|
|
18
|
-
|
|
19
|
-
Default loop:
|
|
20
|
-
- answer from local interface outputs first
|
|
21
|
-
- follow wikilinks and backlinks outward before treating one note as complete
|
|
22
|
-
- climb to parent knowledge-base summaries in `../../summaries/` when you need stronger evidence
|
|
23
|
-
- use raw source files only when needed for verification, direct quotes, ambiguity, or missing context
|
|
24
|
-
- if the user asks for exact chart or table values from a named report, use local outputs only to locate the source and relevant pages, then go straight to the raw PDF and a concrete local extraction path
|
|
25
|
-
- when a caller asks for a trace, audit log, or `artifacts_consulted` list, record local `workflow/use/query/SKILL.md` after you inspect it
|
|
26
|
-
- when you climb to the parent knowledge-base query loop, record `../../workflow/use/query/SKILL.md` after you inspect it
|
|
27
|
-
|
|
28
|
-
Raw-source gate:
|
|
29
|
-
- inspect `../../.interf/source-access.json`
|
|
30
|
-
- actually open and inspect at least one `suggested_checks` path before claiming raw-file verification; a plain existence check is not enough
|
|
31
|
-
- when a caller asks for a trace, audit log, or `artifacts_consulted` list, record `../../.interf/source-access.json` after you inspect it
|
|
32
|
-
- if the path is not reachable or permission is not granted, say the answer is based on interface and parent knowledge-base artifacts only
|
|
33
|
-
- when the question depends on exact figures, direct quotes, chart values, table values, or image-derived evidence, raw inspection is required before answering confidently
|
|
34
|
-
|
|
35
|
-
PDF / chart rule:
|
|
36
|
-
- if the parent source is a PDF, deck, or report and the needed evidence may live in charts, tables, or figures, do not assume the default text layer or existing notes captured everything
|
|
37
|
-
- if local outputs and parent summaries do not preserve the needed numeric detail, inspect the raw source and say whether the value was text-derived, table-derived, or chart-derived
|
|
38
|
-
- opening the PDF with `Read` is not enough for an exact-value chart question; you must take a machine-readable extraction path before answering
|
|
39
|
-
- if the first local extraction method misses the number, continue down another local recovery path instead of settling early for a visual estimate
|
|
40
|
-
- if the default local extraction path still cannot reach the value, switch methods before stopping early; a temporary scratch helper outside the workspace is allowed when needed
|
|
41
|
-
- if the chart does not expose exact numbers as text, say that clearly instead of pretending the interface already captured them
|
|
42
|
-
- if you can only estimate from the chart after exhausting the local extraction path, label the answer `approximate` and keep the precision gap explicit
|
|
43
|
-
|
|
44
|
-
When confidence is low:
|
|
45
|
-
- expand outward through linked briefs, claims, entities, and parent summaries
|
|
46
|
-
- do not stop at the first local note if linked evidence exists above it
|
|
47
|
-
|
|
48
|
-
This skill is for manual question-answering behavior. It does not change retrieve, analyze, or compile runtime contracts.
|
|
@@ -1,133 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
{
|
|
3
|
-
"name": "interface/retrieve",
|
|
4
|
-
"description": "Interface retrieval contract. Identifies relevant files from the connected knowledge base. Scans knowledge-base summaries metadata, applies filters from compile-plan.md, computes delta since last compile. Use when asked to retrieve from the knowledge base, find relevant files, or run a retrieval stage inside interface compile."
|
|
5
|
-
}
|
|
6
|
-
---
|
|
7
|
-
|
|
8
|
-
# Interface Compile — Retrieve
|
|
9
|
-
|
|
10
|
-
Read `interf.json` (must have `type: interface`) and `compile-plan.md` for filter criteria.
|
|
11
|
-
|
|
12
|
-
Local runtime reference:
|
|
13
|
-
- active stage contract: `.interf/stage-contract.json`
|
|
14
|
-
- active run ledger: `.interf/run.json`
|
|
15
|
-
- local config: `interf.json`
|
|
16
|
-
- local plan: `compile-plan.md`
|
|
17
|
-
- local instruction docs: the files listed by `.interf/stage-contract.json`
|
|
18
|
-
|
|
19
|
-
When this skill is embedded into a generated interface, do not try to open SDK repo docs or source files outside the current workspace. The local contract and local docs are the source of truth for this run.
|
|
20
|
-
|
|
21
|
-
This skill identifies which files in the knowledge base are relevant to this interface and which are new since last compile.
|
|
22
|
-
|
|
23
|
-
Retrieve is coverage-gated. The goal is not to guess a relevant set quickly. The goal is to prove that the routing layer scanned the full summary set, reviewed the candidate abstracts, and persisted both selected and rejected files before analysis begins.
|
|
24
|
-
The runtime in `compile-plan.md` is an initial hypothesis. Retrieve may discover missing entities, categories, or relationship clusters that should shape later interface refinement.
|
|
25
|
-
|
|
26
|
-
Important proof semantics:
|
|
27
|
-
- `proof.scanned` is the full summary set scanned at the frontmatter-routing layer
|
|
28
|
-
- `proof.reviewed` is the narrower candidate set whose abstracts were reviewed
|
|
29
|
-
- `proof.retrieved` plus `proof.excluded` should partition the scanned summary set
|
|
30
|
-
|
|
31
|
-
The knowledge base is located at `knowledge_base.path` from `interf.json` (typically `../..`). Knowledge-base summaries are at `{knowledge_base.path}/summaries/`.
|
|
32
|
-
If a coding agent is sandboxed to its current working tree, prefer launching it from the source folder or another root that can reach both the knowledge base and the source folder.
|
|
33
|
-
If `../../.interf/source-access.json` exists, use it as the quick check for whether raw paths are actually reachable from this session before assuming raw fallback will work.
|
|
34
|
-
If local docs are listed by the stage contract, read them before retrieving. They may `extend` or `override` the bundled workflow instructions for this stage, but they do not bypass coverage proof or the stage contract.
|
|
35
|
-
|
|
36
|
-
Harness role:
|
|
37
|
-
- This skill is an internal harness step normally invoked by `interf compile` from inside an interface.
|
|
38
|
-
- For standard operation, prefer the CLI or another higher-level tool over calling this skill directly.
|
|
39
|
-
|
|
40
|
-
## Runtime contract
|
|
41
|
-
|
|
42
|
-
When invoked by the CLI, honor any explicit execution instructions in the prompt. In particular:
|
|
43
|
-
- if `.interf/stage-contract.json` exists, treat it as the authoritative stage contract for this run
|
|
44
|
-
- if the prompt gives an expected summary-set size, use it as the source of truth for progress reporting
|
|
45
|
-
- if the prompt requires `.interf/relevant.json`, write it
|
|
46
|
-
- only emit user-facing lines that start with `STATUS:`, `DONE:`, `BLOCKED:`, or `ERROR:`
|
|
47
|
-
- when updating `.interf/relevant.json` or `.interf/coverage.json`, read the current file first and then rewrite the full JSON document; do not depend on anchored patch edits against stale runtime files
|
|
48
|
-
- the CLI reconciles `.interf/state.json` and refreshes `.interf/health.json` after validation; do not treat those files as stage-owned write targets for retrieve
|
|
49
|
-
- once the selected set is final, write the proof artifacts immediately, emit the `DONE:` line, and stop; do not reopen manual query docs or raw files after selection is settled
|
|
50
|
-
|
|
51
|
-
## Steps
|
|
52
|
-
|
|
53
|
-
```
|
|
54
|
-
Retrieve:
|
|
55
|
-
- [ ] 1. Read config and plan
|
|
56
|
-
- [ ] 2. Scan knowledge-base frontmatter
|
|
57
|
-
- [ ] 3. Review candidate abstracts
|
|
58
|
-
- [ ] 4. Expand through links if needed
|
|
59
|
-
- [ ] 5. Compute delta
|
|
60
|
-
- [ ] 6. Write retrieval proof
|
|
61
|
-
```
|
|
62
|
-
|
|
63
|
-
### 1. Read config and plan
|
|
64
|
-
|
|
65
|
-
- `interf.json` → `knowledge_base.path` to locate the knowledge base
|
|
66
|
-
- `compile-plan.md` → this stage's section: categories, priority evidence tiers, truth modes, key entities, date range
|
|
67
|
-
- if the plan depends on exact figures from PDFs, charts, or tables, keep that modality requirement visible during retrieval
|
|
68
|
-
- `../../.interf/source-access.json` → sample raw paths and suggested access checks when raw fallback is needed
|
|
69
|
-
- local instruction docs listed by the stage contract
|
|
70
|
-
|
|
71
|
-
Resolve `knowledge_base.path` from config and verify the knowledge base exists (has `summaries/`).
|
|
72
|
-
|
|
73
|
-
### 2. Scan knowledge-base frontmatter
|
|
74
|
-
|
|
75
|
-
Read all files in `{knowledge_base.path}/summaries/` frontmatter (fast — no full file reads):
|
|
76
|
-
- source
|
|
77
|
-
- source_kind
|
|
78
|
-
- evidence tier / truth mode / state
|
|
79
|
-
- abstract
|
|
80
|
-
|
|
81
|
-
Build a summary-set map: total files, source-kind distribution, evidence distribution.
|
|
82
|
-
|
|
83
|
-
### 3. Review candidate abstracts
|
|
84
|
-
|
|
85
|
-
From compile-plan.md filter criteria, identify a candidate set. Then read the abstract block for every candidate file before final selection.
|
|
86
|
-
If the use case depends on exact numeric comparisons from charts or tables, do not exclude a candidate just because the summary abstract is coarse. Keep files whose key evidence may still live in raw visuals.
|
|
87
|
-
|
|
88
|
-
### 4. Expand through links if needed
|
|
89
|
-
|
|
90
|
-
If candidate abstracts point to adjacent summaries that may materially change the answer, follow those links, review their abstracts, and repeat until the retrieved set is coverage-complete for the interface question.
|
|
91
|
-
Track emergent clusters that suggest the initial interface runtime is missing concepts, relationships, or taxonomy branches.
|
|
92
|
-
When chart-heavy PDFs or report pages are likely to hold the decisive evidence, preserve that signal for later stages instead of routing the interface toward prose-only summaries.
|
|
93
|
-
If exact numbers will require a local extraction path against the raw PDF, carry that requirement forward explicitly instead of assuming the analysis stage can infer it from a coarse abstract.
|
|
94
|
-
|
|
95
|
-
### 5. Compute delta
|
|
96
|
-
|
|
97
|
-
- If the current workspace already makes the delta obvious, keep `delta_files` limited to the newly relevant or newly changed files.
|
|
98
|
-
- If the prior compile boundary is not obvious from the current workspace, use the conservative fallback: set `delta_files` equal to the selected relevant set for this run.
|
|
99
|
-
|
|
100
|
-
### 6. Write retrieval proof
|
|
101
|
-
|
|
102
|
-
Write the full retrieved set to `.interf/relevant.json` in the current runtime shape. At minimum include:
|
|
103
|
-
- `generated_at`
|
|
104
|
-
- `knowledge_base_summary_count` derived from the current knowledge-base summary total
|
|
105
|
-
- `relevant_files` with the actual knowledge-base-relative summary paths selected in this run
|
|
106
|
-
- `delta_files` with the actual knowledge-base-relative summary paths that are new or changed for this run
|
|
107
|
-
|
|
108
|
-
Do not paste placeholder filenames, canned totals, or copied sample counters into the runtime artifact.
|
|
109
|
-
If `.interf/relevant.json` does not exist yet, create it in one complete write rather than trying to patch a missing file.
|
|
110
|
-
|
|
111
|
-
Write retrieval proof to `.interf/coverage.json` in the current verifier shape. Include:
|
|
112
|
-
- top-level `generated_at`
|
|
113
|
-
- top-level counts derived from this run: `knowledge_base_summary_total`, `frontmatter_scanned`, `candidates_after_frontmatter`, `abstracts_reviewed`, `expansion_passes`, `relevant_selected`, `rejected`, `coverage_complete`
|
|
114
|
-
- `proof.scanned` for the full scanned summary set
|
|
115
|
-
- `proof.reviewed` for the candidate abstracts actually reviewed
|
|
116
|
-
- `proof.retrieved` for the selected relevant set
|
|
117
|
-
- `proof.excluded` for the excluded set
|
|
118
|
-
|
|
119
|
-
`proof.retrieved` plus `proof.excluded` must partition the scanned set for this run.
|
|
120
|
-
|
|
121
|
-
If `.interf/coverage.json` already exists, read it and then rewrite the complete JSON document. Do not patch old counters or timestamps line-by-line.
|
|
122
|
-
If the retrieve stage reveals clear runtime gaps, preserve that signal for later stages via `.interf/analysis.json` or the next stage handoff rather than silently discarding it.
|
|
123
|
-
|
|
124
|
-
Report to user with status-style lines:
|
|
125
|
-
```
|
|
126
|
-
STATUS: loaded retrieve plan N summary files.
|
|
127
|
-
STATUS: scanned N/N
|
|
128
|
-
STATUS: reviewed M abstracts, P expansion passes
|
|
129
|
-
STATUS: selected R relevant, X rejected, D delta
|
|
130
|
-
DONE: retrieve complete
|
|
131
|
-
```
|
|
132
|
-
|
|
133
|
-
When the retrieval proof and relevant set are written, emit the required `DONE:` line and stop. The CLI reconciles `.interf/state.json` and refreshes `.interf/health.json` after validation. Do not keep exploring once retrieval closure is recorded.
|