Calendarr/CLAUDE.md

Calendarr — Arbeitsweise (WICHTIG)

Dieses Repo ist ein Monorepo. Alles liegt hier, es gibt keine getrennten App-Repos mehr.

backend/       FastAPI + SQLite
frontend/      Web-Frontend
ios/           SwiftUI-App, Widgets, Watch-App, Komplikationen
android/       Kotlin/Compose-App
CalendarrKit/  Swift-Paket (CalendarrCore) — geteilt von iOS-App, Widgets und Watch
docs/          DESIGN.md u.a.

Gearbeitet wird auf Branch beta. Der Nutzer deployt daraus auf den Testserver und merged später selbst beta → master.

Diese Maschine = macOS-Entwicklungsrechner. Was hier NICHT geht:

• KEINE Server-Tests, kein Server-Start. Nicht pytest ausführen, keine venvs aufsetzen, den Server nicht lokal starten. Backend-Änderungen werden per Code-Review abgesichert; getestet wird ausschließlich auf dem Testserver.
• Apps lassen sich hier nur bauen, nicht ausführen. UI-, Verhaltens- und Visual-Tests macht der Nutzer auf Gerät bzw. Simulator. Nicht über das Aussehen spekulieren — bei Unsicherheit nachfragen.
• Geräteabhängige Bugs sind hier nicht reproduzierbar. Die Watch-Komplikationen und der Liquid-Glass-Titel-Bug sind Beispiele dafür.

Build-Verifikation (das geht, und nur das)

# iOS inkl. Widgets und Watch-App
cd ios && xcodebuild -project "Calendarr iOS.xcodeproj" -scheme "Calendarr iOS" \
  -destination 'generic/platform=iOS' CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO build

# Mac Catalyst — separat prüfen, der Build bricht sonst unbemerkt
cd ios && xcodebuild -project "Calendarr iOS.xcodeproj" -scheme "Calendarr iOS" \
  -destination 'platform=macOS,variant=Mac Catalyst' CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO build

# CalendarrKit — gegen die native macOS-SDK, das fängt UIKit-Importe ab
cd CalendarrKit && swift build && swift test

# Android
cd android && ./gradlew assembleDebug

Xcode liegt unter /Applications/Xcode.app. Watch-Builds brauchen eine Xcode-Version, deren watchOS-SDK zum Gerät passt.

CalendarrKit

Liegt als git subtree in der Wurzel. Das Xcode-Projekt referenziert es relativ als ../CalendarrKit — von ios/ aus zeigt das genau hierher. Diesen Pfad nicht ändern und das Verzeichnis nicht verschieben, sonst baut iOS nicht mehr.

CalendarrCore ist bewusst Foundation-only — kein SwiftUI, kein UIKit, kein AppKit. swift build gegen die macOS-SDK ist das, was einen versehentlichen UIKit-Import auffallen lässt, bevor ein Consumer darüber stolpert. Das Wire-Format hat eigene Regeln, siehe CalendarrKit/README.md.

Plattform-Parität (WICHTIG)

Feature-Logik gehört möglichst auf den Server, nicht pro Client dupliziert. Beispiel: die Gruppentermin-Dekoration liefert der Server als display_title im /combined-Endpoint — Clients rendern nur. Sichtbare Features müssen auf allen Clients umgesetzt werden (Web, iOS, Android), nicht nur einem.

Ausnahme sind plattformeigene Erweiterungen wie Watch-App und Komplikationen; ein Wear-OS-Gegenstück ist ein eigenes Projekt.

Konventionen

• Keine Emojis als Icons — überall echte Vektor-Icons (Image(systemName:) auf Apple-Plattformen, Icon-Set bzw. inline SVG sonst). Emojis sehen auf jeder Plattform anders aus, was der Paritäts-Anspruch nicht verträgt.
• Commit-Messages auf Englisch, Kommunikation mit dem Nutzer auf Deutsch.
• Nach jeder abgeschlossenen Einheit committen und pushen.
• Fehler nicht mit try? verschlucken. Eine Quelle, die scheitert, muss sagen warum — sonst sieht sie aus wie eine Quelle ohne Inhalt. Das hat schon zweimal Bugs verborgen (KeychainStore, loadWritableCalendars).

Altlasten

~/Projects_Coding/Calendar Stack/ enthält die früheren Einzel-Repos (Calendarr iOS, Calendarr Android, CalendarrKit, Calendarr server). Sie sind veraltet und enthalten nichts, was hier fehlt; das iOS-Remote ist archiviert. Dort nicht mehr arbeiten.