Brainstorm & Evaluation · 0001 · 2026-05-18

LSP-Integration für Claude Code — go/no-go-Bewertung

Heute navigiert Claude durch den SOLCOM-Code hauptsächlich via grep und Glob-Patterns. Der offizielle Claude-Code-Blog empfiehlt das Einbinden von Language-Server-Protocol-Servern für Symbol-Navigation in großen, mehrsprachigen Codebasen. Dieses Dokument bewertet, ob das im SOLCOM-Setup (5 Custom-Module, 80+ SDC-Komponenten, 2-Personen-Team) sinnvoll ist — ohne etwas zu installieren oder zu konfigurieren.

1 — Problem-Statement: Was kostet grep?

Das aktuelle Suchmuster ist deterministisch, aber unscharf. Wenn Claude in einem Refactor-Lauf alle Stellen sucht, an denen getProjectList() aufgerufen wird, findet grep auch gleichnamige Methoden in unverwandten Modulen und Twig-Helpers. In einem Drupal-Projekt potenzieren sich diese False Positives schnell: Hook-Funktionen folgen der Naming-Konvention hook_entity_type_alter(), viele Module implementieren denselben Hook, und grep kann ohne Typ-Kontext nicht unterscheiden, welche Implementierung gemeint ist.

Konkret betroffen sind drei Kategorien von Sub-Agent-Aufgaben:

Cross-Module-Refactoring: Ein Reviewer-Agent, der prüft, ob ein geänderter Hook-Aufruf rückwärtskompatibel ist, muss heute alle Module manuell durchsuchen. Mit LSP reicht ein findReferences-Aufruf.
Twig-Include-Ketten: SDC-Komponenten inkludieren sich gegenseitig über @byte_theme/components/…-Pfade. grep auf Pfad-Strings ist fragil, sobald Pfade umbenannt werden. Ein Twig-LSP mit goToDefinition-Support würde diese Kette in einem Schritt auflösen.
Drupal-Service-Container: Services werden per YAML-Key registriert und per String-ID aufgerufen. Heute findet Claude diese Verbindung nur heuristisch über Pattern-Matching. Ein PHP-LSP würde die Klassen-Instanz über den Service-Container korrekt auflösen — theoretisch; in der Praxis ist Drupal-DI für generische LSPs nicht trivial.

Wichtige Einschränkung: Der MCP-Server drupal-solcom deckt bereits einen großen Teil der Drupal-spezifischen Inspektion ab — Entity-CRUD, Canvas-Trees, Config-Read, Vacancy-Inspect. LSP würde den Code-Symbol-Layer ergänzen, nicht die Drupal-Domain-Schicht ersetzen oder duplizieren.

2 — Kandidaten-Stack

Vier Sprach-Layer sind im SOLCOM-Stack relevant: PHP (Hauptsurface), Twig (Templates), CSS/Tailwind (Theming), JavaScript/TypeScript (Drupal Behaviors). Für jeden Layer gibt es mindestens einen LSP-Kandidaten.

Kandidat	Layer	Lizenz	Maintenance	macOS-Install	RAM-Schätzung
Intelephense	PHP	Freemium (Premium ~15 USD/Jahr)	Aktiv (Ben Mewburn)	`npm i -g intelephense`	~200–350 MB
Phpactor	PHP	Open Source (MIT)	Aktiv, aber schwächerer Auto-Complete	`composer global require phpactor/phpactor`	~80–120 MB
PHPStan-LS	PHP (statische Analyse)	Open Source	Experimentell, kein stabiler LSP-Mode	über composer, kein Standard-LSP-Binary	hoch (analysiert bei Start)
Psalm-LS	PHP (statische Analyse)	Open Source (MIT)	Stabiler als PHPStan-LS, aber kein Hover/Go-to in allen Clients	`composer require --dev vimeo/psalm`	~150 MB
twig-language-server (Tobias Wiens)	Twig	Open Source (MIT)	Letzte Aktivität 2024; kein Drupal-Namespace-Support	`npm i -g @nicklockwood/…` (oder Upstream)	~30–60 MB
Symfony VS-Code-Extension	Twig (Symfony)	Open Source	Auf Symfony-Twig optimiert, kein `@byte_theme/…`-Namespace	via Extension-Host, kein Standalone-LSP	~60 MB
Tailwind CSS IntelliSense (LSP-Mode)	CSS/Tailwind	Open Source (MIT)	Aktiv (Tailwind Labs)	`npm i -g @tailwindcss/language-server`	~40–80 MB
tsserver (TypeScript Language Server)	JS/TS	Open Source (Apache 2.0)	Aktiv (Microsoft)	`npm i -g typescript` (enthalten)	~100–200 MB

Für PHP sticht die Entscheidung zwischen Intelephense und Phpactor heraus. Intelephense hat deutlich besseren Drupal-Support (Namespace-Auflösung, Hook-Erkennung über Contrib-Stubs), kostet aber eine Lizenz für den vollen Feature-Satz. Phpactor ist vollständig open-source, aber bei Drupal-spezifischen Patterns (Services, Routes, Hooks) wesentlich schwächer.

3 — Claude-Code-Integration-Pfad

Claude Code stellt ein natives LSP-Tool bereit (verfügbar als deferred tool im laufenden Session-Kontext). Die unterstützten Operationen sind: goToDefinition, findReferences, hover, documentSymbol, workspaceSymbol, goToImplementation, prepareCallHierarchy, incomingCalls, outgoingCalls.

Das Tool selbst erfordert keine separate MCP-Konfiguration — es ist Teil von Claude Code. Der entscheidende Satz aus der Tool-Dokumentation: „LSP servers must be configured for the file type. If no server is available, an error will be returned." Das bedeutet: Claude Code kann LSP-Calls absetzen, sobald ein laufender LSP-Server am erwarteten Socket hängt. Die Konfiguration geschieht über die Claude-Code-Settings, nicht über DDEV oder Drupal selbst.

Schritt	Aufwand	Einmalig / Wiederkehrend
PHP-LSP-Server installieren (z. B. Intelephense via npm)	~5 Minuten	Einmalig pro Entwickler-Mac
Pfad in Claude-Code-Settings eintragen	~10 Minuten (inkl. Test)	Einmalig, per Dev-Docs dokumentierbar
Onboarding für zweiten Entwickler	~15 Minuten mit Doku	Einmalig
RAM-Overhead im Dauerbetrieb (Intelephense)	~200–350 MB dauernd	Wiederkehrend — relevant auf 16-GB-Macs
Drupal-Stubs aktuell halten (bei Core-Update)	~5–10 Minuten	Wiederkehrend (selten, bei Major-Updates)

Für Twig und JavaScript ist der Aufwand geringer, der Nutzen aber auch deutlich kleiner. Twig-LSPs haben keinen stabilen Drupal-Namespace-Support, sodass @byte_theme/components/icon/icon.twig-Auflösungen wahrscheinlich leer zurückkämen. tsserver würde JavaScript-Behaviors abdecken, ist aber bereits sehr gut via Glob-Search navigierbar, weil Drupal Behaviors einem klaren Strukturmuster folgen.

4 — Go/No-Go-Empfehlung

Pro-Argumente:

Symbol-Navigation wird deterministisch statt heuristisch — insbesondere bei Hook-Namen, die in mehreren Modulen kollisionsträchtig sind.
Das Claude-Code-LSP-Tool ist bereits eingebaut; es ist kein zusätzlicher MCP-Server nötig. Aufwand liegt vollständig auf der Konfigurationsseite.
Cross-Module-Refactoring-Reviews (z. B. der drupal-php-reviewer-Agent) würden von findReferences + incomingCalls messbar profitieren.
Intelephense hat spezifische Drupal-Stub-Unterstützung — das ist keine generische PHP-LSP-Story, sondern passt den Stack.

Contra-Argumente:

Für ein 2-Personen-Team ist der grep-basierte Workflow heute „good enough"; die Fehlerquote durch False Positives ist gering, weil der Codebase-Umfang noch überschaubar ist.
Der MCP-Server drupal-solcom deckt den Drupal-Domänen-Layer (Entities, Config, Canvas, Vacancies) bereits sehr gut ab. LSP würde nur den Code-Symbol-Layer ergänzen — ein Layer, der selten der Bottleneck ist.
Twig-LSP hat keinen stabilen Drupal-Namespace-Support (Stand 2025/2026) — der zweitgrößte Nutzwert (Twig-Include-Auflösung) bliebe vorerst ungeklärt.
Der RAM-Overhead von ~200–350 MB für Intelephense ist auf einem 16-GB-Entwickler-Mac spürbar, wenn DDEV + Browser + andere Tools gleichzeitig laufen.
Bis zum Go-Live-Termin 2026-07-08 sind die verbleibenden F-Stories primär Canvas-Content und Frontend-Parity — kein massives Refactoring-Volumen, das LSP sofort rechtfertigt.

Entscheidungs-Vorschlag Deferred — Q4 2026

Deferred — re-evaluate Q4 2026. Das stärkste Argument dagegen ist der Timing-Mismatch: Die verbleibenden MVP-Stories (Go-Live 08.07.2026) sind Content- und Parity-getrieben, nicht Refactoring-getrieben. LSP-Nutzen entfaltet sich vor allem bei größerem Cross-Module-Refactoring-Volumen — das kommt post-MVP in Phase 2. Der Aufwand (Install, Konfig, Onboarding, RAM) übersteigt den aktuellen Nutzen. Q4 2026 ist der richtige Zeitpunkt: dann ist Phase 2 aktiv, der Codebase wächst weiter, und Intelephense-Premium lohnt sich bei mehreren Entwicklern.

Falls doch go: Erster Pilot wäre Intelephense (PHP) — größter Nutzen pro Installationsaufwand dank Drupal-Stubs und dem bereits eingebauten Claude-Code-LSP-Tool. Kein Custom-MCP nötig.