docs: update Potatium v0.6 architecture and PoP research

docs/PROJEKTPLAN.md

@@ -30,7 +30,7 @@ Potatium (PTM, vor öffentlicher Nutzung Name/Ticker prüfen) ist eine **eigene,
 
 Eine PoP-Runde enthält **drei hintereinander liegende Aufgabenfenster** mit einer neuen, pro Identität/Chain/Runde/Fenster gebundenen, begrenzten PoW-Aufgabe. Fenster 1 ist kostenlos, Fenster 2 und 3 freiwillig und **solange kein gültiges Ticket vorliegt** gegen vorherige bestätigte Gebühren nutzbar. Die Gebühren enthalten jeweils fixe Kosten und eine progressive Komponente. Als Maßstab dienen finalisierte PoP-Gewinne der letzten ungefähr 90 Tage pro registrierter Identität/Betreibergruppe, **nicht die aktuelle Wallet-Balance**; alter Erfolg fällt aus der Bemessung heraus, kein permanent fortschreitender Langzeitvorteil.
 
-Nach dem ersten erfolgreichen Nachweis erhält diese Identität **maximal ein Ticket** und stoppt bis zur nächsten Runde. Lose müssen vor Bekanntwerden eines später verifizierbaren Zufallswerts unwiderruflich feststehen. Die Gebühren für Zusatzfenster werden **verbrannt**; normale Transfergebühren sind zur Validator-Finanzierung vorgesehen, genaue Verteilung offen.
+Nach dem ersten erfolgreichen Nachweis erhält diese Identität **maximal ein Ticket** und stoppt bis zur nächsten Runde. Lose müssen vor Bekanntwerden eines später verifizierbaren Zufallswerts unwiderruflich feststehen. Die Gebühren für Zusatzfenster und Worker werden laut ADR 0007/0008 **zu 100 % in den On-chain-Fonds gebucht und nicht verbrannt**; normale Transfergebühren und Validator-Finanzierung sind noch offen.
 
 Die **Schwelle, Nonce-Raum, Rundendauer, Fensterlängen, Gebührenhöhe, PTM-Emission, Coin-Maximum, Zufallsbeacon und Validatoranzahl** sind weiter unentschieden. Alle genannten Zahlen aus früheren Beispielen bleiben hypothetisch. Pi-4-Benchmark, Simulation und ein neues ADR sind Pflicht vor Implementierung konsenskritischer PoP-Regeln.
 
@@ -47,7 +47,7 @@ Die **Schwelle, Nonce-Raum, Rundendauer, Fensterlängen, Gebührenhöhe, PTM-Emi
 1. **M1:** Architektur-/Coin-/PoP-Parameter dokumentieren, Gebühren-/Fairness-Simulation, Pi-4-Benchmark, ADRs akzeptieren.
 2. **M2:** Ledger, Accounts, deterministischer State, Signaturen, Genesis, Nonce, Tests; **parallel funktionale Web-Wallet** nach festgelegter Schnittstelle.
 3. **M3:** CometBFT anbinden (1, danach 4 Validatoren), Synchronisation/Ausfalltests.
-4. **M4:** PoP-Registry, Fenster, signierte Proofs/Gebühren, Ticketcommit, nachweisbare Ziehung, Mint/Burn und Negativtests.
+4. **M4:** PoP-Registry, Fenster, signierte Proofs/Fondsgebühren, Ticketcommit, nachweisbare Ziehung, Mint-/Fonds-Buchungen und Negativtests.
 5. **M5–M6:** Pi-/Office-PC-Builds, Web-Wallet vervollständigen, private Mehrhost-Tests, Doku/Release.
 
 Jeder Schritt: erst Akzeptanzkriterien, dann kleinste sinnvolle Implementierung, Tests inkl. `gofmt`, `go test ./...`, `go vet ./...`, kurze Dokumentation und Git-Review. Keinen Fortschritt erfinden.
@@ -57,3 +57,23 @@ Jeder Schritt: erst Akzeptanzkriterien, dann kleinste sinnvolle Implementierung,
 Erst **nach M6** dürfen wir getrennte Erweiterungsphasen erwägen: **F1 digitale Sammlerstücke**, **F2 interner PTM-Marktplatz**, **F3 Handelsplattform für fiktive interne Assets mit PTM-Orderbuch, Kursen und Portfolio**, optional **F4 separat gekennzeichnetes Paper-Trading/Börsenlabor**. Diese Phasen sollen PTM als geschlossene interne Währung einen zusätzlichen spielerischen Nutzwert geben, nicht einen angeblichen Fiat-Kurs oder einen Mining-Vorteil erzeugen. Keine implizite Echtgeld-Einlösung, Börsennotierung oder Renditeversprechen.
 
 **Verbindliche Projektgrenze:** Kein F1–F4-Code vor funktionierender Chain, sicherer Wallet und bestandenem Mehrhost-Testnet. Eigentum/Transaktionen müssen kryptografisch überprüfbar sein, Sammlerbesitz beeinflusst die PoP-Lotterie nicht. Für Asset-Minting, sichere Marktorders, Matching, Gebühren und Rechtliches sind vor Implementierung gesonderte Entscheidungen und ADRs nötig. Details in `docs/ZUKUNFT_OEKOSYSTEM.md` und `docs/decisions/0004-zukunftsvision-internes-oekosystem.md`.
+
+## v0.4-Ergänzung: Installationspakete, Cluster und Betreiberidentität
+
+Vereinbartes Produktmodell: **Hub** = eigenständige Full-Node mit eigener GUI, Browser-Wallet und optionalem PoP-Miner. **Worker** = schlanke Mining-Instanz, Hub-abhängig und ohne separate Geld-Wallet. Multi-Hub-/Worker-Cockpit wird priorisiert; Admin-Web erst später, Admin-CLI ab Bedarf. Wallet-/Node-/Miner-/Betreiber-Identitäten bleiben getrennt. Jeder genehmigte Hub-Miner/Worker bis zu ein Ticket/Runde; alle Gewinne/Fees werden pro `operator_id` zusammengefasst und an registrierte Browser-Wallet-Adresse ausgezahlt. Ein gebührenfreier Hub-Mining-Platz pro Betreiber; weitere miningfähige Hubs dürfen nicht als kostenloser Ausweg dienen.
+
+**Noch zu testen:** Worker-Gebühren je Mining-Runde, Tarife, progressive Stufen vs. Pauschalstufen, maximale Worker pro Betreiber (10 nur Simulationskandidat), Fee-Reserve und Failover. Keine bestehenden PoP-Parameter oder Validatorwahl werden dadurch stillschweigend entschieden. Details: `docs/HUB_WORKER_CLUSTER.md`, `docs/WORKER_GEBUEHREN_FORSCHUNG.md`, ADR 0005.
+
+## Betriebsarchitektur und frühe Beobachtbarkeit (ADR 0006, 25.10.2026)
+
+**Wer betreibt was?** `potatium-dev` bleibt reiner Entwicklungs-/Devnet-LXC. Potatium benötigt zusätzlich aktive CometBFT-Validatoren (1 in erster lokaler Devnet-Phase, später vier für Ausfall-/Mehrhosttests), jeweils mit eigener App-DB und eigener Chain-Datenbank, nicht aber einen zentralen Blockchain-SQL-Server. Validatoren zunächst vom Projektbetreiber, später optional von anderen genehmigten Betreibern. Teilnehmer installieren eigenständig Hub-Full-Nodes und Worker; das Wallet-Keymaterial bleibt clientseitig.
+
+**Neue verbindliche UX-Priorität:** Web-Hub-Cockpit und gesondertes **read-only Network-Admin-Cockpit** parallel zum ersten funktionalen Devnet, mit echten Messwerten und transparentem Nichtverbunden-Zustand. Node-/Validator-Aufsicht darf keine on-chain Schreib-, Coin-, Validator- oder Wallet-Schlüssel besitzen; administrative Änderungen erst per geschützten signierten Aktionen in späterer Phase. Ohne Network Admin läuft der Konsens weiter. Monitoring-Historie/Cache kann eine kleine separate Datenbank verwenden, ist aber nicht autoritativ.
+
+Siehe `docs/INFRASTRUKTUR_UND_DEPLOYMENT.md`, `docs/COCKPITS_UND_MONITORING.md`, `docs/decisions/0006-validator-infrastruktur-und-cockpits-ab-devnet.md`. **Gebührenverwendung nach ADR 0007:** 100 % der PoP-/Worker-Gebühren gehen an den On-chain-Fonds; Höhe/Tx-Gebühren/Fonds-Ausgaben sind weiterhin offen. ADR 0003 bleibt historisch dokumentiert und wurde durch ADR 0007 gezielt präzisiert.
+
+## Netzwerkzugang, Identity Admin und Homelab (ADR 0008)
+
+Vereinbarte Vereinfachung: **kein** verpflichtender `potatium-network`-Service, kein Nutzer-Registrierungsportal und keine zentrale Coin-DB. Ein Hub verbindet sich mit überprüfter Chain-ID/Genesis und direkt konfigurierten CometBFT-Peers. Mining-Rechte werden über On-chain-Registry mit protokollautorisierter Freigabe/Sperre verwaltet. Ab erstem lauffähigem Devnet: eigenständiges echtes Hub-Cockpit und separates Network Admin mit bestätigten Supply-/Burn-/Fonds-/Fees-/Identitäts-/Validatorwerten. **Frühe schreibende Admin-Funktionen ausschließlich signierte Freigabe/Sperre**, erst sobald die Register- und Signaturprüfungen implementiert sind. Monitoring-SQL optional, keine Pflicht-Control-Plane. Fonds: 100 % PoP-/Workergebühren, kein Burn. Tarife und Fonds-Ausgaben offen.
+
+Auswertung: `docs/POP_DYNAMIK_FONDS_AUSWERTUNG_2026-10-25.md`, die Modelle sind keine Konsensparameter. Infrastrukturplan: `docs/INSTALLATIONSPLAN_HOMELAB.md`, ADR 0008.