Case study · Routine
Diagnosing and repairing a system that no longer talks to itself
Building blocks that each worked on their own, but whose links had broken without a sound. Four surveys, a map, a pass over every arrow, fixes checked against their source, then monitoring that observes without repairing.
Idea
What problem, in one sentence?
Noticing that the building blocks no longer talk to each other
Each building block worked on its own: mail triage, the dashboard, the scheduled tasks, the sentinel. But the arrows between them had broken without a sound. The symptom was not a visible failure, it was silence: nothing signalled that nothing was flowing.
DifficultyA decision that had been waiting for days and that nobody brought up: it sat in a report that nothing read.
SolutionEvery pending question goes into a single decision queue, read by the dashboard.
DifficultyRoutine runs marked “successful” that had produced nothing.
SolutionA run only counts as successful if it leaves a trace dated today: a log, a file or a table row.
DifficultyScheduled tasks that could not see the plugins installed in the interactive session.
SolutionEach task declares what it needs and checks at start-up that it is available; otherwise it stops and says so.
DifficultyA sentinel that could not see failures, because it read the same logs as the blocks it was watching.
SolutionThe sentinel checks outputs (files, pages, rows), not claims.
!A silent system is not necessarily a healthy one: the absence of alerts must itself be checked.
Concept
What will the tool be, and what will it do?
Running four surveys
Before repairing anything, survey what exists in four parts: the conversations (what was asked and done), the skills and connectors (what is installed, where, and for what use), the scheduled tasks and the dashboard (what runs and what is displayed), the public site (what is published). Each survey is dated and states what it could not read.
What to tell Claude“Run four surveys of my system without changing anything: conversations from the last two months, installed skills and connectors, scheduled tasks and dashboard, public site. For each item: where it lives, what it reads, what it writes and its last dated trace. End with what you could not access.”
DifficultyThe same skills installed in two places, in two different versions.
SolutionThe survey records the version and location of each copy; one source is authoritative, the others derive from it.
Drawing the map and walking every arrow
A map of the system: each building block is a box, each exchange an arrow (who writes what, who reads it, and when). Then a pass over every arrow, one by one: does the source actually write? Does the target read from the same place? An arrow with no reader, or a reader with no source, is a failure waiting to happen.
DifficultyFile paths written for an old computer, still used by some tasks.
SolutionPaths are gathered in a single configuration file that every building block reads.
!Several dozen arrows: do not check them from memory, but one by one, with evidence.
Build
What to ask Claude, in what order?
Dry runs and a problem → solution list
Each item is run dry, without writing anything, to see what it would read and what it would produce. Each gap becomes a problem → solution line on a page where a button copies the fix prompt, ready to paste into a new conversation.
DifficultyA dry run that still wrote to the real log.
SolutionAn explicit test mode that writes to a test folder and announces it at the top of its output.
Reporting in four blocks
The report comes in four blocks: what Claude fixes without approval (a typo in a rules file), what needs approval (changing a task, touching a published page), the paths to align, and what only the person can do: reconnect an account, install a plugin on a computer, choose between two options. This last block is titled “only you are left”.
What to tell Claude“Here is the problem → solution list. Put each line into one of four blocks: without approval, with approval, paths, only you are left. For each line in the “with approval” block, write the question to ask me and the option you recommend.”
DifficultyA list of several dozen fixes, unreadable in one piece.
SolutionThe “only you are left” block is short and comes first: it is the only part waiting for a human action.
Test
How do you prove it works?
Carrying out the approvals, then rereading each write from its source
Once approvals are given, Claude carries them out, then checks each write with a round trip: it rereads the file, page or row from the place where the receiving block will read it, not from what it believes it wrote.
DifficultyA fix announced as done, but written into a copy that nobody read.
SolutionNo fix is declared done without rereading it from the real source, with evidence (date, excerpt).
!A fix that has not been reread is a hypothesis, not a fact.
Adding two checks born from the diagnosis
Two new checks join the monitoring: “task succeeded but no log for today”, which catches empty runs, and “the user path matches the current computer”, which catches paths inherited from an old machine.
Go live
How to deliver, publish and sustain it?
A status-light monitor
A monitor groups status lights by area (mail, calendar, dashboard, tasks, site, connectors). It tests connectors live, shows alarms that can be acknowledged along with their history, and a map of the system where the broken arrow blinks.
DifficultyAlarms that stayed red after a fix and ended up being ignored.
SolutionEach alarm is acknowledged by hand, with the date and reason; an acknowledged alarm that comes back moves to the top.
A Sunday audit, a separate judge, a decisions page
Every Sunday, an audit rereads the system with the age of each alert and the dormancy of projects. The judge is kept apart from what it judges: the sentinel observes, it never repairs. The questions it raises go onto a system decisions page, one card per question with a recommended option, and nothing changes before the answer.
DifficultyA sentinel that fixed what it found by itself, and so hid recurring failures.
SolutionObserving and repairing are two separate roles; repairs go through a decision, then a reread.
!The details of the weekly audit and the decisions page are in the guide on the cross-checked inventory.