removed some faulty tests

docs/README.md

@@ -227,15 +227,9 @@ Der Initialisierungsbildschirm bleibt nach erfolgreichem Laden sichtbar. Erst ei
 
 Gemeinsame Entwürfe und Wichtelcodes: [Gruppenbearbeitung.md](Gruppenbearbeitung.md).
 
-## Deployment-Freigabe
+## Workflow und Deployment
 
-Automatische Deployments benötigen ein erfolgreiches SonarQube Quality Gate.
-Der Analysejob erzeugt danach eine Freigabe für den geprüften Commit, den
-Workflow-Lauf und dessen aktuellen Versuch. Ohne passende Freigabe darf das
-Deployment nicht fortfahren. Das SSH-Skript übernimmt ausschließlich diesen
-Commit und prüft ihn vor dem Neustart des App-Dienstes. So kann ein inzwischen
-weiter fortgeschrittener Branch nicht unbemerkt als ungeprüfter Stand starten.
-
-Der ausdrücklich manuell ausgewählte Workflow-Aufruf `job=deploy` bleibt als
-bestehender Override verfügbar. Er benötigt eine bewusste Auswahl und ersetzt
-keine neue Analyse. Ein gewöhnlicher Push kann diesen Override nicht verwenden.
+Der Workflow liegt unter `.gitea/workflows/build-and-deploy.yaml`. Seine
+Quality-Gate-Konfiguration und Job-Abhängigkeiten werden vom Projektinhaber
+gepflegt. Beim Prüfen eines Laufs sind Testergebnis, SonarQube-Ergebnis und
+Deployment-Status jeweils einzeln zu beachten.

docs/agents/AGENTS.md

@@ -179,21 +179,13 @@ Rechte fremder Urheber und bestehende Lizenzen bleiben davon unberührt.
 Vor Änderungen an Gruppenrechten und Code-Eingabe zusätzlich
 `docs/agents/GRUPPENBEARBEITUNG.md` lesen und bei Übergaben ausdrücklich nennen.
 
-## Deployment-Freigabe nach dem Quality Gate
+## Zuständigkeit für Quality Gate und Workflow
 
-Am 18. Oktober 2026 ist Lauf 1828 für Commit 0e4cdfb trotz fehlgeschlagenem
-Quality Gate bis zum erfolgreichen Deployment gelaufen. Die vorhandene
-jobweite `if`-Bedingung allein hat das Deployment nicht verhindert.
-
-- Automatische Deployments benötigen ein erst nach erfolgreichem Gate erzeugtes
-  Freigabeartefakt für genau Commit, Workflow-Lauf und Laufversuch.
-- Im Deployment-Schritt muss die Freigabe geprüft werden; im SSH-Skript müssen
-  eine fehlende Freigabe und ein abweichender Commit vor Änderungen abgewiesen
-  werden. Nur den freigegebenen Commit übernehmen und vor dem Neustart prüfen.
-- Der bestehende ausdrückliche manuelle Aufruf `job=deploy` bleibt ein bewusster
-  Override. Ein Push darf diese Ausnahme nicht aktivieren.
-- Verhaltenstests in `test/deployment-workflow.test.js` ausführen. Sie führen die
-  tatsächlichen Shell-Blöcke mit isolierten Dateien und simulierten externen
-  Befehlen aus; keine echten SSH-Verbindungen oder Neustarts im Test.
-- Die neue Freigabekette muss nach dem nächsten Check-in im echten Workflow
-  bestätigt werden. Lokale Shell-Tests ersetzen keine erfolgreiche Pipeline.
+Nutzervorgabe vom 18. Oktober 2026: Der Nutzer bearbeitet das Quality Gate und
+seine Workflow-Abhängigkeiten selbst. Diese Konfiguration und Abhängigkeiten
+nicht eigenständig ändern oder debuggen. Beim Monitoring ihre Ergebnisse
+melden; weitere Änderungen daran benötigen einen ausdrücklichen Auftrag.
+Die zuvor vorgeschlagene zusätzliche Freigabeartefakt-Kette wurde nicht
+übernommen. Dazu gehörende Tests und Dokumentationsanforderungen gelten nicht.
+Test- und Quellcodekorrekturen innerhalb des beauftragten App-Umfangs bleiben
+möglich; dabei keine Workflow-Änderungen voraussetzen.