How hperkins.blog was built

01 The premise — prove, don’t describe

The structure was reverse-engineered from one job description — the WordPress VIP Solutions Engineer role — into five hiring criteria: build and demo a proof-of-concept, fluency in enterprise governance language, awareness of enterprise constraints, the motion of a sales cycle, and written communication treated as a first-class work sample. Every section of the site carries one of them.

The information architecture mirrors a sales call. A landing strip answers the buyer’s three questions; then Demo, AI Governance, Work, and About/Resume run the presentation, the discovery conversation, the references, and the close — four items, nothing competing for a twelve-second scan.

02 The platform, chosen then outgrown

The hosting choice was an audit, not a default. WordPress.com Business sat at the intersection of near-zero maintenance, a real code-to-production path, and infrastructure that makes the same governance-first argument as the work it showcases — and the trade-off was stated plainly rather than hidden: Business is not VIP.

Then the centerpiece forced a move. Flavor Agent — the governed-AI plugin the whole site exists to demonstrate — could not run under WordPress.com’s plugin constraints. So the install was exported, imported onto a self-hosted DigitalOcean droplet, and development continued there. The work set the requirements for the infrastructure, not the other way around.

03 Two design systems

The design language was built twice. The first — @hperkins/tokens-kit, an ‘evidence ledger’ — was a React kit of fourteen components over a deliberately quiet neutral palette, where the only saturated colour was the three status hues. Its idiom was compose components, don’t author classes: status shipped as a prop, never faked with markup, so a ‘merged’ row was the same green and the same word everywhere it appeared.

That system was then re-skinned into the current one — Imladris — a Rivendell-inspired parchment, evergreen, and mallorn-gold serif editorial system of nineteen components and six page templates. The shift traded a neutral proof-ledger for a literary register that frames why the work matters, while keeping the evidence layer intact underneath.

04 The theme — a design system in theme.json

The site runs on a custom block child theme — HPerkins Tokens — on Automattic’s Assembler parent. Its premise is that the design system lives in theme.json as a small, named token vocabulary, and every component is a consequence of those tokens rather than a parallel set of hardcoded values.

The colour contract is locked at the schema level: the stock swatches and every custom colour, gradient, and duotone picker are turned off, so to change a colour you edit theme.json, not a block. The four families are self-hosted, not pulled from a CDN. And the token layer round-trips 1:1 with the Imladris project kept in claude.ai/design, diffed on every pull — so a token ‘refresh’ changes nothing, because nothing is left to drift.

05 The content system — one template, proved three ways

Every Work entry follows one locked shape — Problem, Build, Outcome as a causal list, artifact buttons, and a close — and the published entries each end on the same line, trust is structural, proving it a different way: architecturally, iteratively, methodologically. Visual and non-visual work get different treatments by design — Evidence First for proof that lives in changelogs and review records; Proof + Product where a screenshot materially proves what shipped; Operational Story reserved for the Flavor Agent pair.

The written work sample is the long-form essay ‘Expose, Govern, Attest’, which reads WordPress’s AI stack as three nested rings of trust: Vilya, the Ring of Air, exposes a capability an agent can inspect; Narya, the Ring of Fire, governs use the owner can audit; and Nenya, the Ring of Water, attests provenance a stranger can verify.

The essay states the honest part out loud: the rings sit at different maturities — governance has shipped primitives, exposure is shipped at its foundation with the agent-facing layer still in proposals, and attestation is still in-review pull requests. That is where WordPress core is, not where I wish it already were.

06 The build loop — verify before you ship

The inner loop runs locally first, with render-verification before anything reaches the live site: a host-shim mu-plugin, wp server, and Playwright confirm that the tokens resolve, the page CSS loads, and the console is clean. The design system stays in sync through a scripted design-pull from the claude.ai/design project, which diffs the token CSS against theme.json and reports any drift. Verification is the gate, not an afterthought — the same standard the work itself is built to meet.

07 What the git log shows

The current system’s build is in the record. The theme repo carries the Imladris migration end to end — the re-skin from the first system to the parchment one — as thirty commits across two days, each a reviewable step, with the live site reflecting each as caches cleared. The source is public, so the claims here resolve to it.

08 The discipline — the medium is the argument

One rule runs under every other choice: a claim is only as good as the instrument that can check it, and the instrument should be one the author does not control — a changelog line, a maintainer’s merge, a signed manifest, a deploy that either succeeded or didn’t. That is why the site shipped in sequence rather than all at once, and why a stale claim gets corrected rather than defended.

Because status lives in components and colour lives in tokens, a project added next month inherits the same rules: it shows its state three ways and links its artifacts, and an unfulfilled proof shows up as a visible gap rather than a quiet omission. The site does not claim the work is verifiable — it is built so that an unverifiable claim has nowhere to hide.