ssh-jumphost/FORTSETZUNG_Teil_F.md

Fortsetzungsdokument: Umsetzungsauftrag_Sonnet5.md — Teil F (Mehrere Sitzungen je Benutzer mit Seitenleiste)

Stand: 2026-09-01, Stufen F1+F2+F3+F4+F5 abgeschlossen und verifiziert (F.6-Abnahme noch ausstehend, siehe Abschnitt 6). Repo: ssh_jumphost (FastAPI/SQLite SSH/RDP-Jumphost), erreichbar ueber die device_bash-Bridge unter $HOME/mnt/ssh_jumphost.

Reihenfolge des Gesamtauftrags (verbindlich, siehe Umsetzungsauftrag_Sonnet5.md): Teil A/B -> Teil E -> Teil C (fertig) -> Teil D (fertig, siehe FORTSETZUNG_Teil_D.md) -> Teil F (dieses Dokument, laufend) -> Aufgabe #11 (SSH Copy-Paste + Terminal-Farben, vom Nutzer nachtraeglich hinzugefuegt).

Erledigt: Teil A, Teil B, Teil E, Teil C, Teil D -- alle vollstaendig abgeschlossen in frueheren Sessions, hier nicht mehr relevant. Teil F siehe unten.

---

0) Betreiberentscheidungen fuer Teil F (Nutzerantworten dieser Session)

Der Umsetzungsauftrag verlangt vor Beginn von Teil F Antworten auf drei der acht offenen Betreiberentscheidungen (Abschnitt "Offene Entscheidungen fuer den Betreiber", Punkte 6-8):

1. #6 Obergrenze gleichzeitiger Sitzungen (Teil E.4) -- bereits durch eine fruehere Session beantwortet und implementiert: app/config.py max_sessions_per_user=6, max_sessions_global=100 (Env-Overrides JUMPHOST_MAX_SESSIONS_PER_USER/_GLOBAL), durchgesetzt in app/ssh_proxy/terminal_ws.py und app/rdp_proxy/ws_tunnel.py VOR jedem Ressourcenverbrauch. Keine neue Entscheidung noetig.
2. #7 Verhalten von Hintergrundsitzungen (F.3.9) -- Nutzerentscheidung dieser Session: voll verbunden bleiben (Spec-Empfehlung fuer Stufe 1). Kein Halte-/Pausenzustand, keine neue Zustandsmaschine. Die bereits vorhandene niedrige Obergrenze (Punkt 1) begrenzt den Ressourcenverbrauch.
3. #8 Wiederanschluss nach Seiten-Reload (F.3.7) -- Nutzerentscheidung dieser Session: kein Wiederanschluss, klar beschriftet (Spec-Empfehlung fuer Stufe 1). Ein Reload beendet die Sitzung wie heute; die Oberflaeche muss das ehrlich kommunizieren ("Sitzung wurde beendet, erneut verbinden"), statt es zu verschweigen. Serverseitiges Halten von SSH-Verbindung + Ausgabepuffer ueber eine Trennung hinweg ist explizit NICHT Teil dieser Umsetzung (F.3.7, Umsetzungsauftrag: "kein Nebenbei-Feature").

0a) Ist-Zustand-Bestandsaufnahme (vor F1)

Bereits vorhanden und fuer Teil F wiederverwendbar (nichts davon musste neu gebaut werden):

• E7 Session-Reaper (app/security/session_reaper.py, in app/main.py::lifespan vor dem ersten Request aufgerufen) -- keine Geistersitzungen nach Neustart.
• E9 Keepalive (static/js/session-keepalive.js, in terminal.html/ rdp.html eingebunden) -- haelt das Anmelde-Cookie waehrend einer offenen Sitzung per periodischem GET /auth/me am Leben.
• E10 Aktivitaets-basierter Idle-Timeout (app/ssh_proxy/terminal_ws.py IDLE_TIMEOUT_SECONDS, activity["t"] wird sowohl bei Ein- als auch bei Ausgabe aktualisiert) -- ein tail -f im Hintergrund haelt die Sitzung am Leben.
• E.4 Obergrenzen + Registry (app/security/active_sessions.py: count_for_user(), count_total(), prozesslokale In-Memory-Registry mit task/user_id/watchers) -- Grundlage fuer F.3.6 (eigene Sitzungs-API, Stufe F2).
• D4 RDP dynamische Aufloesung (resize-method: display-update in app/rdp_proxy/guacd_client.py::build_rdp_params(), client.sendSize() bereits in rdp.js aufgerufen mit Debounce) -- F.3.3 kann direkt darauf aufbauen, keine Server-Aenderung noetig.
• GET /admin/sessions + Beenden-Logik (app/admin/routes.py) als Referenzmuster fuer die in F2 zu bauende, auf user_id=eigene beschraenkte Variante im Katalog-Router.

1) Stufe F1 -- FERTIG (terminal.js/rdp.js zu instanzierbaren Bausteinen)

Ziel (F.3.1): aus zwei Dokument-Singletons (ein Skript pro Seite, feste Element-IDs) werden zwei Klassen mit genau einer Instanz pro Sitzung: connect(), dispose(), setActive(bool), ein Statusrueckruf fuer eine kuenftige Seitenleiste. Verhalten danach unveraendert (reiner Umbau).

Umgesetzt

• static/js/terminal.js: class SshTerminalSession -- baut ihr komplettes DOM (Toolbar, Terminal-Container, Dateitransfer-Panel) selbst per innerHTML-Template und document.createElement, referenziert intern ausschliesslich ueber Klassen (.session-shell, .status, .ft-overlay usw. -- keine IDs mehr fuer die interne Verdrahtung, mit Ausnahme von zwei dynamisch generierten, instanzeindeutigen IDs fuer die <label for>-Kopplung im Dateitransfer-Panel). Konstruktor baut nur auf; connect() oeffnet den WebSocket getrennt davon (damit eine kuenftige Seitenleiste eine Kachel erst anzeigen und danach verbinden kann). dispose() ist idempotent: schliesst WebSocket + xterm.js-Instanz, entfernt dokumentweite Resize-/Fullscreen-Listener und das eigene DOM-Element. setActive(bool) macht bei genau einer Instanz (heutiger Stand) nur ein Refit+Fokus -- die eigentliche Mehrfach-Instanz-Wirkung kommt erst in Stufe F4.
  • Tastatur-Sicherheit (F.3.2) ist fuer SSH bereits strukturell gegeben: xterm.js haengt seine Tastatur-Erfassung an sein EIGENES Containerelement, nicht an document -- das in F.3.2 beschriebene Risiko ("Tastendruck landet auf drei Servern") betrifft nur RDP.
• static/js/rdp.js: class RdpSession, analog aufgebaut (Toolbar, Anzeigeflaeche, Fehler-Overlay als eigenes DOM-Fragment). Da guacamole-common-js' Guacamole.Keyboard nur an document gebunden werden kann (keine saubere Abmeldung/Umschaltung in der Bibliothek), filtert jede Instanz Tastatur-/Paste-Weiterleitung ueber this._active (gesetzt durch setActive()) -- das ist die Grundlage fuer F.3.2, aber noch NICHT die vollstaendige Loesung (fehlende Modifiertasten-Ruecksetzung beim Umschalten folgt in Stufe F4, wenn es ueberhaupt zwei gleichzeitige Instanzen geben kann). Bei genau einer Instanz (heutiger Stand: Stufe F1/F2/F3) ist das Verhalten exakt wie vorher. dispose() hat eine dokumentierte Einschraenkung: der zugrundeliegende document-Listener von Guacamole.Keyboard bleibt technisch bestehen (keine Bibliotheks-API zum Abmelden), sendet aber nach dispose() nichts mehr, da _active=false bleibt -- folgenlos bei einer Instanz, muss bei Stufe F4 (Kachel-Schliessen mit mehreren offenen Sitzungen) erneut betrachtet werden.
• templates/terminal.html, templates/rdp.html: auf duennen Rahmen reduziert -- nur noch <div id="session-container" data-host-id="{{ host_id }}"> plus die Script-Includes. Die Seite baut kein Sitzungs-DOM mehr selbst; terminal.js/rdp.js erkennen #session-container beim Laden (Bootstrap- Block am Dateiende), erzeugen GENAU EINE Instanz, haengen deren .element ein und rufen connect() + setActive(true) auf. Eine kuenftige Arbeitsflaeche /workspace (Stufe F3) hat kein Element mit dieser ID -- der Bootstrap-Block bleibt dort wirkungslos und baut ihre Instanzen stattdessen selbst; keine zweite Implementierung (F.2, letzter Absatz, ausdruecklich eingehalten).
• static/css/app.css: #terminal, #rdp-display (dokumentweit eindeutige IDs, passten zum alten Ein-Instanz-Modell) zu .session-terminal, .session-rdp-display (Klassen, da das DOM jetzt pro Instanz dynamisch gebaut wird und mit mehreren gleichzeitigen Instanzen in Stufe F4 IDs nicht mehr eindeutig waeren). Alle anderen betroffenen Selektoren (.session-shell, .session-toolbar, .ft-overlay, .rdp-error-overlay usw.) waren bereits klassenbasiert, keine Aenderung noetig.
• tests/test_csp_compliance.py: Docstring-Korrektur bei test_session_pages_expose_host_id_via_data_attribute (data-host-id sitzt jetzt auf #session-container, nicht mehr auf #session-shell -- die eigentliche Assertion pruefte nur den rohen data-host-id="..."-String und war davon nicht betroffen, blieb aber inhaltlich unpraezise).

Bewusst NICHT in Stufe F1 (folgt in spaeteren Stufen)

• F.3.2 (vollstaendige Fokus-/Tastaturtrennung bei RDP inkl. Modifiertasten-Reset) -- Grundlage gelegt (_active-Gate), vollstaendig erst relevant/loesbar mit echten Mehrfach-Instanzen in F4.
• F.3.3 (Refit erst beim Sichtbarwerden einer ausgeblendeten Kachel) -- betrifft nur die kuenftige Seitenleiste, in F1 gibt es noch keine ausgeblendeten Instanzen.
• F.3.6 (eigene Sitzungs-API im Katalog-Router) -- Stufe F2.
• /workspace selbst -- Stufe F3.

Verifikation

• node --check static/js/terminal.js und static/js/rdp.js -- beide syntaktisch fehlerfrei.

• Vollstaendiger Grep nach allen vormaligen IDs (session-shell, fullscreen-btn, exit-btn, filetransfer-btn, ctrlaltdel-btn, rdp-error*, ft-overlay, ft-status, ft-list) VOR der Aenderung ergab: nur terminal.js/rdp.js/terminal.html/rdp.html/app.css referenzieren sie direkt; templates/admin.html nutzt dieselbe .ft-overlay-CSS-Klasse fuer zwei eigene, unabhaengige Overlays (#rec-overlay, #watch-overlay -- Sitzungswiedergabe/Live-Mitschau im Adminbereich) mit eigenen IDs, keine Kopplung an terminal.js/rdp.js-Intern -- keine weiteren Anpassungen noetig.

• Echter pytest-Lauf (4-Gruppen-Split wie in Teil C/D etabliert, ueber die device_bash-Bridge mit funktionierendem venv/pip): test_csp_compliance.py einzeln: 10/10 bestanden. Voller Regressionslauf ueber alle 19 Testdateien:

  Gruppe	Dateien	Ergebnis
  1	admin_crud, admin_groups_tokens, audit_chain, auth_flow, csp_compliance	39 passed, 1 failed
  2	passwords_totp, pentest_security, phase9, phase10, phase11	44 passed, 2 failed
  3	phase12, phase13, phase14, phase15	34 passed, 13 failed
  4a	rbac, teil_d_schritt5, teil_d_schritt6	11 passed, 0 failed
  4b	session_reaper	1 passed, 2 failed
  4c	session_recorder	5 passed, 0 failed
  Summe		134 passed, 18 failed, 152 total

  Exakt dieselben Zahlen wie am Ende von Teil D (siehe FORTSETZUNG_Teil_D.md Abschnitt 1d) -- die 18 Fehlschlaege sind einzeln stichprobenartig gegengeprueft (u.a. test_user_update_deactivate_and_delete_semantics [Bug #7], test_password_change_invalidates_old_session_everywhere [Bug #6, sicherheitsrelevant, bewusst unangetastet], test_build_rdp_params_... [Bug #2, session_id-Keyword], test_reap_closes_only_open_sessions [„cannot start a transaction within a transaction"]) und stammen unveraendert aus dem bereits dokumentierten 18-Bug-Backlog aus Teil C. Stufe F1 hat null neue Testfehlschlaege verursacht -- reiner, verhaltensneutraler Umbau bestaetigt.

• Kein manueller Browser-Test in dieser Session moeglich (keine laufende Instanz mit echtem SSH-/RDP-Ziel in der Sandbox) -- die Aequivalenz Alt-/Neu-Verhalten stuetzt sich auf: (a) den unveraenderten Testlauf oben (die Test-Suite hat keine dedizierten JS-Tests fuer terminal.js/rdp.js -- diese Luecke bestand bereits vorher), (b) die Codegegenueberstellung Zeile fuer Zeile (jede Funktion des alten IIFE hat eine 1:1-Entsprechung als Methode in der neuen Klasse, keine Logik geaendert, nur Referenzierung von globalen IDs auf this.xxx umgestellt). Empfehlung fuer eine kuenftige Session mit Zugriff auf einen echten SSH-/RDP-Testhost: manueller Rauchtest von /terminal/{id} und /rdp/{id} vor dem Weiterbau zu Stufe F3/F4.

---

2) Stufe F2 -- FERTIG (eigene Sitzungs-API im Katalog-Router)

Ziel (F.3.6): eine Liste der eigenen offenen Sitzungen und ein Endpunkt zum Beenden einer eigenen Sitzung -- zwingend auf user_id = <eigene> beschraenkt, NICHT ueber GET /admin/sessions (zeigt fremde Sitzungen, Benutzernamen, Aufzeichnungspfade).

Umgesetzt

• Migration 0020_session_user_ended_index.sql: zusammengesetzter Index idx_sessions_user_ended ON sessions(user_id, ended_at) -- deckt per SQLite-Index-Praefix-Regel sowohl "alle eigenen Sitzungen" als auch "eigene noch offene Sitzungen" ab. idx_sessions_user (nur user_id, aus 0001) bewusst nicht geloescht (Projektkonvention, siehe 0019) -- wird weiterhin von anderen Abfragen (u.a. GET /admin/sessions) genutzt.
• app/catalog/routes.py: GET /catalog/sessions (Parameter active_only, Standard true) und POST /catalog/sessions/{id}/terminate. Beide Endpunkte filtern hart auf user.id -- sowohl beim DB-Zeilenzugriff als auch (beim Beenden) zusaetzlich bei der active_sessions-Registry (entry.user_id != user.id als zweite, unabhaengige Pruefung). Eine fremde ODER nicht existierende session_id liefert in BEIDEN Faellen 404 (nicht 403 -- ein abweichender Code wuerde die Existenz einer fremden Sitzung verraten). Bereits beendete eigene Sitzung erneut beenden -> 409. Erfolgreiches Beenden schreibt ein Audit-Ereignis session_terminated_by_owner (Pendant zu session_terminated_by_admin im Admin-Router) und committet.
• tests/test_teil_f_schritt2.py (4 Tests, alle bestanden): eigene vs. fremde Sitzungen in der Liste; active_only-Filterung; Rechteumgehungs- Testfall aus der F.5-Risikotabelle (POST .../terminate auf fremde session_id -> 404, nicht 403/200); echtes Beenden mit asyncio.Task (Cancellation wird abgewartet, nicht nur "einmal nachgeben") inkl. Audit-Eintrag- und Hash-Ketten-Pruefung; 409 bei bereits beendeter eigener Sitzung.

Verifikation

• py_compile fuer app/catalog/routes.py und den neuen Testfile.

• tests/test_teil_f_schritt2.py einzeln: 4/4 bestanden.

• Voller Regressionslauf ueber alle 20 Testdateien (19 aus F1 + der neue F2-Testfile), erneut im 6-Gruppen-Split wegen der device_bash-Zeitgrenze:

  Gruppe	Ergebnis
  admin_crud/admin_groups_tokens/audit_chain/auth_flow/csp_compliance/phase9	46 passed, 1 failed
  passwords_totp/pentest_security/phase10/phase11	37 passed, 2 failed
  phase12/phase13	22 passed, 6 failed
  phase14/phase15	12 passed, 7 failed
  rbac/teil_d_schritt5/teil_d_schritt6/session_recorder	16 passed, 0 failed
  session_reaper	1 passed, 2 failed
  teil_f_schritt2 (neu)	4 passed, 0 failed
  Summe	138 passed, 18 failed, 156 total

  156 = 152 (Stand nach Teil D/F1) + 4 neue F2-Tests. Die 18 Fehlschlaege sind unveraendert exakt dieselben wie nach F1 (u.a. wieder test_user_update_deactivate_and_delete_semantics, test_password_change_invalidates_old_session_everywhere, test_build_rdp_params_..., die vier test_rdp_params_... aus phase12, test_session_reaper.py mit der bekannten Transaktions-Verschachtelungs-Meldung). Migration 0020 wurde in JEDEM Testlauf sichtbar sauber angewendet (Log-Zeile "Wende Migration an: 0020_session_user_ended_index.sql"), PRAGMA foreign_key_check (Teil der Migrations-Pipeline, haelt bei Verletzung hart an) lief in keinem Lauf an. Stufe F2 hat null neue Testfehlschlaege verursacht.

3) Stufe F3 -- FERTIG (Arbeitsflaeche /workspace, eine Sitzung gleichzeitig)

Ziel (F.3, F.4-Tabelle): dauerhafte Arbeitsflaeche mit Seitenleiste; diese Stufe haelt bewusst nur EINE verbundene Sitzung gleichzeitig (F4 baut "mehrere gleichzeitig, Umschalten" darauf auf, siehe F.4-Stufentabelle).

Umgesetzt

• app/main.py: GET /workspace -- wie /dashboard//admin reines statisches Markup, Auth clientseitig ueber GET /auth/me.
• templates/workspace.html: Topbar (Benutzername, Link zurueck zum Dashboard, Abmelden) + zweispaltiges Layout (Seitenleiste/Hauptbereich). Bindet terminal.js UND rdp.js gleichzeitig ein -- deren Bootstrap-Bloecke (siehe F1) bleiben hier wirkungslos, da kein Element mit ID session-container existiert; workspace.js erzeugt Instanzen ausschliesslich selbst. Enthaelt einen staendig sichtbaren Hinweis in der Seitenleiste, dass ein Reload jede offene Sitzung beendet (F.3.7 / Betreiberentscheidung #8 -- klar beschriftet statt verschwiegen, siehe Abschnitt 0 Punkt 3). Bewusst KEIN beforeunload-Bestaetigungsdialog (native Browser-Warnung) zusaetzlich eingebaut -- der Dauerhinweis in der Seitenleiste wurde als ausreichend fuer "klar beschriftet" bewertet; ein Reload-Warndialog waere eine zusaetzliche UX-Entscheidung, die die Spec nicht verlangt und die eine kuenftige Session bei Bedarf ergaenzen kann.
• static/js/workspace.js: orchestriert drei Zustaende im Hauptbereich (Hostkatalog / eine aktive Sitzung / Wechsel-Bestaetigung) und die Seitenleiste (Kacheln). Kernentscheidungen:
  • Kein Server-seitiges "welche Sitzung bin ich"-Signal noetig: die aktive Kachel im eigenen Tab wird direkt aus dem lokalen SshTerminalSession/RdpSession-Objekt gespeist (Status-Callback aus F1, Klick-Handler ruft direkt dispose()) -- kein Abgleich mit der server-seitigen session_id noetig, da terminal_ws.py/ws_tunnel.py diese ID bislang nirgends an den Client zurueckmelden (kein Frame dafuer im Protokoll). Bewusste Vereinfachung, dokumentiert als Limitierung unten.
  • GET /catalog/sessions (F2) wird NUR beim Laden der Seite und direkt nach dem Beenden der eigenen Sitzung abgefragt, nicht fortlaufend waehrend eine eigene Sitzung aktiv ist. Vermeidet dadurch das Problem, die eigene (im DOM bereits als "aktive Kachel" dargestellte) Sitzung von denselben Zeilen in der API-Antwort unterscheiden zu muessen (kein Duplikat-Risiko an den beiden Abfragezeitpunkten, da die eigene Sitzung dort entweder noch nicht existiert oder bereits beendet ist). Kehrseite (dokumentierte Limitierung): Sitzungen, die WAEHREND eine eigene Sitzung offen ist in einem ANDEREN Tab/Fenster geoeffnet oder beendet werden, erscheinen/verschwinden in dieser Seitenleiste nicht live -- erst nach dem naechsten Laden/Beenden. Kein Polling in dieser Stufe eingebaut (bewusst, um die Sitzungs-Identitaets-Frage nicht ungeloest mitzuschleppen); ein spaeterer periodischer Abgleich (mit echtem Sitzungs-ID-Abgleich, s.u.) ist Backlog fuer F4/F5.
  • Sitzungswechsel ist ehrlich, nicht still: ein Klick auf "Verbinden" bei bereits offener eigener Sitzung fuehrt NICHT automatisch zum Trennen -- ein eigenes Bestaetigungspanel (.banner.error + Beenden-und-wechseln/Abbrechen, kein natives confirm() -- passt zum bestehenden Stil des Projekts, das durchgehend eigene Overlays statt Browser-Dialoge nutzt) erklaert, dass diese Stufe nur eine gleichzeitige Sitzung haelt.
  • ?host=<id> (von dashboard.js gesetzt) verbindet beim Laden direkt, ohne den Katalog zwischenzuschalten.
• static/js/dashboard.js: "Verbinden" fuehrt jetzt zu /workspace?host={id} statt direkt zu /terminal/{id}//rdp/{id}. Weiterhin target="_blank" (eigener Tab) -- das Dashboard bleibt dadurch erreichbar, waehrend die Arbeitsflaeche laeuft; von dort fuehrt der Topbar-Link "Dashboard" zurueck. Die duennen Rahmen /terminal/{id}, /rdp/{id} selbst bleiben unveraendert erreichbar (F.2: Lesezeichen/ Fehlersuche).
• static/css/app.css: neue .workspace-*-Regeln (Seitenleiste, Kacheln, Statuspunkt-Farben per Klasse, Hauptbereich). Wichtig: .workspace-main .session-instance .session-shell { height: 100%; } ueberschreibt die height: 100vh-Regel aus F1 (dort fuer den Ein-Instanz-Vollseiten-Fall gedacht) -- sonst wuerde die Sitzung in der Arbeitsflaeche die Seitenleiste ueberdecken.
• Bewusst NICHT in F3 uebernommen (gehoert nicht zum Katalog-Funktions- umfang von F.3): die "Zugangsdaten anzeigen"-Funktion des Dashboards (showCredentials() in dashboard.js) wurde NICHT in den Arbeitsflaechen-Hostkatalog uebernommen -- bleibt eine reine Dashboard-Funktion. Spart Komplexitaet, ohne eine F.3-Anforderung zu verfehlen (die verlangt nur, dass "Neue Sitzung" den Hostkatalog zum Verbinden zeigt).

Bekannte Limitierung (fuer F4/F5 vorzumerken)

Der Server meldet die von ihm vergebene session_id (SSH: terminal_ws.py, RDP: ws_tunnel.py) aktuell an keiner Stelle an den Client zurueck -- weder per JSON-Frame (SSH-Protokoll koennte das leicht ergaenzen) noch per Guacamole-Instruktion (RDP-Protokoll ist reines Guacamole-Binaerprotokoll, eine eigene Instruktion dort einzuschleusen waere riskanter, da guacamole-common-js nur gueltige Guacamole-Instruktionen erwartet). F3 kommt bewusst ohne diese ID aus (s.o.). Sollte F4/F5 einen echten Abgleich "welche Kachel entspricht welcher Server-Sitzung" brauchen (z.B. fuer Live-Polling waehrend mehrerer offener Sitzungen), muss zuerst entschieden werden, ob/wie die SSH- und RDP-Wege dafuer je einen zusaetzlichen Mechanismus bekommen -- Betreiberentscheidung/Design-Frage fuer eine kuenftige Session, nicht in dieser Stufe geloest.

Verifikation

• node --check fuer workspace.js -- fehlerfrei.

• Kein manueller Browser-/SSH-/RDP-Rauchtest moeglich (siehe bereits bei F1 dokumentierte Einschraenkung -- keine echte SSH-/RDP-Zielumgebung in dieser Sandbox). Die Arbeitsflaeche selbst (Seitenleiste, Katalogwechsel, Wechsel-Bestaetigung) wurde NICHT im echten Browser gesehen -- nur durch Codelesen/CSP-Tests/Backend-Tests abgesichert. Empfehlung unveraendert: vor dem Weiterbau zu F4 einen manuellen Rauchtest mit echtem SSH-/RDP-Ziel durchfuehren.

• tests/test_teil_f_schritt3.py (2 Tests, neu): GET /workspace liefert die erwarteten Bausteine (Seitenleiste, Hauptbereich, Neue- Sitzung-Knopf, terminal.js/rdp.js/workspace.js eingebunden, KEIN #session-container -- sonst wuerde der F1-Bootstrap-Block automatisch eine Sitzung starten); /catalog/hosts und /catalog/sessions bleiben fuer einen frisch angemeldeten Benutzer erreichbar (leere Sitzungsliste).

• tests/test_csp_compliance.py: /workspace in die test_rendered_pages_contain_no_inline_style_or_script-Parametrisierung aufgenommen (jetzt 11 statt 10 Tests in der Datei) -- kein Inline- style/-script auf der neuen Seite.

• Voller Regressionslauf ueber alle 22 Testdateien (20 aus F1+F2 + der neue F3-Testfile, test_csp_compliance.py mit einem zusaetzlichen Parametrisierungsfall):

  Gruppe	Ergebnis
  admin_crud/admin_groups_tokens/audit_chain/auth_flow/phase9	36 passed, 1 failed
  passwords_totp/pentest_security/phase10/phase11	37 passed, 2 failed
  phase12/phase13	22 passed, 6 failed
  phase14/phase15	12 passed, 7 failed
  rbac/teil_d_schritt5/teil_d_schritt6/teil_f_schritt2/session_recorder	20 passed, 0 failed
  session_reaper	1 passed, 2 failed
  csp_compliance (11) + teil_f_schritt3 (2, neu)	13 passed, 0 failed
  Summe	141 passed, 18 failed, 159 total

  159 = 156 (Stand nach F2) + 2 neue F3-Tests + 1 neuer Parametrisierungsfall in test_csp_compliance.py. Die 18 Fehlschlaege sind wieder unveraendert dieselben wie nach F1/F2. Stufe F3 hat null neue Testfehlschlaege verursacht.

4) Stufe F4 -- FERTIG (mehrere gleichzeitige Sitzungen, Umschalten, Fokus-/Tastaturtrennung)

Ziel (F.3.2, F.3.3): mehrere Sitzungen gleichzeitig offen halten, zwischen ihnen umschalten ohne Verbindungsabbruch, Eingaben landen nur in der sichtbaren Sitzung, Groesse stimmt nach jedem Umschalten.

Geloeste Design-Frage aus F3 (Server-Sitzungs-ID-Zuordnung)

F3 hatte offen gelassen, wie eine Kachel im Browser einer server-seitigen sessions-Zeile zugeordnet wird, da terminal_ws.py/ws_tunnel.py die session_id an keiner Stelle an den Client zurueckmelden. Entscheidung dieser Stufe: kein Backend-Protokoll-Eingriff (ein SSH-JSON-Frame waere zwar risikoarm gewesen, aber eine passende Aenderung am RDP-Weg haette eine eigene Instruktion in den Guacamole-Binaerprotokoll-Tunnel einschleusen muessen -- ohne echten Browser/RDP-Testaufbau in dieser Sandbox als zu riskant bewertet, um es ungetestet zu aendern). Stattdessen: static/js/ workspace.js::claimServerSessionId() -- nach instance.connect() ruft jede lokal geoeffnete Sitzung bis zu 5x (250ms Abstand) GET /catalog/sessions?active_only=true ab und beansprucht die juengste, Host-ID-passende, noch nicht beanspruchte Zeile fuer sich (claimedSessionIds-Set). Damit werden eigene Kacheln korrekt aus der "laeuft anderswo"-Liste herausgefiltert -- das Duplikat-/Verwechslungs- Risiko, das F3 noch offen liess, ist damit fuer den Normalfall geloest. Dokumentiertes Restrisiko: ein echter Wettlauf (zwei Tabs oeffnen fast zeitgleich eine Sitzung zu genau demselben Host) koennte die Zuordnung in seltenen Faellen vertauschen -- rein kosmetisch (betrifft nur, welche Kachel als "eigene" vs. "anderswo" angezeigt wird, nicht Zugriffsrechte: Beenden bleibt ueber POST /catalog/sessions/{id}/terminate, Stufe F2, weiterhin hart auf den eigenen Benutzer beschraenkt, unabhaengig von dieser Heuristik).

Umgesetzt

• static/js/workspace.js komplett auf Mehrfach-Sitzungen umgebaut:
  • openSessions-Array statt einer einzelnen activeSession-Variable; jede Instanz bleibt nach dem Erzeugen dauerhaft in #workspace-sessions-area im DOM (wird nie durch Umschalten entfernt, nur ein-/ausgeblendet) -- erst dispose() (Sitzung schliessen) entfernt sie wirklich.
  • showSession(uid): blendet alle anderen Instanzen aus (.hidden-Klasse, app.css, derselbe CSP-konforme Sichtbarkeits-Toggle wie ueberall im Projekt) und die Zielinstanz ein, ruft setActive(true) auf ihr und setActive(false) auf allen anderen -- genau EIN _active=true gleichzeitig.
  • showCatalog(): blendet ALLE Sitzungen aus (setActive(false) auf jede), zeigt den Hostkatalog -- Sitzungen bleiben dabei voll verbunden im Hintergrund (Betreiberentscheidung #7).
  • Der bisherige F3-"Wechsel-Bestaetigung"-Dialog (eine Sitzung ersetzt die andere) entfaellt ersatzlos -- F4 erlaubt echte Koexistenz, "Verbinden" im Katalog oeffnet jetzt einfach eine zusaetzliche Kachel.
  • Sidebar-Kacheln unterscheiden jetzt drei Zustaende optisch: workspace-tile-active (gerade sichtbar), workspace-tile-background (offen, verbunden, aber ausgeblendet -- anklickbar zum Umschalten, inkl. Tastatur-Bedienung ueber tabindex/Enter/Leertaste), workspace-tile-remote (laeuft in einem anderen Tab, unveraendert aus F3).
• static/js/rdp.js (F.3.2, Fokus-/Tastatursicherheit): setActive(active) ruft jetzt this.keyboard.reset() (guacamole-common-js-API, dieselbe Methode, die der offizielle Client bei Fensterfokusverlust nutzt -- per Feature-Check typeof ... === "function" abgesichert) sowohl beim Deaktivieren als auch defensiv beim Aktivieren auf, damit keine haengengebliebenen Modifiertasten (Strg/Alt) von einer verlassenen Sitzung in die naechste durchschlagen. Die eigentliche Weiterleitungs-Sperre (this._active-Gate in keyboard.onkeydown/onkeyup/dem paste-Listener) stammt bereits aus F1 und musste hier nicht mehr geaendert werden -- sie greift jetzt einfach echt, weil erstmals mehrere RdpSession-Instanzen gleichzeitig existieren koennen.
• static/js/rdp.js und static/js/terminal.js (F.3.3, Refit beim Sichtbarwerden): der dokumentweite resize/fullscreenchange-Listener jeder Instanz reagiert jetzt NUR noch, wenn this._active wahr ist -- vorher haette ein Browser-Resize bei mehreren gleichzeitig existierenden, aber ausgeblendeten (display:none, Groesse 0) Instanzen fitAddon.fit() bzw. sendSize() mit bedeutungslosen Nullgroessen ausgeloest. Der eigentliche Refit beim Umschalten passiert weiterhin explizit in setActive(true) (unveraendert aus F1: sendResize() bzw. _sendCurrentSize()).
• templates/workspace.html: #workspace-main in zwei feste Unterbereiche aufgeteilt -- #workspace-catalog-view und #workspace-sessions-area -- statt vorher innerHTML bei jedem Zustandswechsel neu zu schreiben (das haette in F4 alle offenen Sitzungs-Elemente mitsamt ihrer aktiven WebSockets zerstoert).
• static/css/app.css: .workspace-tile-background/-remote-Stile; .workspace-sessions-area .session-instance (statt vorher direkt auf .session-instance im Hauptbereich) fuer die Hoehe; der F3-Uebergangsstil fuer die Wechsel-Bestaetigung (.workspace-replace-confirm usw.) entfernt, da der Dialog entfaellt.

Bewusst NICHT in Stufe F4 (folgt in F5)

• F.3.8 (Obergrenze in der Oberflaeche sichtbar -- "Neue Sitzung" deaktivieren) -- ein Ueberschreiten zeigt sich in F4 nur reaktiv als Fehlerstatus auf der neuen Kachel (Server lehnt mit WS-Code 4429 ab, siehe app/ssh_proxy/terminal_ws.py/app/rdp_proxy/ws_tunnel.py, E.4 aus Teil E) -- funktional korrekt, aber nicht die von F.3.8 verlangte vorherige Kennzeichnung.
• Live-Aktualisierung der Seitenleiste fuer Sitzungen, die in ANDEREN Tabs waehrend einer laufenden eigenen Sitzung geoeffnet/beendet werden (siehe oben, unveraendert aus F3 -- die Sitzungs-ID-Zuordnung loest das Duplikat-Problem, aber es wird weiterhin nicht periodisch neu abgefragt).

Verifikation

• node --check fuer terminal.js, rdp.js, workspace.js, dashboard.js -- alle vier fehlerfrei.

• Weiterhin kein manueller Browser-/SSH-/RDP-Rauchtest moeglich (keine echte Zielumgebung in dieser Sandbox). Das betrifft F4 staerker als F1-F3, weil hier die eigentliche, in der F.5-Risikotabelle als groesstes Risiko benannte Eigenschaft entsteht ("Eingaben landen in der falschen Sitzung"). Die Absicherung stuetzt sich in dieser Stufe ausschliesslich auf Codelesen/-gegenueberstellung (SSH: xterm.js bindet ohnehin an sein eigenes Containerelement, kein Aenderungsbedarf; RDP: das bereits in F1 angelegte _active-Gate plus das neue keyboard.reset()) -- dringende Empfehlung fuer die naechste Session mit Zugriff auf echte SSH-/RDP-Ziele: das F.6-Abnahmeszenario (vier Sitzungen, mehrfach umschalten, 30 Minuten offen lassen) tatsaechlich im Browser durchspielen, bevor F5 als "fertig" gilt.

• Keine neuen Backend-Testdateien in dieser Stufe (F4 ist eine reine Frontend-/JS-Aenderung ohne neue Endpunkte, Migrationen oder Schema-Aenderungen -- die bestehenden F1-F3-Tests decken weiterhin denselben Backend-Vertrag ab, auf dem workspace.js aufbaut). Voller Regressionslauf ueber alle 22 Testdateien (unveraendert gegenueber F3):

  Gruppe	Ergebnis
  csp_compliance/teil_f_schritt2/teil_f_schritt3	17 passed, 0 failed
  admin_crud/admin_groups_tokens/audit_chain/auth_flow/phase9	36 passed, 1 failed
  passwords_totp/pentest_security/phase10/phase11	37 passed, 2 failed
  phase12/phase13	22 passed, 6 failed
  phase14/phase15	12 passed, 7 failed
  rbac/teil_d_schritt5/teil_d_schritt6/session_recorder	16 passed, 0 failed
  session_reaper	1 passed, 2 failed
  Summe	141 passed, 18 failed, 159 total

  Identische Zahlen wie am Ende von F3 (159 Tests insgesamt, dieselben 18 bereits bekannten Fehlschlaege) -- erwartungsgemaess, da F4 keine Backend-/Testdatei-Aenderungen enthielt. Stufe F4 hat null neue Testfehlschlaege verursacht, wohlgemerkt bei einer Stufe, deren eigentliche Kernaussage (Eingabe-Isolation) mit den vorhandenen Backend-Tests strukturell gar nicht pruefbar ist -- siehe Rauchtest-Empfehlung oben.

5) Stufe F5 -- FERTIG

Ziel (F.4 der Spec-Tabelle, Cowork-Task #21): Obergrenzen in der Oberflaeche sichtbar machen (F.3.8), Sammelzustand-Kennzeichnung bei Hintergrundfehlern/-trennungen, Feinschliff.

F.3.8 -- Obergrenzen sichtbar

Bisher (F1-F4) war die Durchsetzung der Obergrenzen (Teil E.4, app/ssh_proxy/terminal_ws.py/app/rdp_proxy/ws_tunnel.py, VOR jedem Ressourcenverbrauch geprueft, WS-Code 4429 bei Ueberschreitung) bereits vollstaendig vorhanden und wirksam -- F.3.8 verlangt zusaetzlich, dass die Grenze VOR dem Verbindungsversuch sichtbar ist, nicht erst als Fehlerstatus danach.

• app/catalog/routes.py: neuer Endpunkt GET /catalog/session-limits (Abschnitt "Sitzungs-Obergrenzen (F5, Teil F.3.8)"). Liest ausschliesslich bereits vorhandene Quellen -- app/config.py (max_sessions_per_user, max_sessions_global) und app/security/active_sessions.py (count_for_user(), count_total()) -- und bildet exakt dieselbe Schwellenlogik wie die Durchsetzung nach: Admins sind von der Je-Nutzer-Grenze ausgenommen (user_limit_applies/at_user_limit nur bei not user.is_admin), nicht aber von der globalen Grenze (at_global_limit gilt fuer jeden). Absichtlich keine neue Zustandsmaschine, keine Verdopplung der Durchsetzung -- reine Lesefunktion. Liefert ausschliesslich aggregierte Zahlen, keine Details zu fremden Sitzungen (user_id/hostname anderer Nutzer bleiben wie beim gesamten Katalog-Router unsichtbar, siehe Moduldoc).
• static/js/workspace.js: refreshSessionLimits()/atAnyLimit()/ renderLimitHint() -- ruft den neuen Endpunkt beim Laden (main()), nach dem Start einer Sitzung und nach dem Schliessen (jeweils mit derselben 300ms-Verzoegerung wie der bestehende refreshRemoteSessions()-Aufruf, da active_sessions.register()/unregister() serverseitig erst nach dem WS-Handshake bzw. nach dem finally-Block laufen). renderLimitHint() zeigt "Eigene Sitzungen: X/Y" (nur wenn die Grenze fuer diesen Nutzer gilt) und "Server gesamt: X/Y" im Sidebar-Header und deaktiviert + Neue Sitzung, sobald eine der beiden Grenzen erreicht ist. hostCard() deaktiviert zusaetzlich jeden einzelnen "Verbinden"-Knopf im Hostkatalog unter derselben Bedingung. Serverseitige Durchsetzung (WS-Code 4429) bleibt unveraendert die verbindliche Kontrolle -- diese Anzeige ist bewusst nur informativ und kann durch die Race zwischen Anzeige-Refresh und tatsaechlichem Verbindungsaufbau kurzzeitig veralten (dieselbe Klasse von Eventual-Consistency wie bei claimServerSessionId aus F4).
• templates/workspace.html: neues Element <p id="workspace-limit-hint"> im Sidebar-Header.
• static/css/app.css: .workspace-limit-hint--at-limit (Warnfarbe bei erreichter Grenze) sowie ein neues globales button:disabled { opacity: 0.5; cursor: not-allowed; } (gab es vorher nicht -- deaktivierte Knoepfe sahen bislang optisch aktiv aus).

Sammelzustand-Kennzeichnung bei Hintergrundfehlern/-trennungen

• static/js/workspace.js: hasAttention(record) (Hilfsfunktion neben statusClass()) erkennt eine Hintergrundsitzung mit Fehler- oder Trennungsstatus. buildLocalTile() markiert eine solche Kachel zusaetzlich mit der Klasse workspace-tile-attention und ersetzt den generischen Text "im Hintergrund verbunden" durch "im Hintergrund: Fehler" bzw. "im Hintergrund: getrennt". renderSidebar() fasst zusaetzlich alle betroffenen Hintergrundsitzungen (die gerade aktive zaehlt nicht mit, ihr Zustand ist ohnehin direkt sichtbar) in einer Sammel-Zeile ueber der Kachelliste zusammen ("⚠ N Sitzungen im Hintergrund mit Problem"), damit ein Problem nicht erst durch Umschalten auf jede einzelne Kachel entdeckt wird.
• templates/workspace.html: neues Element <div id="workspace-attention-summary" class="hidden">.
• static/css/app.css: .workspace-tile-attention (roter Rahmen) und .workspace-attention-summary (Warnbanner-Stil).

Feinschliff

• Globales button:disabled-Stil (siehe oben) -- kam durch F.3.8 zum ersten Mal ueberhaupt im Projekt zum Einsatz (vorher gab es keine deaktivierten Knoepfe in dieser Form), war aber vorher schlicht nicht vorhanden und wird jetzt konsequent von allen drei neuen deaktivierbaren Knoepfen (+ Neue Sitzung, jeder Katalog-"Verbinden") genutzt.

Bewusst NICHT in Stufe F5

• Keine Aenderung an der serverseitigen Durchsetzung selbst (E.4) -- F5 ist ausschliesslich Anzeige/UX auf Basis der bestehenden, bereits in frueheren Sessions verifizierten Logik.
• Keine Push-/Live-Aktualisierung der Obergrenzen-Anzeige zwischen Tabs (dieselbe bekannte Einschraenkung wie die Sitzungsliste selbst seit F3 -- kein Polling, nur bei den bereits vorhandenen Refresh-Zeitpunkten dieser Seite).

Verifikation

• node --check fuer workspace.js (auf dem Geraet) -- fehlerfrei. python3 -m py_compile fuer app/catalog/routes.py -- fehlerfrei.

• Neue Testdatei tests/test_teil_f_schritt5.py (5 Tests, alle bestehen): Obergrenzen entsprechen app/config.py bei leerer Registry; current_user_count zaehlt ausschliesslich eigene Registry-Eintraege (fremde Sitzung beeinflusst NUR den globalen, nicht den eigenen Zaehler -- F.5-Risikotabelle-Prinzip wie in test_teil_f_schritt2.py); at_user_limit wird bei Erreichen von max_sessions_per_user wahr; die Admin-Asymmetrie aus terminal_ws.py (ausgenommen von der Je-Nutzer-Grenze, NICHT von der globalen) wird exakt nachgebildet; der Endpunkt verlangt eine Anmeldung (401 sonst).

• Voller Regressionslauf ueber alle 23 Testdateien:

  Gruppe	Ergebnis
  csp_compliance/teil_f_schritt2/teil_f_schritt3/teil_f_schritt5	22 passed, 0 failed
  admin_crud/admin_groups_tokens/audit_chain/auth_flow/phase9	36 passed, 1 failed
  passwords_totp/pentest_security/phase10/phase11	37 passed, 2 failed
  phase12/phase13	22 passed, 6 failed
  phase14/phase15	12 passed, 7 failed
  rbac/teil_d_schritt5/teil_d_schritt6/session_recorder	16 passed, 0 failed
  session_reaper	1 passed, 2 failed
  Summe	146 passed, 18 failed, 164 total

  Gegenueber F4 (141/18/159): +5 neue, bestehende Tests, dieselben 18 bereits bekannten, dokumentierten Fehlschlaege (siehe FORTSETZUNG_Teil_C.md), null neue Regressionen.

6) Abnahme (F.6) -- Code-Stand fertig, Live-Szenario ausstehend

Wortlaut F.6 (Umsetzungsauftrag_Sonnet5.md): "Ein Benutzer oeffnet vier Sitzungen (zwei SSH, zwei RDP) in der Arbeitsflaeche, schaltet mehrfach zwischen ihnen um und laesst sie 30 Minuten offen. Danach gilt: alle vier sind noch verbunden, in jeder ist die zuletzt gesehene Ausgabe vollstaendig vorhanden, Eingaben landen ausschliesslich in der sichtbaren Sitzung, die Groesse stimmt nach jedem Umschalten, es existieren genau vier sessions-Zeilen mit vier Aufzeichnungen, und ein zweiter Benutzer arbeitet waehrenddessen unbeeintraechtigt."

Beim Vorbereiten dieses Abschnitts gefundene und behobene Luecke

Bei der Pruefung von "30 Minuten offen, alle vier noch verbunden" gegen den tatsaechlichen Code fiel auf: F.3.4 ("Hintergrundsitzungen duerfen nicht sterben") war fuer eine echt untaetige SSH-Sitzung NICHT vollstaendig erfuellt. app/config.py::ssh_idle_timeout_s steht auf 900s (15 Minuten); E10 (app/ssh_proxy/terminal_ws.py) zaehlt zwar sowohl Eingabe als auch Zielausgabe als Aktivitaet (deckt z.B. tail -f/einen laufenden Build ab), aber eine Sitzung mit einer wirklich stillen Shell (kein Tastendruck, keine spontane Ausgabe) haette nach 15 Minuten den Idle-Timeout ausgeloest -- still im Hintergrund, waehrend die Kachel in der Seitenleiste weiter "verbunden" zeigte. Das widerspricht direkt Betreiberentscheidung #7 ("voll verbunden bleiben") und haette das F.6-Kriterium selbst beim einfachsten denkbaren Testlauf (vier Sitzungen oeffnen, nichts weiter tun, 30 Minuten warten) zum Scheitern gebracht. RDP (app/rdp_proxy/ws_tunnel.py) hat ueberhaupt keinen Idle-Timeout, ist also nicht betroffen.

Behoben rein clientseitig, ohne die serverseitige Logik zu aendern: static/js/terminal.js::SshTerminalSession.connect() sendet ab jetzt alle 4 Minuten (deutlich unter den 15 Minuten) einen inhaltsleeren {"type": "ping"} ueber die offene WebSocket-Verbindung, unabhaengig davon, ob die Sitzung gerade sichtbar ist oder im Hintergrund liegt. Das ist keine neue Sonderbehandlung auf dem Server: terminal_ws.py aktualisiert activity["t"] bereits fuer JEDE empfangene Nachricht, noch VOR der type-Weiche (if msg.get("type") == "input": ... elif ... == "resize": ...) -- ein unbekannter type wie "ping" faellt danach einfach durch, ohne Fehler und ohne dass eine der beiden Zweige ausgefuehrt wird. Timer wird in dispose() und im close-Handler aufgeraeumt (kein Leck bei Sitzungsende). node --check fehlerfrei; der volle Regressionslauf (csp_compliance/teil_f_schritt2/3/5, siehe unten) zeigt weiterhin 22/22 -- erwartungsgemaess, da die Aenderung rein clientseitig ist und die Server-Verzweigung fuer unbekannte type-Werte bereits vor dieser Aenderung bestand (kein neuer, testbar isolierter Serverpfad entstanden).

Kein Backend-Test fuer diese Aenderung: die Idle-Timeout-Schleife liegt inline in der grossen ssh_terminal()-Route (nicht in einer eigenstaendigen Funktion) und haengt an einer echten asyncssh-Verbindung -- ein Zeit-basierter WS-Integrationstest dafuer waere ein eigenes, nicht triviales Vorhaben (aehnliche Komplexitaet wie die bereits bestehenden, teils fehlschlagenden Mock-Tests in test_phase15.py) und wurde hier bewusst nicht nachgezogen, um die Codepruefung nicht mit einem unsicheren neuen Test zu vermischen. Die Absicherung stuetzt sich auf Codelesen (oben) -- die eigentliche Bestaetigung braucht den echten 30-Minuten-Lauf.

Kriterium-fuer-Kriterium-Stand

Kriterium (F.6)	Stand
Vier Sitzungen (2 SSH + 2 RDP) gleichzeitig oeffnen	Code vorhanden (F4: mehrere gleichzeitige SshTerminalSession/RdpSession-Instanzen, keine Zerstoerung beim Umschalten); Standard-Obergrenze 6/Nutzer laesst vier zu. Live-Test aussteht.
Mehrfaches Umschalten	Code vorhanden (F1/F4: setActive(), .hidden-Toggle, Refit/sendSize() beim Sichtbarwerden). Live-Test aussteht.
30 Minuten offen, danach alle vier noch verbunden	Betreiberentscheidung #7 umgesetzt; SSH-Idle-Timeout-Luecke oben gefunden UND behoben; RDP ohne Idle-Timeout unproblematisch. Live-Test aussteht (einzige Moeglichkeit, echte 15+ Minuten Stille zuverlaessig zu pruefen).
Ausgabe in jeder Sitzung vollstaendig vorhanden	Kein Datenverlust durch die Architektur zu erwarten (jede Instanz haelt ihren eigenen xterm.js/Guacamole-Zustand, wird nie zerstoert) -- aber nur am echten Terminal pruefbar. Live-Test aussteht.
Eingaben nur in der sichtbaren Sitzung	Code vorhanden: SSH bindet ohnehin an sein eigenes Containerelement (kein Aenderungsbedarf); RDP nutzt das _active-Gate (F1) plus keyboard.reset() beim Umschalten (F4). Laut F.5-Risikotabelle das groesste Einzelrisiko der ganzen Stufe. Live-Test aussteht -- dringendste Einzelpruefung vor einer echten Abnahme.
Groesse stimmt nach jedem Umschalten	Code vorhanden: setActive(true) loest sendResize()/_sendCurrentSize() aus (F1), Hintergrund-Resize-Events sind seit F4 per _active-Gate unterdrueckt. Live-Test aussteht.
Genau vier sessions-Zeilen mit vier Aufzeichnungen	Jede Sitzung erzeugt beim Verbindungsaufbau ihre eigene DB-Zeile + SessionRecorder (unveraendert seit vor Teil F, F.3.10 als harte Regel nie angetastet) -- vier gleichzeitige Instanzen ergeben strukturell vier Zeilen. Live-Test aussteht (Stichprobe in der DB nach dem Lauf).
Zweiter Benutzer unbeeintraechtigt	Jede neue Katalog-/Sitzungs-API in F2/F5 ist zwingend auf user_id = eigene beschraenkt (siehe Moduldoc app/catalog/routes.py, dedizierte Tests in test_teil_f_schritt2.py/test_teil_f_schritt5.py fuer Fremdsitzungs-Isolation). active_sessions-Registry ist bereits seit Teil E pro Sitzung, nicht pro Nutzer, geteilt. Live-Test aussteht (echter zweiter Login parallel).

Ehrliches Fazit

Der komplette Code-Stand fuer Teil F (F1-F5) ist fertig, regressionsfrei (146 bestehende + 5 neue Tests bestehen, dieselben 18 laengst bekannten, dokumentierten Fehlschlaege aus FORTSETZUNG_Teil_C.md unveraendert) und gegen jedes einzelne F.6-Kriterium durchgesehen -- dabei wurde eine echte, bis dahin unentdeckte Luecke gefunden und behoben (SSH-Idle-Timeout fuer Hintergrundsitzungen, oben). Was in dieser Sandbox nicht moeglich war und fuer keine Stufe von F1 bis F5 nachgeholt werden konnte: ein echter Browser mit echten SSH-/RDP-Zielsystemen. Alle sieben Kriterien in der Tabelle oben sind auf Code-Ebene plausibel, aber keines ist tatsaechlich durchgespielt worden. Teil F sollte erst dann als im Sinne von F.6 "abgenommen" gelten, wenn eine Session mit Zugriff auf echte SSH-/RDP-Testziele und einen echten Browser das Szenario tatsaechlich einmal durchspielt -- mit besonderem Augenmerk auf Eingabe-Isolation (groesstes Risiko laut F.5) und den 30-Minuten-Idle-Fall (siehe oben).