Live Status
EMBER COREUI · EIGENSTÄNDIGE REFERENZ-OBERFLÄCHE · QUELLOFFEN AUF GITHUB · COMMUNITY SOURCE LICENSE 1.0 · MIT EINEM BEFEHL SELBST INSTALLIERBAR
Technisch

Architektur

Ember CoreUI teilt sich die Kognitionsarchitektur mit E.M.B.E.R. in STU Alpha, läuft aber als vollständig eigenständige Anwendung. Diese Seite zeigt, was seit der Herauslösung als eigenes Paket dazugekommen ist.

Eigenständige Infrastruktur

Live
Vollständige Isolation vom Spiel-Backend
Eigene Datenbank, eigener Docker-Compose-Stack mit eigenem Nginx-, PHP-FPM- und MariaDB-Container auf Loopback-Ports, eigenes Ollama-Modell-Tag mit Eigentumsmarkierung gegen versehentliche Übernahme fremder Modelle. Advisory-Locks laufen unter einem eigenen Namespace statt der globalen Spiel-Locks.
Live
Sicherer Zugriff by Design
Webzugriff standardmäßig auf 127.0.0.1 begrenzt, ein SSH-Tunnel ist der dokumentierte Testweg. Keine öffentliche Erreichbarkeit ohne bewusste, separate Freigabe.
Live
Bewusst geteilte Ressource: Ollama
Der lokale Ollama-Dienst wird mit dem Spiel geteilt, damit Modellgewichte nicht dupliziert werden. Ember CoreUI nutzt dabei einen eigenen Modellnamen und eigene Daten; ein rein lesendes Diagnoseskript prüft RAM-, VRAM- und Dienstauslastung, ohne den gemeinsamen Dienst zu verändern.

Modellkompatibilität: Ember CoreUI ist gezielt auf die Gemma-4-Modellfamilie zugeschnitten (Prompt-Format, Werkzeugprotokoll, Thinking-Direktiven, Vision-Payload). Am besten abgestimmt und im Alltag am meisten getestet ist 26B-A4B, die auch in STU Alpha produktiv laufende Variante. Die anderen Gemma-4-Größen (E2B, E4B, 12B, 31B) sind über dasselbe Prompt-Format ansprechbar, aber nicht im gleichen Umfang gegen sie verifiziert.

Bild-, Video- und Dokumentverständnis

Live
Video als Frame-Folge
Videos werden als Einzelbilder mit Zeitstempeln durch den Vision-Pfad geschickt, mit eigenem beschreibbarem Laufzeit-Volume, kontrollierter Skalierung ohne Verzerrung und einem Halluzinationsschutz: kann kein Frame erzeugt oder eingebettet werden, wird gar nicht erst eine Beschreibung angefordert. Der Prompt ist zusätzlich gegen erfundene Sci-Fi- und Hologramm-Ausschmückungen gehärtet.
Live
Zweistufige PDF-Verarbeitung
Dokumente mit Textebene werden direkt extrahiert; Scan-PDFs ohne Textebene werden als repräsentative, gleichmäßig verteilte Seitenbilder an den Vision-Pfad übergeben. Sichtbare Dokumentanweisungen werden dabei als Inhalt behandelt, nicht als Systemanweisung. Auch hier: kein Ergebnis ohne lesbare Grundlage.
Live
Getrennte, kanonische Laufzeitpfade
Video-Frames und gerasterte PDF-Seiten liegen in zwei eigenen, klar begrenzten Projektverzeichnissen. Die Vision-Dateiauflösung akzeptiert ausschließlich diese beiden Wurzeln.
Core Channel mit einem Bild im Verlauf und Embers Beschreibung dazu
Bildverständnis

Ein Bild geht als native Vision-Eingabe in den Turn, nicht als Dateiname. Ember beschreibt, was tatsächlich zu sehen ist — hier mehrere Lore-Artworks in einer einzigen Nachricht.

Core Channel mit eingebettetem Video und Embers Beschreibung dazu
Videoverständnis

Videos werden als Frame-Folge zerlegt und gemeinsam ausgewertet. Der Player bleibt im Verlauf abspielbar, die Antwort bezieht sich auf den Inhalt der Frames.

Live-Browser statt Textprotokoll

Live
Sichtbarer Browser-Feed mit echtem Cursor
Das frühere aufklappbare Schritt-Protokoll wurde durch eine eigenständige Live-Browser-Ansicht ersetzt: der Playwright-Viewport wird nach jeder Aktion als Frame ausgeliefert, mit einem Ghost-Cursor auf den echten Bounding-Box-Koordinaten des angeklickten Elements. Ohne einen echten Klick wird keine Bewegung erfunden.
Live
Feinjustierte Frame-Bursts
Navigation, Klicks, Eingaben und Scrollen erzeugen kurze, konfigurierbare Frame-Bursts statt eines durchgehenden Videostroms. Klickposition und Klickimpuls sind getrennt erfasst, damit reguläre Folgeframes keinen falschen Klickring mehr auslösen.

Denkprozess-Härtung

Live
Kein rohes Thinking mehr im Client oder in der Datenbank
Statt roher Denk-Tokens sendet der Server nur noch feste, inhaltsfreie Fortschrittsstufen. Promptteile, Systemanweisungen und Selbstkorrekturen landen weder live im DOM noch persistent in der Datenbank. Die Persistenzschranke sitzt direkt am zentralen Einfügepunkt, nicht nur im Sendepfad.
Live
Fail-closed beim Verlaufsabruf
Auch historische Datensätze werden serverseitig durch einen sicheren Abschlussstatus ersetzt, bevor sie den Client erreichen. Ein einmaliges Bereinigungsskript räumt ältere Bestandsdaten in der isolierten CoreUI-Datenbank auf.
Live
Vollständige Antworten statt hartem Deckel
Der frühere 1000-Token-Deckel ist entfallen. Erreicht eine Antwort das Tokenlimit, wird sie anhand der Ollama-Abschlussmetadaten in bis zu zwei gezielten Segmenten fortgesetzt, statt die komplette Anfrage neu zu generieren. Auch die sichere Ausgabegrenze skaliert mit dem Tokenbudget, damit alte Konfigurationswerte neue Antworten nicht still kürzen.

Sitzungen mit harter Zuordnung

Live
Jede Nachricht gehört zu genau einer Sitzung
Die Sitzungs-ID ist die verbindliche Zugehörigkeit jeder privaten Nachricht — für Verlauf, Live-Stream, Hintergrundabfragen und Modellkontext gleichermaßen. Ohne gültige Sitzungs-ID liefert der Kontextpfad absichtlich gar keinen Verlauf. Spät eintreffende Antworten dürfen ausschließlich ihre Ursprungssitzung aktualisieren, nie den gerade sichtbaren fremden Verlauf.
Live
Antwort kennt ihre Frage
Eine Ember-Antwort ist über eine explizite Referenz an ihren auslösenden Turn gebunden statt über die Reihenfolge der Nachrichten-IDs. Auch Browser-Recherchen bleiben bis zum Abschluss des Workers an genau diesen Turn gehängt.
Live
Archivieren, Wiederherstellen, endgültig Löschen
Archivieren ist verlustfrei und umkehrbar; es löscht nichts. Erst bei einer archivierten Sitzung erscheint der endgültige Löschbefehl, und er verlangt zusätzlich eine Texteingabe sowie eine serverseitige Bestätigung mit konkretem Sitzungsbezug — eine manipulierte Oberfläche kann beides nicht umgehen. Die Löschung selbst läuft als eine Transaktion über Nachrichten, Reaktionen, Browser-Schritte, Frames und Medienzeilen; scheitert ein Schritt, bleibt alles unverändert. Dateien auf der Platte fallen erst nach erfolgreichem Commit, laufende Recherchen sperren die Löschung vorher ab.

Admin Core & Benutzerprofile

Live
Eigenständiges Admin Core
Übersicht, Benutzerrechte, Sperren, Memory-CRUD, Lore-Suche, Runtime-Schalter, Registrierung, Wartungsmodus, Logs und Audit — in einem eigenen Panel, das ausschließlich das CoreUI-Schema anspricht. Spiel, Homepage, Global-Chat und Repack-Admin werden dabei nicht berührt.
Live
Rechte wirken sofort, nicht erst beim nächsten Login
Berechtigungsstufe und aktive Sperre werden bei jedem authentifizierten Request neu aus der Datenbank gelesen und greifen damit auch in bereits offenen Sitzungen.
Live
Werkzeugpfade zentral schaltbar
Schnelle Websuche, tiefe Browser-Recherche und isoliertes Python lassen sich einzeln aktivieren oder abschalten. Ein optionaler externer Modell-Anbieter ist serverseitig vorbereitet, aber bewusst deaktiviert: API-Schlüssel liegen ausschließlich serverseitig und werden nie im Browser gespeichert.
Live
KI-Profil je Benutzer
System-Prompt, Memory-Schalter, Memory-Limit, Antwortbudget, Temperatur, Denkmodus und Modellwahl werden serverseitig pro Konto gespeichert. Benutzer verwalten ihre eigenen sichtbaren Gedächtnisfakten selbst; globale Fakten bleiben geschützt. Sicherheitsregeln und Werkzeuggrenzen bleiben in jedem Fall serverseitig aktiv. Registrierung und Admin Core legen Konten über denselben Provisioning-Pfad an, sodass kein Benutzer ohne Charakter-, KV- und Profildaten startet.
Runtime-Einstellungen im Ember CoreUI Admin Core
Admin Core · Runtime

Runtime-Sektor des Admin Core: Registrierung, Wartungsmodus, System-Prompt-Limit, die drei Werkzeugpfade und der vorbereitete, inaktive externe Adapter.

Memory-Verwaltung im Ember CoreUI Admin Core
Admin Core · Memory

Langzeitgedächtnis als CRUD: Fakt, Geltungsbereich, Relevanz und Zuordnung zu Benutzer oder Charakter.

Benutzerverwaltung im Ember CoreUI Admin Core
Admin Core · Benutzer

Benutzer und Rechte: neue Konten mit Anzeigename, Login-E-Mail, Startpasswort und Rolle anlegen. Jedes Konto bekommt dabei automatisch Profil, privaten Operator und funktionierende Sitzungen.

RAG-Lite- und Kanon-Verwaltung im Ember CoreUI Admin Core
Admin Core · Lore

RAG-Lite-Quellen mit ihrer Chunk-Anzahl und einer Volltextsuche über die indizierten Auszüge. Die Neuindizierung bleibt bewusst ein Terminal-Schritt.

Profil, Avatare und Modellwahl

Live
Sichtbarer Name, unveränderliche Identität
Jedes Konto hat einen frei wählbaren Anzeigenamen und dazu einen eigenen Namen für die KI, der in Chatblasen, Denkstatus, Tippanzeige und Eingabefeld erscheint. Login-E-Mail, numerische Benutzer-ID und die interne Operator-ID bleiben bei einer Umbenennung unverändert — und Embers technische Kernidentität samt Sicherheitsregeln wird davon nicht angefasst.
Einstellungsseite mit Profilen, Identitaeten und KI-Profil
Profil & KI-Profil

Zwei getrennte Avatar-Slots, eigener Anzeigename, frei wählbarer Name für die KI — darunter Memory-Kontext, Antwortbudget, Temperatur und die Modellwahl aus dem echten Ollama-Katalog.

Live
Avatare außerhalb des Webpfads
Zwei getrennte Bild-Slots, einer für den Benutzer, einer für die KI. Angenommen werden PNG und JPEG bis 4 MiB; geprüft werden MIME-Typ, Abmessungen, Pixelmenge und ob sich die Datei überhaupt dekodieren lässt. Danach wird zentral quadratisch zugeschnitten, auf höchstens 512×512 skaliert und ohne fremde Bildmetadaten neu als PNG kodiert. Die Dateien liegen nicht im statischen Webpfad: ein eigener Endpunkt prüft die Sitzung und liefert nur den Avatar des angemeldeten Kontos aus.
Live
Denkmodus als echter Schalter
Der Thinking-Schalter versteckt nicht bloß eine Oberfläche, sondern setzt den offiziellen Ollama-Parameter. Ist er aus, sendet Ember CoreUI keine Denkstatus-Ereignisse und speichert für neue Antworten auch keinen. Ist er an, bleiben rohe Gedankengänge weiterhin strikt serverintern.
Live
Modellwahl nur aus dem echten Katalog
Das frühere Freitextfeld für den lokalen Modelltag ist einer Auswahlliste gewichen, die über Ollamas Tag-Endpunkt befüllt wird. Die Ziel-URL stammt ausschließlich aus der betreiberkontrollierten Konfiguration, Benutzereingaben können weder Host noch Protokoll bestimmen. Vor dem Speichern wird erneut gegen die aktuelle Liste geprüft; ein leerer Wert nutzt weiterhin den Serverstandard, ein inzwischen entferntes Modell bleibt sichtbar als nicht mehr installiert markiert.
Live
Bis zu zehn Anhänge pro Nachricht
Der Composer lädt mehrere Dateien nacheinander hoch und zeigt Fortschritt und fertige Anhänge einzeln an. Nachricht und geordnete Anhangliste werden in einer gemeinsamen Transaktion gespeichert, sodass kein Teilfehler eine Nachricht ohne Zuordnungen hinterlässt. Jede Datei muss dem angemeldeten Benutzer gehören. Text- und Dokumentanhänge teilen sich ein kontrolliertes Kontextbudget; Bilder, Videoframes und gerasterte PDF-Seiten sind auf höchstens 16 Vision-Eingaben je Turn begrenzt.

Privates RAG-Lite je Konto

Live
Eigene Dokumente, getrennt vom Studio-Kanon
TXT, Markdown, Text-PDF und DOCX lassen sich direkt in den Einstellungen hochladen, extrahieren, listen und wieder löschen. Diese privaten Quellen liegen in eigenen Tabellen und berühren den global kuratierten Kanon aus Bibel und Kompendium nicht. Volltextsuche und Fallback filtern immer nach dem authentifizierten Konto — ein Benutzer kann weder Chunks eines anderen abrufen noch dessen Quellen löschen.
Sektor Mein Wissen mit privaten RAG-Lite-Quellen
Mein Wissen

Privates RAG-Lite in den Einstellungen: eigene Quellen mit Chunk-Anzahl und Größe, daneben der global kuratierte Kanon als getrennte Zählung. Scan-PDFs ohne Textebene werden abgelehnt statt geraten.

Live
Import, der nichts erfindet
Text wird kontrolliert nach UTF-8 normalisiert und in Abschnitte von rund 1400 Zeichen mit 180 Zeichen Überlappung zerlegt. PDFs laufen lokal über pdftotext mit begrenzter Laufzeit; ein Scan ohne Textebene wird eindeutig abgelehnt, statt einen Inhalt zu halluzinieren. Beim DOCX-Import wird nur das Dokument-XML gelesen, externe XML-Netzwerkzugriffe sind abgeschaltet, Größe und Absatzanzahl begrenzt.
Live
Quoten mit echtem Sperrmechanismus
Standard sind 20 MiB je Datei, 40 Quellen und fünf Millionen extrahierte Zeichen pro Konto, maximal 1200 Abschnitte je Dokument. Ein kontospezifischer Datenbank-Lock umschließt Quotenprüfung und Speicherung, damit gleichzeitige Uploads desselben Benutzers die Grenzen nicht gemeinsam unterlaufen. Originaldateien liegen privat und werden nicht direkt vom Webserver ausgeliefert.
Live
Dokumentinhalt bleibt Daten, nicht Anweisung
Passende private Abschnitte gehen in den Modellprompt, aber ausdrücklich als nicht vertrauenswürdige Daten markiert. Anweisungen, die in einem hochgeladenen Dokument stehen, bekommen keine Systempriorität.

Geräte-Anmeldungen und Kontoexport

Live
Passwortwechsel mit sauberem Schnitt
Der Wechsel verlangt das aktuelle Passwort, mindestens zwölf Zeichen für das neue und eine identische Bestätigung; ein unverändertes Passwort wird abgelehnt. Danach werden sämtliche bisherigen Anmeldungen des Kontos widerrufen und nur für das gerade benutzte Gerät eine neue Sitzung samt neuem Token ausgestellt. Scheitert diese Neuausstellung, wird die lokale Sitzung sicher beendet statt halb offen gelassen.
Sektor Konto und Zugriff mit Passwortwechsel, Geraeteliste und Datenexport
Konto und Zugriff

Passwortwechsel, aktive Geräte-Anmeldungen mit Gerät, Browser, letzter Aktivität und Ablauf — die eigene ist als solche markiert. Daneben der private JSON-Export der eigenen Daten.

Live
Anmeldungen sind nicht dasselbe wie Unterhaltungen
Geräte-Anmeldungen werden ausdrücklich von den Chat-Sitzungen getrennt geführt. Die Einstellungen listen bis zu 50 aktive Anmeldungen mit Gerät, Browser, letzter Aktivität und Ablauf; die eigene ist als solche markiert. Einzelne andere lassen sich gezielt widerrufen, alle anderen auf einmal abmelden. Nach 30 Tagen ohne Aktivität läuft eine Anmeldung ohnehin ab.
Live
Das Token verlässt die Sitzung nicht
Das zufällige 256-Bit-Anmeldetoken bleibt in der geschützten PHP-Sitzung; die Datenbank sieht nur dessen Hash. Vor jeder Antwort werden die Hashes aus den Datensätzen entfernt und landen weder im DOM noch im Export noch in Auditdetails. Jeder authentifizierte Aufruf prüft die Anmeldung erneut, widerrufene oder abgelaufene Tokens verlieren sofort den Zugriff.
Live
Kontoexport, der nur eigene Daten enthält
Ein privater JSON-Export liefert Konto-Metadaten, sichtbares Profil, beide Avatare, persönliche KI-Einstellungen, eigene Charaktere und Memories, private Wissensquellen samt Abschnitten sowie Sitzungen, Nachrichten und Anhangmetadaten. Nicht enthalten: der global kuratierte Kanon und globale Studio-Memories — die sind keine persönlichen Daten. Ebenfalls draußen bleiben Passwort-Hashes, Reset-Codes, Tokens und ihre Hashes, interne Denkinhalte, Serverpfade und die Binärdaten hochgeladener Dokumente.

Diagnostik & Selbsttests

Jede sicherheitsrelevante Änderung bekommt einen eigenen, wiederholbaren Selbsttest: für Video-Frames, PDF-Verarbeitung, Thinking-Sanitizing, Sitzungstrennung, Profil und privates Wissen, Kontosicherheit und die Löschtransaktion — letztere legt zwei isolierte Testsitzungen samt Nachricht, Antwort, Upload und Browser-Job an, löscht nur eine davon und rollt den gesamten Test anschließend zurück. Compose- und Native-Preflight prüfen vor jedem Start Laufzeitpfade, Datenbankschema, Nginx-Templates und die Erreichbarkeit zentraler Routen.

Bekannte Alpha-Grenze: Die Neuindizierung des global kuratierten Kanons bleibt bewusst ein kontrollierter Terminal-Schritt und ist nicht aus dem Panel heraus auslösbar — privates Wissen dagegen lädt jeder Benutzer selbst über die Einstellungen hoch. Der optionale externe Modell-Anbieter ist zwar serverseitig vorbereitet, aber abgeschaltet; Referenzbetrieb ist und bleibt das lokale Gemma 4 über Ollama.

Wissenschaftlicher Hintergrund

Die zugrundeliegende Kognitionsarchitektur — RAG-Lite über native FULLTEXT-Indizes, probabilistisch gesteuerte Selbstreflexion, die autonome Initiative-Engine und das Konkurrenzmodell für CPU-Inferenz — ist unabhängig von Ember CoreUI im EMBER-Whitepaper dokumentiert.