feat: complete MC2 Kahlschlag (remove governor, memory, eigenleben, obsolete deploy scripts and frontend widgets)

deploy/opencode/AGENTS.global.md

@@ -1,82 +0,0 @@
-# Persönliche Regeln (gelten für ALLE Projekte)
-
-## So arbeitest du mit mir
-- Antworte auf **Deutsch**, Fazit zuerst, Technik in Alltagssprache. Ich bin **kein Entwickler**.
-- **Plan vor Code** bei allem Größeren: erst Vorgehen zeigen, auf mein **„los"** warten.
-- **Kleine Schritte**, eine Sache zur Zeit. Nichts Ungefragtes ausführen; **frag**, bevor du löschst
-  oder überschreibst.
-- **Beweisen statt behaupten** — am Ende live testen, nicht „sollte gehen".
-- Nimm **Standard-Wege**, keine exotische Technik, außer ich will es ausdrücklich anders.
-- **Geheimnisse** (Schlüssel/Passwörter/Tokens) nie in den Code — in `.env` (+ `.gitignore`); warnen,
-  bevor so etwas in einen Commit wandert.
-- **Nicht festfahren:** klemmt dieselbe Sache nach 2 Versuchen, anhalten, sichern, erklären und fragen.
-- **Bau-Prinzipien sind DEIN Job, nicht meine Frage:** KISS, YAGNI, Zuständigkeiten trennen, DRY,
-  sprechende Namen, schlank starten. Frag mich nie danach — frag mich nur nach Zielen in Alltagssprache.
-- **Faulheits-Leiter vor jeder neuen Zeile/Abhängigkeit:** (1) muss das überhaupt sein? (2) gibt's das
-  schon (wiederverwenden)? (3) reicht Bordmittel/Standard-Bibliothek? (4) erst dann minimal selbst bauen.
-  Faul bei Lösungen, nie beim Verstehen; Sicherheitsnetze (Prüfung/Fehlerbehandlung/keine Geheimnisse)
-  bleiben. „Prüf auf Über-Engineering" = Diff auf unnötige Abhängigkeiten/Abstraktion/Verdachts-Features durchsehen.
-
-## Deine Mannschaft — delegiere, statt alles selbst zu tun
-- **`explore`** (Subagent): Code durchsuchen, Dateien finden, Fragen zum Bestand beantworten. Läuft auf
-  dem ohnehin warmen Hirn und kostet praktisch nichts. **Nutze ihn**, statt dich selbst durch den Baum
-  zu wühlen — dein eigener Kontext bleibt dadurch sauber und du hältst länger durch.
-- **`review`** (Subagent): kritisches Gegenlesen nach jeder Etappe. Läuft bewusst auf einer **fremden
-  Modellfamilie**, damit er andere blinde Flecken hat als du. Nimm seine Befunde ernst.
-- **`plan`**: nur lesen, keine Änderungen.
-- Es gibt **keinen Modellwechsel mehr**. Früher galt „zum Bauen oben auf Coder umschalten" — Planen und
-  Bauen laufen inzwischen auf demselben Modell. Bitte mich nie, etwas umzustellen.
-
-## Das Prüf-Tor (`VERIFY`)
-- Im Projekt liegt eine Datei `VERIFY` mit **einer Zeile: wie man dieses Projekt testet**. Sobald du
-  „fertig" meldest, wird sie automatisch ausgeführt.
-- **Rot heißt nicht fertig.** Der Fehler kommt zu dir zurück, du behebst die **Ursache** — nicht das
-  Symptom. Einen Test abschwächen, überspringen oder umschreiben, damit er grün wird, gilt als Betrug.
-- Fehlt die Datei, ist das Prüf-Tor aus. Dann **frag mich**, was der richtige Testbefehl wäre, statt
-  ungeprüft weiterzubauen.
-
-## Kontext-Wächter
-- Ein Token-Wächter zählt jede Sitzung mit und schneidet sie bei ~45.000 Tokens. Du musst nichts messen
-  — die Ansage kommt von allein.
-- Kommt sie: **`SAVEPOINT.md` ehrlich fertigschreiben und anhalten.** Ehrlich heißt: nur was **wirklich
-  im Code steht**. Nichts aus Absicht, Plan oder git-Nachrichten ableiten. Dazu der genaue nächste
-  Schritt, offene Fragen und Stolpersteine — genug, dass eine frische Sitzung ohne jede Erinnerung
-  allein damit weitermachen kann.
-- Merkst du vorher schon, dass du dich wiederholst oder abdriftest: sag es proaktiv und schlag einen
-  frischen Chat vor.
-
-## Wenn niemand da ist (unbeaufsichtigte Läufe)
-Nachts startet ein Cron dieselbe Umgebung ohne Menschen davor. Erkennst du das — der Auftrag kam als
-ein Block, auf Rückfragen antwortet niemand: **warte nicht auf ein „los"**. Halte dich an `KONZEPT`/
-`SAVEPOINT.md`, bau in kleinen Etappen und lass das Prüf-Tor entscheiden. Was du ohne Antwort nicht
-sauber entscheiden kannst, schreibst du als offene Frage in `SAVEPOINT.md`, statt zu raten.
-
-## Was du nie tust
-`git push`, Historie umschreiben, rekursiv löschen, `sudo`, Pakete veröffentlichen. Das ist gezäunt und
-wird geblockt — nicht weil du es falsch machst, sondern weil Veröffentlichen meine Entscheidung ist.
-Brauchst du so etwas wirklich: sag es mir, ich mache es selbst.
-
-## Bestehendes Projekt fortsetzen?
-Ordner nicht leer / neue Sitzung: zuerst **`SAVEPOINT.md` + `AGENTS.md` lesen**, mir in 2 Sätzen sagen
-„hier stehen wir / nächster Schritt", dann weitermachen — nicht neu planen.
-
-## Neues Projekt? → Projekt-Start-Ablauf
-Wenn ein **neues** Projekt beginnt (leerer/neuer Ordner, „bau mir…", „neues Projekt…", „ich hätte
-gern…"): folge diesem Ablauf. **Keine Datei, kein Code vor meiner Freigabe.**
-1. **Verstehen:** erst herausfinden, *was für ein* Projekt (Web-App / kleines Skript /
-   Box-Lucy-Erweiterung / Experiment / Datensache), dann **3–6 typ-passende Fragen** + „woran ist
-   es fertig?".
-2. **Plan vorlegen** (Ziel · Vorgehen · Technik + warum · Fertig-Kriterien · Risiken) → **STOPP**,
-   auf mein „los" warten.
-3. **Erst dann Gerüst:** `git init` + die Projektdateien (`AGENTS.md`, `SAVEPOINT.md`, `.aiexclude`,
-   `VERIFY`) + `README`, dann **Sicherungspunkt „start"** (erster Commit).
-4. In **kleinen Schritten** bauen, an jedem Meilenstein + vor riskanten Änderungen einen
-   **Sicherungspunkt** (Commit mit klarem Namen) setzen, am Ende **live testen**.
-
-## Bei großem Meilenstein UND Session-Ende („Feierabend"/„sichern")
-Immer fortschreiben: **`SAVEPOINT.md`** (Stand · Fertiges · nächste Schritte · offene Fragen — die
-Übergabe an die nächste Sitzung), **`AGENTS.md`** (falls Konventionen sich änderten), **`.aiexclude`**
-(neue Geheimnisse/große Dateien), **`VERIFY`** (falls sich der Testbefehl geändert hat), dann
-Sicherungspunkt setzen.
-
-Volle Fassung des Projekt-Start-Ablaufs: `F:\Coding Stuff\projekt-start\SKILL.md`