Files
ApiCore/TASKS.md
T
Nick SzaunigandClaude Opus 5.5 9760ce154f
Backend Image / build-and-push (push) Successful in 4m27s
Frontend Image / build-and-push (push) Successful in 9m34s
Manifests / validate (push) Successful in 19s
feat: T4 wave 11 – bottling form with article values and confirmation, Telegram in the app
- Bottling form: jar size and best-before from the product with source,
  differs-hints before saving, prefill status, water-content confirmation
  naming the measured value, idempotency key renewed on body change;
  product form gets shelf life (months) and whole-gram jar weight.
- Telegram frontend: link card with step-up dialog, t.me-only deep link,
  status polling, unlink; system Telegram card with receiver/sender state
  and confirmed retry; StepUpDialog shared with the backup import.
- Reauth calls never refresh-and-retry on 401 (no double lockout count);
  German texts for expired session and 429; service worker never caches
  Telegram, notification settings and system responses.
- Telegram backend round 2: shared link removal on every disconnect path,
  lease released on shutdown, connection errors not counted as poison.
- ARCHITECTURE.md §2, §6 (Annahmen 56–58), §10, §11.12, §11.13; TASKS.md T4.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
2026-10-15 01:21:08 +02:00

353 lines
22 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# ApiCore – Aufgabenliste
Abgeleitet aus [`docs/lastenheft.md`](docs/lastenheft.md) Abschnitt 26. Reihenfolge innerhalb MVP ist Bau-Reihenfolge (siehe Vorgabe: Auth zuerst, dann Kette bis Export). Haken erst setzen, wenn Lint+Typecheck+Tests+Build für das jeweilige Projekt grün sind UND das Modul manuell/per Test verifiziert wurde.
## MVP (MUSS) – Abschnitt 26, Liste 1
### 0. Grundgerüst
- [x] Backend: NestJS-Projekt scaffolden, Prisma init, `/api/v1` Versioning, Swagger unter `/api/v1/docs`, `/health` + `/health/ready`
- [x] Backend: `.env.example` (`DATABASE_URL`, `JWT_ACCESS_SECRET`, `JWT_REFRESH_SECRET`)
- [x] Backend: Prisma-Schema für alle MVP-Entitäten (siehe ARCHITECTURE.md §4, §6), erste Migration
- [x] Frontend: Next.js (App Router, TS) scaffolden, Tailwind + shadcn/ui, PWA-Manifest, TanStack Query Provider
- [x] `deploy/k8s/`: Dockerfiles (Backend, Frontend), Deployment/Service/Ingress, ConfigMap/Secret-Vorlagen
### 1. Benutzerverwaltung / Auth
- Backend: `AuthModule`, `UsersModule`, `AuditModule` (Grundstruktur)
- Endpunkte: `POST /api/v1/auth/login`, `POST /api/v1/auth/refresh`, `POST /api/v1/auth/logout`, `GET /api/v1/users`, `POST /api/v1/users`, `GET/PATCH /api/v1/users/:id`, `POST /api/v1/users/:id/deactivate`
- Frontend: `/login`, `/settings/users` (nur Administrator)
- [x] Rollen-Enum + Guards (`JwtAuthGuard`, `RolesGuard`, `@Roles()`) implementiert und in jedem künftigen Modul verpflichtend
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 2. Bienenstände
- Backend: `ApiariesModule`
- Endpunkte: `GET/POST /api/v1/apiaries`, `GET/PATCH /api/v1/apiaries/:id`, `POST /api/v1/apiaries/:id/deactivate`
- Frontend: `/apiaries`, `/apiaries/[id]`, `/apiaries/new`
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 3. Völker
- Backend: `ColoniesModule` (inkl. `ColonyApiaryHistory`, `ColonyLineage` für Ableger/Vereinigung)
- Endpunkte: `GET/POST /api/v1/colonies`, `GET/PATCH /api/v1/colonies/:id`, `POST /api/v1/colonies/:id/move`, `POST /api/v1/colonies/:id/split`, `POST /api/v1/colonies/:id/merge`, `POST /api/v1/colonies/:id/dissolve`, `GET /api/v1/colonies/:id/history`
- Frontend: `/colonies`, `/colonies/[id]`, `/colonies/new`
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 4. Königinnen
- Backend: `QueensModule` (inkl. `QueenColonyHistory`)
- Endpunkte: `GET/POST /api/v1/queens`, `GET/PATCH /api/v1/queens/:id`, `POST /api/v1/queens/:id/assign-colony`, `GET /api/v1/queens/:id/history`
- Frontend: `/queens`, `/queens/[id]`, `/queens/new`
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 5. Durchsichten
- Backend: `InspectionsModule`
- Endpunkte: `GET/POST /api/v1/inspections`, `GET /api/v1/inspections/:id`, `GET /api/v1/colonies/:id/inspections`, `POST /api/v1/inspections/:id/create-task`
- Frontend: `/inspections/new` (mobile-optimiertes Schnellformular), `/colonies/[id]` Tab "Durchsichten"
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 6. Aufgaben
- Backend: `TasksModule` (polymorphe Verknüpfung: Colony/Apiary/Queen/HoneyBatch/Storage/General)
- Endpunkte: `GET/POST /api/v1/tasks`, `GET/PATCH /api/v1/tasks/:id`, `POST /api/v1/tasks/:id/complete`
- Frontend: `/tasks` (Liste, Filter nach Status/Priorität/Fälligkeit)
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 7. Varroamessungen
- Backend: `VarroaModule`
- Endpunkte: `GET/POST /api/v1/varroa-measurements`, `GET /api/v1/colonies/:id/varroa-measurements`
- Frontend: `/varroa/new`, `/colonies/[id]` Tab "Varroa" mit Verlaufsgrafik
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 8. Behandlungen
- Backend: `TreatmentsModule`
- Endpunkte: `GET/POST /api/v1/treatments`, `GET /api/v1/colonies/:id/treatments`
- Frontend: `/treatments/new`, `/colonies/[id]` Tab "Behandlungen"
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 9. Fütterungen
- Backend: `FeedingsModule`
- Endpunkte: `GET/POST /api/v1/feedings`, `GET /api/v1/colonies/:id/feedings`, `GET /api/v1/colonies/:id/feedings/summary`
- Frontend: `/feedings/new`, `/colonies/[id]` Tab "Fütterung"
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 10. Ernten (inkl. Schleuderung als Fundament der Chargenkette)
- Backend: `HarvestsModule`, `ExtractionsModule`
- Endpunkte: `GET/POST /api/v1/harvests`, `GET /api/v1/harvests/:id`, `GET/POST /api/v1/extractions`, `GET /api/v1/extractions/:id`
- Frontend: `/harvests/new`, `/harvests/[id]`, `/extractions/new`
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 11. Honigchargen
- Backend: `HoneyBatchesModule` (inkl. Honigmessungen, siehe ARCHITECTURE.md Annahme 1)
- Endpunkte: `GET/POST /api/v1/honey-batches`, `GET /api/v1/honey-batches/:id`, `GET /api/v1/honey-batches/:id/traceability`, `POST /api/v1/honey-batches/:id/measurements`
- Frontend: `/honey-batches`, `/honey-batches/[id]` (inkl. Rückverfolgbarkeits-Ansicht)
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 12. Grundlegende Lagerverwaltung
- Backend: `StorageModule` (StorageContainer, StockItem, StockMovement)
- Endpunkte: `GET/POST /api/v1/storage-containers`, `GET/POST /api/v1/stock-items`, `POST /api/v1/stock-items/:id/movements`
- Frontend: `/storage`
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 13. Dashboard
- Backend: `DashboardModule`
- Endpunkte: `GET /api/v1/dashboard/summary`, `GET /api/v1/dashboard/alerts`
- Frontend: `/dashboard` (Startseite nach Login)
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 14. Suche und Filter
- Backend: `SearchModule` (`GET /api/v1/search?q=`), Filter-Query-Parameter in bestehenden List-Endpunkten (Standort, Status, Zeitraum etc., kombinierbar)
- Frontend: `/search`, Filterleisten in allen Listen-Views
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 15. Responsive Smartphone-Oberfläche
- Frontend: Mobile-first-Layout für alle o.g. Views verifiziert (Touch-Targets, Bottom-Nav, "+ Neu"-Schnellaktion permanent erreichbar)
- [x] Manuell auf simulierter Smartphone-Breite (< 480px) und Tablet-Breite geprüft
### 16–18. API, API-Dokumentation, Rollen/Berechtigungen
- Cross-cutting, wird pro Modul mitgeliefert (jeder Endpunkt in Swagger, jeder Endpunkt mit Rollen-Guard)
- [x] Abschließende Prüfung: alle Endpunkte in `/api/v1/docs` sichtbar, alle mit Rollenprüfung
### 19. Audit-Log (vollständiges Modul inkl. Abfrage/UI)
- Backend: `AuditModule` erweitert um Abfrage-Endpunkte (Grundstruktur bereits in Schritt 1 gebaut, hier UI + Query-API)
- Endpunkte: `GET /api/v1/audit-log?entityType=&entityId=`
- Frontend: `/settings/audit-log` (nur Administrator)
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 20. Backupfähigkeit
- [x] Prisma-Migrationen reproduzierbar (kein `db push` in Produktion, nur `migrate deploy`)
- [x] Backup-/Restore-Strategie in ARCHITECTURE.md dokumentiert
- [x] `/health/ready` prüft DB-Erreichbarkeit
- [x] Automatisches Backup umgesetzt - abweichend von der ursprünglich geplanten `pg_dump`-CronJob-Strategie als eigenes `BackupModule` (Anwendungsebene, JSON-Export/-Import aller Modelle inkl. Dokumente, cron-gesteuert via `@nestjs/schedule`, Zeitplan per Env-Variable ODER GUI unter Verwaltung > Backup konfigurierbar). Siehe ARCHITECTURE.md Abschnitt 8.
### 21. Datenexport
- Backend: `ExportModule`
- Endpunkte: `GET /api/v1/export/colonies.csv`, `GET /api/v1/export/honey-batches.csv`, `GET /api/v1/export/:report.pdf`, `GET /api/v1/export/:entity.json`
- Frontend: Export-Buttons in den jeweiligen Listen-Views
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### MVP-Abschluss
- [x] Gesamter Backend-Build grün (`lint`, `typecheck`, `test`, `test:e2e`, `build`)
- [x] Gesamter Frontend-Build grün (`lint`, `typecheck`, `test`, `build`)
- [x] Rückverfolgbarkeitskette Volk → Durchsicht → Behandlung → Ernte → Schleuderung → Honigcharge → Lager end-to-end manuell verifiziert
- [x] Alle Erfolgskriterien aus Abschnitt 30 stichprobenartig beantwortbar
## v1.x (SOLL) – Abschnitt 26, Liste 2
Reihenfolge = Bau-Reihenfolge. Gleiche Haken-Regel wie MVP: erst setzen, wenn Lint+Typecheck+Tests+Build grün UND manuell/per Test verifiziert.
### R. Redesign (grundlegend)
- [x] Design-Tokens: warme Honig-/Wachs-Farbpalette (Amber-Primär, Salbeigrün-Sekundär, Warnung/Erfolg), Space Grotesk (Überschrift) + Inter (Fließtext) + IBM Plex Mono (Codes/IDs)
- [x] Navigation, Dashboard, Login neu gestaltet (Hexagon-Markenzeichen, aktiver Link-Zustand, Waben-Signaturmuster)
- [x] Verbleibende Bestandsseiten (Listen/Details aller MVP-Module) auf einheitlichen Karten-/Badge-/Icon-Stil durchgezogen
- [ ] Alle neuen v1.x-Module folgen dem Redesign von Anfang an (kein Nacharbeiten nötig)
### 22. QR-Code-System
- Backend: `QrModule` – erzeugt QR-Code (PNG/SVG) pro Objekt, kodiert Deep-Link (`/colonies/:id`, bei Volk direkt `/inspections/new?colonyId=:id` gemäß Lastenheft-Begründung "reduziert Auswahlaufwand")
- Endpunkte: `GET /api/v1/qr/:entityType/:id.svg` für `entityType` ∈ `colonies|apiaries|queens|honey-batches|storage-containers`
- Frontend: "QR-Code"-Button/Dialog auf den jeweiligen Detailseiten, druckfreundliche Ansicht
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 23. Abfüllungen und Produkte
- Backend: `BottlingModule` (`BottlingBatch`), `ProductsModule` (`Product`); Abfüllung reduziert `HoneyBatch.amount` transaktional
- Endpunkte: `GET/POST /api/v1/bottling-batches`, `GET /api/v1/bottling-batches/:id`, `GET/POST /api/v1/products`, `GET/PATCH /api/v1/products/:id`
- Frontend: `/bottling/new`, `/bottling/:id`, `/products`, `/products/new`
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 24. Inventar
- Backend: `EquipmentModule` (`Equipment`: Inventarnummer, Bezeichnung, Hersteller, Kaufdatum, Zustand, Standort, Wartungsdatum)
- Endpunkte: `GET/POST /api/v1/equipment`, `GET/PATCH /api/v1/equipment/:id`
- Frontend: `/equipment`, `/equipment/new`, `/equipment/:id`
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 25. Kalender
- Backend: `CalendarModule` – aggregiert Durchsichten, Aufgaben, Behandlungen, Fütterungen, Ernten, Königinnenarbeiten in einem Zeitfenster
- Endpunkte: `GET /api/v1/calendar?from=&to=&apiaryId=`
- Frontend: `/calendar` (Monats-/Wochenansicht)
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 26. Benachrichtigungssystem
- Backend: `NotificationsModule` (`Notification`: Priorität INFO/HINWEIS/WARNUNG/KRITISCH, Nachricht, verknüpftes Objekt, gelesen); erzeugt aus Automatisierungen/Schwellenwerten
- Endpunkte: `GET /api/v1/notifications`, `POST /api/v1/notifications/:id/read`
- Frontend: Glocken-Icon in der Navigation mit Liste/Badge für ungelesene Einträge
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 27. Statistik und Reporting
- Backend: `StatisticsModule` – Auswertungen gemäß Abschnitt 4.26 (Volksstärke-Entwicklung, Völkerverluste, Königinnen-Ertrag/Lebensdauer, Standort-Ertrag, Varroa-Verlauf, Honigertrag pro Volk/Stand/Jahr, Futterverbrauch)
- Endpunkte: `GET /api/v1/statistics/{colonies|queens|apiaries|varroa|honey|feeding}`
- Frontend: `/statistics` mit Diagrammen
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 28. Webhooks
- Backend: `WebhooksModule` (`WebhookSubscription`: URL, Events, Secret, aktiv); Event-Dispatcher an bestehende Services angehängt (`colony.created`, `inspection.created`, `queen.created`, `queen.replaced`, `harvest.created`, `batch.created`, `batch.updated`, `product.stock_changed`, `task.created`, `task.completed`), HMAC-signierter POST
- Endpunkte: `GET/POST /api/v1/webhooks`, `DELETE /api/v1/webhooks/:id`
- Frontend: `/settings/webhooks` (nur Administrator)
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 29. Dokumente und Bilder
- Backend: `DocumentsModule` (`Document`: entityType/entityId, Dateiname, MIME-Typ, Größe, Speicherpfad, Hochgeladen-von); Objektspeicher als lokales Volume (`deploy/k8s` ConfigMap-Pfad, austauschbar)
- Endpunkte: `POST /api/v1/documents` (multipart, entityType/entityId), `GET /api/v1/documents?entityType=&entityId=`, `GET /api/v1/documents/:id/download`, `DELETE /api/v1/documents/:id`
- Frontend: Datei-Upload-Widget auf Volk-/Königin-/Durchsicht-/Bienenstand-/Honigcharge-Detailseiten
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet (Durchsicht-Detailseite existiert nicht separat, daher nur Bienenstand/Volk/Königin/Honigcharge)
### 30. Automatisierungen
- Backend: `AutomationModule` (`AutomationRule`: Trigger-Typ, aktiv, Konfiguration, Aktionsvorlage) mit fest hinterlegten Triggern (keine Königin+keine Stifte → Kontrollvorschlag, Varroa-Schwellenwert → Behandlungsprüfung, Futterstatus kritisch → Fütterungsaufgabe), erzeugt Task + Notification
- Endpunkte: `GET/POST /api/v1/automation-rules`, `PATCH /api/v1/automation-rules/:id`
- Frontend: `/settings/automation-rules` (nur Administrator)
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 31. Königinnenbewertung
- Backend: `QueenEvaluation` (Volksstärke, Sanftmut, Wabensitz, Schwarmtrieb, Brutbild, Honigertrag je Skala 1–5, Datum, Notizen) verknüpft mit Königin
- Endpunkte: `GET/POST /api/v1/queens/:id/evaluations`
- Frontend: Bewertungsformular + Verlauf auf der Königin-Detailseite
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 32. Lagerbehälter-Umlagerung
- Backend: `HoneyBatchRelocation`-Historie – Honigcharge zwischen Lagerbehältern umlagern, `storageContainerId` aktualisieren, jede Umlagerung dokumentiert
- Endpunkte: `POST /api/v1/honey-batches/:id/relocate`, `GET /api/v1/honey-batches/:id/relocations`
- Frontend: Lagerbehälter-Sektion + Umlagerungshistorie auf der Honigcharge-Detailseite
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### 33. Importfunktionen
- Backend: `ImportModule` – CSV-Import für Stammdaten (`apiaries`, `colonies`, `queens`), Validierung, Ergebnisbericht (erstellt/übersprungen/Fehler pro Zeile)
- Endpunkte: `POST /api/v1/import/:entity` (multipart CSV)
- Frontend: `/settings/import` (nur Administrator), Datei-Upload + Ergebnisbericht
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
### v1.x-Abschluss
- [x] Gesamter Backend-Build grün (`lint`, `typecheck`, `test`, `test:e2e`, `build`)
- [x] Gesamter Frontend-Build grün (`lint`, `typecheck`, `test`, `build`)
- [x] Erweiterte Kernanforderung aus Abschnitt 29 end-to-end verifiziert: Stand → Volk → Königin → Durchsicht → Behandlung → Ernte → Schleuderung → Honigcharge → Lagerbehälter → Abfüllung → Produkt
## Plattform-Rückgrat (Fahrplan Oktober 2026)
Spec: `docs/superpowers/specs/2026-10-12-plattform-rueckgrat-und-fahrplan-design.md`, Beschreibung in ARCHITECTURE.md Abschnitt 10.
- [x] Laufrollen `api`/`worker`/`job` (ein Image, `dist/cli.js` für Jobs, keine Timer im Prozess)
- [x] Ereignis-Rückgrat: `DomainEvent`-Outbox, Handler in der Zustell-Transaktion, Webhook-Zustellung
- [x] Jobs als Kubernetes-CronJobs (`JobRun`), u. a. `rekey`
- [x] Seite „Verwaltung > System“
- [ ] Ausrollen in den Cluster (api/worker/job getrennt) – gebaut und getestet, noch nicht ausgerollt
## T3. Erfassung am Stand
Plan: `docs/superpowers/plans/2026-10-13-t3-erfassung-am-stand.md`, Annahmen 24–29 in ARCHITECTURE.md.
- [x] 1. `Inspection.broodFrames` (Waben per Plus/Minus), Migration, Backup
- [x] 2. Lese-Endpunkte für Vorbelegung und Wetter (Varroa, Behandlungen, Dokumente)
- [x] 3. Stand-Übersicht und Offline-Paket (`colony-overview`, `offline-pack`, ohne Koordinaten)
- [x] 4. Sammelerfassung Behandlung/Fütterung/Varroa (eine Transaktion, `@Idempotent()`, `bulkId`)
- [x] 5. Zeitlimits (4 s), Flugmodus-Regression (`networkMode`)
- [x] 6. Band „Offline – X Einträge warten“, Warteschlange und Sync
- [x] 7. Navigation aus einer Quelle (`nav-config.ts`), „Mehr“- und „+ Neu“-Sheet, Zurück-Link mit Rückfrage
- [x] 8. Bausteine: Skalen „5 = gut“, Plus/Minus-Stepper, Hinweis „Letztes Mal“
- [x] 9. Durchsicht-Formular: Werte der letzten Durchsicht, Wetter automatisch
- [x] 10. Fotos: Kamera, Neu-Kodierung ohne EXIF/GPS, offline, idempotent (inkl. EXIF-Leck im Dokumenten-Upload)
- [x] 11. Varroa: Zeitraum, Milben/Tag live mit Ampel, Trend mit Schwellenlinie
- [x] 12. Behandlung: Vorbelegung aus der letzten Behandlung mit demselben Mittel
- [x] 13. Sammelerfassung im Frontend (K1/K2, ein Idempotenz-Schlüssel je Absendung)
- [x] 14. Stand-Seite mit Völkern und Ampel, Standrunde
- [x] 15. Offline: „Stand laden“, Offline-Seiten, QR/NFC-Deep-Links, Service Worker
- [x] 16. Offline-Sitzung, Abmelden löscht Pakete, Warteschlange (nach Rückfrage) und Caches
- [x] 17. Dokumentation (ARCHITECTURE.md Abschnitt 2 und Annahmen 24–29)
- [ ] Manuell offen: Prüfung der Foto-Metadaten mit `exiftool` auf einem echten Telefon (auch älteres iOS Safari)
## T4. Logik-Ketten und Saison-Autopilot
Plan: `docs/superpowers/plans/2026-10-13-t4-logik-ketten.md`, Annahmen 31–58 in ARCHITECTURE.md, Beschreibung in Abschnitt 11.
- [x] T4a (Tasks 1–22): Vorschläge statt Aufgaben, Regel-Werte, Varroa-Ampel nach Jahreszeit, Biotechnik- und Wartezeit-Ketten, Saison-Autopilot A1–A3, Erinnerungen, Oberflächen dazu
- [x] T4b (Tasks 23–33): Pflanzenentwicklung mit Wetter (GTS, Saisonzustand, Meldungen), Autopilot A4–A10, Honig-Kette mit Bewegungsbuch und Qualitätsprüfung (409 bei Wassergehalt), Oberflächen; Abfüllungsmaske mit Artikelwerten, Bestätigungsdialog und Haltbarkeit am Artikel
- [x] T4c (Tasks 34–38): Telegram-Bot (Client, Planung, Senden, Verbinden, Empfangen mit Lease, einheitliches Trennen), Betrieb in der System-API, Profil-Karte mit Step-up und Systemkarte
- [ ] Folgepunkt: `packagingSize` im Backend als `@IsInt @Min(1) @Max(10000)` prüfen, nach Datenprüfung in Produktion (braucht Freigabe)
- [ ] Ausrollen in den Cluster – gebaut und getestet, noch nicht ausgerollt
## Später (KANN) – Abschnitt 26, Liste 3
Software-seitig umsetzbare Punkte werden gebaut. Punkte, die dedizierte native Build-Pipelines, echte ML-Modelle oder physische Hardware voraussetzen, sind als "nicht umsetzbar in diesem Kontext" markiert statt mit einer Alibi-Umsetzung – Begründung jeweils dahinter.
- [x] Kartenansicht (Bienenstände mit Koordinaten auf einer Karte)
- [x] Wetterintegration / Wetterhistorie je Bienenstand (externe Wetter-API anhand Bienenstand-Koordinaten)
- [x] Trachtprognosen (heuristische Einschätzung aus Wetterdaten + Saison + historischen Ernten, kein ML-Modell)
- [x] Öffentliche Herkunftsseiten für Honigchargen + Kunden-QR-Code (Abschnitt 27: `wabenhain.com/herkunft/{lot}`, öffentlicher Read-Endpoint)
- [x] Vollständig offlinefähige PWA mit Sync (Service Worker + IndexedDB-Warteschlange für Durchsichten, Sync bei Wiederverbindung)
- [x] NFC-Tags (Web-NFC-API, nur Chrome/Android; kodiert denselben Deep-Link wie der QR-Code; kein Fallback für andere Browser möglich)
- [x] ~~Native Smartphone-App~~ – nicht umsetzbar in diesem Kontext: erfordert eigene native Codebasis, App-Store-Vertrieb und Build-Pipeline ausserhalb einer Web-Session
- [x] ~~KI-Auswertung von Völkerdaten, automatische Anomalieerkennung, Fotoanalyse~~ – nicht umsetzbar in diesem Kontext: erfordert dediziertes ML-Modelltraining/-Betrieb, keine seriöse Umsetzung als einfache Heuristik
- [x] ~~Spracherfassung am Bienenstand, automatische Zusammenfassung einer Durchsicht~~ – nicht umsetzbar in diesem Kontext: erfordert Spracherkennungs-/LLM-Infrastruktur über das bestehende Stack hinaus
- [x] ~~Sensorintegration (Stockwaagen, Temperatur-/Feuchtesensoren)~~ – nicht umsetzbar in diesem Kontext: erfordert physische IoT-Hardware
## ERP-Anbindung
### T8. Inventar-Spiegel für ERPNext (Datenquelle)
- Backend: `ErpExportModule` – nur lesend, Recht `erp-inventory:read` (eigener API-Schlüssel-Scope), Fehlversuchs-Sperre für API-Schlüssel je Client-Netz (IPv6 /64), Zähler über alle api-Pods geteilt (ARCHITECTURE.md Annahme 30)
- Endpunkte: `GET /api/v1/export/inventar/produkte`, `.../chargen`, `.../bewegungen?seit=&nach=&limit=`, `.../ernten?jahr=`
- Frontend: Berechtigung beim Anlegen eines API-Schlüssels wählbar (genau eine je Schlüssel, nur eigene Rechte), Liste zeigt, was ein Schlüssel darf
- Vertrag: [`docs/erp-inventar-export.md`](docs/erp-inventar-export.md)
- [x] Backend-Modul fertig, getestet, grün, committet
- [x] Frontend-Views fertig, getestet, grün, committet
- [ ] ERPNext-Importer (Repo ERPNext) nach dem Vertrag gebaut
## Prüfung September 2026
Prüfmatrix, Verifikationsstand und offene Entscheidungen: [`docs/pruefung-2026-09.md`](docs/pruefung-2026-09.md).