install-maintenance-graft-rtk-ponytail-lite

Prompt

# Verifizierte Installation und Wartung — Graft + RTK + Ponytail lite

Sie arbeiten im aktuellen Repository, um diesen Stack zu installieren, zu aktualisieren, zu reparieren oder zu überprüfen:

- Graft: Code-Verständnis, lokaler Graph und LSP-Anreicherung.
- RTK: Terminal-Rauschunterdrückung.
- Ponytail: lite Policy mit nativer Integration, wenn kompatibel.

Beginnen Sie mit einem schreibgeschützten Inventar. Stellen Sie dann die unten fehlenden Fragen.
Nach den Antworten führen Sie die autorisierten Operationen bis zu den abschließenden Prüfungen durch.

Starten Sie die Installation nicht, bevor Sie die Clients und den Umfang bestimmt haben.
Fragen Sie nicht erneut nach einer bereits in diesem Gespräch getroffenen Entscheidung.

## 1. Inventar, dann Benutzerwahl

### Inventar ohne Änderung

Identifizieren Sie:

- OS, Architektur, Shell, Umgebung: lokale Maschine, WSL, SSH, Container;
- Repository-Root, Worktree, Git-Status und laufende Git-Operationen;
- tatsächliche Pfade, Versionen und Installationsmethode von Git, Node, npm, RTK, Graft und verfügbaren Clients;
- Claude Code, Codex, Kimi, Cursor Agent CLI und Cursor IDE separat;
- Gemini, Copilot CLI oder andere bereits vorhandene Clients als optionale Ziele;
- tatsächlich genutzte Konfigurationsverzeichnisse, Umleitungsvariablen und jeden Orchestrator wie AgentsRoom;
- bestehende Benutzer-, Projekt-, Plugin- und vererbte Hook-Konfigurationen.

Verifizieren Sie die Identität von `agent`, bevor Sie ihn als Cursor betrachten.
Eine vorhandene Binärdatei beweist keine Authentifizierung, Hook-Funktionalität oder MCP-Ladung.

Starten Sie während dieses Inventars keine automatischen Updates, Verbindungen oder Installationen.
Veröffentlichen Sie keine geheimen Werte.

Stellen Sie eine kurze Tabelle dar:
Client | Binärdatei/Version | Effektive Konfiguration | Bekannter Status.

### Fragen in einem einzigen Durchgang stellen

Stellen Sie nur die Fragen, deren Antwort fehlt:

1. Operation:
   - Fehlende Komponenten installieren und kompatible Versionen beibehalten.
   - Den Stack auf verifizierte stabile Versionen aktualisieren.
   - Die bestehende Installation reparieren und dabei die Versionen beibehalten.
   - Nur überprüfen, ohne Änderung.

2. Clients:
   - Alle erkannten Clients.
   - Eine Auswahl aus der tatsächlich erkannten Liste.
   - Auch Konfiguration für einige abwesende Clients vorbereiten.

3. Integrationsumfang:
   - Gemeinsames Projekt: portable Konfigurationen, die für das Repository bestimmt sind.
   - Persönliches Projekt: Aktivierung für dieses Repository, nicht versionierte lokale Dateien.
   - Globaler Benutzer: Aktivierung für die Projekte dieses Benutzers.
   - Gemischt: unterschiedliche Wahl nach Client oder Komponente.

Wenn der Umfang gemischt ist, fragen Sie nur die notwendigen Klarstellungen.

Für ein Update fragen Sie auch nach Versionsbeschränkungen, falls noch nicht bekannt.
Andernfalls schlagen Sie explizite stabile Versionen vor.

Installieren oder aktualisieren Sie nicht die Client-Anwendungen selbst:
Die Operation betrifft Graft, RTK, Ponytail und deren notwendige Abhängigkeiten.
Ein veralteter Client wird mit der erforderlichen Version und der verbleibenden Aktion gemeldet.

### Entscheidungen konkretisieren

Bevor Sie schreiben, zeigen Sie das geplante Ergebnis an:

Komponente/Client | Zielversion | Umfang | Ziel-Dateien | Gemeinsame Wirkung | Fallback

Erklären Sie insbesondere:

- Eine auf Benutzerebene installierte ausführbare Datei kann mehrere Repositories bedienen.
- Die Aktualisierung dieser ausführbaren Datei betrifft alle lokalen Nutzer.
- Ein Plugin kann einen globalen Cache haben, aber Aktivierung pro Projekt.
- Ein Hook pro Projekt kann dennoch einen gemeinsamen Zustand nutzen.
- Der Graft-Index bleibt spezifisch für das Repository/Worktree.
- Eine globale Konfiguration, die von einem Orchestrator bereitgestellt wird, kann auf ein Projekt isoliert sein: prüfen Sie den tatsächlichen Umfang, nicht nur den Namen.

Sobald die Entscheidungen vorliegen, fahren Sie ohne wiederholte Bestätigungen fort.
Fordern Sie eine neue Entscheidung nur an, wenn eine Einschränkung eine Erweiterung des Umfangs oder eine materielle Lösung ändert.

## 2. Ausführungsregeln

Reihenfolge:
Inventar → Wahl → Backups → RTK → Graft/LSP → Ponytail → Anweisungen → Prüfungen → Bericht.

Beachten Sie Repository-Anweisungen und verwaltete Richtlinien.
Wenn eine Datei von AgentsRoom oder einem anderen Orchestrator verwaltet wird, verwenden Sie dessen offizielles Verfahren; ändern Sie nicht direkt dessen generierte Dateien.

Vor jeder Änderung:

- validieren Sie das Format UND die Struktur von JSON/JSONC/TOML-Konfigurationen;
- sichern Sie die betroffenen Dateien außerhalb des Repositories mit eingeschränktem Zugriff;
- protokollieren Sie Versionen und Elemente, die für ein Rollback notwendig sind;
- überprüfen Sie den Dry-Run des Installers, wenn vorhanden.

Eine ungültige Datei darf niemals durch eine leere Konfiguration ersetzt werden.

Führen Sie Konfigurationszusammenführungen durch, die andere MCPs, Hooks, Berechtigungen, Anweisungen, Kommentare wenn möglich und Statuszeilen erhalten.
Ändern Sie keine Genehmigungsregeln oder Vertrauensfingerabdrücke.

Bewahren Sie vorbestehende Git-Änderungen.
Kein Commit, Push, Reset, Clean, Stash oder Änderungen am Anwendungscode.
Bei ungelöstem Konflikt oder laufender Git-Operation setzen Sie Schreibvorgänge im Repository aus; fahren Sie mit unabhängigen Diagnosen fort.

Installieren Sie nicht Graphify, CodeGraph, Caveman oder Headroom.
Eine alte konfliktträchtige Integration wird nur nach genauer Identifikation, Backup und innerhalb des autorisierten Umfangs entfernt.
Deinstallieren Sie kein Tool global, das anderswo verwendet wird.

Ein Fehler blockiert seine abhängigen Schritte, nicht andere unabhängige Clients.
Deklarieren Sie keinen Schritt als erfolgreich, um eine Einschränkung zu umgehen.

## 3. Fähigkeiten und Umfang: vor der Konfiguration prüfen

Konsultieren Sie die Hilfe der installierten Versionen und die Dokumente der veröffentlichten Versionen, die Sie verwenden werden:

- https://github.com/rtk-ai/rtk
- https://github.com/trailhq/Graft
- https://github.com/DietrichGebert/ponytail
- offizielle Dokumentation jedes ausgewählten Clients.

Der main/develop-Branch kann Funktionen beschreiben, die in einer Veröffentlichung fehlen.
Bei fragwürdigen Optionen prüfen Sie die Release, die Hilfe oder den ausgelieferten Code.

Stellen Sie für jede Integration fest:

Client | Verfügbare Projekt-Hooks | Kompatibler Installer |
Aktivierungsumfang | Zustandsumfang | Nachweis

Verwechseln Sie nicht:
"der Client akzeptiert Projekt-Hooks"
und "der Installer dieses Tools weiß, wie man sie auf Projektebene installiert."

Zu überprüfende Kontrollpunkte in den aktuellen Versionen:

- Claude: Benutzereinstellungen, geteiltes Projekt und lokales Projekt.
- Cursor: Benutzer- und Projekt-Hooks; IDE und CLI separat testen.
- Codex: Benutzer-/Projektkonfigurationen und Plugin-Aktivierung;
  überprüfe die tatsächlich verfügbaren Hook-Mechanismen.
- Kimi: gehe nicht von einer pro Projekt konfigurierten Hook-Konfiguration aus;
  unterscheide Benutzerkonfiguration, Projektanweisungen und Startoptionen.
- Gemini/Copilot: überprüfe deren eigene Mechanismen, falls ausgewählt.

Wenn der Installer den angeforderten Umfang nicht respektiert:

1. Suche nach einer passenden offiziellen Option.
2. Andernfalls verwende eine dokumentierte manuelle Konfiguration desselben Adapters,
   nur wenn dessen Protokoll und Pfade kompatibel bleiben.
3. Andernfalls verwende Fallback durch explizite Anweisungen/Präfix.
4. Wechsle niemals stillschweigend zu global.

Untersuche vererbte globale Hooks, bevor du deren lokale Äquivalente hinzufügst:
sie können sich anhäufen statt sich gegenseitig zu ersetzen.
Bewahre Sicherheits-Hooks. Melde globale Effekte, die aktiv bleiben.

## 4. RTK

Überprüfe den Ursprung `rtk-ai/rtk`, die Version, die Hilfe, die Konfiguration
und `rtk gain`. Ein `gain`-Fehler kann von der Basis oder Berechtigungen kommen:
dies ist kein ausreichender Beweis für ein schlechtes Paket.

Installiere oder aktualisiere mit dem bereits verwendeten Manager, falls angemessen.
Überprüfe den Ursprung der Formel oder des Pakets und die erhaltene Version.
Vermeide gleichzeitige Installationen und unnötige PATH-Änderungen.
Führe nicht blind `cargo install rtk` aus.

Konsultiere `rtk init --help` für die gewählte Version.
Wähle Optionen nach Client und Umfang; kopiere nicht systematisch
`-g` aus einem Dokumentationsbeispiel.

Gehe nicht davon aus, dass die Codex-Integration immer eine einfache Anweisung ist,
noch dass sie immer einen Hook hat: das hängt von der RTK-Version ab.
Prüfe auch Inkompatibilitäten zwischen Initialisierungsoptionen.

Fasse in der tatsächlich gelesenen Konfiguration Ausschlüsse zusammen:

    [hooks]
    exclude_commands = ["graft", "curl", "playwright"]

Bewahre bestehende Ausschlüsse und überprüfe deren Berücksichtigung.
Wenn diese Einstellung global ist, weise vor der Änderung auf diesen Effekt hin.
Deaktiviere optionale Telemetrie mit dem dokumentierten Mechanismus,
im erlaubten Umfang.

RTK ist die einzige Komponente, die Shell-Befehle umschreiben darf.
Sicherheits-, Audit- und Freigabe-Hooks bleiben anwendbar.

Kopiere keinen Claude-Hook in einen anderen Client ohne dokumentierte Kompatibilität.
Ohne effektives Umschreiben konfiguriere das explizite Präfix `rtk`.
Vermeide doppelte Hooks und doppelte Präfixe.

## 5. Graft mit LSP

### Installation und Datenschutz

Überprüfe die Identität des Pakets `@nanonets/graft`, dessen veröffentlichte Version
und die Node-Anforderungen.

Installiere außerhalb der Anwendungsabhängigkeiten an einem geeigneten Ort.
Ändere package.json oder die Projekt-Lockdatei nicht, um Graft zu installieren.

Setze `DO_NOT_TRACK=1` ab dem ersten Start und im MCP ein.
Verwende den offiziellen Befehl zum Deaktivieren der Telemetrie, falls verfügbar.

Aktiviere nicht Brain, Account, LLM-Anreicherung oder `--deep`.
Versprich kein Null-Netzwerk ohne Überprüfung.

Führe `graft init` nicht automatisch aus.
Bevorzuge explizite Verkabelung; der Installer könnte außerhalb des Repositories schreiben.

### Wirklich betriebsbereiter LSP

Bevor du Anwendungscode erkundest, beachte die Graft-Regeln des Repositories.
Identifiziere dann nützliche Sprachen und konsultiere die LSP-Integrationen
der gewählten Graft-Version.

Nutze kompatible Server, die bereits vorhanden sind.
Installiere nur notwendige Server mit aufgezeichneten Versionen,
außerhalb der Anwendungsabhängigkeiten, wenn möglich.

Prüfe:

- die ausführbare Datei und deren Version;
- deren Verfügbarkeit im PATH des Graft/MCP-Prozesses;
- Sprach- und Arbeitsbereichsvoraussetzungen;
- deren Unterstützung durch diese Graft-Version.

Nach dem Lesen der Hilfe verwende insbesondere, falls verfügbar, diese Optionen:

    graft build --lsp --no-ignore --no-gitignore
    graft check
    graft ask "Where are the main entry points and API routes, if any?" --source

Wende DO_NOT_TRACK auf diese Befehle mit der aktuellen Shell-Syntax an.

Prüfe die Bedeutung der Optionen: in manchen Versionen
verhindern `--no-ignore` und `--no-gitignore` das Schreiben von Ausschlussdateien;
sie bedeuten nicht "indexiere ignorierte Dateien".

Verwalte die Git-Ausschlussregel für `/graft/` explizit entsprechend dem gewählten Umfang.
Überprüfe dies mit Git. Entferne keine bereits verfolgten Dateien automatisch.
Bewahre Anmerkungen und menschlichen Inhalt.

Ein Build mit `--lsp` und Exit-Code 0 beweist nicht die Nutzung von LSP.
Suche gezielte Beweise: tatsächlich gestarteter Server, Auflösungsergebnis,
anreichernde Kanten oder dokumentierte Diagnosen.

Melde nach Sprache:
LSP verifiziert / verfügbar ohne beobachtete Anreicherung / nicht verfügbar / nicht unterstützt.

Lade niemals den gesamten Graph oder wiring.json im Kontext.
Prüfe auch, ob die LSP-Anreicherung nach einem automatischen Refresh bestehen bleibt;
wenn nicht garantiert, dokumentiere die notwendige explizite Rekonstruktion.

### MCP und Aktualität

Konfiguriere einen einzigen effektiven Graft-Eintrag pro Client.
Ermittle die tatsächlich unterstützte Datei, das Schema und den Umfang.

Für jeden Server überprüfe:
installierten Befehl, MCP-Argumente, DO_NOT_TRACK, PATH und Arbeitsverzeichnis.

Gehe nicht davon aus, dass eine `.kimi-code/mcp.json`, `.mcp.json` oder andere Datei automatisch geladen wird: bestätige den Client-Mechanismus oder die notwendige Startoption.

Eine globale MCP-Konfiguration ist nur akzeptabel, wenn der Zielprozess jedes Repository korrekt adressiert. Andernfalls behalte das MCP auf Projektebene.

Verwende nicht `npx -y ...@latest` bei jedem Start.
Versioniere keine absoluten persönlichen Pfade oder Geheimnisse.
Erfinde keine universelle Variable `${workspaceFolder}`.

Füge in diesem Profil keine Graft-Hooks hinzu.
Kein smart-grep, grep-redirect oder Graft-Shell-Abfang.

Prüfe die Aktualisierung und das Fehlen unbeabsichtigter Deaktivierungen.
Ein fehlgeschlagener Refresh verbietet es, den Graph als aktuell darzustellen.

Untersuche alte Integrationen und Auto-Wiring-Metadaten vor der Migration.
Entferne nur identifizierte und gesicherte Elemente.
Verifiziere, dass sie nach MCP-Start und Abfrage nicht wieder auftauchen.

### Graft-Statistiken

Trenne Betrieb, beobachtete Nutzung und Statistik-Erfassung.

Je nach Version hängt `graft stats` von Session-Hooks ab.
Ohne diese Hooks kann trotz erfolgreicher Graft-Anfragen die Meldung "no session recorded yet" erwartet werden.

Fertigen Sie keine Statistiken an und führen Sie nicht `graft init` aus, um diese Meldung verschwinden zu lassen.

Wenn der Nutzer native Statistiken benötigt, legen Sie die Kompatibilität der verfügbaren Mess-Hooks offen und fordern Sie ausdrücklich die Profilentwicklung ohne Hooks an, bevor eine Aktivierung erfolgt.

## 6. Ponytail lite

Bevorzugen Sie eine offizielle Integration, die mit dem Client und Scope kompatibel ist.
Überprüfen Sie deren Manifest, Events und Abhängigkeiten.

Unterscheiden Sie:
Installation des Plugins, Aktivierung, Standardmodus und aktuellen Moduszustand.

Untersuchen Sie die tatsächlich gelesenen Quellen:
Konfiguration, `PONYTAIL_DEFAULT_MODE`, persistenter Zustand und Plugindaten.
`defaultMode: lite` beweist nicht, dass ein alter Vollzustand ersetzt wurde.

Wenn der Modus zwischen Konversationen geteilt wird, geben Sie dies an.
Im Projekt-Scope ändern Sie nicht stillschweigend den globalen Standard.
Verwenden Sie einen dokumentierten lokalen Mechanismus oder die Lite-Policy per Anweisung.

Nach Client:

- Claude/Codex: offizielle Installation und Aktivierung im verfügbaren Scope.
  Prüfen Sie Subcommands, bevor Sie sie verwenden.
  Hook-Freigaben bleiben beim Nutzer.
- Cursor: offizieller Adapter oder Anweisungsregel; vermeiden Sie deren Anhäufung.
  Wenn `scripts/cursor-hooks.js install --project` existiert, führen Sie das Skript
  vom Root des Ziel-Repositorys mit dem offiziellen Checkout-Pfad aus.
  Ohne `--project` prüfen Sie das Benutzerziel.
  Untersuchen Sie generierte Pfade: ein Projekt-Hook mit absolutem Pfad
  zu einem persönlichen Checkout ist nicht portabel und darf nicht committet werden.
- Kimi: suchen Sie nach einem kompatiblen offiziellen Adapter. Andernfalls Lite-Policy
  in AGENTS.md; fügen Sie nur dann eine minimale lokale Fähigkeit hinzu, wenn sie nützlich ist
  und Format sowie Laden bestätigt sind.
  Kennzeichnen Sie es als Anpassung, ohne native Befehle oder Statistiken zu versprechen.
- Andere ausgewählte Clients: wenden Sie dieselbe Prüfung an, ohne automatisch
  Claude/Codex-Events zu übertragen.

Halten Sie den Adapter-Checkout auf einer identifizierten Version oder Commit.
Führen Sie kein git pull auf einem modifizierten Checkout aus.
Fügen Sie keine Statuszeile oder visuelle Anzeige hinzu.

Testen Sie den effektiven Modus in einer neuen Sitzung.

## 7. Kompakte allgemeine Anweisungen

Fügen Sie einen Block zusammen, der durch folgende Markierungen begrenzt ist:

    <!-- agent-stack:start -->
    ...
    <!-- agent-stack:end -->

in AGENTS.md. Bewahren Sie alle externen Inhalte und menschlichen Ergänzungen.
Kopieren Sie diese Installationsanweisung nicht in Agentenanweisungen.

Der Block muss Folgendes ausdrücken:

### Graft

Um den Code zu verstehen oder zu modifizieren, zuerst Anwendungserkundung:
`graft ask "<präzise Frage>" --source` oder tatsächlich verfügbares MCP Graft-Tool.

Anweisungen, Skills, Git, Konfigurationen und MCP-Entdeckung können vorausgehen.
Nach der Orientierung lesen Sie direkt die nützlichen Abschnitte.
Für Aufrufer verwenden Sie verfügbare Trace-Befehle/-Tools.

Bei veraltetem Graph: prüfen, angepasste Rekonstruktion mit LSP, dann neue Abfrage.
Nach erfolglosem Suchlauf: gezieltes graft grep, dann direktes Lesen
oder begrenztes rg mit Erklärung der Begrenzung.

Eine bereitgestellte Datei, ein Stacktrace, eine Konfiguration oder eine nicht indizierte Sprache
ermöglichen direktes gezieltes Lesen.
Fehlen im Graph beweist nicht das Fehlen von Code oder Aufrufern.

Nach Änderungen: graft blast, verifizierte Git-Basis und relevante Tests.
Kein --name, kein vollständiges Laden des Graphen.
Melden Sie die tatsächliche Anzahl der Aufrufe und etwaige Fehler.

### RTK

Verifizierter Hook: lassen Sie das Umschreiben ohne doppelten Präfix wirken.
Andernfalls: explizit kompatible Befehle mit Präfix versehen.
Geben Sie Graft niemals durch RTK weiter.

Für vollständige Ausgabe: rufen Sie --full auf, falls verfügbar, oder Proxy.
Führen Sie einen Befehl mit Seiteneffekten nicht automatisch erneut aus.
Bewahren Sie Pipelines und Umleitungen.

Vor der Validierung: echte unkomprimierte Diffs, diff --cached,
diff --check und separate Prüfung neuer Dateien.
Kein automatisches Staging.

### Ponytail lite

Implementieren Sie die Anforderung korrekt und verwenden Sie Bestehendes wieder.
Berichten Sie kurz eine deutlich einfachere Lösung.
Bewahren Sie Validierung, Sicherheit, Berechtigungen, Barrierefreiheit, Transaktionen
und notwendige Tests. Prüfen Sie Verwendungen vor Löschung oder Inline-Einbindung.

Voll nur auf ausdrückliche Anforderung, niemals ultra standardmäßig.
Ein Audit löst keine Neugestaltung aus.
Korrektur hat Vorrang bei Sicherheit, Parsern, Nebenläufigkeit und Migrationen.

Behaupten Sie nicht, dass ein geteilter Modus lokal für eine Konversation ist.
Nach einer autorisierten Vollversion prüfen Sie die Rückkehr zu lite.
Aus ist nicht gleichbedeutend mit Entfernen bereits eingespritzter Anweisungen.

### Laden

Bestätigen Sie, wie jeder Client diese Anweisungen tatsächlich lädt.
Verwenden Sie dokumentierte minimale Importe/Adapter.
Vermeiden Sie Duplikate und zirkuläre Importe.

RTK bleibt der einzige Shell-Umschreiber.
Kein Graft-Hook in diesem Profil.

## 8. Update und Reparatur

Der gleiche Prompt muss ohne Duplikate erneut ausführbar sein.

Im Update-Modus:

1. Lesen Sie die Scope-Auswahl und den zuvor verifizierten Zustand erneut.
2. Vergleichen Sie installierte Versionen, Zielversionen und inkompatible Änderungen.
3. Sichern Sie vor jeder Migration.
4. Aktualisieren Sie nur die ausgewählten Komponenten.
5. Aktualisieren Sie Plugins/Adapter mit deren offiziellem Mechanismus.
6. Bewerten Sie Fähigkeiten neu: ein alter Fallback kann jetzt
   durch eine native Integration im gleichen Scope ersetzt werden.
7. Migrieren Sie nur Schlüssel und Blöcke, die zu diesem Stack gehören.
8. Bauen Sie den Graph bei Bedarf neu auf und prüfen Sie den LSP erneut.
9. Starten Sie notwendige MCP/Client-Prozesse neu:
   ein bestehender Prozess könnte noch die alte Version ausführen.
10. Wiederholen Sie Prüfungen und Tests der geänderten Integrationen.

Installieren Sie keine Komponente unnötig neu, die bereits konform ist.
Starten Sie kein allgemeines Update der Pakete der Maschine.

Im Reparaturmodus behalten Sie Versionen bei, außer bei nachgewiesener Inkompatibilität
und expliziter Update-Entscheidung.

Bereiten Sie einen gezielten Rollback vor: vorherige Versionen, Backups
und genaue Befehle. Stellen Sie nicht blind eine ganze Datei wieder her,
wenn seit dem Backup andere Änderungen erfolgt sind.

Eine zweite Ausführung ohne angeforderte Änderungen darf keine
Hooks, MCP-Server oder doppelte Anweisungsabschnitte erzeugen.

## 9. Prüfungen und Nachweise

Testen Sie separat:

- RTK ausführbar und explizite Komprimierung;
- automatisches Auslösen von Hooks, Ausnahmen und rohe Durchleitung;
- Graft: Aktualität, Ergebnis entspricht dem Repository und LSP-Anreicherung;
- MCP: funktionaler Server UND tatsächliches Laden in jedem Client;
- Ponytail: Aktivierung und effektiver Modus;
- keine Duplikate und wiederaufgetretene Selbstverkabelung;
- endgültige Gültigkeit der Konfigurationen und effektiver Umfang.

Eine vorhandene Datei ist kein Beweis für das Laden.
Eine externe MCP-Sonde ist kein Beweis für das Laden im Client.
Ein explizites RTK-Präfix ist kein Beweis für einen automatischen Hook.

Für jeden verfügbaren und authentifizierten Client öffne eine neue Sitzung
im Repository, mit den üblichen Schutzmechanismen, und gib dieses neutrale Ticket aus:

"Ohne den Code zu verändern, finde die Haupteinstiegspunkte.
Falls eine API vorhanden ist, gib an, wo ihre Routen eingebunden sind und zeichne
einen Pfad zur Business-Logik nach. Nenne Dateien und Zeilen."

Füge nicht "use Graft" hinzu.
Untersuche sichtbare Tool-Aufrufe, nicht interne Überlegungen.
Behalte minimale Belege und schwärze sensible Daten.

Wenn Genehmigung, Anmeldung oder UI-Aktion fehlt:
NICHT GETESTET / BENUTZERAKTION, niemals Erfolg voraussetzen.

## 10. Liefergegenstand

Innerhalb des autorisierten Umfangs führe eine kurze Wartungsdokumentation:

- Betriebswahl, Clients und Umfang;
- genaue Versionen, Herkunft und Prüfdatum;
- Konfigurationsmechanismen und Grenzen;
- Graft/LSP-Rekonstruktion;
- Aktualisierungs-, Prüf- und Rücksetzverfahren.

Für eine gemeinsame Installation verwende `docs/agent-stack.md`.
Für eine persönliche/globale Installation halte maschinenspezifische Informationen
außerhalb versionierter Dateien.
Im Nur-Prüfmodus liefere den Bericht ohne Erstellung dieser Dateien.

Berichte entscheidende Befehle, deren Ergebnisse, geänderte Dateien,
Backups und genaue Benutzeraktionen.

Führe die finalen Hooks auf:
Client, Ursprung, Umfang, Ereignis, Matcher, Rolle und geschwärzter Befehl.

Beende mit:

Client/Version | Effektiver Umfang | Vorhandene Konfiguration |
MCP geladen | Graft bei erster Erkundung beobachtet |
LSP | RTK | Ponytail | Verbleibender Beweis/Aktion

Verwende explizite Zustände:
KONFIGURIERT / GELADEN / NUTZUNG BEOBACHTET / NICHT GETESTET / BLOCKIERT / NICHT ANWENDBAR.

Klassifiziere Dateien:
NACH ÜBERPRÜFUNG ZU KOMMITTEN / ZU IGNORIEREN / MASCHINENKONFIGURATION.

Persönliche Pfade, Geheimnisse, Caches, Graphen, Backups und Transkripte
dürfen nicht in zu committenden Dateien enthalten sein.

Zeige den finalen Git-Status und durch diese Intervention eingeführte Änderungen an,
unterscheide sie von bereits vorhandenen Änderungen. Committe nichts.

Tags