---
titel: "Stack und Fundament"
adresse: https://docs.anvil-coder.tech/docs/stack-und-fundament
beschreibung: "Wo du Sprache, Framework und Build-Werkzeug festlegst, woran du die Wahl erkennst, warum das Fundament zuerst kommt und welche Stacks am Ende gebaut und getestet werden."
sprache: de
---

Dokumentation · Konzepte

Wo du Sprache, Framework und Build-Werkzeug festlegst, woran du die Wahl erkennst, warum das Fundament zuerst kommt und welche Stacks am Ende gebaut und getestet werden.

Welche Sprache, welches Framework, welches Build-Werkzeug ein Projekt bekommt, legst **du** fest — in den Grundlagen des Projekts. Anvil Coder liest sie vor jedem Planen und baut genau das, was dort steht. Dieses Kapitel erklärt, wo du den Stack festlegst, was danach passiert und woran du siehst, was gewählt wurde.

## Wo du den Stack festlegst

Überall dort, wo du die Architektur deines Projekts beschreibst:

- im **Spec-Studio** im Architektur-Abschnitt und in den **Architektur-Entscheidungen (ADRs)** — zum Beispiel eine Entscheidung „Backend mit ASP.NET Core, Tests mit xUnit”;

- im Repository in `docs/architecture.md` und `docs/project.md`;

- in den Kapiteln unter `docs/spec/`, besonders in einem Kapitel zu Architektur oder Technologie.

Es genügt ein klarer Satz. Anvil Coder übernimmt nur, was die Dokumente **entscheiden** — es wählt keinen Stack auf eigene Faust. Schliessen die Dokumente etwas aus („kein PHP”), gilt das nicht als Wahl.

Legen die Dokumente nichts fest, baut Anvil Coder wie bisher eine **Java-Anwendung mit Spring Boot und Gradle**.

## Woran du siehst, was gewählt wurde

Im **Verlauf** des Tickets steht beim Planen eine Zeile wie

Stack: python / fastapi / uv — Kapitel 4 legt FastAPI als Web-Framework fest.

mit Sprache, Framework, Build-Werkzeug und dem Satz, in dem deine Dokumente das entscheiden. Neu gewählt wird nur, wenn sich die Dokumente ändern; solange sie gleich bleiben, bleibt auch der Stack — und es entstehen dafür keine weiteren Kosten.

## Das Fundament kommt zuerst

Bei einem neuen Projekt in einer anderen Sprache als Java oder Kotlin legt der erste Lauf das **Fundament** selbst an. Die ersten Aufgaben im Plan heissen „Foundation: …” und schreiben:

- die Build-Konfiguration des gewählten Werkzeugs im Hauptverzeichnis (etwa `pyproject.toml`, `package.json`, `go.mod` oder eine `.sln` mit ihren Projekten), mit fest angegebenen Versionen;

- die Verzeichnisstruktur, die deine Architektur vorgibt, und einen minimalen Einstiegspunkt;

- einen **Rauchtest**, der zeigt, dass die Anwendung lädt.

Sobald das Fundament geschrieben ist, **baut und testet Anvil Coder es sofort**. Ist der Build rot oder findet er keine Build-Konfiguration, werden die Fundament-Aufgaben mit dem Befund noch einmal erzeugt. Bleibt es auch nach den Reparaturrunden rot, endet der Lauf — statt Fachcode auf ein Fundament zu bauen, das nicht funktioniert.

Baut das Fundament, kommt es in den Default-Branch deines Repositorys — damit jeder weitere Lauf darauf aufsetzt:

- Steht die **Autonomie** des Projekts auf **Auto**, übernimmt Anvil Coder das Fundament sofort. Es überschreibt dabei nichts: Hat sich der Default-Branch seit dem Laufstart bewegt oder ist er geschützt, bleibt er, wie er ist.

- Sonst kommt das Fundament mit dem Pull Request des Laufs, den du wie gewohnt freigibst.

Im **Verlauf** des Tickets steht, welcher der beiden Wege genommen wurde.

**Keine fachliche Aufgabe beginnt, bevor das Fundament gebaut ist.** Das hängt nicht davon ab, ob das Modell die Reihenfolge richtig plant — Anvil Coder setzt sie nach dem Planen fest.

Bei Java und Kotlin legt Anvil Coder sein eigenes, erprobtes Gerüst an. Und ein Repository mit bestehendem Code bleibt, wie es ist: Dann gelten dessen Dateien und dessen Build.

## Wie am Ende gebaut und getestet wird

Zum Abschluss jedes Laufs baut und testet Anvil Coder das ganze Repository. Erkannt werden:

| Stack | Woran | Befehl |
| --- | --- | --- |
| Java/Kotlin mit Gradle | `build.gradle`, `settings.gradle` | `gradle build` |
| Java mit Maven | `pom.xml` | `mvn verify` |
| PHP | `composer.json` | Pest, sonst PHPUnit |
| Node.js/TypeScript | `package.json` | `npm test` |
| Go | `go.mod` | `go build` und `go test` |
| Python | `pyproject.toml`, `requirements.txt` | pytest in einer eigenen virtuellen Umgebung |
| .NET | `.sln`, `.csproj` | `dotnet test` (die Solution, sonst das Test-Projekt) |

Einen eigenen Build-Befehl kannst du je Projekt unter **Projekte → Build-Verifikation** eintragen; er geht der Erkennung vor.

## Wenn es nichts zu bauen gibt

Findet der Abschluss-Build keine Build-Konfiguration, ergänzt Anvil Coder bei Java-Projekten seine eigenen Build-Dateien und baut noch einmal. Bleibt es trotzdem ohne Build, endet der Lauf mit **Qualitätsschuld**: Im Lauf-Kopf steht in einem Satz, was los ist (die technischen Einzelheiten unter **Details**), der Pull Request bleibt ein Entwurf. Daneben stehen zwei Knöpfe:

- **Nur VERIFY neu bauen** baut und testet den Lauf noch einmal — ohne neue Planung und ohne neu erzeugten Code. Das ist der richtige Weg, wenn der Build und nicht der Code das Problem war, etwa weil du inzwischen unter **Projekte → Build-Verifikation** einen Build-Befehl eingetragen hast. Es kostet nur die Build-Zeit.

- **Nochmals bauen lassen** beginnt das Ticket von vorn — mit neuer Planung und aufgefrischten Build-Dateien.