constraint-driven-development (de)

Constraint-Driven Development

Übersicht

Andere Skills in diesem Set beschreiben, wie etwas gut aussieht. code-review-and-quality liefert dir fünf Achsen. test-driven-development liefert einen Kreislauf. security-and-hardening liefert eine Bedrohungsliste. Das alles existiert in Prosa, die der Agent liest und möglicherweise befolgt – oder nicht –, und nichts davon überlebt das Ende der Sitzung.

Dieser Skill produziert etwas anderes: eine schriftliche Aufzeichnung der Projekt-spezifischen Schwelle, mit Zahlen, die die Konversation überdauert und mechanisch überprüfbar ist.

Warum das wichtig ist: Wenn du den Code geschrieben hast, konntest du am Lesen erkennen, ob er gut war. Ein Agent schreibt an einem Nachmittag mehr, als du in einer Woche lesen wirst. Die Beurteilung wandert also aus deinem Kopf in Prüfungen, die im Kreislauf laufen. Diese Prüfungen müssen existieren, sie brauchen Zahlen, die du tatsächlich gewählt hast, und sie müssen nahe genug an der Arbeit feuern, dass der Agent seine eigene Ausgabe korrigiert.

Spezifikationsgesteuerte Entwicklung sagt, was gebaut werden soll. Testgetriebene Entwicklung beweist, dass es funktioniert. Constraint-Driven Development definiert, was „gut genug, um ausgeliefert zu werden“ bedeutet – bevor jemand im Pull-Request darüber diskutiert.

Einsatzbereiche

Wende diesen Skill an, wenn:

• Ein neues Projekt oder eine wichtige Funktion beginnt und noch keine Qualitätsschwelle schriftlich festgelegt ist.
• Der Nutzer bittet, „Einschränkungen festzulegen“ oder „Qualitätsgates hinzuzufügen“ oder „den Agenten daran zu hindern, Müll auszuliefern“.
• Ein Agent produziert Code in Mengen, die niemand Zeile für Zeile liest.
• CI hat Checks, aber niemand kann sagen, welche einen Merge blockieren und welche nur Dekoration sind.
• Über Abdeckungs-, Leistungs- oder Barrierefreiheitszahlen wird per PR diskutiert, statt einmalig entschieden.
• Du gleich /build auto oder eine andere autonome Schleife starten willst und das Einzige, was zwischen ihr und Main steht, eine Testsuite ist, die derselbe Agent geschrieben hat.

NICHT anwenden, wenn:

• Das Projekt bereits eine CONSTRAINTS.md hat und der Nutzer sie nicht ändert – lies sie und befolge sie stattdessen.
• Es sich um einmalige Skripte, Spikes oder Wegwerfprototypen handelt.
• Der Nutzer sofort ein Code-Review (code-review-and-quality) oder den Bau einer CI-Pipeline (ci-cd-and-automation) wünscht.
• Code vor dem Product-Market-Fit mit einer erwarteten Lebensdauer von zwei Wochen – der Boden darunter lohnt sich trotzdem, der Rest nicht.

Constraints laden

Das Interview braucht einen Live-Nutzer. Führe es nicht in nicht-interaktiven Kontexten aus (CI, /loop, autonome Läufe). Fehlen Constraints und du befindest dich in einem solchen Kontext, wende den folgenden Boden an, vermerke dies und flagge den Rest für einen Menschen.

Der Prozess

Schritt 1: Erkennen, bevor du fragst

Frage nie, was du lesen kannst. Sammle vor der ersten Frage:

Was	Wo nachsehen
Sprache und Stack	package.json, pyproject.toml, go.mod, Cargo.toml
Test-Runner	dev-Abhängigkeiten, test-Skript, vorhandene Testdateien
Vorhandene Linters	eslint.config.*, biome.json, .ruff.toml
Aktuelle Abdeckung	coverage/-Ausgabe oder einmal Suite ausführen
CI	.github/workflows/, .gitlab-ci.yml
Agentenkonfiguration	.claude/, .codex/, AGENTS.md

Berichte in zwei Zeilen, was du gefunden hast, und frage dann nur noch, was übrig ist.

Schritt 2: Vier Fragen, jede mit einem Standardwert

Befolge die Ein-Frage-pro-Mal-Disziplin von interview-me, mit einer Änderung: Jede Frage hat hier einen Standardwert, sodass „Ich weiß nicht“ eine vollständige Antwort ist, die dennoch eine funktionierende Konfiguration produziert.

F1: Welche dieser Dimensionen sollen über den Boden hinaus durchgesetzt werden?
    (a) Testabdeckung auf neuem Code
    (b) Sicherheits-Scanning
    (c) Performance-Budgets
    (d) Barrierefreiheit
    (e) Architektur-Grenzen
SCHÄTZUNG: (a) und (b) – du hast bereits einen Test-Runner und verarbeitest Benutzereingaben.
STANDARD bei Unsicherheit: (a) und (b).
Sage, was jede Wahl kostet: (c) und (d) benötigen eine laufende URL, (e) benötigt eine Regeln-Datei.

F2: Wenn ein Check fehlschlägt, während der Agent mitten in der Aufgabe ist – soll er blockieren oder nur warnen?
SCHÄTZUNG: Blockieren. Du betreibst Agenten unbeaufsichtigt, und eine Warnung, die niemand liest, ist eine Warnung.
STANDARD bei Unsicherheit: Blockieren auf dem Boden, bei allem anderen zwei Wochen lang nur warnen.

F3: Hast du konkrete Zielzahlen, oder soll ich messen, wo du heute stehst, und diese Linie halten?
SCHÄTZUNG: Messen. Die meisten Teams haben keine Zahl, und eine erfundene wird ignoriert.
STANDARD bei Unsicherheit: Messen und halten. Siehe „Ratchets“ unten.

F4: Was ist der langsamste Check, den du tolerierst, bevor der Agent die Arbeit zurückgibt?
SCHÄTZUNG: Etwa 90 Sekunden. Länger, und du wirst ihn nicht mehr ausführen.
STANDARD bei Unsicherheit: 90 Sekunden am Ende der Aufgabe, unbegrenzt in CI.

Höre nach vier Fragen auf. Ein Aufnahmeprozess mit zwölf Fragen produziert eine Konfiguration, die niemand versteht, und einen Nutzer, der den Start bereut.

Schritt 3: CONSTRAINTS.md schreiben

Eine Datei im Repository-Stamm. Jeder Agent auf jeder Plattform kann sie lesen, und eine Änderung daran taucht im Review auf, wo sie hingehört.

# Constraints

Zuletzt überprüft: 2026-08-08 von @addy

## Boden (immer durchgesetzt, keine Einrichtung nötig)

- Keine neuen Suppression-Kommentare: `@ts-ignore`, `eslint-disable`, `# noqa`, `# type: ignore`
- Keine nicht implementierten Stubs: `throw new Error("Not implemented")`, leeres `catch {}`
- Keine übersprungenen oder gelöschten Tests ohne Grund in der Commit-Nachricht
- Keine Secrets im Quellcode
- Diese Datei darf nicht geschwächt werden, um eine Änderung durchzubringen

## Durchgesetzt mit Zahlen

| Dimension | Regel | Geprüft durch | Läuft bei |
|-----------|------|-----------|---------|
| Typen | Null Typfehler | `tsc --noEmit` | jeder Bearbeitung |
| Lint | Null Fehler aus unserem Config | `biome check` | jeder Bearbeitung |
| Secrets | Keine Secrets im Quellcode | `gitleaks detect --redact` | jeder Bearbeitung |
| Abdeckung | Geänderte Zeilen ≥ 80 % abgedeckt | `vitest run --coverage` + git diff | Aufgabenende, CI |
| Sicherheit: Code | Keine hohen Funde | `semgrep scan --config p/default` | CI |
| Sicherheit: Abhängigkeiten | Nichts mit hohem oder höherem Schweregrad | `osv-scanner scan source -r .` | CI |
| Barrierefreiheit | Null kritische oder schwere Funde | `axe $PREVIEW_URL --tags wcag2a,wcag2aa,wcag21aa` | Preview-Deploy |
| Performance | LCP ≤ 2500ms, CLS ≤ 0,1 | `lighthouse $PREVIEW_URL --output=json` | Preview-Deploy |

Jede Zeile benennt den Befehl, der das Urteil fällt. Eine Dimension mit einer Zahl und keinem Befehl in dieser Spalte ist eine Aspiration, keine Einschränkung.

## Gemessen, noch nicht durchgesetzt

| Metrik | Heute | Richtung |
|--------|-------|-----------|
| Projektabdeckung | 62,4 % | darf nicht fallen |
| Bundle-Größe (Main) | 184 kB | darf nicht wachsen |

## Ausnahmen

| ID | Regel | Pfad | Grund | Verantwortlich | Läuft ab |
|----|------|------|--------|-------|---------|
| W1 | `no-explicit-any` | `src/legacy/**` | Umschreibung in ENG-441 verfolgt | @addy | 2026-11-01 |

Füge dann eine Zeile zu AGENTS.md und CLAUDE.md hinzu: Lies CONSTRAINTS.md, bevor du Code schreibst. Schwäche sie nicht, um eine Änderung durchzubringen.

Schritt 4: Installieren, was jede Dimension braucht

Eine Dimension auszuwählen bedeutet, etwas zu installieren. Lass den Nutzer nicht mit einer Zahl und keinem Mechanismus zurück, und erfinde keinen eigenen Checker, wenn ein De-facto-Standard existiert – diese Tools sind aufgelistet, weil ihre Regelformate und Schwellenwerte das Ziel sind, auf das alles andere im Ökosystem abzielt, sodass die vorhandene Konfiguration des Teams weiter funktioniert.

Dimension	Tool	Installieren	Ausführen	Tor auf
Typen (TS)	tsc	bereits vorhanden	tsc --noEmit	jeder Fehler
Typen (Python)	mypy	pip install mypy	mypy .	jeder Fehler
Lint	dein vorhandenes Config	bereits vorhanden	eslint . / biome check / ruff check	jeder Fehler
Abdeckung (JS)	dein Test-Runner	bereits vorhanden	vitest run --coverage (oder jest --coverage)	Abdeckung geänderter Zeilen
Abdeckung (Python)	pytest-cov	pip install pytest-cov	pytest --cov --cov-report=lcov	gleich
Sicherheit: Code	Semgrep	pipx install semgrep	semgrep scan --config p/default --config p/owasp-top-ten	jeder hohe Fund
Sicherheit: Secrets	gitleaks	brew install gitleaks	gitleaks detect --redact --no-banner	jeder Fund
Sicherheit: Abhängigkeiten	osv-scanner	brew install osv-scanner	osv-scanner scan source -r .	hoch oder höher
Performance: Seite	Lighthouse	npm i -D lighthouse	lighthouse $URL --output=json --quiet	LCP, CLS, Performance-Score
Performance: Bundle	size-limit	npm i -D size-limit	size-limit --json	Pro-Eintrag-Byte-Budget
Barrierefreiheit	axe-core	npm i -D @axe-core/cli	axe $URL --tags wcag2a,wcag2aa,wcag21aa	null kritisch oder schwer
Architektur	dependency-cruiser	npm i -D dependency-cruiser	depcruise --validate src	jede Verletzung
Assertionsqualität	Stryker	npm i -D @stryker-mutator/core	stryker run --mutate <geänderte Dateien>	Mutations-Score

Fünf Dinge, die dich beißen werden, wenn du sie überspringst:

1. --redact bei gitleaks ist nicht optional. Ohne sie landet das gefundene Secret im Transkript des Agenten – so landet ein geleakter Schlüssel in einem Log, einer Zusammenfassung oder einer Commit-Nachricht. Melde die Regel und den Ort, niemals den Wert.
2. Lighthouse und axe benötigen eine URL. Sie funktionieren nur gegen eine laufende App, also gehören sie in die Laufzeitphase gegen ein Preview-Deploy oder einen lokalen Server, den du zuerst startest. Wenn das Projekt keine URL hat, die erreicht werden kann – ein CLI, eine Bibliothek, eine Desktop-App –, sag dies und lass die Dimension fallen, anstatt einen Check zu erfinden, der nicht laufen kann.
3. Begrenze die teuren Checks auf den Diff. stryker run --mutate auf dem gesamten Repository dauert Stunden und wird abgeschaltet; auf den Dateien, die eine Änderung betrifft, dauert es unter einer Minute. Gleiches gilt für Semgrep, das eine Pfadliste akzeptiert.
4. Abdeckung benötigt keinen zweiten Testlauf. Lies das lcov, das deine Suite bereits schreibt, und überschneide es mit git diff. Zweimalige Ausführung der Suite, um eine Zahl zu bekommen, ist der schnellste Weg, die Leute dazu zu bringen, die Funktion zu hassen.
5. Die Registry-Regeln von Semgrep sind kostenlos ausführbar; überprüfe die Lizenz, bevor du sie weiterverteilst. opengrep ist ein Drop-in-Fork mit demselben Regelformat und JSON-Ausgabe, falls das für dein Rechts-Team relevant ist.

Füge jede Dimension zu den eigenen Skripten des Projekts hinzu, damit sie ohne Agenten reproduzierbar sind:

{
  "scripts": {
    "check:fast": "tsc --noEmit && eslint . && gitleaks detect --redact --no-banner",
    "check:task": "npm run check:fast && vitest run --coverage",
    "check:full": "npm run check:task && semgrep scan --config p/default && osv-scanner scan source -r ."
  }
}

Diese Zuordnung ist wichtiger als die Tools. check:fast läuft nach einer Bearbeitung, check:task wenn der Agent denkt, er sei fertig, check:full in CI.

Die Befehle leben jetzt an zwei Orten: der Spalte Geprüft durch in CONSTRAINTS.md und diesen Skripten. CONSTRAINTS.md ist die kanonische Quelle: Sie trägt den Grund neben jedem Befehl und taucht im Review auf. Die Skripte sind Convenience-Wrapper, die sie spiegeln müssen, keine zweite Wahrheitsquelle; wenn sie abweichen, gewinnt die Datei.

Schritt 5: An den Lebenszyklus anbinden

Der größte einzelne Fehler ist, alles überall auszuführen. Ein Check, der den Agenten blockiert, wird abgeschaltet, und ein Tor, das die Leute abgeschaltet haben, ist schlimmer als kein Tor, weil die Schwelle immer noch so aussieht, als ob sie existiert.

Phase	Befehl	Was läuft	Budget
BUILD	/build	Typen, Lint, Secrets, der Boden	unter 5s, nur geänderte Dateien
VERIFY	/test	Relevante Tests, Abdeckung auf geänderten Zeilen	unter 90s
REVIEW	/review	Alles, plus die Wächter unten	Minuten
SHIP	/ship	Richtungschecks, keine Regressionen	CI

Zwei Regeln, die dies tolerierbar halten:

1. Auf den Diff begrenzen. Prüfe die Zeilen, die diese Änderung betrifft, nicht das gesamte Repository. Abdeckung auf geänderten Zeilen ist eine Zahl, die der Agent bewegen kann; Projektabdeckung ist eine, die er geerbt hat.
2. Die Kosten bestimmen den Ort. Alles über ein paar Sekunden wandert aus der Editier-Schleife. Mutationstests auf dem gesamten Repository dauern Stunden; auf den Dateien, die eine Änderung betrifft, dauern sie unter einer Minute – das ist der Unterschied zwischen einem Check, den Leute ausführen, und einem, den sie nicht ausführen.

Schritt 6: Die Schwelle selbst bewachen

Jemand wird darauf hinweisen, dass, wenn der Agent den Code und die Checks schreibt, die Checks nichts beweisen. Halb richtig, und die Konstruktion wert.

Agenten entwickeln keine cleveren Schlupflöcher. Sie treffen auf einen roten Check und nehmen den billigsten Weg nach Grün. Achte auf diese fünf Bewegungen im Diff, zur Review-Zeit:

1. Der Schwellenwert wurde verschoben. Ein Budget gesenkt, ein Schweregrad herabgesetzt, ein Check aus der schnellen Phase entfernt. Vergleiche CONSTRAINTS.md mit ihrem Zustand am Verzweigungspunkt.
2. Ein Test wurde einfacher gemacht. .skip hinzugefügt, eine Testdatei gelöscht, Assertions aus Tests entfernt, die geblieben sind.
3. Ein Checker wurde zum Schweigen gebracht. Neue @ts-ignore oder eslint-disable. Vier Suppressionen verdienen besondere Aufmerksamkeit, weil sie einen Check ausschalten, auf den du dich verlässt: istanbul ignore entfernt Code aus der Abdeckung, anstatt ihn zu testen, Stryker disable versteckt einen überlebenden Mutanten, nosemgrep und gitleaks:allow tun dasselbe für Sicherheitsfunde.
4. Arbeit ist unvollendet. Ein Stub, der eine Ausnahme wirft, ein leeres catch, das einen Fehler in Stille verwandelt, ein TODO, das an der Stelle steht, wo die Implementierung sein sollte.
5. Eine Ausnahme ist aufgetaucht. Eine neue Zeile in der Ausnahmen-Tabelle, die niemand besprochen hat.

Nichts davon benötigt Werkzeuge über git diff hinaus. Die Schwelle zu verschärfen sollte still sein; sie zu lockern sollte laut sein.

Im Unterschied zu den nummerierten Dimensionen hat der Boden kein eigenes De-facto-Werkzeug. Ein Agent, der gebeten wird, den Boden durchzusetzen, neigt dazu, einen Checker von Grund auf zu schreiben, und zwei Agenten schreiben zwei verschiedene. Eine Referenzimplementierung dieser fünf Prüfungen wird mit diesem Skill in references/floor-guard.md mitgeliefert (diff-begrenzt, Exit 0/1/2, Muster pro Ökosystem anpassbar). Passe diese an, anstatt sie neu zu erfinden, aus demselben Grund, aus dem jede Dimension ein De-facto-Werkzeug nennt: damit der Mechanismus über Läufe und Plattformen hinweg derselbe ist.

Nicht alle Checks sind gleich zirkulär. Ordne sie nach einer Frage: Kann der Agent diesen Check bestehen, indem er Code schreibt, der nicht funktioniert?

• Extern – axe-core codiert WCAG, osv-scanner liest eine Schwachstellendatenbank, Lighthouse misst einen echten Browser. Der Agent kann nicht mit diesen argumentieren.
• Projekt – deine Lint-Regeln, deine Schichtengrenzen. Ein Mensch besitzt die Datei.
• Suite – deine eigenen Tests. Am nützlichsten und der einzige wirklich zirkuläre.

Eine Schwelle …

[… für die Übersetzung gekürzt]