--- title: "Kanshō – Handover Laptop-Instanz → Heim-Entwicklung und Server" status: "Aktiver Übergabestand" date: "2026-09-07" product_family: "Jinkendo" document_role: "Session Handover / Environment Transfer / Implementation Bootstrap" parent_document: "runtime_and_deploy.md" canonical_concept_handover: "docs/architecture/functional/handover.md" --- # 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`) | | Persistenz | SQLite `backend/data/kansho.sqlite` (~11,3 MB) | | Medien | `backend/data/media//` (70 Dateien, ~8,9 MB Nutzlast; zwei große JPEGs, viele Mini-WebM/PNG) | | Secrets | `backend/.env` (nicht im Git, nicht im Backup-Archiv) | | Python | 3.12, venv `backend/.venv` | | Remote | `https://gitea.stommer.de/Lars/Kansho.git` | ### 2.2 Git | Element | Ist | |---|---| | Branch | `main` | | HEAD | `e42f751` Message `MVP 1.0` | | Remote | `origin/main` ist **einen Commit hinter** HEAD (`ahead 1`) | | `develop` | existiert **nicht** (Familienmuster Dev=`develop` / Prod=`main` ist entschieden, aber noch nicht angelegt) | Uncommittet (muss vor dem Verlassen des Laptops nach Gitea): - Opening-Fix: `backend/journal_opening.py`, `context_builder.py`, `retrieval.py`, `tests/test_journal_opening.py` - Opening-Doku: `mvp.md` §6.1, `mvp_implementation.md` §17, `mvp_stand_und_abgleich.md` (Tabellen 5.4, §6.4, §7, Dateikarte), `memory_storage_and_offline.md` §6.2 - Invariante: Vorhaben nur aus dem **user-Dialog des vorigen Kalendertags**; gespeicherte Journal-Entries sind kein Opening-Mandat; Opening-Call ohne Space-Recency. Fehlerbild: Nachsatz mit Morgenuhrzeit + 400-Zeichen-Prefix. Tests 2026-09-03/07 lokal grün. - Transfer-Doku und Work Orders (siehe unten) Bewusst **nicht** in diesem Transfer schließen: Prefix-Recency im laufenden `dialogue_turn`. Unversioniert (gehören in denselben oder einen Dokumentations-Commit): - `docs/architecture/functional/Idea_seconmd_sclide.md` (Konzeptbrief Slice 2, Dateiname mit Tippfehler) - `docs/work_orders/` (Debug-Diagnostik, Dialog/Memory-Slice, Laptop-Abschluss, Heim-Setup) - dieses Handover und die Runtime-Ergänzungen Nicht in Git und **nicht** ins Backup: `backend/.env`. ### 2.3 Persönlicher Datenbestand (Inventar, kein Inhalt) Ein Admin-Profil seit 2026-08-19. Zwei Spaces: `Kroatien 2026` (Urlaubsjournal) und `Test für Prosagenerierung`. 17 Journal Days, 17 Current-Entries, 20 Conversations, 379 Messages, Writing Profile vorhanden, Identity-Mappings lokal, Debug-Runs opt-in persistiert. Das ist **Klasse-A/B-Material**. Es darf nicht nach Gitea, nicht an Provider, nicht unverschlüsselt in die Cloud. ### 2.4 Backup dieser Session Erzeugt: `local-backups/kansho-20260907-055703.zip` (gitignoriert). 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. --- ## 3. Was auf dem Laptop noch zu tun ist Siehe Arbeitsauftrag `../../work_orders/laptop_closeout.md`. Kurz: 1. Opening-Fix und diese Dokumentation committen und nach Gitea pushen. 2. Backup-Archiv und `.env` **getrennt** physisch mitnehmen. 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. | | Ältere MVP-Sessions (Freeze, Editorial, Policy, Debug-Persistenz, Writing Style) | Journal-MVP 1.0 | **Abgeschlossen** im Commit `e42f751`, sofern nach Gitea gepusht. | Ältere Transcripts lokal unter Cursor; sie müssen nicht migriert werden, wenn Gitea den Code-Stand trägt. --- ## 5. Welle 1 – Heim-Entwicklung mit SQLite Auftrag: `../../work_orders/home_environment_setup.md` Phase A. 1. Auf dem Heimrechner (erwarteter Pfad analog `C:\dev\Kansho` oder später Linux-Checkout) `git clone https://gitea.stommer.de/Lars/Kansho.git`. 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 \kansho-20260907-055703.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). Erst wenn das gilt, ist der Laptop nicht mehr führend. --- ## 6. Welle 2 – Docker, Postgres, Server Auftrag: `../../work_orders/home_environment_setup.md` Phase B–C. 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. Entschieden (nicht neu verhandeln): - Docker Compose: Frontend, Backend, PostgreSQL 16 - Branches: `develop` → Dev, `main` → Prod - Secrets nur in Server-`.env` - Persönlicher LLM-Egress nur über Privacy Gateway - Kein Auto-Rollback der Datenbank - Kanshō-Ports **nicht** Mitai `3002`/`8002`/`3099`/`8099` kopieren Offen, vor Compose festlegen: 1. Läuft Kanshō auf demselben Pi wie Mitai, als **eigenes** Compose-Projekt? 2. Eigenes Postgres (bevorzugte Richtung: ja, eigene Instanz/DB `kansho`, kein Shared-Schema mit Mitai)? 3. Dev-Domain / Prod-Domain / Host-Pfade (Hypothese: `dev.kansho.jinkendo.de` / `kansho.jinkendo.de`)? 4. Dev-Ports auf dem Pi, lokal bleiben 5188/8018 für den Windows-Checkout ohne Docker. 5. Ob Welle 2 zuerst Compose **mit SQLite-Volume** als Zwischenstand nutzt oder direkt Postgres + Migrationsadapter. Empfohlene Reihenfolge in Welle 2: 1. Offene Host-Fragen beantworten und in `runtime_and_deploy.md` §1/§6 eintragen. 2. `develop` anlegen, sobald Auto-Deploy gewünscht ist; bis dahin darf `main` der einzige Branch bleiben. 3. Compose-Gerüst analog Mitai, **eigene** Container-/Volumen-/Projektnamen (`kansho-*`, keine `bodytrack/`-Pfade). 4. Backend-Start: Postgres ready → nummerierte SQL-Migrationen → App. Fail-fast. 5. Datenübernahme SQLite → Postgres als **eigenes** Migrationsskript mit Probe-Restore, nicht still im Alltagspfad. 6. Gitea-Workflows erst, wenn Runner-Pfade existieren (`runtime_and_deploy.md` §4). 7. Watchtower später prüfen, nicht in diesem Transfer. --- ## 7. Datenschutz beim Transfer - Backup und `.env` nie in Git, nie in Chat-Uploads, nie an OpenRouter. - Identity-Mappings bleiben lokal (Klasse A). - Das Zip ist Klartext-Journal. Transport verschlüsseln (BitLocker-Stick, verschlüsseltes NAS, `age`/`gpg` nach Wahl). - Nach erfolgreichem Heim-Restore Laptop-Kopie als Archive behalten, nicht parallel weiterschreiben. - Debug-Traces in der DB können Prompt-Ausschnitte enthalten; sie reisen im Backup mit. Auf dem Server den Schalter `debug.persist_traces` prüfen. --- ## 8. Bewusst nicht Teil dieses Transfers - Slice 2 / Memory-Continuity implementieren - Zentralen Debug-Export umbauen - Voice, semantisches Retrieval, Self Model - Mitai-Verzeichnisnamen, Mitai-Ports, Shared-Postgres-Schema - Fachliche Produktentscheidungen aus dem Konzept-Handover --- ## 9. Nächster Arbeitsschritt 1. Auf dem Laptop: `laptop_closeout.md` abschließen (Commit/Push, Backup kopieren). 2. Zu Hause: neue Session mit diesem Dokument plus `runtime_and_deploy.md` und `home_environment_setup.md`. 3. Welle 1 bis Restore-Abnahme. 4. Erst dann Welle 2. --- ## 10. Querverweise - Runtime: `runtime_and_deploy.md` - Stack: `product_frame_and_stack.md` - SQLite-Ist: `mvp_implementation.md` §1 und §4 - Fachliches Session-Handover: `../functional/handover.md` - Laptop-Abschluss: `../../work_orders/laptop_closeout.md` - Heim-Setup: `../../work_orders/home_environment_setup.md` - Mitai: `C:\dev\mitai\docker-compose.yml`, `docker-compose.dev.yml`, `.gitea/workflows/`