Colophon

This site is built by garp — and it carries its own copy. The repo commits the compiled binaries right next to the content:

bin/
  garp                # tiny shell shim — picks a binary by uname
  garp-darwin-arm64   # authoring, on my Mac
  garp-linux-amd64    # CI, on Cloudflare Pages

The whole deploy is: build command bin/garp build, output directory site/. Cloudflare Pages clones the repo, runs the committed Linux binary, and publishes the folder it writes. Nothing gets installed in CI — no Go, no Node, no package manager, no lockfile, no cache to warm. The build tool is just in the repo, a ~15 MB file, versioned like everything else.

What a garp repo looks like

content/      every file here becomes a page — content/colophon.md is this page
layouts/      page templates (Pongo2 — Jinja/Nunjucks-familiar)
components/   reusable fragments
data/         global data files, exposed to templates by filename
static/       copied to the output verbatim — CSS, images, host config
site/         the generated output (gitignored) — what actually deploys
bin/          the committed garp binaries
config.yaml   site name, base URL — and any extra key you add
HANDOFF.md    generated — how to build, edit, and deploy this exact repo

One command, garp handoff, produces that self-sufficiency: it writes bin/ and generates HANDOFF.md, a document describing this project's actual shape — its sections, its data files, which tools are in use, and the exact deploy settings. Any developer who clones the repo can build, edit, and ship it having never heard of garp. That's the point: garp is a private studio tool, and the deliverable can't be allowed to depend on it — or on me.

The CI-purity line

There's a hard rule about what may run where:

• In CI, via the committed binary: anything pure Go. Rendering, the data cascade, sitemap.xml and robots.txt synthesis — the build reads only the repo, so it works identically on any machine, forever.
• On my Mac, at authoring time: anything that needs an external tool. The search index on this site is built by Pagefind — an external CLI — so garp runs it locally and the index is committed to static/, where a plain build just copies it. Favicons and OG images are generated the same way: run once, committed as plain files.

The CI build never hard-depends on an external binary being installed. If it did, the deploy would be fragile and the whole handoff guarantee would break — a repo that "builds anywhere" except when some tool is missing doesn't build anywhere.

Garp's own dependencies are vendored into its source, so the binary itself rebuilds offline from a snapshot — and Go's compatibility promise means it keeps compiling for decades.

What this site ships

Everything on this page is the stock kit, dogfooded end to end:

• Templates — Pongo2 layouts and components; pages are Markdown with YAML frontmatter, merged through a three-level data cascade (global → directory → page).
• Blog + Atom feed — stamped by garp blog; the feed is a plain template that loops the blog collection. The listing page is just a page that loops collections.blog — garp never auto-generates pages.
• Kitchen sink — /kitchen-sink is generated from this site's own stylesheet: every design token in the @layer config block, rendered as live var() references, so the reference page can't drift from the CSS.
• Favicons and OG images — generated from one square source image and one committed font file, as plain PNGs in static/.
• Search — a committed Pagefind index; the UI is Pagefind's own widget, loaded only on the search page.
• Zero client-side JavaScript by default — view source on the home page and the only <script> element is a speculation-rules block: declarative JSON the browser reads to prefetch links on hover, a platform primitive, not code. Anything beyond that (the search widget) is an explicit, per-page opt-in.

The CSS is one hand-written stylesheet — system font stacks, no web fonts, no framework. The type you're reading is whatever your OS considers a serif.