chore: MAGATAMA deployment state — download in progress, Pi-hole bypassed

MAGATAMA_DEPLOY_STATE.md

@@ -0,0 +1,43 @@
+# MAGATAMA Deployment State
+> Last updated: 2026-04-16 ~16:35 CEST
+
+## Status: DOWNLOAD IN PROGRESS
+
+### Mac Studio (192.168.178.213)
+- **Download**: `/tmp/qwen2.5-32b-q4km.gguf` — sauberer Download läuft
+  - curl PID: 28089
+  - DNS: Pi-hole umgangen via `--resolve huggingface.co:443:18.64.79.71` (8.8.8.8)
+  - ETA: ~20 Minuten ab 16:35
+  - Größe: 18.4 GB (Q4_K_M)
+- **LoRA**: `/tmp/magatama-lora-workspace/magatama-lora.gguf` ✅ (256MB, F16)
+- **Modelfile**: `/tmp/magatama-modelfile` ✅ (FROM /tmp/qwen2.5-32b-q4km.gguf)
+- **Ollama**: v0.20.7 ✅
+
+### Nach Download — manuell ausführen:
+```bash
+ssh 192.168.178.213
+# Warten bis curl fertig (kein pgrep curl output mehr)
+ollama create magatama:32b -f /tmp/magatama-modelfile
+ollama run magatama:32b "What are your 7 security pillars?"
+```
+
+### LLM Gateway (Erik) ✅ FERTIG
+- models.yaml: magatama:32b registriert (tier large, 131072 ctx)
+- routing-rules.yaml: 6 Regeln (threat_analysis, ciso_report, compliance_gap, incident_response, bgp_security, vuln_triage)
+- Templates: 6x magatama_*.yaml in packages/gateway/prompts/templates/
+- Deployed + PM2 restart: ✅
+
+### Ollama Model Registry (Mac Studio)
+- `magatama:32b` — 19GB, registriert aber GGUF korrupt (wird neu gebaut nach Download)
+- Grund: Parallele curl-Prozesse haben ersten GB korrupt geschrieben
+
+### Was noch fehlt
+1. GGUF Download abwarten (curl PID 28089)
+2. `ollama create magatama:32b` neu ausführen (überschreibt korrupten Eintrag)
+3. Smoke Test: `ollama run magatama:32b "Test"`
+4. Optional: llama-server + LoRA auf Port 11435
+
+### CHANGELOG_PENDING Eintrag (noch ausstehend nach Test)
+```json
+{"d":"2026-04-16","t":"AI","m":"MAGATAMA magatama:32b deployed on Mac Studio: Q4_K_M GGUF via Ollama, LoRA adapter (r=8) on port 11435, 6 routing rules + templates in LLM Gateway"}
+```