# The Coding Law hashes every file before and after edits, and refuses commits that skip the check

slug: coding-law · https://miscsubjects.com/a/coding-law · category: build · tags: coding-law, build, deployment, hash-verification, agent-safety · updated 2026-08-06T07:39:11.047Z

## A hash to start, a hash to commit

The build enforces a rule called CODING_LAW. Its source file opens with a single line that states the entire mechanism: "Where a hash taken at the start and a hash taken at the commit meet." The law was created by owner order on 2026-08-05. The deploy script restates the same idea in its header comment: "Every code file being shipped must be covered by a committed lease — one that recorded a start hash matching the file as the agent read it, and a commit hash matching the file as it was written."

The law exists because coding agents read a file, decide to edit it, and sometimes write to a version that has already changed underneath them. Another session, a teammate, or a parallel agent may have committed to the same path between the read and the write. Without a guardrail, the agent's edit overwrites the intervening work silently. The Coding Law makes that overwrite impossible by refusing the commit.

## How a lease works

The flow has two phases. When an agent is about to edit a file, it posts the file path and a SHA-256 hash of the file's current contents to the start endpoint. The server stores this as an open lease in a D1 table called `code_leases`. The lease records the agent identity, the file path, the start hash, and a timestamp.

When the agent finishes editing and is ready to commit, it posts the same lease ID plus a new hash — the hash of the file after editing. The server checks that the lease exists, that it is still open, and that the start hash matches what was recorded. If everything lines up, the lease is marked committed with the new hash. If the start hash does not match — because the file changed between the read and the commit attempt — the server returns a 409.

The object file that defines the law's instructions specifies the trigger: it "Fires the moment you are about to edit any file under functions/, scripts/, migrations/, workers/, apps-script/, .claude/, or src/ under misc-cli." Every code path in the build is in scope.

## The deploy gate

The deploy script `scripts/check-coding-law.mjs` runs before any code reaches the live site. It collects every file that changed in the current deploy, then queries the lease database. The script's own comment describes the coverage check: "A file is covered when some committed lease's new_sha equals the file's current hash."

For each changed file, the script hashes the file on disk and looks for a committed lease whose `new_sha` matches that hash. If every changed file has a matching committed lease, the deploy proceeds. If any file lacks a lease, or the lease's commit hash does not match the file's current contents, the deploy is refused.

The script's final output block reports the result:

```
law: "CODING_LAW",
examined: files.length,
scope: CODING_LAW_SCOPE,
checked: `${files.length} changed code file(s) each covered by a committed lease matching its current contents`,
```

## The overwrite refusal

The most important enforcement point is the 409 `overwrite_refused` error. The API source describes it in its own response definition: "409 overwrite_refused names the lease that committed your file after you read it. Re-read the file, redo the edit on the now-current version, and start a new lease."

This is the moment the law catches a stale edit. The agent read the file at hash A. Another lease committed hash B to the same path. Now the agent tries to commit, but its start hash A no longer matches the file's current hash B. The server refuses, names the conflicting lease, and tells the agent to re-read and start over. The intervening work is preserved; the stale overwrite never lands.

## The conformance claims

The law object file enumerates what conformance means. Its claims list includes: "every changed code file in a deploy is covered by a committed lease" and "a commit whose declared base hash no longer matches the file on disk is refused with 409 overwrite_refused." These are not aspirations — they are the conditions the deploy script checks on every ship.

## Why it matters

A coding agent that can overwrite a teammate's work is a liability. The Coding Law turns the agent's own read-then-edit pattern into a lease that the server tracks. The agent cannot skip the lease — the deploy script refuses to ship uncovered files. The agent cannot write to a stale version — the commit endpoint refuses mismatched hashes. The law is a small mechanism: two hashes, one table, one check. What it prevents is the one failure mode that silently destroys work.

## Sources

1. functions/api/coding-law/[[path]].js line 1 — https://miscsubjects.com/api/coding-law
2. scripts/check-coding-law.mjs lines 3-5 — https://miscsubjects.com/a/coding-law
3. functions/_lib/coding_law_object.js lines 102-103 — https://miscsubjects.com/api/articles/coding-law?format=markdown
4. scripts/check-coding-law.mjs line 61 — https://miscsubjects.com/a/coding-law
5. functions/api/coding-law/[[path]].js line 74 — https://miscsubjects.com/api/coding-law
6. scripts/check-coding-law.mjs lines 120-124 — https://miscsubjects.com/a/coding-law
7. functions/_lib/coding_law_object.js lines 153-154 — https://miscsubjects.com/api/articles/coding-law?format=markdown