bilmem 0.1.0
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 +439 -0
- package/dist/canonical-CglQQ0xc.d.ts +262 -0
- package/dist/cli/index.js +7601 -0
- package/dist/cli/index.js.map +1 -0
- package/dist/core/index.d.ts +311 -0
- package/dist/core/index.js +1975 -0
- package/dist/core/index.js.map +1 -0
- package/dist/filesystem-B3qAej0l.d.ts +69 -0
- package/dist/index.d.ts +163 -0
- package/dist/index.js +7765 -0
- package/dist/index.js.map +1 -0
- package/dist/install/index.d.ts +373 -0
- package/dist/install/index.js +6632 -0
- package/dist/install/index.js.map +1 -0
- package/dist/jev/index.d.ts +32 -0
- package/dist/jev/index.js +269 -0
- package/dist/jev/index.js.map +1 -0
- package/dist/mcp/index.d.ts +13 -0
- package/dist/mcp/index.js +5479 -0
- package/dist/mcp/index.js.map +1 -0
- package/dist/rules/index.d.ts +59 -0
- package/dist/rules/index.js +388 -0
- package/dist/rules/index.js.map +1 -0
- package/dist/scanner/index.d.ts +169 -0
- package/dist/scanner/index.js +3829 -0
- package/dist/scanner/index.js.map +1 -0
- package/dist/search/index.d.ts +44 -0
- package/dist/search/index.js +301 -0
- package/dist/search/index.js.map +1 -0
- package/dist/stats/index.d.ts +60 -0
- package/dist/stats/index.js +1373 -0
- package/dist/stats/index.js.map +1 -0
- package/dist/storage/index.d.ts +82 -0
- package/dist/storage/index.js +1748 -0
- package/dist/storage/index.js.map +1 -0
- package/dist/types-Nxq5Gzay.d.ts +390 -0
- package/package.json +71 -0
package/README.md
ADDED
|
@@ -0,0 +1,439 @@
|
|
|
1
|
+
# bilmem
|
|
2
|
+
|
|
3
|
+
> **`bilmem` is a lightweight, language-independent knowledge and learning runtime for AI agents and developer tooling.**
|
|
4
|
+
|
|
5
|
+
Its purpose is **NOT** to constantly intercept an agent, monitor every prompt, or act as another autonomous agent.
|
|
6
|
+
|
|
7
|
+
Its purpose is to help an agent:
|
|
8
|
+
|
|
9
|
+
- **reuse knowledge** it already has,
|
|
10
|
+
- **recognize when existing knowledge does not apply** through negative contextual cues,
|
|
11
|
+
- **explicitly represent uncertainty** and first-class unknowns,
|
|
12
|
+
- **avoid repeating previously useless investigations**,
|
|
13
|
+
- **learn from successful and failed work**,
|
|
14
|
+
- **refine existing knowledge** instead of endlessly accumulating memories,
|
|
15
|
+
- **ask for clarification** when local evidence is insufficient,
|
|
16
|
+
- **share, import, and export knowledge** in a portable format.
|
|
17
|
+
|
|
18
|
+
### Core Epistemic Philosophy
|
|
19
|
+
|
|
20
|
+
Bilmem differs fundamentally from repository graphs, vector databases, and memory dumps:
|
|
21
|
+
- Traditional repository tools primarily ask: **"What is related to X?"**
|
|
22
|
+
- Traditional memory systems primarily ask: **"What did we previously store about X?"**
|
|
23
|
+
- **Bilmem asks:**
|
|
24
|
+
|
|
25
|
+
> **"Do I know enough to act, what do I know does not apply, what am I missing, and what is the cheapest next step to resolve the uncertainty?"**
|
|
26
|
+
|
|
27
|
+
Bilmem is a lightweight **epistemic runtime**.
|
|
28
|
+
|
|
29
|
+
### Guiding Principles
|
|
30
|
+
|
|
31
|
+
> **Memory should grow by refinement, not accumulation.**
|
|
32
|
+
|
|
33
|
+
> **Bilmem should be cheaper than not knowing.**
|
|
34
|
+
|
|
35
|
+
> **Prefer the smallest action likely to resolve the uncertainty.**
|
|
36
|
+
|
|
37
|
+
## Architecture Overview
|
|
38
|
+
|
|
39
|
+
```text
|
|
40
|
+
Sources (Filesystem, Structured Markdown, Git, Agent Trajectories, User Corrections)
|
|
41
|
+
│
|
|
42
|
+
▼
|
|
43
|
+
Observations
|
|
44
|
+
│
|
|
45
|
+
▼
|
|
46
|
+
Evidence Graph (IMPORTS, REFERENCES, CO_CHANGED, etc.)
|
|
47
|
+
│
|
|
48
|
+
▼
|
|
49
|
+
Candidate Extraction & Smart Reconciliation
|
|
50
|
+
(NEW, MERGE, UPDATE, SUPPORT, CONTRADICT, SPECIALIZE, IGNORE)
|
|
51
|
+
│
|
|
52
|
+
▼
|
|
53
|
+
Storage (.bilmem/)
|
|
54
|
+
│
|
|
55
|
+
┌───────────┴───────────┐
|
|
56
|
+
▼ ▼
|
|
57
|
+
Search Index Portable YAML
|
|
58
|
+
(Rebuildable) (import/export/dump/restore)
|
|
59
|
+
│
|
|
60
|
+
Query / Context
|
|
61
|
+
│
|
|
62
|
+
Candidate Retrieval (top candidates)
|
|
63
|
+
│
|
|
64
|
+
JEV Contextual Reranking (positive & negative proximity)
|
|
65
|
+
│
|
|
66
|
+
MATCH / POSSIBLE / REJECT with Explanations
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
## Core Concepts
|
|
72
|
+
|
|
73
|
+
### 1. Observation & Provenance
|
|
74
|
+
Something observed directly from a source with verifiable provenance (file path, line, git commit/revision, content hash). `author` is optional and non-essential for truth verification; cryptographic content and revision hashes establish deterministic provenance.
|
|
75
|
+
|
|
76
|
+
### 2. Evidence
|
|
77
|
+
One or more observations supporting or contradicting a claim. Multiple agents reading the same source do **not** count as independent evidence; evidence identity is derived from deterministic source hashing.
|
|
78
|
+
|
|
79
|
+
### 3. Knowledge & Honest Confidence Model
|
|
80
|
+
A reusable conclusion supported by evidence:
|
|
81
|
+
```yaml
|
|
82
|
+
id: auth.session.refresh-order
|
|
83
|
+
type: lesson
|
|
84
|
+
status: active
|
|
85
|
+
statement: Refresh token validation happens before session renewal.
|
|
86
|
+
positive:
|
|
87
|
+
- expired-session
|
|
88
|
+
- refresh-token
|
|
89
|
+
- server-session
|
|
90
|
+
negative:
|
|
91
|
+
- stateless-jwt
|
|
92
|
+
confidenceTier: high
|
|
93
|
+
confidence: 0.95
|
|
94
|
+
evidence:
|
|
95
|
+
- code:src/auth/session.ts
|
|
96
|
+
- git:81ac23
|
|
97
|
+
```
|
|
98
|
+
To avoid deceptive artificial precision (e.g. `0.91`), `bilmem` uses transparent, explainable confidence tiers backed by deterministic evidence scoring:
|
|
99
|
+
- `high` (0.95): Explicit human correction, accepted ADR, or repeatedly verified outcome.
|
|
100
|
+
- `medium` (0.75): Confirmed test pass, documented code pattern, or supported rule.
|
|
101
|
+
- `low` (0.50): Heuristic observation or candidate lesson awaiting verification.
|
|
102
|
+
|
|
103
|
+
### 4. First-Class Unknowns
|
|
104
|
+
`bilmem` treats unknown states as first-class citizens (`KNOWN`, `PARTIALLY_KNOWN`, `UNKNOWN`, `STALE`, `CONFLICTED`) with actionable reasons (`NOT_OBSERVED`, `INSUFFICIENT_EVIDENCE`, `CONFLICTING_EVIDENCE`, `STALE`, `UNRESOLVABLE_LOCALLY`).
|
|
105
|
+
```yaml
|
|
106
|
+
id: project.database.migration
|
|
107
|
+
state: unknown
|
|
108
|
+
reason: UNRESOLVABLE_LOCALLY
|
|
109
|
+
checked:
|
|
110
|
+
- package.json
|
|
111
|
+
- src/db/**
|
|
112
|
+
- scripts/**
|
|
113
|
+
next:
|
|
114
|
+
type: ask
|
|
115
|
+
question: How are database migrations performed in this project?
|
|
116
|
+
```
|
|
117
|
+
This directly prevents future agents from repeating the same failed investigation.
|
|
118
|
+
|
|
119
|
+
### 5. JEV Contextual Matching
|
|
120
|
+
Retrieval is not just fuzzy similarity. JEV calculates:
|
|
121
|
+
- Positive cue overlap
|
|
122
|
+
- Hard negative conflicts (immediate rejection when forbidden patterns are present)
|
|
123
|
+
- Scope alignment (exact, parent, global)
|
|
124
|
+
- Effective confidence (dampened by contradiction ratios and outcome history)
|
|
125
|
+
- Inspectable decision explanations (`MATCH`, `POSSIBLE`, `REJECT`)
|
|
126
|
+
|
|
127
|
+
### 6. Contradiction Precedes Merge & Smart Growth
|
|
128
|
+
Lexical similarity alone **never** justifies merging. Opposing assertions (e.g., `cache enabled in production` vs `cache disabled in production`) have high token overlap but polar opposite meaning. Polarity and negative checks evaluate **strictly before** any merge decision:
|
|
129
|
+
- `CONTRADICT`: Directly conflicts or asserts opposing polarity; flags status or lowers confidence.
|
|
130
|
+
- `SPECIALIZE`: Contextual divergence (e.g. SQLite for dev vs PostgreSQL for prod) creates sub-context branches.
|
|
131
|
+
- `MERGE`: Highly similar non-contradictory statement; consolidates evidence and cues.
|
|
132
|
+
- `NEW`: No related knowledge exists.
|
|
133
|
+
- `UPDATE`: Refines or updates existing knowledge statement.
|
|
134
|
+
- `SUPPORT`: Confirms existing knowledge with new evidence source, increasing confidence.
|
|
135
|
+
- `IGNORE`: Duplicate observation from already-known source with no new information.
|
|
136
|
+
|
|
137
|
+
### 7. Staged Trajectory Learning Pipeline
|
|
138
|
+
`bilmem learn` adheres to a strict multi-stage lifecycle:
|
|
139
|
+
```text
|
|
140
|
+
trajectory → observations → candidate lessons → reconcile → knowledge
|
|
141
|
+
```
|
|
142
|
+
Raw trajectories are never dumped directly into permanent knowledge. Each trajectory step produces traceable `Observation` and `Evidence` nodes. Reusable candidate lessons are extracted and reconciled with existing knowledge before any persistence occurs.
|
|
143
|
+
|
|
144
|
+
### 8. Conservative Scanning ("Ederinden Fazlasını Vaat Etmeme")
|
|
145
|
+
A repository scan is not forced to manufacture knowledge out of thin air. The primary, deterministic output of `bilmem scan` is **Observation & Evidence**. Speculative or loose file signals remain observations; only explicit rule sets, accepted ADRs, and verified git reverts become candidate lessons.
|
|
146
|
+
|
|
147
|
+
---
|
|
148
|
+
|
|
149
|
+
## Storage Architecture
|
|
150
|
+
|
|
151
|
+
Inside `.bilmem/`, the source-of-truth is stored in **append-friendly JSONL** files:
|
|
152
|
+
|
|
153
|
+
```text
|
|
154
|
+
.bilmem/
|
|
155
|
+
├── knowledge.jsonl # Canonical append-log of knowledge units
|
|
156
|
+
├── evidence.jsonl # Canonical append-log of evidence nodes
|
|
157
|
+
├── observations.jsonl # Signal observations with cryptographic hashes
|
|
158
|
+
├── unknowns.jsonl # First-class unknowns and unresolvable questions
|
|
159
|
+
├── outcomes.jsonl # Task feedback and outcome records
|
|
160
|
+
├── revisions.jsonl # Point-in-time snapshot log for diff tracking
|
|
161
|
+
├── rules/ # Declarative YAML rule sets (.bilmem/rules/*.yml)
|
|
162
|
+
├── index/ # Ephemeral, 100% rebuildable search index
|
|
163
|
+
├── config.json # Project configuration and scan checkpoints
|
|
164
|
+
└── metrics.json # Reuse, miss, and prevention telemetry
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
- **JSONL for internal source-of-truth**: Fast streaming, append-friendly writes, and git-diff friendly log lines.
|
|
168
|
+
- **YAML for interchange & rules**: Human-edited rule sets (`.bilmem/rules/*.yml`) and portable sharing (`bilmem export`, `bilmem dump`).
|
|
169
|
+
- **Rebuildable Index**: The search index in `.bilmem/index/` is completely rebuildable from `.bilmem/knowledge.jsonl` at any time.
|
|
170
|
+
|
|
171
|
+
---
|
|
172
|
+
|
|
173
|
+
## CLI Commands
|
|
174
|
+
|
|
175
|
+
```bash
|
|
176
|
+
# Primary Epistemic Operation: Do I know enough to act, what is missing, cheapest next action?
|
|
177
|
+
bilmem resolve "How are sessions renewed?" -p server-session -n stateless-jwt
|
|
178
|
+
|
|
179
|
+
# Lookup knowledge using candidate retrieval + JEV contextual reranker
|
|
180
|
+
bilmem lookup "refresh session" -p expired-session refresh-token
|
|
181
|
+
|
|
182
|
+
# Explain why a knowledge unit exists or inspect its full lifecycle history
|
|
183
|
+
bilmem why auth.session.refresh-order
|
|
184
|
+
bilmem why auth.session.refresh-order --history
|
|
185
|
+
|
|
186
|
+
# Initialize bilmem in current directory
|
|
187
|
+
bilmem init [path]
|
|
188
|
+
|
|
189
|
+
# Scan filesystem conventions, structured markdown, and git history
|
|
190
|
+
bilmem scan [path] [--incremental] [--dry-run]
|
|
191
|
+
|
|
192
|
+
# Inspect incremental learning and revision diffs
|
|
193
|
+
bilmem diff [sinceRef]
|
|
194
|
+
|
|
195
|
+
# Learn from an agent trajectory JSON via the staged pipeline
|
|
196
|
+
bilmem learn trajectory.json [--dry-run]
|
|
197
|
+
|
|
198
|
+
# List active knowledge items
|
|
199
|
+
bilmem known [--scope <scope>] [--status <status>]
|
|
200
|
+
|
|
201
|
+
# List first-class unknowns and unresolvable items
|
|
202
|
+
bilmem unknown
|
|
203
|
+
|
|
204
|
+
# Manage declarative YAML rule sets and guardrails
|
|
205
|
+
bilmem rules list
|
|
206
|
+
bilmem rule add "Use Vitest for testing" --when-file vite.config.ts
|
|
207
|
+
|
|
208
|
+
# Smart import with reconciliation
|
|
209
|
+
bilmem import knowledge.yml
|
|
210
|
+
bilmem import ./rules/
|
|
211
|
+
|
|
212
|
+
# Export active knowledge to YAML
|
|
213
|
+
bilmem export [--scope <scope>] [-o output.yml]
|
|
214
|
+
|
|
215
|
+
# Complete snapshot backup and deterministic restore
|
|
216
|
+
bilmem dump snapshot.yml
|
|
217
|
+
bilmem restore snapshot.yml
|
|
218
|
+
|
|
219
|
+
# Compact knowledge base (merge duplicates, clean stale observations)
|
|
220
|
+
bilmem compact [--dry-run]
|
|
221
|
+
|
|
222
|
+
# Status summary & metrics
|
|
223
|
+
bilmem status
|
|
224
|
+
```
|
|
225
|
+
|
|
226
|
+
### Primary Operation: `bilmem resolve`
|
|
227
|
+
|
|
228
|
+
Unlike search or lookup, `resolve` executes an epistemic evaluation:
|
|
229
|
+
|
|
230
|
+
```bash
|
|
231
|
+
$ bilmem resolve "How are sessions renewed?" -p server-session -n stateless-jwt
|
|
232
|
+
```
|
|
233
|
+
|
|
234
|
+
Structured output:
|
|
235
|
+
```yaml
|
|
236
|
+
state: PARTIALLY_KNOWN
|
|
237
|
+
|
|
238
|
+
known:
|
|
239
|
+
- id: auth.refresh-token
|
|
240
|
+
confidence: high
|
|
241
|
+
|
|
242
|
+
applicable:
|
|
243
|
+
- server-session
|
|
244
|
+
|
|
245
|
+
rejected:
|
|
246
|
+
- id: auth.jwt-refresh
|
|
247
|
+
reason: stateless-jwt conflicts with current context
|
|
248
|
+
|
|
249
|
+
missing:
|
|
250
|
+
- renewal-order
|
|
251
|
+
|
|
252
|
+
checked:
|
|
253
|
+
- src/auth/**
|
|
254
|
+
- docs/auth.md
|
|
255
|
+
|
|
256
|
+
next:
|
|
257
|
+
type: INSPECT_TEST
|
|
258
|
+
target: tests/session-refresh.test.ts
|
|
259
|
+
reason: Most direct uninspected evidence for renewal ordering.
|
|
260
|
+
|
|
261
|
+
fallback:
|
|
262
|
+
type: ask
|
|
263
|
+
question: Does session renewal happen before or after refresh-token validation?
|
|
264
|
+
```
|
|
265
|
+
|
|
266
|
+
### Inspecting Changes with `bilmem diff`
|
|
267
|
+
```text
|
|
268
|
+
$ bilmem diff 8ac12f
|
|
269
|
+
|
|
270
|
+
Since 8ac12f:
|
|
271
|
+
|
|
272
|
+
+ 14 observations
|
|
273
|
+
+ 2 candidates
|
|
274
|
+
↑ 1 knowledge strengthened
|
|
275
|
+
~ 1 knowledge revised
|
|
276
|
+
! 1 contradiction
|
|
277
|
+
? 2 unknowns
|
|
278
|
+
× 1 knowledge needs revalidation
|
|
279
|
+
- 0 invalidated
|
|
280
|
+
```
|
|
281
|
+
|
|
282
|
+
---
|
|
283
|
+
|
|
284
|
+
## Model Context Protocol (MCP) via `mcponce`
|
|
285
|
+
|
|
286
|
+
`bilmem` provides a single-instance MCP server via `mcponce`.
|
|
287
|
+
|
|
288
|
+
Run directly:
|
|
289
|
+
```bash
|
|
290
|
+
bilmem mcp
|
|
291
|
+
```
|
|
292
|
+
|
|
293
|
+
### Exposed MCP Tools:
|
|
294
|
+
1. `bilmem_resolve`: Primary epistemic operation. Determines if enough is known to answer or act, what contextually does not apply, what is missing, and the cheapest next step to resolve uncertainty.
|
|
295
|
+
2. `bilmem_lookup`: Query knowledge with positive/negative context cues. Returns compact, highly applicable knowledge units without flooding agent context.
|
|
296
|
+
3. `bilmem_observe`: Record an observation with preserved provenance.
|
|
297
|
+
4. `bilmem_learn`: Learn from task trajectories or explicit user corrections.
|
|
298
|
+
5. `bilmem_explain`: Inspectable explanation of why an item is known (supports `--history`).
|
|
299
|
+
6. `bilmem_unknown`: Query or record first-class unknowns with checked paths.
|
|
300
|
+
7. `bilmem_scan`: Trigger a repository scan.
|
|
301
|
+
8. `bilmem_stats`: Inspect local-first statistics, knowledge health, and effectiveness metrics (read-only).
|
|
302
|
+
|
|
303
|
+
---
|
|
304
|
+
|
|
305
|
+
## Agent & Editor Installer (`bilmem install`)
|
|
306
|
+
|
|
307
|
+
Bilmem features a lightweight, decoupled installer system to configure Bilmem's MCP server and minimal instructions across supported AI coding agents and editors:
|
|
308
|
+
|
|
309
|
+
```bash
|
|
310
|
+
# Interactive detection & installation for detected agents
|
|
311
|
+
bilmem install
|
|
312
|
+
|
|
313
|
+
# Target specific agents
|
|
314
|
+
bilmem install cursor
|
|
315
|
+
bilmem install claude
|
|
316
|
+
bilmem install codex
|
|
317
|
+
bilmem install gemini
|
|
318
|
+
|
|
319
|
+
# Non-interactive / CI automation
|
|
320
|
+
bilmem install --detected --yes
|
|
321
|
+
bilmem install --all
|
|
322
|
+
|
|
323
|
+
# Dry-run preview
|
|
324
|
+
bilmem install cursor --dry-run
|
|
325
|
+
|
|
326
|
+
# Global vs Project scope (defaults to project-local)
|
|
327
|
+
bilmem install cursor --global
|
|
328
|
+
|
|
329
|
+
# Safe uninstallation (preserves other servers and user rules)
|
|
330
|
+
bilmem uninstall cursor
|
|
331
|
+
|
|
332
|
+
# Health diagnostics & automated repair
|
|
333
|
+
bilmem doctor
|
|
334
|
+
bilmem doctor --fix
|
|
335
|
+
```
|
|
336
|
+
|
|
337
|
+
### Safe, Non-Destructive Editing
|
|
338
|
+
- **JSON Configuration**: Safely parses existing agent configs (`.cursor/mcp.json`, `.claude/mcp.json`, etc.), injects the `bilmem` MCP server under `mcpServers`, preserves all existing third-party servers and settings, and writes atomically.
|
|
339
|
+
- **Agent Instructions**: Installs a token-efficient instruction block bounded by `<!-- bilmem:start -->` and `<!-- bilmem:end -->` into `.cursorrules`, `CLAUDE.md`, `CODEX.md`, or `GEMINI.md` without overwriting custom user guidelines.
|
|
340
|
+
- **Ownership Tracking**: Maintains metadata in `.bilmem/integrations.json` so `bilmem uninstall` cleanly removes only Bilmem-owned blocks and registrations.
|
|
341
|
+
|
|
342
|
+
---
|
|
343
|
+
|
|
344
|
+
## Statistics & Effectiveness Layer (`bilmem stats`)
|
|
345
|
+
|
|
346
|
+
The purpose of stats is **NOT** to create a vanity dashboard. It provides measurable evidence answering:
|
|
347
|
+
|
|
348
|
+
> **Is Bilmem actually reducing repeated investigation and improving knowledge reuse?**
|
|
349
|
+
|
|
350
|
+
Bilmem adheres to the principle: **"Bilmem should be cheaper than not knowing."**
|
|
351
|
+
|
|
352
|
+
- **Deterministic & Observable**: No fake token, dollar, or time savings. Metrics track directly observable events: repeated checks avoided, broad searches avoided, source reads avoided, and knowledge reused.
|
|
353
|
+
- **State vs Activity Separation**: Current state metrics (active, candidates, unknowns, conflicted, needs revalidation) are computed live from canonical state without drifting counters; historical metrics are aggregated from append-only events (`.bilmem/events.jsonl`).
|
|
354
|
+
- **Local & Private by Default**: No network calls, telemetry, or remote analytics.
|
|
355
|
+
|
|
356
|
+
```bash
|
|
357
|
+
# Default overview report
|
|
358
|
+
bilmem stats
|
|
359
|
+
|
|
360
|
+
# Filter activity by timeframe
|
|
361
|
+
bilmem stats --since 24h
|
|
362
|
+
bilmem stats --since 7d
|
|
363
|
+
bilmem stats --since 30d
|
|
364
|
+
|
|
365
|
+
# Filter activity by Git revision
|
|
366
|
+
bilmem stats --since HEAD~20
|
|
367
|
+
bilmem stats --since 81ac23
|
|
368
|
+
|
|
369
|
+
# Inspect single-item lifecycle, evidence, JEV diagnostics, and health
|
|
370
|
+
bilmem stats --knowledge auth.session.refresh-order
|
|
371
|
+
|
|
372
|
+
# Structured JSON output for CI, tooling, or MCP
|
|
373
|
+
bilmem stats --json
|
|
374
|
+
|
|
375
|
+
# Safe reset of metric events log (historical knowledge/evidence are never deleted)
|
|
376
|
+
bilmem stats --reset
|
|
377
|
+
```
|
|
378
|
+
|
|
379
|
+
### Knowledge Health Classifications
|
|
380
|
+
Deterministic, observable health classifications for every knowledge item:
|
|
381
|
+
- `HEALTHY`: Active with verified independent sources and clean outcome history.
|
|
382
|
+
- `NEEDS_REVALIDATION`: Underlying source or dependency changed since last validation.
|
|
383
|
+
- `LOW_EVIDENCE`: Less than 2 independent sources and confidence < 0.75.
|
|
384
|
+
- `FREQUENTLY_REJECTED`: Rejected by JEV in ≥70% of evaluations (min 3 attempts).
|
|
385
|
+
- `FREQUENTLY_MISLEADING`: Misleading outcomes exceed or equal successful outcomes.
|
|
386
|
+
- `UNUSED`: No reuse recorded after creation.
|
|
387
|
+
|
|
388
|
+
---
|
|
389
|
+
|
|
390
|
+
## Programmatic TypeScript API
|
|
391
|
+
|
|
392
|
+
```ts
|
|
393
|
+
import { Bilmem } from 'bilmem';
|
|
394
|
+
|
|
395
|
+
// Initialize bilmem client
|
|
396
|
+
const bilmem = new Bilmem();
|
|
397
|
+
await bilmem.init();
|
|
398
|
+
|
|
399
|
+
// Lookup knowledge with contextual cues
|
|
400
|
+
const results = await bilmem.lookup({
|
|
401
|
+
query: 'session renewal',
|
|
402
|
+
positive: ['server-session']
|
|
403
|
+
});
|
|
404
|
+
|
|
405
|
+
// Record an observation with provenance
|
|
406
|
+
await bilmem.observe({
|
|
407
|
+
claim: 'Refresh token validation happens before session renewal',
|
|
408
|
+
source: 'file:src/auth/session.ts',
|
|
409
|
+
positive: ['auth', 'session']
|
|
410
|
+
});
|
|
411
|
+
|
|
412
|
+
// Learn from task trajectory or user corrections
|
|
413
|
+
await bilmem.learn({
|
|
414
|
+
goal: 'Fix session race condition',
|
|
415
|
+
outcome: 'success',
|
|
416
|
+
events: [
|
|
417
|
+
{ type: 'hypothesis', description: 'Investigate token renewal lock' },
|
|
418
|
+
{ type: 'attempt', description: 'Apply mutex to session refresh' },
|
|
419
|
+
{ type: 'success', description: 'Resolved concurrent refresh race' }
|
|
420
|
+
]
|
|
421
|
+
});
|
|
422
|
+
|
|
423
|
+
// Or compose modular building blocks directly:
|
|
424
|
+
import { Storage, SearchIndex, Retriever } from 'bilmem';
|
|
425
|
+
|
|
426
|
+
const storage = new Storage();
|
|
427
|
+
await storage.init();
|
|
428
|
+
|
|
429
|
+
const index = new SearchIndex();
|
|
430
|
+
await index.buildIndex(await storage.getAllKnowledge());
|
|
431
|
+
|
|
432
|
+
const retriever = new Retriever(index, storage);
|
|
433
|
+
```
|
|
434
|
+
|
|
435
|
+
---
|
|
436
|
+
|
|
437
|
+
## License
|
|
438
|
+
|
|
439
|
+
MIT
|
|
@@ -0,0 +1,262 @@
|
|
|
1
|
+
import { u as ResolutionState, A as ActionType, O as OutcomeType, m as KnowledgeStatus, l as KnowledgeStage, B as BilmemConfig, K as Knowledge, c as Evidence, o as Observation, U as UnknownRecord, p as OutcomeRecord, I as InvestigationReceipt, d as EvidenceRelation, b as BilmemMetrics, y as RuleSet, x as RuleDefinition, v as RevisionSnapshot, h as KnowledgeDiff } from './types-Nxq5Gzay.js';
|
|
2
|
+
import { KnowledgeStoreProvider } from './search/index.js';
|
|
3
|
+
|
|
4
|
+
type JevRejectReason = 'HARD_NEGATIVE' | 'SCOPE_MISMATCH' | 'INSUFFICIENT_CONTEXT' | 'STALE_KNOWLEDGE' | 'CONTEXT_MISMATCH';
|
|
5
|
+
type MetricEvent = {
|
|
6
|
+
type: 'resolve';
|
|
7
|
+
state: ResolutionState;
|
|
8
|
+
action?: ActionType;
|
|
9
|
+
question?: string;
|
|
10
|
+
timestamp: number;
|
|
11
|
+
} | {
|
|
12
|
+
type: 'knowledge_reused';
|
|
13
|
+
knowledgeId: string;
|
|
14
|
+
timestamp: number;
|
|
15
|
+
} | {
|
|
16
|
+
type: 'knowledge_created';
|
|
17
|
+
knowledgeId: string;
|
|
18
|
+
timestamp: number;
|
|
19
|
+
} | {
|
|
20
|
+
type: 'knowledge_merged';
|
|
21
|
+
knowledgeId: string;
|
|
22
|
+
targetId?: string;
|
|
23
|
+
timestamp: number;
|
|
24
|
+
} | {
|
|
25
|
+
type: 'knowledge_strengthened';
|
|
26
|
+
knowledgeId: string;
|
|
27
|
+
timestamp: number;
|
|
28
|
+
} | {
|
|
29
|
+
type: 'knowledge_specialized';
|
|
30
|
+
knowledgeId: string;
|
|
31
|
+
timestamp: number;
|
|
32
|
+
} | {
|
|
33
|
+
type: 'knowledge_superseded';
|
|
34
|
+
knowledgeId: string;
|
|
35
|
+
supersededBy?: string;
|
|
36
|
+
timestamp: number;
|
|
37
|
+
} | {
|
|
38
|
+
type: 'contradiction_detected';
|
|
39
|
+
knowledgeId?: string;
|
|
40
|
+
conflictingId?: string;
|
|
41
|
+
timestamp: number;
|
|
42
|
+
} | {
|
|
43
|
+
type: 'duplicate_ignored';
|
|
44
|
+
timestamp: number;
|
|
45
|
+
} | {
|
|
46
|
+
type: 'jev_result';
|
|
47
|
+
knowledgeId: string;
|
|
48
|
+
result: 'MATCH' | 'POSSIBLE' | 'REJECT';
|
|
49
|
+
reason?: JevRejectReason | string;
|
|
50
|
+
timestamp: number;
|
|
51
|
+
} | {
|
|
52
|
+
type: 'jev_hard_negative';
|
|
53
|
+
knowledgeId: string;
|
|
54
|
+
timestamp: number;
|
|
55
|
+
} | {
|
|
56
|
+
type: 'investigation_reused';
|
|
57
|
+
investigationId: string;
|
|
58
|
+
timestamp: number;
|
|
59
|
+
} | {
|
|
60
|
+
type: 'source_read_avoided';
|
|
61
|
+
source: string;
|
|
62
|
+
timestamp: number;
|
|
63
|
+
} | {
|
|
64
|
+
type: 'broad_search_avoided';
|
|
65
|
+
targetAction?: ActionType;
|
|
66
|
+
timestamp: number;
|
|
67
|
+
} | {
|
|
68
|
+
type: 'question_suggested';
|
|
69
|
+
questionId?: string;
|
|
70
|
+
question?: string;
|
|
71
|
+
timestamp: number;
|
|
72
|
+
} | {
|
|
73
|
+
type: 'question_resolved';
|
|
74
|
+
questionId?: string;
|
|
75
|
+
timestamp: number;
|
|
76
|
+
} | {
|
|
77
|
+
type: 'outcome';
|
|
78
|
+
knowledgeId: string;
|
|
79
|
+
result: OutcomeType;
|
|
80
|
+
timestamp: number;
|
|
81
|
+
};
|
|
82
|
+
interface EffectivenessRatio {
|
|
83
|
+
value?: number;
|
|
84
|
+
formatted: string;
|
|
85
|
+
formula: string;
|
|
86
|
+
}
|
|
87
|
+
type KnowledgeHealthCategory = 'HEALTHY' | 'NEEDS_REVALIDATION' | 'LOW_EVIDENCE' | 'FREQUENTLY_REJECTED' | 'FREQUENTLY_MISLEADING' | 'UNUSED';
|
|
88
|
+
interface StatsReport {
|
|
89
|
+
since?: string;
|
|
90
|
+
sinceTimestamp?: number;
|
|
91
|
+
knowledge: {
|
|
92
|
+
active: number;
|
|
93
|
+
candidates: number;
|
|
94
|
+
unknown: number;
|
|
95
|
+
conflicted: number;
|
|
96
|
+
needsRevalidation: number;
|
|
97
|
+
stale: number;
|
|
98
|
+
total: number;
|
|
99
|
+
};
|
|
100
|
+
learning: {
|
|
101
|
+
observations: number;
|
|
102
|
+
new: number;
|
|
103
|
+
merged: number;
|
|
104
|
+
strengthened: number;
|
|
105
|
+
specialized: number;
|
|
106
|
+
superseded: number;
|
|
107
|
+
contradictions: number;
|
|
108
|
+
ignoredDuplicates: number;
|
|
109
|
+
};
|
|
110
|
+
resolution: {
|
|
111
|
+
resolveCalls: number;
|
|
112
|
+
known: number;
|
|
113
|
+
partiallyKnown: number;
|
|
114
|
+
unknown: number;
|
|
115
|
+
conflicted: number;
|
|
116
|
+
stale: number;
|
|
117
|
+
};
|
|
118
|
+
investigation: {
|
|
119
|
+
repeatedChecksAvoided: number;
|
|
120
|
+
knowledgeReused: number;
|
|
121
|
+
questionsSuggested: number;
|
|
122
|
+
questionsResolved: number;
|
|
123
|
+
broadSearchesAvoided: number;
|
|
124
|
+
sourceReadsAvoided: number;
|
|
125
|
+
investigationsReused: number;
|
|
126
|
+
};
|
|
127
|
+
jev: {
|
|
128
|
+
candidates: number;
|
|
129
|
+
match: number;
|
|
130
|
+
possible: number;
|
|
131
|
+
rejected: number;
|
|
132
|
+
hardNegativeRejects: number;
|
|
133
|
+
reasons: {
|
|
134
|
+
hardNegative: number;
|
|
135
|
+
scopeMismatch: number;
|
|
136
|
+
insufficientContext: number;
|
|
137
|
+
staleKnowledge: number;
|
|
138
|
+
};
|
|
139
|
+
};
|
|
140
|
+
actions: Record<string, number>;
|
|
141
|
+
effectiveness: {
|
|
142
|
+
knowledgeReuseRate: EffectivenessRatio;
|
|
143
|
+
resolveSuccessRate: EffectivenessRatio;
|
|
144
|
+
questionResolutionRate: EffectivenessRatio;
|
|
145
|
+
jevRejectionRate: EffectivenessRatio;
|
|
146
|
+
};
|
|
147
|
+
health: {
|
|
148
|
+
healthy: number;
|
|
149
|
+
needsRevalidation: number;
|
|
150
|
+
lowEvidence: number;
|
|
151
|
+
frequentlyRejected: number;
|
|
152
|
+
frequentlyMisleading: number;
|
|
153
|
+
unused: number;
|
|
154
|
+
};
|
|
155
|
+
}
|
|
156
|
+
interface KnowledgeStatsReport {
|
|
157
|
+
id: string;
|
|
158
|
+
status: KnowledgeStatus;
|
|
159
|
+
stage?: KnowledgeStage;
|
|
160
|
+
statement: string;
|
|
161
|
+
usage: {
|
|
162
|
+
used: number;
|
|
163
|
+
successfulOutcomes: number;
|
|
164
|
+
neutralOutcomes: number;
|
|
165
|
+
misleadingOutcomes: number;
|
|
166
|
+
failedOutcomes: number;
|
|
167
|
+
};
|
|
168
|
+
jev: {
|
|
169
|
+
match: number;
|
|
170
|
+
possible: number;
|
|
171
|
+
rejected: number;
|
|
172
|
+
hardNegativeRejects: number;
|
|
173
|
+
};
|
|
174
|
+
evidence: {
|
|
175
|
+
sources: number;
|
|
176
|
+
independentSources: number;
|
|
177
|
+
sourcesList: string[];
|
|
178
|
+
};
|
|
179
|
+
lifecycle: {
|
|
180
|
+
revisions: number;
|
|
181
|
+
strengthened: number;
|
|
182
|
+
contradictions: number;
|
|
183
|
+
lastUsed?: string;
|
|
184
|
+
lastValidated?: string;
|
|
185
|
+
health: KnowledgeHealthCategory;
|
|
186
|
+
healthReason: string;
|
|
187
|
+
};
|
|
188
|
+
}
|
|
189
|
+
|
|
190
|
+
declare function sanitizeFileName(id: string): string;
|
|
191
|
+
declare function desanitizeFileName(name: string): string;
|
|
192
|
+
declare class Storage implements KnowledgeStoreProvider {
|
|
193
|
+
private baseDir;
|
|
194
|
+
private knowledgeDir;
|
|
195
|
+
private evidenceDir;
|
|
196
|
+
private observationDir;
|
|
197
|
+
private unknownDir;
|
|
198
|
+
private rulesDir;
|
|
199
|
+
private configFile;
|
|
200
|
+
private relationsFile;
|
|
201
|
+
private outcomesFile;
|
|
202
|
+
private metricsFile;
|
|
203
|
+
private revisionsFile;
|
|
204
|
+
private knowledgeJsonlFile;
|
|
205
|
+
private evidenceJsonlFile;
|
|
206
|
+
private observationJsonlFile;
|
|
207
|
+
private unknownsJsonlFile;
|
|
208
|
+
private receiptsDir;
|
|
209
|
+
private receiptsJsonlFile;
|
|
210
|
+
private eventsFile;
|
|
211
|
+
constructor(rootDir?: string);
|
|
212
|
+
getBaseDir(): string;
|
|
213
|
+
isInitialized(): Promise<boolean>;
|
|
214
|
+
init(options?: {
|
|
215
|
+
projectName?: string;
|
|
216
|
+
defaultScope?: string;
|
|
217
|
+
}): Promise<BilmemConfig>;
|
|
218
|
+
getConfig(): Promise<BilmemConfig>;
|
|
219
|
+
saveConfig(config: BilmemConfig): Promise<void>;
|
|
220
|
+
updateConfig(updates: Partial<BilmemConfig>): Promise<BilmemConfig>;
|
|
221
|
+
saveKnowledge(knowledge: Knowledge): Promise<void>;
|
|
222
|
+
getKnowledge(id: string): Promise<Knowledge | undefined>;
|
|
223
|
+
getAllKnowledge(): Promise<Knowledge[]>;
|
|
224
|
+
deleteKnowledge(id: string): Promise<boolean>;
|
|
225
|
+
saveEvidence(evidence: Evidence): Promise<void>;
|
|
226
|
+
getEvidence(id: string): Promise<Evidence | undefined>;
|
|
227
|
+
getAllEvidence(): Promise<Evidence[]>;
|
|
228
|
+
saveObservation(obs: Observation): Promise<void>;
|
|
229
|
+
getObservation(id: string): Promise<Observation | undefined>;
|
|
230
|
+
getAllObservations(): Promise<Observation[]>;
|
|
231
|
+
deleteObservation(id: string): Promise<boolean>;
|
|
232
|
+
saveUnknown(record: UnknownRecord): Promise<void>;
|
|
233
|
+
getUnknown(id: string): Promise<UnknownRecord | undefined>;
|
|
234
|
+
getAllUnknowns(): Promise<UnknownRecord[]>;
|
|
235
|
+
deleteUnknown(id: string): Promise<boolean>;
|
|
236
|
+
appendOutcome(outcome: OutcomeRecord): Promise<void>;
|
|
237
|
+
getAllOutcomes(): Promise<OutcomeRecord[]>;
|
|
238
|
+
appendMetricEvent(event: MetricEvent): Promise<void>;
|
|
239
|
+
getMetricEvents(filter?: {
|
|
240
|
+
sinceTimestamp?: number;
|
|
241
|
+
knowledgeId?: string;
|
|
242
|
+
}): Promise<MetricEvent[]>;
|
|
243
|
+
resetMetricEvents(): Promise<void>;
|
|
244
|
+
saveReceipt(receipt: InvestigationReceipt): Promise<void>;
|
|
245
|
+
getReceipt(id: string): Promise<InvestigationReceipt | undefined>;
|
|
246
|
+
getAllReceipts(): Promise<InvestigationReceipt[]>;
|
|
247
|
+
getRelations(): Promise<EvidenceRelation[]>;
|
|
248
|
+
saveRelations(relations: EvidenceRelation[]): Promise<void>;
|
|
249
|
+
getMetrics(): Promise<BilmemMetrics>;
|
|
250
|
+
saveMetrics(metrics: BilmemMetrics): Promise<void>;
|
|
251
|
+
getRulesDir(): string;
|
|
252
|
+
loadRuleSets(): Promise<RuleSet[]>;
|
|
253
|
+
saveRuleSet(ruleSet: RuleSet, fileName?: string): Promise<string>;
|
|
254
|
+
addRule(rule: RuleDefinition, fileName?: string): Promise<string>;
|
|
255
|
+
appendRevision(snapshot: RevisionSnapshot): Promise<void>;
|
|
256
|
+
getRevisions(): Promise<RevisionSnapshot[]>;
|
|
257
|
+
getLatestRevision(): Promise<RevisionSnapshot | undefined>;
|
|
258
|
+
getDiff(sinceRef?: string): Promise<KnowledgeDiff>;
|
|
259
|
+
}
|
|
260
|
+
declare function formatKnowledgeDiff(diff: KnowledgeDiff): string;
|
|
261
|
+
|
|
262
|
+
export { type EffectivenessRatio as E, type JevRejectReason as J, type KnowledgeHealthCategory as K, type MetricEvent as M, Storage as S, type KnowledgeStatsReport as a, type StatsReport as b, desanitizeFileName as d, formatKnowledgeDiff as f, sanitizeFileName as s };
|