Diagnose – EmpCo-UWG Monitor

Die Diagnose des Plugins meldet belegt, was in einer Umgebung vorhanden ist, ob die Verbindung zum Regelserver besteht und welche Versionen vorliegen. Sie hilft dem Support, ein Problem einzuordnen, und enthält nie geprüfte Inhalte.

Was der Bericht enthält

Umgebung und Fähigkeiten: Anbieter, Oberfläche, Modell und was die Umgebung kann (Unteragenten, Code ausführen, Dateien lesen und schreiben, Skills laden, Connectors). Jeder Wert nennt seine Quelle und einen wörtlichen Beleg; was sich nicht belegen lässt, steht als unknown.
Verbindung: ob der Connector sichtbar ist, ob die Anmeldung besteht und, bei einem Abruf, Uhrzeit (UTC) und request-id des Abrufs. Mit dieser Kennung findet der Support den Abruf im Zugriffsprotokoll des Servers.
Versionen: Plugin, jeder Skill des Plugins, Connector (Name und Adresse) und der Regelstand je geladenem Schritt, jeweils mit Quelle. Weichen geladene Schrittversionen voneinander ab, benennt der Bericht einen gemischten Stand.
Ablauf des letzten Laufs: Enthält das Gespräch bereits eine Prüfung, wertet der Bericht sie mit aus: Schrittkette, Brüche im Ablauf mit der wahrscheinlichen Ursachengruppe (Host, Verbindung, Regeln, Eingabe) und der Vergleich mit den Kriterien der geladenen Regeln. Der Bericht enthält dazu nur Struktur.

Der Bericht enthält nie geprüfte Texte, Fundstellen oder Analyseergebnisse, und außer mit dem Zusatz voll auch keinen Benutzernamen, keine Pfade und keine Umgebungsvariablen. Nichts wird automatisch gesendet; der Bericht steht in der Antwort, und die Person entscheidet, ob sie ihn weitergibt.

Ablauf

Die Diagnose wählt ihren Modus unmittelbar aus dem Aufruf und dem Gespräch.

Direkter Aufruf: Die Auswahl des Skills, das Einfügen des Diagnosetexts oder ein ausdrücklicher Diagnose- beziehungsweise Modusauftrag startet sofort. In einem Gespräch ohne Prüflauf ruft der Standard-Modus genau einmal die erste Regeldatei ab, prüft die öffentliche Support-Seite und führt eine lesende Umgebungsprobe aus.
Automatischer Start: Leitet der Host die Diagnose aus einer allgemeinen Frage oder Störungsmeldung ab, fragt sie genau einmal mit den Optionen „Bericht erstellen“ und „Abbrechen“. Die Frage klärt zugleich, dass der EmpCo-UWG Monitor gemeint ist; eine zweite Frage folgt nicht.
version: Liefert nur Identität, Plugin-, Skill-, Connector- und bereits geladene Regelversionen sowie einfache Checks für Unteragenten und Webzugriff. Regelabruf, Umgebungsprobe, Verbindungs-Tiefencheck und Ablaufbericht entfallen.
Ablauf: Bei einem vorhandenen Prüflauf oder einer Aufforderung wie „Befund prüfen“ beziehungsweise „prüfe die Antwort“ wertet die Diagnose den letzten Lauf oder die letzte Plugin-Antwort anhand des Gesprächsstands aus und trägt dasselbe Kurzprofil wie version.
Zusätze im Aufruf: technik ergänzt im Ablauf den Bericht zu Umgebung, Fähigkeiten und Versionen. voll enthält zusätzlich die vollständige Werkzeugliste und lokale Umgebungsangaben, die weitere Connectors und lokale Pfade nennen; nur verwenden, wenn der Support sie angefordert hat. In einem Gespräch ohne Prüflauf beruhen beide auf dem Standardbericht mit seinem einen Regelabruf.

Mit dem Plugin

Die Diagnose ist ein eigener Skill des Plugins:

in Claude /empco-uwg-monitor:diagnose-monitor-plugin
in ChatGPT @ und den Skill auswählen
in Codex $ und den Skill auswählen

Er kann auch von selbst starten, wenn die Person allgemein nach Version oder Verbindung des Plugins fragt, über eine mögliche Störung klagt oder eine Plugin-Antwort hinterfragt. Dieser automatische Start klärt mit genau einer Freigabefrage zugleich, dass der EmpCo-UWG Monitor gemeint ist; ein direkter Aufruf startet ohne Frage.

In Microsoft 365 Copilot, Copilot Studio oder einem Custom GPT

Ohne Plugin liefert der Regelserver die Diagnose als eigenen Schritt. Senden Sie im Chat mit dem EmpCo-UWG Monitor diese Nachricht:

Erstelle die Diagnose des EmpCo-UWG Monitors.

Der Bericht nennt die Werkzeuge der Umgebung, den Regelstand mit request-id und die in diesem Chat geladenen Schritte, bei einer vorangegangenen Prüfung auch deren Ablauf. Kommt keine Verbindung zum Regelserver zustande, verwenden Sie den Text zum Einfügen unten.

Wenn Sie das Plugin nicht ausführen können

Fehlt der Befehl oder reagiert das Plugin nicht, verwenden Sie den Kasten Text zum Einfügen am Ende dieser Seite:

Den Text vollständig kopieren.
Im betroffenen Chat als Nachricht senden.
Den erzeugten Bericht an den Support schicken.

Dieser Weg funktioniert auch ohne Verbindung zum Regelserver und in Anwendungen ohne Skills, etwa in Microsoft 365 Copilot, Copilot Studio oder einem Custom GPT. Verwenden Sie nach Möglichkeit einen Chat ohne Projektordner. Der Text entspricht der Anweisung des Skills; Dateiverweise darin beziehen sich auf die Abschnitte am Ende des Textes. Das Einfügen ist ein direkter Aufruf: Die Diagnose startet ohne zusätzliche Freigabefrage und liefert den Bericht in einem Block.

Bericht senden

Den Bericht aus der Antwort kopieren (der Kasten mit dem Text) und per E-Mail an die Adresse auf der Support-Seite senden. Der Betreff steht unter dem Block.

Text zum Einfügen

Diagnosetext

Führe die folgende Diagnose in dieser Umgebung aus: Der Text unten ist deine Anweisung für diesen Lauf, deine Antwort ist der Bericht.

Stand dieses Textes: v1.6.3

# Diagnose des EmpCo-UWG Monitors

Erstelle einen belegten Bericht über diese Umgebung, die Verbindung zum Regelserver und den Stand von Paket und Regeln, damit der Support ein Problem einordnen kann. Der Bericht enthält ausschließlich technische Angaben zu Umgebung, Verbindung, Versionen und Ablauf. Geprüfte Texte, Fundstellen und Analyseergebnisse gehören grundsätzlich nie dazu, in keinem Umfang und in keinem Lauf; schreibe das auch nicht als Eigenschaft dieses einen Laufes („in diesem Lauf wurden keine geprüften Texte übertragen“) in die Kurzfassung. Nichts davon wird an den Server gesendet, und es entsteht keine Datei: Die Person kopiert den Bericht aus der Antwort.

Der Modus ergibt sich aus dem Aufruf und dem Gespräch:

- **`version`:** nur das gemeinsame Kurzprofil aus Identität, Plugin-, Skill-, Connector- und bereits geladenen Regelversionen sowie den einfachen Checks für Unteragenten und Webzugriff. Seine Werkzeughandlungen beschränken sich auf die dafür erforderlichen Paketdateien und einfachen Checks; die Ausgabe enthält ausschließlich das Kurzprofil.
- **Ablauf-Modus** (das Gespräch enthält einen bereits vorhandenen Prüflauf oder die Person lässt eine vorhandene Plugin-Antwort prüfen, und der Aufruf nennt keinen anderen Modus): Der Ablaufbericht (Datei `references/ablauf.md`, in der Textfassung der Abschnitt „Ablaufbericht“ am Ende) wertet den letzten Lauf beziehungsweise die letzte Plugin-Antwort aus und enthält dasselbe Kurzprofil wie `version`. Ein vorhandener Prüflauf liegt vor, wenn das Gespräch vor diesem Aufruf bereits Antworten von `empco-uwg-monitor:fetch_claims_monitor_step` (Frontmatter mit `next-steps`) oder eine Prüfung enthält; der eigene Abruf dieser Diagnose zählt nicht. Eine Aufforderung wie „Befund prüfen“ oder „prüfe die Antwort“ wählt den Ablauf-Modus, wenn bereits eine Plugin-Antwort vorliegt. Geladene Schritte belegen Anmeldung und Regelstand; der Modus verwendet den vorhandenen Gesprächsstand.
- **Standard-Modus** (das Gespräch enthält keinen Prüflauf und der Aufruf nennt keinen anderen Modus): der technische Bericht dieser Anweisung mit genau einem Abruf von `report-intake`; seine Ausgabe besteht aus dem technischen Bericht.
- **Zusätze:** `technik` ergänzt im Ablauf-Modus den technischen Bericht mit dem geladenen Gesprächsstand. `voll` enthält immer den technischen Bericht und zusätzlich die vollständige Werkzeugliste sowie lokale Umgebungsangaben; im Ablauf-Modus verwendet er ebenfalls den geladenen Gesprächsstand. Bei einem Diagnoseaufruf in einem Gespräch ohne Prüflauf beruhen `technik` und `voll` auf dem Standardbericht mit seinem einen Regelabruf.

## Zu Beginn: Modus und Freigabe

Ein **direkter Aufruf** liegt vor, wenn die Person den Skill mit Slash, `@` oder `$` auswählt, den vollständigen Diagnosetext einfügt, ausdrücklich die Diagnose verlangt oder `version`, `technik` beziehungsweise `voll` als Steuerwort an einen Diagnoseauftrag anhängt. Starte dann ohne Freigabefrage im bestimmten Modus. Eine allgemeine Frage nach der Version ohne Diagnoseauftrag ist dagegen ein möglicher automatischer Start.

Ein **automatischer Start** liegt vor, wenn der Host diesen Skill aufgrund einer allgemeinen Frage nach Version, Stand, Verbindung, einer Störung oder dem Ablauf des Plugins geladen hat. Stelle vor jeder Handlung genau eine Frage, die zugleich klärt, dass der EmpCo-UWG Monitor gemeint ist, und die Diagnose freigibt. Nutze ein Auswahlwerkzeug (etwa `AskUserQuestion`, `Ask User Input`, `request_user_input`); steht keines zur Verfügung, stelle eine kurze Textfrage, in der jede Option in einer eigenen Zeile mit Buchstaben steht und auf die der Buchstabe als Antwort genügt. Die Optionen lauten **„Bericht erstellen“** (Diagnose im aus dem Gespräch bestimmten Modus starten) und **„Abbrechen“** (ohne Handlung beenden); als Textfrage: „A) Bericht erstellen“, darunter „B) Abbrechen“. Nenne in der Frage die Handlungen des bestimmten Modus; im Standard-Modus sind das ein Abruf der Regeln (`report-intake`, erscheint im Zugriffsprotokoll des Servers, beginnt keine Prüfung), ein Abruf der öffentlichen Support-Seite, eine lesende Umgebungsprobe und die lesende Suche nach einem Projekt. Stelle davor oder danach keine zweite Relevanz-, Umfangs- oder Freigabefrage.

Wählt die Person „Abbrechen“ oder wird die Freigabefrage abgebrochen, übersprungen oder geschlossen, führst du nichts aus: kein Befehl, kein Abruf, kein Bericht; sage in einem Satz, dass nichts ausgeführt wurde und die Diagnose jederzeit direkt aufgerufen werden kann.

## Kernregeln

1. **Belege statt Namen.** Ein Produkt- oder Modellname beweist keine Fähigkeit. Jeder Wert `true` oder `false` nennt `source` und `evidence`.
2. **`source`, stärkster zuerst:** `probe` (eine harmlose Handlung, deren Ergebnis beobachtet wurde), `tool` (Werkzeug mit lesbarer Beschreibung), `prompt` (ausdrückliche Aussage der Anweisungen), `inference` (indirekte Hinweise), `self` (eigene Annahme). `evidence` ist ein wörtliches Zitat: Werkzeugname mit dem ersten Satz der Beschreibung, eine Ausgabezeile oder die Formulierung der Anweisung.
3. **`unknown` ist eine vollständige Antwort.** Ohne Zitat steht `unknown`. `false` gilt nur nach einem unmittelbaren Fehlschlag oder einer ausdrücklichen Aussage; ein fehlendes Werkzeug genügt nur, wenn das Werkzeuginventar nachweislich vollständig ist.
4. **Schreibgeschützt und datensparsam.** Keine Werkzeuge eines Connectors aufrufen außer dem einen Abruf in Schritt 4 im Standard-Modus. Nichts installieren, nichts senden, keine Geheimnisse ausgeben. Die Ausgabe enthält außer mit dem Zusatz `voll` nicht die vollständige Werkzeugliste (sie nennt die übrigen Konnektoren der Person), keine Pfade mit Benutzernamen und keine Umgebungsvariablen.

## Ablauf

### 1. Identität und Werkzeuge

Nenne Anbieter, Produkt, Oberfläche und Modell nur, soweit die Anweisungen es ausdrücklich sagen; sonst `unknown`. Im Modus `version` und im Ablauf-Modus ohne `technik` oder `voll` suchst du in der Werkzeugliste nur die Kandidaten für die beiden einfachen Checks aus Schritt 2 und den Dateizugriff für Schritt 5. Im Standard-Modus sowie mit `technik` oder `voll` gehst du die eigene Werkzeugliste einschließlich nachladbarer Werkzeuge durch und ordnest sie anhand ihrer Beschreibung diesen Fähigkeiten zu: `agents.spawn`, `code.execute`, `files.read`, `files.write`, `files.deliver`, `web.fetch`, `skills.load`, `mcp.connectors`. Ein Namensmuster ist ein Kandidat, kein Beleg; ist von einem nachladbaren Werkzeug nur der Name bekannt, lade seine Beschreibung (etwa über die Werkzeugsuche des Hosts), bevor du es zuordnest oder `unknown` setzt. Die Liste selbst gehört nur mit dem Zusatz `voll` in den Bericht.

### 2. Einfache Checks: Unteragent und Webzugriff

Erzeuge ein Nonce (mit Shell: `head -c 6 /dev/urandom | od -An -tx1 | tr -d ' \n'`; ohne: eine selbst erfundene Zeichenfolge und sage das). Starte mit dem allgemeinen Unteragenten genau diese Aufgabe: „Antworte mit genau dieser Zeichenfolge und sonst nichts: `<Nonce>`“. Gleiche Antwort ergibt `agents.spawn: true, source: probe`; Fehler oder Abweichung ergeben `false` mit dem beobachteten Fehler als Beleg. Gibt es keinen Kandidaten, startest du nichts: `unknown`.

Für `web.fetch` ruft du, wenn ein Webwerkzeug vorhanden ist, genau einmal `https://claims.agent-services.at/support` ab (öffentliche Seite des Servers, ohne Anmeldung). Zeigt das Ergebnis die Überschrift „Support“, gilt `web.fetch: true, source: probe` mit dieser Überschrift als Beleg; ein Fehler ergibt `false` mit der beobachteten Meldung; ohne Webwerkzeug steht `unknown`.

### 3. Umgebung (nur Standard-Modus, `technik` und `voll`, nur mit Shell)

Führe die „Umgebungsprobe“ aus (Datei `scripts/probe.sh`, in der Textfassung der Skriptblock am Ende). Es meldet Betriebssystem, Marker der Sandbox, vorhandene Programme und Bibliotheken; die Uhrzeit in UTC; Benutzername, Arbeitsverzeichnis und Umgebungsvariablen nur mit dem Argument `--roh`, das du nur mit dem Zusatz `voll` verwendest. Ohne Shell ist der Schritt nicht ausführbar; die zugehörigen Werte sind `unknown`.

### 4. Lieferung und Verbindung (nicht in `version`)

- **`loaded_as`:** `plugin-skill`, `project-skill`, `pasted-text`, `system-prompt` oder `unknown`, mit dem Pfad oder der Formulierung als Beleg.
- **`package_files`:** Mit Dateizugriff prüfen, welche dieser Dateien neben oder oberhalb des Skills liegen (bis zu drei Ebenen): `plugin.json`, `.claude-plugin/plugin.json`, `mcp.json`, `.mcp.json`, `agents/openai.yaml`. Ohne Dateizugriff `unknown`.
- **Verbindung:** Nenne, ob `empco-uwg-monitor:fetch_claims_monitor_step` sichtbar ist (Werkzeugname des Hosts wörtlich; Hosts zeigen es mit Präfixen wie `mcp__<Server>__`) und ob der Host den Connector als anmeldepflichtig oder nicht angemeldet führt. Rufe es dafür nicht auf.
- **Abruf (nur Standard-Modus):** genau ein Aufruf von `report-intake`, dessen Antwort du nur für Schritt 5 nutzt, ohne eine Prüfung zu beginnen. Ermittle unmittelbar danach die Uhrzeit in UTC (mit Shell `date -u +%Y-%m-%dT%H:%M:%SZ`) und übernimm `request-id` aus dem Frontmatter der Antwort, soweit vorhanden; beides lässt dem Support den Abruf im Zugriffsprotokoll des Servers finden. Im Ablauf-Modus sowie bei `version` steht `fetch: not_run`; bei `version` erscheint das Feld nicht im Bericht. Fehlt das Werkzeug im Standard-Modus, steht `fetch: not_run` mit dem Beleg „Werkzeug nicht verfügbar“; scheitert ein Aufruf, steht `failed`. In beiden Fällen nenne die beobachtete Meldung wörtlich und verweise für die Schritte zur Anmeldung auf die Anleitung der Anwendung, Abschnitt „Verbindung neu anmelden“ (https://claims.agent-services.at/einrichtung/claude#verbindung-neu-anmelden, https://claims.agent-services.at/einrichtung/chatgpt#verbindung-neu-anmelden; für andere Anwendungen https://claims.agent-services.at/einrichtung) und bei anhaltendem Fehler auf den Support (`references/support.md`, ohne Skill die Seite `/support`).

### 5. Versionen

Diese Versionsliste gehört zum gemeinsamen Kurzprofil von `version` und Ablauf-Modus sowie in jeden technischen Bericht. Lies mit Dateizugriff nur die dafür erforderlichen Paketdateien. Gib die Ebenen getrennt aus; jede mit Quelle, eine nicht verfügbare als `nicht feststellbar`, nie aus einer anderen Ebene oder aus Datei- und Ordnernamen abgeleitet:

- **Plugin-Version:** das Feld `version` des installierten Plugin-Manifests (`plugin.json`, `.claude-plugin/plugin.json`) oder eine ausdrücklich vom Host bereitgestellte Paketversion, mit Pakettyp und Wert (z. B. `Plugin-Version: 1.0.0`). Gibt es keine separate Paketform, `kein Paket`.
- **Alle Skills des Pakets:** je `skills/<Name>/SKILL.md` im Paket (Verzeichnis oberhalb dieses Skills, siehe `package_files`) `version` und `build` aus dem Frontmatter, eine Zeile je Skill; dazu gehört dieser Skill. Ist nur dieser Skill lesbar, nenne die übrigen als `nicht feststellbar`.
- **Connectors des Pakets:** je Server in `mcp.json` beziehungsweise `.mcp.json` Name und Adresse (ohne Query und Zugangsdaten). Die Version des Servers steht nur im Bericht, wenn der Host sie nennt (etwa als Server-Version der Verbindung), sonst `nicht feststellbar`; der Regelstand der Schrittantwort ist ein eigener Wert.
- **Skill- oder Instructions-Stand:** `version` und `build` im Frontmatter dieses Skills; ohne Skill die Zeile „Stand dieses Textes“ am Anfang dieser Anweisung oder, bei einem Instructions-Feld, `build` in dessen Frontmatter. Fehlt `build` und steht nur `version`, benenne das und nenne den Wert trotzdem („kein `build`-Feld, nur `version: X.Y` – Hinweis auf eine ungebaute Quelldatei statt des gebauten Artefakts“). Fehlen beide, benenne das als Anomalie, ohne einen Wert zu erfinden. `build` ist ein Git-Stand (Tag, Commit-Abstand, Kurzkennung): Er wird nicht mit `version` verglichen; ein Anhang `dirty` nennst du als Hinweis auf nicht eingecheckte Änderungen im Bau.
- **Regelstand:** nur aus einer Schrittantwort dieses Gesprächs: `version`, `platform` (Plattform des Zugriffs) und `variant` (Plattform der gelieferten Variante) sowie `build` aus dem Frontmatter je geladenem Schritt. `version` einer Schrittantwort ist der Stand des Regelpakets und stammt aus derselben Quelle wie die Version von Plugin und Skills (`1.0.0`, in einem Entwicklungsbau `1.0.0-dev.<Kennung>`); `build` ist der Git-Stand, aus dem die Regeln gebaut wurden (Tag, Commit-Abstand, Kurzkennung, bei nicht eingecheckten Änderungen `dirty`), und wird nicht mit `version` verglichen; fehlt es, nenne das als Befund und erfinde keinen Wert. Fehlt `variant`, wurden die Basisregeln geliefert; fehlt `platform`, hat keine Quelle (Pfad, Argument des Werkzeugs, zugeordneter Client) eine Plattform genannt, auch das ist kein Befund. Wurde noch kein Schritt geladen, steht dennoch die Zeile `step:report-intake` mit dem Regelstand `nicht geladen`.
- Vergleiche `version` und `build` innerhalb ihrer Auslieferungsoberfläche: Die geladenen Schritte bilden den live ausgelieferten Regelstand, Plugin und Skills den paketierten Stand. Abweichungen innerhalb einer Oberfläche kennzeichnest du als möglichen gemischten Stand beziehungsweise Konflikt. Ein jüngerer `build` der live ausgelieferten Regeln gegenüber dem paketierten Stand ist ein erwarteter Auslieferungsunterschied und ändert `mixed_state` nicht.

### 6. Projekt (Standard-Modus, `technik` und `voll`, nur mit Dateizugriff)

Stelle lesend fest, ob für diesen Arbeitsordner ein Projekt des Skills `manage-claim-monitor-project` eingerichtet ist: Lies dazu `<Ordner>/empco-uwg-monitor/projekt.md` für jeden Ordner einzeln, beginnend beim Arbeitsordner des Gesprächs und dann Ebene für Ebene aufwärts bis zum obersten Ordner; die zuerst gefundene Datei gilt. Lies mit dem vollständigen Pfad, der den Arbeitsordner ausschreibt. `found: true` steht nur, wenn du `projekt.md` gelesen hast; meldet ein Suchmuster die Datei, lies sie danach mit vollständigem Pfad, bevor du `found` setzt. Ein Suchmuster über Unterordner ersetzt diese Suche nicht. Ohne Fund auf allen Ebenen stehen `found: false` und `levels_above: none`. Lies sie und, falls vorhanden, `triage.md` im selben Ordner `empco-uwg-monitor/` nur zum Zählen: ob eine Zeile `Organisation:` vorhanden ist, die Kontextzeilen (Zeilen mit `- ` unter `## Kontext`) und die Triage-Einträge (Überschriften `### ` in `triage.md`). Die Lage des Projekts steht als Anzahl der Ebenen oberhalb des Arbeitsordners (`0` = im Arbeitsordner). Der Bericht enthält vom Projekt nur diese Werte, keine Pfade, keinen Namen der Organisation und keinen Inhalt einer Zeile. Die Diagnose legt kein Projekt an und ändert keines. Ohne Dateizugriff stehen die Werte auf `unknown`; im Modus `version` und im Ablauf-Modus ohne `technik` oder `voll` steht `project: not_run`.

### 7. Vor der Ausgabe

Suche für jedes `true` und `false` das Zitat im Kontext oder in der Ausgabe erneut, ebenso für Anbieter, Produkt, Oberfläche und Modell: Das Zitat muss den genannten Wert wörtlich enthalten (ein Modellname wie „GPT-5“ belegt keinen Anbieter). Nicht gefunden: auf `unknown` zurücksetzen und `downgraded: true` vermerken. Prüfe für das Projekt, dass `found` und jede Zählung aus einem gelesenen Dateiinhalt stammen; stützt sich `found` nur auf ein Suchmuster oder einen fehlgeschlagenen Lesevorgang, hole das Lesen nach. Der Beleg für `found` nennt den gelesenen Dateinamen `projekt.md`, ohne Pfad und ohne eine Zeile daraus. Prüfe, dass kein Wert allein aus einem Namen stammt und dass kein Geheimnis, kein Benutzername und keine Werkzeugliste in der Ausgabe steht (außer mit dem Zusatz `voll`).

## Ausgabe

Gib in dieser Reihenfolge aus:

1. **Kurzfassung** in höchstens acht Zeilen (mit Ablaufbericht zehn) für die Person: Umgebung, die wichtigsten Fähigkeiten, Zustand der Verbindung, Versionen, ob ein Projekt eingerichtet ist, offene Punkte und jede Herabstufung. Schreibe die Kurzfassung in einfachen Worten, ohne Feldnamen und Kennungen des Berichts (nicht `unknown`, `not_run`, `request_id`; sage „nicht feststellbar“, „nicht ausgeführt“) und ohne Verweis auf diese Anweisung („laut Diagnosevorgabe“).
2. **Bericht für den Support** in genau einem Codeblock (Format YAML), damit die Person ihn mit einem Griff kopieren kann. Im Modus `version` enthält er nur das gemeinsame Kurzprofil:

```yaml
diagnose: {version: 1, observed_at: "<UTC-Zeit oder unknown>", scope: version}
runtime:
  vendor: {value: ..., source: ..., evidence: "..."}
  product: {value: ..., source: ..., evidence: "..."}
  surface: {value: chat | work | claude | code | api | ide | unknown, source: ..., evidence: "..."}
  model: {value: ..., source: ..., evidence: "..."}
capabilities:
  agents.spawn: {value: true | false | unknown, source: ..., evidence: "..."}
  web.fetch: {value: true | false | unknown, source: ..., evidence: "..."}
versions: []                    # eine Zeile je Plugin, Skill, Connector und bereits geladenem Schritt wie in Schritt 5
mixed_state: true | false | unknown
unknowns: []
conflicts: []
```

Im Standard-Modus sowie mit `technik` oder `voll` gilt die vollständige Form:

```yaml
diagnose: {version: 1, observed_at: "<UTC-Zeit oder unknown>", scope: standard | voll | technik}
runtime:
  vendor: {value: ..., source: ..., evidence: "..."}
  product: {value: ..., source: ..., evidence: "..."}
  surface: {value: chat | work | claude | code | api | ide | unknown, source: ..., evidence: "..."}
  model: {value: ..., source: ..., evidence: "..."}
capabilities:
  agents.spawn: {value: true | false | unknown, source: ..., evidence: "..."}
  # jede Fähigkeit aus Schritt 1 und 3: code.execute, files.read, files.write, files.deliver, web.fetch, skills.load, mcp.connectors
environment: {os: "...", sandbox_markers: [...], binaries: {python3: true | false}, python_libraries: {docx: true | false}, source: probe | unknown}   # aus der Umgebungsprobe (nicht im Ablauf-Modus ohne `technik`), sonst unknown
delivery:
  loaded_as: {value: ..., evidence: "..."}
  package_files: [...]          # oder unknown
connection:
  tool_visible: {value: true | false | unknown, name: "...", evidence: "..."}
  auth: {value: signed_in | required | unknown, evidence: "..."}
  fetch: {value: ok | failed | not_run, at: "<UTC-Zeit oder unknown>", request_id: "<oder unknown>", evidence: "..."}
versions:                       # eine Zeile je Komponente, immer dieselben Felder
  - {component: plugin,        version: "...", build: unknown, source: "plugin.json"}
  - {component: "skill:<Name>", version: "...", build: "...",  source: "Frontmatter von skills/<Name>/SKILL.md"}   # eine Zeile je Skill im Paket, auch dieser
  - {component: diagnose-text, version: "...", build: "...",   source: "Stand dieses Textes | Instructions-Feld"}    # nur ohne Skill
  - {component: "connector:<Server>", version: "... | nicht feststellbar", source: ".mcp.json | Host", url: "<Adresse ohne Query>"}
  - {component: "step:report-intake", version: "...", build: "... | unknown", source: "Schrittantwort", platform: "... | keine", variant: "... | basis"}
mixed_state: true | false | unknown   # true, wenn geladene Schrittversionen voneinander abweichen
project:                        # aus Schritt 6
  found: {value: true | false | unknown, source: probe | unknown, evidence: "..."}
  levels_above: <Zahl> | none | unknown
  organisation_line: true | false | unknown
  kontext_lines: <Zahl> | unknown
  triage_entries: <Zahl> | unknown   # 0 ohne triage.md
unknowns: [...]
conflicts: []                   # widersprüchliche Belege innerhalb derselben Auslieferungsoberfläche; die Host-Manifeste behalten ihren jeweils vorgesehenen Transporttyp
raw: {tools: [...], env: "..."} # nur mit `voll`; steht im selben Block, damit er sich mit einem Griff kopieren lässt; bei mehr als 50 Werkzeugen nach Quelle gruppiert, nur Namen
```

3. **Senden:** Der Bericht geht per E-Mail an die Supportadresse (`references/support.md`, ohne Skill die Seite `/support`), Betreff: `Diagnose EmpCo-UWG Monitor – <Plugin-Version oder Stand dieses Textes> – <surface>`. Fordere die Person auf, den Bericht aus dem Kasten oben zu kopieren und zu senden, ohne eine Datei anzubieten. Sprich die Person dabei nie mit Fachbegriffen an (nicht „YAML“, „Block“, „Schlüssel“): Nenne ihn „den Bericht“ oder „den Kasten mit dem Bericht“.
4. **Weitere Modi (nur Standard-Modus):** Schließe mit einem kurzen Hinweis: `version` liefert nur Versionen und einfache Fähigkeitschecks, `technik` ergänzt technische Details zu einem vorhandenen Prüflauf, `voll` zusätzlich Werkzeugliste und lokale Umgebungsangaben.

## Definition of done

- [ ] Jeder Wert `true` oder `false` trägt `source` und ein wörtliches `evidence`; `unknown` steht überall, wo es keines gibt.
- [ ] Die Ausgabe enthält außer mit dem Zusatz `voll` keine Werkzeugliste, keinen Benutzernamen, keine Pfade und keine Umgebungsvariablen.
- [ ] `version` enthält nur das gemeinsame Kurzprofil; der Ablauf-Modus enthält dasselbe Profil plus Ablaufbericht.
- [ ] Die Verbindung ist im technischen Bericht mit Sichtbarkeit des Werkzeugs, Anmeldestatus und (im Standard-Modus) dem einen Abruf belegt; im Ablauf-Modus steht `fetch: not_run`.
- [ ] Plugin-Version, Skill-Stand und Regelstand stehen getrennt und mit Quelle; keine ist aus einer anderen abgeleitet.
- [ ] Direkte Aufrufe starten ohne Freigabefrage; ein automatischer Start stellt vor der ersten Handlung genau eine Frage mit „Bericht erstellen“ und „Abbrechen“, ohne Antwort wird nichts ausgeführt.
- [ ] Unteragent und Webzugriff sind mit je einem Check belegt oder `unknown`.
- [ ] Kurzfassung und genau ein Bericht liegen in einer Antwort vor; die Versionen stehen als eine Zeile je Komponente.
- [ ] Der Abruf trägt Uhrzeit (UTC) und `request_id`, soweit vorhanden, sonst `unknown`.
- [ ] Es wurde nichts installiert, nichts gesendet und kein Connector-Werkzeug außer dem freigegebenen Abruf aufgerufen.
- [ ] Das Projekt steht im technischen Bericht nur mit Fund, Ebenen und Zählungen, ohne Pfade, Namen oder Inhalte; die Diagnose hat nichts angelegt oder geändert.
- [ ] Der Standard-Modus endet mit dem Hinweis auf `version`, `technik` und `voll`.

## Ablaufbericht

Werte den letzten Lauf des EmpCo-UWG Monitors in diesem Gespräch aus und vergleiche ihn mit dem Soll der geladenen Schrittantworten. Der Bericht beschreibt nur Struktur: Schritt-Kennungen, Versionen, Werkzeugnamen, Status, Reihenfolge und Zählungen. Geprüfte Texte, Fundstellen, Bewertungen und Eingaben der Person gehören nie in den Bericht. Alles stammt aus dem Verlauf dieses Gesprächs; nichts wird an den Server gesendet, und es entsteht keine Datei: Die Person kopiert den Bericht aus der Antwort.

## Grenzen des Verlaufs

Fehlen frühe Teile des Gesprächs im Kontext (zum Beispiel nach einer Kürzung), benenne das und melde die betroffenen Punkte als `unknown`, statt sie zu rekonstruieren. Läuft die Prüfung noch oder ist sie abgebrochen, setze `status: incomplete` und nenne die Stelle, an der sie stand; verglichen wird nur, was im Verlauf belegt ist.

## 1. Schrittkette

Liste die geladenen Schritte in der Reihenfolge ihres Ladens mit Kennung, `version`, `build`, `platform`, `variant` und `request-id` (soweit vorhanden) aus dem Frontmatter der Antwort. Entnimm das Soll der Abschnitte „Übergabe“ der geladenen Antworten: welche Folgeschritte erlaubt waren und welcher tatsächlich folgte. Ein vorausgesetzter, aber nicht geladener Schritt ist ein Befund.

## 2. Friction

Halte jeden Bruch mit der Schritt-Kennung fest, in der er auftrat:

```
- [<Schritt>] <Art> – <eine Zeile>
```

Arten: Abruf fehlgeschlagen, Abruf wiederholt, Werkzeug oder Fähigkeit angefordert, aber nicht verfügbar oder fehlgeschlagen (etwa Unteragent, Websuche, Dateizugriff; jede Fehlermeldung eines Werkzeugaufrufs im Verlauf zählt), Schritt übersprungen, Antwort vor geladenem Folgeschritt, Schrittantwort unvollständig oder abgeschnitten, Rückfrage des Assistenten ohne Einfluss auf die Bewertung, Korrektur durch die Person. Nenne nur belegte Fälle; eine Reihung ohne Bruch ist kein Befund.

Ordne jeden Befund einer Ursachengruppe zu, die der Support zuerst prüft:

- **Host:** eine Fähigkeit fehlt oder verhält sich anders als vorausgesetzt.
- **Verbindung:** Werkzeug fehlt, Anmeldung verlangt, Abruf scheitert.
- **Regeln:** die geladene Anweisung war mehrdeutig oder widersprüchlich.
- **Eingabe:** Quelle unzugänglich, leer oder nicht prüfbar.

Widersprüche oder Mehrdeutigkeiten in den geladenen Anweisungen (etwa zwei Regeln, die Verschiedenes verlangen) gehören als Eintrag der Gruppe Regeln in die Friction-Liste, nicht nur in die Notiz eines Kriteriums; ein Kriterium, dessen Notiz einen Widerspruch nennt, ist `partial` oder `not_met`, nicht `met`.

Nicht zuordenbar: `unknown`.

## Verbindung und Host (kurzer Check)

Prüfe ohne Abruf, was der Verlauf und die Werkzeugliste belegen: ob `empco-uwg-monitor:fetch_claims_monitor_step` sichtbar ist (Werkzeugname des Hosts wörtlich) und ob die Anmeldung besteht (belegt durch erfolgreich geladene Schrittantworten, widerlegt durch eine Anmelde- oder Verbindungsmeldung im Verlauf, sonst `unknown`). Die Kurzfassung benennt das Ergebnis mit seinem Beleg. „Keine Befunde“ steht nur für Brüche im Verlauf, nie für eine nicht geprüfte Verbindung; ohne Beleg lautet die Angabe „nicht geprüft“. Wer mehr braucht (Fähigkeiten, Versionen, Abruf), ruft die Standarddiagnose auf. Innerhalb der Diagnose entfällt dieser Abschnitt, weil sie `connection` selbst belegt.

## Gemeinsames Kurzprofil

Der Bericht trägt immer dasselbe Kurzprofil wie der Modus `version`: Anbieter, Produkt, Oberfläche und Modell (nur soweit die Anweisungen es ausdrücklich sagen, sonst `unknown`), die Versionsliste aus Schritt 5 der Anweisung sowie die einfachen Checks für Unteragenten und Webzugriff aus Schritt 2. Jeder Wert nennt `source` und `evidence`. Das Kurzprofil führt keinen Regelabruf, keine Umgebungsprobe und keinen Verbindungs-Tiefencheck aus; bereits geladene Regelstände stammen aus dem Gespräch.

## 3. Vergleich mit dem Soll

Gehe die Kriterien der geladenen Antworten einzeln durch: die Voraussetzung einer Prüfantwort (Übergabe des zuletzt geladenen Schritts) und die Punkte des Abschnitts „Ausgabe vor Versand prüfen“ in der Antwort von `report-compose`. Markiere jedes Kriterium als erfüllt, nicht erfüllt, teilweise oder `unknown` mit einer Zeile Begründung, die auf Struktur verweist (etwa „Ausgabeabschnitt 2 ohne Quellenangabe“), nicht auf Inhalt. War `report-compose` nicht geladen, lautet der Befund „Ausgabeprüfung nicht möglich: Schritt nicht geladen“.

## Ausgabe

Gib in dieser Reihenfolge aus:

1. **Kurzfassung** in höchstens acht Zeilen für die Person: eine Zeile Eckdaten (Oberfläche, Plugin-Version), dann gruppiert nach Ursachengruppe mit dem ersten Schritt, den der Support prüfen sollte.
2. **Bericht für den Support** in genau einem Codeblock (Format YAML; innerhalb der Diagnose derselbe Block wie dort, mit diesen Schlüsseln auf oberster Ebene), den du der Person als „den Bericht“ nennst:

```yaml
ablauf: {version: 1, status: complete | incomplete, observed_at: "<UTC-Zeit oder unknown>"}
eckdaten:                       # gemeinsames Kurzprofil; innerhalb der Diagnose stehen dieselben Werte in `runtime`, `capabilities` und `versions`
  runtime: {vendor: ..., product: ..., surface: ..., model: ...}        # je {value, source, evidence}
  capabilities: {agents.spawn: ..., web.fetch: ...}                      # je {value, source, evidence}
  versions: []                 # eine Zeile je Plugin, Skill, Connector und bereits geladenem Schritt gemäß Schritt 5 der Diagnose
connection: {tool_visible: true | false | unknown, name: "...", auth: signed_in | required | unknown, evidence: "..."}   # nur eigenständig
steps:                          # in der Reihenfolge des Ladens
  - {step: report-intake, version: "...", build: "... | unknown", platform: "...", variant: "... | basis", request_id: "<oder unknown>", next_expected: [...], next_actual: "..."}
skipped: []                     # vorausgesetzte, aber nicht geladene Schritte
friction:
  - {step: "...", kind: "...", group: host | verbindung | regeln | eingabe | unknown, note: "..."}
gates:                          # je Kriterium
  - {criterion: "...", result: met | not_met | partial | unknown, note: "..."}
counts: {friction: {host: 0, verbindung: 0, regeln: 0, eingabe: 0, unknown: 0}, gates: {met: 0, not_met: 0, partial: 0, unknown: 0}}
```

3. **Senden** (nur bei eigenständigem Aufruf): wie bei der Standarddiagnose an die Supportadresse (`references/support.md`, ohne Skill die Seite `/support`), Betreff: `Ablaufbericht EmpCo-UWG Monitor – <Datum>`. Mit `request_id` und Uhrzeit findet der Support die Abrufe im Zugriffsprotokoll des Servers und vergleicht sie mit diesem Verlauf.

Empfiehl keine Änderungen an den Regeln; beschreibe nur, was im Verlauf geschah.

## Definition of done

- [ ] Das Kurzprofil entspricht dem Modus `version` und nennt Identität, Versionskomponenten sowie die Checks für Unteragenten und Webzugriff mit Beleg oder `unknown`.
- [ ] Die Schrittkette nennt jeden geladenen Schritt mit Kennung, Version und `request_id` (oder `unknown`) und benennt vorausgesetzte, aber nicht geladene Schritte.
- [ ] Jeder Friction-Eintrag nennt Schritt, Art und Ursachengruppe und beruht auf einem Beleg im Verlauf.
- [ ] Jedes Kriterium des Vergleichs trägt ein Ergebnis und eine strukturelle Begründung; nicht Belegbares ist `unknown`.
- [ ] Der Bericht enthält keinen geprüften Text, keine Fundstelle und keine Bewertung der Person.
- [ ] Fehlende frühe Teile des Verlaufs sind benannt; ein unvollständiger Lauf trägt `status: incomplete`.

## Umgebungsprobe

Skript `scripts/probe.sh`; mit Shell ausführen, sonst weglassen.

```bash
#!/usr/bin/env bash
# Umgebungsprobe des Diagnose-Skills: lesend, ohne Netzwerkzugriff.
# Standard: keine Benutzernamen, Pfade oder Umgebungsvariablen.
# Mit --roh zusätzlich Benutzer, Arbeitsverzeichnis und markierte Umgebungshinweise
# (nur auf Anfrage des Supports mit Freigabe der Person).
set -u
roh=0
[ "${1:-}" = "--roh" ] && roh=1

echo "## time"
date -u +%Y-%m-%dT%H:%M:%SZ 2>/dev/null || echo unknown

echo "## os"
uname -srm 2>/dev/null || echo unknown

echo "## path_markers"
for p in /mnt/data /mnt/user-data /mnt/user-data/uploads /mnt/user-data/outputs /mnt/skills /home/claude /home/sandbox /workspace; do
  [ -e "$p" ] && echo "present: $p"
done
for p in "${HOME:-/nonexistent}/.claude" "${HOME:-/nonexistent}/.codex"; do
  [ -e "$p" ] && echo "present: ~/${p##*/}"
done

echo "## binaries"
for b in python3 node pandoc libreoffice soffice git curl; do
  command -v "$b" >/dev/null 2>&1 && echo "$b: yes"
done

echo "## python_libs"
python3 - <<'PY' 2>/dev/null
import importlib.util as u
for m in ["docx", "openpyxl", "pptx", "jinja2", "reportlab", "pypdf"]:
    print(f"{m}: {'yes' if u.find_spec(m) else 'no'}")
PY

if [ "$roh" = 1 ]; then
  echo "## roh"
  echo "user=$(id -un 2>/dev/null) cwd=$(pwd)"
  env 2>/dev/null | grep -E '^(CLAUDE|CLAUDECODE|CODEX|OPENAI_|CHATGPT|TERM_PROGRAM|CI|GITHUB_ACTIONS)' |
    sed -E 's/((KEY|TOKEN|SECRET|PASSWORD|AUTH|COOKIE)[^=]*=).*/\1<redacted>/' | sed -E 's/(=.{60}).*/\1.../'
fi
```