Hey Jamal! Die woorden van jou van 3 augustus, over ons systeem dat te fragiel is door al die 'wachters'? Je had helemaal gelijk. Vandaag neem ik je mee door de eerste grote opruimronde. Ik vertel je wat we vonden, wat eruit ging, en hoe we voorkomen dat dit opnieuw gebeurt.
Stel je voor: op de MacBook draaiden 68 van die 'wachters', naast honderden scripts. Gigantisch! En het pijnlijkste? Drie van onze *eigen* bewakers gingen stuk. Ze waren bedoeld om te beschermen, maar werden zélf het probleem. Een wachter sloeg vals alarm door z’n eigen meldingen, en een ander slikte zelfs een van jouw opdrachten in. Zo'n oplossing die een nieuw probleem creëert, daar wilden we vanaf.
Nou, de bezem is erdoor! Twaalf wachters zijn de deur uit. Sommige hadden hun taak volbracht, andere bleken overbodig, of deden al weken niets – maar draaiden wel elke paar minuten. Bij elkaar zo'n vijftigduizend nutteloze checks per maand! Die draaien nu niet meer. Geen zorgen, alle cruciale systemen werken nog, en mochten we een verwijderde wachter missen, dan zetten we die zo weer terug.
We zijn nog niet helemaal klaar. Er zijn nog twee clusters met te veel overlap. Zeven 'bewakers' die allemaal kijken of 'iets stuk is', moeten één slimme bewaker worden. En acht 'rapportages' die jou allemaal iets sturen, moeten één gebundelde, dagelijkse briefing vormen. Dit vraagt om bouw- en testwerk, dus dat wordt een aparte klus, na jouw akkoord.
Om herhaling te voorkomen, hebben we duidelijke regels voor nieuwe wachters. Elke nieuwe moet drie dingen hebben: een zelftest die bewijst dat hij werkt én zwijgt wanneer nodig, een heldere vervaldatum of doel, en een check of een bestaande wachter dit niet kan oppakken. Liever een check toevoegen dan een nieuw, los onderdeel. Want Jamal, een wachter is een extra component dat kán breken. Een oorzaak wegnemen, dát maakt het systeem sterker. Wat er niet is, kan ook niet meer stuk.
Dus, dit was de eerste, maar cruciale stap richting een robuuster en minder fragiel systeem. Het is al een stuk lichter en betrouwbaarder. We zijn goed op weg om jouw visie werkelijkheid te maken. Binnenkort meer over de volgende stappen. Goed weekend!
Jamal, 3 augustus: "door alle regels en hooks en watchers die wij bouwen creëren we
alleen maar meer manieren om dingen om te laten vallen — ons systeem is veel te fragiel."
Hij heeft gelijk. Dit verslag laat zien hoe erg het was, wat eruit ging, en welke regel
we vanaf nu aanhouden zodat het niet terugkomt.
Op de MacBook draaiden 68 wachters, 24 hooks en 293 scripts. Op één dag gingen er
drie van onze eigen bewakers stuk:
Elk van die drie was ooit gebouwd om iets te beschermen. Alle drie werden ze zelf het probleem.
| Wachter | Waarom weg |
|---|---|
| herinnering-noodstop | De noodstop is vandaag gebouwd en getest. De herinnering heeft zijn taak gedaan. |
| herinnering-hotjar | Hotjar draait sinds 26 juli. |
| Wachter | Wordt gedekt door |
|---|---|
| telegram-poller-watchdog (draaide elke minuut, log 23 dagen leeg) | telegram-lezer-wacht, die verbindingen meet in plaats van processen |
| sjakie-session-warn | Sjakies eigen session-limit-watcher, vandaag gerepareerd |
| transcript-watchdog | bot-watchdog + de telegram-lezer-wacht |
| Wachter | Interval | Log stil sinds |
|---|---|---|
| dns-queue | 5 min | 24 dagen |
| heartbeat-sync | 10 min | 25 dagen |
| plaud-digest | 20 min | 30 dagen |
| appel-verslag-poller | 5 min | 18 dagen |
| usage-hourly-watch | 1 uur | 26 dagen |
| aireport-analyse | 30 min | 16 dagen |
| actiepunten-3daags-check | 3 dagen | 23 dagen |
Bij elkaar draaiden deze twaalf ruim 50.000 keer per maand zonder aantoonbaar resultaat.
Terugzetten kan altijd: alle plists staan in ~/.claude/launchagents-uitgezet-20260803/.
Terug is één commando: cp <plist> ~/Library/LaunchAgents/ && launchctl bootstrap gui/501 <plist>.
Gecontroleerd na afloop: de wachtrij-worker, telegram-lezer-wacht, noodstop-wachter,
geheugen-deler, hoofdsessie-wacht, besluitenlijst en Kimi-bot draaien allemaal nog.
Ik had gemeld dat er "zeven bewakers zijn die allemaal hetzelfde doen" en stelde voor ze
samen te voegen tot één. Bij het lezen van de code bleek die claim te grof. Ze doen
grotendeels verschillende dingen:
| Wachter | Wat hij echt doet | Oordeel |
|---|---|---|
| bot-watchdog | bots met een dode hartslag herstarten | blijft — dit is de kern |
| fleet-heartbeat | schrijft de hartslagen weg | blijft — dit is de databron, geen bewaker |
| stille-storing | vindt automatiseringen die stil kapot zijn | blijft — unieke functie |
| uptime-monitor | websites down | blijft — unieke functie |
| dubbelwerk-wachter | taken die elke nacht hetzelfde werk overdoen | blijft — unieke functie |
| vastloper | hangende klussen | UIT — logboek 4 dagen leeg, bewaakte alleen claude -p-klussen; bot-watchdog en de nieuwe hoofdsessie-wacht dekken dit |
| mcp-monitor | MCP-servers elk uur | UIT — draaide 24x per dag, meldde in zijn hele bestaan 0 problemen en deed 0 reparaties; de SessionStart-hook toont hetzelfde bij elke sessiestart |
Belangrijker dan de twee die eruit gingen: er is niets nieuws gebouwd. Samenvoegen zou
een nieuw draaiend onderdeel hebben opgeleverd dat zelf kan breken. Wegnemen wat al gedekt
is, is altijd beter dan samenvoegen tot iets nieuws.
De rapportage-cluster (8 stuks die Jamal losse berichtjes sturen) staat nog open. Dat is
wél een echte bundel-klus, maar die vraagt bouwen — dus alleen met Jamals expliciete ja.
Een nieuwe wachter mag er alleen komen als hij drie dingen heeft:
En het belangrijkste onderscheid, want niet alle bouwsels zijn gelijk:
Een wachter kijkt of iets misgaat — dat is een extra onderdeel dat zelf kan breken.
Een oorzaak wegnemen maakt het systeem kleiner.
Voorbeeld van vandaag: Sjakies zeven overtollige Telegram-lezers zijn niet bewaakt, ze zijn
weggehaald. Dat onderdeel kan nu niet meer stuk. Zo hoort het.