Lerne, wie du mit Claude Code Feature‑Spezifikationen aus dem Code erstellst: Verhalten aus Routen und Komponenten extrahieren und daraus eine lebende Spezifikation sowie eine Lückenliste erstellen.
Menschen haben unterschiedliche Erinnerungen daran, was eine App tut. Support erinnert sich an das letzte wütende Ticket. Sales erinnert sich an den Demo‑Pfad. Entwickler erinnern sich daran, was das Feature ursprünglich tun sollte. Frag drei Leute und du erhältst drei selbstsichere Antworten — keine davon entspricht unbedingt dem aktuellen Build.
Mit der Zeit wird der Code zur einzigen Quelle, die aktuell bleibt. Dokumentation driftet, Tickets werden geschlossen und schnelle Fixes häufen sich. Eine Route bekommt eine neue Validierungsregel. Ein UI‑Toggle ändert ein Default. Ein Handler beginnt, andere Fehler zurückzugeben. Niemand aktualisiert die Spezifikation, weil es optional erscheint und jede Änderung zu klein wirkt, um dokumentiert zu werden.
Das führt zu vorhersehbaren Problemen. Teams liefern Änderungen, die Edge‑Cases brechen, von denen sie nichts wussten. QA testet den Happy Path und übersieht Regeln, die in Handlern versteckt sind. Neue Teammitglieder kopieren Verhalten aus der UI, ohne die echten Einschränkungen zu verstehen. Stakeholder debattieren Meinungen statt auf vereinbartes Verhalten zu zeigen.
Ein gutes Ergebnis ist kein perfektes Dokument — es ist gemeinsame Klarheit. Jede:r sollte beantworten können: „Was passiert, wenn ich X mache?“ und „Was garantiert das System?“ ohne zu raten. Du bekommst weniger Überraschungen, kürzere Review‑Zyklen und weniger „Moment, das macht es doch schon“‑Momente, weil das Team dieselbe Wahrheit anschaut.
Wenn eine Spezifikation dem Code entspricht, wird es sicher, Änderungen zu planen. Du erkennst, was stabil ist, was zufällig ist und was fehlt, bevor du auslieferst.
Eine Living Spec ist eine kurze, editierbare Beschreibung dessen, was die App heute tatsächlich tut. Sie ist kein Einmaldokument. Sie ändert sich, wenn sich das Verhalten ändert, sodass das Team ihr vertrauen kann.
Bei Feature‑Spezifikationen, die aus dem Code geschrieben werden (zum Beispiel mit Claude Code), ist das Ziel einfach: echtes Verhalten aus Routen, Handlern und Screens lesen und dann in einfacher Sprache aufschreiben.
Eine nützliche Living Spec konzentriert sich auf das, was Nutzer sehen und was das System verspricht. Sie sollte abdecken:
Was sie nicht behandeln sollte, ist, wie der Code organisiert ist. Sobald du anfängst, Dateien und Refactor‑Pläne zu nennen, driftest du in Implementierungsdetails ab. Vermeide:
Eine Lückenliste ist separat. Sie ist eine kleine Liste von Unstimmigkeiten und Unbekannten, die du beim Schreiben der Spec findest.
Beispiel: Eine Route lehnt Dateien über 10MB ab, die UI sagt aber 25MB. Das ist eine Lücke, bis das Team entscheidet, welche Regel gilt und entweder den Code oder die Spec ändert.
Starte klein. Wenn du versuchst, die ganze App zu dokumentieren, endest du mit einem Haufen Notizen, denen niemand vertraut. Wähle eine Slice, die Nutzer in einem Satz beschreiben können, wie „einen Teamkollegen einladen“, „Checkout“ oder „Passwort zurücksetzen“. Gute Scopes sind ein einzelner Featurebereich, ein Modul oder eine Nutzerreise von Einstiegspunkt bis Ergebnis.
Wähle den Einstiegspunkt danach, wo die Wahrheit liegt:
Bevor du Code liest, sammle ein paar Inputs, damit Unstimmigkeiten schnell auffallen: vorhandene API‑Docs, alte Produktnotizen, Support‑Tickets und bekannte Schmerzpunkte. Diese überschreiben nicht den Code, helfen aber, fehlende Zustände wie Fehler, Edge‑Cases und Berechtigungen zu bemerken.
Halte das Spec‑Format langweilig und konsistent. Teams kommen schneller auf einen Nenner, wenn jede Spec gleich aufgebaut ist.
Nutze diese Struktur wiederholt, dann bleiben deine Feature‑Specs lesbar, vergleichbar und leicht zu aktualisieren.
Beginne bei den Server‑Einstiegspunkten. Routen und Handler zeigen „was die App tut“ in konkreten Begriffen: wer sie aufrufen kann, was gesendet werden muss, was zurückkommt und was sich im System ändert.
Liste die in‑Scope Routen auf und ordne jeder Route eine Nutzerabsicht zu. Schreib nicht „POST /api/orders.“ Schreib stattdessen „Bestellung aufgeben“ oder „Entwurf speichern.“ Wenn du die Absicht nicht leicht in einfachen Worten benennen kannst, ist das bereits eine Spec‑Lücke.
Während du jeden Handler liest, erfasst du Inputs und Validierungsregeln als nutzer‑sichtbare Anforderungen. Füge Pflichtfelder, erlaubte Formate und Regeln hinzu, die echte Fehler auslösen. Zum Beispiel: „E‑Mail muss gültig sein“, „Menge muss mindestens 1 sein“, „Startdatum darf nicht in der Vergangenheit liegen.“
Schreibe Auth‑ und Rollenprüfungen genauso auf. Anstatt „middleware: requireAdmin“, dokumentiere: „Nur Admins können jede Bestellung stornieren. Normale Nutzer können ihre eigene Bestellung nur innerhalb von 10 Minuten stornieren.“ Wenn der Code Ownership, Feature‑Flags oder Tenant‑Grenzen prüft, nimm auch diese mit auf.
Notiere dann Outputs und Outcomes. Was liefert Erfolg zurück (eine erstellte ID, ein aktualisiertes Objekt)? Wie sehen häufige Fehler aus (401 nicht angemeldet, 403 nicht erlaubt, 404 nicht gefunden, 409 Konflikt, 422 Validierungsfehler)?
Schließlich halte Side Effects fest, denn sie sind Teil des Verhaltens: Datensätze erstellt oder aktualisiert, E‑Mails oder Benachrichtigungen gesendet, Events veröffentlicht, Hintergrundjobs in die Queue gestellt und alles, was andere Flows auslöst. Diese Details verhindern Überraschungen, wenn Teams später auf die Spec angewiesen sind.
Routen sagen, was die App kann. Komponenten zeigen, was Nutzer tatsächlich erleben. Betrachte die UI als Teil des Vertrags: was angezeigt wird, was blockiert wird und was passiert, wenn etwas schiefgeht.
Finde zuerst die Einstiegs‑Screens für das Feature. Suche nach der Seitenkomponente, dem Layout‑Wrapper und einigen „Entscheidungs“‑Komponenten, die Fetching, Berechtigungen und Navigation steuern. Dort lebt meist das echte Verhalten.
Wenn du Komponenten liest, erfasse Regeln, die Nutzer merken: wann Aktionen deaktiviert sind, Pflichtschritte, bedingte Felder, Ladezustände und wie Fehler angezeigt werden (Inline‑Feldfehler vs Toast, automatischer Retry, „nochmals versuchen“‑Buttons). Notiere auch Zustands‑ und Caching‑Verhalten wie zuerst angezeigte veraltete Daten, optimistische Updates oder „zuletzt gespeichert“‑Zeitstempel.
Achte auf versteckte Flows, die das, was Nutzer sehen, still verändern. Suche nach Feature‑Flags, Experiment‑Buckets und Admin‑Only‑Gates. Notiere stille Redirects wie das Weiterleiten nicht angemeldeter Nutzer zur Anmeldung oder das Weiterleiten von nicht berechtigten Nutzern zu einem Upgrade‑Screen.
Ein konkretes Beispiel: Auf einem „E‑Mail ändern“‑Screen dokumentiere, dass der Speichern‑Button deaktiviert bleibt, bis die E‑Mail gültig ist, ein Spinner während der Anfrage angezeigt wird, Erfolg ein Bestätigungsbanner auslöst und Backend‑Validierungsfehler unter dem Input gerendert werden. Wenn der Code ein Flag wie newEmailFlow zeigt, notiere beide Varianten und die Unterschiede.
Schreibe jeden UI‑Flow als kurze Schritte (was der Nutzer tut, was die UI zurücktut) und halte Bedingungen und Fehler neben dem Schritt, den sie beeinflussen. Das macht die Spec lesbar und Lücken leichter erkennbar.
Rohnotizen aus Routen und Komponenten sind nützlich, aber schwer zu diskutieren. Formuliere um, was du beobachtet hast, in eine Spec, die PMs, Designer, QA und Entwickler lesen und zustimmen können.
Ein praktisches Muster ist eine User‑Story pro Route oder Screen. Halte sie klein und konkret. Zum Beispiel: „Als angemeldete:r Nutzer:in kann ich mein Passwort zurücksetzen, damit ich wieder Zugriff erhalte.“ Wenn der Code unterschiedliches Verhalten nach Rolle zeigt (Admin vs User), teile es in separate Stories statt es in Fußnoten zu verstecken.
Schreibe dann Akzeptanzkriterien, die reale Code‑Pfade widerspiegeln, nicht das ideale Produkt. Wenn der Handler 401 zurückgibt, wenn das Token fehlt, ist das ein Kriterium. Wenn die UI Submit deaktiviert, bis ein Feld gültig ist, ist das ein Kriterium.
Führe Datenregeln in einfacher Sprache an, besonders solche, die für Überraschungen sorgen: Limits, Sortierung, Eindeutigkeit, Pflichtfelder. „Benutzernamen müssen eindeutig sein (bei Save geprüft)“ ist klarer als „Unique‑Index“.
Edge‑Cases sind oft der Unterschied zwischen einem schönen Dokument und einem nützlichen. Hebe Leerzustände, Nullwerte, Retries, Timeouts und das, was Nutzer sehen, wenn ein API‑Call fehlschlägt, hervor.
Wenn du auf Unbekanntes triffst, markiere es statt zu raten:\n\n- Unknown: Welche Meldung soll erscheinen, wenn die E‑Mail nicht gefunden wird?\n- Unknown: Dürfen 0 Artikel erlaubt sein oder muss mindestens 1 vorhanden sein?\n- Unknown: Ist dieser Fehler für Nutzer sichtbar oder wird er nur geloggt?\n Solche Marker werden zu kurzen Fragen an das Team statt zu stillen Annahmen.
Eine Lückenliste ist kein zweites Jira. Sie ist ein kurzes, evidenzbasiertes Protokoll, wo Code und beabsichtigtes Verhalten nicht übereinstimmen oder wo niemand klar erklären kann, was „korrekt“ ist. Gut gemacht wird sie ein Werkzeug zur Einigung, nicht zur Planungsdebatte.
Sei streng bei dem, was als Lücke zählt:\n\n- Unklares Verhalten: die App tut etwas, aber die Regel steht nirgends geschrieben.\n- Inkonsistenz: zwei Stellen verhalten sich unterschiedlich im gleichen Fall.\n- Fehlende Regel: ein Edge‑Case existiert, aber keine Entscheidung ist im Code oder den Docs sichtbar.
Wenn du eine Lücke protokollierst, gib drei Teile an, damit sie fundiert bleibt:\n\n- Type: Bug (Code scheint falsch) oder Missing Decision (Intent unklar)\n- Impact: Nutzerverwirrung, Sicherheitsrisiko, Datenverlust oder gering\n- Evidence: wo du es gesehen hast und was du beobachtet hast (Route/Handler/Komponente)
Evidence verhindert, dass die Liste zu Meinungen wird. Beispiel: „POST /checkout/apply-coupon akzeptiert abgelaufene Coupons, aber CouponBanner.tsx blockiert sie in der UI. Impact: Umsatz und Nutzerverwirrung. Type: Bug oder Missing Decision (intendierte Regel bestätigen).“
Halte die Liste kurz. Setze eine harte Obergrenze, z. B. 10 Items in der ersten Runde. Wenn du 40 Probleme findest, gruppiere sie in Muster (Validierungsinkonsistenzen, Berechtigungsprüfungen, Leerzustände) und behalte nur die wichtigsten Beispiele.
Vermeide Datumsangaben und Zeitplanung in der Lückenliste. Wenn du Ownership brauchst, halte es leichtgewichtig: notiere, wer die Entscheidung treffen sollte (Produkt) oder wer das Verhalten verifizieren kann (Engineering), und verschiebe die echte Planung in dein Backlog.
Wähle einen kleinen, stark genutzten Bereich: Checkout mit Promo‑Codes und Versandoptionen. Ziel ist nicht, das ganze Produkt neu zu schreiben, sondern zu erfassen, was die App heute tut.
Beginne mit Backend‑Routen. Dort zeigen sich Regeln oft zuerst. Du könntest Routen wie POST /checkout/apply-promo, GET /checkout/shipping-options und POST /checkout/confirm finden.
Aus diesen Handlern formulierst du Verhalten in einfachen Worten:
Dann prüfe die UI‑Komponenten. Ein PromoCodeInput zeigt vielleicht, dass die Totals erst nach einer erfolgreichen Antwort aktualisiert werden und Fehler inline unter dem Input erscheinen. Eine ShippingOptions‑Komponente wählt beim ersten Laden automatisch die günstigste Option und löst eine vollständige Preisaufstellung aus, wenn der Nutzer sie ändert.
Jetzt hast du eine lesbare Spec und eine kleine Lückenliste. Zum Beispiel: Fehlermeldungen unterscheiden sich zwischen Promo‑Route und UI („Invalid code“ vs „Not eligible“) und niemand kann eine klare Steuer‑Rundungsregel nennen (pro Position vs. Gesamtsumme).
Bei der Planung stimmt das Team zuerst über die Realität ab, dann entscheidet es, was geändert werden soll. Statt Meinungen zu diskutieren, prüft ihr dokumentierte Verhaltensweisen, wählt eine Inkonsistenz zur Behebung und lasst den Rest als „bekanntes aktuelles Verhalten“ stehen, bis es sich lohnt, ihn anzugehen.
Eine Spec hilft nur, wenn das Team zustimmt, dass sie die Realität widerspiegelt. Mach eine kurze Durchsicht mit einer Entwicklerin/einem Entwickler und einer Produktperson. Halte es knapp: 20–30 Minuten konzentriert auf das, was Nutzer tun können und wie das System reagiert.
Formuliere während der Durchsicht Aussagen als Ja/Nein‑Fragen. „Wenn ein Nutzer diese Route trifft, geben wir immer 403 ohne Session zurück?“ „Ist dieser Leerzustand beabsichtigt?“ Das trennt beabsichtigtes Verhalten von zufällig eingetragener Funktionalität.
Stimmt euch auf Vokabular ab, bevor ihr etwas editiert. Verwendet die Begriffe aus der UI (Button‑Labels, Seitentitel, Fehlermeldungen). Fügt interne Namen nur hinzu, wenn sie Entwickler:innen helfen, den Code zu finden (Routen‑ oder Komponenten‑Namen). Das verhindert Abweichungen wie Produkt sagt „Workspace“, die Spec aber „Org“ nennt.
Um sie aktuell zu halten, macht Ownership und Rhythmus explizit:
Wenn du ein Tool wie Koder.ai nutzt, helfen Snapshots und Rollbacks beim Vergleichen von „vorher“ und „nachher“, besonders nach großen Refactors.
Der schnellste Weg, Vertrauen in eine Spec zu verlieren, ist, das Produkt zu beschreiben, das man haben möchte, nicht das Produkt, das man hat. Regel: Jede Aussage sollte durch etwas untermauert sein, das du im Code oder auf einem echten Screen zeigen kannst.
Eine weitere Falle ist, die Form des Codes in das Dokument zu kopieren. Eine Spec, die liest wie „Controller -> Service -> Repository“, ist keine Spezifikation, sondern eine Ordnerkarte. Schreib in nutzerzentrierten Begriffen: was die Aktion auslöst, was der Nutzer sieht, was gespeichert wird und wie Fehler aussehen.
Berechtigungen und Rollen werden oft bis zum Schluss ignoriert, dann bricht alles zusammen. Nimm Zugriffsregeln früh auf, auch wenn sie noch unordentlich sind. Hebe hervor, welche Rollen ansehen, erstellen, bearbeiten, löschen, exportieren oder genehmigen können und wo die Regel durchgesetzt wird (nur UI, nur API oder beides).
Überspringe nicht die Nicht‑Happy‑Paths. Echtes Verhalten versteckt sich in Retries, Teilfehlern und zeitbasierten Regeln wie Abläufen, Cooldowns, Cronjobs oder „nur einmal pro Tag“‑Limits. Behandle diese als erstklassiges Verhalten.
Eine schnelle Methode, Lücken zu finden, ist zu prüfen auf:\n\n- Validierungsfehler und die genauen Fehlermeldungen, die Nutzer sehen\n- Handhabung doppelter Submits (Idempotenz)\n- Hintergrundarbeit (Queues, Cron) und was passiert, wenn sie fehlschlägt\n- Konkurrenzprobleme (zwei Nutzer ändern denselben Datensatz)\n- Zeitbasiertes Verhalten (Timeouts, Abläufe, Rate‑Limits)
Zum Schluss: Halte die Lückenliste in Bewegung. Jede Lücke sollte als „unknown, needs decision“, „bug, fix“ oder „missing feature, plan“ gekennzeichnet sein. Wenn nichts gelabelt wird, stagniert die Liste und die Spec hört auf, „living“ zu sein.
Mach einen schnellen Durchlauf auf Klarheit, Abdeckung und Umsetzbarkeit. Jemand, der sie nicht geschrieben hat, sollte verstehen, was das Feature heute tut und was noch unklar ist.
Lies die Spec wie eine neue Kollegin/ein neuer Kollege am ersten Tag. Wenn sie das Feature in einer Minute zusammenfassen kann, bist du nah dran. Wenn sie ständig fragt „Wo fängt das an?“ oder „Was ist der Happy Path?“, straffe die Einleitung.
Checke:\n\n- One‑Page‑Test: Die Einleitung nennt das Nutzerziel, wo der Flow startet und wo er endet.\n- Rollen und Zugriff: Schlüsselrollen und was jede:r kann oder nicht kann.\n- Outcomes: Wie Erfolg aussieht und was Nutzer sehen, wenn es fehlschlägt (Meldungen, Redirects, Retries).\n- Kanten und Limits: Größenlimits, Ratenlimits, Timeouts, Validierungsregeln und was passiert, wenn Daten fehlen.\n- Sprache: Nutze Nutzerbegriffe zuerst; definiere unvermeidbares Fachvokabular einmal.
Jede Lücke sollte konkret und testbar sein. Statt „Fehlerbehandlung unklar“ schreibe: „Wenn der Zahlungsanbieter 402 zurückgibt, zeigt die UI einen generischen Toast; bestätige gewünschte Meldung und Retry‑Verhalten.“ Füge eine nächste Aktion hinzu (Produkt fragen, Test ergänzen, Logs prüfen) und nenne, wer antworten soll.
Wähle einen Feature‑Bereich und begrenze die Zeit auf 60 Minuten. Wähle etwas Kleines, aber Reales (Login, Checkout, Suche, ein Admin‑Screen). Schreib einen Satz Scope: was eingeschlossen ist und was nicht.
Führe den Workflow einmal End‑to‑End aus: Überfliege die wichtigsten Routen/Handler, trace den Haupt‑UI‑Flow und schreibe beobachtbares Verhalten auf (Inputs, Outputs, Validierung, Fehlerzustände). Wenn du hängen bleibst, protokolliere die Frage als Lücke und mache weiter.
Wenn du fertig bist, teile die Spec, wo das Team kommentieren kann, und setze eine Regel: Jede ausgelieferte Verhaltensänderung muss die Spec im gleichen Lieferfenster aktualisieren, auch wenn es nur fünf Zeilen sind.
Halte Lücken getrennt vom Backlog. Gruppiere sie in „unknown behavior“, „inconsistent behavior“ und „missing tests“ und prüfe sie wöchentlich kurz, um zu entscheiden, was jetzt relevant ist.
Wenn Erstellen und Iteration langsam wirken, kann ein chatbasiertes Builder‑Tool wie Koder.ai helfen, schnell eine erste Version zu bekommen. Beschreibe das Feature, füge Schlüssel‑Snippets oder Routennamen ein, verfeinere die Formulierungen im Gespräch und exportiere den Source bei Bedarf. Wichtig ist Geschwindigkeit und gemeinsame Klarheit, nicht ein größeres Prozessgerüst.
Beginne mit einem kleinen, für Nutzer sichtbaren Bereich (zum Beispiel „Passwort zurücksetzen“ oder „einen Teamkollegen einladen“). Lies zuerst die Routen/Handler, um Regeln und Ergebnisse zu erfassen, und dann den UI‑Flow, um zu dokumentieren, was Nutzer tatsächlich sehen (deaktivierte Zustände, Fehler, Weiterleitungen). Schreibe das Ganze mit einer konsistenten Vorlage und protokolliere Unbekanntes als separate Lückenliste.
Standard: behandle das aktuelle Verhalten des Codes als Quelle der Wahrheit und dokumentiere es.\n\nWenn das Verhalten zufällig oder inkonsistent aussieht, „korrigiere“ es nicht in der Spezifikation – markiere es stattdessen als Lücke mit Belegen (wo du es gesehen hast und wie es sich verhält) und hol eine Entscheidung ein, ob der Code oder die Spezifikation angepasst werden soll.
Halte es langweilig und wiederholbar. Eine praktische Vorlage ist:\n\n- Purpose\n- Entry points\n- Preconditions (Auth/Rolle/Daten)\n- Main flow (5–10 Schritte)\n- Data and side effects\n- Errors and edge cases\n- Open questions\n\nSo bleiben Spezifikationen lesbar und Abweichungen leichter zu erkennen.
Schreibe Regeln als nutzerorientierte Anforderungen, nicht als Code‑Notizen.\n\nBeispiele:\n\n- „E‑Mail muss gültig sein“\n- „Menge muss mindestens 1 sein“\n- „Nur Admins können jede Bestellung stornieren; normale Nutzer können ihre eigene Bestellung nur innerhalb von 10 Minuten stornieren“\n\nErfasse, was einen Fehler auslöst und was der Nutzer dann sieht.
Konzentriere dich auf Beobachtbares:\n\n- Erfolgsresultat (was sich ändert, was der Nutzer sieht)\n- Häufige Fehlerarten (nicht angemeldet, nicht erlaubt, nicht gefunden, Validierungsfehler)\n- Side Effects (Datensätze aktualisiert, E‑Mails/Benachrichtigungen gesendet, Background‑Jobs in die Queue)\n\nSide Effects sind wichtig, weil sie andere Features und Support/Operations beeinflussen.
Wenn UI etwas blockiert, das die API erlaubt (oder umgekehrt), protokolliere es als Lücke, bis eine Entscheidung getroffen ist.\n\nNotiere dabei:\n\n- Was die UI sagt/tut\n- Was das Backend erzwingt\n- Die Auswirkung (Verwirrung, Sicherheit, Datenprobleme)\n\nDann stimmt ihr euch auf eine Regel ab und aktualisiert sowohl Code als auch Spezifikation.
Halte die Lückenliste klein und evidenzbasiert. Jeder Eintrag sollte haben:\n\n- Type: Bug vs. fehlende Entscheidung\n- Impact: gering vs. schwerwiegend (Verwirrung, Sicherheit, Datenverlust)\n- Evidence: wo du es gesehen hast (Route/Handler/Komponente) und das genaue Verhalten\n\nVermeide, daraus direkt ein zweites Backlog zu machen.
Dokumentiere sie explizit, statt sie zu verbergen.\n\nEinschließlich:\n\n- Leere Zustände (keine Ergebnisse, keine Berechtigung)\n- Retries/Timeouts und was der Nutzer als Nächstes tun kann\n- Doppelte Einreichungen (Doppelklick, Refresh)\n- Konkurrenzfälle (zwei Personen bearbeiten denselben Datensatz)\n- Zeitbasierte Regeln (Ablaufzeiten, Cooldowns)\n\nDas sind oft die Stellen, an denen Überraschungen und Bugs auftreten.
Kurz und fokussiert: 20–30 Minuten Read‑Through mit einer Entwicklerin/einem Entwickler und einer Produktperson.\n\nFormuliere Aussagen als Ja/Nein‑Checks (z. B. „Gibt die Route immer 403 zurück, wenn keine Session vorhanden ist?“). Stimmen sich auf Vokabular ab, indem ihr die UI‑Bezeichnungen verwendet (Button‑Labels, Seitentitel, Fehlermeldungen), damit alle dasselbe meinen.
Leg die Spezifikation nahe am Code ab und mache Updates zum Teil des Shipping‑Workflows.\n\nPraktische Defaults:\n\n- Eine klare Owner‑Person, die Spezifikationsänderungen merged\n- Update‑Trigger: jede Verhaltensänderung, die gemerged wird, oder bei jedem Release\n- PR‑Checklist‑Item: „Spec aktualisiert?“\n- Lücken separat halten und sie regelmäßig kurz prüfen\n\nZiel sind kleine, häufige Änderungen — keine große Überarbeitung.
