Beitragen und Qualitaet

Beitragen und Qualität

Arbeitsablauf

1. Einen kleinen, klar benannten Branch vom aktuellen main erstellen.
2. Bestehende Architektur und Tests des betroffenen Bereichs lesen.
3. Änderung inklusive Tests und Dokumentation implementieren.
4. Betroffene Tests lokal ausführen.
5. Pull Request gegen main erstellen.
6. CI-Fehler und Review-Hinweise beheben.
7. Erst nach grüner CI mergen.

Direkte Produktivänderungen ausserhalb des dokumentierten Release-Prozesses sind nicht Teil des Entwicklungsworkflows.

Branches und Commits

• Branches beschreiben Zweck oder Issue, z. B. fix/tenant-scope-export.
• Ein Commit enthält eine zusammenhängende Änderung.
• Commit-Nachrichten beschreiben das Ergebnis im Imperativ.
• Generierte Dateien, Secrets, lokale .env, Storage und Testergebnisse nicht committen.
• Migration, Modell, Service, Tests und Doku dürfen in einem fachlich atomaren Commit gemeinsam geändert werden.

Pull-Request-Inhalt

Ein PR beschreibt:

• Problem und gewünschtes Verhalten;
• wesentliche technische Entscheidung;
• Sicherheits- und Tenant-Auswirkungen;
• Schema-/Konfigurationsänderungen;
• ausgeführte Tests;
• Rollout-/Rollback-Besonderheiten;
• Screenshots bei sichtbaren UI-Änderungen.

Definition of Done

• Fachliches Verhalten ist vollständig umgesetzt.
• Code folgt Route → Service → Repository und bestehenden Frontend-Mustern.
• Tenant-, Rollen- und ID-Grenzen sind geprüft.
• Erfolgs-, Fehler- und Konfliktfälle sind getestet.
• Migrationen laufen auf bestehender und frischer DB.
• Relevante Frontend-Builds und Typprüfungen sind grün.
• Logs enthalten keine Secrets oder unnötigen personenbezogenen Daten.
• Wiki bzw. führende Quelldokumentation ist aktualisiert.
• CI ist vollständig grün; warnende Dependency-Funde wurden gelesen.

Testtiefe nach Änderung

Änderung	Mindestprüfung
Repository/Service	Pytest inkl. Tenant- und Fehlerfall
API-Route	Auth-, Rollen-, Validierungs- und Cross-Tenant-Test
Frontend-Logik	Vitest; bei Nutzerfluss zusätzlich Playwright
Schema/Migration	Upgrade gegen frische DB und Anwendungstest
Upload/Datei	Grösse, Magic Bytes, Quota, Scan und Pfadsicherheit
Auth/MFA	beide Login-Welten getrennt testen
Deployment	Shell- und Release-Konfigurationstests

Review-Schwerpunkte

• Kann eine fremde Tenant-ID eingeschleust werden?
• Wird eine interne ID exponiert?
• Ist ein Check-then-write-Ablauf race-sicher?
• Bleibt ein Rollback möglich?
• Sind Fehlercodes und UI-Fehlerbehandlung konsistent?
• Werden sensible Aktionen auditiert?
• Sind Hintergrundjobs mehrfach-worker-sicher?
• Ist neue Konfiguration dokumentiert und sicher voreingestellt?

Stil und Wartbarkeit

Python verwendet Typannotationen und klar getrennte Services/Repositories. TypeScript bleibt strict und verwendet gemeinsame API-Typen. Grosse Komponenten werden nach fachlichen Verantwortlichkeiten zerlegt. Kommentare erklären Gründe und Sicherheits- invarianten, nicht offensichtliche Syntax.

Automatische Format-/Lint-Werkzeuge sind nur dann ein verlässliches Gate, wenn sie in CI tatsächlich ausgeführt werden. Neue Werkzeuge müssen daher zusammen mit ihrem CI-Schritt dokumentiert und eingeführt werden.