RAG-Quellen (Tabelle SharePoint-Quellen 2) sind jetzt die fünf indexierbaren Wissensbasis-Unterordner (Anwenderdokumentationen, Technische Dokumentationen, Rechte und Rollen, Compliance, Kundeninformationen; je typ=intranet). Alte „Dokumentationen"-Library als Quelle entfernt. Sync-source_url baut jetzt lib=<Ordnername> (statt hartcodiert), damit Chat-Quellen den richtigen Doku- Bereich-Tab öffnen. Sync gelaufen, 5 Ordner indexiert; Doks ohne Unterordner- Zuordnung (Pitch, KI-und-Fraia-Sales, Nutzungsrichtlinien) aus dem RAG gefallen - gewollt. Nur .html wird indexiert (Compliance-PDFs/DOCX nicht).

Alle SharePoint-Quellen laufen jetzt über dieselbe Pipeline. Neue Tabelle „SharePoint-Quellen 2" (i0Lj90e8dol2zel5) mit Spalte „typ". Der Sync (f8LIvTMr4qZTvXso) reicht typ durch: typ=intranet -> document_source „sharepoint-html" + source_url auf das Intranet-Doku-Show-Sandwich, sonst „sharepoint". Delta/Cleanup auf beide document_source-Werte geweitet. srcFor-Fix: Quelle->Datei-Zuordnung jetzt per driveId statt nur Pfad-Präfix (Library-Wurzel matchte vorher nicht -> typ blieb fälschlich „standard"). Admin-Backend (v2byqmPU2Vccioig) auf die neue Tabelle + typ umgestellt; die Dokumentationen-Library erscheint im Panel. Verifiziert: 16 Dokumente unverändert, 2 Changelog-Chunks automatisch gelöscht.

Das Formular „SharePoint-Quelle hinzufügen" hat ein Typ-Dropdown (Standard rechtebeschränkt / Intranet-Doku für alle); bei Standard ist die Gruppe Pflicht, Intranet-Quellen zeigen „Intranet - für alle sichtbar" statt Gruppen-Dropdown. Die SharePoint-Ordner-URL in der Quellenliste ist jetzt ein klickbarer Link (öffnet den Ordner in neuem Tab). Der Block „Front-End-Zugriff" zeigt jetzt die Entra-Gruppen (Benutzer/Admin) mit Mitglieder-Anzahl statt der Einzelpersonen-Liste; der überflüssige tenant-weite users-list-Graph-Call entfällt.

Nachdem die Quelldateien in SharePoint gelöscht wurden, lief der Sync in die 0-Dateien-Schutzbremse („Abbruch vor versehentlichem Cleanup") - das hielt das Dashboard auf Dauer-error. Fix (f8LIvTMr4qZTvXso): neue Verzweigung „Keine Quellen?" nach „Quellen-Token bauen" - bei 0 aktiven Quellen kommt eine freundliche 200-Antwort („nichts zu syncen") statt des throw, und zwar OHNE Resolve/List/Diff/Cleanup (kein Datenrisiko). Die Quelle „Daten der Wissensbasis" wurde aus der Tabelle SharePoint-Quellen entfernt. Sync bleibt aktiv und einsatzbereit für künftige SharePoint- Quellen. Die 304 Chunks blieben unangetastet.

Die versteckende CSS-Regel (body.stack-azure .doc-btn.delete) wurde entfernt - lokal in styles.css und chirurgisch im deployten Frontend- Bundle (F1ma6YU1imRqFVYF). Admins können Dokumente damit wieder pro Eintrag aus Qdrant löschen (zweistufige „Wirklich löschen?"-Bestätigung). Der Backend-Delete-Endpunkt war bereits admin-geschützt vorhanden. Hinweis: aktiv gesyncte Quellen kommen beim nächsten Sync-Lauf zurück.

Aus dem RAG-Permission-Thema (Teams sah weniger als das Web). Ursache: der Teams-Bot erzeugte ein fest verdrahtetes Service-JWT mit role:'user' ohne Gruppen - egal wer schrieb. Der Permission-Filter im RAG-Chat blendete dadurch document_source='sharepoint'-Chunks (u.a. den Changelog) aus. Fix (DSGwZZrDQOJPhPLs): - Neuer Node „Absender-Gruppen holen": Graph-Lookup /users/{aadObjectId}/ memberOf mit der Read-only-Cred (tarKfwlkOqGxAaez). - „Service-JWT generieren" leitet role + groups aus der echten Gruppen- mitgliedschaft ab (Admins-Gruppe -> role:'admin'), Username aus der Activity. So sieht der Absender im Teams dieselben Inhalte wie im Web. - Datenfluss-Fix: question/conversationId werden wieder aus „Activity verarbeiten" gezogen (der eingefügte Graph-Node hatte das durchlaufende Item ersetzt -> Frage ging verloren -> generische „tschüss"-Antwort).

Aus dem Security-Check (P1). Der Teams-Bot-Webhook (DSGwZZrDQOJPhPLs) prüfte bisher nur das serviceUrl-Muster - fälschbar. Jetzt wird der eingehende Microsoft-Token vollständig validiert: - Neuer Node "JWKS holen": holt die Signaturschlüssel von https://login.botframework.com/v1/.well-known/keys (jwks_uri aus dem OpenID-Metadokument; das zuerst geratene /v1/keys war 404). - Neuer Node "Bot-Token prüfen": RS256-Signaturprüfung in pure JS (BigInt-Modexp + vorhandenes SHA-256, PKCS#1 v1.5) + Claims-Check (aud == Bot-AppId, exp, iss). n8n-Sandbox-sicher, kein crypto-Modul. - IF "Auth gültig?": ungültig/fehlend -> 401, gültig -> normaler Flow. Rollout in 2 Stufen (Monitor -> Enforce) mit echtem Teams-Token verifiziert: valider Token = durch, kein/gefälschter Token = 401. Antwort im Teams unter Enforce bestätigt.

Build-Prompt-Node (azure-rag-build-prompt) im RAG-Chat-Workflow (wWCoSj4prVSExZJq) leichten Patch erhalten: const u = r.payload.source_url || r.payload.web_url || r.payload.url; if (u && !docUrls.has(name)) docUrls.set(name, u); Neue HTML-Chunks (document_source='sharepoint-html') liefern source_url auf das Intranet-Doku-Show-Sandwich; alte PDF-Chunks (document_source='sharepoint') fallen auf web_url zurueck. Beide Quellentypen sind seit dem Re-Sync mit umbenannten Filenamen aktuell - alte 'Doku - ...'-Filenamen sind aus dem HTML-Index raus, im PDF-Index noch da (Cut-Over offen).

Caddy-Block (Root-Rewrite auf /webhook/atlas-frontend) seit 31.05.2026 vormittag spaet von Christoph deployed. Atlas-Frontend erreichbar ueber https://atlas-001.fraia.de/.

Token-per-Minute-Quota am Foundry-Deployment hochgesetzt - alter Default 10K war Ursache der 429-Fehler im Atlas-Chat. Embedding- Deployment text-embedding-3-large bleibt auf 410K seit 28.05.2026.

Neuer Workflow "Fraia.Atlas-001 - HTML Library Sync" (ID 3HIhCO1HnwMo9fe2, Webhook POST /atlas-html-sync) indexiert die SharePoint-Library "Dokumentationen" (driveId b!gU-gDKywHUSsZUFp... cccff7b71-Z, Site /sites/intranet) direkt als HTML, ohne PDF-Roundtrip: - Children GET (flach, keine Rekursion - Library hat keine Unterordner) - HTML normalisieren: Mermaid-Bloecke + script/style/svg/head/ comments entfernen, Tags strippen, Entities decoden (inkl. ouml/auml/uuml/szlig), Whitespace normalisieren - Chunks 1200 Zeichen mit 100 Overlap (wie bestehender Sync) - 25 Chunks/Batch fuer Azure-Embedding text-embedding-3-large - Qdrant-Insert mit neuem Payload-Feld source_url: https://intranet.frairaum-management.de/webhook/intranet ?view=doku-show&lib=dokumentationen&file=<encoded> Beim Anklicken einer RAG-Quelle wird damit das Intranet- Sandwich geoeffnet, nicht mehr das SharePoint-PDF. - document_source='sharepoint-html' (klare Trennung zu den alten 'sharepoint'-Chunks) - Soft-Delete: Cleanup-Filter scope-iert auf document_source= sharepoint-html und sync_id != current, beruehrt keine anderen Quellen Erster Lauf erfolgreich: 18 Dokumente -> 12 Batches -> 299 Chunks in fraia-atlas-docs, ~8 Sekunden Laufzeit. Status der Wissensbasis aktuell parallel: - document_source='sharepoint' (alter PDF-Sync): aktiv - document_source='sharepoint-html' (neuer HTML-Sync): aktiv Beide werden vom RAG-Chat gefunden, bis Phase 3 (Chat passt Quellen-Box auf source_url) und Cut-Over (alte PDF-Chunks abraeumen) folgen.

Vorher: bei channel='teams' wurde history immer auf [] gesetzt - Folgefragen ohne Kontext, Antworten wirkten „veraltet" gegenüber dem Web-Chat. Fix: Teams-Bot-Workflow (ID DSGwZZrDQOJPhPLs) sendet jetzt zusätzlich die `conversationId` an den RAG-Chat. RAG-Chat- Workflow (ID wWCoSj4prVSExZJq) liest und schreibt history pro conversationId in einer separaten staticData.teamsHistory-Bucket (getrennt von staticData.history[userId] für Web). Beide Stränge sind auf 20 Einträge gerollt. Effekt: Folgefragen wie „und das X - wo finde ich das?" funktionieren jetzt im Teams-Bot mit Kontext. Hinweis: $getWorkflowStaticData wird bei Workflow-Edits zurück- gesetzt - für echte Persistenz später eine Data Table.

Workflow `Fraia.Atlas-001 - Frontend` (ID F1ma6YU1imRqFVYF) Node „HTML senden": X-Frame-Options: SAMEORIGIN entfernt. Content- Security-Policy um frame-ancestors erweitert: default-src * 'unsafe-inline' 'unsafe-eval' data: blob:; frame-ancestors 'self' https://*.sharepoint.com https://*.sharepoint.de https://*.cloud.microsoft https://*.officeapps.live.com https://atlas-001.fraia.de https://aurora-001.fraia.de https://n8n-01.strukturwerk-ki.de; Hintergrund: Vorbereitung für Embedding im FrAIraum-Intranet (eigenes Frontend, /webhook/intranet) und in SharePoint-Seiten. Funktional unverändert für direkten Browser-Aufruf.

Token-Kosten und Azure-Kosten in einen Block „Kostenmanagement" zusammengezogen. Wichtig + bewusst: die Azure-Ist-Kosten sind der ECHTE Gesamtwert (Azure OpenAI läuft in der Subscription, ist also schon enthalten) - die KI-Token-Schätzung steht daneben nur als Cross-Check („davon Chat-KI"), wird NICHT addiert (keine Doppelzählung). Der veraltete „OpenAI-Nutzung"-Link (Überbleibsel der alten OpenAI-Instanz vor dem Atlas-Cutover 27.05.) ist raus; stattdessen der Azure-Kostenanalyse-Link.

Neuer kleiner Kostenblock im Dashboard, direkt bei den (geschätzten) Token-Kosten: zeigt die echten Azure-Subscription-Ist-Kosten (Monat bis heute, EUR) der Subscription FrAIraum-Prod + Deep-Link in die Azure- Kostenanalyse. Quelle ist die Azure Cost Management API (management.azure.com) - NICHT Microsoft Graph, sondern eine eigene App „FrAIa - Kosten lesen" mit Azure-RBAC-Rolle „Kostenverwaltung: Leser" auf der Subscription (kein Graph-Consent). Neuer Dashboard-Node „Azure-Kosten holen" (neverError, graceful -> bei Fehler „nicht abrufbar"). Hinweis im Block: Azure-Kostendaten hinken ~24 h. Verifiziert (~1 € MTD).

Ein wiederholter/abgelaufener Login-Callback (z.B. neu geladene Callback-URL) crashte vorher am Token-Exchange („URL parameter must be a string, got undefined"). Jetzt fangen zwei IF-Guards (State-Fehler? / Token-Fehler?) die Fehler- und Reuse-Fälle ab und leiten sauber per 302 zur Login-Seite; das Frontend zeigt dann „Der Anmelde-Link ist abgelaufen oder wurde bereits verwendet. Bitte melde dich erneut an." statt einer kryptischen Meldung. Außerdem repariert: das „Sichtbar für"-Dropdown im SharePoint-Quellen-Panel war nach dem Entschlacken der SharePoint-Sync-App leer (der Gruppen-Lese-Node im Admin-SharePoint-Workflow lief noch auf der alten Credential) - jetzt auf die read-only App „Gruppen und Nutzer lesen" umgebogen, Dropdown listet die Entra-Gruppen wieder.

Das Panel listet nur noch Personen MIT Rolle (Admins/Benutzer); "Kein Zugriff" wird nicht mehr angezeigt - kompaktere, relevante Liste.

Das Verwalten der Rollen aus dem Frontend ist wieder raus: die Gruppen- Mitgliedschaft (Admins/Benutzer) ändert ausschließlich der Entra-Admin in Microsoft Entra - das Panel zeigt Personen + Rolle nur noch an (Badge), konsistent zur SharePoint-Logik (Frontend schreibt nie Entra). Der Schreib-Pfad (group-add/remove samt Auswertung) ist aus dem Workflow Webseiten-Verwaltung entfernt (25 statt 33 Nodes). Das Gruppen-/Nutzer- Lesen läuft jetzt über eine eigene, read-only Entra-App „FrAIa - Gruppen und Nutzer lesen" (GroupMember.Read.All + User.Read.All); die SharePoint-Sync-App wurde im Gegenzug auf Sites.Read.All entschlackt (Prinzip: eine App pro Zweck). Verifiziert: Admins/Benutzer + Klarnamen werden korrekt gelesen.

Der RAG-Chat brach bei einem kurzen Azure-OpenAI-Aussetzer sofort mit „Verbindungsfehler" ab, weil der Node „Embed Query (Azure)" kein Retry hatte (anders als der Sync-Embed). Jetzt 3 Versuche mit 2 s Abstand - transiente Azure-Fehler (z.B. „The service was not able to process your request") werden abgefangen, statt die ganze Anfrage zu killen. Ursache des akuten Chat-Ausfalls am 29.05. war ein bestätigter Microsoft-Incident („Azure OpenAI Service Elevated Error Rates in multiple regions", via Azure Service Health) - der Embedding-Aufruf in Sweden Central lief in HTTP 500. Kein Defekt auf unserer Seite; bei längerer Azure-Störung helfen auch Retries nicht (offen: freundlicher Ausfall-Hinweis im Chat statt rohem „Verbindungsfehler").

Das Panel „Front-End-Zugriff" (Admin-Einstellungen) listet jetzt - analog zu „SharePoint-Quellen & Zugriff" - alle Personen aus Microsoft Entra. Rechts je Person ein Rollen-Dropdown: Admin, Benutzer oder Kein Zugriff. Die Rolle entspricht der exklusiven Gruppenmitgliedschaft (Admin nur in der Admins-Gruppe, Benutzer nur in der Benutzer-Gruppe) und wird direkt in Microsoft Entra gesetzt; das Umsetzen ist idempotent (bereits gesetzt bzw. bereits entfernt gilt als Erfolg). Backend: drei neue Aktionen am Workflow Webseiten-Verwaltung (Nutzerliste lesen, Mitglied hinzufügen, Mitglied entfernen). Der Endpunkt kann ausschließlich die zwei bekannten Frontend-Gruppen ändern (Gruppen-ID-Whitelist im Code) und bleibt admin-only. Voraussetzung fürs Schreiben ist die Microsoft-Berechtigung GroupMember.ReadWrite.All - bis sie erteilt ist, zeigt die UI einen klaren Hinweis statt eines Fehlers. Lesen (Nutzerliste, Mitglieder) funktioniert bereits.

Panel „Funktionen" in „Features" und „Wissensbasis-Webseiten" in „Website-Quellen" umbenannt. Der Block „Microsoft-Gruppen & Zugriff" wandert vom Dashboard in die Einstellungen und heißt dort jetzt „Front-End-Zugriff" - er zeigt die beiden Microsoft-Sicherheitsgruppen samt Mitgliedern. Panel-Reihenfolge in den Einstellungen: Features, Front-End-Zugriff, SharePoint-Quellen & Zugriff, Website-Quellen. (Die Möglichkeit, Personen direkt aus diesem Panel einer Gruppe zuzuordnen oder zu entfernen, folgt separat - sie braucht eine neue Microsoft-Schreibberechtigung.)

Das Web-Frontend hat einen neuen Tab "Dashboard" mit einer Live-Statusübersicht von Atlas-001: eine Gesamt-Ampel (grün / neutral-grau / rot), Kennzahl-Kacheln (indexierte Chunks, Fehler der letzten 24 Stunden und 7 Tage, letzter Sync) und ein Komponenten-Status für Qdrant, SharePoint-Sync und Webseiten-Sync. Aus dem E-Mail-Briefing führt der Klick auf die Atlas-001-Karte direkt ins Frontend.

Alle Atlas-Workflows melden ihre automatischen Fehler jetzt an einen gemeinsamen Fehler-Log. Das Dashboard zeigt sie mit Klartext-Meldung, betroffenem Node und einem Direktlink in die jeweilige n8n-Ausführung - vorher war ein Fehler nur eine nackte Zahl im Briefing.

Jede Chat-Antwort protokolliert ab sofort ihre Kennzahlen (Trefferqualität, Latenz, Tokens) - ohne Fragetexte zu speichern. Das Dashboard zeigt daraus einen Konfidenz-Donut (hoch / mittel / niedrig), die durchschnittliche Trefferqualität und einen Wissenslücken-Zähler: Fragen mit schwacher Trefferlage sind das Signal, welche Dokumente in der Wissensbasis noch fehlen.

Unter jeder Fraia-Antwort stehen jetzt zwei Daumen (hilfreich / nicht hilfreich). Das direkte Nutzerurteil fließt als Zufriedenheitsquote ins Dashboard - das ehrlichste Signal für die Antwortqualität.

Das Dashboard rechnet den Token-Verbrauch grob in Euro um (gpt-4.1-mini, input-lastige RAG-Nutzung), damit der laufende Aufwand auf einen Blick greifbar ist.

Wer sich am Frontend anmelden darf und ob als Admin oder normaler Nutzer, wird jetzt über zwei Entra-Sicherheitsgruppen gesteuert (Admins-Gruppe und Benutzer-Gruppe). Die Rolle wird aus der Gruppenmitgliedschaft im Microsoft-Token abgeleitet. Neue Personen werden einfach der passenden Gruppe hinzugefügt, ohne Code-Änderung. Die alte fest verdrahtete Mitgründer-Liste bleibt nur als Fallback.

Neuer Dashboard-Block "Microsoft-Gruppen & Zugriff" zeigt die beiden Zugriffs-Gruppen und ihre Mitglieder (Name, E-Mail, aktiv/deaktiviert) direkt aus Microsoft Graph. So ist auf einen Blick klar, wer Zugriff hat und mit welcher Rolle.

In den Admin-Einstellungen lassen sich die "War das hilfreich?"-Daumen jetzt für den Web-Chat und für Teams getrennt ein- und ausschalten. Die Schalter wirken serverseitig (Feature-Flags), also für alle Nutzer und beide Kanäle zugleich.

Admins können in den Admin-Einstellungen öffentliche Webseiten hinterlegen, die der Webseiten-Sync zusätzlich ohne Login crawlt und indexiert - parallel zu den beiden internen FrAIraum-Seiten, die weiterhin mit Zugangsdaten abgeglichen werden.

Die Buttons "SharePoint synchronisieren" und "Webseiten synchronisieren" sitzen jetzt direkt in den jeweiligen Status-Kacheln des Dashboards (Status und Auslöser an einem Ort). Die beiden Admin-Menüpunkte tragen ein Schild-Symbol statt des Wortes "Admin-". Der Komponenten-Status nutzt klare Häkchen/Kreuz-Symbole statt farbiger Punkte, die Konfidenz-Palette wurde kontrastreicher gemacht, ein 30-Tage-Qualitätsblock und ein dezenter Link zur echten OpenAI-Nutzung kamen hinzu.

Der Menüpunkt "Dokumente in der Wissensbasis" entfällt. Die Dokumentenliste ist jetzt über einen Button in der Qdrant-Kachel des Dashboards erreichbar; von dort führt ein Zurück-Button wieder ins Admin-Dashboard. Die Admin-Einstellungen sind in "Funktionen" und "Wissensbasis-Webseiten" gegliedert.

Der bisher fest im Workflow eingebaute Teams-Ordner ist raus - der Sync liest nur noch die Quellen aus der Tabelle. Der interne Ordner „Daten der Wissensbasis" läuft jetzt als normale, verwaltbare Quelle (in der UI sicht- und in der Sichtbarkeit steuerbar). Umstellung ohne Re-Index und ohne Datenverlust (Bestand per SharePoint-Datei-ID als unverändert erkannt); die Altlast „Kundenunterlagen-Test" wurde dabei aufgeräumt. Für Kundenstacks heißt das: keine festen Pfade im Code, alles über die Oberfläche konfigurierbar.

Die vier Verwaltungs-Bereiche (Funktionen, Wissensbasis-Webseiten, SharePoint-Quellen, Ordner-Zugriff) sitzen jetzt in klar abgegrenzten Karten mit eigener Kopfzeile (Emerald-Akzentbalken) statt flach untereinander - übersichtlicher und konsistent mit dem CI.

Der Dashboard-Block zeigte „Insufficient privileges", weil die Abfrage Mitglieder-Profilfelder (u.a. accountEnabled) per $expand verlangte. Umgestellt auf den direkten /members-Endpunkt - der Block zeigt jetzt die Mitgliederzahl je Gruppe. Die Klarnamen der Mitglieder bleiben noch verborgen: dafür braucht die Graph-App zusätzlich die Berechtigung User.Read.All (GroupMember.Read.All allein gibt nur die Mitgliedschaft als IDs frei, Graph maskiert Name/E-Mail).

Die Admin-Einstellungen haben zwei neue Bereiche: (1) "SharePoint-Quellen" - zusätzliche SharePoint-Ordner per URL hinzufügen, deaktivieren oder entfernen; (2) "Ordner-Zugriff" - per Klick festlegen, welche Microsoft- Gruppe welchen Ordner bzw. welche Quelle sehen darf (Gruppen-Auswahl als Dropdown direkt aus Entra, Ordner-Vorschläge aus den vorhandenen Quellen). Damit ist die komplette Wissensbasis-Verwaltung (Quellen + Berechtigungen) ohne Workflow-Eingriff über die Oberfläche pflegbar - ein eigenes Admin-Backend steht dahinter, nur für Admins.

Der SharePoint-Sync kann jetzt beliebig viele SharePoint-Verzeichnisse einlesen - nicht mehr nur den einen Teams-Ordner. Quellen werden in der neuen Tabelle "SharePoint-Quellen" per SharePoint-URL hinterlegt (intern über Microsoft Graph zu Laufwerk-/Ordner-ID aufgelöst) und vollständig rekursiv durchsucht (auch tief verschachtelte Unterordner). Jede Quelle bekommt ihr eigenes Label, das direkt in die Zugriffssteuerung (Ordner -> Gruppe) einfließt. Sicherheitsnetz: Schlägt das Auflisten einer Quelle fehl oder werden 0 Dateien gefunden, bricht der Lauf ab, BEVOR der Aufräumschritt etwas löschen kann - so kann ein Verbindungsfehler nie versehentlich die Wissensbasis leeren. Die internen Teams-Inhalte laufen unverändert als feste Quelle weiter.

Der RAG-Chat filtert die SharePoint-Inhalte jetzt pro Nutzer: Wer einen Ordner nicht sehen darf, bekommt auch keine Antworten daraus - die betreffenden Stellen erreichen das Sprachmodell gar nicht erst. Steuerung über die Microsoft-Sicherheitsgruppen des Nutzers: in der neuen Tabelle "SharePoint-Zugriff" wird je Ordner eine Gruppe hinterlegt; nur Mitglieder dieser Gruppe sehen den Ordner. Defaults: nicht zugeordnete Ordner sind nur für Admins sichtbar, Admins sehen alles, Webseiten-Inhalte bleiben für alle offen. Der Filter wirkt direkt in der Vektorsuche (Qdrant), die Gruppen kommen aus dem Microsoft-Login-Token. Greift zunächst im Web-Chat; Teams folgt später. Ordner-Zuordnung wirkt sofort, ohne Neu-Indexierung.

Der frühere Block "Antwort-Qualität" hieß irreführend: der Donut misst die Retrieval-Konfidenz (wie gut die Suche in der Wissensbasis getroffen hat), nicht die Güte der Antwort selbst. Bei text-embedding-3-large liegen schon sehr gute Treffer real bei 40-68 %, die alte "hoch"-Schwelle (70 %) war praktisch unerreichbar - deshalb sah alles nur "mittel" aus. Geändert: Block heißt jetzt "Antwort-Auswertung", der Donut ist klar als "Retrieval-Konfidenz" benannt, die Nutzer-Zufriedenheit (Daumen-Feedback) steht als eigentliches Qualitätssignal als Headline-Kachel vorn. Die Konfidenz-Schwellen wurden an die reale Verteilung kalibriert: hoch ab 55 %, mittel ab 40 %, niedrig darunter.

"Aktive Nutzer" steht jetzt bei den Kennzahl-Kacheln oben (neben Chunks, Fehlern und letztem Sync) statt im Qualitätsblock. Tokens und Kosten sind in den Qualitätsblöcken zu einer Kachel zusammengefasst (erst Tokens, darunter die geschätzten Kosten). Der 30-Tage-Block ist standardmäßig eingeklappt und lässt sich per Knopf "Historische Daten anzeigen" aufklappen. Die Unterzeile unter der Überschrift ist entfallen.

Wird Fraia nach sich selbst gefragt (Workflows, Architektur, Stack, Modelle), antwortet sie jetzt ausschließlich über Atlas-001 und blendet Aurora-001-Quellen aus - auch wenn die Aurora-Architektur-Doku in der Wissensbasis liegt. Nur auf ausdrückliche Nachfrage geht sie auf Aurora-001 ein. Vorher vermischte sie bei Selbstauskünften beide Stacks.

Der Teams-Bot nutzt das server-seitige Gesprächsgedächtnis des RAG-Chats bewusst nicht mehr: jede Teams-Anfrage steht für sich. Vorher teilten sich alle Teams-Nachrichten (und der Web-Login) denselben Verlauf - das ist jetzt entkoppelt.

Microsoft hat das Kontingent für das Embedding-Modell text-embedding-3-large in Sweden Central von anfangs 10K auf 410K Tokens/Minute (und 1230 Requests/Minute) angehoben. Die frühere Drosselung (HTTP 429) bei großen Sync-Läufen, etwa umfangreichen Compliance-PDFs, ist damit aufgehoben.

Die in einer Antwort genannten Quellen sind jetzt klickbare Links - sowohl im Web-Chat als auch im Microsoft-Teams-Bot. Ein Klick öffnet das Dokument direkt in SharePoint. Damit die Dokumente dabei inline angezeigt werden statt heruntergeladen, liegen die Wissensbasis-Dokumente jetzt als PDF in SharePoint.

Die lokale Anmeldung (Benutzername/Passwort) samt lokaler Benutzerverwaltung wurde komplett aus dem Atlas-Auth-Workflow entfernt. Die Anmeldung läuft jetzt ausschließlich über das Microsoft-Konto (Entra ID).

Atlas-001 hat einen eigenständigen Health-Check (täglich 08:00 Uhr): prüft Erreichbarkeit, gefüllte Wissensbasis und ob der nächtliche Sync jünger als 26 Stunden ist. Verschickt ab sofort nach jedem Lauf eine Status-Mail (OK oder ALERT), nicht mehr nur im Fehlerfall.