Kansho/docs/work_orders/laptop_closeout.md

title	status	date	document_role	canonical_handover
Kanshō – Arbeitsauftrag Laptop-Abschluss vor dem Heimtransfer	Arbeitsauftrag / teilweise erledigt	2026-09-07	Cursor Implementation Brief / Laptop Closeout	docs/architecture/technical/environment_handover.md

Arbeitsauftrag: Laptop-Abschluss

Arbeite im Repository C:\dev\Kansho auf dem Urlaubs-Laptop. Ziel ist, alles zu sichern und nach Gitea zu bringen, was zu Hause nicht mehr aus Cursor-Sessions rekonstruierbar ist.

Dieses Dokument ersetzt nicht docs/architecture/technical/environment_handover.md. Docker, Postgres und Server-Deploy gehören nicht hierher, sondern nach home_environment_setup.md.

Bereits in der Transfer-Session erledigt (2026-09-07)

• Opening-Fix gegen veraltete Recency-Impulse: Code vorhanden, python tests/test_journal_opening.py grün.
• Kanonische Doku nachgezogen (2026-09-07): mvp.md §6.1 Fehlerbild Nachsatz/Prefix, Fit-Gap mvp_stand_und_abgleich.md, mvp_implementation.md §17, memory_storage_and_offline.md. Bewusst offen dokumentiert: 400-Zeichen-Recency im laufenden Dialogzug.
• Inventar der lokalen SQLite-Instanz (1 Profil, 2 Spaces, 17 Days/Entries, 379 Messages).
• Inventar der lokalen SQLite-Instanz (1 Profil, 2 Spaces, 17 Days/Entries, 379 Messages).
• Lokales Backup: local-backups/kansho-20260907-055703.zip (~10,1 MB, SHA256 2D1E160F6DF95FA0C46B8F3FE69C1681827DE0DF304A2E955304A5C56CC7854F). SQLite + 70 Medien, keine Secrets.
• .\scripts\test-mvp.ps1 Exit 0 (isolierte Temp-Daten, Produktions-SQLite unangetastet).
• Technisches Handover und Heim-Setup-Auftrag angelegt.

Noch auf dem Laptop, bevor die Instanz aufhört führend zu sein

1. Keine neuen Produktfeatures

Nicht auf dem Laptop beginnen oder zu Ende bauen:

• docs/work_orders/debug_diagnostics_perfection.md
• docs/work_orders/dialogue_memory_next_slice_handover.md
• docs/architecture/functional/Idea_seconmd_sclide.md (Slice-2-Konzeptbrief)

Diese Dateien versionieren, nicht ausführen.

2. Git nach Gitea

Ohne Push bleibt e42f751 MVP 1.0 und der Opening-Fix nur auf dem Laptop.

Vorschlag zwei Commits (dieser Abschluss darf committen, wenn der Nutzer den Transfer schließt):

1. Opening-Fix + kanonische Opening-Doku (mvp.md, mvp_implementation.md, mvp_stand_und_abgleich.md, memory_storage_and_offline.md, Tests)
2. Transfer-Dokumentation, Work Orders, Slice-2-Brief

Remote: origin = https://gitea.stommer.de/Lars/Kansho.git, Branch main. Nach dem Push git status muss „up to date with origin/main“ zeigen.

develop auf dem Laptop nicht anlegen, solange kein Dev-Host existiert.

3. Daten und Secrets physisch kopieren

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
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.

Wenn nach dem Backup noch Dialoge auf dem Laptop laufen: neues Backup erzeugen und dieses Archiv mitnehmen.

4. Instanz stilllegen

• Uvicorn/Vite beenden.
• Keine parallelen Schreibzugriffe Laptop + Heimrechner auf denselben persönlichen Bestand.
• Laptop-Ordner als Archive behalten, bis Welle 1 zu Hause bestätigt ist.

5. Kurzer lokaler Smoke (optional, wenn Zeit)

Nur wenn der Opening-Fix committet werden soll und der Dev-Server ohnehin läuft:

• Neuen Journal Day im Space Kroatien 2026 starten: erster Impuls darf keine abgeschlossene Vortags-Episode als offenen Faden nehmen.
• .\scripts\test-mvp.ps1 rührt die Produktions-SQLite nicht an.

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

Abschlussbericht

Nennen: Commit-Hashes, Backup-Dateiname, ob nach dem Backup noch geschrieben wurde, was bewusst offen bleibt.