@unerr-ai/unerr 0.2.5 → 0.2.7
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 +19 -8
- package/dist/cli.js +2751 -2477
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -3,13 +3,13 @@
|
|
|
3
3
|
</p>
|
|
4
4
|
|
|
5
5
|
<p align="center">
|
|
6
|
-
<strong>
|
|
6
|
+
<strong>Your AI agent has read your codebase. It was never briefed on it.</strong>
|
|
7
7
|
</p>
|
|
8
8
|
|
|
9
9
|
<p align="center">
|
|
10
|
-
<strong>unerr is operational intelligence for your codebase</strong> —
|
|
11
|
-
|
|
12
|
-
|
|
10
|
+
<strong>unerr is operational intelligence for your codebase</strong> — the lived history your team carries in its head:<br/>
|
|
11
|
+
what's been tried, what broke, what the team decided. One local runtime, <em>behind</em> every MCP your agent already speaks,<br/>
|
|
12
|
+
that hands the agent that judgment the moment it starts working — instead of letting it relearn your repo, every session.
|
|
13
13
|
</p>
|
|
14
14
|
|
|
15
15
|
<p align="center">
|
|
@@ -28,11 +28,11 @@
|
|
|
28
28
|
<p align="center">
|
|
29
29
|
<code>npm install -g @unerr-ai/unerr</code>
|
|
30
30
|
<br /><br />
|
|
31
|
-
<sub>Zero configuration. Install, restart your IDE, and the next prompt
|
|
31
|
+
<sub>Zero configuration. Install, restart your IDE, and the next prompt already knows your repo.</sub>
|
|
32
32
|
</p>
|
|
33
33
|
|
|
34
34
|
<p align="center">
|
|
35
|
-
<sub>Measured, not estimated:
|
|
35
|
+
<sub>Measured, not estimated: the agent lands on the right code while spending <strong>86–90% fewer tokens</strong> getting there —<br/>
|
|
36
36
|
same corpus, same tokenizer, with a fidelity gate that discards any "saving" that lost the answer. <a href="./benchmarks/README.md">See the benchmarks →</a></sub>
|
|
37
37
|
</p>
|
|
38
38
|
|
|
@@ -40,7 +40,11 @@
|
|
|
40
40
|
|
|
41
41
|
## The old way is over
|
|
42
42
|
|
|
43
|
-
Coding agents now write the code.
|
|
43
|
+
Coding agents now write the code. They've read every line of your repo — and not one of them has been briefed on it. They don't know what the team tried here and abandoned, why this function drifted, what broke the last time someone touched it, or which decision is load-bearing. A new engineer gets that briefing on day one. The agent starts cold, every single session.
|
|
44
|
+
|
|
45
|
+
So it guesses. It greps where a senior engineer would check the call graph. It re-derives on Tuesday what it worked out on Monday. And the knowledge that *would* brief it — who changed each file and why, what failed before, the conventions the team accreted — is scattered across one tool for memory, another for the graph, a third for context, none of which can reach across the others.
|
|
46
|
+
|
|
47
|
+
**unerr is the layer that ends the guessing.** One per-repo runtime, behind every MCP your agent already speaks, that carries your codebase's lived history and hands the agent that judgment the moment it starts — so it lands on the right code without burning turns, and sees what a change will break before it breaks it.
|
|
44
48
|
|
|
45
49
|
| The old way | With unerr |
|
|
46
50
|
|---|---|
|
|
@@ -59,7 +63,7 @@ You've felt all four of these in the last 48 hours:
|
|
|
59
63
|
- The agent reads a 2,000-line file to find a 5-line function, then still doesn't know that function has 24 callers in six other files.
|
|
60
64
|
- You don't trust the agent to refactor anything important. It treats your codebase like a flat string of text — locally correct, globally wrong.
|
|
61
65
|
|
|
62
|
-
These aren't four problems. They're one:
|
|
66
|
+
These aren't four problems. They're one: **your agent acts on your codebase without ever having been briefed on it.** It greps where a senior engineer would check the call graph, and it relearns on Tuesday what it worked out on Monday.
|
|
63
67
|
|
|
64
68
|
---
|
|
65
69
|
|
|
@@ -82,6 +86,13 @@ The outcome you get is **agents that behave like senior engineers** — checking
|
|
|
82
86
|
|
|
83
87
|
## See it in action
|
|
84
88
|
|
|
89
|
+
**Watch it run** — a real Claude Code session in this repo. The agent attempts a signature change to `extractFilePath`; *before* the edit lands, unerr surfaces **12 callers at risk across 4 files**, so the agent updates every one of them in the same turn instead of breaking them silently.
|
|
90
|
+
|
|
91
|
+
<p align="center">
|
|
92
|
+
<a href="https://youtu.be/pL1izMwYZpI"><img src="https://unerr.dev/open-cli/video/unerr-cascade.gif" alt="unerr cascade guard firing inside a live Claude Code session — 12 callers surfaced before a signature edit" width="760" /></a>
|
|
93
|
+
<br/><sub><strong>Cascade guard, live</strong> · unerr catches the 12 callers of <code>extractFilePath</code> before the edit ripples. ▶ <a href="https://youtu.be/pL1izMwYZpI">Watch the full demo on YouTube</a>.</sub>
|
|
94
|
+
</p>
|
|
95
|
+
|
|
85
96
|
Two places unerr shows up so you know it's working — inside the chat, and in a browser.
|
|
86
97
|
|
|
87
98
|
**Inside the chat.** Every coding turn opens with one line naming what unerr loaded ("loaded a convention you wrote yesterday for `src/payments/gateway.ts`…") and closes with one line totalling what it saved you ("this turn: 2 catches · ≈ 4.2k tokens saved · +5 turns of headroom this session"). Catches are *named, countable events*, not a ratio.
|