Files
planer/phase0/erkenntnisse.md
2026-07-22 16:12:23 +02:00

7.9 KiB
Raw Blame History

Phase-0-Erkenntnisse (Scan-Validierung am Creator)

Testfall: backend/kanban.py (269 Zeilen) → Einheiten-Datei nach docs/format.md. Prompt: prompt-einheiten.md, Prüfung: pruefe.py, Ergebnisse: beispiel-einheiten-*.md.

Läufe (2026-07-09)

Lauf Modell Mechanisches Ergebnis
v1 M2.7-highspeed (kalt) 9 Einheiten, volle Abdeckung, 0 falsche Anker/Kanten — aber 6 Zitat-Fehler (mehrzeilige Statements zusammengezogen) + 1 Kanten-Formatfehler
v2 M2.7-highspeed (kalt), geschärfter Prompt schlechter: beleg-Format gedriftet (inline), 9 Zitat-Fehler, davon 1 echte Fabrikation (f-String zu %-Formatierung umgeschrieben), 1 Einheit vergessen; davor 1 Stall (7-min-Timeout, bekanntes kalt-Routen-Problem)
v3 M3 (nativ) 0 Fehler: alle 26 Zitate wörtlich, Format exakt, Kanten-Richtungen korrekt, Innenfunktionen sauber als Zusatz-Anker; 1 Einheit vergessen (_progress — von der Abdeckungsprüfung gefangen)

Erkenntnisse

  1. Das Zitat-Treue-Gate funktioniert und ist nötig — es hat in v2 eine echte Code-Fabrikation gefangen (paraphrasiertes Zitat). Kernannahme von Phase 0 bestätigt: mechanische Gates machen billige Modelle sicher benutzbar.
  2. Modellwahl fürs Schneiden/Fakten: M3, nicht M2.7-highspeed. M2.7-HS ist bei wörtlichen Zitaten unzuverlässig (und Prompt-Schärfung hat es nicht behoben — v2 war schlechter als v1). M3 war fehlerfrei. Später per Telemetrie neu bewerten.
  3. Kein Lauf war vollständig UND fehlerfrei zugleich → die Pipeline braucht den Nachfass-Schritt: Abdeckungsprüfung meldet fehlende Symbole, ein Folge-Call ergänzt nur diese (Karten-Retry der Kanban-Engine passt dafür).
  4. Formattreue schwankt zwischen Läufen (v2: beleg inline statt eigene Zeile) → Grammatik-Parse-Fail = Retry (Engine kann das); Prüfskript parst tolerant, wo es den Prüfzweck nicht schwächt.
  5. kalt-Routen-Stalls bestätigt (1 von 3 kalt-Calls hing) — Timeouts + Retry sind Pflicht, wie im Creator.
  6. Format-Anpassungen aus der Praxis: Zusatz-Anker dürfen verschachtelte Symbole sein (Innenfunktionen); beleg muss Ausschnitt GENAU EINER Quellzeile sein (steht jetzt im Prompt und in docs/format.md nachzuziehen).

Zweiter Block (gleicher Tag): Nachfass, weitere Dateien, Feature-Sicht

  1. Nachfass-Kreislauf funktioniert end-to-end. kanban.py nach Nachfass: 9 Einheiten, 31 Belege, 0 Fehler, 0 Warnungen. pipeline.py nach geschärftem Nachfass: 17 Einheiten, 52 Belege, volle Abdeckung.
  2. Nachfass braucht eine harte Regel gegen Wegsortieren: M3 nutzte ergaenze-anker zunächst als Fluchtweg (alle 16 fehlenden Symbole in bestehende Einheiten gefaltet, fachlich teils falsch). Fix im Prompt: ergaenze-anker NUR für unselbstständige Hilfssatelliten, im Zweifel eigene Einheit — danach korrekt.
  3. Neuer M3-Fehlermodus: Thinking-Overrun. Bei pipeline.py dachte natives M3 bis ans 32k-Token-Limit und lieferte LEEREN Text (2× hintereinander, je >21k Tokens unsichtbar verbrannt). Erkennbar an: leere Ausgabe + Output-Tokens am Limit. Pipeline-Regel: leere Ausgabe = Fehler + Retry; Token-Zähler aus der OpenCode-Session-DB loggen. M3-kalt (ohne Thinking) als Ausweichroute lief, stallte aber 1× und deckte schwächer ab (6/22 Symbolen) → Erst-Scan nativ-M3, bei Overrun Retry, Lücken macht der Nachfass zu.
  4. Zitat-Gate fängt auch Minimal-Umformungen: config.py-Zitat war fast richtig (Tupel-Teil weggelassen) — existiert so nicht im Code. Genau die gefährliche Klasse.
  5. Escaping-Rauschen normalisieren: Modelle verdoppeln Backslashes in Zitaten (\\n statt \n) → Prüfskript entschärft \" und \\ vor dem Vergleich.
  6. Feature-Sicht aus Einheiten allein funktioniert. M3 aggregierte aus 42 Einheiten (kanban+pipeline+config, ohne Quellcode!) eine lesbare Sicht: 3 Bereiche, 13 Features, Fähigkeits-Sprache, plausible kern/rand-Flags, 0 kaputte Referenzen, unreferenziert nur echte interne Helfer. Kernannahme „Sichten = billige Aggregation über Einheiten" bestätigt. → beispiel-features.md

13a. Parallele OpenCode-Kaltstarts hängen (2× reproduziert: drei gleichzeitige opencode run → alle Exit 124, keine Session erzeugt; sequenziell läuft es). Der Creator serialisiert Starts deshalb mit einer Stagger-Sperre (_opencode_start_lock, _OPENCODE_START_DELAY) — die MUSS mit übernommen werden.

  1. Infra-Fehlerklassen gesehen und unterscheidbar: (a) harter Stall (inventory:

    1 h tot, kein Output, Session offen), (b) Thinking-Overrun (Output-Tokens am Limit, leerer Text), (c) Netzausfall (Exit 124/Timeout, KEINE Session in der DB, leeres Stderr). Alle drei enden in leerer Ausgabe — die Pipeline muss sie an den Signalen unterscheiden: (c) pausiert den Lauf (Provider nicht erreichbar, Leitprinzip 2), (a)+(b) sind Retry-Fälle. Erreichbarkeits-Check vor Lauf-Start ist Pflicht.

Phase-1-Abnahme (Creator-Scan, 2026-07-09 nachmittags): Befunde der ~3h-Untersuchung

  1. Sechs Läufe, 614 MiniMax-Calls, 2,16M Input-/1,29M Output-Tokens, ~35 min echte Rechenzeit — der Rest der Zeit ging an: (a) meine Prozess-Orchestrierung (pkill traf falsche PIDs → Lauf 2+3 parallel auf EINEM Board → Kartenchaos; tail-Pipe puffert → kein Live-Output), (b) einen ungeklärten Hänger, (c) Iterationszyklen.

  2. Gefixt & belegt: blinde Retries (→ Befund-Feedback), halluzinierte Kanten/Anker (→ mechanische Streichung), fast-richtige Zitate wie :== (→ Fenster-Snap), Barriere-Loch (sammeln drainte vor Producer-Ende — Beweis: Sichten-Calls mit 868 vs. 36.688 Input-Tokens; → gate=research_done), Working-Tree-Check stolperte über eigene .planer-Dateien (→ Ausnahme), Kaskadentod beim Schreiben (→ degradierend).

  3. OFFEN — Hänger: Prozess lebt nach Board-Ende weiter (47 min solo-idle belegt, 15s CPU, futex). Parallel-Läufe als Alleinursache durch Timeline widerlegt; alle LLM-/DB-Pfade haben Timeouts. Verdachtsklasse: ein nie endender Processor-Task hält den Flow über den Aktiv-Zähler wach. SIGUSR1-Stackdump ist jetzt eingebaut — der nächste Hänger liefert den Stack.

  4. OFFEN — Zitate mit eingebetteten Anführungszeichen/Regex (z. B. re.sub-Muster) brechen Parse (greedy Quote-Regex) und Snap → 3 hartnäckig tote Chunks.

  5. OFFEN — Skript-Dateien ohne def/class (creator/projects/ragsystem): Modell erfindet Pseudo-Symbole ('modul'); Datei-Einheiten (## pfad ohne ::) sind im Format vorgesehen, aber in Parser/Gates nicht implementiert.

  6. OFFEN — Sichten referenzieren Einheiten mit FALSCHEM Datei-Prefix (Symbol existiert, Datei falsch: repair.py-Einheit als board_inventory.py referenziert). Mechanische Referenz-Streichung ist eingebaut; besser wäre ID-Korrektur (Symbol eindeutig → Prefix ersetzen).

  7. OFFEN — creator/projects/ + uni/ sind Inhaltsdaten, keine Projektquellen → braucht projekt-eigene Ausschluss-Config. Und: Kern/Features-Qualität bei voller Übersicht noch unbewiesen (einziger kompletter Sichten-Lauf sah die Teil-Übersicht).

  8. Abschlusslauf erfolgreich (nach Fixes 1719): 96/98 Chunks, alle 3 Sichten, Kern beschreibt den ganzen Creator korrekt (Inventar→Artefakte→Guide, 14 Feature-Bereiche). Rest-Tote: 2 Chunks (database.py, textkit.py — Zitat-Klasse, Fehlertext durch Paket-Attribution verwischt). Der „Hänger" dieses Laufs war KEIN Hänger — nur die lange Sichten-Endphase; mein USR1 killte den Prozess vor dem Bericht (faulthandler- Registrierung wirkte nicht — prüfen). Artefakte liegen final in creator/.planer/.

Offen in Phase 0

  • board_inventory.py (2344 Zeilen) — Hintergrund-Lauf ausstehend; erwartete Erkenntnis: große Dateien brauchen Chunking (Symbol-Gruppen je Call)
  • config.py-Zitatfehler per Nachfass/Repair beheben (Muster ist validiert, niedrige Prio)
  • Bewertung mit dem Nutzer: taugt das Ergebnis zum Wiedereinlesen?