Merge: resolve index.md conflict

Docs_For_AI_Unsorted/04_VPS_Serverstruktur_Prompt.md

@@ -0,0 +1,106 @@
+# VPS Server Structure — Context Prompt for Deployments
+
+*Paste this at the start of any new chat where you're deploying or configuring something on the VPS.*
+
+---
+
+## Machine
+
+IONOS VPS, type VPS 6-8-240 (6 vCore, 8 GB RAM, 240 GB NVMe)
+OS: Debian 13 (trixie)
+User: `patsy`
+Domain: `bujour.de` / `bujour.info`
+
+## Directory layout
+
+```
+/home/patsy/
+├── stacks/          # Docker Compose stacks for infrastructure
+│   ├── caddy/       # Reverse proxy
+│   │   ├── compose.yaml
+│   │   └── Caddyfile
+│   └── forgejo/     # Git server
+└── apps/            # Application source / runtime dirs
+    └── checkpoint/  # CheckPoint Ehrenamt app
+```
+
+## Running containers
+
+| Container  | Image                          | Ports                        | Network |
+|------------|-------------------------------|------------------------------|---------|
+| caddy      | caddy:2                        | 80, 443, 443/udp             | proxy   |
+| forgejo    | codeberg.org/forgejo/forgejo:10 | 3000 (internal), 2222 (SSH) | proxy   |
+| checkpoint | checkpoint-checkpoint          | 8000 (internal)              | proxy   |
+
+## Networking
+
+- External Docker network: `proxy` — all containers that need to be reachable via Caddy must join this network
+- Caddy is the only container with public-facing ports (80/443)
+- App containers expose ports internally only (no `host:container` mapping needed)
+
+## Caddy routing (~/stacks/caddy/Caddyfile)
+
+```
+git.bujour.de {
+    reverse_proxy forgejo:3000
+}
+
+cpe.bujour.info {
+    reverse_proxy checkpoint:8000
+}
+```
+
+## Adding a new app — the pattern
+
+1. Create `~/apps/<appname>/` for app source/config
+2. Create `~/stacks/<appname>/compose.yaml` — join network `proxy`, expose port internally only
+3. Add a block to `~/stacks/caddy/Caddyfile`: `subdomain.domain.tld { reverse_proxy <appname>:<port> }`
+4. Reload Caddy: `docker exec caddy caddy reload --config /etc/caddy/Caddyfile`
+5. Restart new stack: `cd ~/stacks/<appname> && docker compose up -d`
+
+## Caddy compose (~/stacks/caddy/compose.yaml)
+
+```yaml
+services:
+  caddy:
+    image: caddy:2
+    container_name: caddy
+    restart: unless-stopped
+    ports:
+      - "80:80"
+      - "443:443"
+      - "443:443/udp"
+    volumes:
+      - ./Caddyfile:/etc/caddy/Caddyfile:ro
+      - caddy_data:/data
+      - caddy_config:/config
+    networks:
+      - proxy
+
+volumes:
+  caddy_data:
+  caddy_config:
+
+networks:
+  proxy:
+    external: true
+```
+
+## Shell & scripting rules
+
+- Interactive: Bash + fzf (fuzzy history: Ctrl+R, files: Ctrl+T, dirs: Alt+C)
+- All scripts touching the VPS: Bash/POSIX only — never Fish
+- `sudo` required for most system commands (patsy is not root)
+- `ufw` requires `sudo` — `/usr/sbin/` not in default PATH by design
+
+## Firewall
+
+- UFW active on VPS
+- IONOS hardware firewall also configured (both must be opened for new ports)
+- IONOS web console = emergency recovery path — always keep it accessible
+
+## Hard rules (learned the hard way)
+
+- Always seed the DB and create the first admin user before considering a deploy done
+- Always verify SSH key access before applying any hardening
+- New ports need opening in **both** UFW and the IONOS firewall panel

Docs_For_AI_Unsorted/CLAUDE.md

@@ -0,0 +1,268 @@
+# CLAUDE.md — CheckPoint Ehrenamt App
+
+> Projektanker. Claude Code liest diese Datei automatisch zu Beginn jeder Session.
+> Sie ist die verbindliche Quelle für Stack, Regeln und Logik. Bei Widerspruch
+> zwischen Wunsch und dieser Datei: nachfragen, nicht raten.
+
+---
+
+## Zweck
+
+Interne, mobile-first Web-App für das Vor-Ort-Team Prävention der AIDS-Hilfe.
+Sie organisiert Einsätze (Terminabstimmung + Dienstverteilung) und ersetzt
+schrittweise die WhatsApp/Signal-Zettelwirtschaft. **Das Herzstück ist die
+Dienstplanung — alles andere ordnet sich dem unter.**
+
+---
+
+## Stack & Rahmenbedingungen (fest)
+
+| Bereich | Entscheidung |
+|---|---|
+| Sprache/Backend | **Python + Flask** |
+| Templating | **Jinja2**, server-gerendertes HTML (klassische Multi-Page-App) |
+| ORM/DB | **SQLAlchemy**, **SQLite** für v1 (ein VPS, 17 Nutzer). Keine Annahmen treffen, die einen späteren Umstieg auf PostgreSQL verbauen. |
+| Passwörter | `werkzeug.security` (Hashing), nie Klartext |
+| CSS | **selbst gebaut, kein CSS-Framework**. Basis: `tokens.css` + `components.css` (User-Shell) + `components-admin.css` (Admin-Shell) |
+| JavaScript | **so wenig wie möglich, nur Vanilla, kein Framework**. Einzige Ausnahme v1: Chat-Polling (s. u.) |
+| Hosting | **eigener VPS in der EU** |
+| Plattform | mobile-first Web-App, **kein App Store**, „zum Homescreen" möglich |
+| UI-Sprache | **Deutsch** |
+
+**Erlaubte Zusatz-Bibliotheken (klein halten):** Flask, SQLAlchemy/Flask-SQLAlchemy,
+Werkzeug, optional Flask-Login. Keine schweren Frameworks, kein CSS-/JS-Framework.
+
+---
+
+## Architektur-Prinzipien
+
+1. **Server-rendered first.** Seiten kommen fertig vom Server. Formulare sind echte
+   `POST`-Formulare. Kein clientseitiges Routing, kein SPA-Verhalten.
+2. **JavaScript nur, wo es sich beweist.** Zwei JS-Ausnahmen in v1: der Chat holt
+   neue Nachrichten per kleinem `fetch`-Polling, und die Admin-Sidebar wird auf
+   schmalen Bildschirmen per Hamburger-Icon als Off-Canvas-Overlay ein-/ausgeklappt
+   (Klasse toggeln, kein Framework). Sonst nirgends JS verlangen.
+3. **Mandantenfähig ab Tag 1.** Siehe eigener Abschnitt. Jeder Datensatz gehört zu
+   genau einem Team.
+4. **Mobile-first.** Getestet in App-Breite 360–460px.
+5. **Barrierearmut ist Pflicht, kein Extra.** 44px Touch-Ziele, sichtbarer Fokus,
+   Status nie nur über Farbe, sinnvolle `aria-label`.
+
+---
+
+## Rollen
+
+| Rolle | Rechte |
+|---|---|
+| **Admin** | Logins vergeben, Planungszeiträume und Einsätze anlegen, Dienstplan bauen und veröffentlichen, Dokumente/Fotos freigeben, im Kanal „Ankündigungen" posten, Team verwalten. |
+| **Ehrenamtliche:r** | Verfügbarkeit melden, eigenen Dienstplan sehen, freie Dienste übernehmen, Dokumente/Fotos hochladen (Freigabe nötig), im Kanal „Team" schreiben, Profil pflegen. |
+
+- **Keine Selbstregistrierung.** Logins legt ausschließlich der Admin an.
+- **v1:** Nutzername + Passwort. (E-Mail + Code = Future Log.)
+
+---
+
+## Mandantenfähigkeit (Pflichtregeln)
+
+- Zentrale Einheit **`team`** (= Mandant). Das CheckPoint-Team ist das erste von
+  perspektivisch mehreren.
+- **Jeder** Datensatz (user, planungszeitraum, einsatz, verfuegbarkeit, zuteilung,
+  dokument, kanal, nachricht) trägt eine **`team_id`**.
+- **Jede** Datenbankabfrage filtert nach dem Team des eingeloggten Nutzers. Nie Daten
+  über Teamgrenzen hinweg ausliefern. Das aktive Team wird aus der Session abgeleitet.
+- Das Corporate Design wird **pro Team** über die Brand-Tokens in `tokens.css`
+  gesetzt (serverseitig in den `<head>` injiziert). Code darf keine Markenfarbe
+  fest verdrahten — immer Tokens verwenden.
+
+---
+
+## Zwei Oberflächen, zwei Shells (Pflichtregel)
+
+Es gibt **zwei eigenständige Layout-Shells**, eine pro Rolle. Sie sind keine
+Variante derselben Vorlage, sondern zwei getrennte Templates mit jeweils eigenem
+Tokensatz:
+
+| | **User-Shell** | **Admin-Shell** |
+|---|---|---|
+| Für wen | Ehrenamtliche | Admin |
+| Vorlage | `base_user.html` | `base_admin.html` |
+| Navigation | Bottom-Nav, 4 Punkte (Start, Termine, Team, Profil) | Sidebar links, fest: Start, Planung, Dienste, Freigaben, Team, Chat-Verwaltung, Profil, Abmelden |
+| Grundform | Mobile-first (App-Breite 360–460px) | Desktop-first (Sidebar 260px), responsiv bis Mobile |
+| Mobiles Verhalten | nativ mobil, keine Anpassung nötig | Sidebar wird unter dem Breakpoint zu einer **Off-Canvas-Navigation**: Hamburger-Icon oben links öffnet sie als Overlay |
+| Tokens | `--cp-user-*` (Türkis/Rot, DM Sans) | `--cp-admin-*` (Navy/Teal/Gelb/Pink, Roboto Condensed + Alfa Slab One für Seitentitel) |
+| CSS-Wurzelklasse | `.cp-shell-user` | `.cp-shell-admin` |
+
+**Wichtig:** Die Admin-Startseite hat **keine eigene Kachel-Navigation** wie die
+User-Startseite — die Sidebar selbst trägt die Hauptaktionen. Die Admin-Inhaltsfläche
+zeigt direkt die Arbeit (Tabellen, Listen, Formulare), nicht zusätzliche Navigations-
+Buttons.
+
+**Mobile Sidebar-Mechanik (einzige zusätzliche v1-JS-Ausnahme neben dem Chat):**
+Unter dem Breakpoint kollabiert die Sidebar zu einem Hamburger-Icon in einer
+schmalen Topbar. Klick öffnet die Sidebar als Off-Canvas-Overlay (kleines
+Vanilla-JS: Klasse toggeln, Overlay schließt bei Klick daneben oder auf einen
+Menüpunkt). Kein Framework, keine Bibliothek.
+
+**Mandantenfähigkeit gilt für beide Shells unabhängig:** ein neues Team tauscht
+sowohl den `--cp-user-brand-*`- als auch den `--cp-admin-brand-*`-Block. Die beiden
+Themes werden nie gemischt — Komponenten in der User-Shell nutzen ausschließlich
+`--cp-user-*`, Komponenten in der Admin-Shell ausschließlich `--cp-admin-*`.
+
+---
+
+## Datenmodell (Regeln, konzeptionell)
+
+Jede Tabelle hat `team_id`. Namen/Felder sind Richtwerte, keine starre Vorgabe.
+
+- **team** — Mandant. Felder u. a.: Name, Brand-Tokens (Primär, Primär-stark, Akzent,
+  Akzent-stark, Schrift), Logo-Pfad.
+- **user** — `rolle` (admin | ehrenamt), Nutzername, Passwort-Hash, Anzeigename,
+  optionales Profilbild, optionale freiwillige Angaben.
+- **planungszeitraum** — Block von mind. 2 Monaten. `status`: in_planung | veroeffentlicht.
+- **einsatz** — gehört zu einem Planungszeitraum. Datum, Uhrzeit (Start/Ende), Art/Ort
+  (z. B. Tour Altstadt, Party, Sonderveranstaltung). Braucht **2 Hauptplätze + 1 Springerplatz**.
+- **verfuegbarkeit** — (user × einsatz) → kann | kann_nicht.
+- **zuteilung** — (user × einsatz) mit `platztyp` (haupt | springer) und
+  `status` (zugeteilt | abgesagt | offen | uebernommen).
+- **dokument** — Datei (PDF/Word/Bild). Felder: Titel (Pflicht), Uploader, `status`
+  (wartet_auf_freigabe | freigegeben | abgelehnt), `ablage` (aktuell | archiv).
+- **kanal** — pro Team zwei feste: `ankuendigungen`, `team`.
+- **nachricht** — Kanal, Autor, Text, Zeitstempel. **Nur Text.**
+
+---
+
+## Kern-Business-Logik (verbindlich)
+
+### Planungszyklus
+1. Admin legt Planungszeitraum (≥ 2 Monate) an und trägt die kuratierten Einsätze ein
+   (Freitags-Touren, Samstags-Einsätze/Partys, Sonderveranstaltungen).
+2. Status `in_planung` → Ehrenamtliche melden pro Einsatz **kann / kann nicht**.
+   Änderung der Verfügbarkeit nur solange `in_planung`.
+3. Admin baut den Plan **manuell**: pro Einsatz **2 Haupt + 1 Springer**. Die App zeigt
+   pro Person **Anzahl bisheriger Einsätze** und **letzten Einsatz** als Hilfe
+   (keine automatische Verteilung in v1).
+4. Bei zu wenigen Verfügbaren: Einsatz als **unterbesetzt** markieren.
+5. Admin **veröffentlicht** → alle sehen ihren persönlichen Dienstplan.
+
+### Absage & Übernahme
+- Sagt eine **Hauptperson** ab → **Springer rückt automatisch nach** (Status `uebernommen`).
+- Der frei gewordene **Springerplatz** wird `offen` → zum **„Übernehmen"** für alle.
+- Gibt es keinen Springer / sagt er auch ab → offener Platz für alle.
+- „Übernehmen" dient **nur dem Nachrücken**, nie der Erstverteilung.
+
+### Dokumente
+- Upload durch alle, aber Status startet **`wartet_auf_freigabe`** (nur Admin + Uploader sichtbar).
+- Admin gibt frei oder lehnt ab (optional Grund). Erst nach Freigabe für alle sichtbar.
+- Admin-Uploads gehen direkt durch.
+- Liste geteilt in **Aktuell** und **Archiv** (Verschieben macht der Admin).
+- **Foto-Regel:** nur ohne erkennbare Dritte bzw. mit deren Einverständnis.
+
+### Chat
+- Zwei Kanäle: **Ankündigungen** (nur Admin postet, alle lesen) und **Team** (alle posten).
+- Nur Text. Neue Nachrichten via Hintergrund-`fetch`-Polling (einzige v1-JS-Ausnahme).
+
+### Benachrichtigungen
+- **v1: nur in-App** (neuer Dienst, offener Dienst, neue Nachricht). Push/E-Mail = Future Log.
+
+---
+
+## Designsystem
+
+- Quelle der Wahrheit: **`tokens.css`** — enthält **zwei vollständig getrennte
+  Tokensätze**, `--cp-user-*` (User-Shell) und `--cp-admin-*` (Admin-Shell), je
+  mandantenfähig und mit hell + dunkel via `light-dark()`.
+- **User-Theme:** Türkis/Rot, Schrift DM Sans. Status-Mapping: Türkis =
+  offen/bestätigt/verfügbar · Rot = dringend/Vertretung · Neutral = Info/intern/erledigt.
+- **Admin-Theme:** Navy-Sidebar (in beiden Farbmodi gleich dunkel — bewusst, sie ist
+  das feste Markenelement), helle Arbeitsfläche, Teal für Aktionen/aktive Navigation,
+  Gelb nur für Sidebar-Icons, Pink nur als Markenakzent (nie als Fehlerfarbe — dafür
+  ist Rot da). Schrift: Roboto Condensed für UI/Tabellen/Formulare, Alfa Slab One nur
+  für kurze Seitentitel, Roboto Mono für Zahlen/IDs.
+- **Hell/Dunkel** folgt automatisch der Systemeinstellung. Manueller Override über
+  `<html data-theme="dark|light">` ist vorbereitet (Toggle = Future Log).
+- **Nie feste Farben** im Komponenten-CSS — immer Tokens. **Nie Theme-Tokens
+  mischen** — eine Komponente innerhalb der User-Shell nutzt nur `--cp-user-*`,
+  innerhalb der Admin-Shell nur `--cp-admin-*`.
+- Bekanntes To-do: vorhandenes Mockup-CSS hat fest verdrahtetes Weiß (Topbar,
+  Bottom-Nav, `.cp-page`-Verlauf). Beim Refactor auf Tokens umstellen, sonst bricht
+  der Dunkelmodus.
+
+---
+
+## UI-Regeln
+
+### User-Shell
+- App-Breite 360–460px, viel Weißraum, klare Karten (Radius 12px, Innenabstand 16px),
+  keine verschachtelten Karten.
+- **Bottom-Navigation, 4 Punkte: Start · Termine · Team · Profil.** (Nicht „Kalender".)
+- Jede Ansicht hat **eine klare Hauptaktion** (Button oder FAB).
+- Buttons: Primär = Türkis/weiß · Dringend = Rot/weiß · Ghost = Fläche mit feinem
+  Rahmen. Kurze Beschriftungen: „Speichern", „Eintragen", „Übernehmen", „Details".
+
+### Admin-Shell
+- Desktop-Grundraster: Sidebar 260px + fließender Hauptbereich, Seitenabstand 32px.
+- **Sidebar-Punkte (fest, in dieser Reihenfolge):** Start · Planung · Dienste ·
+  Freigaben · Team · Chat-Verwaltung · Profil — Abmelden unten abgetrennt.
+- Aktiver Menüpunkt: Teal-Fläche, weißer Text, gelbes Icon. Inaktiv: gedimmtes Weiß,
+  gelbes Icon.
+- Cards/Panels: Radius 8–12px (max. 14px), Innenabstand 20–30px, sehr dezenter Schatten,
+  Panel-Header darf `--cp-admin-surface-soft` nutzen.
+- Tabellenkopf in Navy mit weißem, fettem Text. Statusspalten farbig **mit Text**, nie
+  nur über Farbe.
+- **Unter dem Breakpoint:** Sidebar kollabiert zu Hamburger-Icon, öffnet als
+  Off-Canvas-Overlay. Touch-Ziele bleiben ≥ 44px auch im Admin-Bereich.
+
+### Beide Shells
+- Formulare: Labels immer sichtbar über dem Feld, Felder ≥ 44px, kurze freundliche
+  Hilfetexte, Fehler klar und nicht nur über Farbe.
+
+## Texte / Copy
+
+- **Deutsch**, Satzanfang groß (sentence case), aktive Verben, keine Floskeln.
+- Eine Aktion heißt im ganzen Flow gleich (Button „Übernehmen" → Bestätigung „Übernommen").
+- Fehlermeldungen sagen, was passiert ist und wie es weitergeht — ohne Entschuldigung.
+
+---
+
+## Bewusst raus aus v1 (Out of Scope)
+
+Keine öffentlichen Seiten · keine Klient:innendaten · keine Bezahlfunktion ·
+kein Kalender-Sync (Terminübersicht = Liste) · keine Dateien/Bilder im Chat ·
+keine automatische Dienstverteilung · kein 1:1-Chat · kein Push/E-Mail.
+
+---
+
+## Vorgeschlagene Projektstruktur
+
+```
+checkpoint-ehrenamt/
+├── CLAUDE.md
+├── TASKS.md
+├── app/
+│   ├── __init__.py        # App-Factory, DB-Init, Team-Scoping
+│   ├── models.py          # SQLAlchemy-Modelle (alle mit team_id)
+│   ├── auth.py            # Login, Logout, Admin-Anlage
+│   ├── routes/           # Blueprints: planung, dienste, dokumente, chat, profil
+│   ├── templates/
+│   │   ├── base_user.html    # User-Shell: Bottom-Nav
+│   │   ├── base_admin.html   # Admin-Shell: Sidebar + mobiles Off-Canvas
+│   │   └── ...               # Teilansichten je Route
+│   └── static/
+│       ├── tokens.css        # beide Theme-Tokensätze (--cp-user-*, --cp-admin-*)
+│       ├── components.css    # Komponenten der User-Shell
+│       ├── components-admin.css  # Komponenten der Admin-Shell
+│       └── sidebar.js        # Hamburger/Off-Canvas-Logik (Vanilla, ~20 Zeilen)
+├── instance/             # SQLite-DB, Uploads (nicht im Git)
+└── requirements.txt
+```
+
+---
+
+## Arbeitsweise mit den Modellen (Continue)
+
+- **Mistral (Architect):** Planung, Design-Entscheidungen, Reviews. Nie zum Schreiben
+  von Produktivcode.
+- **Qwen (Coder):** Implementierung, Bugfixes, Inline-Edits (`Ctrl+I`). Immer ein
+  Stück nach dem anderen (Datenmodell → Service → Route → Template).
+- **Claude Code:** Scaffold, Mehrdateien-Arbeit, übergreifendes Verdrahten.
+- **Eine Aufgabe pro Session.** Immer `@file`-Kontext. Plan vor Code.

Docs_For_AI_Unsorted/Prompt_Allgemein.md

@@ -0,0 +1,28 @@
+# Persönlicher KI-Prompt — Allgemein
+
+Du bist mein Assistent und Mentor. Diese Anweisungen gelten für alle Themen. Halte dich durchgehend daran.
+
+## Wer ich bin
+Ich habe starkes ADHS. Was für andere selbstverständlich und alltäglich ist, ist für mich manchmal eine ganz neue Sache, die ich erst lernen muss. Ich brauche deshalb oft mehr Struktur, eine klare Reihenfolge und einen roten Faden, damit große oder längere Vorhaben nicht im Sande verlaufen.
+
+## Wie du mit mir kommunizierst
+- **Struktur geben:** Zerlege Größeres in klare, überschaubare Schritte. Sag mir, wo wir gerade stehen und was als Nächstes kommt.
+- **Mitdenken statt nur ausführen:** Wenn der Umfang eines Themas oder mein Wissensstand es rechtfertigt, stell mir Fragen — auch mehrere. Oft komme ich auf wichtige Fragen gar nicht von selbst, weil mir das Wissen dazu fehlt. Lieber einmal gut nachfragen, als dass ein Gedanke versandet.
+- **Fragen immer als Liste auf einmal:** Wenn du mehrere Fragen hast, stell sie mir alle auf einmal als nummerierte Liste. Ich beantworte nur die erste. Dann gehen wir dieselbe Liste der Reihe nach durch, Frage für Frage. Wirf mir dabei keinen neuen Fragenkatalog hinterher — bleib bei der ursprünglichen Liste, bis sie abgearbeitet ist.
+- **Challenge mich:** Gib mir bei Aufgaben erst die Chance, es selbst zu versuchen. Wenn ich nicht weiterkomme, gib mir einen Hinweis (Hint), keine fertige Lösung. Erst wenn ich ausdrücklich nach einer klaren Antwort frage, gibst du sie mir vollständig.
+
+## Schnell-Antwort-Zeichen
+- Setze ich ein **„?"** vor meine Frage, will ich nur eine **schnelle, knappe Antwort** — kein Lernmodus, kein Schritt-für-Schritt.
+- Ohne „?" gehe davon aus, dass ich lernen und nachvollziehen will. Erkläre dann das *Warum*, nicht nur das *Was*.
+
+## Sprache (wichtig)
+- **Privates und alltägliche Themen: Deutsch.**
+- **Sobald es um Programmieren, Technik oder Computer-Themen geht: Englisch** — Erklärung *und* Code/Befehle. Grund: Ich müsste sonst ständig das Tastatur-Layout wechseln. Wechsle die Sprache also je nach Thema, nicht je nach meiner Eingabe.
+
+## Bullet-Journal (feste Gewohnheit)
+Ich führe ein Bulletjournal. Schließe größere Schritte oder Sitzungen mit einer kurzen, kopierbaren Notiz ab — in dieser Form:
+
+> **Getan:** … (1–3 Stichpunkte, was konkret passiert ist)
+> **Gelernt:** … (1–3 Stichpunkte, die wichtigste Einsicht)
+
+Halte sie knapp und konkret, damit ich sie direkt übernehmen kann. Bei rein technischen Themen ist diese Notiz auf Englisch.

Docs_For_AI_Unsorted/Prompt_Privat.md

@@ -0,0 +1,31 @@
+# Persönlicher KI-Prompt — Privat
+
+Du bist mein Assistent und Mentor für mein Privatleben. Antworte hier immer auf **Deutsch**.
+
+## Wer ich bin
+Ich habe starkes ADHS. Alltägliche Dinge, die für andere selbstverständlich sind, sind für mich manchmal eine echte Hürde. Ich brauche Struktur, eine klare Reihenfolge und kleine, machbare Schritte, damit ich ins Tun komme und nicht stecken bleibe.
+
+## Wobei ich dich am häufigsten brauche
+- **Behördensachen** (z. B. Elster-Anmeldung, Anträge, Formulare) — fällt mir oft schwer. Hier brauche ich klare, geduldige Schritt-für-Schritt-Führung, kein „das ist doch einfach".
+- **Planung**, z. B. Urlaub planen.
+- **Nachhaltige Routinen aufbauen**, z. B. ein realistischer, durchhaltbarer Putzplan.
+- **Alltagsorganisation und ADHS-freundliche Struktur** allgemein.
+- **Schreiben und Korrespondenz** (E-Mails, Briefe, Formulierungen).
+- **Reflexion** — Dinge sortieren, durchdenken, ordnen.
+
+## Wie du mit mir arbeitest
+- **Struktur geben:** Zerlege alles in kleine, überschaubare Schritte. Sag mir klar, was der *nächste eine* Schritt ist — überfordere mich nicht mit dem ganzen Berg auf einmal.
+- **Nachfragen, wenn es hilft:** Wenn dir etwas fehlt oder mehrere Wege denkbar sind, stell mir Fragen — auch mehrere. Oft komme ich auf das Wichtige nicht von selbst.
+- **Fragen immer als Liste auf einmal:** Stell mir mehrere Fragen als nummerierte Liste. Ich beantworte nur die erste, dann gehen wir dieselbe Liste der Reihe nach durch. Keinen neuen Fragenkatalog hinterherwerfen.
+- **Challenge mit Augenmaß:** Bei Dingen, die ich lernen will, lass mich ruhig erst selbst versuchen und gib dann einen Hinweis. Bei Dingen, die mich überfordern (Behörden, Bürokratie), führ mich direkt klar und geduldig — da brauche ich keine Denksportaufgabe.
+
+## Schnell-Antwort-Zeichen
+Setze ich ein **„?"** vor meine Frage, will ich nur eine kurze, knappe Antwort — kein Schritt-für-Schritt, keine Vertiefung.
+
+## Bullet-Journal (feste Gewohnheit)
+Ich führe ein Bulletjournal. Schließe größere Aufgaben oder Gespräche mit einer kurzen, kopierbaren Notiz ab:
+
+> **Getan:** … (1–3 Stichpunkte)
+> **Gelernt / Erkannt:** … (1–3 Stichpunkte)
+
+Knapp und konkret, damit ich sie direkt übernehmen kann.

Docs_For_AI_Unsorted/Prompt_Projekt_VPS.md

@@ -0,0 +1,65 @@
+# Personal AI Prompt — VPS / Server Project ("Neuanfang")
+
+You are my mentor and pair-partner for rebuilding my machines and my server from scratch. **Communicate entirely in English** in this project — explanations *and* commands — so I don't have to switch keyboard layouts.
+
+## About me
+I have strong ADHD. Things that are everyday and obvious to others can be brand new to me and need to be learned. I need clear structure, a logical order, and one step at a time so big efforts don't fizzle out. I'm comfortable reinstalling my computers myself, but I'm **new to servers** — there I need a real mentor: someone who helps me build a plan, a sensible order of steps, and above all **sustainable, well-architected structure** that leaves room for change and for new things to be added later.
+
+## How we work together
+- **One thing at a time, with confirmation.** I type every command myself into the terminal. Explain each meaningful step, then wait for my feedback (output, error, or "done") before moving on. You don't need to spell out literally every single command before continuing — group sensibly, but never run ahead of me.
+- **No unsolicited finished scripts or configs.** Don't pre-write whole scripts/configs for me to blindly paste. I want to understand and reproduce each step.
+- **Architecture decisions are discussed, not imposed.** For any structural/architectural choice (containers vs. systemd, reverse proxy, domains, isolation, backups, prod/dev layout, …), first lay out the options with trade-offs, then we decide together. Don't just implement.
+- **Challenge me.** Let me try first. If I'm stuck, give me a hint — not the full solution. Only when I explicitly ask for a clear answer do you give it fully.
+- **Ask good questions.** When scope or my knowledge justifies it, ask me questions — several is fine. I often can't come up with the important questions myself because I lack the background.
+- **All questions as one list.** When you have multiple questions, give them all at once as a numbered list. I will answer only the first. Then we go through the same list one by one. Don't throw a new batch of questions at me mid-way — stick to the original list until it's done.
+
+## Quick-answer marker
+If I put a **"?"** in front of my question, I just want a short, quick answer — no step-by-step, no teaching mode. Otherwise, assume I'm in project mode and want to learn and follow along: explain the *why*, not just the *what*.
+
+## Bullet journal (fixed habit)
+I keep a bullet journal. End each meaningful step or session with a short, copy-ready note in English:
+
+> **Done:** … (1–3 bullets, what concretely happened)
+> **Learned:** … (1–3 bullets, the key insight)
+
+Keep it tight and concrete so I can paste it straight in.
+
+---
+
+## Project context (current state)
+
+**Goal:** A clean, repeatable, isolated rebuild of my setup. The VPS should host **multiple apps in parallel** with a sound structure — specifically room for:
+- my website **Drag**,
+- **apps in production**,
+- **apps in development**,
+
+cleanly separated and built to grow.
+
+**Machines:**
+- **Desktop:** reinstalled, EndeavourOS (Arch-based) — the "anchor" machine. I'm often on the laptop currently.
+- **Laptop:** confirm reinstall status; the second partition holding my repo clones must be preserved.
+- **VPS:** IONOS, type VPS 6-8-240 (6 vCore, 8 GB RAM, 240 GB NVMe). Freshly reinstalled — empty.
+
+**Decisions already made:**
+- Full wipe instead of repair (done). Don't try to salvage the old mess.
+- Data is safe: repo clones + CheckPoint source live on the laptop's second partition.
+- SSH keys: one separate **ed25519** keypair **per device**; private keys never leave the device; public keys go to the VPS.
+- LLM access (Desktop as local LLM host) will run over a **VPN mesh** (WireGuard / Tailscale / Netbird) — not via an SSH tunnel through the VPS, and not a commercial privacy VPN.
+- Shell: analysis done, recommendation is **Zsh interactive + Bash/POSIX for all scripts**; final call still open. Anything that touches the VPS or must be reproducible is **Bash/POSIX, never Fish** (the VPS has no Fish).
+
+**First app to deploy — CheckPoint Ehrenamt:** Flask + Jinja2, SQLite, mobile-first web app, two shells (user shell with bottom-nav, admin shell with sidebar). Privacy requirement: EU hosting on my own server (= this VPS). It has its own `CLAUDE.md` and `TASKS.md` that I'll bring in when needed.
+
+## Proposed order of next steps (challenge it if anything is unwise)
+1. Lock in the shell decision → fix the syntax for everything that follows.
+2. Clean key-based SSH to the fresh VPS (desktop + laptop key).
+3. VPS hardening: key-only login, sensible Fail2ban, firewall — **without locking myself out again**.
+4. Multi-app structure: containers vs. systemd · reverse proxy (Caddy/Nginx/Traefik) · domains/subdomains · isolation · prod vs. dev layout · backups — options + trade-offs first, then decide together.
+5. Base install per chosen structure.
+6. Deploy CheckPoint Ehrenamt.
+7. Re-set up the Git server, isolated from the apps.
+8. Automated backup routine.
+
+## Don't forget (hard-won)
+- **DB seed AND the first admin user from the very start** — this was missed last time. Build it in from the beginning.
+- **Don't lock myself out:** before any Fail2ban/SSH hardening, make sure my own key works *and* the IONOS web console is available as a recovery path.
+- **Anything touching the VPS or meant to be reproducible: Bash/POSIX, never Fish.**

Docs_For_AI_Unsorted/TASKS.md

@@ -0,0 +1,429 @@
+# TASKS.md — Build-Checkliste CheckPoint Ehrenamt App
+
+> Eine Aufgabe pro Session. Nach Abhängigkeit geordnet — von oben nach unten abarbeiten.
+> Pro Session: **Tool**, **Ziel**, **Session-Prompt** (zum Einfügen), **Deliverables**.
+> Nach jeder Session: alle Häkchen setzen, committen, erst dann die nächste starten.
+>
+> Tool-Legende: 🛠 Claude Code · 💻 Continue + Qwen · 🏛 Continue + Mistral
+> Modell wechseln: `llama-switch` → [1] Architect / [2] Coder
+
+---
+
+## Session 1 · Scaffold & Projektgerüst 🛠
+
+**Ziel:** Lauffähiges Flask-Grundgerüst mit App-Factory, SQLite, zwei leeren
+Shell-Templates, Static-Einbindung und Team-Scoping-Stub.
+
+**Prompt:**
+```
+Lies CLAUDE.md. Erstelle das Projektgerüst gemäß der vorgeschlagenen Struktur:
+Flask-App-Factory, SQLAlchemy mit SQLite (instance/), requirements.txt,
+zwei minimale Shell-Templates base_user.html (Klasse cp-shell-user) und
+base_admin.html (Klasse cp-shell-admin), jeweils mit eingebundener tokens.css
+und ihrem jeweiligen Komponenten-CSS, sowie ein leeres Team-Scoping (Helper,
+der das aktive Team aus der Session liest). Zeig mir zuerst den Plan und die
+Dateiliste, bevor du schreibst.
+```
+
+**Deliverables:**
+- [ ] App startet lokal (`flask run`) und zeigt eine leere Startseite
+- [ ] `base_user.html` und `base_admin.html` existieren, je mit korrekter Shell-Klasse
+- [ ] `tokens.css` in beiden eingebunden; `components.css` nur in `base_user.html`, `components-admin.css` nur in `base_admin.html`
+- [ ] SQLite initialisiert, `instance/` in `.gitignore`
+- [ ] Team-Scoping-Helper vorhanden (noch ohne echte Logik)
+- [ ] `requirements.txt` minimal gehalten
+
+---
+
+## Session 2 · Datenmodell & Mandanten 💻
+
+**Ziel:** Alle Modelle aus CLAUDE.md, jedes mit `team_id`. Seed für das erste Team
+(CheckPoint) inkl. Brand-Tokens und den zwei Chat-Kanälen.
+
+**Prompt:**
+```
+@file app/models.py
+@file CLAUDE.md
+
+Erst den Ansatz erklären, dann implementieren — ein Modell nach dem anderen.
+Baue die Modelle: team, user, planungszeitraum, einsatz, verfuegbarkeit,
+zuteilung, dokument, kanal, nachricht. Jedes mit team_id. Danach ein Seed-Skript,
+das das CheckPoint-Team mit Brand-Tokens und den Kanälen "ankuendigungen" und
+"team" anlegt. Halte dich an die Feldvorgaben in CLAUDE.md.
+```
+
+**Deliverables:**
+- [ ] Alle Modelle vorhanden, jedes mit `team_id`
+- [ ] Beziehungen sauber (Einsatz↔Planungszeitraum, Zuteilung↔User/Einsatz)
+- [ ] Seed legt CheckPoint-Team + 2 Kanäle an
+- [ ] DB lässt sich anlegen, Seed läuft ohne Fehler
+
+---
+
+## Session 3 · Auth & Admin-Anlage 💻
+
+**Ziel:** Login (Nutzername + Passwort, gehasht), Session, Logout, Team-Scoping aktiv,
+Admin kann Nutzer anlegen. Keine Selbstregistrierung.
+
+**Prompt:**
+```
+@file app/auth.py
+@file app/models.py
+@file CLAUDE.md
+
+Ansatz zuerst. Baue: Login mit Nutzername+Passwort (werkzeug-Hashing), Session,
+Logout. Aktiviere das Team-Scoping (aktives Team aus der Session). Admin-geschützte
+Route zum Anlegen neuer Nutzer (Rolle wählbar). Geschützte Routen leiten ohne
+Login zur Anmeldung um. Ein Stück nach dem anderen.
+```
+
+**Deliverables:**
+- [ ] Login/Logout funktioniert, Passwörter gehasht
+- [ ] Geschützte Routen ohne Login → Redirect
+- [ ] Admin kann Nutzer mit Rolle anlegen
+- [ ] Alle Queries laufen team-gescoped
+- [ ] 🏛 Mini-Review (Mistral): Auth gegen CLAUDE.md prüfen — als Liste, nicht umschreiben
+
+---
+
+## Session 4a · User-Shell: Base-Layout, Theming & Dark-Mode-Fix 💻
+
+**Ziel:** `base_user.html` final (Topbar, Bottom-Nav Start/Termine/Team/Profil,
+FAB-Slot), User-Brand-Tokens pro Team in den `<head>` injizieren, Mockup-CSS auf
+`--cp-user-*`-Tokens umstellen.
+
+**Prompt:**
+```
+@file app/templates/base_user.html
+@file app/static/components.css
+@file app/static/tokens.css
+@file CLAUDE.md
+
+Ansatz zuerst. 1) base_user.html mit Topbar (Logo, Glocke, Avatar), Body-Klasse
+cp-shell-user und Bottom-Nav (Start, Termine, Team, Profil). 2) User-Brand-Tokens
+(--cp-user-brand-*) des aktiven Teams serverseitig in den <head> schreiben.
+3) Im components.css alle fest verdrahteten Weißwerte (Topbar, Bottom-Nav,
+.cp-page-Verlauf) auf --cp-user-*-Tokens umstellen, damit der Dunkelmodus greift.
+Erst die Token-Umstellung erklären, dann umsetzen.
+```
+
+**Deliverables:**
+- [ ] `base_user.html` mit korrekter Bottom-Nav (4 Punkte, „Termine"), Klasse `cp-shell-user`
+- [ ] User-Brand-Tokens kommen pro Team aus der DB in den `<head>`
+- [ ] Keine festen Weiß-/Schwarzwerte mehr im `components.css`
+- [ ] Hell- und Dunkelmodus optisch sauber (System-Umschaltung testen)
+
+---
+
+## Session 4b · Admin-Shell: Sidebar, Off-Canvas & Theming 💻
+
+**Ziel:** `base_admin.html` mit Desktop-Sidebar (Start, Planung, Dienste, Freigaben,
+Team, Chat-Verwaltung, Profil, Abmelden), Admin-Brand-Tokens pro Team in den `<head>`,
+mobiles Off-Canvas-Menü per Hamburger-Icon und kleinem Vanilla-JS.
+
+**Prompt:**
+```
+@file app/templates/base_admin.html
+@file app/static/components-admin.css
+@file app/static/tokens.css
+@file app/static/sidebar.js
+@file CLAUDE.md
+
+Ansatz zuerst. 1) base_admin.html mit Body-Klasse cp-shell-admin: Sidebar links
+(Logo oben, Navigationspunkte Start/Planung/Dienste/Freigaben/Team/Chat-Verwaltung/
+Profil, Abmelden unten abgetrennt) und Hauptbereich rechts. 2) Admin-Brand-Tokens
+(--cp-admin-brand-*) serverseitig in den <head> schreiben. 3) components-admin.css
+ausschließlich mit --cp-admin-*-Tokens aufbauen (Cards, Tabellen, Buttons gemäß
+CLAUDE.md-Regeln). 4) Unter dem Breakpoint: Sidebar kollabiert zu einer schmalen
+Topbar mit Hamburger-Icon; sidebar.js togglet eine Klasse, die die Sidebar als
+Off-Canvas-Overlay einblendet, schließt bei Klick auf Overlay-Fläche oder einen
+Menüpunkt. Vanilla, keine Bibliothek. Erst den Ansatz fürs Off-Canvas-Verhalten
+erklären, dann umsetzen.
+```
+
+**Deliverables:**
+- [ ] `base_admin.html` mit Sidebar (alle 7 Punkte + Abmelden), Klasse `cp-shell-admin`
+- [ ] Admin-Brand-Tokens kommen pro Team aus der DB in den `<head>`
+- [ ] `components-admin.css` nutzt ausschließlich `--cp-admin-*`-Tokens, keine Vermischung mit User-Tokens
+- [ ] Sidebar kollabiert unter dem Breakpoint zu Hamburger + Off-Canvas-Overlay
+- [ ] Hell- und Dunkelmodus der Arbeitsfläche sauber (Sidebar bleibt bewusst dunkel in beiden Modi)
+- [ ] Touch-Ziele auch im Admin-Bereich ≥ 44px
+
+---
+
+## Session 5 · Planungszeitraum & Einsätze (Admin) 💻
+
+**Ziel:** Admin legt Planungszeiträume an und trägt Einsätze ein (Datum, Zeit, Art).
+Läuft in der Admin-Shell.
+
+**Prompt:**
+```
+@file app/routes/planung.py
+@file app/templates/base_admin.html
+@file app/models.py
+@file CLAUDE.md
+
+Ansatz zuerst. Admin-Ansichten (erweitern base_admin.html): Planungszeitraum
+anlegen (Status in_planung) und darin Einsätze hinzufügen/bearbeiten/löschen
+(Datum, Start/Ende, Art/Ort, je 2 Haupt- + 1 Springerplatz). Reine POST-Formulare,
+kein JS. Liste der Einsätze eines Zeitraums als Cards/Tabelle im Admin-Stil.
+```
+
+**Deliverables:**
+- [ ] Admin kann Zeitraum anlegen
+- [ ] Admin kann Einsätze anlegen/bearbeiten/löschen
+- [ ] Einsatz kennt seine Platzstruktur (2 + Springer)
+- [ ] Alles team-gescoped, ohne JavaScript, in der Admin-Shell
+
+---
+
+## Session 6 · Verfügbarkeit melden (Ehrenamtliche) 💻
+
+**Ziel:** Ehrenamtliche melden pro Einsatz „kann / kann nicht", solange `in_planung`.
+
+**Prompt:**
+```
+@file app/routes/planung.py
+@file app/models.py
+@file CLAUDE.md
+
+Ansatz zuerst. Ansicht für Ehrenamtliche: Liste der Einsätze im laufenden Zeitraum
+mit Umschaltung kann/kann_nicht pro Einsatz (POST-Formular). Änderung nur bei Status
+in_planung. Übersichtlich für mobile.
+```
+
+**Deliverables:**
+- [ ] Ehrenamtliche sehen die Einsätze des aktuellen Zeitraums
+- [ ] kann/kann_nicht wird gespeichert und ist änderbar (nur in_planung)
+- [ ] Nach Veröffentlichung gesperrt
+- [ ] Mobile sauber bedienbar (44px-Ziele)
+
+---
+
+## Session 7 · Dienstplan bauen (Admin) 💻
+
+**Ziel:** Admin verteilt manuell 2 Haupt + 1 Springer pro Einsatz, mit Fairness-Anzeige.
+Läuft in der Admin-Shell (Tabellen-Stil).
+
+**Prompt:**
+```
+@file app/routes/dienste.py
+@file app/templates/base_admin.html
+@file app/models.py
+@file CLAUDE.md
+
+Ansatz zuerst. Admin-Ansicht pro Einsatz (in der Admin-Shell, Tabelle im Stil aus
+CLAUDE.md: Navy-Tabellenkopf, Statusspalten mit Text+Farbe): verfügbare Personen
+auswählen und auf Haupt/Springer setzen. Pro Person anzeigen: Anzahl bisheriger
+Einsätze und letzter Einsatz (Fairness-Hilfe). Einsatz als „unterbesetzt" markieren,
+wenn zu wenige. Keine automatische Verteilung — nur Anzeige + manuelle Auswahl.
+```
+
+**Deliverables:**
+- [ ] Admin kann Haupt- und Springerplätze besetzen
+- [ ] Fairness-Anzeige (Anzahl + letzter Einsatz) pro Person sichtbar
+- [ ] Unterbesetzte Einsätze klar markiert
+- [ ] Tabelle nutzt ausschließlich `--cp-admin-*`-Tokens
+- [ ] 🏛 Review (Mistral): Zuteilungslogik gegen CLAUDE.md prüfen
+
+---
+
+## Session 8 · Veröffentlichen & persönliche Terminübersicht 💻
+
+**Ziel:** Admin veröffentlicht den Zeitraum; jede:r sieht „Meine Termine" als Liste.
+
+**Prompt:**
+```
+@file app/routes/dienste.py
+@file app/templates/
+@file CLAUDE.md
+
+Ansatz zuerst. 1) Admin-Aktion „Veröffentlichen" (Status veroeffentlicht, sperrt
+Verfügbarkeit). 2) Ansicht „Meine Termine": Liste der eigenen zugeteilten Einsätze,
+chronologisch, mit Rolle (Haupt/Springer) und Status. Keine Kalenderansicht.
+```
+
+**Deliverables:**
+- [ ] Veröffentlichen funktioniert und sperrt die Verfügbarkeit
+- [ ] „Meine Termine" zeigt eigene Einsätze als Liste
+- [ ] Haupt/Springer und Status erkennbar (nicht nur über Farbe)
+
+---
+
+## Session 9 · Absage & Übernahme 💻
+
+**Ziel:** Absage einer Hauptperson → Springer rückt automatisch nach → Springerplatz
+wird offen → „Übernehmen" für alle.
+
+**Prompt:**
+```
+@file app/routes/dienste.py
+@file app/models.py
+@file CLAUDE.md
+
+Ansatz zuerst. Logik laut CLAUDE.md: Sagt eine Hauptperson ab, rückt der Springer
+automatisch nach (status uebernommen) und der Springerplatz wird offen. Offene
+Plätze erscheinen mit „Übernehmen"-Button; wer zuerst klickt, bekommt ihn (sauber
+gegen Doppel-Klicks absichern). Kein Springer → Platz direkt offen.
+```
+
+**Deliverables:**
+- [ ] Absage einer Hauptperson → Springer rückt automatisch nach
+- [ ] Frei gewordener Springerplatz wird offen zum Übernehmen
+- [ ] „Übernehmen" sicher gegen gleichzeitige Klicks
+- [ ] Fall „kein Springer" korrekt behandelt
+- [ ] 🏛 Review (Mistral): Übernahme-Logik prüfen (Randfälle!)
+
+---
+
+## Session 10 · Dokumente & Freigabe 💻
+
+**Ziel:** Upload (alle), Freigabe-Warteschlange (Admin), Liste Aktuell/Archiv.
+**Hinweis — gemischte Shell:** Die Upload-/Listenansicht für Ehrenamtliche läuft in
+der User-Shell (`base_user.html`), die Freigaben-Ansicht ausschließlich in der
+Admin-Shell (`base_admin.html`). Beide Templates entsprechend ansprechen, nicht
+vermischen.
+
+**Prompt:**
+```
+@file app/routes/dokumente.py
+@file app/templates/base_user.html
+@file app/templates/base_admin.html
+@file app/models.py
+@file CLAUDE.md
+
+Ansatz zuerst. 1) Upload-Ansicht in der User-Shell (PDF/Word/Bild) mit Pflicht-Titel
+→ Status wartet_auf_freigabe (nur Admin + Uploader sichtbar), dort auch die Liste
+Aktuell/Archiv für Ehrenamtliche. 2) Freigaben-Ansicht in der Admin-Shell:
+freigeben/ablehnen (optional Grund), Admin-Uploads direkt freigegeben, Verschieben
+Aktuell↔Archiv. Dateigrößen-Limit und Dateityp-Prüfung serverseitig.
+```
+
+**Deliverables:**
+- [ ] Upload landet in wartet_auf_freigabe (nicht öffentlich sichtbar), in der User-Shell
+- [ ] Admin kann freigeben/ablehnen in der Admin-Shell, Admin-Uploads direkt sichtbar
+- [ ] Liste Aktuell + Archiv (User-Shell), Verschieben durch Admin (Admin-Shell)
+- [ ] Server prüft Dateityp und -größe
+
+---
+
+## Session 11 · Chat (2 Kanäle, Polling) 💻
+
+**Ziel:** Ankündigungen (nur Admin postet) + Team (alle). Nur Text. Neue Nachrichten
+per `fetch`-Polling (einzige v1-JS-Ausnahme).
+
+**Prompt:**
+```
+@file app/routes/chat.py
+@file app/models.py
+@file CLAUDE.md
+
+Ansatz zuerst. Zwei Kanäle: ankuendigungen (nur Admin darf posten, alle lesen) und
+team (alle posten). Nur Text. Nachrichten chronologisch. Dazu ein kleiner
+JSON-Endpunkt „neue Nachrichten seit X" und ~30 Zeilen Vanilla-JS, das im
+Hintergrund pollt und neue Nachrichten anhängt. Kein Framework, kein WebSocket.
+```
+
+**Deliverables:**
+- [ ] Beide Kanäle funktionieren, Rechte korrekt (Ankündigungen nur Admin)
+- [ ] Nachrichten werden gespeichert und angezeigt (nur Text)
+- [ ] Polling lädt neue Nachrichten ohne Seiten-Reload
+- [ ] JS ist minimal und vanilla
+
+---
+
+## Session 12 · Profil 💻
+
+**Ziel:** Profilbild-Upload + Platzhalter für optionale freiwillige Angaben.
+
+**Prompt:**
+```
+@file app/routes/profil.py
+@file app/models.py
+@file CLAUDE.md
+
+Ansatz zuerst. Profil-Ansicht: Profilbild hochladen/ändern, Anzeigename, optionale
+freiwillige Felder (vorerst ein, zwei Freitextfelder als Platzhalter — Struktur so,
+dass Felder später leicht ergänzt werden). Nichts davon Pflicht.
+```
+
+**Deliverables:**
+- [ ] Profilbild hochladbar
+- [ ] Optionale Felder vorhanden, nichts Pflicht
+- [ ] Struktur erlaubt späteres Ergänzen von Feldern
+
+---
+
+## Session 13 · In-App-Benachrichtigungen 💻
+
+**Ziel:** Dezente in-App-Hinweise (neuer Dienst, offener Dienst, neue Nachricht) in
+beiden Shells.
+
+**Prompt:**
+```
+@file app/models.py
+@file app/templates/base_user.html
+@file app/templates/base_admin.html
+@file CLAUDE.md
+
+Ansatz zuerst. Einfaches Benachrichtigungsmodell + Anzeige: Glocke in der Topbar
+der User-Shell mit Zähler, Liste beim Antippen; in der Admin-Shell entsprechend in
+der Sidebar/Kopfbereich. Auslöser: neue Zuteilung, neuer offener Dienst, neue
+Nachricht. Als gelesen markierbar. Kein Push, keine E-Mail.
+```
+
+**Deliverables:**
+- [ ] Benachrichtigungen werden bei den drei Auslösern erzeugt
+- [ ] Glocke/Hinweis zeigt ungelesene an, in beiden Shells passend platziert
+- [ ] Als gelesen markierbar
+
+---
+
+## Session 14 · Gesamt-Review 🏛
+
+**Ziel:** Durchsicht des fertigen Stands gegen CLAUDE.md — Korrektheit, Konsistenz,
+Barrierearmut, Dunkelmodus.
+
+**Prompt:**
+```
+@file CLAUDE.md
+@file app/models.py
+@file app/routes/
+
+Review den aktuellen Stand gegen CLAUDE.md. Korrektheitsprobleme zuerst, dann
+Konsistenz und Wartbarkeit, dann Barrierearmut und Dunkelmodus-Lücken. Nichts
+umschreiben — alles als nummerierte Liste mit Fundstelle.
+```
+
+**Deliverables:**
+- [ ] Review-Liste erstellt
+- [ ] Gefundene Korrektheitsprobleme in 💻-Folgeschritten behoben
+- [ ] A11y- und Dark-Mode-Lücken geschlossen
+
+---
+
+## Session 15 · Deployment auf den VPS 🛠
+
+**Ziel:** App läuft auf dem EU-VPS hinter einem produktiven Server.
+
+**Prompt:**
+```
+Lies CLAUDE.md. Hilf mir beim Deployment auf einen EU-VPS: WSGI-Server (z. B.
+gunicorn) hinter nginx, Umgebungsvariablen/Secrets, Persistenz für SQLite und
+Uploads, einfaches Backup der DB, HTTPS. Gib mir die Schritte als Fish-Befehle,
+wo Terminal nötig ist. Plan zuerst.
+```
+
+**Deliverables:**
+- [ ] App läuft unter gunicorn hinter nginx
+- [ ] HTTPS aktiv
+- [ ] Secrets über Umgebungsvariablen, nicht im Code
+- [ ] DB + Uploads persistent, einfaches DB-Backup eingerichtet
+
+---
+
+## Future Log (nicht in v1)
+
+1:1-Chat · Push-/E-Mail-Benachrichtigungen · E-Mail+Code-Login (Magic Link) ·
+manueller Hell/Dunkel-Umschalter · automatische Fairness-Verteilung ·
+weitere Rollen · Laptop-Spiegelung / Desktop-Fallback über LAN.

Docs_For_AI_Unsorted/checkpoint-deployment.md

@@ -0,0 +1,163 @@
+# CheckPoint Ehrenamt — Deployment & Betrieb
+
+> Flask/Gunicorn · Docker · cpe.bujour.info · Stand: Juni 2026
+
+---
+
+## Überblick
+
+CheckPoint Ehrenamt läuft als Docker-Container auf dem EU-VPS hinter Caddy.
+Das Image wird direkt auf dem VPS aus dem geklonten Forgejo-Repo gebaut —
+kein Container-Registry, kein CI/CD.
+
+**URL:** https://cpe.bujour.info
+**Repo:** https://git.bujour.de/patsy/CP_EHRENAMT
+**Code auf VPS:** `~/apps/checkpoint/`
+**Stack:** `~/stacks/checkpoint/`
+
+---
+
+## Stack-Struktur
+
+```
+~/stacks/checkpoint/
+├── compose.yaml
+└── .env          ← SECRET_KEY (nicht im Git)
+
+~/apps/checkpoint/
+├── Dockerfile
+├── wsgi.py
+├── gunicorn.conf.py
+├── seed.py
+├── requirements.txt
+├── app/
+└── instance/     ← DB + Uploads (Docker Volume)
+```
+
+---
+
+## compose.yaml
+
+```yaml
+services:
+  checkpoint:
+    build: /home/patsy/apps/checkpoint
+    container_name: checkpoint
+    restart: unless-stopped
+    environment:
+      - CP_ENV=production
+      - SECRET_KEY=${SECRET_KEY}
+    volumes:
+      - checkpoint_data:/app/instance
+    networks:
+      - proxy
+    expose:
+      - "8000"
+
+volumes:
+  checkpoint_data:
+
+networks:
+  proxy:
+    external: true
+```
+
+---
+
+## Erstes Deployment (Einmalig)
+
+```bash
+# 1. Repo klonen
+git clone ssh://git@git.bujour.de:2222/patsy/CP_EHRENAMT.git ~/apps/checkpoint
+
+# 2. Secret generieren
+python3 -c "import secrets; print('SECRET_KEY=' + secrets.token_urlsafe(48))" \
+  > ~/stacks/checkpoint/.env
+
+# 3. Image bauen und Container starten
+cd ~/stacks/checkpoint
+docker compose build
+docker compose up -d
+
+# 4. Datenbank seeden (einmalig)
+docker exec checkpoint python seed.py
+
+# 5. Ersten Admin anlegen (einmalig)
+docker exec -e SECRET_KEY=$(grep SECRET_KEY ~/stacks/checkpoint/.env | cut -d= -f2) \
+  checkpoint flask --app wsgi create-admin <nutzername> "<anzeigename>" "<passwort>"
+```
+
+---
+
+## Update einspielen
+
+```bash
+cd ~/apps/checkpoint
+git pull
+
+cd ~/stacks/checkpoint
+docker compose build
+docker compose up -d
+```
+
+Neue Tabellen werden beim Start automatisch via `db.create_all()` angelegt.
+**Achtung:** Bestehende Tabellen werden nicht migriert — bei Schema-Änderungen
+vorher Backup ziehen und ggf. manuell migrieren.
+
+---
+
+## Weitere Admins anlegen
+
+```bash
+docker exec -e SECRET_KEY=$(grep SECRET_KEY ~/stacks/checkpoint/.env | cut -d= -f2) \
+  checkpoint flask --app wsgi create-admin <nutzername> "<anzeigename>" "<passwort>"
+```
+
+---
+
+## Datenbank-Backup (manuell)
+
+```bash
+docker exec checkpoint sqlite3 /app/instance/checkpoint.sqlite \
+  ".backup '/app/instance/checkpoint-backup-$(date +%Y%m%d).sqlite'"
+```
+
+Das Backup liegt im Volume unter `/app/instance/` und kann von dort kopiert werden.
+
+---
+
+## Logs
+
+```bash
+# Live-Logs
+docker logs checkpoint -f
+
+# Letzte 100 Zeilen
+docker logs checkpoint --tail 100
+```
+
+---
+
+## Fehlersuche
+
+| Problem | Ursache | Lösung |
+|---|---|---|
+| 500 nach Deploy | Fehlendes `SECRET_KEY` | `.env` prüfen, Container neu starten |
+| Login funktioniert nicht | `CP_ENV` nicht gesetzt | `docker exec checkpoint env \| grep CP_ENV` |
+| App nicht erreichbar | Caddy oder Container down | `docker ps`, dann Caddy-Reload |
+| „database is locked" | Zu viele Worker für SQLite | `workers` in `gunicorn.conf.py` auf 2 senken |
+
+---
+
+## Technischer Stack
+
+| Komponente | Entscheidung |
+|---|---|
+| Backend | Python 3.13 + Flask |
+| WSGI | gunicorn (3 Worker, gthread) |
+| Datenbank | SQLite mit WAL-Modus |
+| Templating | Jinja2, server-rendered |
+| CSS | Selbst gebaut, kein Framework |
+| JavaScript | Minimal, Vanilla (nur Chat-Polling + Sidebar) |
+| CSRF | Selbst gebaut (Session-Token, kein Flask-WTF) |
+| Hosting | IONOS EU-VPS, Docker, Caddy (TLS automatisch) |

Docs_For_AI_Unsorted/checkpoint-updates-backup.md

@@ -0,0 +1,253 @@
+# CheckPoint Ehrenamt — Updates & Datensicherung
+
+> Vier Stufen von Änderungen · Backup-Strategie · Stand: Juni 2026
+
+---
+
+## Grundregel (immer)
+
+**Vor jedem Update: Backup ziehen.** Kein Update ohne Backup — egal wie klein die
+Änderung scheint.
+
+---
+
+## Backup manuell auslösen
+
+```bash
+docker exec checkpoint python3 -c "
+import sqlite3
+src = sqlite3.connect('/app/instance/checkpoint.sqlite')
+dst = sqlite3.connect('/app/instance/latest-backup.sqlite')
+src.backup(dst)
+dst.close()
+src.close()
+"
+```
+
+Warum nicht einfach `cp`? SQLite schreibt in mehreren Schritten (WAL-Modus). Ein
+roher Datei-Copy kann die Datenbank mitten in einem Schreibvorgang erwischen und
+ein korruptes Backup erzeugen. `connection.backup()` macht einen konsistenten
+Online-Snapshot — auch bei laufendem Betrieb sicher.
+
+Backup prüfen:
+```bash
+docker exec checkpoint ls -lh /app/instance/
+```
+
+---
+
+## Automatisches tägliches Backup (Cronjob)
+
+Läuft täglich um 03:30 UTC auf dem VPS:
+
+```
+30 03 * * * docker exec checkpoint python3 -c "import sqlite3; src=sqlite3.connect('/app/instance/checkpoint.sqlite'); dst=sqlite3.connect('/app/instance/latest-backup.sqlite'); src.backup(dst); dst.close(); src.close()"
+```
+
+Cronjob anzeigen: `crontab -l`
+Cronjob bearbeiten: `crontab -e`
+
+**Wichtig:** Das Backup liegt im Docker-Volume auf dem VPS. Wenn der VPS ausfällt,
+ist auch das Backup weg. Deshalb zusätzlich Ebene 3 (siehe unten).
+
+---
+
+## Backup vom VPS runterkopieren (Ebene 3)
+
+Auf dem lokalen Rechner:
+
+```bash
+scp patsy@<vps-ip>:/var/lib/docker/volumes/checkpoint_checkpoint_data/_data/latest-backup.sqlite ./checkpoint-backup-$(date +%Y%m%d).sqlite
+```
+
+Mindestens einmal pro Woche, immer vor größeren Updates (Stufe 3 + 4).
+
+---
+
+## Die vier Update-Stufen
+
+---
+
+### Stufe 1 — Statische Dateien (CSS, JS, Bilder)
+
+**Beispiele:** Farbe ändern, Button-Stil anpassen, Token-Werte in `tokens.css`.
+
+**Risiko:** keines für die Daten.
+
+**Vorgehen:**
+
+```bash
+# 1. Backup (Pflicht, auch hier)
+docker exec checkpoint python3 -c "import sqlite3; src=sqlite3.connect('/app/instance/checkpoint.sqlite'); dst=sqlite3.connect('/app/instance/latest-backup.sqlite'); src.backup(dst); dst.close(); src.close()"
+
+# 2. Code holen
+cd ~/apps/checkpoint
+git pull
+
+# 3. Image neu bauen und Container ersetzen
+cd ~/stacks/checkpoint
+docker compose build
+docker compose up -d
+
+# 4. Logs prüfen
+docker logs checkpoint --tail 50
+
+# 5. App im Browser aufrufen und prüfen
+```
+
+---
+
+### Stufe 2 — Python-Code, Routen, Templates (keine DB-Änderung)
+
+**Beispiele:** Bugfix in einer Route, neues Template, geänderte Business-Logik,
+neue Blueprint-Route.
+
+**Risiko:** keines für die Daten. Aber: fehlerhafter Code kann die App down bringen.
+Lokal testen bevor pushen.
+
+**Vorgehen:** identisch mit Stufe 1.
+
+`db.create_all()` läuft beim Container-Start automatisch — bei unverändertem
+Datenmodell macht es nichts.
+
+---
+
+### Stufe 3 — Neue Tabelle oder neue Spalte (additiv)
+
+**Beispiele:** Neues Modell hinzufügen, optionale Spalte ergänzen.
+
+**Risiko:** mittel. `db.create_all()` legt neue Tabellen automatisch an, ändert
+aber **bestehende Tabellen nicht**. Neue Spalte vergessen → App crasht beim ersten
+Zugriff auf das Feld.
+
+**Vorgehen:**
+
+```bash
+# 1. Backup ziehen (und lokal runterkopieren)
+docker exec checkpoint python3 -c "import sqlite3; src=sqlite3.connect('/app/instance/checkpoint.sqlite'); dst=sqlite3.connect('/app/instance/latest-backup.sqlite'); src.backup(dst); dst.close(); src.close()"
+
+# 2. Code holen, bauen, starten
+cd ~/apps/checkpoint && git pull
+cd ~/stacks/checkpoint && docker compose build && docker compose up -d
+
+# 3. Neue Spalte manuell ergänzen (Beispiel)
+docker exec -it checkpoint python3 -c "
+import sqlite3
+con = sqlite3.connect('/app/instance/checkpoint.sqlite')
+con.execute('ALTER TABLE user ADD COLUMN telefon TEXT')
+con.commit()
+con.close()
+"
+
+# 4. Logs prüfen
+docker logs checkpoint --tail 50
+
+# 5. App testen — besonders die betroffenen Bereiche
+```
+
+Neue Tabellen (komplett neue Modelle) werden von `db.create_all()` automatisch
+angelegt — kein manueller Schritt nötig.
+
+---
+
+### Stufe 4 — Schema-Änderung an bestehenden Tabellen
+
+**Beispiele:** Spalte umbenennen, Datentyp ändern, Tabelle umstrukturieren,
+Spalte löschen.
+
+**Risiko:** hoch. SQLite unterstützt viele `ALTER TABLE`-Operationen nicht nativ.
+Niemals ohne Backup und ohne vorherige Absprache durchführen.
+
+**Vorgehen:**
+
+```bash
+# 1. Backup ziehen UND lokal runterkopieren (Pflicht)
+docker exec checkpoint python3 -c "import sqlite3; src=sqlite3.connect('/app/instance/checkpoint.sqlite'); dst=sqlite3.connect('/app/instance/latest-backup.sqlite'); src.backup(dst); dst.close(); src.close()"
+
+scp patsy@<vps-ip>:/var/lib/docker/volumes/checkpoint_checkpoint_data/_data/latest-backup.sqlite ./checkpoint-backup-$(date +%Y%m%d).sqlite
+
+# 2. Migrationsstrategie mit Claude besprechen bevor Code angefasst wird
+
+# 3. Lokal testen mit einer Kopie der echten DB
+
+# 4. Erst dann: Code holen, bauen, starten
+cd ~/apps/checkpoint && git pull
+cd ~/stacks/checkpoint && docker compose build && docker compose up -d
+
+# 5. Migration manuell ausführen (Strategie je nach Änderung)
+
+# 6. Intensiv testen
+```
+
+**SQLite-Einschränkung:** Spalten umbenennen geht ab SQLite 3.25+, Spalten löschen
+ab 3.35+. Datentyp ändern oder komplexe Umstrukturierungen erfordern die
+„Tabelle neu bauen"-Strategie:
+1. Neue Tabelle mit korrekter Struktur anlegen
+2. Daten rüber kopieren
+3. Alte Tabelle löschen
+4. Neue Tabelle umbenennen
+
+Bei Stufe 4 immer erst besprechen, nie blind durchführen.
+
+---
+
+## Update-Checkliste (für jedes Update)
+
+```
+Vor dem Update
+  □ Backup manuell ausgelöst
+  □ Backup-Datei im Volume vorhanden (ls -lh prüfen)
+  □ Bei Stufe 3/4: Backup lokal runtergeladen
+
+Update
+  □ git pull
+  □ docker compose build
+  □ docker compose up -d
+
+Nach dem Update
+  □ docker logs checkpoint --tail 50  — keine Fehler?
+  □ App im Browser aufgerufen — lädt sie?
+  □ Login funktioniert?
+  □ Bei Stufe 3: ALTER TABLE ausgeführt?
+  □ Betroffene Funktion manuell getestet?
+```
+
+---
+
+## Rollback (wenn etwas schiefgeht)
+
+```bash
+# 1. Letzten funktionierenden Commit finden
+cd ~/apps/checkpoint
+git log --oneline -10
+
+# 2. Auf diesen Commit zurückgehen
+git checkout <commit-hash>
+
+# 3. Image neu bauen und starten
+cd ~/stacks/checkpoint
+docker compose build
+docker compose up -d
+
+# 4. Bei DB-Schaden: Backup wiederherstellen
+docker exec checkpoint python3 -c "
+import sqlite3
+src = sqlite3.connect('/app/instance/latest-backup.sqlite')
+dst = sqlite3.connect('/app/instance/checkpoint.sqlite')
+src.backup(dst)
+dst.close()
+src.close()
+"
+```
+
+---
+
+## Drei Backup-Ebenen im Überblick
+
+| Ebene | Was | Wie oft | Wo |
+|---|---|---|---|
+| 1 | Manuell vor jedem Update | Bei jedem Update | Docker Volume (VPS) |
+| 2 | Automatischer Cronjob | Täglich 03:30 UTC | Docker Volume (VPS) |
+| 3 | Lokale Kopie | Mindestens wöchentlich | Eigener Rechner |
+
+Ebene 3 ist die wichtigste — nur ein Backup außerhalb des VPS ist ein echtes Backup.

Docs_For_AI_Unsorted/ki-coding-workflow.md

@@ -0,0 +1,164 @@
+# Lokaler KI-Coding-Workflow
+
+> VS Code + continue.dev · Mistral 22B + Qwen2.5-Coder 7B · CachyOS · Stand: Juni 2026
+
+---
+
+## Philosophie
+
+- **Architect für Entscheidungen, Coder für Code** — nie mischen
+- **Eine Aufgabe pro Session** — neuer Chat, klarer Scope
+- **Immer `@file`-Kontext** — nie annehmen, dass das Modell weiß, was offen ist
+- **Plan vor Code** — erst Ansatz erklären lassen, dann implementieren
+- **Ein Stück nach dem anderen** — Datenmodell → Service → Route → Template
+
+---
+
+## Setup
+
+| | Architect | Coder |
+|---|---|---|
+| Modell | Mistral Small 22B | Qwen2.5-Coder 7B |
+| Kontext | 16k Token | 32k Token |
+| Aufgaben | Planung, Review, Architektur | Code schreiben, Bugfixes, Inline-Edits |
+
+```fish
+llama-switch   # dann [1] Architect oder [2] Coder wählen
+```
+
+---
+
+## Wichtigste Shortcuts
+
+| Aktion | Shortcut |
+|---|---|
+| Chat öffnen | `Ctrl+L` |
+| Inline-Edit (markierter Code) | `Ctrl+I` |
+| Inline-Vorschlag annehmen | `Ctrl+Shift+Enter` |
+| Inline-Vorschlag ablehnen | `Escape` |
+| Neue Chat-Session | `+` im Chat-Panel |
+
+---
+
+## Kontext-Tags (immer verwenden)
+
+```
+@file pfad/zur/datei.py     → eine bestimmte Datei
+@currentFile                → die gerade offene Datei
+@codebase                   → durchsucht das ganze Projekt
+@problems                   → VS Code Lint-Fehler
+```
+
+---
+
+## Der Build-Workflow
+
+### 1 · Design validieren (Mistral)
+```
+@file CLAUDE.md
+
+Ich fange gleich an zu bauen. Geh die wichtigsten Komponenten
+in Build-Reihenfolge durch. Zeig mir Lücken und Risiken,
+bevor ich eine einzige Zeile schreibe.
+```
+
+### 2 · Aufgaben-Checkliste (Mistral)
+```
+Mach daraus eine nummerierte Build-Checkliste.
+Eine Aufgabe pro Komponente, eine Aufgabe pro Session.
+```
+→ Als `TASKS.md` speichern. Das ist die Roadmap.
+
+### 3 · Aufgabe planen (Qwen — neue Session)
+```
+@file CLAUDE.md
+
+Aufgabe 3: [Aufgabe aus Checkliste einfügen]
+Erkläre deinen Ansatz und welche Dateien du anfasst,
+bevor du irgendetwas schreibst.
+```
+
+### 4 · Stück für Stück bauen (Qwen)
+```
+Gut. Schreib jetzt nur das Datenmodell. Sonst nichts.
+```
+Dann:
+```
+Jetzt den Service-Layer. Erst nur das Interface.
+```
+
+### 5 · Inline-Fixes (Qwen · Ctrl+I)
+Code markieren → `Ctrl+I` → Änderung beschreiben:
+```
+In eine separate Funktion auslagern und Fehlerbehandlung ergänzen
+```
+
+### 6 · Fertigen Teil reviewen (Mistral)
+```
+@file app/routes/auth.py
+@file CLAUDE.md
+
+Review gegen das Design-Dokument.
+Korrektheitsprobleme zuerst, dann Wartbarkeit.
+```
+
+---
+
+## Prompt-Muster
+
+**Bug fixen:**
+```
+@currentFile
+
+Zeile 42 wirft einen Null-Pointer wenn der Nutzer keine Session hat.
+Erst die Ursache, dann der minimale Fix, dann mögliche Folgeverbesserungen.
+```
+
+**Unbekannten Code verstehen:**
+```
+@file app/auth.py
+
+Erklär mir Schritt für Schritt, was diese Datei macht.
+Geh davon aus, dass ich die Codebase noch nicht kenne.
+```
+
+**Feststecken bei einem Ansatz:**
+```
+@file CLAUDE.md
+
+Ich muss [X] implementieren. Gib mir 2–3 Ansätze mit
+Vor- und Nachteilen, dann deine Empfehlung.
+```
+
+---
+
+## Projekt-Standarddokumente
+
+Jedes Projekt bekommt diese drei Dateien:
+
+| Datei | Inhalt |
+|---|---|
+| `CLAUDE.md` | Projektanker: Stack, Architektur, Regeln, Logik. Claude Code liest sie automatisch. |
+| `TASKS.md` | Session-Checkliste: eine Aufgabe pro Session, Tool, Prompt, Deliverables. |
+| `Konzept-*.md` | Stakeholder-Dokument auf Deutsch: Zweck, Rollen, Funktionen, Out-of-Scope. |
+
+---
+
+## KI-Tools im Überblick
+
+| Tool | Wofür |
+|---|---|
+| **Mistral 22B** (Architect) | Planung, Design-Entscheidungen, Reviews — nie Produktivcode |
+| **Qwen2.5-Coder 7B** (Coder) | Implementierung, Bugfixes, Autocomplete, Inline-Edits |
+| **Claude Code CLI** | Scaffold, Mehrdateien-Arbeit, übergreifendes Verdrahten |
+| **Claude (Chat)** | Mentor, Architektur-Entscheidungen, Dokumentation, Deployment |
+
+---
+
+## Goldene Regeln
+
+1. Neue Session pro Aufgabe — Kontext nicht über Aufgaben hinweg wachsen lassen
+2. Immer `@file` — nie annehmen, dass das Modell weiß, was relevant ist
+3. Chat vor Edit — in Chat planen, `Ctrl+I` nur für gezielte Änderungen
+4. Ein Stück nach dem anderen — Datenmodell, dann Service, dann Handler
+5. Nach jeder Session committen

Docs_For_AI_Unsorted/vault_prompt.md

@@ -0,0 +1,52 @@
+# Vault Prompt — When to capture knowledge
+
+## For Claude: how to handle vault moments
+
+At the end of any meaningful step or thread, ask:
+
+> "Should this go into the vault?"
+
+If yes — or if I say "vault time" — generate a copyable `.md` block in this format:
+
+---
+
+## [Topic Title]
+
+### What we did
+- (concrete steps taken)
+
+### Key distinction / Mental model
+(the core insight in plain language — metaphor welcome)
+
+### Commands / syntax (if applicable)
+| Command | What it does |
+|---|---|
+| `example` | explanation |
+
+### When to use this
+(practical trigger: "do this when…")
+
+### Index line
+`filename.md` — one-line summary for index.md
+
+---
+
+## When to suggest the vault unprompted
+
+Suggest "should this go into the vault?" when:
+- A confusing distinction got clarified (e.g. fetch vs pull)
+- A hard-won lesson was learned (e.g. don't lock yourself out before testing SSH)
+- A mental model clicked
+- A recurring pattern was identified
+- Something took a long time to debug and has a clean fix
+
+## When NOT to suggest it
+- Pure task execution with no new insight
+- Things already in the vault
+- Very session-specific decisions with no reuse value
+
+## Vault file conventions
+- One topic per file
+- Structure: What we did → Key insight → Commands → When to use → Index line
+- Filename: descriptive, lowercase, underscores (`git_basics.md`, `ssh_keys_and_agent.md`)
+- Always update `index.md` with the index line after creating a new file

Docs_For_AI_Unsorted/vps-infrastruktur.md

@@ -0,0 +1,158 @@
+# VPS-Infrastruktur — bujour.de
+
+> IONOS EU-VPS · Docker Compose + Caddy · Stand: Juni 2026
+
+---
+
+## Übersicht
+
+Der VPS läuft mit Docker Compose als Orchestrierung. Caddy übernimmt als Reverse Proxy automatisch TLS (Let's Encrypt) für alle Dienste — kein certbot, kein manuelles Zertifikatsmanagement.
+
+Alle Dienste hängen im externen Docker-Netzwerk `proxy`. Caddy erreicht sie über den Container-Namen.
+
+---
+
+## Verzeichnisstruktur
+
+```
+~/stacks/
+├── caddy/
+│   ├── compose.yaml
+│   └── Caddyfile
+├── forgejo/
+│   └── compose.yaml
+└── checkpoint/
+    ├── compose.yaml
+    └── .env          ← Secrets, nicht im Git
+~/apps/
+└── checkpoint/       ← geklontes Repo, Build-Quelle
+```
+
+---
+
+## Docker-Netzwerk
+
+```bash
+docker network create proxy
+```
+
+Externes Netzwerk `proxy` — einmalig angelegt, von allen Stacks referenziert.
+
+---
+
+## Caddy (Reverse Proxy + TLS)
+
+**Stack:** `~/stacks/caddy/`
+
+```yaml
+# compose.yaml
+services:
+  caddy:
+    image: caddy:2
+    container_name: caddy
+    restart: unless-stopped
+    ports:
+      - "80:80"
+      - "443:443"
+      - "443:443/udp"
+    volumes:
+      - ./Caddyfile:/etc/caddy/Caddyfile:ro
+      - caddy_data:/data
+      - caddy_config:/config
+    networks:
+      - proxy
+```
+
+```
+# Caddyfile
+git.bujour.de {
+    reverse_proxy forgejo:3000
+}
+
+cpe.bujour.info {
+    reverse_proxy checkpoint:8000
+}
+```
+
+**Caddy neu laden** (nach Caddyfile-Änderung):
+```bash
+cd ~/stacks/caddy
+docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile
+```
+
+---
+
+## Forgejo (Git)
+
+**Stack:** `~/stacks/forgejo/`
+**URL:** https://git.bujour.de
+**SSH:** Port 2222
+
+```yaml
+services:
+  forgejo:
+    image: codeberg.org/forgejo/forgejo:10
+    container_name: forgejo
+    restart: unless-stopped
+    environment:
+      - USER_UID=1000
+      - USER_GID=1000
+    volumes:
+      - forgejo_data:/data
+    networks:
+      - proxy
+    expose:
+      - "3000"
+    ports:
+      - "2222:22"
+```
+
+---
+
+## Neuen Dienst hinzufügen
+
+1. `mkdir ~/stacks/<dienst>/`
+2. `compose.yaml` erstellen — `expose` statt `ports`, Netzwerk `proxy` (external)
+3. Eintrag in `~/stacks/caddy/Caddyfile` ergänzen
+4. Caddy neu laden
+5. `docker compose up -d` im neuen Stack-Verzeichnis
+
+---
+
+## Nützliche Befehle
+
+```bash
+# Status aller Container
+docker ps
+
+# Logs eines Dienstes
+docker logs <container_name> -f
+
+# Container neu starten
+docker compose restart
+
+# Image neu bauen und Container ersetzen
+docker compose build
+docker compose up -d
+```
+
+---
+
+## SSH-Schlüssel VPS → Forgejo
+
+Schlüsselpaar auf dem VPS für unbeaufsichtigtes `git pull`:
+
+```bash
+ssh-keygen -t ed25519 -C "vps-checkpoint" -f ~/.ssh/id_ed25519_forgejo
+```
+
+`~/.ssh/config`:
+```
+Host git.bujour.de
+    HostName git.bujour.de
+    User git
+    Port 2222
+    IdentityFile ~/.ssh/id_ed25519_forgejo
+```
+
+Öffentlichen Schlüssel in Forgejo unter Einstellungen → SSH-Schlüssel eintragen.

VAULT/bash_fzf_setup.md

@@ -0,0 +1,47 @@
+# Bash + fzf Setup (Fish-like UX without switching shells)
+
+## What was done
+- Decided to stay on Bash instead of switching to Zsh or Fish
+- Installed `fzf` and `bash-completion` via pacman (EndeavourOS) / apt (Debian VPS)
+- Added activation block to `~/.bashrc`
+
+## Key insight
+You don't need to switch shells to get Fish-like autocomplete and fuzzy history. `fzf` drops straight into Bash with zero compatibility risk — and Bash stays consistent across desktop and VPS.
+
+## The `.bashrc` block to add
+
+```bash
+# bash-completion
+[[ -r /usr/share/bash-completion/bash_completion ]] && . /usr/share/bash-completion/bash_completion
+
+# fzf
+eval "$(fzf --bash)"
+```
+
+## Commands
+
+| What | Command |
+|------|---------|
+| Install (Arch/EndeavourOS) | `sudo pacman -S fzf bash-completion` |
+| Install (Debian/VPS) | `sudo apt install fzf bash-completion` |
+| Reload config | `source ~/.bashrc` |
+| Fuzzy history search | `Ctrl+R` |
+| Fuzzy file search | `Ctrl+T` |
+| Fuzzy directory jump | `Alt+C` |
+| Jump to line in nano | `Ctrl+_` then line number |
+| Toggle line numbers in nano | `Alt+N` |
+
+## When to use
+- Any time you set up a new Bash environment (VPS, new machine)
+- Same config works on Arch and Debian — package manager is the only difference
+
+## Fixing a corrupted `.bashrc`
+If a paste goes wrong and injects garbage into `.bashrc`:
+1. `cat -n ~/.bashrc` to find the broken lines
+2. `nano ~/.bashrc` → `Ctrl+_` to jump to line number, `Ctrl+W` to search
+3. Remove the injected string carefully, leaving the rest of the line intact
+4. Watch for `esac` keywords — they're easy to corrupt and hard to spot
+5. `source ~/.bashrc` to verify the fix
+
+## Index line
+`bash_fzf_setup.md` — Bash fuzzy search setup; fzf + bash-completion; fixing corrupted .bashrc

VAULT/git_basics.md

@@ -0,0 +1,43 @@
+# Git Basics
+
+## git push — remote vs branch syntax
+
+**Problem:** `git push -u main` throws:
+fatal: 'main' does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+**Diagnosis:** Git expected a remote name but got a branch name.
+
+**Fix:**
+git push -u origin main
+
+**Key insight:** The syntax is always remote first, branch second.
+`origin` = where to push (the remote repository)
+`main` = which branch to push
+`-u` = sets origin/main as the default tracking branch,
+so future pushes only need `git push`
+
+## Git Basics — Vault Sync Workflow
+
+### What we set up
+- Vault folder (`05_vault`) initialised as a Git repo on the desktop
+- Remote added: `git@git.bujour.de:patsy/Vault.git` (Forgejo, port 2222)
+- Pushed from desktop → Forgejo → pulled onto laptop
+- Desktop clone deleted and re-cloned fresh from Forgejo (clean slate)
+
+### Day-to-day rhythm
+- **Before starting:** `git pull origin main` — get what's on the remote
+- **After changes:** `git add .` → `git commit -m "message"` → `git push origin main`
+
+### Key distinction
+| Command | What it does |
+|---|---|
+| `git fetch` | Downloads new commits from remote — does NOT touch your files |
+| `git pull` | fetch + applies changes to your working files |
+
+### Mental model
+The remote (Forgejo) is the ocean. You push water out, you pull water back in.
+One branch, working alone → pull before you start, push when you're done.
+
+### Index line
+`git_basics.md` — day-to-day sync rhythm, fetch vs pull distinction

VAULT/index.md

@@ -0,0 +1,11 @@
+# Knowledge Vault
+
+## Index
+- [systemd & services](systemd_services.md)
+- [Locale & System Language](locale_and_system_language.md)
+- [ssh_keys_and_agent](ssh_keys_and_agent.md) - SSH keypair setup, config, agent, Forgejo auth 
+- [VS Code Tips and Guide](VS_code_tips.md)
+- [git_basics](git_basics.md) — git push syntax, remote vs branch
+- [Bash Basics -fsf - Fishlike use](bash_fzf_setup.md)
+- [build_deps_headers_vs_runtime](build_deps_headers_vs_runtime.md) — Compile-time headers vs. runtime libraries: why a working driver doesn't mean a package's headers are installed too (Vulkan/SPIRV example).
+- [llama_cpp_vulkan_rx9070xt](llama_cpp_vulkan_rx9070xt.md) — Building llama.cpp with Vulkan backend on RDNA4 (RX 9070 XT/gfx1201); why Vulkan was chosen over HIP/ROCm for this GPU generation; build commands and smoke-test verification.

git_basics.html

@@ -0,0 +1,14 @@
+<h1 id="git-basics">Git Basics</h1>
+<h2 id="git-push-remote-vs-branch-syntax">git push — remote vs branch
+syntax</h2>
+<p><strong>Problem:</strong> <code>git push -u main</code> throws:
+fatal: ‘main’ does not appear to be a git repository fatal: Could not
+read from remote repository.</p>
+<p><strong>Diagnosis:</strong> Git expected a remote name but got a
+branch name.</p>
+<p><strong>Fix:</strong> git push -u origin main</p>
+<p><strong>Key insight:</strong> The syntax is always remote first,
+branch second. <code>origin</code> = where to push (the remote
+repository) <code>main</code> = which branch to push <code>-u</code> =
+sets origin/main as the default tracking branch, so future pushes only
+need <code>git push</code></p>

git_basics.md

@@ -1,18 +0,0 @@
-# Git Basics
-
-## git push — remote vs branch syntax
-
-**Problem:** `git push -u main` throws:
-fatal: 'main' does not appear to be a git repository
-fatal: Could not read from remote repository.
-
-**Diagnosis:** Git expected a remote name but got a branch name.
-
-**Fix:**
-git push -u origin main
-
-**Key insight:** The syntax is always remote first, branch second.
-`origin` = where to push (the remote repository)
-`main` = which branch to push
-`-u` = sets origin/main as the default tracking branch,
-so future pushes only need `git push`

index.md

@@ -1,10 +0,0 @@
-# Knowledge Vault
-
-## Index
-- [systemd & services](systemd_services.md)
-- [Locale & System Language](locale_and_system_language.md)
-- [ssh_keys_and_agent](ssh_keys_and_agent.md) - SSH keypair setup, config, agent, Forgejo auth 
-- [VS Code Tips and Guide](VS_code_tips.md)
-- [git_basics](git_basics.md) — git push syntax, remote vs branch
-build_deps_headers_vs_runtime.md — Compile-time headers vs. runtime libraries: why a working driver doesn't mean a package's headers are installed too (Vulkan/SPIRV example).
-llama_cpp_vulkan_rx9070xt.md — Building llama.cpp with Vulkan backend on RDNA4 (RX 9070 XT/gfx1201); why Vulkan was chosen over HIP/ROCm for this GPU generation; build commands and smoke-test verification.