orbitalo/homelab-brain

Fork 0

[Session 2026-06-11] Cline intensiv testen & einstellen (lokales Qwen läuft) #100

New issue

Open

opened 2026-06-11 18:38:41 +00:00 by orbitalo · 5 comments

orbitalo commented

2026-06-11 18:38:41 +00:00

Owner

Was wurde gemacht

Cline (VS Code) auf dem KI-Server mit lokalem Modell zum Laufen gebracht — Ziel von Issue #97/#99 im Kern erreicht.
Modell qwen3.6-hauhau in Ollama importiert: HauhauCS Qwen3.6-35B-A3B uncensored IQ4_XS (17,4 GB GGUF), passt komplett in die RTX 3090.
Bewiesen: echte Coding-Aufgabe (Datei anlegen + ausführen), Homelab-Verständnis, Terminal-Diagnose, MCP-Nutzung. Cline hat selbstständig CT-999-Doku gelesen, openmemory durchsucht und PBS-Diagnose über SSH gefahren.

Änderungen an Infrastruktur (KI-Server, Tailscale 100.84.255.83)

Ollama-Modell qwen3.6-hauhau erstellt aus C:\llm\models\Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive-IQ4_XS.gguf (Modelfile: C:\llm\Modelfile.hauhau, Go-Template mit fest geschlossenem Denk-Block, num_ctx 49152 als Default).
Cline-Config (%APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json):
- Provider: Ollama (nativ, http://127.0.0.1:11434), Modell qwen3.6-hauhau, Model Context 98304.
- MCPs aktiv: openmemory + forgejo. Cloudflare + Playwright auf disabled:true (kosteten zusammen ~49K Kontext-Tokens → bei Bedarf zuschalten).
- Forgejo-MCP korrigiert: native forgejo-mcp.exe (PATH) statt kaputtem npx forgejo-mcp, gültiger Token.
Execution Policy für User wutti auf RemoteSigned gesetzt (für VS-Code-Shell-Integration).
Passwortloser SSH-Zugang KI-Server → pve-hetzner eingerichtet (neuer Key C:\Users\wutti\.ssh\id_ed25519, Public-Key in root@100.88.230.59:~/.ssh/authorized_keys). Cline kann darüber pct exec etc. fahren.

Erkannte Probleme / Learnings

Ollama kann Thinking NICHT per Modelfile abschalten (offiziell, bestätigt). Nur per Request-Parameter think:false. Cline schickt das nicht → das Modell denkt, liefert aber via nativer /api/chat trotzdem nutzbaren content. Über den OpenAI-/v1-Pfad blieb content leer → das war die Ursache der frühen "empty response"-Fehler.
Modellgröße ↔ Kontext-Tradeoff: 24-GB-Qwen (zensiert) ließ kaum Kontext übrig; das kleinere uncensored IQ4_XS (17,4 GB) lässt Platz für 98K–131K Kontext auf der 3090.
MCP-Tool-Budget: Clines System-Prompt + alle MCP-Tools fraßen 80K Tokens. Cloudflare + Playwright allein ~49K. Forgejo (70 Tools) ~15–18K. → nur die nötigen MCPs dauerhaft laden.
SSH-Lücke: direkte Passwort-Logins hängen Cline. Lösung: passwortloser Key + Hub-Pattern ssh root@100.88.230.59 'befehl'.
Die alte llama.cpp-Schiene (Issue #99) war ein Umweg — Ollama lief längst mit denselben Modellen. Lehre: erst Ist-Zustand prüfen, dann bauen.

Nächste Schritte (diese Issue = TODO)

Cline intensiv testen an echten Aufgaben: mehrstufige Coding-Tasks, Homelab-Ops (pct exec, journalctl), Git-Ops über Forgejo-MCP, Memory-Schreiben/-Lesen.
Plan- vs Act-Mode Verhalten prüfen, Auto-Approve sinnvoll einstellen (Edit + Safe Commands + Max Requests; NICHT blind "alle Befehle" wegen Homelab-root-Zugang).
Tool-Calling-Format beobachten — folgt Qwen zuverlässig Clines XML-Format? Bei Fehlern ggf. Modelfile-Template feinjustieren.
Kontext-Verhalten unter Last: reicht 98K mit Forgejo? Sonst auf 131072 (passt VRAM) oder KV-Cache-Quantisierung für 160K+.
.clinerules im real genutzten Workspace dauerhaft mit Homelab-SSH-Hub-Pattern hinterlegen (heute nicht gefunden, weil Workspace-abhängig).
SSH-Zugang ausweiten auf weitere Nodes (pve-mu-2/3 etc.) falls nötig, oder konsequent über pve-hetzner als Hub.
Thinking-Problem final entscheiden: mit Thinking leben (content kommt) oder Proxy bauen, der think:false erzwingt (schneller, weniger Kontext pro Turn).
llama.cpp aufräumen: gestoppter llama-server + Scheduled Task llama-server auf dem KI-Server entfernen (wird durch Ollama ersetzt). 17,4-GB-GGUF wird von Ollama genutzt → behalten.
Entscheiden, ob qwen3.6-hauhau zum Default-Modell auch in OpenCode wird (statt devstral).

Betroffene Systeme

KI-Server (RTX 3090, Tailscale 100.84.255.83, Windows, User wutti) — Ollama, Cline/VS Code, SSH-Key
pve-hetzner (100.88.230.59) — authorized_keys ergänzt (SSH-Hub für Cline)
CT 111 forgejo (100.89.246.60:3000) — MCP-Anbindung
CT 122 openmemory (100.92.71.93:8765) — MCP-Anbindung
Bezug: Issues #97 (Cline-Migration) und #99 (lokales Modell auf 3090) — Kernziel erreicht, Feintuning offen.

## Was wurde gemacht - **Cline (VS Code) auf dem KI-Server mit lokalem Modell zum Laufen gebracht** — Ziel von Issue #97/#99 im Kern erreicht. - Modell **`qwen3.6-hauhau`** in Ollama importiert: HauhauCS Qwen3.6-35B-A3B **uncensored IQ4_XS** (17,4 GB GGUF), passt komplett in die RTX 3090. - Bewiesen: echte Coding-Aufgabe (Datei anlegen + ausführen), Homelab-Verständnis, Terminal-Diagnose, MCP-Nutzung. Cline hat selbstständig CT-999-Doku gelesen, openmemory durchsucht und PBS-Diagnose über SSH gefahren. ## Änderungen an Infrastruktur (KI-Server, Tailscale 100.84.255.83) - **Ollama-Modell** `qwen3.6-hauhau` erstellt aus `C:\llm\models\Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive-IQ4_XS.gguf` (Modelfile: `C:\llm\Modelfile.hauhau`, Go-Template mit fest geschlossenem Denk-Block, `num_ctx 49152` als Default). - **Cline-Config** (`%APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json`): - Provider: Ollama (nativ, `http://127.0.0.1:11434`), Modell `qwen3.6-hauhau`, **Model Context 98304**. - MCPs aktiv: **openmemory + forgejo**. Cloudflare + Playwright auf `disabled:true` (kosteten zusammen ~49K Kontext-Tokens → bei Bedarf zuschalten). - Forgejo-MCP korrigiert: native `forgejo-mcp.exe` (PATH) statt kaputtem `npx forgejo-mcp`, gültiger Token. - **Execution Policy** für User wutti auf `RemoteSigned` gesetzt (für VS-Code-Shell-Integration). - **Passwortloser SSH-Zugang** KI-Server → pve-hetzner eingerichtet (neuer Key `C:\Users\wutti\.ssh\id_ed25519`, Public-Key in `root@100.88.230.59:~/.ssh/authorized_keys`). Cline kann darüber `pct exec` etc. fahren. ## Erkannte Probleme / Learnings - **Ollama kann Thinking NICHT per Modelfile abschalten** (offiziell, bestätigt). Nur per Request-Parameter `think:false`. Cline schickt das nicht → das Modell denkt, liefert aber via nativer `/api/chat` trotzdem nutzbaren `content`. Über den OpenAI-`/v1`-Pfad blieb `content` leer → das war die Ursache der frühen "empty response"-Fehler. - **Modellgröße ↔ Kontext-Tradeoff:** 24-GB-Qwen (zensiert) ließ kaum Kontext übrig; das kleinere uncensored IQ4_XS (17,4 GB) lässt Platz für 98K–131K Kontext auf der 3090. - **MCP-Tool-Budget:** Clines System-Prompt + alle MCP-Tools fraßen 80K Tokens. Cloudflare + Playwright allein ~49K. Forgejo (70 Tools) ~15–18K. → nur die nötigen MCPs dauerhaft laden. - **SSH-Lücke:** direkte Passwort-Logins hängen Cline. Lösung: passwortloser Key + Hub-Pattern `ssh root@100.88.230.59 'befehl'`. - Die alte llama.cpp-Schiene (Issue #99) war ein Umweg — Ollama lief längst mit denselben Modellen. Lehre: erst Ist-Zustand prüfen, dann bauen. ## Nächste Schritte (diese Issue = TODO) - [ ] **Cline intensiv testen** an echten Aufgaben: mehrstufige Coding-Tasks, Homelab-Ops (pct exec, journalctl), Git-Ops über Forgejo-MCP, Memory-Schreiben/-Lesen. - [ ] **Plan- vs Act-Mode** Verhalten prüfen, Auto-Approve sinnvoll einstellen (Edit + Safe Commands + Max Requests; NICHT blind "alle Befehle" wegen Homelab-root-Zugang). - [ ] **Tool-Calling-Format** beobachten — folgt Qwen zuverlässig Clines XML-Format? Bei Fehlern ggf. Modelfile-Template feinjustieren. - [ ] **Kontext-Verhalten** unter Last: reicht 98K mit Forgejo? Sonst auf 131072 (passt VRAM) oder KV-Cache-Quantisierung für 160K+. - [ ] **`.clinerules`** im real genutzten Workspace dauerhaft mit Homelab-SSH-Hub-Pattern hinterlegen (heute nicht gefunden, weil Workspace-abhängig). - [ ] **SSH-Zugang ausweiten** auf weitere Nodes (pve-mu-2/3 etc.) falls nötig, oder konsequent über pve-hetzner als Hub. - [ ] **Thinking-Problem** final entscheiden: mit Thinking leben (content kommt) oder Proxy bauen, der `think:false` erzwingt (schneller, weniger Kontext pro Turn). - [ ] **llama.cpp aufräumen:** gestoppter `llama-server` + Scheduled Task `llama-server` auf dem KI-Server entfernen (wird durch Ollama ersetzt). 17,4-GB-GGUF wird von Ollama genutzt → behalten. - [ ] Entscheiden, ob `qwen3.6-hauhau` zum Default-Modell auch in OpenCode wird (statt devstral). ## Betroffene Systeme - **KI-Server** (RTX 3090, Tailscale 100.84.255.83, Windows, User wutti) — Ollama, Cline/VS Code, SSH-Key - **pve-hetzner** (100.88.230.59) — authorized_keys ergänzt (SSH-Hub für Cline) - **CT 111 forgejo** (100.89.246.60:3000) — MCP-Anbindung - **CT 122 openmemory** (100.92.71.93:8765) — MCP-Anbindung - Bezug: Issues #97 (Cline-Migration) und #99 (lokales Modell auf 3090) — Kernziel erreicht, Feintuning offen.

orbitalo commented

2026-06-11 18:48:14 +00:00

Author

Owner

Kontextfenster-Grenzen (live gemessen 11.06.2026, abends)

Direkt am Modell auf dem KI-Server ausgelesen (ollama show / ollama ps / nvidia-smi):

Modell-Architektur-Grenze: 262144 Tokens (256K) — qwen3.6-hauhau (arch qwen35moe, 34.7B, IQ4_XS) ist laut GGUF auf 256K trainiert. Theoretische Obergrenze, kein Flaschenhals.
VRAM-Grenze 3090 (echte Decke):
- Bei 98304 Kontext (aktuell geladen): 20,4 GB / 24 GB belegt, 3,4 GB frei.
- Modellgewichte ~17,4 GB, KV-Cache wächst ~27 KB/Token.
- ~131K passt knapp (~21,5 GB). Ab ~140K → OOM/RAM-Spillover.
Aktuell aktiv: Cline-Setting greift, ollama ps zeigt CONTEXT 98304.

Plan für morgen

KV-Cache-Quantisierung (q8_0 bzw. q4_0) aktivieren → dann sind 160K–256K auch auf der 3090 möglich (kostet etwas Präzision). Entscheiden ob 131K nativ oder 160K+ mit Quant.
Heunadel-Test (needle-in-haystack): definierten Fakt an verschiedenen Positionen in einen langen Kontext einbetten und prüfen, ob das Modell ihn zuverlässig wiederfindet ("lost in the middle"-Check). Ziel: reale nutzbare Kontextgrenze ermitteln, nicht nur die technische.
Ergebnis bestimmt den finalen num_ctx-Wert + Cline Model-Context-Setting.

## Kontextfenster-Grenzen (live gemessen 11.06.2026, abends) Direkt am Modell auf dem KI-Server ausgelesen (`ollama show` / `ollama ps` / `nvidia-smi`): - **Modell-Architektur-Grenze: 262144 Tokens (256K)** — `qwen3.6-hauhau` (arch qwen35moe, 34.7B, IQ4_XS) ist laut GGUF auf 256K trainiert. Theoretische Obergrenze, kein Flaschenhals. - **VRAM-Grenze 3090 (echte Decke):** - Bei **98304 Kontext** (aktuell geladen): 20,4 GB / 24 GB belegt, 3,4 GB frei. - Modellgewichte ~17,4 GB, KV-Cache wächst ~27 KB/Token. - **~131K** passt knapp (~21,5 GB). **Ab ~140K** → OOM/RAM-Spillover. - **Aktuell aktiv:** Cline-Setting greift, `ollama ps` zeigt CONTEXT 98304. ## Plan für morgen - [ ] **KV-Cache-Quantisierung** (q8_0 bzw. q4_0) aktivieren → dann sind 160K–256K auch auf der 3090 möglich (kostet etwas Präzision). Entscheiden ob 131K nativ oder 160K+ mit Quant. - [ ] **Heunadel-Test (needle-in-haystack):** definierten Fakt an verschiedenen Positionen in einen langen Kontext einbetten und prüfen, ob das Modell ihn zuverlässig wiederfindet ("lost in the middle"-Check). Ziel: reale nutzbare Kontextgrenze ermitteln, nicht nur die technische. - [ ] Ergebnis bestimmt den finalen `num_ctx`-Wert + Cline Model-Context-Setting.

orbitalo referenced this issue

2026-06-11 18:50:04 +00:00

KI-Server: RTX 3090 mit llama.cpp + Qwen3.6 35B aktivieren #99

orbitalo commented

2026-06-11 19:06:52 +00:00

Author

Owner

Performance-Benchmark (gemessen 11.06.2026, abends)

Gemessen per Ollama-API (/api/generate, think:false, num_predict=200) direkt auf dem KI-Server gegen qwen3.6-hauhau:

Metrik	Wert
Generierung (Decode)	~132 Tokens/s
Prompt-Verarbeitung (Prefill)	~175 Tokens/s

Gemessen bei kleinem Kontext (CLI-Default 49152). Übertrifft die #99-Erwartung (~100 tok/s).
Grund: MoE mit nur 3B aktiven von 34,7B Parametern → wenig Rechenlast pro Token, läuft komplett im VRAM.
Caveat: Tempo sinkt mit füllendem Kontext (KV-Cache wächst), realistisch ~80–110 tok/s nahe 98K. Prefill ~175 tok/s bedeutet: ein frisch gefüllter Riesen-Kontext dauert (50K ≈ 5 min), aber Cline cached den Prompt → nur erster Turn betroffen.

Wichtige Beobachtung: Thinking ist sehr ausgeprägt

Ein simples "drei Sätze"-Prompt ließ das Modell minutenlang denken (mehrere CLI-Läufe liefen >2 min und mussten abgebrochen werden). think:false per nativem API-Parameter schaltet es sauber ab und liefert sofort. → Bestätigt den TODO-Punkt: Proxy bauen, der think:false für Cline erzwingt — spart pro Turn massiv Zeit und Kontext-Tokens. Hohe Priorität für morgen.

Messmethodik: base64-kodiertes PowerShell via SSH (Remote-Shell ist cmd.exe → JSON-Quoting umgangen), Invoke-RestMethod gegen 127.0.0.1:11434.

## Performance-Benchmark (gemessen 11.06.2026, abends) Gemessen per Ollama-API (`/api/generate`, `think:false`, `num_predict=200`) direkt auf dem KI-Server gegen `qwen3.6-hauhau`: | Metrik | Wert | |---|---| | **Generierung (Decode)** | **~132 Tokens/s** | | **Prompt-Verarbeitung (Prefill)** | **~175 Tokens/s** | - Gemessen bei kleinem Kontext (CLI-Default 49152). Übertrifft die #99-Erwartung (~100 tok/s). - Grund: MoE mit nur **3B aktiven** von 34,7B Parametern → wenig Rechenlast pro Token, läuft komplett im VRAM. - **Caveat:** Tempo sinkt mit füllendem Kontext (KV-Cache wächst), realistisch ~80–110 tok/s nahe 98K. Prefill ~175 tok/s bedeutet: ein frisch gefüllter Riesen-Kontext dauert (50K ≈ 5 min), aber Cline cached den Prompt → nur erster Turn betroffen. ### Wichtige Beobachtung: Thinking ist sehr ausgeprägt Ein simples "drei Sätze"-Prompt ließ das Modell **minutenlang** denken (mehrere CLI-Läufe liefen >2 min und mussten abgebrochen werden). `think:false` per nativem API-Parameter schaltet es sauber ab und liefert sofort. → Bestätigt den TODO-Punkt: **Proxy bauen, der `think:false` für Cline erzwingt** — spart pro Turn massiv Zeit und Kontext-Tokens. Hohe Priorität für morgen. _Messmethodik: base64-kodiertes PowerShell via SSH (Remote-Shell ist cmd.exe → JSON-Quoting umgangen), Invoke-RestMethod gegen 127.0.0.1:11434._

orbitalo commented

2026-06-12 15:19:31 +00:00

Author

Owner

Cline-Test am 12.06.2026: hausmeister-bot (CT 116) laeuft stabil, read-only-Diagnose ueber SSH-Hub erfolgreich.

Der SSH-Quoting-Fix in .clinerules (REGEL 1 - keine inneren Anfuehrungszeichen fuer Windows-Terminal) hat die Befehlsanzahl pro Task von 48 auf 12 gesenkt - eine signifikante Reduktion des Kontext-Verbrauchs.

Forgejo-MCP funktioniert einwandfrei, Issue-Kommentar erfolgreich erstellt.

Cline-Test am 12.06.2026: hausmeister-bot (CT 116) laeuft stabil, read-only-Diagnose ueber SSH-Hub erfolgreich. Der SSH-Quoting-Fix in .clinerules (REGEL 1 - keine inneren Anfuehrungszeichen fuer Windows-Terminal) hat die Befehlsanzahl pro Task von 48 auf 12 gesenkt - eine signifikante Reduktion des Kontext-Verbrauchs. Forgejo-MCP funktioniert einwandfrei, Issue-Kommentar erfolgreich erstellt.

orbitalo commented

2026-06-12 15:23:36 +00:00

Author

Owner

Cline-Test-Session 12.06.2026 (vollstaendige Auswertung)

Getestet mit qwen3.6-hauhau (Ollama 0.30.7) in Cline 3.89.2 auf dem KI-Server. Sauberer Test-Workspace C:\dev\homelab angelegt (git init), weg von C:\llm (dort lagen die GGUFs -> Checkpoint-Timeout). Checkpoints deaktiviert.

Ergebnis-Scorecard

Faehigkeit	Status
XML-Tool-Format	OK
OpenMemory-MCP (lesen/schreiben/Dedup)	OK
SSH-Hub-Befehle	OK (nach Quoting-Fix)
Forgejo-MCP (lesen + schreiben)	OK (Kommentar #253)
Coding (Python schreiben + ausfuehren)	OK (ports_check.py, lief sofort)
Deutsch	OK (nach Sprach-Regel)
Read-only-Sicherheit	OK (keine destruktiven Befehle)

Erledigte TODOs aus dieser Issue

Cline intensiv getestet (4 echte Tasks: Diagnose, Re-Run, Forgejo-Schreiben, Coding)
Tool-Calling-Format: qwen trifft Clines XML zuverlaessig
Kontext-Verhalten: ~27K Baseline (Forgejo-MCP ~15-18K ist der Brocken), ~71K nutzbar von 98K -> gesund
.clinerules mit SSH-Hub-Pattern hinterlegt (3 Regeln, siehe unten)
Thinking-Problem ENTSCHIEDEN: kein Proxy. Empirisch getestet: /no_think-Soft-Switch wirkt beim hauhau-Finetune NICHT, nur API-Param think:false greift. Cline 3.89.2 sendet think:false nicht. ABER: Thinking global abschalten senkt Qualitaet bei harten Tasks und waere nur bei <10% reinen Mechanik-Sessions noetig. -> Denken anlassen.

Wichtigste Learnings

.clinerules ist entscheidend. Ohne sie driftet/flailt qwen. Datei MUSS .clinerules heissen (nicht clinerules.md -> wird nicht auto-geladen).
qwen verrennt sich bei Reibung. 3x gesehen: 48 Befehle bei SSH-Quoting, 90 Befehle bei einem transienten Forgejo-Netzwerkfehler (statt aufzugeben). Jeweils per Regel entschaerft.
3 Regeln in .clinerules eingefuehrt: REGEL 0 = nur Deutsch (gegen Chinesisch-Drift); REGEL 1 = SSH ohne innere Quotes (Windows-Terminal) -> Befehle pro Task 48->12; REGEL 2 = max 2 Versuche, bei MCP-Fehler stoppen statt manuell per curl/ping zu probieren.
Forgejo-MCP-Fehler vom KI-Server war transient (dial tcp); danach HTTP 200 verifiziert.

Fazit zu #97 (Cursor-Ersatz)

Cline + qwen deckt die ~70% (Ops + Standard-Coding) zuverlaessig ab, MIT den Regeln und gelegentlicher Aufsicht. Cursor noch nicht kuendigen; fuer die harten 30% Claude-via-OpenRouter als Eskalations-Profil bereithalten (wie in #97 geplant, jetzt belegt).

Offen fuer naechste Session

REGEL 2 unter echtem Fehler erneut testen (greift das Stoppen?)
Plan- vs Act-Mode bei komplexem Task
llama.cpp-Reste aufraeumen (gestoppter llama-server + Scheduled Task) - erst jetzt sicher, da Ollama-Weg bestaetigt
Optional: qwen3.6-hauhau als OpenCode-Default?

## Cline-Test-Session 12.06.2026 (vollstaendige Auswertung) Getestet mit `qwen3.6-hauhau` (Ollama 0.30.7) in Cline 3.89.2 auf dem KI-Server. Sauberer Test-Workspace `C:\dev\homelab` angelegt (git init), weg von `C:\llm` (dort lagen die GGUFs -> Checkpoint-Timeout). Checkpoints deaktiviert. ### Ergebnis-Scorecard | Faehigkeit | Status | |---|---| | XML-Tool-Format | OK | | OpenMemory-MCP (lesen/schreiben/Dedup) | OK | | SSH-Hub-Befehle | OK (nach Quoting-Fix) | | Forgejo-MCP (lesen + schreiben) | OK (Kommentar #253) | | Coding (Python schreiben + ausfuehren) | OK (ports_check.py, lief sofort) | | Deutsch | OK (nach Sprach-Regel) | | Read-only-Sicherheit | OK (keine destruktiven Befehle) | ### Erledigte TODOs aus dieser Issue - [x] Cline intensiv getestet (4 echte Tasks: Diagnose, Re-Run, Forgejo-Schreiben, Coding) - [x] Tool-Calling-Format: qwen trifft Clines XML zuverlaessig - [x] Kontext-Verhalten: ~27K Baseline (Forgejo-MCP ~15-18K ist der Brocken), ~71K nutzbar von 98K -> gesund - [x] .clinerules mit SSH-Hub-Pattern hinterlegt (3 Regeln, siehe unten) - [x] Thinking-Problem ENTSCHIEDEN: **kein Proxy**. Empirisch getestet: /no_think-Soft-Switch wirkt beim hauhau-Finetune NICHT, nur API-Param think:false greift. Cline 3.89.2 sendet think:false nicht. ABER: Thinking global abschalten senkt Qualitaet bei harten Tasks und waere nur bei <10% reinen Mechanik-Sessions noetig. -> Denken anlassen. ### Wichtigste Learnings 1. **`.clinerules` ist entscheidend.** Ohne sie driftet/flailt qwen. Datei MUSS `.clinerules` heissen (nicht `clinerules.md` -> wird nicht auto-geladen). 2. **qwen verrennt sich bei Reibung.** 3x gesehen: 48 Befehle bei SSH-Quoting, 90 Befehle bei einem transienten Forgejo-Netzwerkfehler (statt aufzugeben). Jeweils per Regel entschaerft. 3. **3 Regeln in `.clinerules` eingefuehrt:** REGEL 0 = nur Deutsch (gegen Chinesisch-Drift); REGEL 1 = SSH ohne innere Quotes (Windows-Terminal) -> Befehle pro Task 48->12; REGEL 2 = max 2 Versuche, bei MCP-Fehler stoppen statt manuell per curl/ping zu probieren. 4. Forgejo-MCP-Fehler vom KI-Server war transient (dial tcp); danach HTTP 200 verifiziert. ### Fazit zu #97 (Cursor-Ersatz) Cline + qwen deckt die ~70% (Ops + Standard-Coding) zuverlaessig ab, MIT den Regeln und gelegentlicher Aufsicht. Cursor noch nicht kuendigen; fuer die harten 30% Claude-via-OpenRouter als Eskalations-Profil bereithalten (wie in #97 geplant, jetzt belegt). ### Offen fuer naechste Session - REGEL 2 unter echtem Fehler erneut testen (greift das Stoppen?) - Plan- vs Act-Mode bei komplexem Task - llama.cpp-Reste aufraeumen (gestoppter llama-server + Scheduled Task) - erst jetzt sicher, da Ollama-Weg bestaetigt - Optional: qwen3.6-hauhau als OpenCode-Default?

orbitalo commented

2026-06-12 16:17:08 +00:00

Author

Owner

Echter Coding-Test (12.06.2026, Nachtrag)

Aufgabe: dedupe.py schreiben (rekursiver SHA-256-Duplikatfinder mit --min-size, nur ausgeben nie loeschen), Testdateien anlegen, ausfuehren, aufraeumen.

Code-Qualitaet: ueberraschend gut

qwen deckte von sich aus echte Edge-Cases ab, die im ersten Entwurf oft fehlen:

Gechunktes Hashing (8192 B) -> auch grosse Dateien ok
os.access(.., R_OK) fuer unlesbare Dateien
Symlink-Skip gegen Endlosschleifen
try/except (OSError, PermissionError) robuste Fehlerbehandlung
Type-Hints (dict[str, list[tuple[str,int]]]), defaultdict, saubere Funktionstrennung, Docstrings

Entscheidend: 0 Traceback, 0 SyntaxError - das Programm lief beim ERSTEN Versuch korrekt. Output + Summary ("33 B frei durch Loeschen von 1 Kopie") logisch richtig.

Prozess: dieselbe Schwaeche wie immer (Windows-Shell)

15 execute_command - aber NICHT am Programm, sondern am Test-Scaffolding: Erst python -c "..." && mkdir testdir 2>nul & ... (cmd-Murks), dann auf PowerShell Set-Content umgeschwenkt -> lief. Cleanup erst rmdir /s /q (cmd), dann Remove-Item -Recurse (PS). Wichtig: selbst korrigiert (cmd->PS), kein 90er-Spiral - bei ~15 Befehlen geblieben. Disziplin greift langsam.

Bewertung

Aspekt	Status
Code-Qualitaet	OK (Edge-Cases, Typen, robust)
Programm-Korrektheit	OK (lief sofort)
Agentischer Loop (schreiben->testen->ausfuehren->aufraeumen)	OK komplett
Windows-Shell-Scaffolding	fummelig, aber selbst-korrigiert

Fazit: Echte Coding-Kompetenz vorhanden. Schwacher Punkt bleibt konsistent das Windows-Terminal-Quoting bei Hilfsbefehlen, nicht das Programmieren. Fuer Standard-Entwicklung brauchbar. Bestaetigt das #97-Urteil: ~70% (Ops + Coding) traegt lokal.

## Echter Coding-Test (12.06.2026, Nachtrag) Aufgabe: `dedupe.py` schreiben (rekursiver SHA-256-Duplikatfinder mit --min-size, nur ausgeben nie loeschen), Testdateien anlegen, ausfuehren, aufraeumen. ### Code-Qualitaet: ueberraschend gut qwen deckte von sich aus echte Edge-Cases ab, die im ersten Entwurf oft fehlen: - Gechunktes Hashing (8192 B) -> auch grosse Dateien ok - `os.access(.., R_OK)` fuer unlesbare Dateien - **Symlink-Skip** gegen Endlosschleifen - `try/except (OSError, PermissionError)` robuste Fehlerbehandlung - Type-Hints (`dict[str, list[tuple[str,int]]]`), defaultdict, saubere Funktionstrennung, Docstrings Entscheidend: **0 Traceback, 0 SyntaxError** - das Programm lief beim ERSTEN Versuch korrekt. Output + Summary ("33 B frei durch Loeschen von 1 Kopie") logisch richtig. ### Prozess: dieselbe Schwaeche wie immer (Windows-Shell) 15 execute_command - aber NICHT am Programm, sondern am Test-Scaffolding: Erst `python -c "..." && mkdir testdir 2>nul & ...` (cmd-Murks), dann auf PowerShell `Set-Content` umgeschwenkt -> lief. Cleanup erst `rmdir /s /q` (cmd), dann `Remove-Item -Recurse` (PS). Wichtig: **selbst korrigiert (cmd->PS), kein 90er-Spiral** - bei ~15 Befehlen geblieben. Disziplin greift langsam. ### Bewertung | Aspekt | Status | |---|---| | Code-Qualitaet | OK (Edge-Cases, Typen, robust) | | Programm-Korrektheit | OK (lief sofort) | | Agentischer Loop (schreiben->testen->ausfuehren->aufraeumen) | OK komplett | | Windows-Shell-Scaffolding | fummelig, aber selbst-korrigiert | **Fazit:** Echte Coding-Kompetenz vorhanden. Schwacher Punkt bleibt konsistent das Windows-Terminal-Quoting bei Hilfsbefehlen, nicht das Programmieren. Fuer Standard-Entwicklung brauchbar. Bestaetigt das #97-Urteil: ~70% (Ops + Coding) traegt lokal.