KB-Agent führt aktuell ansible-eulernest F-14-Rolle (codex_mcp + Vault-Fill) durch. N3 (Smoke-Test-Suite) erst freigeben wenn codex-mcp Endpoint live ist. N1/N2 unabhängig davon weiterhin dispatchbar. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
⚠️ ARCHIVIERT — abgelöst durch ansible-eulernest
Dieses Repo war die Planungsphase für den Jetson-AI/Ollama-Host und wurde nie gebaut. Die Implementierung ist direkt im Schwester-Repo
ansible-eulernestentstanden — dort liegen jetzt Code und Doku (Single Source of Truth):
- Implementierung:
group_vars/jetson/vars.yml,roles/{jetson_bootstrap,ollama,ollama_exporter},jetson.yml- Doku: README §„Jetson AI / Ollama" +
docs/jetson-quickstart.md- Repo: https://git.eulernest.eu/user2595/ansible-eulernest
Der „Projekt-Vertrag" (Profile, Pfade, Daemon-Env,
num_ctx) und die Designentscheidung ausdocs/adr/0002-ollama-native.mdwurden dorthin portiert. Die reale Box läuft inzwischen auf JetPack 7.2 mit einem vierten Profil (coder, für den ci-ai-Bot) — Details nur noch inansible-eulernest.Dieses Repo ist veraltet, read-only archiviert und wird nicht mehr gepflegt. Der Inhalt unten ist der historische Planungsstand (agent-swarm-Bootstrap, Stand 2026-06).
Jetson AI / Ollama (MLOps)
Lokal laufendes Single-User-AI-System auf einem Jetson Orin Nano Super (8 GB):
Ollama-Daemon serviert drei Modell-Profile (OpenAI-kompatibel), ein schlanker
Exporter-Sidecar exponiert /metrics. Modellwechsel passiert nativ über den
Modellnamen — kein eigener Swapper, kein Gateway (siehe docs/adr/0002-ollama-native.md).
- Profile:
qwen-light(Daily-Driver) ·gemma(Creative/Chat, multimodal) ·qwen-heavy(harte Reasoning-Fälle).OLLAMA_MAX_LOADED_MODELS=1hält genau ein Modell resident → drei Profile sind quasi gratis. - Optimierung:
q8_0-KV-Cache + Flash Attention,num_ctxje Profil explizit. - Daten: DVC ist Modell-Source-of-Truth; Ollamas Blob-Store nur Laufzeit-Cache.
Scope: Dieses Repo deckt nur den Jetson ab. nginx (TLS + OAuth) und Prometheus/Grafana laufen off-box. Ollama hat keine eigene Auth → nur ans LAN binden, Firewall auf den Proxy. Voller Vertrag:
CONVENTIONS.md.
Arbeitsmodell (agent-swarm)
Dieses Repo wurde aus dem agent-swarm-Template gebootstrapt: ein Leader/Worker-
Agentensystem, dessen Stand komplett auf Disk lebt — kalt lesbar ohne Vorkontext.
Methodik: docs/methodology.md · Herkunft:
docs/about-template.md.
| Wo | Datei |
|---|---|
| Stand & nächster Schritt | STATE.md |
| Plan / Board / Ready-Set (DAG) | ROADMAP.md |
| Gemeinsamer Vertrag | CONVENTIONS.md |
| Kalt-Review-Einstieg | REVIEW.md |
| Dispatch-fertige Worker-Prompts | session-prompts/ |
Sofort bauen
Die Planung ist fertig (W1–W6 im Board). So baust du es:
- W1 zuerst — frische Session öffnen, Modell Sonnet, Inhalt von
session-prompts/W1.mdeinfügen → legt das Grundgerüst an. - Review-Gate (Opus, kalt) → mergen → W1 im Board auf
✅. - W2–W5 parallel — je eigene Session (
session-prompts/W2.md…W5.md), disjunkte Datei-Ownership, laufen unabhängig. - W6 zuletzt — Docs, integriert die Realität der anderen Pakete.
Jeder Worker-Prompt ist self-contained (Modell, Branch, Dateien, Akzeptanzkriterien,
Abschluss-Gates). Die Gates (scripts/gate-*.sh) sind aktiv und prüfen Ownership,
Hygiene und Doku-Drift bei jedem Schritt.