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>
87 lines
3.9 KiB
Markdown
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.
|