How I work
The specification is the only thing holding an agent to account.
An agent will produce something plausible for almost any instruction. The question is never whether it produced code — it is whether anyone wrote down what "correct" meant before it started, and checked afterwards.
Every ticket is specified before implementation begins: scope, deliverables, observable acceptance criteria, dependencies. The output is then reviewed against that specification rather than accepted because it runs. This is ordinary practice in regulated industries, where an outcome has to be traceable, documented, defensible and repeatable — and it turns out to be exactly what agent-written code needs.
Six projects, six questions
Each repository isolates one idea, so that what it demonstrates is not confounded by the others. They are experiments, not a portfolio.
| Project | The idea under test | Verifiable artefact |
|---|---|---|
| test-assist | One specification, two independent implementations | Both builds ship · 384 tests · 3 workflows · 4 releases |
| audiobook-tracker | Local-first and offline-first, with optional sync | 70 tests over offline behaviour and sync |
| cah-pwa | Behaviour in editable prompt files, not code | Plan-to-scaffold generator · phase decision records |
| crossword-helper | Release engineering for already-installed users | Versioned service-worker caching · 20 CI runs |
| town-weaver | Hosted API migrated to fully client-side inference | Runs offline · no keys · no per-call cost |
| grocery-assist | Specification deliberately ahead of code | Plan exists; code deliberately does not yet |
The artefacts recur across all six because the method travels between domains rather than being reinvented per codebase: phase decision records that lock scope before implementation and get amended in the open when a design proves wrong; ticketed backlogs with explicit dependency graphs and exit criteria; and ID-coded test plans whose case IDs stay stable across unrelated projects, so coverage is measured against the plan rather than estimated.
What gates this site
The same discipline, pointed at my own work. Every push to
main runs five gates, in order. If any one fails, nothing
deploys.
- 01
Build
The site compiles to static output, or the run stops here.
- 02
Regression suite
Playwright against the built output: every page renders its expected heading, navigation works at mobile and desktop viewports, the contact form validates and submits, every internal link returns 200, and no page logs a console error.
- 03
Accessibility
axe-core across every page. Zero violations at WCAG 2.1 AA — not "few", zero.
- 04
Performance budgets
Lighthouse on mobile emulation, with enforced floors on performance, accessibility, best practices and SEO.
- 05
Claim verification
Every number on the Work page lives in one configuration file and nowhere else. This gate fetches the cited repositories, re-counts using the real runners, and fails the build if any figure has drifted — so the page claiming its numbers are verifiable is the page that cannot deploy with a wrong one.
This gate exists because of a real defect. A published count of 71 tests turned out to be 70: a
grephad matched/register/i.test(t)— a regular-expression call, not a test. Machines now count the tests.
Currently building
TestForge — in development. More when there is something verifiable to show.