ankn/Orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Migrate all repos into monorepo context folders

Browse Source 
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
      Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
      Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)

Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
This commit is contained in:
ankn
2026-06-30 20:39:52 +02:00
parent 2f2b295531
commit a5f8fb49ab
1717 changed files with 447332 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
bahn/teamlandkarte-mcp/.kiro/specs/llm-competence-inference/bugfix.md
+31
View File
@@ -0,0 +1,31 @@
# Bugfix Requirements Document
## Einleitung
Die Kompetenz-Inferenz im Tool `validate_task_requirements` (sowie in `extract_requirements` und `find_matching_tasks`) funktioniert nicht mehr. Der frühere Embedding-basierte Ansatz (`infer_competences`, `ensure_task_embedding`) wurde im Rahmen der Umstellung auf BM25+LLM entfernt, ohne dass ein Ersatz implementiert wurde. Die Variable `inferred_comps` ist daher immer eine leere Liste `[]`.
Es soll ein LLM-basierter Ansatz implementiert werden, der aus allen verfügbaren Kompetenzen (via `get_all_competence_names()`) bis zu 10 passende Kompetenzen für einen gegebenen Task-Text auswählt – analog zum bereits funktionierenden LLM-basierten `infer_primary_role`.
## Bug-Analyse
### Aktuelles Verhalten (Defekt)
1.1 WHEN `validate_task_requirements(task_id)` aufgerufen wird THEN liefert das System immer eine leere Kompetenz-Tabelle, da `inferred_comps` stets `[]` ist
1.2 WHEN `extract_requirements(task_description)` aufgerufen wird THEN enthält das Ergebnis keine inferierten Kompetenzen (`inferred_competences` ist immer `[]`)
1.3 WHEN `find_matching_tasks(capacity_id)` intern Kompetenzen inferieren soll THEN werden stattdessen nur die DB-Skills verwendet, da die Kompetenz-Inferenz deaktiviert ist
### Erwartetes Verhalten (Korrekt)
2.1 WHEN `validate_task_requirements(task_id)` aufgerufen wird THEN SHALL das System per LLM-Aufruf bis zu 10 passende Kompetenzen aus der vollständigen Kompetenzliste (`get_all_competence_names()`) inferieren und mit Konfidenzwerten in der Tabelle anzeigen
2.2 WHEN `extract_requirements(task_description)` aufgerufen wird THEN SHALL das System per LLM-Aufruf bis zu 10 passende Kompetenzen inferieren und diese in den `requirements.competences` aufnehmen
2.3 WHEN `find_matching_tasks(capacity_id)` intern Kompetenzen inferiert THEN SHALL das System per LLM-Aufruf bis zu 10 passende Kompetenzen inferieren und diese für das Scoring verwenden
2.4 WHEN der Task-Text leer ist oder keine Kompetenzen in der DB vorhanden sind THEN SHALL das System eine leere Kompetenzliste zurückgeben, ohne einen Fehler zu werfen
2.5 WHEN der LLM-Aufruf fehlschlägt (Timeout, API-Fehler) THEN SHALL das System eine leere Kompetenzliste zurückgeben und den Fehler loggen, ohne den gesamten Tool-Aufruf abzubrechen
### Unverändertes Verhalten (Regressionsprävention)
3.1 WHEN `validate_task_requirements(task_id)` aufgerufen wird THEN SHALL das System WEITERHIN die Rollen-Inferenz per LLM korrekt durchführen
3.2 WHEN `validate_task_requirements(task_id)` aufgerufen wird THEN SHALL das System WEITERHIN die DB-Skills des Tasks korrekt anzeigen
3.3 WHEN `find_matching_capacities(task_id)` aufgerufen wird THEN SHALL das System WEITERHIN das bestehende LLM-Fulltext-Matching unverändert verwenden
3.4 WHEN der LLM-Aufruf für Rollen-Inferenz fehlschlägt THEN SHALL das System WEITERHIN `None` zurückgeben ohne Absturz
3.5 WHEN `infer_primary_role` aufgerufen wird THEN SHALL das System WEITERHIN genau eine Rolle aus der Rollenliste auswählen