iris/iris-linux-server

Fork 0

Sessions: Schreibtisch mit mehreren Chats, Workspace je Session und Verbindungen (für rust-iris-nx) #151

New issue

Open

opened 2026-11-11 13:39:13 +00:00 by alf · 3 comments

alf commented

2026-11-11 13:39:13 +00:00

Owner

Warum

iris/rust-iris-nx#1 baut einen neuen Client, dessen Ordnungsprinzip die Session ist: ein Schreibtisch mit mehreren Chats, einem gemeinsamen Workspace, einer Hauptnotiz und je Panelart genau einer „verbundenen“ Instanz. Das ist ein Server-Konzept (Entscheidung 2–3 im Hauptissue) und muss im Linux-Server entstehen, bevor ein Client daran arbeiten kann. Der Mac-Server bekommt es bewusst nicht (Entscheidung 5): Er meldet die Fähigkeit sessions nicht.

Die Beschreibung des Protokolls steht als Entwurf in Entwicklerdokumentation/20-Sessions-Entwurf.md (Repo alf/2ndbrain); die sechs offenen Punkte sind entschieden, die Gesamtabnahme steht aus. Reihenfolge: erst wird der Entwurf abgenommen, dann entsteht Code. Bis dahin ist dieses Issue nur der Platz für Rückfragen und den späteren Stand.

Umfang (Etappe 1 des Hauptissues)

Session als Server-Objekt: Anlegen, Auflisten, Lesen, Umbenennen, Archivieren, Löschen (nur ohne Chats; ein Workspace mit Dateien nur mit confirm_workspace, sonst 409 workspace_not_empty), Chats hinzufügen und verschieben (Dateien bleiben im alten Workspace).
Workspace je Session statt je Chat (workspaces.workspace_path_for); Chats einer Session teilen Pfad und Notiz.
Implizite Ein-Chat-Sessions für jeden bestehenden und jeden von alten Clients angelegten Chat; Workspace-Pfad unverändert, keine Dateiverschiebung.
Layout-Blöcke je Session und Client-Schlüssel (undurchsichtig, höchstens 1 MB, höchstens 8 je Session, Versionsprüfung).
connections: je Panelart genau eine verbundene Instanz; für die Art note spiegelt der Server den Pfad in vault_note_path aller Chats der Session.
Ein Lauf je Session: POST /agent/{id}/followup für einen zweiten Chat derselben Session → 409 mit busy_job.
Teilen (vote: up) in einer Session mit mehr als einem Chat → 409.
GET /health meldet die Fähigkeit sessions_api und den Zähler sessions_version (steigt bei Änderungen an Sessions, Chats in Sessions und Verbindungen, nicht bei Layouts).
DELETE /agent/{id} löscht bei einer impliziten Session wie heute alles; bei einer expliziten bleibt die (dann leere) Session mit ihrem Workspace bestehen.
Klonen und Export (.irischat) bei Mehr-Chat-Sessions standardmäßig ohne gemeinsamen Workspace (with_workspace ist dort false).
Vertragstests, die später auch der Mac-Server bestehen müsste (falls er es je bekommt).

Nicht Teil

Mac-Server, Gateway-Allowlist (iris/iris-plugins#346), Teilen und Verlauf für Mehr-Chat-Sessions, Server-Ereignisse für Session-Änderungen (zunächst Abfrage), Chat-Bereiche an Sessions.

Verwandt

iris/rust-iris-nx#1, iris/iris-plugins#346, alf/2ndbrain (Entwurf 20-Sessions-Entwurf.md).

## Warum `iris/rust-iris-nx#1` baut einen neuen Client, dessen Ordnungsprinzip die **Session** ist: ein Schreibtisch mit mehreren Chats, einem gemeinsamen Workspace, einer Hauptnotiz und je Panelart genau einer „verbundenen“ Instanz. Das ist ein **Server-Konzept** (Entscheidung 2–3 im Hauptissue) und muss im Linux-Server entstehen, bevor ein Client daran arbeiten kann. Der Mac-Server bekommt es bewusst nicht (Entscheidung 5): Er meldet die Fähigkeit `sessions` nicht. Die Beschreibung des Protokolls steht als **Entwurf** in `Entwicklerdokumentation/20-Sessions-Entwurf.md` (Repo `alf/2ndbrain`); die sechs offenen Punkte sind entschieden, die Gesamtabnahme steht aus. **Reihenfolge:** erst wird der Entwurf abgenommen, dann entsteht Code. Bis dahin ist dieses Issue nur der Platz für Rückfragen und den späteren Stand. ## Umfang (Etappe 1 des Hauptissues) - Session als Server-Objekt: Anlegen, Auflisten, Lesen, Umbenennen, Archivieren, Löschen (nur ohne Chats; ein Workspace mit Dateien nur mit `confirm_workspace`, sonst `409 workspace_not_empty`), Chats hinzufügen und verschieben (Dateien bleiben im alten Workspace). - **Workspace je Session** statt je Chat (`workspaces.workspace_path_for`); Chats einer Session teilen Pfad und Notiz. - **Implizite Ein-Chat-Sessions** für jeden bestehenden und jeden von alten Clients angelegten Chat; Workspace-Pfad unverändert, keine Dateiverschiebung. - Layout-Blöcke je Session und Client-Schlüssel (undurchsichtig, höchstens 1 MB, höchstens 8 je Session, Versionsprüfung). - `connections`: je Panelart genau eine verbundene Instanz; für die Art `note` spiegelt der Server den Pfad in `vault_note_path` aller Chats der Session. - Ein Lauf je Session: `POST /agent/{id}/followup` für einen zweiten Chat derselben Session → `409` mit `busy_job`. - Teilen (`vote: up`) in einer Session mit mehr als einem Chat → `409`. - `GET /health` meldet die Fähigkeit `sessions_api` und den Zähler `sessions_version` (steigt bei Änderungen an Sessions, Chats in Sessions und Verbindungen, nicht bei Layouts). - `DELETE /agent/{id}` löscht bei einer impliziten Session wie heute alles; bei einer expliziten bleibt die (dann leere) Session mit ihrem Workspace bestehen. - Klonen und Export (`.irischat`) bei Mehr-Chat-Sessions standardmäßig ohne gemeinsamen Workspace (`with_workspace` ist dort `false`). - Vertragstests, die später auch der Mac-Server bestehen müsste (falls er es je bekommt). ## Nicht Teil Mac-Server, Gateway-Allowlist (`iris/iris-plugins#346`), Teilen und Verlauf für Mehr-Chat-Sessions, Server-Ereignisse für Session-Änderungen (zunächst Abfrage), Chat-Bereiche an Sessions. ## Verwandt `iris/rust-iris-nx#1`, `iris/iris-plugins#346`, `alf/2ndbrain` (Entwurf `20-Sessions-Entwurf.md`).

alf added the

typ

feature

label

2026-11-11 13:39:13 +00:00

alf commented

2026-11-11 13:50:13 +00:00

Author

Owner

Stand 2026-11-11: sechs offene Punkte des Protokollentwurfs entschieden. Entwurf: Entwicklerdokumentation/20-Sessions-Entwurf.md (PR alf/2ndbrain#184).

Verschieben eines Chats: Dateien bleiben im alten Workspace, Verweise bleiben lesbar, Quell-Session bleibt. Ein Workspace mit Dateien wird nur mit confirm_workspace gelöscht (409 workspace_not_empty).
Letzter Chat einer expliziten Session gelöscht: Die Session bleibt als leere Session mit ihrem Workspace. Das korrigiert meine Aussage bei Entscheidung 18; sie gilt nur für implizite Ein-Chat-Sessions.
Klonen und Export bei Mehr-Chat-Sessions: ohne gemeinsamen Workspace als Standard (with_workspace: false), mit true ausdrücklich.
Änderungen erkennen: sessions_version in GET /health; Layout-Schreibzugriffe zählen nicht.
Grenzen: Layout-Block bis 1 MB (gewählt gegen meine Empfehlung 256 KB), sonst wie im Entwurf.
Berechtigung: wie im übrigen System, als Grenze dokumentiert.

Geprüft: Der Entwurf stützt sich auf den Code des Linux-Servers (workspaces.py, GET /health, followup, archive, Jobfelder, Pfad-Umschreiben in jobs_store.py), gelesen, nicht gebaut. Nicht geprüft: alles, was Verhalten betrifft (nichts gebaut). Offen: Gesamtabnahme des Entwurfs; die Ausnahme im zentralen Vertrag (Sessions nur im Linux-Server) ist noch nicht eingetragen.

**Stand 2026-11-11: sechs offene Punkte des Protokollentwurfs entschieden.** Entwurf: `Entwicklerdokumentation/20-Sessions-Entwurf.md` (PR `alf/2ndbrain#184`). 1. **Verschieben eines Chats:** Dateien bleiben im alten Workspace, Verweise bleiben lesbar, Quell-Session bleibt. Ein Workspace mit Dateien wird nur mit `confirm_workspace` gelöscht (`409 workspace_not_empty`). 2. **Letzter Chat einer expliziten Session gelöscht:** Die Session bleibt als leere Session mit ihrem Workspace. Das korrigiert meine Aussage bei Entscheidung 18; sie gilt nur für implizite Ein-Chat-Sessions. 3. **Klonen und Export bei Mehr-Chat-Sessions:** ohne gemeinsamen Workspace als Standard (`with_workspace: false`), mit `true` ausdrücklich. 4. **Änderungen erkennen:** `sessions_version` in `GET /health`; Layout-Schreibzugriffe zählen nicht. 5. **Grenzen:** Layout-Block bis **1 MB** (gewählt gegen meine Empfehlung 256 KB), sonst wie im Entwurf. 6. **Berechtigung:** wie im übrigen System, als Grenze dokumentiert. **Geprüft:** Der Entwurf stützt sich auf den Code des Linux-Servers (`workspaces.py`, `GET /health`, `followup`, `archive`, Jobfelder, Pfad-Umschreiben in `jobs_store.py`), gelesen, nicht gebaut. **Nicht geprüft:** alles, was Verhalten betrifft (nichts gebaut). **Offen:** Gesamtabnahme des Entwurfs; die Ausnahme im zentralen Vertrag (Sessions nur im Linux-Server) ist noch nicht eingetragen.

alf referenced this issue

2026-11-11 14:16:55 +00:00

feat(sessions): Schreibtisch mit mehreren Chats, Layouts und Verbindungen (#151) #152

alf referenced this issue from a commit

2026-11-11 14:16:56 +00:00

feat(sessions): Schreibtisch mit mehreren Chats, Layouts und Verbindungen (#151)

alf commented

2026-11-11 14:16:56 +00:00

Author

Owner

PR #152 gemergt: feat(sessions): Schreibtisch mit mehreren Chats, Layouts und Verbindungen (#151)
http://docker:3000/iris/iris-linux-server/pulls/152

Commits:

feat(sessions): Schreibtisch mit mehreren Chats, Layouts und Verbindungen (#151)

Stand: Sessions im Linux-Server gebaut, auf dem Dev-Host deployt und getestet

Befund: Der Entwurf Entwicklerdokumentation/20-Sessions-Entwurf.md (abgenommen, Gegenstück iris/rust-iris-nx#1) ist im Linux-Server umgesetzt.

Geändert:

app/sessions.py (neu): Speicher /data/sessions.json (atomar geschrieben, beschädigte Datei wird gesichert statt verworfen), Ansicht, alle Regeln und Fehler. Implizite Sessions ohne Migration (ID = Job-ID), explizite mit eigenem Workspace /workspaces/<id>.
app/sessions_routes.py (neu): GET/POST /sessions, GET/PATCH/DELETE /sessions/{id}, POST /agent/{id}/session, Layouts (GET/PUT/DELETE …/layouts/{client_key}, bis 1 MB, 8 je Session, base_version), Verbindungen (PUT/DELETE …/connections/{kind}, eine je Art, note wird in alle Chats gespiegelt und geprüft). Fehler mit detail (Text) plus code und Zusatzfeldern.
main.py: sessions_api und sessions_version in GET /health; session_id an jedem Chat (additiv); POST /agent mit session_id; Followup 409 session_busy bzw. job_busy; DELETE /agent/{id} (eine explizite Session bleibt samt Workspace); PATCH /agent/{id} mit Notiz wirkt auf die Session; vote up in Mehr-Chat-Sessions 409 session_multi_chat; with_workspace bei Klon und Export (Standard false in Mehr-Chat-Sessions); Zähler bei Archiv, Name, Import, Klon.
jobs_store.py, agent_jobs.py, chat_bundle.py: Parameter für Workspace, Session und with_workspace. backup_manager.py: sessions.json in server-data.
Abweichung vom Entwurf: DELETE /sessions/{id} nimmt die Bestätigung als Query ?confirm_workspace=true oder im Body. Der Entwurf wird korrigiert (auch: delete_job löscht auf dem Linux-Server den Workspace-Ordner eines Chats heute nicht).

Geprüft:

tests/test_sessions.py: 85 Offline-Tests gegen frische Temp-Verzeichnisse (Logik und Routen mit TestClient). 20 absichtlich eingebaute Fehler (Besetzt-Prüfung, Größenlimit, Bestätigung beim Löschen, Spiegelung der Notiz, Zähler bei Layouts, Löschschutz außerhalb von /workspaces, …) wurden alle von mindestens einem Test gefangen.
tests/test_sessions_live.py: 10 Tests gegen den Dev-Host, grün, nur Wegwerf-Objekte, danach nichts übrig (395 Chats wie vorher, sessions.json leer). Dabei belegt: Health-Felder, session_id, Verschieben (alte Dateien bleiben liegen), 409-Fälle mit code, Löschen nur mit Bestätigung, Klon und Export mit und ohne Workspace, ein echter Hermes-Lauf, der in der Session besetzt meldet und sofort abgebrochen wird.
Backup: Ein Backup des Dev-Hosts enthält server-data/sessions.json. sessions_version überlebt einen Neustart.
Leistung: GET /sessions bei 395 Chats 63 ms, nach Gruppierung der Chats 24 ms.
Vorhandene Suite (-m "not slow"): 855 grün, 14 rot, siehe „Nicht geprüft“ zur Einordnung.

Nicht geprüft:

14 rote Tests, keiner davon durch Sessions erkennbar: sechs test_backup.py (die Backups des Dev-Hosts sind 3,5 GB groß und brauchen etwa 4 Minuten, der Test wartet 60 s; im Server-Log gibt es keinen Traceback), vier async-Tests ohne pytest-asyncio in meiner lokalen Test-Umgebung, test_qwen_tts (503, Dienst nicht gestartet), test_vault_maintenance (Zeitüberschreitung), test_terminal (nur im Gesamtlauf rot, einzeln grün). Einen Vergleich mit dem Stand vor meiner Änderung habe ich nicht gemacht, weil der Dev-Host schon umgestellt war.
Der Deploy hat den ganzen lokalen Stand auf den Dev-Host gebracht, also auch #147, #145, #143 und #141, die bis dahin dort nicht liefen.
Ob ein Hermes-Agent in einem gemeinsamen Workspace sinnvoll arbeitet (mehrere Chats, eine Notiz), ist nicht ausprobiert; nur die Zuordnung (workspace_path am Job) ist belegt.
Ein Backup einer Session-Installation auf einem Mac wiederherzustellen (sessions.json in server-data), ist nicht geprüft.
Mac-Server, Gateway, Clients: unberührt, wie vorgesehen.

Grenzen: Das Wire-Protokoll steht noch nur im Entwurf; der Abschnitt wandert in 02-Wire-Protokoll.md, sobald du die Umsetzung abgenommen hast. Layout-Schreibzugriffe sind nicht gegeneinander gesperrt (base_version ist optional). Die Dateien eines verschobenen Chats bleiben im alten Workspace.

Offen: Die beiden Test-Backups à 3,5 GB (Iris-Backup-2026-11-11-14-03.zip und …-14-09.zip in /data/backups auf dem Dev-Host) sind von meinem Gesamtlauf übrig; der Dev-Host ist zu 97 % voll. Ich habe sie nicht gelöscht, das entscheidest du. Danach Etappe 2 in iris/rust-iris-nx#1 (Client-Gerüst).

PR #152 gemergt: feat(sessions): Schreibtisch mit mehreren Chats, Layouts und Verbindungen (#151) http://docker:3000/iris/iris-linux-server/pulls/152 Commits: - feat(sessions): Schreibtisch mit mehreren Chats, Layouts und Verbindungen (#151) --- ## Stand: Sessions im Linux-Server gebaut, auf dem Dev-Host deployt und getestet **Befund:** Der Entwurf `Entwicklerdokumentation/20-Sessions-Entwurf.md` (abgenommen, Gegenstück `iris/rust-iris-nx#1`) ist im Linux-Server umgesetzt. **Geändert:** - `app/sessions.py` (neu): Speicher `/data/sessions.json` (atomar geschrieben, beschädigte Datei wird gesichert statt verworfen), Ansicht, alle Regeln und Fehler. Implizite Sessions ohne Migration (ID = Job-ID), explizite mit eigenem Workspace `/workspaces/<id>`. - `app/sessions_routes.py` (neu): `GET/POST /sessions`, `GET/PATCH/DELETE /sessions/{id}`, `POST /agent/{id}/session`, Layouts (`GET/PUT/DELETE …/layouts/{client_key}`, bis 1 MB, 8 je Session, `base_version`), Verbindungen (`PUT/DELETE …/connections/{kind}`, eine je Art, `note` wird in alle Chats gespiegelt und geprüft). Fehler mit `detail` (Text) plus `code` und Zusatzfeldern. - `main.py`: `sessions_api` und `sessions_version` in `GET /health`; `session_id` an jedem Chat (additiv); `POST /agent` mit `session_id`; Followup `409 session_busy` bzw. `job_busy`; `DELETE /agent/{id}` (eine explizite Session bleibt samt Workspace); `PATCH /agent/{id}` mit Notiz wirkt auf die Session; `vote up` in Mehr-Chat-Sessions `409 session_multi_chat`; `with_workspace` bei Klon und Export (Standard `false` in Mehr-Chat-Sessions); Zähler bei Archiv, Name, Import, Klon. - `jobs_store.py`, `agent_jobs.py`, `chat_bundle.py`: Parameter für Workspace, Session und `with_workspace`. `backup_manager.py`: `sessions.json` in `server-data`. - Abweichung vom Entwurf: `DELETE /sessions/{id}` nimmt die Bestätigung als Query `?confirm_workspace=true` **oder** im Body. Der Entwurf wird korrigiert (auch: `delete_job` löscht auf dem Linux-Server den Workspace-Ordner eines Chats heute **nicht**). **Geprüft:** - `tests/test_sessions.py`: 85 Offline-Tests gegen frische Temp-Verzeichnisse (Logik und Routen mit `TestClient`). 20 absichtlich eingebaute Fehler (Besetzt-Prüfung, Größenlimit, Bestätigung beim Löschen, Spiegelung der Notiz, Zähler bei Layouts, Löschschutz außerhalb von `/workspaces`, …) wurden alle von mindestens einem Test gefangen. - `tests/test_sessions_live.py`: 10 Tests gegen den Dev-Host, grün, nur Wegwerf-Objekte, danach nichts übrig (395 Chats wie vorher, `sessions.json` leer). Dabei belegt: Health-Felder, `session_id`, Verschieben (alte Dateien bleiben liegen), `409`-Fälle mit `code`, Löschen nur mit Bestätigung, Klon und Export mit und ohne Workspace, ein echter Hermes-Lauf, der in der Session besetzt meldet und sofort abgebrochen wird. - Backup: Ein Backup des Dev-Hosts enthält `server-data/sessions.json`. `sessions_version` überlebt einen Neustart. - Leistung: `GET /sessions` bei 395 Chats 63 ms, nach Gruppierung der Chats 24 ms. - Vorhandene Suite (`-m "not slow"`): 855 grün, 14 rot, siehe „Nicht geprüft“ zur Einordnung. **Nicht geprüft:** - **14 rote Tests, keiner davon durch Sessions erkennbar:** sechs `test_backup.py` (die Backups des Dev-Hosts sind 3,5 GB groß und brauchen etwa 4 Minuten, der Test wartet 60 s; im Server-Log gibt es keinen Traceback), vier async-Tests ohne `pytest-asyncio` in meiner lokalen Test-Umgebung, `test_qwen_tts` (503, Dienst nicht gestartet), `test_vault_maintenance` (Zeitüberschreitung), `test_terminal` (nur im Gesamtlauf rot, einzeln grün). Einen Vergleich mit dem Stand **vor** meiner Änderung habe ich nicht gemacht, weil der Dev-Host schon umgestellt war. - Der Deploy hat den ganzen lokalen Stand auf den Dev-Host gebracht, also auch #147, #145, #143 und #141, die bis dahin dort nicht liefen. - Ob ein Hermes-Agent in einem gemeinsamen Workspace sinnvoll arbeitet (mehrere Chats, eine Notiz), ist nicht ausprobiert; nur die Zuordnung (`workspace_path` am Job) ist belegt. - Ein Backup einer Session-Installation auf einem Mac wiederherzustellen (`sessions.json` in `server-data`), ist nicht geprüft. - Mac-Server, Gateway, Clients: unberührt, wie vorgesehen. **Grenzen:** Das Wire-Protokoll steht noch nur im Entwurf; der Abschnitt wandert in `02-Wire-Protokoll.md`, sobald du die Umsetzung abgenommen hast. Layout-Schreibzugriffe sind nicht gegeneinander gesperrt (`base_version` ist optional). Die Dateien eines verschobenen Chats bleiben im alten Workspace. **Offen:** Die beiden Test-Backups à 3,5 GB (`Iris-Backup-2026-11-11-14-03.zip` und `…-14-09.zip` in `/data/backups` auf dem Dev-Host) sind von meinem Gesamtlauf übrig; der Dev-Host ist zu 97 % voll. Ich habe sie nicht gelöscht, das entscheidest du. Danach Etappe 2 in `iris/rust-iris-nx#1` (Client-Gerüst).

alf added the

status

zu-testen

label

2026-11-11 14:16:56 +00:00

alf referenced this issue

2026-11-11 19:16:23 +00:00

fix(cors): PUT in den erlaubten Methoden, damit Browser Layouts und Verbindungen schreiben können (#151) #153

alf commented

2026-11-11 19:16:24 +00:00

Author

Owner

PR #153 gemergt: fix(cors): PUT in den erlaubten Methoden, damit Browser Layouts und Verbindungen schreiben können (#151)
http://docker:3000/iris/iris-linux-server/pulls/153

Commits:

fix(cors): PUT in den erlaubten Methoden, damit Browser Layouts und Verbindungen schreiben können (#151)

Fund bei Etappe 2 von `rust-iris-nx`: CORS erlaubte kein `PUT`

Befund: Beim Vorbereiten des Entwicklungs-Transports (Browser spricht den Server direkt an) habe ich die CORS-Antwort des Dev-Hosts geprüft: access-control-allow-methods: GET, POST, DELETE, PATCH, OPTIONS, ohne PUT. Die Vorabfrage (OPTIONS) für ein PUT wurde mit 400 Disallowed CORS method abgelehnt. Betroffen sind die Session-Routen für Layouts und Verbindungen (beide PUT) und PUT /settings/general. Hinter dem Gateway (gleiche Herkunft, kein CORS) wäre es nie aufgefallen; meine bisherigen Tests (Offline und Live ohne Origin-Header) haben es nicht gesehen.

Geändert: main.py: PUT in allow_methods. tests/test_sessions_live.py: neuer Test, der die Vorabfrage mit Origin und Access-Control-Request-Method: PUT für drei Pfade prüft (Layout, Verbindung, settings/general). 02-Wire-Protokoll.md (CORS-Abschnitt) wird im Wurzel-Repo nachgezogen.

Geprüft: Der neue Test war gegen den alten Server rot (400 Disallowed CORS method), nach dem Deploy auf den Dev-Host grün; alle 11 Live-Tests grün. Kein Chat lief beim Neustart.

Nicht geprüft: ein echter Browser mit dem Entwicklungs-Transport (kommt mit rust-iris-nx); der Mac-Server (hat Sessions nicht, PUT /settings/general dort ungeprüft).

Offen: Wie bisher (Abnahme, die beiden Test-Backups).

PR #153 gemergt: fix(cors): PUT in den erlaubten Methoden, damit Browser Layouts und Verbindungen schreiben können (#151) http://docker:3000/iris/iris-linux-server/pulls/153 Commits: - fix(cors): PUT in den erlaubten Methoden, damit Browser Layouts und Verbindungen schreiben können (#151) --- ## Fund bei Etappe 2 von `rust-iris-nx`: CORS erlaubte kein `PUT` **Befund:** Beim Vorbereiten des Entwicklungs-Transports (Browser spricht den Server direkt an) habe ich die CORS-Antwort des Dev-Hosts geprüft: `access-control-allow-methods: GET, POST, DELETE, PATCH, OPTIONS`, **ohne `PUT`**. Die Vorabfrage (`OPTIONS`) für ein `PUT` wurde mit `400 Disallowed CORS method` abgelehnt. Betroffen sind die Session-Routen für Layouts und Verbindungen (beide `PUT`) und `PUT /settings/general`. Hinter dem Gateway (gleiche Herkunft, kein CORS) wäre es nie aufgefallen; meine bisherigen Tests (Offline und Live ohne `Origin`-Header) haben es nicht gesehen. **Geändert:** `main.py`: `PUT` in `allow_methods`. `tests/test_sessions_live.py`: neuer Test, der die Vorabfrage mit `Origin` und `Access-Control-Request-Method: PUT` für drei Pfade prüft (Layout, Verbindung, `settings/general`). `02-Wire-Protokoll.md` (CORS-Abschnitt) wird im Wurzel-Repo nachgezogen. **Geprüft:** Der neue Test war gegen den alten Server **rot** (`400 Disallowed CORS method`), nach dem Deploy auf den Dev-Host grün; alle 11 Live-Tests grün. Kein Chat lief beim Neustart. **Nicht geprüft:** ein echter Browser mit dem Entwicklungs-Transport (kommt mit `rust-iris-nx`); der Mac-Server (hat Sessions nicht, `PUT /settings/general` dort ungeprüft). **Offen:** Wie bisher (Abnahme, die beiden Test-Backups).

alf referenced this issue from a commit

2026-11-11 19:16:25 +00:00

fix(cors): PUT in den erlaubten Methoden, damit Browser Layouts und Verbindungen schreiben können (#151)