Orchestrator/bahn/teamlandkarte-mcp/.kiro/specs/llm-fulltext-matching/requirements.md

Anforderungsdokument

Einleitung

Dieses Dokument beschreibt die Anforderungen für die Einführung eines zweiten Matching-Verfahrens in der Teamlandkarte: einen LLM-basierten Volltext-Vergleich zwischen Aufgaben und Kapazitäten. Das bestehende Score-basierte Verfahren (Rolle + Kompetenzen, BM25/RRF + LLM-Rollen-Similarity) bleibt unverändert verfügbar. Der Nutzer wählt pro Suche das Verfahren aus.

Das neue Verfahren bezieht zusätzliche Felder aus der Datenbank ein (Beschreibung, Referenzen, Zertifikate auf Kapazitätsseite; Titel, Beschreibung und gesuchte Kompetenzen auf Aufgabenseite), berechnet kein numerisches Scoring mehr und ordnet jede Kapazität bzw. Aufgabe direkt einer der bestehenden Kategorien zu. Zusätzlich liefert das LLM für jeden Fall eine Kurzbegründung (1–2 Sätze).

Glossar

• MCP_Server: Der Teamlandkarte MCP-Server (Modul mcp_server.py), der die MCP-Tools für Matching, Suche und Datenanzeige bereitstellt.
• DBClient: Protokollklasse aus database/types.py, die alle Datenbankzugriffe abstrahiert.
• TrinoClient: Konkrete DBClient-Implementierung (database/trino_client.py) für Trino/Presto.
• Matcher: Bestehende, Score-basierte Matching-Komponente in matching/matcher.py.
• LLM_Fulltext_Matcher: Neues Modul, das den LLM-basierten Volltext-Vergleich durchführt und Kategorien direkt zuweist.
• AzureOpenAIClient: Wrapper für Azure-OpenAI-Chat-Completions in azure/openai_client.py.
• LLM: Large Language Model (Azure OpenAI Chat Completion).
• Capacity: Frozen Dataclass Capacity in models.py (Kapazitätseintrag eines Mitarbeitenden).
• Task: Frozen Dataclass Task in models.py (veröffentlichte Aufgabe).
• Capacity_Profile: Aggregiertes Volltext-Profil einer Kapazität, bestehend aus Rolle, Kompetenzen, Beschreibung, Referenzen und Zertifikaten.
• Task_Profile: Aggregiertes Volltext-Profil einer Aufgabe, bestehend aus Titel, Beschreibung und gesuchten Kompetenzen.
• Matching_Method: Auswahlwert für das verwendete Verfahren. Erlaubte Werte: score (bisheriges Score-basiertes Matching) und llm_fulltext (neues LLM-Volltext-Matching).
• Kategorie: Eine der bestehenden Ergebniskategorien Top, Good, Partial, Low, Irrelevant.
• Rationale: Vom LLM erzeugte Kurzbegründung (1–2 Sätze) für die zugewiesene Kategorie.
• find_matching_capacities: MCP-Tool für die Suchrichtung Aufgabe→Kapazität.
• find_matching_tasks: MCP-Tool für die Suchrichtung Kapazität→Aufgabe.
• Teamlandkarte_Agent: GitHub-Copilot-Agent in .github/agents/teamlandkarte_agent.md (sowie das Pendant in .kiro/agents/teamlandkarte.md) inklusive seiner Skills/Workflows.
• Architecture_Doc: docs/architecture.md.
• Readme: README.md im Repository-Root.
• Capacity_Description: Inhalt der Spalte description in teamlandkarte_v_capacities_latest.
• Capacity_Certificate: Eintrag aus teamlandkarte_v_capacity_certificates_latest (Feld description, Join via capacity_id, 1:n).
• Capacity_Reference: Eintrag aus teamlandkarte_v_capacity_references_latest (Spalte projects, Join via capacity_id, 1:n) inklusive des zugehörigen Partner_Name aus teamlandkarte_v_partners_latest.
• Partner: Eintrag aus teamlandkarte_v_partners_latest. Eine Capacity_Reference verweist über die Spalte partner_id auf einen Partner; die Verknüpfung erfolgt über teamlandkarte_v_capacity_references_latest.partner_id = teamlandkarte_v_partners_latest.id.
• Partner_Name: Wert der Spalte name aus teamlandkarte_v_partners_latest, der einer Capacity_Reference über partner_id zugeordnet ist. Ist partner_id NULL oder existiert kein passender Partner, gilt der Partner_Name als leere Zeichenkette.

Anforderungen

Anforderung 1: Auswahl des Matching-Verfahrens

User Story: Als Nutzer möchte ich pro Suchanfrage zwischen dem bisherigen Score-basierten Matching und dem neuen LLM-basierten Volltext-Matching wählen können, damit ich je nach Situation das passende Verfahren einsetzen kann.

Akzeptanzkriterien

1. THE MCP_Server SHALL akzeptieren einen Parameter matching_method mit den erlaubten Werten score und llm_fulltext in den Tools find_matching_capacities und find_matching_tasks.
2. WHEN matching_method nicht übergeben wird, THE MCP_Server SHALL den Standardwert score verwenden, sodass das bestehende Verhalten unverändert bleibt.
3. WHEN matching_method = "score" übergeben wird, THE MCP_Server SHALL das bestehende Score-basierte Matching ausführen.
4. WHEN matching_method = "llm_fulltext" übergeben wird, THE MCP_Server SHALL das neue LLM-basierte Volltext-Matching über den LLM_Fulltext_Matcher ausführen.
5. IF ein ungültiger Wert für matching_method übergeben wird, THEN THE MCP_Server SHALL eine Fehlermeldung zurückgeben, die die erlaubten Werte (score, llm_fulltext) auflistet, und die Suche nicht ausführen.
6. THE MCP_Server SHALL den verwendeten Wert von matching_method im Antwort-META-JSON sowie in der angezeigten Suchkonfiguration ausweisen.

Anforderung 2: Erweiterte Datenabfrage für Kapazitäten

User Story: Als Entwickler möchte ich, dass für das LLM-Volltext-Matching die Kapazitäts-Beschreibung, alle Zertifikate und alle Referenzen aus der Datenbank verfügbar sind, damit das LLM ein vollständiges Profil bewerten kann.

Akzeptanzkriterien

1. THE DBClient SHALL eine Methode bereitstellen, die für eine gegebene capacity_id die Capacity_Description aus teamlandkarte_v_capacities_latest (Spalte description) zurückgibt.
2. THE DBClient SHALL eine Methode bereitstellen, die für eine gegebene capacity_id alle zugeordneten Capacity_Certificate-Beschreibungen aus teamlandkarte_v_capacity_certificates_latest (Feld description, Join über capacity_id) als Liste von Strings zurückgibt.
3. THE DBClient SHALL eine Methode bereitstellen, die für eine gegebene capacity_id alle zugeordneten Capacity_Reference-Einträge aus teamlandkarte_v_capacity_references_latest (Spalte projects, Join über capacity_id) inklusive des zugehörigen Partner_Name aus teamlandkarte_v_partners_latest (Join teamlandkarte_v_capacity_references_latest.partner_id = teamlandkarte_v_partners_latest.id, Spalte name) als Liste strukturierter Einträge mit den Feldern projects und partner_name zurückgibt.
4. WHEN ein LLM-Volltext-Matching für mehrere Kapazitäten ausgeführt wird, THE DBClient SHALL eine Batch-Variante bereitstellen, die Beschreibungen, Zertifikate und Referenzen (inklusive Partner_Name über den Join auf teamlandkarte_v_partners_latest) für eine Liste von capacity_id-Werten in höchstens drei SQL-Abfragen lädt (eine pro Quelle); der Partner-Join SHALL Bestandteil derselben Referenz-Abfrage sein und keine zusätzliche SQL-Abfrage erzeugen.
5. WHEN für eine Kapazität keine Beschreibung in der Datenbank vorhanden ist (NULL oder leer), THE DBClient SHALL für die Capacity_Description den Wert None zurückgeben.
6. WHEN für eine Kapazität keine Zertifikate vorhanden sind, THE DBClient SHALL eine leere Liste für Capacity_Certificate zurückgeben.
7. WHEN für eine Kapazität keine Referenzen vorhanden sind, THE DBClient SHALL eine leere Liste für Capacity_Reference zurückgeben.
8. IF die partner_id einer Capacity_Reference NULL ist oder der Join auf teamlandkarte_v_partners_latest keinen Treffer liefert, THEN THE DBClient SHALL den Partner_Name dieser Capacity_Reference als leere Zeichenkette zurückgeben und die Referenz dennoch mit dem Feld projects in der Ergebnisliste belassen.
9. THE TrinoClient SHALL alle neuen SQL-Abfragen ausschließlich als SELECT-Statements ausführen und die bestehende Read-Only-Guard _ensure_select_only verwenden.
10. THE TrinoClient SHALL die neuen Abfragen über die bestehende Connection-Pool-Infrastruktur und die Retry-Logik (_retry) ausführen.

Anforderung 3: Aufbau des Capacity_Profile

User Story: Als Entwickler möchte ich, dass das System aus den Datenbankfeldern ein konsistentes Volltext-Profil pro Kapazität erzeugt, damit das LLM eine einheitliche Eingabe erhält.

Akzeptanzkriterien

1. THE LLM_Fulltext_Matcher SHALL pro Kapazität ein Capacity_Profile bilden, das die folgenden Felder enthält: id, owner_name, role_name, competences, description, references und certificates.
2. THE LLM_Fulltext_Matcher SHALL jedes Element der Liste references im Capacity_Profile als strukturierten Eintrag mit den Feldern partner_name und projects führen, sodass beide Bestandteile einer Capacity_Reference erhalten bleiben.
3. WHEN ein Feld in der Datenbank leer oder None ist, THE LLM_Fulltext_Matcher SHALL das entsprechende Feld im Capacity_Profile mit einer leeren Zeichenkette bzw. einer leeren Liste belegen, ohne das gesamte Profil zu verwerfen.
4. WHEN der Partner_Name einer Capacity_Reference leer ist, THE LLM_Fulltext_Matcher SHALL die Referenz dennoch in references aufnehmen und ausschließlich das Feld projects in die serialisierte Darstellung übernehmen, ohne einen Platzhaltertext für den Partner einzufügen.
5. THE LLM_Fulltext_Matcher SHALL das Capacity_Profile in einer für das LLM lesbaren, deterministischen Textstruktur serialisieren, in der jedes Feld klar mit einer Überschrift gekennzeichnet ist (z. B. Rolle:, Kompetenzen:, Beschreibung:, Referenzen:, Zertifikate:).
6. THE LLM_Fulltext_Matcher SHALL jeden Eintrag im Abschnitt Referenzen: so darstellen, dass sowohl Partner_Name als auch Projekte für das LLM sichtbar sind (z. B. im Format Partner: <partner_name> – Projekte: <projects> oder als gleichwertige strukturierte Darstellung mit benannten Feldern).
7. THE LLM_Fulltext_Matcher SHALL die Reihenfolge der Felder in der serialisierten Darstellung über alle Kapazitäten konstant halten, sodass die LLM-Eingabe deterministisch ist.

Anforderung 4: Aufbau des Task_Profile

User Story: Als Entwickler möchte ich, dass das System aus den Datenbankfeldern ein konsistentes Volltext-Profil pro Aufgabe erzeugt, damit das LLM eine einheitliche Eingabe erhält.

Akzeptanzkriterien

1. THE LLM_Fulltext_Matcher SHALL pro Aufgabe ein Task_Profile bilden, das die folgenden Felder enthält: id, title, description und skills (gesuchte Kompetenzen).
2. WHEN ein Feld in der Datenbank leer oder None ist, THE LLM_Fulltext_Matcher SHALL das entsprechende Feld im Task_Profile mit einer leeren Zeichenkette bzw. einer leeren Liste belegen.
3. THE LLM_Fulltext_Matcher SHALL das Task_Profile in einer für das LLM lesbaren, deterministischen Textstruktur serialisieren, in der jedes Feld klar mit einer Überschrift gekennzeichnet ist (z. B. Titel:, Beschreibung:, Gesuchte Kompetenzen:).
4. THE LLM_Fulltext_Matcher SHALL die Reihenfolge der Felder in der serialisierten Darstellung über alle Aufgaben konstant halten.

Anforderung 5: LLM-Volltext-Matching für die Richtung Aufgabe→Kapazität

User Story: Als Nutzer möchte ich, dass find_matching_capacities mit matching_method = "llm_fulltext" einen LLM-basierten Volltext-Vergleich zwischen einem Task_Profile und allen Capacity_Profile-Einträgen durchführt, damit ich Kapazitäten über die rein lexikalische Kompetenzbetrachtung hinaus bewerten lassen kann.

Akzeptanzkriterien

1. WHEN find_matching_capacities mit matching_method = "llm_fulltext" aufgerufen wird, THE LLM_Fulltext_Matcher SHALL für jede gefilterte Kapazität (gleicher Vorfilter wie beim Score-Matching, z. B. Verfügbarkeitsfilter) einen LLM-Vergleich zwischen Task_Profile und Capacity_Profile durchführen.
2. WHEN find_matching_capacities mit matching_method = "llm_fulltext" aufgerufen wird, THE MCP_Server SHALL als Eingabe das aktuell bestätigte Anforderungs-Set (role_name, competences, optionale Beschreibung, Zeitraum) sowie ggf. die zugrunde liegende Aufgabe verwenden, um das Task_Profile zu bilden.
3. THE LLM_Fulltext_Matcher SHALL pro Kapazität genau eine Kategorie aus der Menge Top, Good, Partial, Low, Irrelevant zurückgeben.
4. THE LLM_Fulltext_Matcher SHALL pro Kapazität eine Rationale mit 1 bis 2 Sätzen zurückgeben, die die Zuweisung in die jeweilige Kategorie erläutert.
5. THE LLM_Fulltext_Matcher SHALL die LLM-Antwort als strukturiertes JSON pro Kapazität anfordern und parsen (Felder: category, rationale).
6. IF das LLM für eine Kapazität eine Kategorie zurückgibt, die nicht in der erlaubten Menge liegt, THEN THE LLM_Fulltext_Matcher SHALL diese Kapazität der Kategorie Irrelevant zuordnen und die Rationale durch einen Hinweis auf die ungültige LLM-Antwort ergänzen.
7. IF der LLM-Aufruf für eine Kapazität fehlschlägt, THEN THE LLM_Fulltext_Matcher SHALL diese Kapazität in einer separaten Fehlerliste ausweisen und sie nicht als reguläres Ergebnis kategorisieren.
8. THE LLM_Fulltext_Matcher SHALL die Ergebnisse nach Kategorie gruppieren und innerhalb jeder Kategorie eine deterministische Sortierreihenfolge anwenden (Sortierung primär nach Kategorie, sekundär nach capacity_id aufsteigend).

Anforderung 6: LLM-Volltext-Matching für die Richtung Kapazität→Aufgabe

User Story: Als Nutzer möchte ich, dass find_matching_tasks mit matching_method = "llm_fulltext" einen LLM-basierten Volltext-Vergleich zwischen einem Capacity_Profile und allen Task_Profile-Einträgen durchführt, damit ich auch in dieser Suchrichtung das neue Verfahren nutzen kann.

Akzeptanzkriterien

1. WHEN find_matching_tasks mit matching_method = "llm_fulltext" aufgerufen wird, THE LLM_Fulltext_Matcher SHALL für jede offene Aufgabe einen LLM-Vergleich zwischen Capacity_Profile und Task_Profile durchführen.
2. WHEN find_matching_tasks mit matching_method = "llm_fulltext" aufgerufen wird, THE MCP_Server SHALL für die angegebene capacity_id Beschreibung, Zertifikate und Referenzen aus der Datenbank laden und in das Capacity_Profile einbeziehen.
3. THE LLM_Fulltext_Matcher SHALL pro Aufgabe genau eine Kategorie aus der Menge Top, Good, Partial, Low, Irrelevant zurückgeben.
4. THE LLM_Fulltext_Matcher SHALL pro Aufgabe eine Rationale mit 1 bis 2 Sätzen zurückgeben.
5. THE LLM_Fulltext_Matcher SHALL die LLM-Antwort als strukturiertes JSON pro Aufgabe anfordern und parsen (Felder: category, rationale).
6. IF das LLM für eine Aufgabe eine Kategorie zurückgibt, die nicht in der erlaubten Menge liegt, THEN THE LLM_Fulltext_Matcher SHALL diese Aufgabe der Kategorie Irrelevant zuordnen und die Rationale durch einen Hinweis auf die ungültige LLM-Antwort ergänzen.
7. IF der LLM-Aufruf für eine Aufgabe fehlschlägt, THEN THE LLM_Fulltext_Matcher SHALL diese Aufgabe in einer separaten Fehlerliste ausweisen und sie nicht als reguläres Ergebnis kategorisieren.
8. THE LLM_Fulltext_Matcher SHALL die Ergebnisse nach Kategorie gruppieren und innerhalb jeder Kategorie eine deterministische Sortierreihenfolge anwenden (Sortierung primär nach Kategorie, sekundär nach task_id aufsteigend).

Anforderung 7: Direkte Kategorisierung ohne mathematisches Scoring

User Story: Als Nutzer möchte ich beim LLM-Volltext-Matching keine numerischen Score-Spalten mehr sehen, sondern ausschließlich die vom LLM zugewiesene Kategorie, damit das neue Verfahren als rein qualitative Bewertung erkennbar ist.

Akzeptanzkriterien

1. WHEN matching_method = "llm_fulltext" verwendet wird, THE MCP_Server SHALL in den Ergebnistabellen keine Spalten Role Score, Competence Score oder Overall Score ausgeben.
2. WHEN matching_method = "llm_fulltext" verwendet wird, THE MCP_Server SHALL für jeden Treffer ausschließlich die LLM-zugewiesene Kategorie als Bewertungsfeld ausweisen.
3. WHEN matching_method = "score" verwendet wird, THE MCP_Server SHALL die bestehenden Score-Spalten unverändert ausgeben.
4. THE LLM_Fulltext_Matcher SHALL für jedes Ergebnis ein Datenfeld category (String) und ein Datenfeld rationale (String) im gespeicherten Suchergebnis (SearchCache) hinterlegen, ohne numerische Scores zu schreiben.
5. THE MCP_Server SHALL die Summary-Tabelle im LLM-Volltext-Modus weiterhin als Zähler je Kategorie (Top, Good, Partial, Low, Irrelevant) ausgeben.

Anforderung 8: Begründungsspalte (Rationale) in der Ausgabe

User Story: Als Nutzer möchte ich in der Ergebnistabelle des LLM-Volltext-Matchings eine zusätzliche Spalte sehen, die in 1–2 Sätzen erläutert, warum eine Kapazität bzw. Aufgabe in der jeweiligen Kategorie gelandet ist, damit ich die Entscheidung des LLM nachvollziehen kann.

Akzeptanzkriterien

1. WHEN matching_method = "llm_fulltext" verwendet wird, THE MCP_Server SHALL die Ergebnistabellen für find_matching_capacities und find_matching_tasks um eine Spalte Begründung (Rationale) erweitern.
2. THE MCP_Server SHALL die Spalte Begründung direkt rechts neben der Spalte Category einfügen.
3. THE MCP_Server SHALL pro Zeile genau die vom LLM zurückgegebene Rationale (1–2 Sätze) anzeigen.
4. WHEN die Rationale Zeilenumbrüche oder Pipe-Zeichen enthält, THE MCP_Server SHALL diese so escapen oder ersetzen, dass die Markdown-Tabelle gültig bleibt.
5. WHEN die Rationale länger als 280 Zeichen ist, THE MCP_Server SHALL die Rationale auf 280 Zeichen kürzen und ein abschließendes Auslassungszeichen (…) anhängen, damit die Tabellendarstellung lesbar bleibt.
6. THE MCP_Server SHALL die ungekürzte Rationale im persistierten Suchergebnis (SearchCache) speichern, sodass nachgelagerte Tools (get_results_by_category, filter_search_results) den vollständigen Text ausgeben können.

Anforderung 9: Kompatibilität mit Refinement- und Pagination-Tools

User Story: Als Nutzer möchte ich auch beim LLM-Volltext-Matching durch Kategorien blättern und Filter anwenden können, damit der bestehende Such-Workflow konsistent bleibt.

Akzeptanzkriterien

1. WHEN matching_method = "llm_fulltext" verwendet wird, THE MCP_Server SHALL ein gültiges search_id zurückgeben, das mit get_results_by_category und filter_search_results verwendet werden kann.
2. WHEN get_results_by_category ein Suchergebnis aus dem LLM-Volltext-Modus paginiert, THE MCP_Server SHALL die Ergebnistabelle ohne Score-Spalten und mit der Spalte Begründung ausgeben.
3. WHEN filter_search_results ein Suchergebnis aus dem LLM-Volltext-Modus filtert, THE MCP_Server SHALL die Filterung ausschließlich auf nicht-Score-basierten Filtern (Rollenfilter, Kompetenzfilter, Verfügbarkeitsfilter, Aufgaben-Textfilter, Aufgaben-Kompetenzfilter) durchführen.
4. IF ein Score-bezogener Filter (z. B. min_similarity) auf ein LLM-Volltext-Suchergebnis angewendet wird, THEN THE MCP_Server SHALL den Filter ignorieren und in der Applied Filters-Tabelle einen Hinweis aufnehmen, dass der Filter im LLM-Volltext-Modus nicht wirksam ist.
5. THE MCP_Server SHALL im META-JSON des Suchergebnisses das verwendete Verfahren als matching_method ausweisen, damit Folgewerkzeuge das Schema korrekt interpretieren können.

Anforderung 10: Anpassung der Copilot-Agent-Konfiguration

User Story: Als Nutzer möchte ich, dass sowohl der GitHub-Copilot-Agent teamlandkarte_agent als auch der Kiro-Pendant-Agent das neue Matching-Verfahren kennen und mich aktiv nach dem gewünschten Verfahren fragen, damit das neue Feature über die Agenten nutzbar ist.

Akzeptanzkriterien

1. THE Teamlandkarte_Agent SHALL in seiner Konfigurationsdatei (.github/agents/teamlandkarte_agent.md) und im Pendant .kiro/agents/teamlandkarte.md die Existenz und den Zweck der beiden Verfahren score und llm_fulltext dokumentieren.
2. WHEN der Nutzer eine Suche nach passenden Kapazitäten oder Aufgaben startet, THE Teamlandkarte_Agent SHALL den Nutzer explizit nach dem gewünschten matching_method (Score-basiert oder LLM-Volltext) fragen, sofern dieses nicht bereits aus dem Verlauf hervorgeht.
3. THE Teamlandkarte_Agent SHALL die Skills/Workflows so erweitern, dass find_matching_capacities und find_matching_tasks mit dem zusätzlichen Parameter matching_method aufgerufen werden.
4. THE Teamlandkarte_Agent SHALL die Rolle der Spalte Begründung im Output dokumentieren und in den Hinweisen erwähnen, dass im LLM-Volltext-Modus keine numerischen Scores erscheinen.
5. THE Teamlandkarte_Agent SHALL den bestehenden Bestätigungs-Workflow (show_pending_requirements, confirm_requirements) beibehalten und für beide Verfahren gleich anwenden.

Anforderung 11: Aktualisierung von Architektur- und README-Dokumentation

User Story: Als Entwickler oder Onboardee möchte ich, dass architecture.md und README.md das neue Matching-Verfahren beschreiben, damit ich Architektur und Nutzung des Systems korrekt verstehe.

Akzeptanzkriterien

1. THE Architecture_Doc SHALL einen Abschnitt enthalten, der den LLM_Fulltext_Matcher als Komponente innerhalb der Business-Logic-Layer beschreibt, einschließlich seiner Eingaben, Ausgaben und externen Abhängigkeiten (Azure OpenAI Chat Completion).
2. THE Architecture_Doc SHALL die zusätzlichen Datenquellen (teamlandkarte_v_capacities_latest.description, teamlandkarte_v_capacity_certificates_latest, teamlandkarte_v_capacity_references_latest, teamlandkarte_v_partners_latest) im Datenmodell- und Schema-Verifikationsabschnitt aufführen.
3. THE Architecture_Doc SHALL die Verknüpfung zwischen teamlandkarte_v_capacity_references_latest.partner_id und teamlandkarte_v_partners_latest.id sowie die Übernahme der Spalte name als Partner_Name in das Capacity_Profile dokumentieren.
4. THE Architecture_Doc SHALL den neuen Parameter matching_method und seine Wertebereiche im Tool-Surface-Abschnitt für find_matching_capacities und find_matching_tasks dokumentieren.
5. THE Architecture_Doc SHALL den Runtime-View für beide Suchrichtungen um den LLM-Volltext-Pfad ergänzen.
6. THE Readme SHALL im Quick-Start- und Usage-Abschnitt erklären, wie der Nutzer zwischen score und llm_fulltext wählt.
7. THE Readme SHALL beschreiben, dass im LLM-Volltext-Modus keine numerischen Scores ausgegeben werden und stattdessen eine Spalte Begründung erscheint.
8. THE Readme SHALL die zusätzlichen Datenbank-Views aufführen, die der Server im LLM-Volltext-Modus liest, einschließlich teamlandkarte_v_partners_latest und der Verknüpfung zu Capacity_Reference über partner_id.

Anforderung 12: Anpassung weiterer Skripte und Tools

User Story: Als Entwickler möchte ich, dass alle relevanten Hilfsskripte und MCP-Tools mit dem neuen Verfahren konsistent zusammenarbeiten, damit es keine Inkonsistenzen zwischen Server, Agent und Skripten gibt.

Akzeptanzkriterien

1. THE MCP_Server SHALL den Parameter matching_method in allen Docstrings der betroffenen Tools (find_matching_capacities, find_matching_tasks, ggf. filter_search_results, get_results_by_category) dokumentieren.
2. THE MCP_Server SHALL die Konfigurationsdatei config.toml um einen optionalen Schlüssel matching.default_method erweitern, der den Standardwert für matching_method beim Server-Start festlegt.
3. WHEN matching.default_method in config.toml nicht gesetzt ist, THE MCP_Server SHALL den Default-Wert score verwenden.
4. IF matching.default_method einen anderen Wert als score oder llm_fulltext enthält, THEN THE MCP_Server SHALL beim Start einen ConfigError mit beschreibender Meldung werfen.
5. THE MCP_Server SHALL alle bestehenden Tests so erweitern oder ergänzen, dass sowohl der Modus score als auch der Modus llm_fulltext (mit gemocktem LLM) abgedeckt sind.