Pyrus AI Ecosystem — MCP-Infrastruktur

Dieses Repository ist die Implementierungs- und Governance-Heimat für den Pyrus MCP-Infrastrukturdienst und sein unterstützendes KI-Engineering-Team. Es enthält auch die architektonische Spezifikation und Roadmap für das zukünftige Knowledge MCP, das ein separater Dienst mit eigenem Datenspeicher und Lebenszyklus ist.

Produktgrenzen

AI clients / employees
        |
        +---------------------+
        |                     |
        v                     v
   Pyrus MCP             Knowledge MCP
   Pyrus actions         canonical knowledge
        |                     |
        v                     v
     Pyrus API          PostgreSQL/pgvector
        ^                     ^
        |                     |
        +------- PyrusBot ----+
             orchestration

Pyrus MCP

Ein produktionsreifer externer Dienst, der autorisierten Mitarbeitern/KI-Hosts ermöglicht, Pyrus-Operationen über MCP durchzuführen. Er ist unabhängig bereitstellbar und darf nicht von einer Entwickler-Workstation abhängen.

Knowledge MCP

Ein separater MCP-Dienst für kanonische versionierte Dokumentation, Nachweise/Abstammung, semantische Einbettungen, Hybridabruf und kontrollierte Veröffentlichung in der Pyrus-Wissensdatenbank über Pyrus MCP.

PyrusBot

Eine zukünftige Orchestrierungs-/Anwendungsschicht, die beide MCPs nutzt. Sie kann später zu einem Chat-Bot, CLI, Web-Dienstprogramm oder IDE-Adapter werden, ohne die Infrastrukturverträge zu ändern.

Related MCP server: MCP Gateway

Aktuelle Priorität

Pyrus MCP-Produktionsreife hat oberste Priorität. Knowledge MCP wird parallel spezifiziert, aber erst nach Genehmigung seiner Verträge implementiert. Die PyrusBot-Integration folgt nach stabilen Infrastrukturverträgen.

Normative Dokumente

• IMPLEMENTATION_PLAN.md — normativer Implementierungseinstiegspunkt.

• docs/architecture/system-architecture-v2.md — vollständige Systemarchitektur.

• docs/architecture/contracts-v2.md — MCP-, Pyrus-API-, Sicherheits-, Webhook- und Knowledge-Verträge.

• docs/planning/production-roadmap-v2.md — Phasen-Roadmap und Parallelisierungsregeln.

• tasks/registry.yaml — ausführbarer Aufgaben-Graph mit Besitzern, Reviewern, Toren und Abhängigkeiten.

• contracts/pyrus-tool-catalog.yaml — wiederherstellbarer Legacy-Kompatibilitätskatalog; derzeit blockiert, bis Legacy-Nachweise wiederhergestellt sind.

• docs/qa/gates.md — Merge-/Release-/Produktionsakzeptanztore.

• docs/ai-team/agent-registry.yaml — Engineering-Rollen und Befugnisse.

Kritische aktuelle Blocker

1. Der vorherige Plan verwies auf pyrus_mcp_tools_spec.json und inventory.json, aber diese Artefakte sind im aktuellen Repository nicht vorhanden. Der genaue Legacy-Vertrag muss wiederhergestellt werden, bevor eine 1:1-Parität erklärt werden kann.

2. Der sichtbare Plan sagt '61 Tools', aber die derzeit sichtbare gruppierte Liste stimmt nicht unabhängig mit dieser Zahl überein. Die genaue Legacy-Anzahl und -Namen sind daher eine P0-Vertragswiederherstellungsaufgabe.

3. Ein einzelnes SERVER_AUTH_TOKEN ist kein ausreichendes Multi-User-Produktionsautorisierungsmodell. Ziel ist MCP/OAuth-kompatible Bearer-Autorisierung, Zielgruppenvalidierung, Bereiche, Mandantenbindung, Widerruf und Prüfung.

4. SQLite ist eine lokale Entwicklungsoption, nicht das dauerhafte Produktions-System-of-Record.

Engineering-Stack

Pyrus MCP

Python 3.11+ Richtlinie; uv; FastMCP; Streamable HTTP; stdio für lokale Tests; Pydantic; httpx; pytest; Ruff; statische Typisierung; PostgreSQL; optionales Redis; Docker; GitHub Actions; externes Geheimnis-Management.

Knowledge MCP

Python + FastMCP; PostgreSQL + pgvector; Objektspeicher für große/rohe Artefakte; Embedding-Provider-Adapter mit Modell-/Versionsdatensätzen; Hintergrund-Indizierungs-/Embedding-Jobs; optionales Redis; die gleiche Produktionssicherheits- und Beobachtbarkeitsdisziplin.

Entwicklungsmodell

Jedes Implementierungselement hat einen primären Ausführenden, einen unabhängigen Reviewer und explizite Gate-Besitzer. Eine Aufgabe wird aufgeteilt, sobald sie mehr als ein unabhängig testbares Ergebnis enthält. Neue Entdeckungen erstellen verknüpfte Aufgaben, anstatt den Umfang stillschweigend zu erweitern.

Die Produktionsfreigabe ist durch Architektur-, Vertrags-, Sicherheits-, QA-, Persistenz-, Beobachtbarkeits-, Staging- und Release-Checks abgesichert.

Nützliche Befehle

node scripts/dashboard-server.mjs
# Open http://localhost:4748/

Das Dashboard ist eine Schnittstelle zur Aufgabenregistrierung; die Registrierung und die obigen Dokumente bleiben die Quelle der Wahrheit.