Demo / scenarios · 3 of 3

The weekly review, including the week it could not do its job

One run from the demo vault — a complete, fictional chief-of-staff system built by Claude Code sessions working from the bootstrap prompt. Rowan is invented and so is everyone here, but the files, the quotes and the commits are real: every one of them can be opened.

Input
Sunday at 17:00, twice — once with a single day of history behind it, and again a week later
Outcome
Sixteen changes the first week; and three weeks of a failed check recorded honestly instead of skipped
Guides
the weekly reviewwatching for new guidesthe review surface

The daily brief asks what is next. The weekly review asks what you are pretending. It is the ritual most people skip, and the one that does the work.

What happened

Rowan picked Sunday at five over Friday, and said why: “Friday I’m done thinking.” Sunday is when the week ahead can still be changed.

The first review ran the day after the system was set up, with one day of history behind it — which is faintly absurd, and was done anyway, because a habit that waits for enough material never starts.

It produced sixteen changes. The substantial ones came from Rowan opening his accountant’s weekly email and reading all the way to the bottom, “for what I believe is the first time” — which turned up a capital call with a deadline in the section he had never scrolled to.

Two things fell out that nobody asked for:

  • His wedding anniversary falls inside his wife’s three-week trip. So do all three of the weekly dinners they protect. Both facts were already written down, forty-eight hours apart, in different files. Neither was wrong. Nothing had put them next to each other.
  • A ten-working-day payment deadline crosses a public holiday, making it ambiguous by a day. The review said so, and named the one message that would settle it.

How it works

  1. A fixed slot, chosen with a reason — and kept even when there is nothing to review.
  2. The counting happens first, automatically. How many things are open, how many are past a date their owner set, what has not moved. Numbers are computed rather than recalled, so the review argues from evidence instead of mood.
  3. Facts from different files get put on the same page. This is the entire point. Nothing in this system is clever on its own; it is useful because it holds everything at once, once a week.
  4. It checks whether its own instructions have been updated — fetching the guide index from this site and reporting anything new.
  5. Every line ends in a question that Rowan answers, and the answers become tasks. A review you read but do not act on is a newspaper.

The week it could not do its job

Step 4 failed. Then it failed again. Then a third time — the local copy of this site was down, and the assistant could not reach it.

What it wrote instead of a result:

“second consecutive unreachable fetch recorded; nothing seen, nothing claimed”

By the third week it had diagnosed the cause precisely — the server was running and returning errors on every address it tried, so the file was not missing, the server was broken — while noting that the repository responsible “is not the vault and is not Hobbs’s to change.”

Why it matters

That failure is the least impressive artifact in this demo and possibly the most important one.

A system that invents a plausible answer when something fails is worse than no system, because you cannot tell the two apart by looking at the output. Three weeks of recorded failure is what trustworthy looks like from the inside.

When the connection came back, the step ran properly: every guide checked, each with a one-line verdict on whether it applied here, and Rowan answering yes to two, no to most, and not yet to everything that would have required handing over a password.

See it in the vault