29 lines
955 B
Markdown
29 lines
955 B
Markdown
# RFID-Roadmap
|
|
|
|
## Heute schon vorhanden
|
|
|
|
- `rfid_devices` fuer Standortgeraete
|
|
- `rfid_tags` fuer Karten/Chips pro Mitglied
|
|
- `rfid_events` als technische Inbox
|
|
- `/api/rfid/intake` fuer rohe Events
|
|
|
|
## Warum das sinnvoll ist
|
|
|
|
Die spaetere Hardware kann kommen, ohne dass sich das Kernmodell fuer Salden,
|
|
Konsum und Einzahlungen aendert. RFID ist nur ein weiterer Erfassungsweg in
|
|
dieselbe Buchungslogik hinein.
|
|
|
|
## Nächste Ausbaustufen
|
|
|
|
1. Geraet aktivieren und Token-Rotation einfuehren
|
|
2. Dublettenschutz ueber `event_id` und Zeitfenster haerten
|
|
3. Mapping-Regeln `Tag -> Mitglied -> Standardprodukt`
|
|
4. optionale Freigabe- oder Double-Tap-Regeln
|
|
5. Uebernahme von `rfid_events` in echte `consumption_events`
|
|
|
|
## Produktionshinweis
|
|
|
|
Wenn spaeter mehr als HTTPS-Webhooks noetig werden, sollte ein kleiner externer
|
|
Relay-Service zwischen Lesegerät und Webspace geschaltet werden. Das eigentliche
|
|
SaaS-Ledger kann trotzdem auf Netcup-Webspace bleiben.
|