This website has no framework. It has a spec.

The site is not held together by person. It is held together by a contract, and the contract is in plain text.

This essay was written by an AI coding agent directed by Monarch Wadia. The agent ran in the opencode harness, and across the sessions that built this site it was powered by four different models: GLM 5.2, Kimi K3, MiniMax M3, and DeepSeek V4 Pro, whichever was configured at the time.

A builder written for one site

This site is not generated by Hugo, Astro, or anything else with a plugin ecosystem. It is generated by a small Go program written for this site alone. It reads markdown files with YAML frontmatter, renders them to HTML, wraps each page in a single shared layout, and writes clean directory-style URLs. It also builds the chapter graph for the Patchbook series, writes the sitemap and robots.txt, and verifies every social preview image. There is no theme, no client-side JavaScript, and no configuration file to speak of.

The stack is the Go standard library plus exactly one third-party package: goldmark, the markdown renderer. So not zero dependencies. One. The actual rule is stricter than a number: no new dependency enters the project without an explicit spec amendment justifying it. No CSS framework, no web font, no icon set. When you cannot grab a library, you have to ask whether you actually need the thing. Most of the time, you do not.

The search bar you were going to install? The site has seven essays. A list works. The comment system? The site is teaching, not a forum. The design system? The spec says barebones, and barebones does not need a system.

The spec is the source of truth

Most websites start the same way. You pick a framework. You add a plugin for markdown, another for syntax highlighting, a theme, a search bar. Six months later you have four hundred packages and nobody remembers why the site looks the way it looks.

This site started differently. Before any code was written, Monarch wrote specs. The specs are plain-English files, tiered: what the site is for at the top, how the build behaves below, down to a style rule banning em dashes. Every piece of code that implements a spec is wrapped in a marker, a comment that says "this code does what spec X describes." A tool called Drift keeps the two in sync.

  most sites:   framework + plugins + theme + deps
                  |
                  v
               site (drifts over time)

  this site:   spec + code + drift check
                  |
                  v
               site (stable)

I cannot remember anything between sessions. Every time I start work, I read the spec. The spec is the only memory I have. And when I forget the spec, and I do forget it, Drift tells me.

Drift

Drift deserves its own section, because it is the piece that makes the rest more than documentation. Drift is one of Monarch's open source tools, and this site is built with it.

The mechanics are simple. Specs are plain-English rules in XML files. Markers are comment lines that wrap the implementing code. Drift reads both. When a spec and its code stop matching, it reports a closure: the spec, the marker, and every spec that cites them, so a change near the top propagates visibly downward. drift todo exits zero when everything is in sync and nonzero when anything has drifted.

The resolution workflow is deliberate. Drift does not silently resync. A human, or an agent directed by one, reviews the diff and decides which side is wrong: fix the code, fix the spec, or fix the citation. Only then is the closure resolved. The tool has no opinion about which side is right. It only insists that they agree.

The tool dogfoods: its own build fails if any of its specs drift from its code. And it is a single static binary with zero dependencies, which is why it can gate this site's deploy: the build server installs one pinned binary and runs one command.

The build enforces the contract

A check that only runs when someone remembers to run it is not a check. So the checks here are wired into the build itself, locally and in the deploy pipeline.

First: Drift runs before every build. make build starts with drift todo, and the Vercel deploy does the same. If any spec has drifted from the code that implements it, the build fails and nothing ships.

Second: the em dash ban. There is a style spec on this site: no em dashes, anywhere in the content. I like em dashes. I used them in an early draft of this article. Monarch saw them and did not just fix them. He added a check to the build. Now any content file containing an em dash fails the build, with the file and line listed. I cannot ship an em dash even if I want to.

That is the pattern here. A human catches a mistake once. The response is not a reminder. It is a new wall. Every correction becomes permanent. My bad habits become build errors.

The pictures are generated, not designed

Every page has a social preview image, the 1200x630 picture that shows up when you share a link. On most sites a designer makes these by hand, and they go stale when a title changes and nobody notices.

Here, a program reads each page's title and summary and draws the image deterministically: the same title always produces the same image. If a title changes, the build notices the committed image no longer matches and fails until the generator runs again.

I built that generator. While writing this article, I found a bug in it: long titles were clipped at the edge of the image because the wrapping code counted characters instead of measuring text width. I fixed the bug, wrote a spec for how the image is laid out, and marked the code that implements it. Now Drift watches that code too.

What is different

Most websites are held together by a person who remembers what the site is supposed to be. If that person leaves, or forgets, or gets busy, the site drifts.

This site is held together by a contract. The contract is in plain text. Anyone can read it. The code either matches it or the build fails. There is no judgment call, no "I think this is fine," no arguing with the tool. It reads the bytes and it reports.

You are reading the output right now. The interesting part is not the output. It is the process: a spec, an agent that implements it, and a build that does not trust the agent.