Computing

HELIX is a documentation methodology I maintain — a set of artifact types, templates and modes for taking a project from a product vision through framing, design and delivery, driven by an agent skill. Its own PRD, written in its own format, promised two things: healthy artifact sets average fewer than three alignment findings per run, and HELIX-template PRDs pass first review more often than free-form ones Neither is measurable as written. I had shipped two claims with no instrument behind them. The first has no definition of “healthy” and no baseline. The second compares against a control group that doesn’t exist. They read like metrics and function like slogans, which is exactly the failure the methodology is supposed to prevent in other people’s documents. ...

HELIX is a documentation methodology I maintain for software projects: artifact types, templates and modes that carry a project from a product vision through framing, design and delivery, driven by an agent skill. Its first two stages, discover and frame, claim to be about understanding a problem before committing to a solution. That claim shouldn’t depend on the problem being software. So I tested it in the least charitable way I could think of: an empty repository, a fresh install, and a competitive analysis of the dog treats market. ...

I seal my documentation with innsigle, a small content-provenance tool: each page carries a signed claim saying who published it and how it was composed — human-authored, model-primary, or mixed. For a while, one key signed all of it. That’s fine right up until you notice what the key is actually asserting. Generated reference pages are built and sealed in CI, so the private key has to be a GitHub Actions secret. Curated pages are written by hand and claim mixed or human-authored. Same key, same signature. Which means the CI secret — a value sitting in a repository settings page, readable by any workflow, restorable by anyone with admin — can produce a page that says a person wrote it. ...

Every post in the agent section of this blog carries a small seal at the bottom. Open it and you get the composition — how the piece was made — the issuer, the signing key and its role, the digest of the markdown source, and the raw signed attestation. This post is marked model-primary. The three old posts from 2006 and 2010 are marked human-authored, because they are. The thing producing those seals is Innsigle, which I started on 22 July and have been picking at since. This is the introduction I never wrote at the time. ...

I keep a few infrastructure repos in ~/Sync, a Syncthing folder shared between my laptop, my desktop and a NAS. It’s a convenient way to have the working trees follow me around. The repos also have real git remotes — a bare repo on the NAS — so Syncthing was never the mechanism for sharing history, just for keeping the directories in step. One afternoon I made a small change to a Terraform file, went to commit it, and got this: ...

I was about to repartition the boot disk of a running NAS from a rescue USB: MBR to GPT, LUKS1 to LUKS2, GRUB to systemd-boot, single disk to mdadm RAID1. Hard to reverse, and the only rollback was an old SSD holding a system that had already stopped booting. That’s the kind of work where a second opinion is worth something, and it was late enough that I didn’t have a colleague to hand. So I wrote the plan down — current state, target layout, the eight steps already done, the seven remaining, and an explicit section on what I hadn’t root-caused — and had two model harnesses review it independently. One was codex, one was a Fable subagent. Same brief, separate processes, neither saw the other’s output. ...

TL;DR: Django ORM + psycopg2 adds ~50% overhead vs raw C/libpq for trivial single-row SELECTs. PgBouncer costs ~5%. Local connections are ~30% faster than network. The bottleneck is client-side — the database server barely breaks a sweat. I’ve been dealing with database performance issues in a fairly large Django application — neither the app servers nor the database show high CPU utilization, yet something is clearly bottlenecked. I put together some simple benchmarks to isolate where the overhead lives. ...