# Kanshō – Handover: Laptop-Urlaubsinstanz → normale Entwicklung und Server
Dieses Dokument ist der **technische Aufsatzpunkt** für den Umgebungswechsel. Es ersetzt weder `runtime_and_deploy.md` noch das fachliche Konzept-Handover `../functional/handover.md`.
**Stand:** 2026-09-07, erstellt auf dem Urlaubs-Laptop unter `C:\dev\Kansho`.
Ziel: Code, Dokumentation und persönliche Testdaten so übergeben, dass zu Hause weiterentwickelt und später auf Docker/PostgreSQL umgestellt werden kann, ohne die Urlaubsdaten zu verlieren.
---
## 1. Leitentscheidung für den Transfer
**Zwei Wellen, nicht eine.**
| Welle | Was | Warum |
|---|---|---|
| **1. Kontinuität** | Gitea-Stand klonen, lokale SQLite-Instanz wie bisher, Backup wiederherstellen, Dialog-/Journalqualität prüfen | Der gebaute Slice ist SQLite. Die persönlichen Daten liegen in `backend/data/`. Postgres ist Ziel, nicht Ist. |
| **2. Betriebsrahmen** | Docker Compose, eigenes Postgres, Deploy-Muster analog Mitai, Gitea-Runner | Entschiedenes Ziel in `product_frame_and_stack.md`. Nicht im selben Schritt wie der erste Daten-Restore. |
Ein SQLite-Restore auf dem Heimrechner **vor** der Postgres-Migration ist die Restore-Übung, die `runtime_and_deploy.md` §7 Punkt 3 verlangt. Erst wenn Welle 1 grün ist, wird der Slice auf Compose/Postgres gehoben.
Nicht tun: Urlaubs-SQLite in ein noch nicht existierendes Postgres-Schema laden, während uncommitteter Code nur auf dem Laptop liegt.
---
## 2. Ist-Stand der Laptop-Instanz (2026-09-07)
### 2.1 Laufzeit
| Element | Ist |
|---|---|
| Host | Windows-Laptop, Pfad `C:\dev\Kansho` |
| Start | ohne Docker: Uvicorn **8018**, Vite **5188** (`strictPort`) |
-`ec0f8ba` Opening-Fix: Vorhaben nur aus dem **user-Dialog des vorigen Kalendertags**; Journal-Entries kein Opening-Mandat; Opening-Call ohne Space-Recency. Fehlerbild (Nachsatz + 400-Zeichen-Prefix) in `mvp.md` §6.1 und Fit-Gap.
- Transfer-Doku, Work Orders, Slice-2-Brief auf `main` direkt danach.
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.
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.
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.
---
## 4. Offene Cursor-Sessions (Laptop)
Diese Sessions sind Kontext, keine zweite Source of Truth. Kanonisch bleiben die Repository-Dateien.
| Session | Thema | Status für den Transfer |
|---|---|---|
| [Opening-Impuls](d5e159cf-4d3c-4069-95f9-123a5500b1da) | Erster Impuls zog abgeschlossene Vortage / 400-Zeichen-Entry-Prefix | **Code und kanonische Doku fertig (2026-09-07).** Invariante in `mvp.md` §6.1, Fit-Gap §6.4, `mvp_implementation.md` §17. Bewusst offen: Prefix-Recency im laufenden Dialogzug. Persönliche Dialoginhalte nicht in Doku. |
| Diese Session | Umgebungswechsel | **Laptop-pflichtig.** Handover und Work Orders angelegt; kanonische Opening-Doku nachgezogen. Commit/Push und physisches Backup bleiben die Abnahme. |
| `docs/work_orders/debug_diagnostics_perfection.md` | Zentraler Admin-Export | **Verschieben.** Kein Laptop-Zwang. |
| `docs/work_orders/dialogue_memory_next_slice_handover.md` | Dialog + Langzeitgedächtnis | **Verschieben.** Konzept/Fit-Gap, keine Implementierung auf dem Laptop. |
| `docs/architecture/functional/Idea_seconmd_sclide.md` | Fachlicher Slice-2-Brief | **Verschieben.** Keine Dateien ändern, bis eine Konzept-Session ihn abarbeitet. |
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).
Erst wenn das gilt, ist der Laptop nicht mehr führend.
Mitai-Referenz auf dem Heimrechner: `C:\dev\mitai` (Compose, `.gitea/workflows/`, Hostpfade `/home/lars/docker/bodytrack` und `bodytrack-dev`).
**Noch nicht im Kanshō-Repo:** Dockerfiles, Compose, Gitea-Workflows, Postgres-Adapter. `backend/db.py` ist SQLite (`sqlite3`, `PRAGMA`, `datetime('now')`). Das ist eine eigene Implementierungsarbeit, kein Copy-Paste von Mitai-Fachlogik.
1. Läuft Kanshō auf demselben Pi wie Mitai, als **eigenes** Compose-Projekt? **Ja.**`/home/lars/docker/kansho` und `kansho-dev`.
2. Eigenes Postgres? **Ja**, `kansho` / `kansho_dev`, kein Shared-Schema.
3. Dev-Domain / Prod-Domain / Host-Pfade? **`dev.kansho.jinkendo.de` / `kansho.jinkendo.de`**, Ports 3096/8096 und 3006/8005. Lokal bleiben 5188/8018. Prod-UI nicht 3005 (Bookstack auf dem Pi).
4. Welle 2 SQLite im Volume oder direkt Postgres? **Direkt Postgres.** SQLite bleibt lokal und für Tests.
Diese Schritte sind im Repository angelegt (`docker-compose*.yml`, `.gitea/workflows/`, `backend/db_init.py`, `backend/sqlite_to_postgres.py`). Pi-Bootstrap und Cutover: `docs/DEPLOYMENT.md`.
