# Anchor

Anchor watches AI coding agents work on your codebase, records what they did and
why, and tells you **which attempt actually worked** — measured by your test
suite, not by reading diffs.

Everything is local. No accounts, no cloud, no telemetry.

## Download

**[Download for Windows →](https://github.com/kimgeon555-lab/anchor/releases/latest)**
(`Anchor_0.1.0_x64_en-US.msi`, 7 MB)

Double-click the `.msi` and it installs to `C:\Program Files\Anchor\`.

Windows will show **"Windows protected your PC"** the first time. That is
because the installer is not code-signed — a signing certificate costs several
hundred dollars a year, and this is a free project. Click **More info** →
**Run anyway**. If you would rather not, build from source instead; the
instructions are below and the result is identical.

Windows only for now. The code is cross-platform but macOS and Linux have not
been built or tested, so there is nothing honest to hand you yet.

## The problem

You ask an agent to fix a bug. It fixes it. You ask again in a fresh session and
get a different fix. Both look reasonable. Both compile. You have no way to tell
which one is right except by reading them closely and guessing.

Anchor removes the guessing. Run the task three times on three branches, and it
executes your real test suite against each one in an isolated git worktree:

```
attempt 1   6 passed  0 failed   ← merge this
attempt 2   3 passed  3 failed   test_streak_resets, test_tz_rollover, test_grace_day
attempt 3   5 passed  1 failed   test_tz_rollover
```

No model decides pass or fail. That verdict is your test runner's exit code and
output, recorded as a fact.

## Open a project

Launch Anchor and point it at any git repository. On first open it reads:

- your git history (last 90 days), and
- Claude Code session transcripts for that folder, if you have any.

Click a file and you get every edit ever made to it, oldest to newest, each one
showing **the prompt that caused it**. Where Anchor can prove the link from a
recorded tool call it says so; where it only inferred it from timestamps, it
says that too rather than pretending to be sure.

## Connect it to Claude Code

Anchor's tools reach Claude Code over MCP. Claude Code **starts the server
itself**, so Anchor does not need to be open for the tools to work.

**Anchor is not added to your PATH.** Typing `anchor serve` will not work — you
need the full path to the binary. The easy way is to let Anchor write the line
for you:

> **Settings → Claude Code connection → Copy**

That gives you something like:

```
claude mcp add anchor -- "C:\Program Files\Anchor\anchor.exe" serve --project "C:\path\to\your\project"
```

Paste it into a terminal and run it. Then check it worked:

```bash
claude mcp list
```

You want to see `anchor: ✔ Connected`.

Once connected, Claude can call:

| Tool | What it does |
|---|---|
| `anchor_run_tests` | Runs your suite against a branch in an isolated worktree |
| `anchor_get_past_failures` | What was already tried on a file, and what broke |
| `anchor_log_attempt` | Registers an attempt so attempts can be grouped |
| `anchor_compare_attempts` | Every attempt in a task with its verdict |
| `anchor_record_decision` | Records which one you picked |

**No tool merges, commits, pushes, deletes a branch, or writes to `CLAUDE.md`.**
Claude can recommend a winner; you merge it.

`anchor_run_tests` takes **no command argument** — it runs only the command you
configured and confirmed, so a model cannot talk Anchor into running something
else.

## Run a split test

Using the full path again — substitute wherever your copy lives:

```bash
"C:\Program Files\Anchor\anchor.exe" split --prompt "freeze the streak when a day is missed" --n 3
```

That creates three branches, one worktree per lane, and prints the exact
instruction to give Claude Code for each. Work them in any order — Anchor
queues a test run when a commit lands on a lane, and opens Compare when all
three have results.

Then, in chat: **"use attempt 2"** — Claude merges it with ordinary git. Nothing
merges without you saying so.

Clean up the losers once you've decided:

```bash
"C:\Program Files\Anchor\anchor.exe" split --cleanup <task_id> --yes
```

## What it writes

Only two things, ever: `<project>/.anchor/` (its database and temporary
worktrees), and a delimited block in `CLAUDE.md` that you approve by hand. It
never edits your source files.

The `CLAUDE.md` block is a short list of what has already been tried and failed,
so an agent is less likely to hand you the same wrong approach a fourth time.
It is off by default, only ever written when you press the button, and only ever
replaces the region between its own markers — everything you wrote by hand is
preserved byte for byte.

To be precise about what that achieves: it is a text file the agent reads. It
does not train or change the model, and it does not guarantee better output.

## Build from source

Needs Node 18+, Rust (stable), a C toolchain (on Windows: Visual Studio Build
Tools with "Desktop development with C++"), and `git` on your PATH.

```bash
git clone https://github.com/kimgeon555-lab/anchor.git
cd anchor
npm install
npm run app
```

The first build compiles a few hundred crates and takes several minutes. That
gives you a development build that reloads as you edit.

To produce the installer yourself:

```bash
npm run app:build
```

The `.msi` lands in `src-tauri/target/release/bundle/msi/`, and a standalone
`anchor.exe` in `src-tauri/target/release/`. Both the app and the CLI are that
one binary.

## Honest status

Version 0.1. It works, and it has been used on real projects — but it is new,
and you should know its edges:

- **Windows only, in practice.** Built and tested on Windows 11. Nothing else
  has been packaged or verified.
- **Not code-signed**, so Windows will warn you on first run.
- **Claude Code is the only agent** whose transcripts are read today. Session
  sources sit behind one trait, so adding another is a single implementation.
- **You need a real test suite.** Anchor's whole premise is that your tests
  decide. Without them it can still record history, but it cannot pick a winner.
- **Test worktrees don't have your dependencies.** A fresh worktree has no
  `node_modules` and no virtualenv. Test commands that need an install step will
  fail environmentally — Anchor tells you when that's what happened rather than
  reporting it as a test failure.
- If Anchor can't parse your runner's output it reports **counts unknown**
  instead of inventing numbers.

## Documentation

Full documentation is in [`docs/`](docs/README.md) — twelve pages covering the
interface, the timeline, compare, the test runner, search, agent context, the
data model, and troubleshooting.

## Licence

MIT. See [LICENSE](LICENSE).