211 lines
16 KiB
Text
211 lines
16 KiB
Text
....................... TASKS
|
|
|
|
|
|
|
|
kannst du die ausführungsprotokollierung anpassen? das protokoll soll laufend anzeigen, welcher assistent welches resultat produziert hat und welcher assistent aktuell am arbeiten ist. Prozentzahlen sind keine nötig, diese machen keinen sinn. das polling so beibehalten, aber wenn keine neuen Daten bereitstelen, dann beim letzten Timestamp einfach laufend "." ergänzen, bis die nächste Meldung ausgegeben wird. hast du alle daten, um dies im frontend und im backend anzupassen?
|
|
|
|
Im Ausführungsprotokoll pro Eintrag nur den Titel zeigen und die Details zwar ins Protokoll nehmen, aber ausblenden. Der Benutzer kann dann im Protokoll die zugeklappten Texte aufklappen, um die gewünschten Details gezielt zu sehen.
|
|
|
|
Im Front-End beim Workflow-Modul bitte das Ausführungsprotokoll-Fenster dynamisch in der Grösse anpassbar machen. in der Breite und der Höhe. Dasselbe für das Ergebnis-Fenster. Zudem die Ansicht so gestalten, dass die Fensterteile "Workflow-Konfiguration" und "Ausführung & Ergebnisse" ein- und ausgeblendet werden können, damit jeweils ein Teil die komplette Arbeitsfläche verwenden kann, weil dort viel Text stehen wird. Dies ist für den Benutzer besser.
|
|
|
|
|
|
|
|
----------------------- OPEN
|
|
|
|
TOKENS!!! - Bei Folgeanfragen immer nur den letzten Input mitnehmen oder anders optimieren. AI fragen...
|
|
|
|
Erweiterete Parameter aus config.ini einbinden in die Module
|
|
|
|
Chat mit Instant message - auch inputs geben während der ausführung
|
|
|
|
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.
|
|
|
|
----------------------- DONE
|
|
|
|
nun zu diesem zentralen modul. ich hätte gern, dass die daten als tabellen dargestellt und bearbeitet werden können. für view, add, modify, delete jeweils icon pro datensatz ganz links und zuoberst im header ein "new item" symbol oder text, mach einen vorschlag.
|
|
|
|
ist es möglich, eine checkbox pro datensatz zu machen, um mehrere elemente auszuwählen und oben an der tabelle icons zu haben für mehrfach delete?
|
|
|
|
die tabelle soll nach allen feldern gefiltert und sortiert werden können
|
|
|
|
kannst du bitte den code so anpassen, dass main.js die seitenmodule im Anhang dynamisch erst dann lädt, wenn die entsprechende seite in der navigation aufgerufen wird?
|
|
|
|
dann bitte main.js modularisieren, sodass dort nur funktionsaufrufe auf sub-module ausgeführt werden. das navigationsmenu nach "navigation.js" auslagern. den aufbau und betrieb des aktuellen workspaces im main.js drin lassen.
|
|
|
|
Der aktuelle Hauptbereich mitt der Auswahl des workspaces, den zugehörigen Agenten etc ist neu ein Objekt, welches in der "mainView" dargestellt werden kann. Auch andere Objekte können in der mainView dargestellt werden und haben jeweils ihre spezifischen Paramter dazu, wie nachfolgend erklärt.
|
|
|
|
im main.js wird ein globales objekt aller elemente erstellt, welche in der navigation enthalten sein sollen und welches die grundlage für alle funktonsaufrufe beinhaltet. damit gibt es dann im index.html keine details mehr zu den navigationen.
|
|
|
|
|
|
diese attribute hat das globale objekt:
|
|
|
|
globalState
|
|
.objects
|
|
.user
|
|
.mainView
|
|
|
|
Hier die Spezifikation der Objekte.
|
|
|
|
.objects[...]: hat eine liste von objekten, welche im mainScreen geladen werden können. Diese Attribute pro Objekt bitte gemäss den heutigen js files im anhang sinngemäss übernehmen:
|
|
- label: Liste des Labelnamen in den verschiedenen sprachen (default, en, fr...)
|
|
- modulName: string; dieser wird verwendet für die objektklasse "js/modules/{modulname}.js" und für die html-komponente dazu "modules/part-{modulname}.html und für die calls ans backend /api/{modulname}/..."
|
|
- icon: Icon vor dem Menupunkt
|
|
- navigationContext: "left" für agents, data, prompts, users, mandates, workspaces ; "top" für sprachauswahl, logout
|
|
- isVisible (hier wird z.b. users und mandates nur angezeigt, wenn auch die berechtigung dafür besteht)
|
|
- isActive: Wenn der Menupunkt ausgewählt ist
|
|
- navigationContext: diese Optionen, wo ein Objekt ins Menu genommen wird:
|
|
--"nav_left" für agents, data, prompts, users, mandates, workspaces
|
|
--"nav_top" für sprachauswahl, logout
|
|
- navigationActionType: Was passiert, wenn auf das Menu geklickt wird. Diese Optionen:
|
|
--"module": Standard-Menu button. Es wird ein Modul in die mainView geladen. Das Modul wird erst geladen und mit den Daten initiiert, wenn der Menupunkt ausgewählt wird
|
|
--"group_open": Gruppenheader; Start einer neuen Gruppe; alle nachfolgenden Objekte der Liste sind in dieser Gruppe integriert. Die Gruppe kann im Menu auf- und zugeklappt werden. Initial Gruppe open, alle Menupunkte sichtbar
|
|
--"group_collapsed": Gruppenheader; Start einer neuen Gruppe; alle nachfolgenden Objekte der Liste sind in dieser Gruppe integriert. Die Gruppe kann im Menu auf- und zugeklappt werden. Initial Gruppe collapsed.
|
|
|
|
.user: Attribute zum aktiven user
|
|
- mandate_id
|
|
- user_id
|
|
- username
|
|
- full_name
|
|
- language (default, en, fr, ...)
|
|
- isAdmin
|
|
- isSysAdmin
|
|
- lastWorkspaceId: Id des zuletzt genutzten Workspaces - aktuell "null"
|
|
- session: aktuell null und nicht verwendet
|
|
|
|
.mainView: enthält immer die aktuellen Attribute, welche die Seite in der mainView nutzen kann
|
|
- currentWorkspace: objekt des aktuell ausgewählten Workspaces
|
|
- availableFiles[]: list of objects
|
|
- availableAgents[]: list of objects
|
|
- availablePrompts[]: list of objects
|
|
- currentWorkflowId: id
|
|
|
|
|
|
kannst du bitte part-workflow.html und workflow.js mit dem dynamischen Multi-Agent Chat aktualisieren, welcher im backend angepasst wurde 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
|
|
|
|
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
|
|
|
|
|