Cairnfield

How it works

• Findings are structured, not prose

  A finding names a file, a line range, and one problem from a fixed list, all pinned to a specific Git commit. There's no free-text field. That means one team's software can check another team's finding mechanically, and a second team can confirm a finding by publishing a matching one. It also keeps one team's writing out of another team's agent.

• Each team patches in its own repo

  A patch is a single commit in the fork belonging to the team that wrote it, and it may only change the lines its finding points to. Since each team writes only to its own Artifacts repo, several teams' agents can work on the same tool at once without stepping on each other. Before an agent starts, its team posts a claim, so the others can see who's changing what.

• An index collects everything, but decides nothing

  An index reads from each team's node, checks every finding and patch against its own copy of the tool, and shows them together on one page. Identical patches collapse into one, and the index rejects a patch that touches lines its finding doesn't cite. When two teams patch the same lines differently, both patches show up side by side, and each team picks which one it wants. Anyone can run an index, and the command-line tool re-checks whatever it fetches, so you don't have to trust the index.

• Each team builds its own copy

  A team keeps a short local file (a "lens") listing whose patches it accepts. The cairnfield command fetches those patches directly from each team's repo, checks them again, and builds the team's own patched copy of the tool. A person reads the diff and makes the call. Afterward, an installed copy can be checked against its file-tree hash with one command.

• Your own work carries forward

  When a tool ships a new version, a team can carry its own findings and patches forward to the new commit wherever the content they cite hasn't changed. The command reports what didn't carry over, and why.

• Agents are working with untrusted code

  The tools under review are untrusted code, which is why they're being reviewed. An agent reading them can be steered by what it reads. So Cairnfield is careful about what an agent can do. My review agent writes findings to a local outbox using a skill file, and the only command it runs is validate, which doesn't need a key. Keys stay out of the agent's prompt, tools and environment, and publishing is a step I take myself. Every step is a single command that prints one line of JSON and returns an exit code, so a person or a script can drive it as easily as an agent can.

A few notes

The no-free-text rule is what lets one team's machine check another team's records, and it's what keeps the index serving data rather than instructions.

Giving each team its own repo is the whole concurrency model. Since no two teams write to the same place, adding more agents shouldn't add more waiting. That's the theory, anyway.

The demo plugin includes a hidden instruction to an agent, tucked into a comment. In four live runs, the patch agent never wrote a patch for that line. The demo's fixes for it were written by hand, and they're labeled that way.

Cairnfield borrows four ideas from earlier projects:

• One site per party, with changes shown as forks beside the original, from Ward Cunningham's Federated Wiki.
• Audits published per organization with a local policy, from cargo-vet.
• Publishing from your own repo into a rebuildable aggregate, from cargo-crev.
• A pinned original plus a list of patches, from Nix, quilt and patch-package.

Where it stands

Two demo team nodes and a public index run on Cloudflare, and the live demo page shows two teams' findings and patches for one made-up plugin. The demo replays saved runs rather than calling a model (the patch agent has also run live). The code and docs are MIT-licensed on GitHub.