docs: update Proof of Potato model to v0.2

AGENTS.md

@@ -1,14 +1,12 @@
-# Codex-Projektregeln für Potatium
+# AGENTS.md: verbindliche Leitlinien für Codex im Potatium-Repository
 
-Diese Datei ist die kurze, maßgebliche Arbeitsanweisung für alle Coding-Agenten.
-
-1. **Projekt verstehen:** `README.md`, `docs/PROJEKTPLAN.md`, `docs/PROTOKOLL_ENTWURF.md`, `docs/ROADMAP.md`, `docs/WEB_WALLET.md` zuerst lesen. Entscheidungen (`docs/decisions`) beachten. Ungeklärte Punkte nicht als festgelegt ausgeben.
-2. **Sicherer Anfang:** Das vorhandene Repository ist nur ein compilierbares Grundgerüst. `potatiumd` zeigt eine statische Web-Wallet-Vorschau, hat noch keine Blockchain, keine Schlüsselverwaltung und keine echte API. Implementierten Status ehrlich halten.
-3. **Architektur:** Go, CometBFT + ABCI++ als vorläufiger Stack; eigenständige PoP-Miner und Validatoren getrennt. UI **ab erster funktionaler MVP-Version**, nicht verschieben.
-4. **Mining:** Ein gültiges Los je freigegebener Node-ID pro Runde; kleine PoW-Aufgabe; Teilnehmermenge fixieren, dann erst überprüfbare Zufallszahl ziehen; keine offensichtlichen Mehrfachlose; manuelle Nodefreigabe löst Sybil-Problematik nur organisatorisch.
-5. **Wallet-Sicherheit:** Kein privater Schlüssel/Seed ans Backend oder ins Git. Browser-Krypto erst auf Basis einer explizit geprüften Schlüssel-/Signaturspezifikation und gepflegter Bibliotheken. Den UI-Entwurf nicht als funktionale Wallet verkaufen.
-6. **Arbeitsweise:** Zuerst Bestandsaufnahme und kurze Umsetzungsplanung, dann kleine überprüfbare Änderungen. Keine unbegründeten neuen Frameworks oder großen Abhängigkeiten. Keine produktiven Ports nach außen.
-7. **Prüfen:** `gofmt`, `go test ./...`, `go vet ./...`, Shell-Syntaxprüfung; bei Bugs Regressionstest. Tests und Grenzen nennen, nichts erfinden.
-8. **Docs synchron:** Architektur-/Protokollentscheidungen in `docs/decisions/` mit Status Proposed/Accepted/Rejected; Roadmap aktualisieren. Keine stillschweigenden Änderungen bereits angenommener Produktziele.
-9. **Git:** Kleine logisch getrennte Commits vorschlagen; nicht ungefragt pushen, remotes überschreiben oder irreversible Befehle ausführen.
-10. **Zielplattform:** Ubuntu Server 26.04 LTS im unprivilegierten Proxmox-LXC; Builds später für Linux AMD64/ARM64; Raspberry Pi 4 als Zielreferenz.
+1. **Zuerst lesen:** `README.md`, `docs/PROJEKTPLAN.md`, `docs/PROTOKOLL_ENTWURF.md`, `docs/POP_FAIRNESS_UND_GEBUEHREN.md`, `docs/ROADMAP.md`, `docs/WEB_WALLET.md`, `docs/decisions/*.md`. Die letzte akzeptierte ADR entscheidet bei historischen Widersprüchen. Der *tatsächliche Git-Stand* ist maßgeblich.
+2. **Bestandsaufnahme:** Umgebung Ubuntu 26.04 LTS im unprivilegierten LXC, Workspace `/home/potatium/src/potatium`, Go, private Gitea-Git-Remote. Bestehende Änderungen erhalten; nicht ungefragt branch/rebase/push oder `git clean/reset` verwenden.
+3. **Architektur:** eigenständige Hobby-L1, Go, CometBFT/ABCI++ mit eigener deterministischer App als vorläufige Wahl, kein Cosmos SDK für den Start. Validatoren bestätigen Blöcke, Miner lösen nur PoP-Challenges. `linux/amd64` und `linux/arm64` als Ziel; Pi 4 als Benchmarkminimum.
+4. **PoP v0.2 (akzeptierte Produktidee):** Jede Mining-Runde hat **3 zeitlich getrennte Fenster**. Fenster 1 gratis; Fenster 2/3 optional solange noch kein gültiges Ticket angenommen wurde und nach bestätigter **fixer + progressiver** Gebühr. Progressionsbasis: finalisierte PoP-Mining-Gewinne der zurückliegenden **ca. 90 Tage je registrierter Mining-Identität/Betreibergruppe**, **nicht Wallet-Guthaben**. Keine lebenslange Benachteiligung. Zusatzgebühren burnen; normale Transaktionsgebühren sollen Validatoren finanzieren, Aufteilung noch offen. Pro identifizierter Mining-Node **maximal ein Ticket je Gesamtrunde**. Nach Erfolg stoppen. Identität/Hardware und Betreiberzuordnung können Sybil nicht kryptografisch beweisen.
+5. **Noch nicht entschieden:** BTC-artige Coin-Grenze, Mint je Runde, Gebührenbeträge/Schwellen, Nonce-Raum, exakte Fensteranzahl an Blöcken, p=70 %, feste Blockzeit, Wallet-Kryptografie, Beaconauswahl. Beispiele niemals als gültige Konsensregel kodieren. Vor PoP-Implementierung Simulationen und Pi-Messung samt ADR.
+6. **Ziehung:** Ticketbestand vor künftiger überprüfbarer Zufallsquelle finalisieren. Kein `time.Now()`, externe Zufallsabfrage oder Float in deterministischen State-Transitions. Reorgs, Zeit-/Höhenfristen, Beacon-Ausfall, Zensur, Replay, Rundungsrest und Multi-Node-Gleichheit behandeln.
+7. **Gebühren/Wallet:** Browser-Web-Wallet **ab erster funktionaler MVP-Version**; Keys erzeugen, importieren, verschlüsselt sichern/entsperren, Adresse, Balance, senden/empfangen, Verlauf/Netzstatus. Miner/Node erhalten nie Private Keys/Seeds. Zusatzfenster nur mit explizit begrenzter signierter Wallet-Freigabe, auf Runde/Identität/Fenster, Betrag, Nonce und Ablauf gebunden; noch nicht implementiert. UI-Vorschau niemals als funktionsfähig ausgeben.
+8. **Tests:** Go `gofmt`, `go test ./...`, `go vet ./...`; passende Integrationstests, fuzzer/race tests. Für PoP Simulation und Pi 4 / Office-PC Benchmark, Fairness, Gebühren-Erwartungswerte, abweichenden Codepfad, Replay, Burn und Restart. Tests und Resultate **nie erfinden**.
+9. **Sicherheit:** keine öffentlich gebundenen Test-APIs (nur `127.0.0.1`/SSH-Forward), keine echten Schlüssel/Tokens/Datenbank-/Wallet-Dateien in Git. Keine unverhältnismäßigen Dependencies, keine destruktiven Befehle ohne Backup. Entgeltliche Chance auf Lotteriegewinn birgt Rechtsrisiko; bis auf Weiteres **wertlose private Test-PTM**.
+10. **Lieferstil:** Vor jeder größeren Änderung kurze Planung + Akzeptanzkriterien; danach Dateien/Änderungen, was real läuft, Testbefehle mit Ergebnissen, Grenzen und nächsten kleinen Schritt angeben. ADR für wesentliche Entscheidungen.