# AGENTS.md

## Regeln fuer dieses MediaWiki-Projekt
- Arbeite vorsichtig und nicht destruktiv.
- Keine echten API-Keys oder Zugangsdaten ins Repository schreiben.
- Respektiere bestehende MediaWiki-Strukturen, Templates und Erweiterungen.
- Groessere Aenderungen zuerst knapp planen, dann schrittweise umsetzen.
- Prompt-Dateien liegen in `extensions/AiMoocGenerator/prompts/`.
- Provider-Logik, Renderer und MediaWiki-Artikelanlage sauber getrennt halten.
- Bei Unsicherheit lieber Platzhalter, TODOs und example-Dateien anlegen als riskante Produktivaenderungen.

## Codex-Plugins / autonomer Arbeitsmodus
- Passende installierte Codex-Plugins eigenstaendig nutzen, wenn sie die Aufgabe sicherer, schneller oder qualitativ besser machen.
- Zentrale Codex-/Connector-Policy: `docs/CODEX_PROJECT_SETTINGS.md` beachten und bei neuen Tools aktuell halten.
- `build-web-apps` und Browser fuer Webentwicklung, UI-Checks, lokale visuelle Tests und Frontend-Debugging einsetzen.
- `codex-security` fuer Security-Scans, Diff-Reviews, Threat-Modeling und vorsichtige Pruefung von MediaWiki/PHP/JS verwenden.
- `github` fuer Issues, PRs, CI, Reviews und Release-Arbeit nutzen, sofern das jeweilige Projekt ueber GitHub laeuft.
- `google-drive`, Documents, Spreadsheets und Presentations fuer redaktionelle Dokumente, Tabellen, Unterrichtsmaterial, Verlagstexte und Praesentationen einsetzen.
- `figma` und `canva` fuer Layouts, Cover, Marketingmaterial, Website-Prototypen und Design-to-Code-Arbeit verwenden.
- `build-web-data-visualization` fuer Dashboards, Lern-/Content-Statistiken, Projektberichte und Datenvisualisierungen einsetzen.
- Externe Connectoren nur mit freigegebenen Konten und ohne Ausgabe von Secrets oder personenbezogenen Schueler:innendaten verwenden.
- GitHub-Connector bevorzugt mit ausgewaehlten Repositories, PR-Templates und CI-Gates nutzen; keine pauschalen Privat-Repo-Freigaben.
- Slack nur fuer Status, PR-Entwuerfe und kurze Arbeitsauftraege nutzen; keine Rohlogs, Secrets oder Schueler:innendaten posten.
- Linear nur nutzen, wenn dort wirklich Aufgaben gepflegt werden; sonst GitHub Issues/Projects bevorzugen.
- Plugin-Autonomie hebt die Server-, Datenschutz-, Secret- und Live-Freigaberegeln in dieser Datei nicht auf.

## Serverwechsel / CCX33
- CCX33-Staging ist die Entwicklungsbasis: `https://staging.moocwiki.org`.
- Aenderungen zuerst lokal lesen/planen und dokumentieren, dann kontrolliert auf Staging testen.
- Serverwechsel ist als Staging-Migration abgeschlossen; Migration nicht unnoetig weiter ausdehnen.
- Keine Live-Domain-Aenderung ohne explizite Freigabe.
- Keine Live-Datenbank veraendern ohne Backup, Restore-Plan und explizite Freigabe.
- Keine Strato-Daten loeschen.
- Produktive `LocalSettings.php`, `.env.local` und Secret-Dateien nicht ausgeben und nicht in Pakete uebernehmen.
- Keine `.env`-Dateien lesen; `schulduell/.env.local` bleibt tabu.
- Fuer echte Serverbefehle Logdateien mit Zeitstempel vorsehen.
- Keine Secrets in Logs, Chat, Repository oder Browserausgaben.
- Externe KI fuer Schueler:innen bleibt deaktiviert, bis Datenschutz, Rollen, Limits und Gates bestanden sind.
- Keine produktive externe KI ohne Freigabe.
- Keine Google-OAuth-Produktivaktivierung ohne Freigabe.
- Keine echten Schueler:innendaten in Tests.
- PHP-Lint, JS-Checks und passende Gates nach Aenderungen ausfuehren.
- Immer Rueckfallmoeglichkeit dokumentieren.
- Groessere Aenderungen in kleine Arbeitspakete teilen.

## noahROBOT / Hardware-Gate
- Der reale noahROBOT bleibt bis zur schriftlichen Hardwarefreigabe im Modus `simulation-only`.
- Keine Firmware flashen, keine seriellen Ports schreibend oeffnen, keine Motoren bestromen und keine Betriebssystem-, Hotspot- oder systemd-Installation ohne gesonderte Freigabe ausfuehren.
- Beim Start, Reset, Parserfehler, Heartbeat-Ausfall, Verbindungsverlust und Dienstende ist der Sollzustand immer `STOP`.
- Pinbelegung, Motor-Nennspannung, Motor-Stallstrom, Motorstromversorgung, L298N-Boardvariante und Not-Stopp-Verdrahtung nie raten. Sie muessen in `docs/WIRING.md` bestaetigt sein.
- Ein LLM darf nur semantische Absichten vorschlagen. Nur deterministische, allowlist-basierte Sicherheitslogik darf daraus begrenzte RobotCommand-Nachrichten erzeugen.
- Browser-, WebSocket- oder API-Nachrichten duerfen nie ungeprueft an den Funduino oder Motortreiber weitergereicht werden.
- Ein physischer, rastender Not-Stopp muss die Motorenergie unabhaengig von Browser, Mini-PC, USB und Firmware unterbrechen koennen.
- Erste Motortests nur mit frei drehenden Raedern, strombegrenzter Versorgung, erreichbarem Not-Stopp und zweiter beobachtender Person planen.
- Tests verwenden synthetische Daten. Audio, Video, Gespraechsinhalte, PINs und Tokens gehoeren nicht in Betriebslogs.
- Verbindliche Planungsdokumente: `docs/HARDWARE.md`, `docs/ARCHITECTURE.md`, `docs/INSTALLATION.md`, `docs/WIRING.md`, `docs/SERIAL_PROTOCOL.md`, `docs/SAFETY.md` und `docs/MAC_REMOTE_SETUP.md`.
