I build software with coding agents under positive control: every change planned, gated, reviewed and shipped the same way.

Every session starts here. It surfaces ready work in priority order and routes it by shape and board state.

The agent explores the codebase and drafts a design doc. Nothing is an issue yet. The doc is a proposal; issues are a commitment.

# Home thread — design

Status: Approved (G1, 2026-10-03)
Date: 2026-10-03
Slug: home-thread
**Feature branch:** feature/home-thread

The home page of markevans.io is one real feature moving through the delivery
chain, played as a self-running, steppable sequence of flight strips on a git
spine, with a radar scope as the console.

A question comes up that would derail the design. I open an isolated thread, settle it there, and bring back only the findings.

While designing this page I set it aside for one question: what shows a change moving under control? I looked at the paper flight strips air traffic controllers pass between bays, and at how git draws a branch history. What came back: each step is a strip of ruled cells (Ctl, Bay, Rmk), the board's four states are the strip bay, and the sequence runs down a git graph that forks, merges and loops.

I read the design doc and approve it, send it back, or cut it down.

We drew four designs and compared them side by side, then took elements from two of them to agree on the initial design.

One sized issue becomes a task file, an implementation plan and a branch. The issue number threads through all of them.

registries · tailwind · tailwind-build · tokens-only · color-means-role · typeface-means-speaker · content-is-files · no-invented-content · testing

I read the implementation plan before any code exists.

The first slice forecast about 1,600 lines across 33 files, past the 25-file limit. I split it: tokens, loader and gates first (#14), the static page second (#21), so nothing user-facing changed until the foundation was in.

The agent loads the task file and builds. Tests first, one commit per logical unit.

19 files changed, 1,040 lines added, 35 removed

Before any PR exists, an agent with a new context reviews the branch. It has not seen the implementation conversation, so it reads the diff cold.

I invoke this one myself. Opening a PR has an audience.

An agent will eventually miss a rule, so the rules a machine can check are checked. None of these depend on the agent cooperating.

scan_ruby ✓ · scan_js ✓ · lint ✓ · gates ✓ · test ✓

A person reads the PR. On a feature built in slices, each slice is read by /pr_review from a fresh session, and the feature PR is read by a human against the design doc.

The review shown here is slice #23's: eight comments from /pr_review, run by the agent in a fresh session. Each was answered with a fix commit. One added content:check, the gate that held this page until its content was filled.

Each review comment gets a fix or a reply, then its conversation is resolved. Other people are reading those threads, so I choose when this runs.

Nothing merges with an open conversation.

One click. Everything after it is automation.

Merged to main in #22 on 2026-10-04, then held: the production build runs `content:check`, and this page's own placeholders failed it until each one was filled. Then `kamal deploy` to markevans.io.