3.9 KiB
Mehrere Recherche-Datenbanken pro Projekt – 2026-10-24
Ausbau des SQL-Providers um ausdrücklich konfigurierte zusätzliche Datenbanken
derselben MariaDB-Verbindung. Standarddatenbank und alte Einzel-DB-Konfigurationen
bleiben gültig. Zusätzliche Tabellen verwenden datenbank.tabelle; es gibt keine
automatische Suche nach gleichnamigen Tabellen in anderen DBs.
[database.additional_databases] unterstützt konkrete Tabellenlisten oder
ausdrücklich ["*"] für metadaten-sichtbare Tabellen einer benannten DB.
Die Standardliste tables unterstützt dieselbe ausdrückliche Wildcard.
Keine implizite Freigabe anderer DBs, keine beliebigen SQL-Befehle, keine
Schreiboperationen. Separate Server/Zugänge innerhalb einer Projektverbindung
sind nicht Bestandteil dieses Formats.
Angepasst: SQL-Auflösung und Metadaten-Caches, Werkzeug-/Capture-/Zustandsschemata, Belegherkunft, DB-Beziehungsanalyse über mehrere Schemas in einer lesenden Repeatable-Read-Transaktion, Entity-Namenskataloge, Enrichment-Tabellenvergleiche, Toolhinweise und vollständige Bereitschaftsprüfung. Vcore-Mehrdatenbankvorlage, README, Projektanleitung und gebündelte Webanleitung aktualisiert.
Erfolgreiche lokale Prüfungen
python -m pytest tests/test_multidatabase_research.py tests/test_context_expansion.py tests/test_entity_resolution.py tests/test_database_fact_grounding.py tests/test_deployment.py tests/test_user_manual.py -q
84 passed, 1 dependency deprecation warning
Davon 14 Mehrdatenbank-Testfälle einschließlich parametrisierter Ablehnungen. Reale SQL-Selektion über getrennte SQLite-Attach-Schemas; MariaDB-Metadaten und Transaktionsbefehle werden im Adapter simuliert. Geprüft: identische Tabellennamen mit verschiedenen Daten, korrekte Schema-/Belegzuordnung, Abweisung nicht freigegebener Schemas vor Verbindungsaufbau, Wildcard-Entdeckung und Pagination, keine Auth-/Charakter-/Locale-Reference-Freigabe, gemeinsame Beziehungstransaktion, Entity-/Enrichment-Regeln, vollständige Paket-/Evidence-Validierung, Mehrdatenbank-Startprüfung mit fehlender DB und vollständige Vcore-Vorlage. Keine Secrets oder Host-/Benutzerdaten im Provider-Binding.
Bekannte Fehler und Gegenprobe
Zusätzlicher Lauf über Mehrdatenbank-, Relations-, ProjectResearch-, Deployment-
und Manual-Tests vor dem letzten Vorlagentest: 73 bestanden, 1 übersprungen,
5 fehlgeschlagen. Dieselben fünf Tests scheitern auch am unveränderten HEAD
9408af5 (52 bestanden, 1 übersprungen). Die Gegenprobe nutzte eine temporäre
separate Baseline-Sourcekopie; Arbeitsdateien wurden nicht zurückgesetzt.
- test_database_relations.py::test_hybrid_loop_uses_relations_with_fixture_llm_and_can_resume
- test_project_research.py::test_model_loop_uses_project_tools_and_compact_previous_result[True]
- test_project_research.py::test_model_loop_uses_project_tools_and_compact_previous_result[unknown]
- test_project_research.py::test_model_loop_uses_project_tools_and_compact_previous_result[upgrade]
- test_project_research.py::test_started_project_loop_keeps_legacy_prompt_protocol
Diese Alt-Schleifenprüfungen bleiben offen. Die harte Promptgrenze wurde nicht gelockert; es wurden keine Budgets zurückgesetzt oder Tests zum Bestehen verändert.
Messumfang und Grenzen
Alle Modellantworten in lokalen Workflow-Fixtures sind Testdoubles; keine echten LLM-Anfragen. Keine Cloudkosten oder neuen Token-/Cache-Abrechnungsmetriken. Keine Verbindung zum VPS, keine Änderungen an echten DBs, kein Dienststart. Echte MariaDB-Verbindungen und Serverrechte werden nach dem Update mit der Bereitschaftsprüfung auf dem Zielserver kontrolliert.
Vor Testbeginn Trials 16.939.129.428 Bytes, Fehlerkorpus 2.471.041 Bytes und kleine
pytest-Temporärdaten. Nur kleine Source-/SQL-/Case-Fixtures; das 20-GB-Budget bleibt
eingehalten. Temporäre Baseline-Kopie nach Gegenprobe entfernt. Keine vollständigen
LLM-Testarchive angelegt. docs/architecture.md unverändert, kein Push.