---
title: "The Build Fails If a Single Byte Is Out of Place"
description: "Our founder's agent-first remote IDE for Claude Code runs under the same discipline we ask of audit clients: an append-only decision record with 84 numbered entries, calibration numbers that never ship without their assumptions, and a CI gate where a single differing byte fails the build."
canonical: "https://www.clocktowerassoc.com/specs/case-studies/vimes"
date: "2026-08-18"
tags:
  - "Engineering Discipline"
  - "Founder Project"
  - "Machine-Enforced"
generated_from: "docs/case-studies/vimes.md"
---

# The Build Fails If a Single Byte Is Out of Place

*Decision discipline, machine-enforced on our founder's own project, in public, mid-build.*

---

# 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.

## Related

- [VIMES in the Showcase](https://www.clocktowerassoc.com/showcase/vimes): What VIMES is and where it stands, including the mid-build status disclosure this study quotes.
- [The Repository](https://github.com/TickTockBent/vimes): Every claim in this study is checkable in the public repo: the decision record, the calibration rules, and the CI gates.