Rbm.FamStack/CLAUDE.md

CLAUDE.md – FamilyPlanner

Digitaler Familienplaner (PWA) auf .NET 10 + Aspire 13. Anforderungen: docs/ARCHITECTURE.md, Fortschritt: docs/ROADMAP.md, Entscheidungen: docs/adr/.

Befehle

dotnet build FamilyPlanner.slnx                            # muss ohne Warnungen bauen (TreatWarningsAsErrors)
dotnet test --solution FamilyPlanner.slnx                  # alle Tests (Microsoft.Testing.Platform); Integrationstests brauchen Docker
dotnet test --project tests/FamilyPlanner.UnitTests        # schnell, ohne Docker
dotnet test --project tests/FamilyPlanner.Web.Tests        # bUnit
dotnet test --project tests/FamilyPlanner.IntegrationTests # Aspire + SQL-Server-Container (~1–2 min)
aspire run                                                 # bzw. dotnet run --project src/FamilyPlanner.AppHost
aspire publish -o artifacts/compose                        # Docker-Compose aus dem App-Modell (Aspire-CLI >= 13.6)
# ohne passende CLI:
dotnet run --project src/FamilyPlanner.AppHost --no-launch-profile -- --operation publish --step publish --output-path ../../artifacts/compose

# Neue EF-Migration (aus dem Repo-Root; Tool über dotnet-tools.json: `dotnet tool restore`)
dotnet ef migrations add <Name> -p src/FamilyPlanner.Infrastructure -s src/FamilyPlanner.MigrationService -o Persistence/Migrations

# Produktiv-Stack lokal bauen/starten
cd deploy && cp .env.example .env && docker compose up -d --build

Wichtig: Wenn der AppHost läuft, sind die DLLs von Api/Web gesperrt → vor dotnet build/Tests beenden. Die Integrationstests starten einen eigenen, flüchtigen SQL-Container; der Dev-AppHost nutzt das Volume familyplanner-sql-data.

Lokaler Seed-Admin (AppHost-Parameter, siehe src/FamilyPlanner.AppHost/appsettings.Development.json): admin / Admin123!ChangeMe – Passwortwechsel beim ersten Login.

Struktur

• src/FamilyPlanner.Domain – Entities, Rollen (Roles), Policies (Policies), reine Logik. Keine Abhängigkeiten auf EF/ASP.NET.
• src/FamilyPlanner.Infrastructure – AppDbContext (Identity), Konfigurationen unter Persistence/Configurations, Migrations unter Persistence/Migrations, Seeding.
• src/FamilyPlanner.Api – Minimal APIs als Vertical Slices unter Features/<Feature>/; jeder Slice hat eine Map<Feature>Endpoints-Erweiterung.
• src/FamilyPlanner.Shared – DTOs (records) für Api und Client.
• src/FamilyPlanner.Web – BFF: statische WASM-Auslieferung + YARP (/api, /hubs, /ics → Api).
• src/FamilyPlanner.Web.Client – Blazor WASM + MudBlazor. Seiten unter Pages/, API-Clients unter Services/.
• src/FamilyPlanner.MigrationService – migriert + seedet, beendet sich.

Konventionen

• UI-Texte auf Deutsch; Code, Bezeichner und Commit-Typen auf Englisch.
• Commits: Conventional Commits (feat:, fix:, docs:, test:, chore:, refactor:, ci:).
• Alle Zeiten in UTC speichern (DateTimeOffset/UTC), Anzeige in Europe/Berlin. TimeProvider injizieren statt DateTime.UtcNow.
• Neue Entitäten erben von AuditableEntity; löschbare implementieren ISoftDeletable; Einkauf/Aufgaben/Termine bekommen RowVersion.
• Berechtigungen immer serverseitig, nie nur im UI: fachliche Endpunkte mit .RequirePermission(Permission.X) (Matrix in Domain/Authorization/Permissions.cs, ADR-0008). Bei AccessLevel.Restricted muss der Slice objektbezogen prüfen (z. B. „nur eigene“) – dafür Tests schreiben. Matrix-Änderungen in PermissionMatrixTests nachziehen.
• Administrative Aktionen schreiben ins Audit-Log (IAuditLogger), ohne Passwörter/PINs.
• Request-DTOs mit Validatoren in FamilyPlanner.Shared (FluentValidation) – Api validiert per .Validate<T>(), der Client nutzt dieselben Validatoren.
• Schreibende Requests vom Client tragen X-Requested-With: FamilyPlanner (wird vom HttpClient-Handler im Client gesetzt, siehe ADR-0006).
• Validierung mit FluentValidation im jeweiligen Slice.
• Pakete nur über Directory.Packages.props (keine Versionen in .csproj), nur stabile Versionen.
• Keine Secrets im Repo: User Secrets / Aspire-Parameter lokal, .env in Docker.
• Nach jeder Roadmap-Phase: Build, Tests, Aspire-Start prüfen, Roadmap abhaken, committen.