EvolutionCore → xi-runtime

Langfristiger Pfad für umgebungsunabhängige Selbstverbesserung. Nicht Teil der aktuellen UX-Coherence-Arbeit (Phasen 1–5 / Nav–Shell–Neon).

These (verbindlich)

EvolutionCore ist der portable Evolutionskern für Agenten: dieselbe Loop (mutieren → trialen → scoren → committen) in jeder Umgebung über Adapter — mit Versionierung und Rollback.

• Self ist portabel (Elixir/OTP-Dienst).
• World ist steckbar (Umgebungen über Ports).
• Nicht umgebungslos: ohne Umgebung gibt es kein Feedback. Umgebungsunabhängig heißt: der Kern ändert sich nicht pro App — die App implementiert den Port.

Kurz: Self portabel. World steckbar.

Was EvolutionCore ist

Repo: EvolutionCore (eigenständiges Elixir-Repo, außerhalb des UX-Stacks).

Elixir/OTP-Dienst: JSON-API (Bandit), Postgres (Ecto), Hintergrundjobs (Oban), Agenten-Skeleton (Jido), Orchestrator mit dateibasierten Implementation Runs (Phase 1).

Aspekt	Stand (Juli 2026)
Stack	Elixir ~> 1.18, Bandit, Ecto, Oban
API	/api/v1/status, /api/v1/ingest, /api/v1/trigger_optimization, …
Runs	Dateibasiert unter priv/runs/, Zustand im GenServer (nicht persistent)
Evolutionsloop	Noch nicht implementiert — Gerüst + Spec
Phase 2	Spec in Repo docs/PHASE2_SPEC.md (Persistenz, Pipeline)

Heute verbessert ein Lauf nichts am Zielsystem: Job → leerer Run-Ordner → Log. Die Tabellen für Proposals/Metriken/Lessons existieren, werden aber noch nicht befüllt.

Beziehung zu XI und ADDXION

EvolutionCore ist kein Consumer von Neon, Auth oder Shell. Es wird nicht in @addxion/xi hineinkopiert.

Langfristig ist @addxion/xi/runtime der TypeScript-Port/Client. EvolutionCore bleibt Backend.

Apps (süper · addxion.ai · …)     ← Umgebungen (World)
           │
   @addxion/xi/runtime              ← Port / Client (TS)
           │
   EvolutionCore (Elixir)           ← Self / Evolutionsloop
           │
   optional @addxion/ai             ← LLM nur als Worker-Capability

Schicht	Verantwortung
@addxion/xi (protocol, nav)	Cross-App-Glue (Manifeste, Nav) — unverändert
@addxion/xi/runtime	App-Kontext → Env-Ports; HTTP zu EvolutionCore
EvolutionCore	Mutation, Trial, Score, Commit, Versionierung, Rollback
@addxion/ai	LLM-SSOT — nicht durch EvolutionCore ersetzen
@addxion/shell	Chat-UI — kein Evolutions-Backend

Umgebungs-Ports (Vertrag)

Jede Umgebung (App, Workspace, Ops-Adapter) muss denselben Vertrag erfüllen:

Port	Bedeutung
observe	Zustand / Events / Kontext liefern
act	Aktion ausführen (Tool, Code, API, …)
evaluate	Erfolg / Kosten / Risiko als Score liefern
constrain	erlaubte Aktionen, Sandbox, Limits

Umgebungsspezifisches (GitHub, DOM, Fahrschul-Domäne, …) bleibt hinter dem Adapter. Fitness-Rohsignale mappt der Adapter auf ein gemeinsames Schema; der Core entscheidet über Evolution.

Evolutionsstufen (Produkt)

Stufe	Inhalt	Status
1 — Behavioral	Policies, Heuristiken, Tool-Wahl → A/B gegen Score	Ziel-MVP
2 — Skill/Code	Neue Skills/Module im Workspace, nur bei Messgewinn	danach
3 — Architektur-Selbstumbau	Kernel/Supervision autonom redesignen	Vision, kein MVP

Autonomie in Levels: Propose → Trial → Commit → Propagate (Propagation nur wenn der Adapter es erlaubt).

Was EvolutionCore nicht ist

• Kein Coding-Agent (Pi / Hermes / Cursor)
• Kein Issue-Work-Orchestrator (Symphony)
• Kein Ersatz für @addxion/ai oder Chat-Shell
• Kein generisches Agent-Framework „nur weil Elixir“
• Kein Claim „überall besser“ ohne implementierten Port und Score

Was jetzt nicht nötig ist

• Pi/Hermes in Produkt-Apps
• EvolutionCore an Chat-Shell
• Cross-Repo Agent-Sync zwischen süper und addxion.ai
• Vorzeitige runtime-Implementierung in Consumern vor Phase 6.4

Fokus UX-Stack bleibt: Neon, Shell, Behavior, xi-nav.

Beweis (Falsifizierbarkeit)

„Umgebungsunabhängig“ gilt erst nach empirischem Beweis:

1. Env A — ein Adapter mit messbarem Fitness-Gain nach N Generationen
2. Env B — zweiter Adapter, gleicher Core

Eine Umgebung = Feature. Zwei = These.

ADDXION-Proof-Pfad (langfristig): erste App hinter xi/runtime = Env A; zweite App oder Workspace-Adapter = Env B.

Migrations-Roadmap

Phase	Inhalt
xi-0	protocol + nav (Manifest, keine Agents) — erledigt
xi-1	runtime Stub: Health/Status gegen EvolutionCore
xi-2	EvolutionCore API hinter @addxion/xi/runtime (HTTP-Client)
xi-3	Erster Evolutionsloop + Env A (interne Optimierung, nicht Endnutzer-Chat)
xi-4	Env B — These bewiesen

Ökosystem-Tracking: Roadmap 6.4. Parallel darf EvolutionCore den Loop ohne App-UI bauen (z. B. Workspace-Adapter), solange Ports und Grenzen eingehalten werden.

Führungsprinzipien

1. Kein umgebungsspezifisches Feature ohne Port.
2. Keine Evolution ohne evaluate / Score.
3. Kein Universalitäts-Claim ohne zweite Umgebung.
4. MVP = Stufe 1 (Behavioral), nicht Architektur-Selbstumbau.
5. Elixir = Evolutionsbetrieb (Supervision, parallele Trials) — nicht besserer Chat-Agent.

Audit-Notiz

Eigenständiges Elixir-Repo mit HTTP-API-Stub und Orchestrator-GenServer. Keine TypeScript-Integration. Kein Deploy im ADDXION-Produktionspfad. These und XI-Slot sind dokumentiert; Implementierung der Loop steht aus.

Truths

ID	Wahrheit
T-EVOLUTION-CORE	Portabler Evolutionskern; World steckbar; xi/runtime = Port
T-PKG-XI	Ein Package xi, Subpath-Exports, kein UI
T-PKG-AI	LLM-SSOT bleibt @addxion/ai
T-PLATFORM-SSOT	Plattform-Wahrheit nur in addxion-docs
T-REPO-BOUNDARY	EvolutionCore eigenes Repo

Für Agents

Scope: These und Grenzen EvolutionCore → @addxion/xi/runtime.

• @addxion/xi/runtime bleibt Stub bis Phase 6.4 / xi-1+ — keine vorzeitige Consumer-Runtime
• Evolutionslogik nur in EvolutionCore; in xi/runtime nur Client/Port-Typen
• Chat/LLM nicht durch EvolutionCore ersetzen (@addxion/ai, Shell)
• Status: roadmap.md (6.4); Package-Grenzen: packages-guide.md
• Neue Umgebung = neuer Adapter hinter den Ports, kein Fork des Cores