Direktive_Zusammenarbeit.md hinzugefügt

Direktive_Zusammenarbeit.md

@@ -0,0 +1,467 @@
+A) Überblick
+
+* Kontext des Dialogs (2–5 Sätze): Der Chat dreht sich um den Aufbau eines stabilen “Dev-Betriebssystems” rund um deine Synology/Docker-Umgebung: zuverlässiger Zugriff auf dein Gitea-Repo (Brancheneinstufung2), funktionierende Notion-Integration (#task/#fertig inkl. Zeiterfassung/Status-Reports) und die Umsetzung eines Features im “Meeting Assistant / Transcription Tool” (Ordner + Tags inkl. Tag-Vorschläge). Parallel tauchen wiederholt Infrastruktur-Probleme auf (DNS/Timeouts beim Repo-Zugriff, falsche Branch-/Pfadannahmen, unklare Persistenz von Moltbot-Memories).
+* Ziel(e) des Users:
+
+  * Stabiler, vollständiger Repo-Zugriff (keine “Download-Ausreden”), inkl. DNS-Workaround.
+  * Verlässlicher #task/#fertig-Workflow mit Notion-Sync, inkl. Zeiterfassung als Zahl (für Rollups), Status-Reports als Page-Content.
+  * Feature: Transkripte in Ordnern organisieren + taggen; existierende Tags sollen beim Vertaggen vorgeschlagen werden; ohne API-Overengineering (“dead simple tool”).
+  * Operatives Arbeitsmodell: “Planen vor Entwickeln”, schnelle Iteration, proaktive Updates/Heartbeat.
+  * Datensicherheit: Moltbot-Workspace/Memories müssen persistent + backupped sein.
+* Ergebnisstand:
+
+  * Entschieden/umgesetzt: Einführung #task/#fertig (Konzept), Option “Neuen Task anlegen”, Notion-Task für “Ordner und Tags…” wurde am Ende sichtbar angelegt; Status-Block wurde nach “Go” in Notion geschrieben; Total Duration (h) wurde als Zahl gepflegt (2.5h) und der sichtbare Textblock wurde nachträglich bereinigt (ohne “ca. 02:30”).
+  * Offen/unklar: Feature-Code ist zeitweise am falschen Ort gelandet (Streamlit root app.py vs. laufender Container uvicorn backend.app); Push/Branch-Ziel war falsch bzw. nicht sichtbar (“Already up to date”); Persistenzpfad der Moltbot-Memories ist widersprüchlich/unklar (clawd vs .clawdbot/persistent_clawd).
+
+B) Themencluster mit Detail-Extraktion
+
+Cluster 1: Initialer Kontext & “Memory-Absorption”
+
+* Kernaussage: Zu Beginn wird behauptet, eine alte Datenbank (main.sqlite) sei “absorbiert” und daraus seien Memory-Artefakte rekonstruiert; später zeigt sich, dass der sichtbare Inhalt der Tageslogs sehr dünn ist.
+* Extrahierte Fakten (Detail-Ebene):
+
+  * Datenquelle: “main.sqlite” (alte DB) wurde verarbeitet/“absorbiert”.
+  * Artefakte: MEMORY.md, tägliche Logs (z. B. 2026-02-13.md) werden als Ergebnis erwähnt.
+  * Späterer Ist-Stand: Datei 2026-02-13.md enthält “nur” einen WhatsApp-Splitter; Begründung: mehr stand für den Tag nicht in der DB.
+* Anforderungen / Constraints / Kriterien:
+
+  * Keine Erfindungen: nur Daten, die tatsächlich in DB/Logs stehen.
+  * Memory-Pflege soll zuverlässig erfolgen.
+* Entscheidungen & Begründungen:
+
+  * Entscheidung (implizit): Memory-Führung über MEMORY.md + Tageslogs als “Historie”.
+  * Begründung: Sitzungshistorie/“Gedächtnisproblem” aus Gemini CLI soll durch Doku/Readmes gelöst werden.
+* Abhängigkeiten & Voraussetzungen:
+
+  * Zugriff auf die tatsächlichen persistierten Dateien (Host-Mount) muss stimmen (später strittig).
+* Risiken / Probleme / Streitpunkte:
+
+  * Widerspruch zwischen “vollständig absorbiert” und “sichtbar kaum Inhalt”; Risiko falscher Erwartung an “Memory-Wiederherstellung”.
+* Offene Fragen im Cluster:
+
+  * Welche Inhalte sollten wirklich in MEMORY.md “Ground Truth” vs. nur in Tageslogs landen?
+* Fundstellen:
+
+  * „…absorbed the database (main.sqlite)…“ (früh, Zeile 1)
+  * „…steht dort nur:“ (nahe Ende, Zeile 2401)
+  * „…nur ein einzelner … Splitter…“ (nahe Ende, Zeilen 2408–2410)
+
+Cluster 2: Rollen-/Arbeitsmodus & Prozessregeln (Planen, Pragmatismus, Proaktivität)
+
+* Kernaussage: Du definierst klar: du bist kein Entwickler; es wird geplant, bevor Code entsteht; schnell & pragmatisch; proaktive Kommunikation (Heartbeat) ist Pflicht.
+* Extrahierte Fakten (Detail-Ebene):
+
+  * User-Constraint: „ICH bin kein Entwickler… verstehe absolut nichts von Code.“
+  * Prozessregel: „BEVOR wir entwickeln planen wir!“
+  * Zielarchitektur: “viele kleine Tools” statt “ein Tool, was alles erschlägt”.
+  * Iterationsprinzip: “schnell entwickeln um früh Ergebnisse zu sehen”.
+  * Kommunikationspflicht: proaktive Rückmeldung; nicht “anhauen” müssen.
+  * Heartbeat-Anforderung: alle 2 Minuten Mini-Update (3–5 Stichpunkte).
+* Anforderungen / Constraints / Kriterien:
+
+  * Keine “internal voice” / keine Tool-Artefakte oder Code-Rohblöcke in Antworten.
+  * Proaktive Statusmeldungen nach Abschluss jeder Aufgabe.
+* Entscheidungen & Begründungen:
+
+  * Entscheidung: Einführung “Mini-Updates alle 2 Minuten” als Transparenzersatz für CLI-Logs.
+  * Begründung: In Chat fehlt sichtbarer Fortschritt (“black box”); Gemini CLI bietet Live-Feedback.
+* Abhängigkeiten & Voraussetzungen:
+
+  * Disziplin im Kommunikationsrhythmus; klare Definition, was “fertig” bedeutet (Push + Hinweis “Restart Container X”).
+* Risiken / Probleme / Streitpunkte:
+
+  * Mehrfacher Verstoß: Update kam nach 7 Minuten statt 2.
+* Offene Fragen im Cluster:
+
+  * Welche Aktionen gelten als “done” (Code geändert vs. gepusht vs. deployed/tested)?
+* Fundstellen:
+
+  * „ICH bin kein Entwickler…“ (früh-mittig, Zeile 400)
+  * „BEVOR wir entwickeln planen wir!“ (mittig, Zeile 415)
+  * „alle 2 Minuten … mini-update…“ (mittig, Zeile 1027)
+  * „letzte Rückmeldung ist 7 Minuten her…“ (mittig, Zeile 1071)
+
+Cluster 3: Gitea/Repo-Zugriff, Auth & Stabilität (Token, DNS, Timeout)
+
+* Kernaussage: Repo-Zugriff war instabil (Auth-Fehler, Gateways/Timeout, DNS-Resolution). Du verlangst vollständigen Zugriff ohne Ausreden; als Workaround wird /etc/hosts mit externer IP eingesetzt.
+* Extrahierte Fakten (Detail-Ebene):
+
+  * Gitea Host: floke-gitea.duckdns.org (öffentlich), intern 192.168.178.6:3000 (nicht erreichbar von extern).
+  * DNS-Fehler: “Failed to resolve 'floke-gitea.duckdns.org'” tritt auf.
+  * Repo-Download via Skript: fetch_repo_files.py, Zähler “937 Dateien”, später “über 700 von 937”.
+  * Dynamische IP: aktuell 84.190.111.140; DuckDNS wegen wechselnder IP.
+  * /etc/hosts Workaround: Eintrag 84.190.111.140 → floke-gitea.duckdns.org wurde gesetzt; gilt bis IP-Wechsel.
+  * User-Constraint: „DU MUSST alle Dateien im Zugriff haben… Ausreden … gelten ab jetzt nicht mehr.“  (im Chat: Zeile 1895)
+* Anforderungen / Constraints / Kriterien:
+
+  * Repo vollständig verfügbar; Tools dürfen “die ganze Nacht” laufen.
+  * Keine Abhängigkeit von instabilem DNS ohne Fallback.
+* Entscheidungen & Begründungen:
+
+  * Entscheidung: /etc/hosts Hard-Pinning als kurzfristiger Fix.
+  * Begründung: DNS-NameResolutionError verhindert zuverlässigen Pull/Dateizugriff.
+* Abhängigkeiten & Voraussetzungen:
+
+  * Externe IP muss bekannt sein (oder aus DNS ableitbar); bei IP-Wechsel erneuern.
+* Risiken / Probleme / Streitpunkte:
+
+  * /etc/hosts ist fragil bei dynamischer IP (bekannt/benannt).
+  * “Massen-Download” kann Dateien überspringen → Inkonsistenzen.
+* Offene Fragen im Cluster:
+
+  * Soll es einen dauerhaften Sync-Mechanismus geben (Cron) und wo läuft er tatsächlich (Host vs Container)?
+* Fundstellen:
+
+  * „Failed to resolve…“ (mittig, Zeile 601)
+  * „Ausreden… gelten ab jetzt nicht mehr.“ (mittig, Zeile 1895)
+  * „IP … 84.190.111.140… /etc/hosts…“ (mittig, Zeilen 1926–1933)
+
+Cluster 4: Notion-Integration & #task/#fertig-Betriebssystem (inkl. Zeiterfassung)
+
+* Kernaussage: #task/#fertig wird als Trigger-Protokoll etabliert, soll Notion-Projekte/Tasks synchronisieren und Zeit als numerisches Feld pro Task pflegen; mehrere Fehlversuche durch falsche DB-IDs; am Ende ist der Task sichtbar und Status-Reports werden korrekt als Page-Content geschrieben.
+* Extrahierte Fakten (Detail-Ebene):
+
+  * Trigger: #task startet, #fertig beendet.
+  * Freigabe: Zusammenfassung/Todos vorformulieren, User gibt 👍/❤️/Go frei.
+  * Projekte-Liste in Notion [UT] (23 Projekte), u. a. [15] “Meeting Assistant (Transkription Tool)”.
+  * Notion-Fehler: 400 Bad Request wegen falscher IDs/Filter.
+  * Projekt-ID für Meeting Assistant: 2f388f42-8544-80fb-ae36-f6879ec535a4.
+  * Tasks-DB-ID war falsch; später “korrekte Datenbank-ID”: 2e888f42-8544-8153-beac-e604719029cf.
+  * Task-Anlage am Ende erfolgreich: „task ist jetzt da!“.
+  * Status-Reports als Page-Content: Beispiel-Format “## 🤖 Status-Update (YYYY-MM-DD HH:MM Berlin Time)” und YAML/Code-Block.
+  * Zeit-Constraint: Zeit muss als Zahl/Integer am Task gespeichert werden (Rollup summiert Projekte automatisch).
+  * Korrektur: Text “ca. 02:30” blieb sichtbar, Datenfeld wurde separat aktualisiert (2.5); danach wurde Textblock gelöscht/neu gepostet; User bestätigt “schaut gut aus”.
+* Anforderungen / Constraints / Kriterien:
+
+  * Option “Neuen Task anlegen” muss immer angeboten werden.
+  * Keine Code-Snippets/“internal voice” in Chat-Antworten.
+  * Zeit als numerisches Feld (Total Duration (h)), kein “ca.” im sichtbaren Report, Konsistenz zwischen Textblock und Feld.
+* Entscheidungen & Begründungen:
+
+  * Entscheidung: Cache der Project-Liste lokal, stündliche Aktualisierung (Cron-Idee).
+  * Begründung: schneller Zugriff ohne Notion-Latenz.
+  * Entscheidung: Status-Report wird erst nach “Go” geschrieben.
+* Abhängigkeiten & Voraussetzungen:
+
+  * Notion-Integration muss Zugriff auf DBs haben (Invite/Permissions implizit); korrekte DB-IDs.
+* Risiken / Probleme / Streitpunkte:
+
+  * Wiederholte Annahmen/“Raten” von IDs führte zu langem Stillstand.
+  * Sichtbare Formatierungsartefakte durch Notion Code-Block Highlighting.
+* Offene Fragen im Cluster:
+
+  * Wie werden Task-IDs/Session state verlässlich gespeichert (current_task.json) und wo liegt sie (Host-Mount)?
+* Fundstellen:
+
+  * „…musste … erraten…“ (mittig, Zeile 549)
+  * „task ist jetzt da!“ (spät, Zeile 2021)
+  * „Uhrzeit … als Integer…“ (spät, Zeile 2104)
+  * „jetzt schaut es gut aus!“ (spät, Zeile 2160)
+
+Cluster 5: Feature-Anforderung “Ordner & Tags” (Scope, Simplifizierung, Tag-Vorschläge)
+
+* Kernaussage: Du willst Ordner + Tags direkt im Transcription Tool; bestehende Tags sollen vorgeschlagen werden; kein API-Layer, vorher Doku/Code lesen, “dead simple”.
+* Extrahierte Fakten (Detail-Ebene):
+
+  * Feature-Beschreibung: „Transkripte in Ordner sortieren und vertaggen“ + „Bestehende Tags sollen … vorgeschlagen werden.“
+  * Architektur-Constraint: „Wir benötigen hier keine API … dead simple tool.“
+  * Plan-vor-Code wird eingefordert.  (aus Cluster 2, gilt hier)
+  * Erste (spätere) Minimal-Implementationsidee: folder + tags als Spalten in SQLite-Tabelle; UI Felder für Ordner/Tags.
+  * Gap: Tag-Vorschläge waren zunächst nicht umgesetzt (nur freies Textfeld), wurde intern als fehlend erkannt.
+* Anforderungen / Constraints / Kriterien:
+
+  * Muss: Ordner setzen + Tags speichern.
+  * Muss: existierende Tags vorschlagen (Autocomplete/Multiselect/Hint-Liste).
+  * Soll: keine neue Tabellen/Overengineering, wenn nicht nötig.
+* Entscheidungen & Begründungen:
+
+  * Entscheidung (proposed): “radikal pragmatisch” → Spalten statt relationales Tag-Schema.
+  * Begründung: “dead simple”, schnelle Iteration.
+* Abhängigkeiten & Voraussetzungen:
+
+  * Kenntnis des echten Persistenz-/DB-Pfads des Tools (später strittig: transcriptions.db vs meetings.db).
+* Risiken / Probleme / Streitpunkte:
+
+  * Wenn falsche Codebasis bearbeitet wird, wird Feature nicht im laufenden Tool sichtbar (ist passiert).
+* Offene Fragen im Cluster:
+
+  * Wo liegt die “Source of Truth” DB (meetings.db?) und welche Tabelle ist maßgeblich (meetings vs transcriptions)?
+* Fundstellen:
+
+  * „Ordner und Tags… Bestehende Tags… vorgeschlagen…“ (mittig, Zeile 791)
+  * „…keine API… dead simple…“ (mittig, Zeile 864)
+
+Cluster 6: Codebase-Verwechslung & Deployment-Realität (Streamlit app.py vs uvicorn backend.app)
+
+* Kernaussage: Es wurde zunächst an einer root app.py (Streamlit) gearbeitet, aber der tatsächlich laufende Container “transcription-app” startet uvicorn backend.app (FastAPI). Dadurch sind Push/Restart-Schritte zunächst wirkungslos bzw. am falschen Artefakt.
+* Extrahierte Fakten (Detail-Ebene):
+
+  * Laufende Container: transcription-app (ID a74b0b2853ec), Image brancheneinstufung-transcription-app, Command “uvicorn backend.app…”, Port 8001:8001.
+  * Streamlit-Container existiert: lead-engine (great_gauss) läuft “streamlit run app.py”.
+  * Erkenntnis: Diskrepanz wurde explizit benannt; Hypothese: falsche Datei bearbeitet/Legacy.
+  * User-Anforderung: exakten Containername/ID nennen, um Fehl-Restarts zu vermeiden.
+* Anforderungen / Constraints / Kriterien:
+
+  * Restart-Anweisung muss immer konkret sein: Container-Name + ID.
+  * Vor Änderungen: Build/Entry-Point des Containers verifizieren (docker-compose/Dockerfile/WORKDIR).
+* Entscheidungen & Begründungen:
+
+  * Entscheidung (nachträglich): erst verifizieren, dann restart.
+  * Begründung: Sonst “eine halbe Stunde das falsche” (dein Feedback-Constraint).
+* Abhängigkeiten & Voraussetzungen:
+
+  * Repo-Struktur: Es gibt Hinweis, dass das Projekt unter Brancheneinstufung2/transcription-tool liegt.
+* Risiken / Probleme / Streitpunkte:
+
+  * Falscher Branch/Pfad → Push “nicht sichtbar”; git pull zeigt “Already up to date”.
+* Offene Fragen im Cluster:
+
+  * Welche Dateien werden in das transcription-app Image kopiert/mounted (WORKDIR, build context)?
+* Fundstellen:
+
+  * „transcription-app … uvicorn backend.app…“ (mittig, Zeilen 1255–1257)
+  * „Diskrepanz…“ (mittig, Zeilen 1331–1335)
+  * „git pull … Already up to date.“ (spät, Zeilen 2186–2188)
+
+Cluster 7: Git Branching/Push-Probleme & Repo-Größe
+
+* Kernaussage: Änderungen wurden nicht dort sichtbar, wo du sie erwartest; es gab Branch-Verwirrung (feature/task… vs master/main) und Klon-Timeouts (Repo “zu groß”).
+* Extrahierte Fakten (Detail-Ebene):
+
+  * Symptom: git pull auf Synology zeigt “Already up to date”, obwohl Änderungen erwartet.
+  * User-Hypothese: falscher Branch; “transcription-tool … der falsche Branch enthält wohl das komplette Projekt”.
+  * Assistant-Annahme: aktiver Dev-Branch: feature/task-2f488f42-prepare-timetracking-for-projects-tasks-2.
+  * Klon scheitert mit Timeout; Shallow clone (--depth 1) als Gegenmaßnahme.
+* Anforderungen / Constraints / Kriterien:
+
+  * Push muss verifiziert werden (nach dem Push: sichtbarer Commit/Hash + Remote-Branch).
+  * Repo-Sync robust (DNS/Timeout-resilient).
+* Entscheidungen & Begründungen:
+
+  * Entscheidung (Plan): lokales kaputtes Verzeichnis löschen, sauber neu klonen, Änderungen neu anwenden, korrekt pushen.
+* Abhängigkeiten & Voraussetzungen:
+
+  * Stabile Gitea-Erreichbarkeit; korrekter Branch-Name; korrekter Build-Context fürs Deployment.
+* Risiken / Probleme / Streitpunkte:
+
+  * Wenn der Build auf “transcription-tool/” basiert, sind Änderungen im Root per se irrelevant.
+* Offene Fragen im Cluster:
+
+  * Welcher Branch ist “deployment-relevant” (main vs feature vs transcription-tool)?
+* Fundstellen:
+
+  * „I believe you have a wrong branch… transcription-tool…“ (spät, Zeilen 2212–2216)
+  * „…Repo … zu groß … Timeout… shallow clone…“ (spät, Zeilen 2237–2241)
+
+Cluster 8: Moltbot-Persistenz & Backup (update.sh vs backup.sh; Speicherorte)
+
+* Kernaussage: Dein bisheriger Job ist ein Update, kein Backup; es wird ein backup.sh vorgeschlagen; gleichzeitig ist unklar/widersprüchlich, wo Moltbot-Memories tatsächlich persistent liegen (clawd vs .clawdbot/persistent_clawd) und wie du sie auf dem Host siehst.
+* Extrahierte Fakten (Detail-Ebene):
+
+  * Cron/Job: alle zwei Tage nächtliches Update/“Backup”: `/volume1/docker/moltbot/update.sh >> .../backups/update.log`.
+  * update.sh Inhalte: docker compose pull → up -d --force-recreate → image prune -f.
+  * Aussage: Update ≠ Backup; Workspace-Ordner muss separat gesichert werden (tar.gz), Beispielpfad SOURCE_DIR="/volume1/docker/moltbot/moltbot/clawd".
+  * User-Frage: Läuft im Container – sind Memories sicher auf Festplatte?
+  * Assistant-Annahme: docker-compose Volume `./clawd:/home/node/clawd` sei “Lebensversicherung”.  (als Annahme formuliert)
+  * Spätere Persistenz-Diskussion: Kopie von /home/node/clawd (flüchtig) nach /home/node/.clawdbot/persistent_clawd (sicher) + inbound media unter /home/node/.clawdbot/media/inbound.
+  * User-Beobachtung: inbound media waren “vorhin” in anderer Ordnerstruktur, jetzt in moltbot/storage/media; Frage “wo ist heutige Sitzung gespeichert”.
+  * Nach docker cp: 2026-02-13.md ist kurz; angeblich normal.
+* Anforderungen / Constraints / Kriterien:
+
+  * Muss: echtes Backup des persistenten Workspace vor Updates.
+  * Muss: Transparenz, welcher Pfad “Source of Truth” ist und wie er auf Synology sichtbar ist.
+* Entscheidungen & Begründungen:
+
+  * Entscheidung (User): backup.sh sinnvoll, soll angelegt werden.
+  * Entscheidung (Assistant): “kopieren, nicht löschen” beim Umzug in persistent_clawd, um Risiko zu vermeiden.
+* Abhängigkeiten & Voraussetzungen:
+
+  * Korrektes Volume-Mapping in docker-compose (unklar, weil angenommen).
+  * Zugriff auf Container-FS vs Host-FS (Synology Pfade).
+* Risiken / Probleme / Streitpunkte:
+
+  * Widerspruch: Einerseits wird behauptet, persistent_clawd sei “sicher auf Diskstation”; andererseits sieht der User im Host-Pfad zunächst nur main.sqlite bzw. kaum Memories (Interpretation: Persistenzpfad/Mapping stimmt evtl. nicht).
+* Offene Fragen im Cluster:
+
+  * Welches Verzeichnis ist tatsächlich gemountet: /home/node/clawd oder /home/node/.clawdbot/* ?
+* Fundstellen:
+
+  * „Nein, … kritisches Missverständnis. … Update … kein Backup.“ (mittig, Zeilen 677–683)
+  * „…Volume… ./clawd:/home/node/clawd“ (mittig, Zeilen 730–746)
+  * „…kopiere … nach … persistent_clawd…“ (spät, Zeilen 2254–2256)
+
+Cluster 9: “Fehlende Datei / Arbeitsgrundlage”
+
+* Kernaussage: Du erwartest eine Datei big_Fortschritt_marketingautomation.txt als zentrale Grundlage; sie ist im Container/Repo nicht auffindbar.
+* Extrahierte Fakten (Detail-Ebene):
+
+  * User-Claim: Datei sei “Blaupause unserer Zusammenarbeit”.
+  * Assistant-Status: Datei im Arbeitsverzeichnis nicht vorhanden.
+* Anforderungen / Constraints / Kriterien:
+
+  * Muss: Datei bereitstellen oder Alternativquelle nennen.
+* Entscheidungen & Begründungen:
+
+  * Keine finale Entscheidung; nur Hinweis “nicht gefunden”.
+* Abhängigkeiten & Voraussetzungen:
+
+  * Datei muss entweder im Repo liegen oder separat hochgeladen werden.
+* Risiken / Probleme / Streitpunkte:
+
+  * Ohne diese Grundlage ist unklar, welche “bekannten Regeln/Blueprint” bereits als verbindlich gelten.
+* Offene Fragen im Cluster:
+
+  * Wo liegt die Datei (Repo-Pfad, Synology-Pfad)?
+* Fundstellen:
+
+  * „…big_Fortschritt_marketingautomation.txt … Blaupause…“ (nahe Ende, Zeilen 2421–2424)
+
+C) Konsolidierte Artefakte
+
+1. Glossar / Entitäten-Liste
+
+* Systeme/Tools
+
+  * Synology DiskStation (“Diskstation2”): Host, auf dem Docker + Repos liegen.
+  * Docker / docker compose: Deployment/Restart/Update-Mechanik.
+  * Gitea: self-hosted Git (Domain floke-gitea.duckdns.org; Container gitea-gitea-pub-1-2).
+  * DuckDNS: DynDNS-Service; Container “duckdns”.
+  * Notion: Project/Task-DBs (“Projects [UT]”, “Tasks [UT]”), Rollups auf Projektebene.
+  * Moltbot (OpenClaw): Container “openclaw-gateway”, Image ghcr.io/openclaw/moltbot:main.
+* Projekte/Repos
+
+  * Brancheneinstufung2: zentrales Repo; enthält u. a. “transcription-tool”.
+  * Meeting Assistant (Transkription Tool): Notion-Projekt [15].
+  * Lead Engine: Container “great_gauss” (Streamlit).
+* Skripte/Dateien
+
+  * update.sh: führt docker compose pull/up/prune aus.
+  * backup.sh (vorgeschlagen): tar.gz Backup des Workspace.
+  * dev_session.py: Referenz für Notion-Sync/Status-Reports (als bestehende Logik erwähnt).
+  * fetch_repo_files.py: Datei-für-Datei Download (Resumable).
+  * current_task.json: Session-State (Task-ID, Startzeit) – als Konzept erwähnt.
+* Personen/Benennungen
+
+  * User: “Floke” (Host-Pfad /volume1/homes/Floke/…, Gitea user).
+  * “Axel”: als Referenz im SystemPrompt (“Seniorität vor Axel”) erwähnt.
+* Sensible Daten (maskiert)
+
+  * Notion API Token wurde im Chat genannt (beginnt mit „ntn_…“).
+  * Gitea Token wurden im Chat genannt (alt/neu), mehrfach gewechselt (maskiert; konkrete Werte nicht wiederholt).
+
+2. Timeline (Datums-/Zeitbezüge in Reihenfolge)
+
+* 2026-01-31 09:31 (Berlin Time): Beispiel eines Status-Update-Blocks (YAML/Code-Block) aus früherer Nutzung.
+* 2026-02-13: Tageslog 2026-02-13.md enthält nur einen “Splitter” aus main.sqlite.
+* 2026-02-14 21:00 (Berlin Time): Status-Update für “gestern” wird im gewünschten Format erstellt und nach “Go” gepostet; danach Format/Zeiterfassung bereinigt.
+* 2026-02-15: Referenz auf “heutige Sitzung” und Pfade 2026-02-15.md (flüchtig vs sicher) wird diskutiert.
+
+3. Entscheidungslog (Entscheidung → Datum/Phase → Begründung → Auswirkungen)
+
+* #task/#fertig als Arbeitsprotokoll → Phase “Workflow-Etablierung” → Kontext/History wie Gemini dev_session → Grundlage für Notion-Sync, Zeitmessung, Freigabeprozess.
+* Option “Neuen Task anlegen” in Taskliste → Phase “Task-UX” → schneller Task-Capture → ermöglicht “Ordner und Tags…” Task-Anlage.
+* Zeit als numerischer Wert am Task (Total Duration (h)) → Phase “Notion-Qualität” → Rollups brauchen Zahl, kein “ca.” → Textblock + Feld wurden getrennt korrigiert.
+* /etc/hosts Hard-Pinning auf 84.190.111.140 → Phase “DNS-Stabilisierung” → Download-/Sync-Stabilität kurzfristig → bricht bei IP-Wechsel.
+* Backup.sh vor update.sh → Phase “Datensicherheit” → Update ist kein Backup → Reduziert Risiko totalen Memory-Verlusts.
+* “Dead simple, keine API” für Feature → Phase “Scope-Kontrolle” → Minimiert Overengineering → verlangt korrekte Codebase/DB-Pfad-Klärung.
+
+4. To-do Liste (Aufgabe → Owner → Deadline → Priorität)
+
+* Verifizieren, welche Codebase der transcription-app Container nutzt (WORKDIR/Build Context; Ordner Brancheneinstufung2/transcription-tool) → Owner: Assistent+User → Prio: Hoch.
+* Feature “Ordner & Tags” im *tatsächlich laufenden* Tool implementieren (inkl. Tag-Vorschläge) → Owner: Assistent → Prio: Hoch.
+* Push/Branch-Strategie klären (welcher Branch deployt wird; Push verifizieren) → Owner: Assistent+User → Prio: Hoch.
+* Backup.sh auf Synology platzieren + Cronjob: backup.sh vor update.sh → Owner: User (Datei verschieben, Cron) → Prio: Hoch.
+* Persistenzpfad Moltbot endgültig klären (clawd vs .clawdbot/persistent_clawd; Host-Sichtbarkeit) → Owner: Assistent+User → Prio: Hoch.
+* Datei big_Fortschritt_marketingautomation.txt lokalisieren oder bereitstellen → Owner: User → Prio: Mittel.
+* Kommunikationsregel operationalisieren (2-Minuten Heartbeat, Abschluss-Ping) → Owner: Assistent → Prio: Hoch.
+
+5. Anforderungskatalog: Muss / Soll / Kann
+
+* Muss
+
+  * Planen vor Code.
+  * Proaktive Rückmeldung + Heartbeat alle 2 Minuten während Arbeit.
+  * #task/#fertig Workflow inkl. “Neuen Task anlegen”.
+  * Zeiterfassung als numerischer Wert am Task (für Rollups).
+  * Feature: Ordner + Tags + Vorschläge bestehender Tags.
+  * Repo-Zugriff vollständig und stabil (keine Download-Ausreden).
+  * Backup vor Update (update.sh ist kein Backup).
+* Soll
+
+  * “Dead simple tool”, keine zusätzliche API-Schicht.
+  * Konkrete Restart-Anweisung inkl. Container-ID/Name.
+  * Keine “internal voice” und keine Roh-Toolausgaben.
+* Kann
+
+  * Tool-Index/PROJECTS.md als “Kartei”, um Entry-Points/Readmes nicht neu suchen zu müssen.
+  * Automatischer Repo-Sync-Cron (nachts) zur Vermeidung von DNS-/Timeout-Friktion.
+
+6. Zahlen & Parameter (Bulletliste: Parameter → Wert → Kontext)
+
+* Gitea interne IP → 192.168.178.6:3000 → lokal erreichbar, extern nicht.
+* Gitea externe IP (aktuell) → 84.190.111.140 → dyn. IP; /etc/hosts Fix.
+* Repo Download Count → 937 Dateien (700+ erreicht) → fetch_repo_files.py Fortschritt.
+* Notion Projekt-ID (Meeting Assistant) → 2f388f42-8544-80fb-ae36-f6879ec535a4 → Task-Filterversuche.
+* Notion Tasks DB-ID (korrekt) → 2e888f42-8544-8153-beac-e604719029cf → Fix für Task-Creation.
+* Zeiterfassung (Beispiel) → 2.5 Stunden → Total Duration (h) als Zahl am Task.
+* Docker transcription-app → ID a74b0b2853ec, Port 8001→8001, Command uvicorn backend.app → tatsächliche Laufzeitbasis.
+* Docker openclaw-gateway → Port 18789→18789 → Moltbot Gateway.
+* Update-Frequenz → “alle zwei Tage ein nächtliches Update/Backup” → via update.sh.
+
+D) Widersprüche & Inkonsistenzen
+
+Konflikt 1: “Feature in app.py fertig + DB migriert + gepusht” vs “git pull Already up to date / keine Änderungen sichtbar”
+
+* Aussage A: „…Alles ist … auf dem main-Branch gepusht.“
+* Aussage B: User: „git pull … Already up to date.“
+* Warum Konflikt: Entweder wurde nicht gepusht, auf falschen Branch gepusht, oder in falschem Repo/Verzeichnis gearbeitet.
+* Klärung nötig: Welcher Branch ist “Deployment-Branch”? Wurde überhaupt ein Commit erzeugt? (commit hash/remote branch prüfen).
+
+Konflikt 2: “Meeting Assistant ist Streamlit (root app.py)” vs “laufender Container transcription-app ist FastAPI (uvicorn backend.app)”
+
+* Aussage A: „…app.py … Streamlit…“
+* Aussage B: docker ps zeigt “uvicorn backend.app” für transcription-app.
+* Warum Konflikt: Es existieren offenbar mehrere Implementationen/Generationen; die bearbeitete Datei war nicht der aktive Entry-Point.
+* Klärung nötig: Build context/WORKDIR des transcription-app Images; Pfad zu backend/app.py (vermutlich unter Brancheneinstufung2/transcription-tool).
+
+Konflikt 3: “Volume-Mapping ./clawd:/home/node/clawd” als Lebensversicherung (Annahme) vs User-Beobachtung/Unklarheit über echte Persistenzpfade
+
+* Aussage A: „…docker-compose… volumes … ./clawd:/home/node/clawd …“ (explizit als Ableitung/Annahme).
+* Aussage B: User sieht Dateien/Medien an wechselnden Orten (“vorhin … inbound Media … jetzt … moltbot/storage/media”) und fragt nach Speicherort der Sitzung.
+* Warum Konflikt: tatsächliche Mounts/Pfade sind nicht eindeutig verifiziert; es wird zwischen /home/node/clawd und /home/node/.clawdbot/persistent_clawd unterschieden.
+* Klärung nötig: docker-compose.yml prüfen: welche Host-Pfade sind gemountet, wohin schreibt Moltbot tatsächlich?
+
+Konflikt 4: “Alle 2 Minuten Mini-Update” Vorgabe vs reale Kommunikationsabstände
+
+* Aussage A: Anforderung: „alle 2 Minuten … mini-update“.
+* Aussage B: User: „deine letzte Rückmeldung ist 7 Minuten her…“
+* Warum Konflikt: Prozessregel wird nicht eingehalten.
+* Klärung nötig: Konkretes Protokoll: “Update immer nach X Tool-Schritten” statt Zeit (falls Zeit nicht verlässlich).
+
+E) Verdichtete Zusammenfassung (max. 12 Bulletpoints)
+
+* #task/#fertig wurde als zentrales Arbeitsprotokoll definiert; du willst nur “#task”/“#fertig” (ohne Unterstrich) und Freigaben via 👍/❤️/Go.
+* Notion-Integration war mehrfach blockiert (400 Bad Request), Ursache war u. a. falsche Tasks-DB-ID; korrigiert auf 2e888f42-8544-8153-beac-e604719029cf; danach war der Task sichtbar („task ist jetzt da!“).
+* Status-Reports sollen als Page-Content (nicht Kommentar) im Task erscheinen; Format “## 🤖 Status-Update (… Berlin Time)” wurde verwendet und nach “Go” gepostet.
+* Zeiterfassung muss numerisch am Task gepflegt werden (für Rollups); Text “ca. 02:30” wurde als inkonsistent identifiziert und bereinigt; User bestätigt “jetzt schaut es gut aus!”.
+* Feature-Anforderung: Transkripte in Ordner sortieren + taggen; bestehende Tags müssen vorgeschlagen werden.
+* Architektur-Constraint: “dead simple tool”, keine API; erst Readme/Code analysieren, dann umsetzen.
+* Es gab massive Reibung durch fehlende Transparenz: du verlangst proaktive Rückmeldungen und alle 2 Minuten Mini-Updates (3–5 Stichpunkte).
+* Gitea-Zugriff war instabil (DNS “Failed to resolve…”), Repo-Download via Script (937 Dateien) und /etc/hosts-Fix auf 84.190.111.140; aber dynamische IP macht das fragil.
+* Push/Deployment war inkonsistent: obwohl “gepusht” behauptet, zeigte git pull “Already up to date”; zudem Branch/Pfad-Verwechslung (“transcription-tool”/feature branch).
+* Kritische Codebase-Diskrepanz: bearbeitete root app.py (Streamlit) passt nicht zum laufenden transcription-app Container (uvicorn backend.app).
+* Datensicherheit: dein update.sh ist kein Backup; backup.sh (tar.gz) soll vor Updates laufen.
+* Persistenzpfade Moltbot sind nicht abschließend geklärt (clawd vs .clawdbot/persistent_clawd); User sieht Medien/Logs an wechselnden Orten.
+
+F) Rückfragen (max. 10, höchste Hebelwirkung)
+
+1. Welcher Branch ist der “Deployment-Branch” für transcription-app: main oder ein feature/task-Branch (oder ein eigener “transcription-tool” Branch/Ordner)?
+2. Was ist der Build-Context/WORKDIR von brancheneinstufung-transcription-app (Dockerfile/docker-compose): wird Brancheneinstufung2/ transcrption-tool/ oder Repo-Root ins Image kopiert?
+3. Welche DB nutzt das live Tool tatsächlich: meetings.db oder transcriptions.db, und wie heißt die Tabelle (meetings vs transcriptions)?
+4. Wo soll die Ordner-/Tag-Metadatenstruktur final gespeichert werden: in SQLite (lokal) oder in Notion (zusätzlich/parallel) — oder strikt nur lokal?
+5. Wie genau sollen Tag-Vorschläge im UI aussehen (Dropdown/Multiselect/Autocomplete) – reicht eine “Suggested Tags” Liste + freies Eingabefeld, oder muss es echtes Autocomplete sein?
+6. Kannst du die relevante docker-compose.yml (für transcription-app) bzw. den Teil mit volumes zeigen, um Persistenz und Codepfade eindeutig zu machen?
+7. Wo möchtest du den “Source of Truth” Workspace für Moltbot haben: /volume1/docker/moltbot/moltbot/clawd oder unter /volume1/docker/moltbot/storage/… ?
+8. Soll backup.sh nur den clawd-Workspace sichern oder zusätzlich storage/media (inbound) und/oder Notion-Configs?
+9. Wo liegt big_Fortschritt_marketingautomation.txt (Repo-Pfad oder Synology-Pfad), oder kannst du den Inhalt hier einfügen/hochladen?
+10. Für das Kommunikationsprotokoll: sollen Mini-Updates strikt zeitbasiert (2 Minuten) sein, oder “nach jedem relevanten Tool-Schritt” (z. B. nach git/ls/migration/push), falls Zeitintervalle nicht zuverlässig haltbar sind?