Hier ist ein konkreter E2E-Testplan für den aktuellen Stand der Extension in Chromium/Opera unter Linux.

Ziel des Testlaufs

Prüfen, ob die aktuelle Version bereits als zusammenhängendes System funktioniert:

• Extension lädt sauber
• Sidepanel öffnet
• Service Worker läuft
• Content Script hängt an der Zielseite
• State kann vom Sidepanel abgefragt werden
• Storage-/Advisor-/Timeline-/Executor-UI reagiert
• keine stillen Laufzeitfehler in Konsole oder Service Worker

1. Vorbereitungen

Im Repo:

cd ~/devel/chatbot-companion
npm run build
npm test

Erwartung:

• Build grün
• Tests grün

Dann prüfen, dass die wichtigen Dateien da sind:

ls -1 manifest.json sw.js sidepanel.html sidepanel.js content.js site-adapter.js

2. Extension als Unpacked laden

Chromium / Chrome

1. chrome://extensions öffnen
2. Developer mode aktivieren
3. Load unpacked
4. Repo-Ordner ~/devel/chatbot-companion auswählen

Opera

1. opera://extensions öffnen
2. Developer mode aktivieren
3. Load unpacked
4. Repo-Ordner ~/devel/chatbot-companion auswählen

Erwartung:

• Extension wird ohne Manifest-Fehler geladen
• keine rote Fehlermeldung direkt im Extension-Manager

3. Sidepanel-Verfügbarkeit prüfen

Im Extension-Manager prüfen:

• ist die Extension aktiviert?
• gibt es Fehlerhinweise bei Service Worker / Background Page?
• lässt sich das Sidepanel öffnen?

Dann Zielseite öffnen, auf der der Chatbot läuft.

Danach das Sidepanel der Extension öffnen.

Erwartung:

• sidepanel.html wird sichtbar
• UI rendert
• keine leere weiße Fläche
• Buttons und Statusfelder sind sichtbar

4. Zielseite + Content Script prüfen

Auf der Chatbot-Seite:

1. DevTools öffnen
2. Konsole prüfen
3. nach offensichtlichen Fehlern suchen

Besonders relevant:

• Fehler aus content.js
• Fehler aus site-adapter.js
• CSP-/Permission-/Message-Fehler

Erwartung:

• keine ungefangenen Exceptions direkt nach Seitenaufruf
• kein permanenter Fehler-Loop

5. Service Worker prüfen

Im Extension-Manager bei der Extension den Service Worker inspizieren.

Dort in der Konsole prüfen:

• startet sw.js sauber?
• fehlen importierte Module?
• gibt es Message-Handler-Fehler?
• gibt es Storage-Fehler?

Erwartung:

• keine Fehler wie:

  • missing import
  • undefined global
  • unknown message type bei normalem Laden
  • storage unavailable

6. Erstes State-Handshake testen

Mit geöffneter Zielseite und geöffnetem Sidepanel prüfen:

• werden Sessions angezeigt?
• kommen Metriken?
• erscheint Storage-Health?
• erscheinen Timeline / Event Log / Advisor?

Erwartung:

• Sidepanel bleibt nicht auf “leer”
• mindestens Default-/Initialzustand kommt zurück
• auch wenn noch keine echten Chatdaten gelesen werden, muss die UI stabil bleiben

Achte auf diese Bereiche:

• Version-Badge
• Storage health
• Storage integrity
• Storage schema
• Storage writes
• Storage tiering
• Storage offload GC
• Storage timeline
• Storage advisor
• Advisor executor

7. Negativtest: Adapter greift nicht richtig

Falls die Zielseite nicht korrekt erkannt wird, muss trotzdem Folgendes gelten:

• Sidepanel bleibt benutzbar
• keine komplette UI-Explosion
• Status zeigt eher “leer / none / not-run / no recommendation”
• nicht permanent Exceptions

Das ist wichtig, weil damit klar wird, ob das Grundsystem stabil ist, auch wenn der DOM-Adapter noch nicht perfekt sitzt.

8. Storage-Persistenz testen

Jetzt ein echter Reload-Test.

Ablauf

1. Zielseite öffnen
2. Sidepanel öffnen
3. ein paar Sekunden warten
4. Browser-Tab neu laden
5. Sidepanel erneut öffnen bzw. offen lassen
6. prüfen, ob Zustände wieder da sind

Erwartung:

• Schema-/Storage-/Event-Bereiche kommen wieder hoch
• nichts “vergisst” sofort alles
• kein Fehler durch Rehydration, Tiering, Offload-GC oder Advisor-State

Besonders prüfen:

• storageSchemaVersion
• storageMigrationLog
• storageEventLog
• storageAdvisorExecutionStatus

9. Timeline / Event Log testen

Es sollten inzwischen Events sichtbar sein, z. B. durch:

• Load-State
• Schema-Upgrade
• Writes
• evtl. Advisor-/Tiering-/Integrity-Status

Erwartung:

• Timeline zeigt Anzahl / letztes Event
• Event-Log zeigt mehrere Einträge
• kein kaputtes Rendering durch lange Texte oder fehlende Felder

10. Advisor nur lesen

Noch ohne Aktion:

Prüfen, ob im Sidepanel eine plausible Advisor-Zeile erscheint, z. B.:

• healthy / observe
• recommend-compaction
• expect-tiering
• reduce-write-pressure
• repair-missing-offload

Erwartung:

• Advisor ist nicht leer
• Preview-Aktionen werden angezeigt
• keine JS-Fehler beim Rendern

11. Safe Executor testen

Jetzt die beiden Buttons im Sidepanel prüfen:

• Run advisor safe actions
• Run advisor + compaction

Test A: Safe ohne Compaction

Button klicken.

Erwartung:

• kein UI-Absturz
• storageAdvisorExecutionStatus ändert sich
• Timeline/Event-Log bekommt neue Einträge
• wenn nichts auszuführen war: sauberer blocked/noop/executed-Status

Test B: Mit Compaction-Gate

Button klicken und Bestätigung akzeptieren.

Erwartung:

• nur dann Compaction, wenn Advisor wirklich dazu rät und eine Action verfügbar ist
• sonst sauber blockiert
• Status muss klar sagen, was blockiert wurde und warum

12. Cooldown / Idempotenz testen

Das ist wichtig für 002o.

Ablauf

1. Safe-Advisor einmal ausführen
2. direkt danach nochmal denselben Button klicken

Erwartung:

• dieselbe Aktion wird nicht stumpf nochmal ausgeführt

• Executor-Status zeigt eher:

  • decision_already_applied
  • oder cooldown_active

Das ist einer der wichtigsten praktischen Checks.

13. Compaction-/Rollback-Pfad testen

Nur wenn im UI aktuell Compaction-Kandidaten sichtbar sind.

Prüfen

• gibt es reclaimable Bereiche?
• lässt sich eine Compaction auslösen?
• erscheint Audit-Eintrag?
• erscheint Recovery/Rollback-Zustand?
• funktioniert Rollback sauber?

Erwartung:

• Compaction verändert den State kontrolliert
• Rollback bringt ihn kontrolliert zurück
• Event-Log zeigt beide Vorgänge

14. Was du parallel offen haben solltest

Praktisch am besten 3 Fenster gleichzeitig:

• Webseiten-DevTools-Konsole
• Service-Worker-Konsole
• Sidepanel

So siehst du sofort:

• DOM-/Adapterfehler
• Message-/Storagefehler
• UI-Fehler

15. Fehlerbilder sauber unterscheiden

A. Sidepanel leer, aber keine Fehler

Dann kommt vermutlich nur kein brauchbarer Capture-State vom Adapter.

B. Sidepanel mit Fehlern, Service Worker Fehlerfrei

Dann ist meist sidepanel.js oder Rendering kaputt.

C. Service Worker Fehler

Dann sitzt das Problem meist in:

• Imports
• Message-Handler
• Storage-State
• neuen Statusfeldern / Schemafeldern

D. Nur echte Zielseite kaputt, aber Fixture / Grundsystem okay

Dann ist fast sicher der site-adapter.js der Engpass.

16. Minimaler Abnahmepunkt für “praktisch testbar”

Ich würde die aktuelle Version als praktisch testbar ansehen, wenn diese 6 Punkte erfüllt sind:

1. Extension lädt ohne Fehler
2. Sidepanel öffnet stabil
3. GET_CAPTURE_STATE liefert stabil Antwort
4. Service Worker wirft keine Laufzeitfehler
5. Advisor/Timeline/Storage-Status rendern
6. Safe-Executor lässt sich klicken, ohne das System zu zerlegen

17. Sinnvolle Dokumentation während des Testlaufs

Für jeden Befund kurz notieren:

• Schritt
• Erwartet
• Ist
• Konsole-Fehler ja/nein
• Reproduzierbar ja/nein

Ein sehr praktisches Raster:

[PASS|FAIL] Schrittname
Expected:
Actual:
Console:
Notes:

18. Ehrliche Gesamteinschätzung

Ja, ein echter E2E-Test ist jetzt sinnvoll. Aber:

• Das Extension-/Storage-/Advisor-System ist deutlich weiter als die Gewissheit, dass der Adapter zur echten Chatbot-Seite schon perfekt sitzt.
• Der wahrscheinlichste Engpass im echten Feldtest ist nicht das Sidepanel, sondern das DOM-Auslesen der Zielseite.

Darum ist der beste erste Praxistest:

1. Extension laden
2. Sidepanel öffnen
3. echte Zielseite aufmachen
4. Service Worker + Seitenkonsole beobachten
5. prüfen, ob Daten wirklich aus der Seite kommen

Wenn du willst, schreibe ich dir als Nächstes einen ultrakompakten Test-Checkbogen zum Abhaken für Chromium/Opera, den du 1:1 während des Testlaufs verwenden kannst.