# Release-Record 1.7.0 — Greenfield und Brownfield

Datum: 2026-09-06. Version `1.7.0` in `pyproject.toml`. Commit-Hash:
siehe Merge-Commit des Pull Requests. Ausgeliefert nach dem Merge durch
`deploy.yml`.

## Was sich ändert

Der Owner will, dass das Projekt Greenfield und Brownfield unterstützt.
Greenfield heißt: ein neues Produkt aus einer Idee. Brownfield heißt:
eine Idee für ein Produkt, das schon Code hat. Bisher kannte der Fahrer
`idea-to-production` nur die neue Idee. Die Spec steht unter
`_bmad-output/specs/spec-greenfield-brownfield/SPEC.md`.

| Bereich | Änderung | Wirkung für Nutzer |
|---|---|---|
| Skill | `idea-to-production`: Block "Two tracks". Vor Phase 1 prüft der Fahrer das Repo und schreibt die Spur (`greenfield` oder `brownfield`) in `STATE.md`. Brownfield: Phase 0 Bestand (project-context, vorhandene Pläne, Suite grün als Tor), forge-idea statt Brainstorming, vorhandene PRD, Architektur und Spec aktualisieren, correct-course bei Widerspruch, Regressionstests, kleine Schritte, Feature-Flag, nichts Fremdes umschreiben. Prosa an anderen Stellen gekürzt; 78 von 80 Zeilen | Der eine Befehl geht auch in einem bestehenden Projekt |
| Router | Zeile 1 in Schritt 1 nennt "new product or change to an existing one" und beide Spuren; Eval 7 prüft die Brownfield-Route | Der Router erreicht den Fahrer auch für Änderungen |
| Doku | `docs/cheat-sheet.md`: Abschnitt "Neu oder bestehend", Schritt 0 Bestand in der Tabelle, drittes Tor, Spur in der Stand-Datei. README: zwei Sätze zu beiden Fällen | Ein Mensch versteht, dass beides geht |
| Test | `tests/test_cheat_sheet.py`: Skill nennt beide Spuren, Zustandsdatei führt die Spur, Brownfield startet grün, Cheat-Sheet erklärt beide Fälle, Router leitet bestehende Produkte | Skill, Router und Cheat-Sheet driften nicht auseinander |

## Entscheidungen

- **Spur wird erkannt, nicht erfragt.** Quelldateien, Tests, `AGENTS.md`
  oder Planungsartefakte heißen Brownfield. Die Person kann überstimmen.
- **Rote Suite ist ein eigener Schritt.** Der Fahrer repariert zuerst,
  dann kommt die Idee. Im Dialog fragt er; autonom repariert er.
- **Vorhandene Pläne werden ergänzt.** PRD, Architektur und Spec nutzen
  den Update-Modus der installierten Skills. Nichts wird neu erfunden.
- **Kein Budget-Anstieg.** Der Skill blieb unter 80 Zeilen durch kürzere
  Prosa, nicht durch gestrichene Regeln. Die zwei Tore stehen jetzt an
  den Phasen 8 und 10 statt in einem eigenen Absatz.

## Nachweise

- Compile: 238 Prüfungen ok, 0 FAIL. Skill 78 von 80 Zeilen (Claude),
  79 von 80 (Cursor); Router 66 Zeilen Quelle.
- Suite lokal: siehe Pull Request. CI: siehe Pull Request.

## Abhängigkeiten (gepinnt)

Unverändert gegenüber 1.6.1: `bmad-method@6.12.0`, `cis=v0.3.2`,
`tea=v1.24.0`, `cisco-ai-skill-scanner==2.0.14`.

## Rollback

Dauer: etwa 20 Minuten (davon 15 Minuten CI und Deploy).

1. Branch anlegen und den Stand 1.6.1 anwenden:
   ```sh
   git checkout -b rollback-1.7.0 main
   git diff --binary main d7098f4 | git apply
   git add -A && git commit -m "rollback: Stand d7098f4 (v1.6.1)"
   git push -u origin rollback-1.7.0
   ```
   Erwartete Ausgabe: `git diff --stat d7098f4 HEAD` ist leer.
2. Pull Request öffnen und mergen. Erwartete Ausgabe: das CI-Gate ist grün.
3. Der Deploy startet nach dem Merge von selbst.
4. In betroffenen Projekten den Install erneut ausführen. Der Skill kennt
   dann wieder nur die neue Idee; eine `STATE.md` mit Feld Spur bleibt
   als Nutzerdatei liegen und stört nicht.

Keine Datenmigration. Kein Reverse-Skript nötig.