AITM hält eine ganze Menge Zustand lokal vor, um zuverlässig zu arbeiten und sich zu merken, was es über die Projekte gelernt hat. Dies ist eine allgemeinverständliche Übersicht darüber, was gespeichert wird und warum es wichtig ist.
Welche Daten AITM speichert
Die Datenübersicht
| Was es ist | Wo es liegt | Warum es wichtig ist |
|---|---|---|
| Datenbank pro Projekt | Eine eigene Datenbankdatei für jedes verwaltete Projekt | Enthält die Contracts und den Task-Verlauf dieses Projekts — pro Projekt getrennt gehalten, sodass sich die Daten eines Projekts nie mit denen eines anderen vermischen |
| Globale Datenbank | Eine gemeinsame Datenbank für AITM selbst | Enthält anwendungsweite Einstellungen, Hints, die Variablenregistrierung und andere projektübergreifende Konfiguration |
| Task-Ausführungslogs | Log-Ordner pro Projekt | Die detaillierte, zeilenweise Aufzeichnung dessen, was während der Ausführung eines Tasks geschah — nützlich zum Debuggen eines Tasks, der sich unerwartet verhalten hat |
| Task-Datenordner | Task-Ordner pro Projekt, ein Unterordner pro Task-Nummer | Enthält die Ergebnisdateien, Metadaten und alle für den Task aufgenommenen Screenshots — das speist die Ansicht Ergebnisse & Archiv |
| Worktrees | Temporäre Git-Checkouts, einer pro laufendem Task | Die isolierte Arbeitskopie, die die KI-Agents eines Tasks tatsächlich bearbeiten; sie wird beim Start eines Tasks angelegt und nach dem Merge automatisch entfernt — siehe Die Pipeline |
| Knowledge-Graph-Dokumente | Automatisch generierte Dokumentationsdateien | Menschenlesbare Exporte der Contracts und des Abhängigkeitswissens, die unter Knowledge Sharing beschrieben sind; werden nach jedem Merge automatisch neu erzeugt |
Warum lokaler, persistenter Zustand wichtig ist
Nichts davon ist beiläufige Buchführung — es ist der Mechanismus hinter allem, was an anderer Stelle in diesem Leitfaden behandelt wird:
- Die Datenbank pro Projekt sorgt dafür, dass Contracts, Task-Verlauf und Präzedenzfall-Abfragen zwischen Sitzungen und zwischen Tasks erhalten bleiben, statt bei jedem Schließen der App zurückgesetzt zu werden.
- Task-Datenordner machen das Archiv zu einem wirklich nützlichen Prüfpfad statt zu einer Liste von Titeln — jedes dort sichtbare Ergebnis, jeder Screenshot und jedes Metadatenfeld wird direkt aus diesen Ordnern gelesen.
- Worktrees sind das mechanische Fundament der Isolationsgarantie, die unter Die Pipeline beschrieben ist — da jeder Task einen wirklich getrennten Dateisystem-Checkout erhält, kann laufende Arbeit nie versehentlich in den Haupt-Branch gelangen.
- Die Knowledge-Graph-Dokumente machen aus "die KI hat sich zufällig etwas gemerkt" ein "das Projekt hat eine dauerhafte, einsehbare Aufzeichnung seines eigenen Verhaltens" — siehe Knowledge Sharing.
Wie Datenbank-Backups vor unbegrenztem Wachstum und stillem Datenverlust geschützt werden
Datenbank-Backups brauchen eigenen Schutz — andernfalls könnten sie entweder die Festplatte füllen oder genau dann stillschweigend verschwinden, wenn sie am dringendsten gebraucht werden. AITM hält sie unter einer gestaffelten Aufbewahrungsrichtlinie und überwacht ihre Größe auf Anomalien:
- Gestaffelte Aufbewahrung — statt einer einheitlichen Grenze, die alle Datenbank-Backups löscht, die älter als N Tage sind (und damit bei einem verpassten Tageslauf alle DB-Backups auf einen Schlag vernichten könnte), dünnt AITM Backups schrittweise aus: Es behält einige der neuesten Tages-Backups, ein paar ältere Backups im Abstand mehrerer Tage und ein noch älteres Wochen-Backup. Das Ergebnis ist eine kleine, aber breit gestreute Menge von Wiederherstellungspunkten, ohne dass der Backup-Speicher unbegrenzt wächst.
- Warnungen bei Größenanomalien — bevor irgendetwas bereinigt wird, vergleicht AITM die Größe des heutigen Datenbank-Backups mit der von gestern. Ein deutlicher Rückgang (möglicher Datenverlust) oder ein deutliches unerwartetes Wachstum löst eine E-Mail-Warnung aus, die die vorherige Größe, die aktuelle Größe und die prozentuale Änderung enthält, sodass die Anomalie bekannt wird, bevor ein altes, gesundes Backup überschrieben oder bereinigt würde.
- Verifiziertes Bereinigen inkrementeller (Delta-)Backups — inkrementelle Wiederherstellungs-Backups, die älter als 3 Tage sind, werden fortlaufend bereinigt, aber erst, nachdem das neueste noch behaltene Backup dieser Kette als intakt verifiziert wurde. Schlägt diese Verifizierung fehl, stoppt die Bereinigung für diese Datenbank, und nichts Älteres wird gelöscht — so kann ein einziges beschädigtes neuestes Backup nie dazu führen, dass die darunterliegenden älteren, noch guten Backups mitgelöscht werden.
Gut zu wissen
- Der Code des Projekts wird nie außerhalb eines Worktrees verändert — die normale Arbeitskopie bleibt unberührt, während ein Task läuft.
- Nichts verlässt den Rechner außer Aufrufen an den konfigurierten KI-Provider.
- Dieses lokale, persistente Wissen ermöglicht es AITM, sich über die Zeit am Projekt zu verbessern, statt bei jedem Task bei null anzufangen.