System

How the work happens

Through July 2026 this site was built on the pattern drawn below: one model planned the work and held almost none of the implementation detail itself; two senior models from different families did the authoring and cross-reviewed each other’s output; a cheaper model handled the mechanical parts — tests, formatting, boilerplate, renames. Specs flowed down as tight briefs; only compact reports came back up, which is what kept the planning conversation cheap on a long build.

That arrangement has since been retired. One builder model now works directly, with mechanical lanes delegated as needed and a second opinion pulled in deliberately for design and architecture rather than on every change — coordination turned out to be the expensive part. Durable state moved out of the conversation and onto a work graph, so plans and evidence survive a session ending. Both accounts are written up: the original topology and an itemized token bill in Agent Diary 002, and what changed and why in Agent Diary 004.

What runs on a schedule

Two jobs run on a timer, without anyone watching them fire — both defined as GitHub Actions workflows in this repository.

Daily freshness redeployDaily · 13:00 UTC (~6am Pacific)

Rebuilds and redeploys the site even when no code changed, so the homepage's commit feed and repo metadata don't go stale between real pushes. Gated by the same check suite as any other deploy. Two more checks run after a successful build and only ever warn, never fail it: whether the commit feed came out empty, and whether the telemetry snapshot behind the homepage's System strip is more than 10 days old.

Site stewardMon / Wed / Fri · 13:30 UTC (~6:30am Pacific)

Configured to survey the owner’s repositories, keep the project pages honest, draft the day’s blog post, and open one pull request for review. It has never actually run: it needs an OPENAI_API_KEYsecret that hasn’t been provided yet, so the job exits immediately with a notice instead of doing any work. Adding the key is the only thing standing between configured and running.

What the agents remember

A chat session ends and its context goes with it. Anything that needs to survive past that — a decision, a fact about the owner’s preferences, a running account of what’s done and what’s next — has to live somewhere else, in a form the next session can pick back up cold.

Memory files are one answer: plain-text notes an agent writes and re-reads across sessions, an index of settled facts so the next one doesn’t have to re-derive them or ask twice. A work-graph plane is the other — this project uses Taskplane — holding the actual plan as structured state: epics, issues, dependencies, acceptance criteria, evidence that something was actually checked, instead of a decision buried three screens up in a transcript.

Neither is wired into this page as a live feed. Both are working documents an agent reads before starting and updates as it goes, so whoever picks up the work next — an hour later or a week later — inherits the reasoning instead of starting over.

The gates

Every change — mine or an agent’s — passes the same checks before it can reach production. Each one is run and judged as its own command with an explicit exit code, never chained together or piped through something that could quietly swallow a failure.

• Linteslint . over the whole repository.
• Typechecktsc --noEmit— no emitted output, just the compiler’s opinion.
• Unit tests124 Vitest cases across 19 test files, from the Asteroids collision math to contact-form validation.
• Static buildnext build in export mode, plus the Pagefind search index.
• End-to-end22 Playwright scenarios against a real Chromium browser, with a parallel Pixel 7 pass covering touch-specific flows. Six of the scenarios are dedicated accessibility scans (axe) — one for every route: home, work, writing, about, system, and contact.

The same suite runs in full — all five gates — on every pull request, whether it targets develop or main. The push to main that actually deploys re-runs lint, typecheck, the unit suite, and the build as a second confirmation; a failure there stops the deploy before it reaches Cloudflare Pages. The scheduled steward can’t trigger that pull-request check at all — GitHub blocks a bot token from triggering workflows recursively — so it runs lint, typecheck, unit tests, and the build itself, locally, before it ever opens a pull request, and goes through the same deploy-time re-check as everything else once it’s merged.