Files
Calendarr/CLAUDE.md
T
ScarriffleandClaude Opus 5 4816a33980 Describe the monorepo the way it actually is now
The working instructions still described four separate repositories and a
server directory that did not exist on the development machine, which is how
work ended up in a fork whose remote had since been archived. Replaced with the
current layout, the build commands that are actually verifiable here, the
CalendarrKit subtree path the Xcode project depends on, and a pointer marking
the old per-app checkouts as stale.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-10-19 05:57:46 +02:00

87 lines
3.9 KiB
Markdown

# 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)
```bash
# 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.