# 0005 – Grundlegendes Refactoring erst nach grüner Baseline und festgeschriebenen Verträgen

Status: vorgeschlagen · Datum: 2026-09-02 · Beteiligte: AG QGIS

## Kontext
Der Code ist gewachsen (zehn Dateien über 600 Zeilen, implizite Verträge, rote Tests). Ein Umbau jetzt würde Wissen
zerstören, das nur im Code steht, und wäre nicht durch Tests abgesichert.

## Entscheidung
Reihenfolge: (1) Workspace und Wissensbasis, (2) Tests mit Baseline und CI, Rot→Grün, (3) Verträge festschreiben
(Abhängigkeiten, Variablen, Linkliste, Manifest), (4) Refactoring-Konzept mit Zielarchitektur und Scheiben,
erst dann (5) Umbau. Bis dahin gilt „kein Refactoring nebenbei“; strukturelle Änderungen brauchen ein Issue.

## Folgen
Fachliche Weiterentwicklung bleibt möglich. Die Fachschale-Idee des Alternativansatzes wird im Refactoring-Konzept
bewertet, nicht vorher eingebaut.

## Verworfene Alternativen
Sofortiges Refactoring (Risiko); Neuentwicklung auf Basis des Alternativansatzes (verwirft 29 500 Zeilen Fachlogik).