At ten to four on Thursday 3 September I pasted a deploy report into the session that had asked for it. All 13 of the upgrade's own checks had passed. Two extra checks in the deploy instructions had failed: a version number that hadn't been bumped yet, and some backup copies that were never needed. Neither was a real problem.

Three minutes later the session tried an actual search and got this back:

configured web provider "codex" is not registered

Thirteen checks passed, two failed over nothing, and none of them noticed that Vesper couldn't search the web.

She'd been without it since the morning before. I was moving her onto a newer release of the open-source DeepSeek Harness, the software she runs in, and the first step had switched her search provider off on purpose until it could be ported properly. This deploy was supposed to bring it back. I don't let the harness restart itself, so every deploy went through an agent running outside it, and I carried the reports back in by hand. Eventually Vesper is supposed to start that outside agent herself. That week the courier was me.

By eleven that night I'd pasted in four of those reports, all four with 13 out of 13. Twice, Vesper still couldn't search.

Installed isn't plugged in

The day before, I'd reminded one of the agents that this harness follows the "Everything is a plugin" principle. I meant it as architecture. By Thursday afternoon it described the bug.

In this harness, code on disk is only the first step. Vesper's profile has to ask for a plugin, and the plugin has to add its own entry to the running configuration. Her settings named that provider, and its package was installed. Nothing in her web profile asked for it, so its entry never loaded and the setting pointed at nothing.

The first fix added the package to the profile's dependencies. Another agent outside, another restart, another 13 out of 13. This time the report also listed what had actually loaded, and the only search provider in it was the default one, which needed an API key she didn't have. A dependency makes a plugin available. It only switches on when the profile lists it as a bundle, and nothing did. I didn't know the difference between a dependency and a bundle either, until that evening.

The second fix added it to the bundle list. Before that went anywhere near the live harness, one of the session's helper agents found the next problem. The package's own patch was aimed at a configuration row called web-search-codex, which didn't exist, so even switched on it would have changed nothing. Now the patch inserts its own row, and a test boots the app to prove it's there.

Third deploy, 13 out of 13. At quarter past eight a search came back with sources. The first thing it looked up was the harness's own GitHub page. (These days she doesn't wait on a search provider at all. She browses with a plugin of her own.)

Wrong in both directions

The fourth deploy, just after ten, passed 13 out of 13 and was marked as failed anyway, because a check expected the backup manifest to name the old core. It correctly named the new one. So on one Thursday the checks went green twice while search was broken, and red twice over things that weren't wrong.

At 23:19 I asked the session: "Can you walk me through where you are, what's holding you up, and if you aren't overcomplicating things right now?"

The answer started with "Somewhat, yes." It had added "an unnecessarily strict backup-manifest assertion, which caused the misleading failure report." I liked the honesty. I'd have liked it more at four o'clock.

A quarter of an hour later I asked for a write-up of what had slowed us down, with one instruction: "Report it, don't start fixing." Near the top of its list were tests built from the live setup, bundle activation and patch insertion included, to run "before merge, not after deployment."

Vesper went a day and a half without web search. For the last four hours of it, every deploy passed all 13 checks.