164 lines
7.7 KiB
Markdown
164 lines
7.7 KiB
Markdown
# 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.
|
|
|
|
```toml
|
|
[[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
|
|
|
|
```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:
|
|
|
|
```toml
|
|
# 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](linux-deployment.md) 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.
|