adsd

custom/apps/mining-checker/docs/README.md

@@ -2,7 +2,7 @@
 
 ## Zweck
 
-Das Modul erfasst DOGE-Mining-Messpunkte, analysiert OCR-Vorschlaege aus Screenshots, speichert Messreihen projektbezogen und berechnet Performance-, Kurs- und Zielmetriken.
+Das Modul erfasst Mining-Messpunkte der aktuell konfigurierten Kryptowaehrung, analysiert OCR-Vorschlaege aus Screenshots, speichert Messreihen projektbezogen und berechnet Performance-, Kurs- und Zielmetriken. `DOGE` ist lediglich die aktuelle Konfiguration, nicht eine fest verdrahtete Fachregel.
 
 ## Ordnerstruktur
 
@@ -124,3 +124,31 @@ Zusaetzlich koennen in den Settings diese Leitwerte hinterlegt werden:
 - Zielminer-Laufzeit in Monaten
 
 Die Uebersicht berechnet daraus automatisch den theoretischen Preis des Zielminers, den benoetigten Krypto-Gegenwert und die Resttage bis zur theoretischen Anmietung auf Basis des letzten Uploads.
+
+## Verbindliche Fachregeln: Wallet, Miner und Wertentwicklung
+
+Diese Regeln sind bei jeder Erweiterung der Wallet-, Miner- oder Uebersichtslogik einzuhalten.
+
+1. Ein Miner wird zu einem festen Zeitpunkt gemietet. Fiat-Mieten koennen bei Ablauf zum gleichen Preis verlaengert werden; Krypto-Mieten haben eine feste Laufzeit.
+2. Erwirtschaftete Coins bleiben zuerst im Mining-Tool. Erst ein erfasster Transfer aus dem Mining-Tool erhoeht den Bestand des hier verfolgten Wallets.
+3. Solange Coins im Mining-Tool oder im Wallet liegen, wird ihr Gegenwert mit dem aktuellen Kurs der jeweiligen Waehrung bewertet.
+4. Wird ein Miner mit der Kryptowaehrung bezahlt, reduziert der Kauf den Walletbestand um den gezahlten Coin-Betrag. Gleichzeitig wird dessen Fiat-Gegenwert zum Kaufzeitpunkt als feste Buchung gespeichert. Dieser Betrag darf durch spaetere Kursaenderungen nicht mehr beeinflusst werden.
+5. Ein Wallet-Screenshot ist fuer seinen Zeitstempel autoritativ. Sein erkannter Hauptbestand ueberschreibt die rechnerische Wallet-Historie bis zu diesem Zeitpunkt; erst danach werden weitere Transfers, Krypto-Minerkaeufe und externe Wallet-Auszahlungen verrechnet.
+6. Jede erfasste Auszahlung aus dem Mining-Tool muss den Walletbestand automatisch fortschreiben. Externe Auszahlungen aus dem hier verfolgten Wallet reduzieren ihn.
+7. Der angezeigte bisherige Wert ist die Summe aus aktuellem Gegenwert im Mining-Tool, aktuellem Gegenwert im Wallet und allen festgeschriebenen Gegenwerten von mit Krypto bezahlten Minern.
+
+### Historische Krypto-Miner
+
+Beim Schema-Upgrade werden vorhandene Krypto-Miner einmalig bewertet:
+
+1. Gibt es einen Referenzpreis in einer anderen Waehrung als der gezahlten Kryptowaehrung, wird dieser als historisch nachvollziehbarer, fester Gegenwert verwendet.
+2. Fehlt eine belastbare historische Referenz, wird der ausgegebene Coin-Betrag mit dem fest vereinbarten Fallback `0,07 EUR` pro Coin bewertet und dauerhaft gespeichert.
+3. Die feste Bewertung wird in `settled_value_amount` und `settled_value_currency` des jeweiligen gekauften Miners gespeichert. Das Schema-Upgrade ist nach dem Deployment auszufuehren.
+
+## Verbindliche Fachregeln: Zielminer-ETA
+
+1. Die Zielminer-ETA basiert ausschliesslich auf dem letzten Mining-Upload, dessen Coin-Bestand und dessen durchschnittlicher Tagesrate (`doge_per_day_interval`, technisch historisch benannt).
+2. Die absolute ETA lautet: `Zeitpunkt letzter Upload + (am Upload fehlende Coins / durchschnittliche Coins pro Tag)`.
+3. Die angezeigte Restzeit ist die Differenz zwischen dieser festen ETA und der aktuellen Zeit. Sie muss bis zum naechsten Upload weiter herunterlaufen und darf nicht durch eine Neuberechnung ab der aktuellen Zeit nach hinten verschoben werden.
+4. Ein neuer Upload ersetzt die Berechnungsbasis durch seinen dann aktuellen Bestand und seinen neu ermittelten Durchschnitt.
+5. Die Begriffe `DOGE pro Tag` in historischen Feldern sind technische Altbezeichnungen. Fachlich beziehen sie sich immer auf die aktuell konfigurierte Mining-Kryptowaehrung.

docs/WEITERENTWICKLUNG.md

@@ -85,6 +85,7 @@ Bei jeder groesseren Aenderung ist zu pruefen:
 3. Braucht ein Unterordner eine gepflegte `README.md`
 4. Muessen zentrale Dateien angepasst werden
 5. Ist der Inhalt spaeter fuer einen Hilfebereich relevant
+6. Wurden fachliche Berechnungs- oder Buchungsregeln geaendert, muss die aktive Modul-Dokumentation im selben Change aktualisiert werden. Code ohne passende Fachregel-Dokumentation gilt nicht als abgeschlossen.
 
 ## Aktuell wichtige Projektregeln