> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # Findings und Issues > Verwandle Audit-Belege in zugewiesene, nachverfolgbare Behebungsaufgaben. Ein Finding ist die beleggestützte Aussage des Audits über einen Fehler. Ein Issue ist der dauerhaft bestehende Workflow, um darauf zu reagieren. ## Arbeit triagieren und zuweisen 1. Öffne **Analyze → Audits**, wähle einen abgeschlossenen Lauf und selektiere ein Finding, um dessen Analyse, Empfehlung, Sessions und Evidenzabfragen einzusehen. 2. Bestätige, weise zu, verwerfe, stumme, löse auf oder öffne das Finding erneut, nachdem du seine Belege geprüft hast. 3. Gehe zu **Analyze → Issues** und filtere den dauerhaften Eingang nach Status, Schweregrad oder Verantwortlichem. 4. Öffne das Issue, um es zuzuweisen, Kommentare oder Abonnenten hinzuzufügen und es nach verifizierter Behebung aufzulösen. Beginne mit der Finding-Zusammenfassung. Überprüfe, ob die Fehlerbeschreibung, die empfohlene Reaktion, der Schweregrad und die Einordnung mit den Sessions übereinstimmen, die du vom Audit erwartet hast. Ein Audit-Finding mit Schweregrad, Vorkommenszahl, Ursachenanalyse, empfohlener Maßnahme, Rankingfaktoren und Belegen. Öffne anschließend eine betroffene Session, anstatt allein auf Basis der Zusammenfassung zu entscheiden. Der verknüpfte Trace sollte das genaue Ereignis und den Payload zeigen, die das Finding unterstützen. Eine von einem Audit-Finding verknüpfte Session, geöffnet am relevanten Fehler mit seinen Ereignis-Metadaten und dem rohen Payload. Verwende nach der Überprüfung der Belege Issues, um der Reaktion einen Eigentümer zu geben und sie unabhängig von künftigen Audit-Läufen zu verfolgen. Der Issues-Eingang mit aktiven, bestätigten und aufgelösten Aufgaben inklusive Schweregrad und Eigentümerschaft. Öffne das Issue, um Untersuchungsnotizen zu erfassen, Abonnenten zu benachrichtigen und den Reaktionsverlauf festzuhalten. Löse es erst auf, nachdem die Behebung deployed und verifiziert wurde. Eine Issue-Detailansicht mit Quelle, Verstoßbelegen, Verantwortlichen, Abonnenten, Zeitverlauf und Kommentaren. ```bash theme={null} fp audits findings --audit checkout-reliability --status open fp audits finding fp audits ack --reason "owner assigned" fp audits assign --to engineer@example.com fp issues list fp issues show fp issues assign --assignee engineer@example.com fp issues comment-add --body "policy is in observe mode" fp issues resolve --yes ``` Verwende `fp issues subscribe `, `fp issues unsubscribe ` und `fp issues subscribers `, um Beobachter zu verwalten. Siehe die [Cloud-CLI-Audit- und Issue-Referenz](/de/reference/cloud-cli#audits) für Audit-Findings und [`fp issues`](/de/reference/cloud-cli#issues) für die Issue-Verwaltung. ## Ein Finding überprüfen Stelle sicher, dass es folgendes enthält: * Ein stabiles Fehlermuster, nicht nur einen einmaligen Titel * Schweregrad und betriebliche Auswirkung * Betroffene Session-IDs oder unterstützende Abfragen * Ausreichend Kontext, um das Verhalten zu reproduzieren * Eine vorgeschlagene Reaktion, die mit den Belegen übereinstimmt ## Ein Issue zur Verwaltung der Reaktion verwenden Erstelle oder verknüpfe ein Issue, wenn das Finding Zuweisung, Diskussion, Statusänderungen, Kommentare oder Abonnenten benötigt. Issues können auch Alert-Incidents und manuell gemeldete Probleme repräsentieren – deshalb sind sie unter „Audit-Reaktion" und nicht in der primären Navigation angesiedelt. Löse das Issue auf, wenn die Behebung deployed und verifiziert ist. Löse das Finding auf, wenn das Fehlermuster für die Audit-Population adressiert wurde. Diese Zeitpunkte können sich unterscheiden. ## Ein Issue in einen Policy-Entwurf umwandeln 1. Öffne das Issue und überprüfe sein Finding, die zitierten Sessions, die Ursache und die Empfehlung. 2. Wähle **generate policy** und überprüfe das Eignungsergebnis sowie den vorgeschlagenen Durchsetzungsintent. Ein **no policy**-Ergebnis bedeutet, dass das Verhalten stattdessen einen Alert, eine Workflow-Änderung oder eine menschliche Reaktion erfordern könnte. 3. Wähle **write this policy**, überprüfe und teste den generierten Quellcode dann im **Admin → policy editor**, bevor du **publish version** auswählst. Verwende **open the editor anyway**, wenn du dem Eignungscheck nicht zustimmst. 4. Gehe zu **Admin → enforcement**, deploye die Version im **observe**-Modus und überprüfe ihre Entscheidungen unter **Observe → policy**, bevor du sie durchsetzt. Der Issue-Titel, die Finding-Beschreibung, die Ursache, die Empfehlung und der Eignungsintent helfen beim Verfassen des Entwurfs. Es wird nichts automatisch veröffentlicht oder deployed. Verwende die CLI, um die Belege zu prüfen, bevor du das Issue im Dashboard öffnest: ```bash theme={null} fp issues show fp audits finding fp events --session-id --full --all ``` Policy-Eignung, Cloud-Veröffentlichung und Fleet-Deployment sind Dashboard-Workflows. Verwende `failproofai policies --install --custom `, wenn du den entsprechenden Policy-Quellcode zuerst lokal validieren möchtest. Wandle ein bestätigtes, wiederholbares Aktionsmuster in eine Policy-Version um.