Colophon

How the posts get written

Every post here is drafted by an AI from notes I write first. The notes come before anything else: what happened, in what order, what broke, what it cost. The AI turns that into prose. It does not decide what happened, and it does not supply numbers.

Two rules sit above every other instruction in the repository. Never invent a fact, and never generate my experience. The second is what makes the first enforceable: if a detail is not in my notes then it is not mine, and a plausible invention is worse than a gap, because a gap gets fixed and an invention gets published. Where a figure was needed and I had not counted it, the draft carries a marker instead. Either I answer it or the sentence is cut. Nothing gets estimated into place.

After the draft comes a critic pass that returns objections and never rewrites prose, two rounds at most, then a fact-checker that traces every number, date and version back to the notes. Anything that does not trace is flagged as fabricated. I set the publish flag by hand, and no part of the process is allowed to set it for me.

The sentences are machine-made. What they describe is not.

How the site is built

Astro 7, static output, no adapter and no server. MDX files in a git repository, no CMS. Plain CSS with custom properties, no framework. The only JavaScript that reaches the page is Vercel Analytics.

Titles and metadata are set in JetBrains Mono, body text in Newsreader, both self-hosted from this domain as variable subsets under the SIL Open Font License. Nothing is fetched from a third-party CDN at runtime. Colours follow the operating system's light or dark setting and there is no toggle.

There is no syntax highlighting, because the blog does not publish code. The highlighter is switched off in the build configuration rather than merely unused. Evidence comes from artefacts instead: log excerpts, timing tables, error messages, lines off a bill.

Hosting is Vercel, deployed by its Git integration on a push to the main branch. DNS is Route 53 in ap-southeast-2, managed by Terraform and applied by hand.

What the outcomes mean

Every post is filed under one of four outcomes. It is the only thing on this site that takes a colour, and the word always says what the colour says — a hue never carries a meaning on its own here.

shipped

It went to production and it worked. The verdict is in.

still-running

In production, no verdict yet. Too early to say whether it held.

abandoned

Stopped on purpose. Not a failure — often the most useful thing in the post, and the reason this word is amber rather than red.

experiment

Tried, not concluded. It takes no colour at all, because there is no signal to give yet.

An outcome can change after publication. When it does the post says so, showing what it was and when it moved, rather than quietly rewriting the record.

The numbers in the footer

Four numbers, computed from this repository's git history each time the site is built. They keep the shape of the DORA delivery metrics because that shape is familiar, but only the first still measures software. The other three were pointed at the thing this site actually produces, which is writing, and the labels say what is counted rather than borrowing the original names.

Deploy freq counts changes landing on the main branch over the last 90 days, expressed per month; a design tweak and a published post each count once.Draft→live is the median time a post spends between its file first appearing in the repository and being published — time in the repository, not time from the idea, because my notes live outside git and it cannot see when I started thinking. Revised is the share of published posts that were changed after they went live, counting only edits below the frontmatter, so correcting a tag does not register as rewriting a paragraph. Time to revise is the median wait before that first change landed, across revised posts only.

An em dash means the number is not available. It never means zero. Nothing is estimated: where git cannot answer honestly the footer stays quiet, and if the build runs against an incomplete copy of the history all four go quiet together rather than measure a fragment.

The last three also stay quiet until they rest on at least three posts, because a median of one is that one value and a median of two is the midpoint between two. Right now draft→live rests on 2 posts, revised on the 2 posts published so far, and time to revise on the 0 posts that have been revised. The full definitions, including what is excluded and why, are indocs/METRICS.md.

The source

The repository is public, at github.com/dr3dr3/andre-blog. The writing rules are in docs/WRITING.md, including the list of words that are banned outright.