Fifty-seven items reached Done and four went to Won't Do, and seven of the fifty-seven belong to a week already written up. Entry 017 closed its own ticket at 11:13 on the Sunday morning, and said in terms that a client's nameserver switch and post-cutover verification were still ahead. They were — by about two hours. The whole cutover ran that afternoon and was finished by ten past two, and the entry describing it is this one. That is the second week running that the tail after filing has not been empty, which makes the case for sweeping eight days rather than seven steadily harder to argue with.
For the small services business whose migration last week's entry left mid-flight, the move itself took under an hour. A full backup of the outgoing site was taken first. Then the zone was recreated at the new provider with its records replicated, the nameservers switched at the registrar, the custom domains attached to the hosting project, and the result verified end to end. Later in the week came a handover note for the owner and a photo refresh across the site. The soak period is still running — a cutover is not finished when the ticket resolves, it is finished when nothing has gone wrong for long enough that you can stop watching.
The ordering is the whole trick, and not a sophisticated one: back up before you touch anything, because a backup taken afterwards is a backup of whatever you just did.
For the junior chess club, the week's most satisfying build was a game viewer. The core went in on the Friday evening and the rest across Saturday: comments, variations and the annotation glyphs a real game score carries; a static-position mode for the teaching pages; keyboard operability, so a game can be played through without a mouse; and lazy initialisation, so a page carrying a dozen boards does not pay for all twelve before the reader has reached the first.
The last piece is the one worth explaining. The viewer needs a fallback for readers without JavaScript, and the obvious way to build one is to have the site generate it at deploy time — except this site deliberately has no build step. So the fallback exists in the HTML as authored, and a small tool that never ships produces it at the moment of writing rather than the moment of publishing.
The rule underneath is worth stating on its own. Replacing a written-out move list with an interactive board once the script runs is enhancement. Requiring the script to run before the moves can be read at all is not a fallback strategy — it is a single point of failure with better manners.
The best item of the week produced nothing a visitor will ever see. A rule governing how content is written on that project turned out to be cited by seven other tickets, and six of them cited it only in comments. A sweep run the day before had read descriptions and not comments, so it found none of those six. The rule was the most-referenced constraint on the board and, read from its own ticket, it looked as though nobody had ever used it.
The sweep that fixed this had been built twice already and lost twice before anyone thought to commit it — the more embarrassing half, and the more useful one. A rule cited everywhere and reciprocated nowhere is invisible from precisely the place the work gets done: the ticket in front of you when you are deciding what the work is.
Last week's entry spent its length on quality gates reporting a pass they had not earned, and the thread continued. A content-security-policy test failed two assertions on one machine, passed them on the build server, and blamed the policy — and a check that is wrong about the cause is worse than one that stays quiet, because it sends you to the wrong file. The performance gate reported the site's worst score without saying which page produced it, which is a number nobody can act on.
Alongside those: a definition of done and a gate policy written down rather than assumed; the consistency gate extended to check canonical facts and to refuse raw colour outside the token file; security headers and a content-security policy implemented; the last inline styles and scripts moved out to files so that policy could be strict; three webfonts self-hosted and subset. And the dependency graph and security alerts, agreed weeks ago and parked twice, were finally switched on.
The content migration proper began: every existing page and post inventoried, extraction tooling built so the old content could be ported faithfully rather than retyped, the uploads tree enumerated at export so nothing could quietly go missing, a 404 page built, and a club email address that had been wrong on the live site for some time corrected.
One item deserves naming. The club's historic archive was built to be usable rather than merely complete, and then verified complete before anything was retired. That ordering is the whole item. Once the old site is gone the claim that the archive is fine cannot be tested; the only moment it can be checked is the moment both copies still exist, and that moment is short and very easy to spend on something else.
— On the record —Once the original is gone, the backup is fine stops being a claim and starts being a hope.
A new engagement opened, for a beauty therapy studio, and its first pass went in across two evenings: a repository and a hosting project, an image optimisation pass, clean URLs and redirects for the old addresses, a sitemap and a robots file, an accessibility audit to the same AA standard everything here is held to, a mobile menu bug found and fixed, a privacy notice, and a contact form with bot mitigation, a verified sending domain and — again — a version that works with the script switched off. The deliverability test, the cutover and the decommission of the old hosting are all still ahead.
The retained veterinary practice had one item, this morning: another clear-down of accumulated form entries. It stays on the list because retention is not something you do once.
What stood still is, as always, the part worth naming, and this week it is largely last week's list. The trace identifier has not moved since the twelfth of July; the internal developer tool not since the second, a fifth week; the family-history application's cloud foundations not since April, now four months. The chess club's governance block is still open — the data mapping and record of processing, the controller and processor positions in writing, the subprocessor list and transfer assessment, the retention position for historic posts, and a takedown route with a service level attached. Six projects saw no activity at all. Eighteen items are in progress across the board.
The through-line, if there is one, is verification. A cutover verified after the move rather than assumed. An archive verified before the original went, in the short window where verifying was still possible. A fallback that works when the thing it stands in for does not. None of that is difficult work and none of it shows. It is only the difference between having done something and being able to demonstrate it — which, on a week that also moved a live domain, is not a small distinction.