docs(reconciliation): sync planning repo to ansible-eulernest reality

Plan ↔ reality abgleich nach tatsächlicher Implementierung in ansible-eulernest:

- CONVENTIONS.md: 4 Profile (+ coder), Registry-Pull statt GGUF/DVC,
  SoT-Pointer auf ansible-eulernest, JP7.2 Source-Build-Note
- STATE.md: W2–W4 done (via ansible-eulernest), W1/W5/W6 dropped,
  N1–N3 (GPU-metric, benchmarks, smoke-tests) als nächste Schritte
- ROADMAP.md: Abgeschlossene Items referenzieren ansible-eulernest-Rollen;
  neue Items N1–N3 für verbleibende Arbeit
- manifests/requirements.md: R-03–R-06 done, R-02/R-07/R-08 drift
- docs/adr/0003: Registry-Pull > GGUF; ansible-eulernest als Impl-SoT
- sessions/2026-06-14-reconciliation.md: Session-Log

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

docs/adr/0003-registry-pull-over-gguf.md

@@ -0,0 +1,53 @@
+# 0003 — Registry-Pull statt lokaler GGUFs; ansible-eulernest als Implementierungs-SoT
+
+- **Status:** accepted
+- **Datum:** 2026-06-14
+- **Supersedes (partiell):** ADR-0002 — nur die DVC=SoT-Klausel; die Kernentscheidung
+  (nativer Ollama-Daemon, kein eigener Swapper) bleibt vollständig gültig.
+
+## Kontext
+
+ADR-0002 sah vor: lokale GGUFs unter `/opt/jetson-ai/models/`, DVC als Modell-SoT,
+`build-models.sh` als reproduzierbare Build-Kette. Bei der tatsächlichen Inbetriebnahme
+des Jetson Orin Nano Super (JetPack 7.2, 2026-06) traten drei Faktoren auf:
+
+1. **JP7.2 / sm_87-Problem:** Der offizielle Ollama-Installer liefert CUDA-Bibliotheken
+   ohne sm_87-Support → Ollama würde CPU-only laufen. Lösung: Source-Build
+   (`roles/ollama/tasks/build_jp72.yml`) mit `cmake -DCMAKE_CUDA_ARCHITECTURES=87`.
+   Dieser Aufwand hatte Priorität; DVC-Infrastruktur wurde verschoben.
+
+2. **Iterative Einrichtung ohne DVC-Puffer:** Die Implementierung lief direkt in
+   `ansible-eulernest`; ein separates GGUF-Download + DVC-Tracking hätte mehrere GB
+   Datenübertragung auf dem Jetson bedeutet, ohne klaren Nutzen für den Einzelbetrieb.
+
+3. **Ollama-Registry als ausreichende Reproduzierbarkeit:** Für Single-User-Betrieb
+   (nicht Produktion, keine reproduzierbare Forschung) genügt `base: qwen2.5:7b` in
+   `group_vars/jetson/vars.yml`. Ansible stellt sicher, dass dieselbe Konfiguration
+   jederzeit neu eingespielt werden kann.
+
+## Entscheidung
+
+**Registry-Pull als Standard.** `ollama_profiles[].base` in
+`ansible-eulernest/group_vars/jetson/vars.yml` ist die SoT für Modell-Identität.
+Kein GGUF-Download, kein DVC-Tracking in dieser Phase.
+
+**ansible-eulernest ist der Implementierungs-SoT.** Dieses Repo (`jetson-ai-ollama`)
+bleibt Planungs- und Methodologie-Referenz; die live laufende Konfiguration wird
+ausschließlich über Ansible verwaltet.
+
+**Vier Profile statt drei.** Das vierte Profil `coder` (`qwen2.5-coder:7b`, temp 0.3)
+wurde nach Fertigstellung der ci-ai-Gitea-Integration ergänzt — war zum Planungszeitpunkt
+noch nicht bekannt.
+
+## Konsequenzen
+
+- **Vorteil:** Kein GGUF-Download-Aufwand; Ansible-Idempotenz deckt Reproduzierbarkeit ab;
+  schnelleres iteratives Deployment.
+- **Risiko:** Modell-Versionen sind unpinned (Ollama Registry kann sich ändern).
+  Mitigation: Digest-Check im Pre-Demo-Checklist; N2 (Benchmark-Script) kann Regressionen
+  erkennen.
+- **GGUF-Pfad nicht permanent geschlossen:** `/opt/jetson-ai/models/` bleibt reserviert.
+  Falls Versionspinning kritisch wird (z. B. für reproduzierbare Forschung mit codex-py),
+  kann der GGUF+DVC-Weg nachgerüstet werden. Ein neues ADR wäre dann nötig.
+- **N3 (Smoke-Tests) deckt R-09/R-10 ab** — Verifikation bleibt als nächster Schritt
+  offen (ROADMAP N3).