The setup
VIMES is an agent-first remote IDE for Claude Code, built and maintained by our founder: a daemon owns every Claude Code process on a dev box and streams structured state to any browser, so a phone is a full peer of the desk. The premise is that when an agent writes most of the code, the human's job shifts from typing to supervising, and the tooling should be built for that job.
This case study is not about what VIMES does, though. It is about how it is built, because the method is the thing we are actually selling when we sell an audit: the ability to tell disciplined engineering from engineering that merely looks disciplined. Everything below is public, in the repository, right now.
Discipline you can grep
Plenty of projects claim rigor in the README. VIMES turns rigor into something the build can fail on.
The core package is pure logic, with clocks, randomness, and I/O injected at the boundary, and a CI grep gate fails the build if Date.now, Math.random, or crypto.randomUUID appears anywhere in core. Determinism is proven by byte comparison rather than asserted: six scenario profiles, including flaky-mobile, concurrent-clash, cold-restart, and hostile-input, run twice on every CI pass, and a single differing byte between the two runs' event logs fails the gate. Underneath it all sits an append-only event log as the source of record. Every read model is a fold over that log, and replay equivalence (booting from a snapshot must equal replaying from empty) is a tested invariant rather than a design intention.
Decisions with receipts
The docs directory is the part an audit firm cares about most.
The decision record, decisions.md, is append-only and now holds 84 numbered entries. A reversal is a new dated entry, never an edit, and decision numbers are preserved forever. Each entry records what was decided, why, the evidence behind it (a harness probe, a calibration run, a spike result), and which open question it closes.
The measurement record, calibration.md, refuses naked numbers. Its own rule is that performance bands "are pinned with their assumptions (workload profile, device, network condition), never as bare numbers." Its status line, as of this writing, still reads "No bands pinned yet," because the measurement instrument has not priced anything, and pretending otherwise would be fiction.
The rest of the suite follows the same pattern: open-questions.md, where undecided items live with their trigger and current lean until they migrate into the decision record, a risk-register.md, and twenty slice documents, each scoping what is in, what is explicitly out, and the exit gate that closes it.
One concrete example of the system working: during slice 0, an implementing agent hit a contradiction between the recovery design and the state machine's legal edges. It reported the conflict instead of silently patching around it. The resolution, adding a spawning→interrupted edge, is decision D13, dated, with the rejected alternative and its failure mode written down, and the test profile was extended so the new edge is exercised, not just legal.
The honesty clause
The README's status line, verbatim:
"Status: mid-build, and not yet packaged for anyone else to run. ... Read it as a working system with its reasoning on display, not a product you can adopt today."
He could have waited to show VIMES until it was a polished product. We are pointing at it now because the reasoning on display is the point: this is the standard we audit against, applied in public, mid-build, when it is hardest to keep.
Why this matters to a buyer
When we audit your systems, the questions we ask are the ones this repository answers about itself. Where is the decision recorded? What evidence backed it? What was rejected, and why? What does CI actually enforce, versus what the README merely claims? An auditor who has never worked under that discipline can still sell you a checklist. The judgment we sell comes from living with it.