Fallstudie · Routine
Ein System diagnostizieren und reparieren, dessen Teile nicht mehr miteinander sprechen
Bausteine, die jeder für sich funktionierten, deren Verbindungen aber lautlos abgerissen waren. Vier Erhebungen, eine Übersichtskarte, ein Durchgang über alle Pfeile, an der Quelle nachgeprüfte Korrekturen und danach eine Überwachung, die feststellt, ohne zu reparieren.
Idee
Welches Problem, in einem Satz?
Feststellen, dass die Bausteine nicht mehr miteinander sprechen
Jeder Baustein funktionierte für sich: die Sortierung der E-Mails, das Dashboard, die geplanten Aufgaben, der Wächter. Doch die Pfeile zwischen ihnen waren lautlos abgerissen. Das Symptom war keine sichtbare Panne, sondern Stille: Nichts zeigte an, dass nichts mehr floss.
SchwierigkeitEine Entscheidung, die seit Tagen anstand und die niemand vorlegte: Sie lag in einem Bericht, den nichts las.
LösungJede offene Frage kommt in eine einzige Entscheidungsliste, die das Dashboard liest.
SchwierigkeitRoutinedurchläufe, die als „erfolgreich“ vermerkt waren, aber nichts erzeugt hatten.
LösungEin Durchlauf gilt nur als erfolgreich, wenn er eine Spur mit dem heutigen Datum hinterlässt: Protokoll, Datei oder Tabellenzeile.
SchwierigkeitGeplante Aufgaben, die die in der interaktiven Sitzung installierten Plugins nicht sahen.
LösungJede Aufgabe gibt an, was sie braucht, und prüft beim Start, ob es verfügbar ist; andernfalls bricht sie ab und sagt es.
SchwierigkeitEin Wächter, der die Pannen nicht sah, weil er dieselben Protokolle las wie die Bausteine, die er überwachte.
LösungDer Wächter prüft die Ergebnisse (Dateien, Seiten, Zeilen), nicht die Meldungen.
!Ein stilles System ist nicht unbedingt ein gesundes: Auch das Ausbleiben von Warnungen muss geprüft werden.
Konzept
Was wird das Werkzeug sein, und was soll es tun?
Vier Erhebungen durchführen
Vor jeder Reparatur den Bestand in vier Teilen erheben: die Unterhaltungen (was verlangt und getan wurde), die Skills und Konnektoren (was installiert ist, wo und wofür), die geplanten Aufgaben und das Dashboard (was läuft und was angezeigt wird), die öffentliche Website (was veröffentlicht ist). Jede Erhebung ist datiert und sagt, was sie nicht lesen konnte.
Was Sie Claude sagen„Führe vier Erhebungen meines Systems durch, ohne etwas zu ändern: Unterhaltungen der letzten zwei Monate, installierte Skills und Konnektoren, geplante Aufgaben und Dashboard, öffentliche Website. Für jedes Element: wo es liegt, was es liest, was es schreibt und seine letzte datierte Spur. Schließe mit dem, worauf du nicht zugreifen konntest.“
SchwierigkeitDieselben Skills an zwei Orten installiert, in zwei verschiedenen Versionen.
LösungDie Erhebung hält Version und Ort jeder Kopie fest; eine einzige Quelle ist maßgeblich, die anderen leiten sich davon ab.
Die Karte zeichnen und alle Pfeile abgehen
Eine Übersichtskarte des Systems: Jeder Baustein ist ein Kasten, jeder Austausch ein Pfeil (wer schreibt was, wer liest es, zu welchem Zeitpunkt). Dann ein Durchgang über alle Pfeile, einer nach dem anderen: Schreibt die Quelle tatsächlich? Liest das Ziel an derselben Stelle? Ein Pfeil ohne Leser oder ein Leser ohne Quelle ist eine Panne, die nur auf ihren Moment wartet.
SchwierigkeitDateipfade, die für einen alten Computer geschrieben waren und von manchen Aufgaben noch genutzt wurden.
LösungDie Pfade werden in einer einzigen Konfigurationsdatei gebündelt, die jeder Baustein liest.
!Mehrere Dutzend Pfeile: nicht aus dem Gedächtnis prüfen, sondern einen nach dem anderen, mit Beleg.
Umsetzung
Was bittet man Claude, in welcher Reihenfolge?
Trockenläufe und eine Liste Problem → Lösung
Jedes Element wird im Trockenlauf gestartet, ohne etwas zu schreiben, um zu sehen, was es lesen und was es erzeugen würde. Jede Abweichung wird zu einer Zeile Problem → Lösung auf einer Seite, auf der eine Schaltfläche den Korrekturprompt kopiert, bereit zum Einfügen in eine neue Unterhaltung.
SchwierigkeitEin Trockenlauf, der trotzdem in das echte Protokoll schrieb.
LösungEin ausdrücklicher Testmodus, der in einen Testordner schreibt und das am Anfang seiner Ausgabe ankündigt.
Das Ergebnis in vier Blöcken vorlegen
Das Ergebnis besteht aus vier Blöcken: was Claude ohne Zustimmung korrigiert (ein Tippfehler in einer Regeldatei), was eine Zustimmung braucht (eine Aufgabe ändern, eine veröffentlichte Seite anfassen), die anzugleichenden Pfade, und was nur die Person selbst tun kann: ein Konto neu verbinden, ein Plugin auf einem Rechner installieren, zwischen zwei Optionen wählen. Dieser letzte Block heißt „Jetzt sind nur Sie gefragt“.
Was Sie Claude sagen„Hier ist die Liste Problem → Lösung. Ordne jede Zeile einem der vier Blöcke zu: ohne Zustimmung, mit Zustimmung, Pfade, jetzt sind nur Sie gefragt. Schreibe für jede Zeile im Block „mit Zustimmung“ die Frage, die du mir stellen willst, und die Option, die du empfiehlst.“
SchwierigkeitEine Liste mit mehreren Dutzend Korrekturen, am Stück unlesbar.
LösungDer Block „Jetzt sind nur Sie gefragt“ ist kurz und steht ganz oben: Er ist der einzige Teil, der auf eine menschliche Handlung wartet.
Prüfung
Wie beweist man, dass es funktioniert?
Die Freigaben ausführen und jeden Schreibvorgang an der Quelle nachlesen
Sind die Freigaben erteilt, führt Claude sie aus und prüft dann jeden Schreibvorgang in einem Hin und Zurück: Er liest die Datei, die Seite oder die Zeile an der Stelle nach, an der der empfangende Baustein sie lesen wird, und nicht anhand dessen, was er geschrieben zu haben glaubt.
SchwierigkeitEine als erledigt gemeldete Korrektur, die in eine Kopie geschrieben war, die niemand las.
LösungKeine Korrektur gilt als erledigt, ohne an der echten Quelle nachgelesen zu sein, mit Beleg (Datum, Auszug).
!Eine nicht nachgelesene Korrektur ist eine Annahme, keine Tatsache.
Zwei Prüfungen aus der Diagnose ergänzen
Zwei neue Prüfungen kommen zur Überwachung hinzu: „Aufgabe erfolgreich, aber kein Protokoll von heute“, die leere Durchläufe aufspürt, und „der Benutzerpfad passt zum aktuellen Rechner“, die von einem alten Computer geerbte Pfade aufspürt.
Inbetriebnahme
Wie ausliefern, veröffentlichen und am Leben halten?
Ein Monitor mit Kontrollleuchten
Ein Monitor fasst die Kontrollleuchten nach Bereichen zusammen (E-Mail, Kalender, Dashboard, Aufgaben, Website, Konnektoren). Er testet die Konnektoren live, zeigt quittierbare Alarme mit ihrem Verlauf und eine Übersichtskarte des Systems, auf der der defekte Pfeil blinkt.
SchwierigkeitAlarme, die nach der Korrektur rot blieben und schließlich übersehen wurden.
LösungJeder Alarm wird von Hand quittiert, mit Datum und Grund; ein quittierter Alarm, der wiederkehrt, rückt nach oben.
Ein Sonntagsaudit, ein getrennter Prüfer, eine Entscheidungsseite
Jeden Sonntag liest ein Audit das System neu, mit dem Alter jeder Warnung und dem Ruhezustand der Projekte. Der Prüfer ist von dem getrennt, was er prüft: Der Wächter stellt fest, er repariert nie. Die Fragen, die er aufwirft, kommen auf eine Seite für Systementscheidungen, eine Karte pro Frage mit einer empfohlenen Option, und nichts ändert sich vor der Antwort.
SchwierigkeitEin Wächter, der selbst korrigierte, was er fand, und so wiederkehrende Pannen verdeckte.
LösungFeststellen und Reparieren sind zwei getrennte Rollen; die Reparatur läuft über die Entscheidung und danach über ein Nachlesen.
!Die Einzelheiten zum wöchentlichen Audit und zur Entscheidungsseite stehen in der Karte zur abgeglichenen Bestandsaufnahme.