The journal learns to write itself

Situation. Phase three of six, building the first version. By Sunday afternoon the operating team had produced more than I had written down: a security review, a release gate, an outbound batch, a public skills pack, and three runs of that pack against the company itself. Every entry in this journal so far had been typed by hand or drafted for me in a chat window and pasted across. The record was falling behind the work it was meant to record.

What happened. I asked for the same thing the security pack had just given other engineers, pointed at this site: a way to capture a project while working on it, from wherever the work is. We ran through seven ideas and built three. One drafts a field note from the conversation it is run in, in this journal’s own three-paragraph shape, as a draft, and hands back a list of every name, number and company it used so I can strike what is not mine to publish. One records a decision as the next numbered ADR and refuses to write if what it finds is a recommendation rather than a decision. One is the gate before the site deploys: types, build, links to drafts, missing tags, em-dashes, uncommitted files, and the anonymisation standard for the enterprise project, which it fails outright today because that standard is still an empty template. The three live in this site’s repository and install as a private plugin from the local checkout, so a git pull is the update. We decided against making them public: they are my notebook, and they carry the rules the day job’s sign-off depends on. The first thing they did was write this note.

Next. A fortnight of use before the next four (milestones, costs, lessons, a Monday sweep of the week for moments worth recording). The number that matters is how many entries in that fortnight were captured at the moment they happened rather than reconstructed afterwards; today it is one of five.

Addendum, 11 October, later. The gate described above checked content and not schema. That evening a question about subscriber numbers found that the newsletter form had been failing since 5 October: the double opt-in change added four database columns through a migration that was never applied to production, and every sign-up since had errored on a column that did not exist. Total subscribers: one, from 1 October, almost certainly my own test. The migration is now applied and the gate has a ninth check, pending migrations are NO-GO. The gate was six days too late to catch its first real failure, which is recorded here rather than tidied away.

It was broken twice over. With the schema fixed, a sign-up stored correctly and still sent nothing: the sending credentials had never been set on the hosting project, so since 1 October every confirmation had been skipped with a one-line log entry nobody read. The mail helper was moved to the provider the rest of the company already uses, the key was set, and nothing changed, because on this host a new secret only reaches the function after the next deploy. Redeployed, the first confirmation left at 16:01, landed in a corporate junk folder, and was confirmed at 16:03. Two confirmed subscribers by the end of the evening, both my own addresses. The form has been on the site for eleven days. Nobody could have subscribed on any of them.