.......................... Tasks

In den Einstellungen des Frontends soll die Sprache des aktiven benutzers gemäss den Listenoptionen in den "...model.py" angepasst werden können. die sprache gilt dann auch für die Attributnamen in einem Formularfeld im  "generic-entity.js". eine sprachänderung zieht somit eine anpassung des Users über das API nach sich, indem die Sprache in der Datenbank angepasst wird.

Chat mit Instant message - auch inputs geben während der ausführung


--------------------------- OPEN

Workflow mit dem dynamischen Multi-Agent Chat aktualisieren und im Ausführungsprotokoll die Details eines laufenden Chats mit aufklappbaren Texten ergänzen. Das Ausführungsprotokoll-Fenster dynamisch in der Grösse anpassbar machen

Css aufräumen und konsolidieren für gemeinsame Klassen mit allen html und js parallel

Linkes Menu: Gruppierungsbereiche zum auf- und zuklappen machen:

----------------------- done


Admin Seite mit CRUD für User Mgmt und Mandate Management, generisch

Im Frontend soll im generischen Formular "generic-entity.js" für ein neues Objekt die ID entweder hidden oder schreibgeschützt sein. die ID wird nicht benötigt, sondern wird erst mit dem speichern in der datenbank erstellt. d.h. nach dem speichern in der datenbank werden die daten der entsprechenden tabelle neu geladen.


Kannst du mir bitte code struktur und logik das 'agentservice_interface.py' anpsssen und die code struktur zur besseren wartung und weiterenwticklung verbessern:

1. die anbindung der ai-modelle mit den entsprechenden config-daten und den funktionsaufrufen in separate dateien auslagern ("connector_ai_openai","connector_ai_webscraping"). im 'agentservice_interface.py' die connector module bei der initialisierung importieren und vorbereiten.

2. den agenten-chat 'execute_workflow' nicht in der reihenfolge der agents ausführen, sondern als tischrunde der agents.das heisst ein AI moderator moderiert die agenten autonom und ruft anhand der produzierten antworten und der eigenschaften der agentss den jeweils nächsten geeigneten agenten anhand der 'capabilities' auf, nachdem ein agent seine antwort geliefert hat.
der initiale prompt mit den zugehörigen files und dem chatverlauf im 'LogEntry' mit den n letzten Datensätzen (n wird aus dem Config file aus der variablen Application.MAX_HISTORY gelesen) wird in ein 'message'-objekt als dictionary transformiert, welches so aussieht:
    message = {
        "role": "user", #--> statisch, immer so
        "content": [ #--> liste der Files
            {
                "type": "text",
                "text": prompt_text
            },
            {
                "type": content_type, # --> diese funktion integrieren wir später
                "source": {
                    "type": "base64",
                    "media_type": mime_type,
                    "data": base64_file # --> hier das dateiname der jeweiligen datei
                }
            },
			{
                "type": "text",
                "text": LogEntries # --> hier die LogEinträge als Textpaket
			}
        ]
    }
wenn der AI moderator der Meinung ist, dass die aufgabe erfüllt ist, beendet er den workflow.


3. initialisierungsset: beantwortet Anfragen direkt mit dem hinterlegten KI Modell, welche keine spezialisierten Agenten benötigen. Dies ist die Generierung von Text, Code, Strukturen, die Analyse von Files, Graphiken erstellen, etc.
(Agent) Organisator: Dieser analysiert den User Prompt und strukturiert die auszuführenden Aufräge sowie die nötigen zu liefernden Resultate
(Agent) Entwickler: Dieser entwickelt python code im Auftrag der anderen Agents und führt ihn anschliessend aus
(Agent) Webscrape: Ein Agent, welcher webscraping durchführt. Dieser nutzt die Funktion '_scrape_url', um eine Webseite zu scannen und den Inhalt zurückzugeben. Er kann auch den Entwickler beauftragen, einen Code zu generieren, welcher die funktion _scrape_url mit einer logik (z.B. iterativ oder batch-mässig) ausführt
(Prompt): Kannst Du mir ein paar initiale Prompts für die folgenden Fragebereiche vorbereiten, welche ausgewählt werden können:
. Web Research
. Analyse
. Protokoll
. Design


4. Kannst Du bitte die fehlenden CRUD Methoden in den modulen "workspaces" und "prompts" ergänzen. Ich glaube, es fehlen Post und Delete.


5. Datenbank-Management verbessern: In den zwei Modulen "gateway_interface.py" und "lucydom_interface" finden keine Manipulationen oder Referenzierungen mit ID's statt. Die ID's für einen neuen Datensatz werden nur in "connector_....py" modulen vergeben. Jeder datensatz hat eine unique id. in den modulen "...interface.py" werden keine id's generiert. die abfrage für die id=1 wird ersetzt mit der funktion 'get_initial_id', welche weiter unten erklärt ist.
Dazu bitte die Module anpassen und in den Modulen "connector...py" eine system-tabelle ergänzen, welche sich merkt, welche ID der erste datensatz jeder tabelle hat, denn dieser ist der jeweilige system-datensatz. dann eine funktion 'get_initial_id' erfassen, welche in den  modulen Modulen "gateway_interface.py" und "lucydom_interface" aufgerufen werden kann, um die id des initialen datensatzes pro tabelle abzufragen.





der gateway funktioniert noch nicht ganz.
kannst mir bitte die module prüfen und besser stukturieren?

Diese anforderungen und das setting der dateien:

models.py: die datei umbenennen in "model_lucydom.py"
    - die class "User", "UserInDB", "Token" in der datei entfernen und in eine separate datei "model_gateway.py" auslagern.
    - alle datentypen-definitionen sind hier, abschliessend und unabhängig vom datenbanksystem.
    - alle ID's sind long-Zahlen, keine Texte
    - bei jeder class und bei jedem attribut einer class ein label ergänzen, was der name des attributes bzw. der class ist, wenn dies in einem formular abgefragt wird. das label soll einen defaultwert haben und pro sprache gesetzt werden können.
    - alle objekte mandantenfähig machen, d.h. bei jedem Objekt die Attribute "mandate_id" und "user_id" ergänzen. 

model_gateway.py:
    - alle datentypen-definitionen sind hier, abschliessend und unabhängig vom datenbanksystem.
    - alle ID's sind long-Zahlen, keine Texte
    - bei jeder class und bei jedem attribut einer class ein label ergänzen, was der name des attributes bzw. der class ist, wenn dies in einem formular abgefragt wird. das label soll einen defaultwert haben und pro sprache gesetzt werden können.
    - Die class "Mandate" mit den Attributen (id,name,language) ergänzen
    - Bei der class "User" die "id" und "mandate_id" und "language" ergänzen
    - alle objekte mandantenfähig machen, d.h. bei jedem Objekt die Attribute "mandate_id" und "user_id" ergänzen. 

database.py aufteilen in 2 files "connector_db_json.py" und "interface_lucydom.py".

connector_db_json.py: Ein erster Konnektor von zukünftig weiteren Konnektoren
    1. Parameter, welche übergeben werden:
        - DB_Folder, DB_USER und DB_APIKEY
        - Kontextparamter für "mandate_id" und "user_id", welche nicht null sein dürfen.
        - Die aktuelle JSON-Datenbank im Folder DB_Folder einbinden und so übernehmen, wie sie ist. Falls der Folder fehlt, diesen erstellen.
    2. Der Konnector "db" wird als Objekt zur verfügung gestellt.
    3. Es werden diese generischen Methoden im Objekt "db" zur Verfügung gestellt.  jede abfrage filtert automatisch die datensätze auf die Kontextparamter "mandate_id" und "user_id", sofern diese Parameter in einem Datensatz nicht null oder "" sind.
        - get_tables(optional filterkriterien): liste aller tabellen
        - get_fields(table, optional filterkriterien): liste aller attribute einer tabelle
        - get_schema(table, language, optional filterkriterien): objekt aller attribute einer tabelle mit ihrem Datentyp und dem Label in der entsprechenden Sprache. Ohne Sprache Angabe wird der Default Wert als Label genommen
        - get_recordset(table, optional filterkriterien für fields, optional filterkriterien für records): liefert das entsprechende datenobjekt mit den Datensätzen
        - record_create(table,json with attributes): ergänzt einen Datensatz im Kontext "mandate_id", alle attribute, welche nicht im "json with attributes" drin sind, werden auf die standardwerte gemäss dem models.py gesetzt
        - record_delete: löscht einen Datensatz, aber nur wenn es im Kontext "mandate_id" ist, sonst Verweigerung "Not your mandate"
        - record_modify: ändert einen Datensatz, aber nur wenn er im Kontext "mandate_id" ist, sonst Verweigerung "Not your mandate"

interface_lucydom.py: Ein Interface zum Gateway, es werden weitere Interfaces folgen. Das Interface macht dies:
    1. Die Datenbank mit diesen Parametern einbinden:
        - Connector "connector_db_json.py"
        - Datenbank "/data_lucydom"
        - Datenmodell "model_lucydom.py"
    2. Das Objekt "db" kann nun genutzt werden
    3. initialisierung der Datenbank, falls sie nicht existiert, aber nur die minimal nötigen Objekte: Der "Default Workspace" in "workspaces"

interface_gateway.py: Ein Interface zum Gateway, es werden weitere Interfaces folgen. Das Interface macht dies:
    1. Die Datenbank mit diesen Parametern einbinden:
        - Connector "connector_db_json.py"
        - Datenbank "/data_gateway"
        - Datenmodell "model_gateway.py"
    2. Das Objekt "db" kann nun genutzt werden
    3. initialisierung der Datenbank, falls sie nicht existiert, aber nur die minimal nötigen Objekte: User "Admin", Mandate "Root"

app.py: Die Initialisierung klar strukturieren und die Endpunkte gemäss der neuen Struktur anpassen
    1. Teil: Interfaces einbinden.
    2. Alle nötigen Initialisierungen: diese sollen in den jeweiligen Interfaces drin sein, ausser die generischen Teile.
    3. Alle Access & Security Funktionen auslagern in "auth.py"
    4. Alle Token-Endpunkte komplett generisch halten und vereinfachen:
        - Dort keine Attributdefinitionen oder Feld-Listen reinnehmen. Wenn ein Modell angepasst wird, sollen hier keine Anpassungen nötig sein.
        - Die Abfragen und  exceptions mit Hilfsfunktionen vereinfachen, sodass die Modellierung der Endpunkte für den Programmierer sehr einfach, übersichtlich und klar ist.
        - Tasks als Kommentare erfassen, was mit all diesen Aenderungen der Endpunkte im Frontend umgebaut werden muss.


agent_service.py: Umbenennen in "interface_agentservice.py"
- Bei allen Workflow-Endpunkten, welche nur von einem Interface Logik beziehen, die Logik im Interface integrieren und den Code beim Endpunkt vereinfachen.
- Nur bei Endpunkten, welche Logik kombiniert von mehreren Interfaces benötigen, die Logik beim Endpunkt integrieren
- Ziel soll es sein, dass die Endpunkte-Codestruktur maximal schlank und übersichtlich ist, also auch die Strukturierung und Gruppierung der Endpunkte


