Integrationen

Optionale Erweiterungen, die bewusst aktiviert werden.

Vue als Astro Island

Vue ist nicht vorinstalliert. Das ist keine Nachlässigkeit, sondern die Vorgabe: Die allermeisten Seiten eines Kundenprojekts brauchen kein Framework im Browser, und ein vorinstalliertes zieht Abhängigkeiten, Bündelgröße und Hydration-Entscheidungen in jedes Projekt, das es nie benutzt.

pnpm astro add vue

Danach features.vue: true in project.config.ts. Steht das Flag, ohne dass @astrojs/vue auflösbar ist, bricht der Build mit einem Hinweis ab — ein Flag, das ins Leere zeigt, wäre eine stumme Fehlfunktion.

Wann eine Insel gerechtfertigt ist

Die Frage ist nicht „wäre Vue hier bequemer", sondern „geht es ohne". Das Kontaktformular des Starters ist die Messlatte: mehrere Felder, Prüfung im Browser, Fehlerübersicht mit Fokusführung, Statusmeldung nach dem Absenden — und dafür reichen rund 200 Zeilen src/lib/forms/runtime.ts und kein Framework.

Gerechtfertigt ist eine Insel dort, wo der Zustand nicht mehr im DOM steht, sondern zwischen Schritten gehalten werden muss:

Fall	Warum eine Insel
Mehrstufiges Formular	Zustand über Schritte hinweg, Zurück-Navigation, Fortschrittsanzeige
Bedingte Felder in größerer Zahl	Sichtbarkeitsregeln, die als DOM-Manipulation unübersichtlich werden
Konfigurator mit Live-Berechnung	Abgeleitete Werte, die bei jeder Eingabe neu entstehen
Filter- und Sortieroberfläche	Viele voneinander abhängige Zustände auf derselben Liste

Nicht gerechtfertigt: ein Klappmenü (<details>), ein Tab-Wechsel, ein Formular mit festen Feldern, ein Zähler.

Die Hydration-Direktive

Sie wird begründet, nicht geraten:

• client:visible ist die Vorgabe für alles unterhalb der Falz. Eine Insel, die niemand zu Gesicht bekommt, lädt nie.
• client:idle für Inseln über der Falz, die nicht sofort bedienbar sein müssen.
• client:load nur, wenn die Insel unmittelbar nach dem Laden bedient wird — und mit einer Begründung im Pull Request.
• client:media für Inseln, die nur in einer Bildschirmgröße existieren.

Der Formularvertrag gilt auch dort

Eine Vue-Insel, die ein Formular absendet, benutzt submitForm() aus src/lib/forms/submit.ts wie jede andere Seite. Sie baut keinen eigenen Request und kennt den Provider nicht — sonst gälte der Providerwechsel für sie nicht mehr. Siehe Formulare.

WebMCP

Experimentell und standardmäßig deaktiviert (features.webMcp: false).

Die Idee: Eine Website stellt einem Assistenten im Browser Werkzeuge bereit — „welche Termine sind frei", „berechne den Preis für diese Konfiguration" —, statt dass er die Seite liest und rät. Der Standard ist jung, die Browserunterstützung ist es auch.

Was das Flag heute tut

Es setzt eine Logzeile beim Bauen. Sonst nichts.

Das ist Absicht und keine Lücke: Der Starter liefert keine Funktion aus, die es nicht gibt (Regel 7). Ein Flag, das eine Werkzeugbeschreibung ins HTML schreibt, ohne dass ein Werkzeug dahintersteht, wäre genau die Behauptung, die dieses Repository an jeder anderen Stelle vermeidet.

Deshalb fragt pnpm starter:init auch nicht danach. Eine Frage im Dialog würde eine Entscheidung suggerieren, die keine Folgen hat. Wer das Flag einschaltet, tut das von Hand, bewusst und mit dieser Seite daneben.

Die Erweiterungsstelle

Wer WebMCP in einem Projekt umsetzt, folgt dem Muster, das der Starter für Tracking benutzt (ADR 0008):

1. Zur Bauzeit entscheiden, was es gibt. Eine Funktion nach dem Vorbild von planTracking() leitet aus project.config.ts ab, welche Werkzeuge dieses Projekt anbietet. Keine Bedingung im Browser-Code — sonst ist sie nicht prüfbar.
2. Zur Laufzeit nur ausführen. Das Skript in der Seite registriert, was der Plan sagt.
3. Jedes Werkzeug hat eine sichtbare Entsprechung. Ein Werkzeug „Termin buchen" ohne Buchungsfunktion auf der Website ist dieselbe Art Behauptung wie ein JSON-LD-Knoten ohne Inhalt.
4. Ein Werkzeug, das Daten überträgt, braucht eine Einwilligung — mit einem Eintrag in consentConsumers(), damit der Dialog beschreiben kann, worum er bittet (Regel 10).
5. Ein Werkzeug, das etwas verändert, gehört nicht in eine statische Website. Der Starter liefert keinen Server aus; alles Schreibende läuft über den Formular-Handler und dessen Prüfreihenfolge.

Wann es sich lohnen wird

Sinnvoll wären Werkzeuge, die eine Frage beantworten, für die man sonst durch drei Seiten klickt: Öffnungszeiten samt Feiertagen, Verfügbarkeit einer Leistung an einem Standort, eine Preisberechnung mit wenigen Eingaben.

Nicht sinnvoll: eine Werkzeugbeschreibung für Inhalte, die ohnehin als Text auf der Seite stehen. Dafür gibt es strukturierte Daten, und die sind bereits eingerichtet.