ApiCore/TASKS.md

ApiCore – Aufgabenliste

Abgeleitet aus 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

• Backend: NestJS-Projekt scaffolden, Prisma init, /api/v1 Versioning, Swagger unter /api/v1/docs, /health + /health/ready
• Backend: .env.example (DATABASE_URL, JWT_ACCESS_SECRET, JWT_REFRESH_SECRET)
• Backend: Prisma-Schema für alle MVP-Entitäten (siehe ARCHITECTURE.md §4, §6), erste Migration
• Frontend: Next.js (App Router, TS) scaffolden, Tailwind + shadcn/ui, PWA-Manifest, TanStack Query Provider
• 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)
• Rollen-Enum + Guards (JwtAuthGuard, RolesGuard, @Roles()) implementiert und in jedem künftigen Modul verpflichtend
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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"
• Backend-Modul fertig, getestet, grün, committet
• 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)
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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"
• Backend-Modul fertig, getestet, grün, committet
• 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"
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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)
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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)
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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)
• 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)
• 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)
• Backend-Modul fertig, getestet, grün, committet
• Frontend-Views fertig, getestet, grün, committet

20. Backupfähigkeit

• Prisma-Migrationen reproduzierbar (kein db push in Produktion, nur migrate deploy)
• Backup-/Restore-Strategie in ARCHITECTURE.md dokumentiert
• /health/ready prüft DB-Erreichbarkeit
• 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
• Backend-Modul fertig, getestet, grün, committet
• Frontend-Views fertig, getestet, grün, committet

MVP-Abschluss

• Gesamter Backend-Build grün (lint, typecheck, test, test:e2e, build)
• Gesamter Frontend-Build grün (lint, typecheck, test, build)
• Rückverfolgbarkeitskette Volk → Durchsicht → Behandlung → Ernte → Schleuderung → Honigcharge → Lager end-to-end manuell verifiziert
• 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)

• 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)
• Navigation, Dashboard, Login neu gestaltet (Hexagon-Markenzeichen, aktiver Link-Zustand, Waben-Signaturmuster)
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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)
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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)
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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)
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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
• Backend-Modul fertig, getestet, grün, committet
• Frontend-Views fertig, getestet, grün, committet

v1.x-Abschluss

• Gesamter Backend-Build grün (lint, typecheck, test, test:e2e, build)
• Gesamter Frontend-Build grün (lint, typecheck, test, build)
• 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.

• Laufrollen api/worker/job (ein Image, dist/cli.js für Jobs, keine Timer im Prozess)
• Ereignis-Rückgrat: DomainEvent-Outbox, Handler in der Zustell-Transaktion, Webhook-Zustellung
• Jobs als Kubernetes-CronJobs (JobRun), u. a. rekey
• 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.

• 1. Inspection.broodFrames (Waben per Plus/Minus), Migration, Backup
• 2. Lese-Endpunkte für Vorbelegung und Wetter (Varroa, Behandlungen, Dokumente)
• 3. Stand-Übersicht und Offline-Paket (colony-overview, offline-pack, ohne Koordinaten)
• 4. Sammelerfassung Behandlung/Fütterung/Varroa (eine Transaktion, @Idempotent(), bulkId)
• 5. Zeitlimits (4 s), Flugmodus-Regression (networkMode)
• 6. Band „Offline – X Einträge warten“, Warteschlange und Sync
• 7. Navigation aus einer Quelle (nav-config.ts), „Mehr“- und „+ Neu“-Sheet, Zurück-Link mit Rückfrage
• 8. Bausteine: Skalen „5 = gut“, Plus/Minus-Stepper, Hinweis „Letztes Mal“
• 9. Durchsicht-Formular: Werte der letzten Durchsicht, Wetter automatisch
• 10. Fotos: Kamera, Neu-Kodierung ohne EXIF/GPS, offline, idempotent (inkl. EXIF-Leck im Dokumenten-Upload)
• 11. Varroa: Zeitraum, Milben/Tag live mit Ampel, Trend mit Schwellenlinie
• 12. Behandlung: Vorbelegung aus der letzten Behandlung mit demselben Mittel
• 13. Sammelerfassung im Frontend (K1/K2, ein Idempotenz-Schlüssel je Absendung)
• 14. Stand-Seite mit Völkern und Ampel, Standrunde
• 15. Offline: „Stand laden“, Offline-Seiten, QR/NFC-Deep-Links, Service Worker
• 16. Offline-Sitzung, Abmelden löscht Pakete, Warteschlange (nach Rückfrage) und Caches
• 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.

• 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
• 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
• 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

T6. Compliance (Tierarzneimittel, Etikett, Behörden, Prüfbereitschaft)

Plan: docs/superpowers/plans/2026-10-14-t6-compliance.md, Annahmen ab 59 in ARCHITECTURE.md (zuletzt 94), Beschreibung in Abschnitt 12.

• T6a (Tasks 1–13, Backend): Schema und Rechte, Tierarzneimittel mit Packungen und Bewegungsbuch, Dokumente, Etikett-Pflichtangaben mit Druck-Sperre und Probedruck, Sperrbezirk, Behördenpaket (Anzeigen, PDFs), Hinweise und Tagesauswertung, Prüfbereitschaft
• T6b (Tasks 14–19, Frontend): Prüfbereitschaft, Tierarzneimittel, Behandlungsmaske mit Mittel/Packung/Dosis, Etikett-Prüfung, Anzeigen und Einstellungen, Sperrbezirk mit Wächtern
• Browserprüfung aller T6-Seiten (Desktop und 390 px, Fehler- und Leerzustände, Tastatur, prefers-reduced-motion)
• Folgepunkt: packagingSize im Backend als @IsInt prüfen, nach Datenprüfung in Produktion (braucht Freigabe)
• Frage an den Inhaber: „Wer darf Etiketten drucken?“ (heute nur ADMIN, Annahme 77)
• Rechtswerte in ComplianceSettings vom Inhaber prüfen lassen (Fristen, Paragraphen, Ziffernhöhen, x-Höhe, Landesrecht Bayern; gegen gesetze-im-internet.de und EUR-Lex)
• Ausrollen in den Cluster – gebaut und getestet, noch nicht ausgerollt (Runbook; Secrets über deploy/k8s/scripts/ensure-secrets.sh)

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.

• Kartenansicht (Bienenstände mit Koordinaten auf einer Karte)
• Wetterintegration / Wetterhistorie je Bienenstand (externe Wetter-API anhand Bienenstand-Koordinaten)
• Trachtprognosen (heuristische Einschätzung aus Wetterdaten + Saison + historischen Ernten, kein ML-Modell)
• Öffentliche Herkunftsseiten für Honigchargen + Kunden-QR-Code (Abschnitt 27: wabenhain.com/herkunft/{lot}, öffentlicher Read-Endpoint)
• Vollständig offlinefähige PWA mit Sync (Service Worker + IndexedDB-Warteschlange für Durchsichten, Sync bei Wiederverbindung)
• NFC-Tags (Web-NFC-API, nur Chrome/Android; kodiert denselben Deep-Link wie der QR-Code; kein Fallback für andere Browser möglich)
• Native Smartphone-App – nicht umsetzbar in diesem Kontext: erfordert eigene native Codebasis, App-Store-Vertrieb und Build-Pipeline ausserhalb einer Web-Session
• 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
• Spracherfassung am Bienenstand, automatische Zusammenfassung einer Durchsicht – nicht umsetzbar in diesem Kontext: erfordert Spracherkennungs-/LLM-Infrastruktur über das bestehende Stack hinaus
• 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
• Backend-Modul fertig, getestet, grün, committet
• 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.