Projekt und Recherchezugriffe konfigurieren

Die Projektkonfiguration wird über Dateien verwaltet, nicht über die Webseite. Sie legt fest, welche Werkzeuge ein Auftrag verwenden darf. Ein aufrufendes Programm kann weder Repository noch DB-Zugänge oder Budgets mit einem Auftrag überschreiben. Aktuell ist das Profil wow/vcore mit dem Importadapter vcore implementiert; andere Projekttypen erfordern entsprechende Adapter und Profile.

Zuordnung in api.toml

Ein Projektelement ordnet eine feste Projekt-ID einem Profil und dessen Konfigurationsdateien zu. Relative Pfade beziehen sich auf die API-Konfigurationsdatei. Der Erfassungsworker muss genau dieselbe Projekt-/Profilzuordnung senden und sein Integrationsschlüssel muss für das Projekt freigegeben sein.

[[projects]]
id = "viano-core"
type = "wow"
profile = "vcore"
adapter = "vcore"
planning_mode = "joint"
[projects.settings]
project_config = "project.toml"
llm_config = "llm.toml"
investigation_config = "investigation.bounded.toml"
budget_config = "budget.human-tests.toml"

Die Linux-Vorlagen stehen unter deploy/linux/; der Installer legt die Konfiguration unter /etc/viano-bug-analysis an. Er überschreibt bestehende Dateien nicht. Die ausführliche Vcore-Projektvorlage steht unter config/project.example.toml, die Relationsregeln unter config/project-relations.vcore.toml.

Source und Datenbank in project.toml

relations_file = "project-relations.vcore.toml"
[project]
type = "wow"
profile = "vcore"

[source]
path = "/srv/viano-bug-analysis/viano-core"
url = "https://gitea.viano-software.de/Nico/Viano-Core"
commit = "VOLLSTAENDIGEN_40_STELLIGEN_COMMIT_EINTRAGEN"

[database]
host = "127.0.0.1"
port = 3306
database = "cata_world"
user = "viano_reader"
password_env = "VIANO_DB_PASSWORD"
snapshot_id = "KENNUNG_DER_TATSAECHLICHEN_DATENGRUNDLAGE"
tables = ["creature_template", "creature"]

Das Beispiel zeigt nur den Aufbau und enthält absichtlich ungültige Platzhalter. Die beiden Tabellen sind keine vollständige Vcore-Freigabeliste. Für das echte Profil die vollständige Vorlage einschließlich Limits, Enrichment und Analysewerkzeugregeln verwenden und passend prüfen.

Der Source-Checkout muss lokal vorhanden sein und den konfigurierten Commit enthalten. Die URL allein klont oder aktualisiert kein Repository. Der Worker liest Git-Objekte dieses festen Stands und benötigt keine Schreibrechte auf den Checkout. Die Linux-Vorlage enthält eine gezielte Git-Vertrauenskonfiguration für den root-eigenen Checkout. Neue Source-Stände bewusst bereitstellen und deren vollständigen Commit konfigurieren.

Der DB-Administrator legt einen Benutzer mit ausschließlich passenden SELECT- Rechten an. Zusätzlich begrenzt tables die zugänglichen Tabellen. Diese Freigabeliste ersetzt keine serverseitigen Rechte. Account- oder Charakterdaten gehören nicht zur standardmäßigen World-Recherche. Für entfernte DBs einen geschützten Netzwerkweg nutzen; der aktuelle Provider konfiguriert selbst kein TLS.

Das Passwort steht entweder in der durch password_env benannten Umgebungsvariable oder einer separaten geschützten Datei über password_file. Nur eine dieser Varianten setzen. Unter Linux lädt der Worker beispielsweise VIANO_DB_PASSWORD aus seiner root-geschützten worker.env. Passwörter nicht in Fallakten, LLM-Prompts oder Versionsverwaltung ablegen. Die LLM bekommt Werkzeugergebnisse statt Zugangsdaten.

Mehrere Datenbanken pro Projekt

Eine Projektverbindung kann mehrere Datenbanken derselben MariaDB-Instanz ansprechen. Host, Port, DB-Benutzer und Passwortbezug werden gemeinsam verwendet. database benennt die Standarddatenbank; unqualifizierte Tabellennamen beziehen sich ausschließlich auf diese. Zusätzliche Datenbanken werden ausdrücklich freigegeben, etwa für Vcore:

# Im vorhandenen [database]-Abschnitt: database = "cata_world", user = "buganalysis"
[database.additional_databases]
cata_hotfixes = ["*"]
cata_locale = ["*"]

Den neuen Abschnitt beispielsweise am Ende der vorhandenen Datei ergänzen. [database] nicht ein zweites Mal anlegen und die übrigen Projektregeln behalten. Die vollständige alternative Vorlage steht unter config/project.vcore-multidb.example.toml.

["*"] gibt ausdrücklich alle metadaten-sichtbaren Tabellen der genannten DB frei. Alternativ eine nichtleere Liste konkreter Tabellen verwenden. Auch die Standarddatenbank unterstützt tables = ["*"]; die bisherige konkrete Liste bleibt genauso gültig. Ein leeres Array ist keine pauschale Freigabe. Die tatsächlich gewährten DB-Rechte bleiben zusätzlich maßgeblich. Nicht aufgeführte Datenbanken sind selbst bei weitergehenden DB-Grants gesperrt. In diesem Beispiel sind cata_auth, cata_characters und cata_locale_reference nicht für Recherche freigegeben.

Werkzeuge verwenden in zusätzlichen DBs qualifizierte Tabellennamen wie cata_locale.NAME_DER_TABELLE. database.tables entdeckt die zugänglichen Namen über alle freigegebenen DBs; Suchtext und Seitengrenzen gelten weiterhin. Gleichnamige Tabellen werden nicht verwechselt. Die Datenbank steht in der Belegherkunft und bei Mehrdatenbank-Ergebnissen auch in den Ergebniseinträgen. Die LLM erhält keine Serveradresse, Anmeldenamen oder Passwörter.

Namenskataloge, Enrichment-Regeln und Beziehungsprofile können ebenfalls qualifizierte Tabellen referenzieren. Die Beziehungsanalyse führt die konfigurierten Schritte innerhalb einer gemeinsamen lesenden Transaktion aus; sie prüft die Transaktionsfähigkeit der beteiligten Tabellen. Dieses Format konfiguriert keine unterschiedlichen DB-Server oder getrennten Zugangsdaten innerhalb derselben Projektverbindung.

Die Bereitschaftsprüfung prüft alle freigegebenen Tabellen einschließlich Wildcard-Inventaren. Eine nicht erreichbare oder nicht lesbare zusätzliche DB wird nicht stillschweigend ausgelassen. Bestehende Einzel-DB-Konfigurationen benötigen keine Änderung. Bei aktiven Fallakten trotzdem die bestehende Konfigurationsbindung beachten; ein Update setzt keine Budgets zurück.

Weitere Konfigurationen

Datei	Zuständigkeit
api.toml	HTTP-Bindung, Workspace, Projekte, Nutzerdatei und optionale env-basierte Maschinenclients
worker.toml	Verweis auf api.toml, Polling, Wiederholungsabstände, Speicherreserve und Telemetrie
llm.toml	Anbieter, Modell, Schlüssel-Environment, Timeouts, Ausgabe-/Denkeinstellungen und Cache
investigation.bounded.toml	Untersuchungsmodus und begrenztes Kontextfenster
budget.human-tests.toml	Fachliche Budgetregeln und menschliche Testanfragen
telemetry.toml	Heartbeats und lokale Betriebsbeobachtung
project-relations.vcore.toml	Projektspezifische Beziehungen für Recherchewerkzeuge

Die versionierte Modellvorlage config/llm.gemini-cache.example.toml verwendet GEMINI_API_KEY. Das ist unabhängig vom Integrationsschlüssel für externe Auftragsübergaben. Die API erhält api.env; der Analyseworker erhält worker.env mit Cloud- und DB-Zugangsdaten.

Prüfen und ändern

Der Befehl python -m viano_bug_analysis.deployment check prüft mit Rolle und Konfigurationspfad die Betriebsbereitschaft ohne Modellanfrage. Die Linux-Anleitung zeigt die vollständigen Befehle unter der tatsächlichen Dienstidentität. Die Prüfung umfasst Git-Objekte und freigegebene DB-Schemata; die Gültigkeit des Cloud-Schlüssels wird nicht durch einen bezahlten Modellaufruf getestet. --offline prüft keine Git-/DB-Verbindung.

Vor Code- oder Profiländerungen den Worker kontrolliert anhalten und die Auswirkungen auf laufende Akten prüfen. Der Worker bindet Fälle an ihren Konfigurationsstand. Eine Änderung ist kein Weg zum Zurücksetzen von Budgets; abweichende Bindungen können eine Betreiberprüfung erfordern. Bestehende Dateien und Zugangsdaten vor Änderungen sichern.

7.7 KiB Raw Blame History