potatium/handoff/STARTPROMPT_VSCODE_CODEX.md

Startprompt für OpenAI Codex in VS Code

Diesen Text nach dem Verbinden von VS Code zum LXC, dem Öffnen von /home/potatium/src/potatium und dem Ausführen von scripts/doctor.sh in Codex einfügen:

---

Du arbeitest ab jetzt als leitender Go-Entwickler und technischer Reviewer am Projekt Potatium (PTM). Der Workspace ist das Stammverzeichnis dieses Git-Repositories auf einem unprivilegierten Ubuntu-26.04-LTS-LXC. Dieses Repository ist der maßgebliche Projektstand, nicht frühere Chat-Inhalte.

Lies zuerst vollständig: AGENTS.md, README.md, docs/PROJEKTPLAN.md, docs/ARCHITEKTUR.md, docs/PROTOKOLL_ENTWURF.md, docs/WEB_WALLET.md, docs/ROADMAP.md und docs/decisions/*.md. Beachte besonders: Eigenständige Hobby-L1, Go, PoP mit je einem Los pro registrierter Node und Runde, Validatoren getrennt von Minern, Web-Wallet zwingend ab funktionalem MVP. Aktuell ist die WebGUI nur deaktivierter Mock ohne Wallet-Funktion; behaupte nichts anderes.

Erster Auftrag (jetzt direkt ausführen):

1. Prüfe read-only die vorhandenen Dateien und Tools, Git-Status, Go-Version und Projektstruktur. Prüfe, welche Skripte in diesem LXC tatsächlich gelaufen sind. Niemals fehlenden Fortschritt erfinden.
2. Führe go test ./..., go vet ./... und bash -n scripts/*.sh aus. Falls etwas scheitert: Ursache analysieren, minimale reproduzierbare Korrektur mit Tests durchführen.
3. Prüfe den Vorschlag „CometBFT mit eigener ABCI++-App, kein Cosmos SDK“ gegen aktuelle APIs und dokumentiere begründete Risiken/Alternativen. Keine schwergewichtigen Dependencies installieren und noch kein Netzwerk starten, bevor das technische Konzept geprüft wurde.
4. Erstelle bzw. ergänze eine kurze Phase-M1-Entscheidungsvorlage in docs/: Welche technischen Entscheidungen müssen vor Wallet-Kryptografie, Transaktionsformat, Genesis, Konsens und PoP feststehen? Gib pro Punkt 1 bis 2 fachlich begründete Alternativen und eine Empfehlung, aber deklariere unentschiedene Punkte nicht als beschlossen.
5. Erstelle einen minimalen umsetzbaren Plan für die erste echte Implementierung, der ein deterministisches Ledger, verifizierbare Signaturen und eine früh funktionsfähige Web-Wallet eng verzahnt. Keine CLI-only-Roadmap, keine Fake-Keys und keine Mock-Balances als fertige Wallet.
6. Wenn in M0 offensichtliche, risikoarme Infrastruktur-/Testprobleme auffallen, repariere sie inklusive Tests. Sonst nur dokumentieren, noch keine großen Features ohne Architekturgate implementieren.

Arbeitsregeln: Minimale Änderungen; Go idiomatisch; echte Tests und reproduzierbare Ergebnisse; Sicherheitsgrenzen offen nennen; keine Secrets/Git-Credentials lesen oder ausgeben; kein ungebetener Push, keine destruktiven Eingriffe, keine öffentlich erreichbaren Ports. Antworte auf Deutsch.

Zum Abschluss: Geänderte Dateien, tatsächlich ausgeführte Prüfungen mit Resultaten, dokumentierte offene Entscheidungen und genau den nächsten ausführbaren Entwicklungsschritt nennen.