Ship the laptop journal backup via self-hosted Gitea.

USB and NAS are unavailable on this machine; the zip is the only path for personal SQLite and media. Provider keys stay out of git.

Co-authored-by: Cursor <cursoragent@cursor.com>

.gitignore

@@ -46,3 +46,8 @@ backend/data/
 local-backups/
 *.kansho-backup.zip
 *.db
+
+# One-time self-hosted Gitea transport of the laptop backup (2026-09-07).
+# Not a product datastore. Remove transfer/ after restore.
+!transfer/
+!transfer/*.zip

README.md

@@ -91,13 +91,14 @@ Restore bestätigt ausdrücklich, legt vorher ein Sicherheitsbackup an und über
 
 ## Transfer auf die Heim-Umgebung
 
-Persönliche Daten liegen **nicht** in Git. Vor einem Rechnerwechsel:
+Persönliche Daten liegen **nicht** beim Provider. Der einmalige Laptop-Transport (kein Stick/NAS auf diesem Gerät) läuft über das selbst gehostete Gitea:
 
-1. `.\scripts\backup-local.ps1 create` und das Zip plus `backend/.env` getrennt, verschlüsselt kopieren.
-2. Zu Hause klonen, `.\scripts\dev-setup.ps1`, Restore mit `-Confirm -Replace`.
-3. Docker/Postgres sind Welle 2, nicht der erste Restore.
+1. `git pull` muss `transfer/kansho-laptop-20260907.zip` enthalten.
+2. `.\scripts\dev-setup.ps1`, `backend/.env` aus der Example plus Keys.
+3. Restore: `.\scripts\backup-local.ps1 restore -Archive .\transfer\kansho-laptop-20260907.zip -Confirm -Replace`
+4. Docker/Postgres sind Welle 2, nicht der erste Restore.
 
-Details und Checklisten: `docs/architecture/technical/environment_handover.md`, `docs/work_orders/laptop_closeout.md`, `docs/work_orders/home_environment_setup.md`.
+Details: `docs/architecture/technical/environment_handover.md`, `transfer/README.md`.
 
 ## Lokal weiterarbeiten
 

docs/architecture/technical/environment_handover.md

@@ -53,7 +53,7 @@ Nicht tun: Urlaubs-SQLite in ein noch nicht existierendes Postgres-Schema laden,
 |---|---|
 | Branch | `main` |
 | HEAD | `main` auf dem Laptop, nach `e42f751 MVP 1.0`: Opening-Fix `ec0f8ba`, danach Transfer-Doku |
-| Remote | Push nach Gitea ist die letzte Laptop-Pflicht; ohne Push sieht der Heim-Clone nur `MVP 1.0` |
+| Remote | `origin/main` trägt Opening-Fix und Transfer-Doku (`326a9a4`). Persönliche Daten reisen extra über `transfer/` (siehe §2.5). |
 | `develop` | existiert **nicht** (Familienmuster Dev=`develop` / Prod=`main` ist entschieden, aber noch nicht angelegt) |
 
 Committet auf dem Laptop (2026-09-07):
@@ -75,11 +75,19 @@ Das ist **Klasse-A/B-Material**. Es darf nicht nach Gitea, nicht an Provider, ni
 
 ### 2.4 Backup dieser Session
 
-Erzeugt: `local-backups/kansho-20260907-055703.zip` (gitignoriert).
+Lokale Kopien unter `local-backups/` (gitignoriert). Führendes Transportarchiv: `transfer/kansho-laptop-20260907.zip` (erzeugt 2026-09-07 07:02 UTC, SQLite war neuer als das Morgen-Backup).
 
 Enthält SQLite (Backup-API) + 70 Mediendateien + Manifest/Checksummen. Enthält **keine** `.env` und keine Keys. Das Archiv ist **unverschlüsselt** und persönlich.
 
-Vor dem Abschalten des Laptops: Archiv auf verschlüsselten USB-Stick, NAS-Share oder den Heimrechner kopieren. Zweite Kopie getrennt halten. Nicht committen.
+### 2.5 Transportweg Gitea (entschieden 2026-09-07)
+
+Auf diesem Laptop dürfen weder USB-Stick noch NAS verbunden werden. **Entschieden:** Datenbank und persönliche Journaldaten laufen über das selbst gehostete Gitea, weil es nur in der eigenen Infrastruktur existiert. Das ist kein Freibrief für öffentliche Remotes und kein Egress an Provider.
+
+- Code und Doku: Branch `main`
+- Persönliche Daten: `transfer/kansho-laptop-20260907.zip` auf `main`
+- Secrets: `backend/.env` **nicht** in Git. Auf dem Ziel `backend/.env.example` kopieren und Keys neu eintragen.
+
+Nach Restore `transfer/` aus dem Tree nehmen. Die Git-Historie behält das Zip.
 
 ---
 
@@ -89,8 +97,8 @@ Siehe Arbeitsauftrag `../../work_orders/laptop_closeout.md`.
 
 Kurz:
 
-1. Opening-Fix (`ec0f8ba`) und Transfer-Doku (`29e3d0f`) nach Gitea pushen, falls `origin/main` noch hinterherhinkt.
-2. Backup-Archiv und `.env` **getrennt** physisch mitnehmen.
+1. Opening-Fix und Transfer-Doku sind auf `origin/main` (`326a9a4`).
+2. Persönliches Backup über `transfer/` nach Gitea, nicht per Stick/NAS.
 3. Backend beenden, keine weiteren Dialoge mehr als „führende Instanz“ führen, sobald Welle 1 zu Hause bestätigt ist.
 4. Slice-2-Konzept, Debug-Export und Memory-Slice **nicht** auf dem Laptop zu Ende bauen.
 
@@ -121,7 +129,7 @@ Auftrag: `../../work_orders/home_environment_setup.md` Phase A.
 2. `.\scripts\dev-setup.ps1` (Windows) bzw. venv + `npm install`.
 3. `backend/.env` aus der **separaten** Secret-Kopie anlegen, nicht aus dem Backup.
 4. Backend **nicht** mit Produktionsdaten starten, bevor das Restore-Ziel leer oder bewusst überschrieben wird.
-5. Restore: `.\scripts\backup-local.ps1 restore -Archive <pfad>\kansho-20260907-055703.zip -Confirm -Replace`.
+5. Restore: `.\scripts\backup-local.ps1 restore -Archive .\transfer\kansho-laptop-20260907.zip -Confirm -Replace`.
 6. Start: Backend 8018, Frontend 5188. Login mit dem bestehenden Admin-Konto (Passwort-Hash steckt in der SQLite, nicht in `.env`).
 7. Smoke: Space `Kroatien 2026` sichtbar, Journal Days vorhanden, ein Entry mit Medien, ein Dialogzug fail-closed ohne Key und mit Key über Gateway, Health `GET /api/health`.
 8. `.\scripts\test-mvp.ps1` (isolierte Temp-DB, ändert die Restoredaten nicht).

docs/architecture/technical/runtime_and_deploy.md

@@ -109,13 +109,15 @@ Kein Ersatz für Produktions-Backup, Docker oder Verschlüsselung.
 
 ### 7.2 Transfer Laptop → Heim-Entwicklung und Server (2026-09-07)
 
-Die Urlaubsinstanz lief ohne Docker auf SQLite (`backend/data/kansho.sqlite`, Ports 5188/8018). Persönliche Dialog- und Journaldaten liegen nicht in Gitea.
+Die Urlaubsinstanz lief ohne Docker auf SQLite (`backend/data/kansho.sqlite`, Ports 5188/8018).
 
 **Reihenfolge entschieden:** zuerst Kontinuität (Clone + SQLite-Restore + Smoke), danach Betriebsrahmen (Compose, Postgres 16, Gitea-Runner). Postgres bleibt Ziel; `backend/db.py` ist weiterhin SQLite. Ein direkter Sprung „Laptop-SQLite nach Prod-Postgres“ ohne Zwischen-Restore ist verworfen.
 
-Kanonisches Session-Handover: `environment_handover.md`. Aufträge: `../../work_orders/laptop_closeout.md`, `../../work_orders/home_environment_setup.md`.
+**Additiv 2026-09-07 (Transportweg):** Auf dem Urlaubs-Laptop dürfen weder USB-Stick noch NAS verbunden werden. Der einzige Weg für Datenbank und persönliche Journaldaten ist das **selbst gehostete** Gitea (`gitea.stommer.de`, nur eigene Infrastruktur). Das ist eine einmalige Transportentscheidung, kein Produktregelwechsel: Provider, OpenRouter und öffentliche Remotes bleiben ausgeschlossen. Provider-Keys und `backend/.env` bleiben **außerhalb** Git.
 
-Laptop-Backup dieser Session: `local-backups/kansho-20260907-055703.zip` (nur lokal, gitignoriert). `.env` reist getrennt.
+Aktuelles Transportartefakt: `transfer/kansho-laptop-20260907.zip` (SHA256 `EBF7455D5688588E8C6E50C05D16200CE191D79FB7CEACDBA9C25460B7497B07`). Nach erfolgreichem Restore auf dem Zielrechner das Verzeichnis `transfer/` aus dem Arbeitsbaum entfernen.
+
+Kanonisches Session-Handover: `environment_handover.md`. Aufträge: `../../work_orders/laptop_closeout.md`, `../../work_orders/home_environment_setup.md`.
 
 Noch nicht im Repository: Dockerfiles, Compose, `.gitea/workflows/`, Postgres-Adapter. Mitai unter `C:\dev\mitai` bleibt Muster, nicht Quelle für Ports oder `bodytrack/`-Pfade.
 

docs/work_orders/home_environment_setup.md

@@ -8,7 +8,7 @@ canonical_handover: "docs/architecture/technical/environment_handover.md"
 
 # Arbeitsauftrag: Heim-Entwicklungsumgebung, Server und Datenübernahme
 
-Arbeite **nicht** auf der Urlaubs-SQLite als führende Instanz. Voraussetzung: `laptop_closeout.md` ist erfüllt (Gitea aktuell, Backup und `.env` liegen vor).
+Arbeite **nicht** auf der Urlaubs-SQLite als führende Instanz. Voraussetzung: `laptop_closeout.md` ist erfüllt (`origin/main` inkl. `transfer/`-Zip). USB/NAS sind auf dem Laptop nicht der Weg.
 
 Lies zuerst:
 
@@ -46,11 +46,11 @@ Ziel: Dieselbe Anwendung wie auf dem Laptop, mit den Urlaubsdaten, auf dem Heimr
 1. `git clone https://gitea.stommer.de/Lars/Kansho.git` (Windows-Pfadempfehlung `C:\dev\Kansho`, wenn frei).
 2. `git log -1` muss den Opening-Fix und die Transfer-Doku enthalten. Fehlt das, zuerst Laptop-Push nachholen.
 3. `.\scripts\dev-setup.ps1`
-4. `backend/.env` aus der Secret-Kopie. Nicht aus dem Backup-Zip.
-5. Backend aus, dann Restore:
+4. `backend/.env` neu aus `backend/.env.example` plus Provider-Keys (Passwortmanager / OpenRouter). Keys sind **nicht** im Zip und nicht in Git.
+5. Backend aus, dann Restore aus dem geklonten Tree:
 
 ```powershell
-.\scripts\backup-local.ps1 restore -Archive <pfad>\kansho-20260907-055703.zip -Confirm -Replace
+.\scripts\backup-local.ps1 restore -Archive .\transfer\kansho-laptop-20260907.zip -Confirm -Replace
 ```
 
 6. Start: Backend `--port 8018`, Frontend `npm run dev` (5188).

docs/work_orders/laptop_closeout.md

@@ -51,13 +51,13 @@ Remote: `origin` = `https://gitea.stommer.de/Lars/Kansho.git`, Branch `main`. Na
 
 | Artefakt | Wohin | Nicht |
 |---|---|---|
-| `local-backups/kansho-20260907-055703.zip` | verschlüsselter Stick / NAS / Heimrechner | Git, Chat, Cloud-Klartext |
-| `backend/.env` | separate Secret-Notiz oder Passwortmanager | Backup-Zip, Git |
+| `transfer/kansho-laptop-20260907.zip` | selbst gehostetes Gitea `Lars/Kansho` (einmaliger Transport) | öffentliche Remotes, Provider, Chat |
+| `backend/.env` | Passwortmanager / neu eintragen auf dem Ziel | Git, Zip |
 | Login-Passwort des Admin-Profils | Kopf / Passwortmanager | Doku-Repo |
 
-Nach dem Kopieren Checksumme des Zip notieren (`Get-FileHash`). Restore prüft Manifest-Checksummen zusätzlich.
+USB-Stick und NAS sind auf diesem Laptop **nicht zulässig**. SHA256 des Transportzips: `EBF7455D5688588E8C6E50C05D16200CE191D79FB7CEACDBA9C25460B7497B07`.
 
-Wenn nach dem Backup noch Dialoge auf dem Laptop laufen: neues Backup erzeugen und **dieses** Archiv mitnehmen.
+Wenn nach diesem Backup noch Dialoge auf dem Laptop laufen: neues Zip erzeugen, `transfer/` ersetzen, erneut pushen.
 
 ### 4. Instanz stilllegen
 
@@ -76,11 +76,11 @@ Kein Live-OpenRouter-Zwang für den Abschluss.
 
 ## Abnahme Laptop
 
-- [ ] Opening-Fix und Transfer-Doku auf `origin/main`
-- [ ] Backup-Zip außerhalb des Laptops
-- [ ] `.env` außerhalb des Laptops
-- [ ] Slice-2 / Debug / Memory-Aufträge nur versioniert, nicht implementiert
-- [ ] Persönliche SQLite nicht in Git
+- [x] Opening-Fix und Transfer-Doku auf `origin/main`
+- [ ] Transport-Zip `transfer/kansho-laptop-20260907.zip` auf `origin/main`
+- [ ] `.env` nicht in Git; Keys auf dem Ziel neu eintragen
+- [x] Slice-2 / Debug / Memory-Aufträge nur versioniert, nicht implementiert
+- [x] Rohe `backend/data/`-SQLite nicht als lose Datei in Git (nur das Backup-Zip unter `transfer/`)
 
 ## Abschlussbericht
 

transfer/README.md

@@ -0,0 +1,30 @@
+---
+title: "Kanshō – Einmaliger Laptop-Datentransfer über Gitea"
+status: "Transportartefakt, nach Restore entfernen"
+date: "2026-09-07"
+---
+
+# Einmaliger Datentransfer (Laptop 2026-09-07)
+
+Dieses Verzeichnis ist **kein** Produkt-Datenspeicher. Es existiert, weil auf dem Urlaubs-Laptop weder USB-Stick noch NAS verbunden werden darf. Der Transport läuft über das selbst gehostete Gitea (`gitea.stommer.de`), das nur in der eigenen Infrastruktur erreichbar ist.
+
+## Inhalt
+
+- `kansho-laptop-20260907.zip` – SQLite (Backup-API) + Journalmedien, Manifest, Checksummen
+- **Nicht enthalten:** `backend/.env`, Provider-Keys, TLS-Zertifikate
+
+Das Archiv enthält persönliche, **unverschlüsselte** Journalinhalte, Identity-Mappings und ggf. Debug-Spuren. Es ist Klasse A/B. Nicht an Provider, nicht öffentlich klonen, nicht in fremde Remotes spiegeln.
+
+## Restore auf dem Zielrechner
+
+Backend aus. Danach:
+
+```powershell
+.\scripts\backup-local.ps1 restore -Archive .\transfer\kansho-laptop-20260907.zip -Confirm -Replace
+```
+
+`.env` neu anlegen aus `backend/.env.example` und denselben Provider-Keys (Passwortmanager / OpenRouter). Das Admin-Login steckt im SQLite-Hash, nicht in der `.env`.
+
+## Nach erfolgreichem Restore
+
+Dieses Verzeichnis aus dem Arbeitsbaum entfernen und in einem eigenen Commit nach Gitea schieben. Die Git-Historie behält die Datei; das ist bewusst der Preis dieses Transportwegs.