Avalonia Desktop
Vollständiges Cockpit für Stammdaten, Bestand, Einkauf, Preise, Chargen, Pfand und Reporting.
Home OperationsMission Control
Produktentwicklung · verteiltes System
KuraPilot.
蔵
Eine Home-Operations-Plattform, die Vorräte, Einkäufe, Preise, Chargen und Pfand über mehrere Geräte hinweg verlässlich steuert – mit einem unveränderlichen Datenkern statt überschreibbarer Momentaufnahmen.
KURAPILOT · HOME COCKPIT
LIVE OPERATIONS
Haushalt im Überblick
Clients02
Data CoreAPI
IntegrityLedger
Inventory Manifestaus Bewegungen berechnet
AKTUELLShopping Operationsatomar & idempotent
BEREITDevice FleetPairing & Token
SICHERStatusAktiv in Entwicklung
RolleEigenprojekt · Konzeption & Entwicklung
RepositoryPrivat
Verifikation185/185 letzte dokumentierte Abnahme
16.NET-Projekte
197Testmethoden im Code
20Datenbankmigrationen
3Client- & API-Surfaces
Die eigentliche Aufgabe
Bestand ist kein Feld. Er ist eine Geschichte.
Ein Produkt im Schrank scheint simpel – bis mehrere Lagerorte, Teilmengen, Einkäufe, Umlagerungen, Inventuren, Chargen, Mindesthaltbarkeit und Pfand zusammenkommen. Ein einzelner überschriebener Zahlenwert könnte dann nicht mehr erklären, warum der Bestand so ist.
KuraPilot modelliert deshalb jede Veränderung als Buchung. Der aktuelle Zustand entsteht aus der Historie. Selbst komplexe Vorgänge bleiben nachvollziehbar, wiederholbare API-Aufrufe erzeugen keine Doppelbuchungen und Datenbank-Trigger schützen die Journale vor stillen Änderungen.
PHYSICAL EVENTScannen · Kaufen · Verbrauchen · Umlagern
→DOMAIN OPERATIONValidieren · atomar buchen · Idempotenz prüfen
→APPEND-ONLY LEDGERHistorie bewahren · Zustand berechnen
System Architecture
Vom Küchenschrank bis zum Zentralbetrieb.
Alle Oberflächen verwenden dieselben fachlichen Use Cases. Der modulare Monolith hält die Domäne im Zentrum; Clients, HTTP, Datenbanken und Betrieb bleiben klar getrennte Adapter.
Android + Scanner
Kotlin, Jetpack Compose, CameraX und ML Kit verbinden Produkt-, Bestands- und Einkaufsflows mit echten Barcodes.
ASP.NET Core API
Authentifizierte Verträge, ProblemDetails, Idempotenz und atomare Application Use Cases für alle Clients.
PostgreSQL + SQLite
Zentraler Betrieb mit PostgreSQL; SQLite bleibt lokaler Entwicklungsmodus. Beide schützen dieselben Fachregeln.
DESKTOP / ANDROID→ HTTPS →API→APPLICATION→DOMAIN↘ Infrastructure · PostgreSQL / SQLite
Operational Capabilities
Ein zusammenhängendes System statt einzelner Features.
Die Bereiche teilen eine gemeinsame Buchungslogik. Ein Einkauf kann Preisbeobachtungen, Wareneingänge, Chargen, Pfand und Einkaufslisten verändern – innerhalb kontrollierter Transaktionen.
STOCK CONTROL
Bestand mit Herkunft.
Zugänge, Verbrauch, Umlagerung, Inventurkorrektur und Sonderabgang landen im unveränderlichen Bewegungsjournal. Negative Bestände werden verhindert; Lagerorte, Chargen und FEFO bleiben erhalten.
- Feste Dezimalmengen bis drei Nachkommastellen
- Produktfamilien, Kategorien und typisierte Barcodes
- Chargen, MHD und First-Expire-First-Out
- Atomare Transfers zwischen Lagerorten
SHOPPING OPERATIONS
Vom Bedarf bis zum Wareneingang.
Mindest- und Zielbestände erzeugen erklärbare Vorschläge. Einkaufslisten bleiben persistent; der Kaufabschluss schreibt Kaufhistorie, Preis und Bestand als zusammenhängenden Vorgang.
- Automatische und manuelle Listeneinträge
- Nachfüllvorschläge mit gewünschter Menge
- Preisverlauf und Händlervergleich
- Separate Pfandbuchungen und Teilrückgaben
RECEIPT PIPELINE
E‑Bons als prüfbare Evidenz.
PDF-Belege von REWE, Lidl und Netto werden zunächst als Vorschau strukturiert. Erst eine kontrollierte Bestätigung importiert Kauf- und Preisbeobachtungen; der Bestand ändert sich dabei nicht still im Hintergrund.
- Händlerspezifische Parser mit strukturierten Positionen
- Vorschau vor persistenter Übernahme
- Duplikatschutz und UTC-Zeitgrenzen
- Portabler JSON-Export für Betriebsdaten
DEVICE FLEET
Mehrgerätebetrieb ohne statische Secrets.
Desktop und Android registrieren sich über kurzlebige Pairing-Codes. Geräte besitzen widerrufbare Identitäten, signieren den Austausch und erhalten kurzlebige Zugriffstokens mit begrenztem Scope.
- ECDSA-Geräteidentitäten
- Widerruf und Pairing-Audit
- JWT-Bearer und serverseitige Scope-Prüfung
- TLS-Reverse-Proxy vor Loopback-Diensten
Engineering Depth
Gebaut für Betrieb, Migration und Fehlerfälle.
Die Komplexität steckt nicht nur im sichtbaren Produkt. Ein großer Teil des Projekts schützt Daten, Geräte und Betriebsabläufe, wenn etwas wiederholt, unterbrochen oder migriert wird.
Drei geschützte Journale
Bestand, Käufe und Pfand bleiben getrennt, append-only und durch Datenbank-Trigger geschützt.
Idempotente Schreibvorgänge
Stabile Request-Keys verhindern Doppelbuchungen bei Retries und werden im Zentralbetrieb atomar gespeichert.
Backup & Restore
PostgreSQL-Backups, Restore-Abnahme, Monitoring, Update-Skripte und portabler Export gehören zum System.
Mehrschichtige Tests
197 Testmethoden decken Domain, Application, Infrastructure, API, Desktop, Android und Wurschtgate ab.
Kontrollierter Providerwechsel
SQLite-Historien werden nur über dokumentierte, prüfbare Pfade in den PostgreSQL-Zentralbetrieb überführt.
Wurschtgate
Ein eigenes Übergabe- und Tower-Werkzeug verbindet Commits, strukturierte Handovers und Betriebsstatus.
Development Flightplan
Vom lokalen Tool zur Produktplattform.
Jede Etappe hat eine neue Systemgrenze eingeführt. Geplante Phasen sind bewusst keine automatische Implementierungsfreigabe.
- 01–06.5LOCAL FOUNDATIONCOMPLETE
Domäne, Journale und Desktop
Produkte, Lager, Einkauf, Preise, Chargen, Pfand, Reporting und UI-Refactor.
- CK007SERVICE BOUNDARYCOMPLETE
Server & API
HTTP-Verträge, Authentifizierung, Scope-Prüfung und idempotente Schreibvorgänge.
- CK008CENTRAL OPERATIONSCOMPLETE
PostgreSQL & Gerätebetrieb
Migration, Pairing, API-only Desktop, Backup/Restore und E‑Bon-Import.
- CK009MOBILE CLIENTIN PROGRESS
Android Operations
Produkte, Bestand, Einkauf und physischer CameraX/ML-Kit-Scanner; Offline/Sync und Release-Abnahme folgen.
- CK032RELEASE BOUNDARYPLANNED
Public 1.0
Signing, Distribution, Upgrade, Compliance, Accessibility und finale Betriebsabnahme.
Dokumentierter Qualitätsstand
185 / 185 Tests bestanden.
Letzte vollständig dokumentierte Gesamt-Abnahme des zentralen Betriebs: Release-Build ohne Fehler, beide Datenbankmodelle ohne Drift, keine bekannten verwundbaren NuGet-Pakete und physisch geprüfter REWE-E‑Bon-Import. Der aktuelle lokale Kontrolllauf wurde durch Windows Application Control beim Laden gebauter DLLs blockiert und deshalb nicht als neue Abnahme gewertet.
Produkt in Aktion
Drei Arbeitsflächen.
Ein gemeinsamer Bestand.
Die Android-Oberfläche bringt die zentralen Abläufe dorthin, wo sie gebraucht werden: direkt an Vorrat, Einkaufsliste und Regal. Alle Ansichten greifen auf dasselbe fachliche Modell zu.
Bestand, offene Einkäufe und kritische Artikel auf einen Blick.
Produkte suchen, filtern und ihre Mengen direkt am Lagerort prüfen.
Bedarf erfassen und die gemeinsame Liste unterwegs abarbeiten.
Echte Aufnahmen aus einem Android-Emulator mit neutralen, eigens für die Präsentation angelegten Demodaten. Es wurden keine privaten Haushalts- oder Produktionsdaten verwendet.
Produktstatus
Ein ernsthaftes System für einen sehr alltäglichen Ort.
Aktiver Entwicklungsstand: KuraPilot ist der geplante öffentliche Produktname des intern weiterhin als CurryKing geführten Projekts. Die finale Verwendung bleibt von einer vollständigen Markenprüfung abhängig.
- 01Fachlich belastbarer Ledger-Kern statt überschreibbarer Bestände
- 02Desktop, Android und API auf gemeinsamen Use Cases
- 03Sicherer Zentralbetrieb mit widerrufbaren Geräteidentitäten
- 04Reproduzierbare Migrationen für SQLite und PostgreSQL
- 05E‑Bon-, Preis-, Chargen-, MHD- und Pfandprozesse
- 06Dokumentierte Roadmap bis zur Public-Release-Grenze