Last week the internal developer tool was given a face — a layout shell and a design system, a surface composed and ready to be looked at, but with its controls not yet wired to anything behind them. This week the controls were built and connected. Twenty-one of the thirty-four items closed belonged to that single effort, and they turned a face into an instrument: the tool can now do, for a person, the three things it was always meant to do — read a schedule back to them, show them the days it will fall on, and tell them how one schedule differs from another.
The first of those is the part you touch. The expression input was built — the single field where a schedule is typed or edited — and beneath it the plain-language description that answers it: enter a terse line of symbols above, and read an ordinary English sentence below. Around that pair went the controls that frame it: a segmented selector for the dialect a schedule is written in, since the same field can mean different things under different conventions; a timezone type-ahead that keeps two zones distinct — the one a schedule is reckoned in, and the one you happen to be reading it from; a panel that anchors each error to the field that caused it rather than barking from the top of the page; and a banner held in reserve for the genuine edge cases that deserve a word of their own. The effect is quiet but exact: a thing typed in one place is answered, in the next, by a sentence anyone can read.
The second is the part that makes a schedule real. A line of cron is an abstraction until you can see the actual days it lands on, so the tool grew a calendar — three of them, in fact. A month grid that marks every firing across a page you take in at a glance; a week view laid out as a seven-by-twenty-four field, for schedules whose rhythm is daily rather than monthly; and an agenda — a plain chronological list, with a copy-everything control for when you simply want the times as text. A day in any of the three can be touched for a small popover of precisely what fires and when. And because a schedule is rarely wanted in isolation, the firings can now be carried out of the tool altogether: handed to a real calendar as an .ics file, or to a spreadsheet as CSV.
The third face is the one with the most quietly useful consequence. A compare mode was added — its own addressable place in the tool — that sets two expressions side by side and marks where they agree and where they part. A summary bar across the top says, in a sentence, how the two differ; and the difference is then drawn straight onto the calendar itself, each side's firings marked left and right, so you can see — not merely read — what changed. It answers the question every edit to a live schedule really asks: what, precisely, will be different once I ship this? Knowing that before the change goes out, rather than discovering it after, is the whole point of the thing.
Beneath those three went the finishing that no one notices unless it is missing. The way errors surface was de-duplicated, so a single fault no longer announces itself twice — once inline and once in the panel — but reports itself in one considered place. The input rows were given a polish pass for alignment and rhythm. And one small, satisfying detail: the error underline beneath a long expression now keeps pace with the field as it scrolls sideways, so the mark stays under the thing it means. None of it demonstrates well. All of it is the difference between a thing that looks finished and a thing that is.
— On instruments —A face can be admired. An instrument is the moment a thing begins to answer a question you actually have.
Outward, the clinical canine massage practice's site moved from a working contact pipeline to one that can be trusted in public. This week it gained the layer that watches and records: an audit table that writes down every outcome the contact form can reach — and the write path was checked against all eight of those outcomes, not merely the happy one; telemetry that watches requests and their dependencies from the inside; and an alert that mails out, off the site's own domain, the moment the server begins returning errors — so a failure is something we are told about rather than something a visitor discovers for us. The development bypass that had stood in for bot-protection was removed and the real check mounted live in its place. And interim example copy was drafted for two of the site's sections, so the preview reads as something true rather than as placeholder. It is the unglamorous prerequisite to launch: a site you can see into is a site you can stand behind.
The smaller stewardship was kept, as it always is. For a local dog-training club it was a week of governance rather than code: its annual general meeting attended, a new first-aid course signed off, its secretary set up properly on a club email account of her own, and a rules-and-regulations notice readied for the club's website. And for the retained veterinary practice, another clear-down of accumulated contact-form entries — the recurring, unglamorous data hygiene that keeps a modest site holding no more than it should, and for no longer than it ought.
Looking ahead: the internal tool, now able to describe, show and compare, turns from building those faculties toward making them fit to be released; the canine massage practice's site, watched and protected, turns from hardening toward going live; the practice's own website waits still on its final pre-launch verification; and the retained clients go on being kept, as they always are.
Thirty-four items to Done across four projects — twenty-one of them a tool of our own, carried this week from a face to a working instrument that reads a schedule, shows it, and tells it apart from another. One client site hardened toward its launch, the smaller work quietly kept. The same deliberate, unhurried practice, still turned inward — but with the inward thing now nearly ready to be passed on.