Kurzreferenz zu den in diesem Leitfaden verwendeten Begriffen sowie Antworten auf häufige Fragen.
Glossar & FAQ
Glossar
| Begriff | Definition |
|---|---|
| Agent | Der KI-"Arbeiter", der einen Pipeline-Schritt ausführt und mit einem bestimmten Provider und Modell konfiguriert ist. Siehe Settings. |
| Archive | Die durchsuchbare Aufzeichnung jedes abgeschlossenen Tasks mit vollständigen Ergebnisdetails. Ein archivierter Task kann mit Restore wieder in die Queue gestellt werden. Siehe Ergebnisse lesen & Archiv. |
| Auto-merge | Die Task-Option autoMergeDev, die einen fertigen, getesteten Task automatisch nach dev mergt. Siehe Einen Task erstellen. |
| Branch / Worktree | Der isolierte Git-Branch und der separate Arbeitsordner, die für jeden Task angelegt werden, damit er andere Arbeit nicht beeinflussen kann. Siehe Die Pipeline. |
| Brainstorm | Das Panel für offene Erkundung und Planung mit der KI, ohne Code zu bearbeiten. Siehe Brainstorm. |
| Chat | Das Unterhaltungspanel pro Projekt für schnelle, Contract-bewusste Fragen und Diskussionen. Siehe Chat. |
| Contract | Ein gespeichertes Faktenblatt, das beschreibt, wie sich ein bestimmter Teil des Projekts verhält, und automatisch synchron gehalten wird. Siehe Knowledge Sharing. |
| Dashboard | Die Hauptarbeitsansicht von AITM mit Projekt-Tabs, Karten und der Task-Queue. |
| Dev Panel (AITM Dev Panel) | Eine einbindbare JS-Werkzeugleiste (aitm-dev-panel.js), die vom AITM-Server ausgeliefert wird, markierte UI-Elemente überlagert, einen Live-Ereigniszähler und einen Inspektor zeigt und DOM-Interaktionen an AITM zurückmeldet, damit es die DOM-Element-Map des Projekts aufbauen und pflegen kann. Siehe DOM-Map + Dev Panel. |
| dev branch | Der Standard-/Integrations-Branch, in den jeder Pipeline-Task mergt. Siehe Merging, Post-Merge Fixes & Scope Gate. |
| DOM Explorer | Das Verzeichnis der echten UI-Elemente eines Projekts und dessen, was was auslöst, für Projekte mit Frontend. Siehe Variable Explorer & IntelliSense. |
| E2E (End-to-End) | Automatisierte Tests, die die echte laufende Anwendung in einem Browser so ausführen, wie es ein Benutzer täte. Siehe Testing. |
| Hint | Eine kurze, wiederverwendbare Regel, die die KI in künftigen Tasks automatisch anwendet, ohne dass sie wiederholt werden muss. Siehe Knowledge Sharing. |
| Integration branch (defaultBranch) | Die Einstellung pro Projekt, die benennt, in welchen Branch die Tasks eines Projekts mergen (Standard: dev); bearbeitbar in den Project settings mit einer Prüfung "Verify remote". Siehe Merging, Post-Merge Fixes & Scope Gate. |
| Knowledge Graph | Die vernetzte Karte der Variablen, Contracts, UI-Elemente und der Dokumentation eines Projekts. Siehe Knowledge Sharing. |
| License slot | Ein Projekt-Slot: Die Lizenz legt fest, wie viele Projekte AITM verwalten darf. Sie begrenzt nicht, wie viele Tasks gleichzeitig laufen — das regelt die separate Pipeline-Einstellung Max concurrently running tasks. Siehe Lizenzierung & Projekt-Slots. |
| Lite mode | Eine Task-Option, die den Planungsschritt Architect überspringt, wenn das Coding-Modell stark genug ist. Siehe Einen Task erstellen. |
| main branch | Der stabile Release-Branch, der nur durch einen Merge dev → main zum Release-Zeitpunkt aktualisiert wird. Siehe Merging, Post-Merge Fixes & Scope Gate. |
| Merge Queue | Der Mechanismus, der Merges nach dev einzeln serialisiert und eine automatische Konfliktlösung versucht. Siehe Die Pipeline. |
| Pipeline | Die automatische Abfolge von 12 Schritten (branch → architect → code → compliance-check → review → fix → test → e2e → verify → snapshot → docs → chain-audit), die den Prompt eines Tasks in eine fertige Änderung verwandelt, die die Merge-Queue anschließend nach dev mergt. Siehe Die Pipeline. |
| Priority | Ein Hinweis auf die Queue-Position eines Tasks: low, medium oder high. Siehe Einen Task erstellen. |
| Project | Eine Codebasis, in die AITM eingebunden wurde und für die es Tasks anlegen kann. Siehe Überblick & Einstieg. |
| Provider | Der zugrunde liegende KI-Dienst (Claude, Gemini, OpenAI, DeepSeek, NVIDIA, Ollama), der einen Pipeline-Schritt ausführt. Siehe Settings. |
| Status (task) | Der aktuelle Zustand eines Tasks: pending, running, awaiting_input, waiting, finished, failed, stopped, conflict oder archived. awaiting_input bedeutet, dass die KI auf eine Antwort oder Freigabe wartet; waiting bedeutet, dass der Task auf Korrekturen von Bugs wartet, die beim E2E-Testen gefunden wurden. Siehe Einen Task erstellen. |
| Task | Eine einzelne zugewiesene Arbeitseinheit, die die Pipeline durchläuft. Siehe Einen Task erstellen. |
| Turn | Grob ein Denk-/Handlungsschritt eines KI-Agents (z. B. eine Datei lesen oder bearbeiten). Siehe Settings. |
| Verdict | Das Ergebnis eines Testschritts als bestanden/fehlgeschlagen (oder detaillierter), vor allem E2E-Urteile. Siehe Ergebnisse lesen & Archiv. |
| Watchdog | Der Hintergrundprozess, der hängende Pipeline-Schritte erkennt und automatisch fortsetzt. Siehe Die Pipeline. |
FAQ
Was passiert, wenn ein Task fehlschlägt?
Die Pipeline hält am fehlschlagenden Schritt an, und der Task-Status wird failed, wobei der Grund festgehalten wird. In der Regel lässt sich der Task ab diesem Schritt (oder einem früheren) fortsetzen, sobald klar ist, was schiefgegangen ist — siehe Ergebnisse lesen & Archiv.
Können mehrere Tasks gleichzeitig laufen?
Ja, über verschiedene Projekte hinweg. Innerhalb eines einzelnen Projekts laufen Tasks nacheinander, damit nicht zwei Tasks um denselben Branch konkurrieren; verschiedene Projekte laufen vollständig parallel.
Pusht AITM jemals von sich aus auf ein Remote oder einen Produktions-Branch?
Nein. Auto-merge mergt nur in den lokalen dev-Branch. Ein Push darüber hinaus ist immer eine bewusste, separate Aktion, die selbst ausgeführt wird.
Was, wenn die KI mitten im Task hängen bleibt?
Der Watchdog bemerkt einen hängenden Schritt und setzt die Pipeline automatisch fort, bis zu einer begrenzten Zahl von Versuchen. Kann er sich dennoch nicht erholen, wird der Task mit erhaltenem Grund als failed markiert, damit entschieden werden kann, wie es weitergeht. Siehe Die Pipeline.
Wo werden die Daten gespeichert?
Lokal, in einer Kombination aus Datenbanken pro Projekt, Task-Ordnern und automatisch generierter Dokumentation. Die vollständige Übersicht steht unter Welche Daten AITM speichert.
Müssen perfekte Prompts geschrieben werden?
Nein, aber spezifischere Prompts brauchen weniger Fix-Zyklen. Siehe die Tipps zum Schreiben von Prompts unter Einen Task erstellen.
Was ist der Unterschied zwischen Chat, Brainstorm und einem Task?
Chat und Brainstorm besprechen und planen — sie berühren den Code nie. Ein Task ist das Einzige, was tatsächlich Code ändert, und er durchläuft stets die vollständige, geprüfte und getestete Pipeline. Siehe Chat und Brainstorm.
Was bedeutet das Banner "License blocked (session-mismatch)"?
Der Lizenzserver sah, wie derselbe Schlüssel gleichzeitig von zwei Orten Heartbeats sendete — eine zweite AITM-Instanz, eine geklonte VM oder ein wiederhergestelltes Backup, das neben dem Original läuft. Solange das besteht, nimmt die Queue keine Tasks an. Die doppelte Instanz wird gestoppt, dann wird im Banner auf Retry geklickt (oder in Settings → License auf Refresh from server). Besteht Gewissheit, dass nur eine Instanz existiert, ist die Sperre ein Fehlalarm und kann über dasselbe Banner entsperrt werden. Siehe Lizenzierung & Projekt-Slots.
Warum zeigt die Kopfzeile nach einem Task-Merge eine Schaltfläche "Restart"?
AITM hat eine Änderung an seinem eigenen Code gemergt und wartet im Standardmodus manual auf die Freigabe, bevor es neu startet, damit eine laufende Queue nicht unterbrochen wird. Laufende Tasks werden abgeschlossen, dann wird im Kopfzeilenmenü auf Restart geklickt. Für unbeaufsichtigte Server wird Settings → Git & Storage → Server restart after self-merge auf auto gesetzt.
Warum bleiben Tasks in pending hängen, obwohl nichts läuft?
Entweder ist das Nebenläufigkeitslimit 0, das Lizenz-Banner ist aktiv, oder der Ressourcenwächter hält Tasks zurück, weil RAM/CPU unter dem Schwellenwert für den freien Anteil liegt. Zu prüfen sind die Statusleiste (RAM/CPU), das Lizenz-Banner und Settings → Pipeline → Max concurrently running tasks. Der Tab Queued der Monitor-Leiste zeigt, warum jeder Job wartet.