Auromix/feature-spec-builder

Feature Spec Builder

Verwandle "Bruchstücke" in "entwicklungsreife Funktionsanforderungen".

Der Kern ist nicht das Schreiben von Dokumentation, sondern das systematische Aufdecken und Vervollständigen der in einem Satz nicht genannten Informationen. Einem Satz wie "Ich brauche Funktion X" fehlen typischerweise 80% der für die Entwicklung notwendigen Informationen: Rollen, Szenarien, Grenzen, Zuständigkeiten, Schnittstellen, Abhängigkeiten, Abnahme. Dieser Skill schließt diese Lücken durch einen "festgelegten Dimensionsscan + interaktives, schrittweises Nachfragen" und erstellt am Ende eine Funktionsanforderung, die eine Entwicklungsüberprüfung besteht.

Die Ausgabe dieses Skills endet bei der Funktionsanforderung – sie enthält einen Schnittstellenvertragsentwurf und Abnahmekriterien, aber keine Aufgabenzerlegung und keinen Implementierungsplan. Die Aufgabenzerlegung wird dem Entwicklungsteam überlassen.

---

Konfigurationsbereich (vor der ersten Nutzung ausfüllen)

Dieser Skill basiert auf einem produktspezifischen Koordinatensystem und Teamvereinbarungen für Klassifizierung und Zusammenarbeit. Ersetzen Sie die Platzhalter durch die tatsächlichen Definitionen Ihres Teams; nach Themen gruppiert, nicht verwendete Gruppen können als Standard belassen werden.

A. Fähigkeitskoordinatensystem

L1 = <z.B. Atomare Fähigkeit / Basisschnittstelle für Bewegung und Wahrnehmung>
L2 = <z.B. Kombinierte Fähigkeit / Anwendungsentwicklungskit>
L3 = <z.B. Komplette Lösung / Szenarioauslieferung>
Fünf Domänen: Domäne1=<…> Domäne2=<…> Domäne3=<…> Domäne4=<…> Domäne5=<…>

B. Schnittstellenvereinbarung

API-Budget = <z.B. max. 300 Methoden>   Sprach-/Bindungsvereinbarung = <z.B. C++ core + pybind11>

C. Integrator und Form

Integratorstufen = <z.B. Associate / Professional / Expert>   Form = <Simulation / Echtes Gerät / Beides>
Ausgabeverzeichnis = <Standard: feature-specs/; Ausgabe wird in <dieses Verzeichnis>/<Feature-Name>/<Feature-Name>.md geschrieben>

D. Produktprinzipien (Richtschnur für die Selbstprüfung vor der Ausgabe)

Integrierte Standardprinzipien übernehmen: Ja / Nein (Standard = Ja, vollständiger Text in references/product-principles.md)
Team-spezifische/ergänzende Prinzipien: <kann leer bleiben; falls ausgefüllt, mit integrierten Standardprinzipien zusammengeführt, bei Konflikten gilt das Team>
Konfliktpriorität: <Zwei harte Einschränkungen können nicht überschrieben werden: Sicherheitsstandard und Abwärtskompatibilität sind rote Linien, bei Kollision muss die Entscheidung eskaliert und manuell getroffen werden; die relative Priorität der übrigen Prinzipien bitte hier eintragen, bei Leerstand wird bei Kollision stets eine Rückmeldung an den Benutzer zur Entscheidung gegeben, keine automatische Sortierung>
Unterschriftsberechtigter für breaking changes: <Wer muss unterschreiben, wenn ein Break festgestellt wird, z.B. Platform Architecture Lead>

E. Implementierungsebene × Abteilungszuordnung (für Schritt 4 der abteilungsübergreifenden Zerlegung und Zuweisung von Verantwortlichen; orthogonal zu L-Tier – L-Tier regelt die äußere Abstraktionsebene, Implementierungsebene regelt, welche Technologie-Stacks und Abteilungen intern betroffen sind)

Implementierungsebene → Verantwortliche Abteilung/Rolle (Owner) → Abteilungsübergreifender Unterzeichner
  Runtime-Ebene:
    2nd-Level-Entwicklungs-SDK-Schicht → <ausfüllen, z.B. SDK/Plattformteam> → <Unterzeichner>
    Basissoftware (Firmware/Middleware) → <ausfüllen, z.B. Embedded/Firmware-Team> → <Unterzeichner>
    Algorithmusdienste (Wahrnehmung/Algorithmen) → <ausfüllen, z.B. Algorithmus-Team> → <Unterzeichner>
    Hardware (Mechanik/Elektronik) → <ausfüllen, z.B. Hardware/Elektronik-Team> → <Unterzeichner>
  Nicht-Runtime-Ebene (Ökosystem-/Integrations-/Dokumentations-Features fallen hier an, nicht gewaltsam dem Firmware-/Algorithmus-/Hardware-Team zuweisen):
    Dokumentationsportal-Ebene → <ausfüllen, z.B. DevRel/Dokumentation/Frontend> → <Unterzeichner>
    Build-/Distributions-Infrastruktur-Ebene → <ausfüllen, z.B. SDK-Build/DevOps> → <Unterzeichner>
  Abteilungsübergreifender Eskalationspfad = <z.B. Layer-Owner → Abteilungsleiter → Abteilungsübergreifende Architektur-Review → CTO>

Was tun, wenn der Konfigurationsbereich nicht ausgefüllt ist: Mindestens Gruppe A (Fähigkeitsebenen + fünf Domänen) ausfüllen, diese beiden bestimmen direkt die Genauigkeit der Klassifizierung. Degradierte Behandlung der übrigen Gruppen:

• A/B/C nicht ausgefüllt: Bei der Klassifizierung (automatischer Klassifizierungsschritt) explizit angeben: "Die folgenden L-Ebenen/Domänen/API-Budget/Bindungsvereinbarung sind meine Annahme" und Begründung liefern; in allen Feldern des Haupttextes, die dieses Koordinatensystem verwenden (Ebene, Fähigkeitsdomäne, API-Budget, Bindungsvereinbarung, verteilt in den Abschnitten "Fähigkeitspositionierung", "Auswirkungsanalyse, Kompatibilität, Veröffentlichungsstrategie", "Schnittstellenvertragsentwurf") ausnahmslos [bestätigen] setzen, niemals Annahmewerte als bestätigt schreiben; "Tatsächliche Werte des Konfigurationsbereichs müssen ergänzt werden" in den Abschnitt "Offene Punkte zur Bestätigung" schreiben.
• D nicht ausgefüllt: Standardmäßig die 10 integrierten Standardprinzipien aus references/product-principles.md anwenden und im Abschnitt "Selbstprüfung der Produktprinzipien" anmerken: "Dieses Mal werden die integrierten Standardproduktprinzipien verwendet." Die Selbstprüfung der Produktprinzipien muss in jedem Fall durchgeführt werden, niemals überspringen, nur weil der Konfigurationsbereich leer ist.
• E nicht ausgefüllt: Owner/Abteilung/Unterzeichner in der abteilungsübergreifenden Zerlegung in Schritt 4 ausnahmslos mit [bestätigen: zuweisung erforderlich] kennzeichnen und den Benutzer auffordern, sie zu ergänzen, niemals Abteilungsnamen erfinden – das fälschliche Zuweisen von Verantwortlichkeiten zu falschen Teams ist der gefährlichste Fehler.

F. Organisation und Prozesse (lokale private Konfiguration, für unternehmensweite Zusammenarbeit)

Die Struktur "Wer ist wofür zuständig, welche Prozess-Gates durchlaufen, wie wird versioniert" ist unternehmensspezifisch und privat und wird nicht in diesen Skill geschrieben. Für die unternehmensweite Zusammenarbeit kopieren Sie die Vorlage aus references/org-process-config.md in eine lokale org-process.local.md (oder führen Sie scripts/init-org-config.sh aus, um sie zu generieren) und füllen Sie sie mit der Rollenkarte / den Liefer-Gates / dem Versionsrhythmus und der Pipeline-Kapazität Ihres Unternehmens aus. Lokal und privat, nicht einchecken (bereits in .gitignore).

• Mit dieser Konfiguration: Bei der Ausgabe den Owner gemäß Rollenkarte auf die tatsächliche Person festlegen, im Abschnitt "Auswirkungsanalyse, Kompatibilität, Veröffentlichungsstrategie" die zu durchlaufenden Gates und Liefergegenstände auflisten, Zielversion und Aufwand (Personentage) vs. Pipeline-Kapazität angeben und bei Änderungen nach Sperrung der Anforderung auf CCB-Prozess hinweisen (Details siehe references/org-process-config.md).
• Ohne diese Konfiguration: Allgemeine Rollenplatzhalter verwenden (z.B. [Produktmanager: zuweisung erforderlich]) und den Benutzer darauf hinweisen, dass eine lokale Konfiguration generiert werden kann. Schreiben Sie unter keinen Umständen echte Personennamen/interne Prozesse in den Skill oder in Dokumente, die zur öffentlichen Weitergabe bestimmt sind.

---

Workflow

Nach Erhalt einer fragmentierten Anforderung streng entlang dieser Hauptkette vorgehen:

Fragment empfangen → Anforderungsaufteilung (implizite Mehrfachfeatures erkennen) → Automatische Klassifizierung → Ebenenübergreifende Zerlegung und Routing (Änderungen auf verschiedenen Ebenen, Owner, Abhängigkeitsreihenfolge identifizieren) → Erste Klärungsstufe (Positionierung, grob) → Zweite Klärungsstufe (Funktionsdetails, fein) → Ausgabedokument (Prinzipien-Selbstprüfungs-Gate durchlaufen)

Schritt 1: Empfang und Paraphrasierung

Das vom Benutzer gegebene Fragment einlesen. Das Verständnis zunächst in einem Satz paraphrasieren ("Ich verstehe, dass Sie ... möchten, richtig?") und den Benutzer um Bestätigung oder Korrektur bitten. Dies verhindert von Anfang an Fehlinterpretationen.

Schritt 2: Anforderungsaufteilung (Implizite Mehrfachfeatures erkennen)

Ein fragmentierter Wunsch enthält oft mehr als eine Anforderung – besonders Fragmente aus Chat-/E-Mail-Threads, wo die Hauptanforderung am auffälligsten ist, aber daneben noch andere Anliegen, vom Dialog abweichende Fragen oder aus dem Ziel abgeleitete implizite Fähigkeiten verstreut sind. Nicht sofort in die auffälligste Anforderung stürzen und mit der Arbeit beginnen, sondern zuerst eine Aufteilungsscan durchführen:

• Das Fragment vollständig lesen und jeden unabhängig existierenden Wunsch auflisten (eine Aktion / eine Fähigkeit = ein Kandidaten-Feature). Besonders auf vier oft übersehene Arten achten: ① Die "ursprüngliche Frage", die durch Nachfragen in den Hintergrund gedrängt wurde; ② Vom Hauptanliegen unabhängige, nur beiläufig im selben Dialog erwähnte Wünsche; ③ Punkte, die das Entwicklungsteam bereits mit "vorübergehend nicht unterstützt / selbst implementieren" beantwortet hat (oft vergrabene, versteckte Anforderungen); ④ Aus dem ultimativen Ziel des Kunden abgeleitete, aber nicht explizit genannte kombinierte Fähigkeiten.
• Heuristik für heterogene Liefergegenstände: Wenn in einem Wunsch gleichzeitig verschiedene Liefergegenstandsformen (ausführbarer Code/Schnittstellenvertrag/Dokumentationsinhalt/Webseitenstruktur/Verteilungspaket) auftauchen, priorisiert auf Mehrfachfeatures prüfen – verschiedene Liefergegenstandsformen entsprechen oft verschiedenen Ownern, verschiedenen Abnahmearten und verschiedenen Wartungszyklen; eine Vermischung in einer MD-Datei führt dazu, dass Prüfgegenstand und Abnahmekriterien in Konflikt geraten (z.B. "ROS-Beispiel bereitstellen + ein neues Portal-Modul hinzufügen" = Code-Feature + Dokumentations-Feature, Owner und Abnahme sind grundlegend verschieden).
• Cluster verwandter Features mit gemeinsamer Wahrheitsquelle: Wenn mehrere aufgeteilte Features eine einzige Wahrheitsquelle teilen (z.B. Dokument-Tutorial = Code im Beispiel-Repository = externe Projektion des Haupt-Feature-Vertrags), dennoch jedes Feature eigenständig dokumentieren, aber in jedem Dokument muss im Abschnitt "Abhängigkeiten und Voraussetzungen" / "Verwandte Features" explizit die Zugehörigkeit der Wahrheitsquelle festgenagelt werden (welches Dokument/Repository die Definitionshoheit hat, der Rest sind Projektionen/Referenzen), und ein Abhängigkeitsdiagramm innerhalb des Clusters beifügen – das Paradigma "Definitionshoheit" aus dem "Schnittstellenvertrag zwischen den Ebenen" wiederverwenden, um zu vermeiden, dass mehrere Dokumente jeweils eine andere Version schreiben, die nicht übereinstimmen.
• Wenn es tatsächlich nur einen Wunsch gibt, notieren "Einzelfeature bestätigt" und direkt zur Klassifizierung übergehen.
• Wenn es mehrere gibt, eine Anforderungsaufteilungstabelle erstellen (Kandidaten-Feature | Ursprungszitat | Art | Status | Beziehung/Abhängigkeit zum Hauptanliegen), dann den Benutzer entscheiden lassen, welche in dieser Runde verfeinert werden sollen – dies ist eine Bereichsentscheidung, niemals eigenmächtig für ihn festlegen. Die nicht ausgewählten Features im Abschnitt "Offene Punkte zur Bestätigung" als "Platzhalter für verwandte Features" hinterlassen, um eine spätere separate Projektinitiierung zu ermöglichen.
• Wenn mehrere Features zusammen bearbeitet werden, für jedes Feature ein separates, eigenständiges Anforderungsdokument erstellen, niemals mehrere Anforderungen in dasselbe Dokument mischen – die folgenden Schritte einzeln durchlaufen, untereinander nur mit "verwandte Features" aufeinander verweisen und Abhängigkeiten klar kennzeichnen (z.B. D hängt von A+B ab). (Hinweis: Auch wenn ein Feature mehrere Ebenen umfasst, wird nur eine MD-Datei erstellt, intern nach Lesergruppen gegliedert, nicht in mehrere Dateien aufgeteilt; dies ist "interne Schichtung/Lesergruppen innerhalb desselben Features", nicht im Widerspruch zu "mehrere Features jeweils eigenständig dokumentieren".)

Dieser Schritt ist in der gesamten Kette der am leichtesten zu überspringende, aber der, der die Korrektheit der Ausgabe am meisten beeinflusst: Wird er übersprungen, decken die vom Entwicklungsteam erhaltenen Anforderungen möglicherweise nur einen Teil des Kundenwunsches ab oder vermischen mehrere an sich unabhängige Features zu einem einzigen.

Schritt 3: Automatische Klassifizierung

Die Anforderung im Koordinatensystem verankern: Auf welcher L1/L2/L3-Ebene liegt sie? Zu welcher der fünf Domänen gehört sie? Übergreift sie mehrere Domänen? Die Klassifizierung selbst deckt bereits die erste Reihe impliziter Probleme auf – wenn Sie sauber klassifizieren können, fehlen dem Fragment in einer bestimmten Dimension Informationen, was genau die Lücke ist, die später geklärt werden muss. Unsicherheiten bei der Klassifizierung notieren.

Hinweis: Die Klassifizierung nagelt die äußere Abstraktionsebene (L-Tier) und die Fähigkeitsdomäne fest, beantwortet nicht die Frage "Welche Implementierungsebenen sind intern betroffen, welcher Abteilung gehören sie an?" – das ist Sache des nächsten Schritts (Schritt 4). Eine L1-Schnittstelle kann nur die 2nd-Level-Entwicklungsschicht betreffen, aber auch den gesamten Weg bis zu Firmware/Algorithmen/Hardware.

N/A-Ausgang für L-Tier bei Nicht-Runtime-Features: Wenn das Feature seinem Wesen nach eine Liefer-/Verteilungs-/Installations-/Dokumentationsform einer bestehenden Fähigkeit ist (keine neue Runtime-Fähigkeit, stellt keine API bereit, verbraucht kein API-Budget, z.B. Offline-Installationspaket/Beispiel-Repository/Portal-Modul – Prototyp H/I), L-Tier explizit als N/A (kein Fähigkeits-Feature, fällt nur auf die Implementierungsebene-Achse) kennzeichnen, die fünf Domänen können mit N/A markiert werden, keinen L-Wert erzwingen. Entscheidungssignal: Der Liefergegenstand ist ein "Verteilungspaket/Dokument/Webseitenstruktur" und keine "Runtime-API/ein Runtime-Verhalten"; der Schwerpunkt verlagert sich auf die Build-/Distributions-Infrastruktur-Ebene oder die Dokumentationsportal-Ebene + externe Abhängigkeitsachse (Schritt 4).

Schritt 4: Ebenenübergreifende Zerlegung und Routing (für ebenenübergreifende Features obligatorisch)

Die Klassifizierung beantwortet nur "Auf welcher L-Ebene, welcher Domäne?"; dieser Schritt beantwortet weiter "Welche Implementierungsebenen sind von dieser Anforderung betroffen? Wer ist wofür auf welcher Ebene zuständig? Wer muss zuerst liefern, wer danach? Kann das Feature allein durch die 2nd-Level-Entwicklungsschicht unabhängig ausgeliefert werden?" Viele Kundenanforderungen scheinen auf der 2nd-Level-Entwicklungs-SDK-Ebene zu liegen, sind aber stark von tieferen Ebenen abhängig – Firmware/Middleware, Algorithmusdienste, sogar Hardware – und diese Ebenen gehören oft zu verschiedenen Abteilungen.

Gemäß der Entscheidungsfragen in references/cross-layer-routing.md fünf Aufgaben durchführen:

1. Ebene für Ebene prüfen, ob eine Änderung erforderlich ist: Für die vier Runtime-Ebenen (2nd-Level-Entwicklungs-SDK-Schicht / Basissoftware (Firmware·Middleware) / Algorithmusdienstschicht / Hardwareschicht) für jede Ebene fragen "Was muss auf dieser Ebene geändert werden?". Außerdem zwingend die beiden Arten von Nicht-Runtime-Ebenen prüfen (Ökosystem-/Integrations-/Dokumentations-Features haben ihren Schwerpunkt oft hier): Dokumentationsportal-Ebene (Portalbereiche, Beispiel-Repository, Dokumenten-IA – Owner ist DevRel/Dokumentation/Webseite, nicht die Entwicklung) und Build-/Distributions-Infrastruktur-Ebene (Packaging, Multi-Umgebungs-CI, ABI/Pre-Compilation – Owner ist SDK-Build/DevOps). ⚠ Wenn der Liefergegenstand Beispiel/Verpackung/Installation/Verteilung/Dokumentation ist (Prototyp H/I), auch wenn der technische Boden = reine 2nd-Level-Entwicklung, nicht standardmäßig der 2nd-Level-Entwicklungs-SDK-Gruppe zuweisen – gemäß Konfigurationsbereich Gruppe E an den entsprechenden Owner routen (gewaltsames Zuweisen zu Firmware-/Algorithmus-/Hardware-Teams oder standardmäßiges Ablegen bei der 2nd-Level-Entwicklungs-Gruppe sind beides gefährliche Fehlzuweisungen). Wenn sauber "Nur 2nd-Level-Entwicklungsschicht betroffen, keine Portal-/Infrastrukturänderungen" geantwortet werden kann, "Einzelebenen-Feature (2nd-Level-Entwicklungs-SDK)" notieren und direkt zu Schritt 5 übergehen.

2. Niedrigste Änderungsebene bestimmen (hartes Gate) + Machbarkeit widerlegen: Die niedrigste Ebene finden, die geändert werden muss. Sobald eine Ebene mit "nicht unterstützt / unsicher" antwortet, entlang 2nd-Level-Entwicklung → Firmware → Algorithmen → Hardware schrittweise nach unten gehen, bis der Boden erreicht ist (eine Ebene gefunden, die es unterstützt, oder physikalische Undurchführbarkeit festgestellt). Ein Schlussfolgerung zur Ebenenreichweite (drei Optionen) geben: A. Reine 2nd-Level-Entwicklung lieferbar / B. Ebenenübergreifend lieferbar / C. Aktuell auf dieser Ebene nicht lieferbar (untere Ebene nicht eingeplant oder physikalische Einschränkung). Wenn die niedrigste Änderungsebene nicht die 2nd-Level-Entwicklungs-SDK-Ebene ist, ist dieses Feature nicht allein durch die 2nd-Level-Entwicklungsebene unabhängig lieferbar – an prominenter Stelle im Dokument einen Warnhinweis setzen: ⚠ Nicht unabhängig von der 2nd-Level-Entwicklungsebene lieferbar: Die niedrigste Änderung dieses Features liegt auf <Ebene>, <Owner-Abteilung> muss zuerst <Fähigkeit> liefern, bevor die 2nd-Level-Entwicklungsebene kapseln kann, und dies in den Abschnitt "Fähigkeitspositionierung" und in die DoR aufnehmen. Bei Erreichen von Hardware-/physikalischen Einschränkungen sofort aufhören, auf der 2nd-Level-Entwicklungsebene Schnittstellensignaturen zu verfeinern – das Schreiben eines Entwurfsvertrags, der nicht realisierbar ist, ist ein häufiger Grund für die Ablehnung in Reviews.

3. Tabelle der ebenenübergreifenden Zerlegung + Abhängigkeitsreihenfolge + Schnittstellenvertrag zwischen den Ebenen erstellen: Auflisten, was auf jeder Ebene geändert werden muss, die verantwortliche Abteilung, ob die obere Ebene blockiert wird; die Abhängigkeitskette von unten nach oben ableiten; für jede ebenenübergreifende Abhängigkeit einen Übergabevertrag entwerfen, der festlegt, "was die untere Ebene der oberen Ebene bereitstellt" (einschließlich der Zugehörigkeit der Definitionshoheit – um zu vermeiden, dass zwei Abteilungen jeweils eine Version schreiben, die nicht übereinstimmt).

4. Owner und abteilungsübergreifende noch zu bestätigende Punkte identifizieren (jeder Punkt muss ein Zuordnungstripel enthalten): Welche Ebenen "müssen geändert werden/können unterstützt werden" können Sie selbst nicht beurteilen und müssen bei der entsprechenden Abteilung nachfragen (z.B. "Unterstützt die Firmware überhaupt Beamforming?"), als abteilungsübergreifende noch zu bestätigende Punkte auflisten. Der Benutzer dieses Skills (normalerweise Produkt-/SDK-Seite) erhält in der Konversation keine echten Antworten von den unteren Ebenen, daher nicht einfach nur [bestätigen] in die Liste setzen und abhaken – jeder Punkt muss ein Tripel enthalten: Verifizierungs-Owner (wer wendet sich an diese Abteilung) | Bis zu welchem Review-Ergebnis muss eine Antwort vorliegen | Standardannahme/Ausweichplan bei nicht rechtzeitiger Antwort (gleiches Paradigma wie bei schwellenwertbezogenen [bestätigen] Punkten mit "Verantwortlicher + Methode + Frist"). Diese sind oft die kritischen Pfadblockierer für die gesamte Anforderung.

5. Schlussfolgerung B/C obligatorisch: Tatsächlichen Liefergegenstand in die Haupterzählung zurückschreiben (um "Pseudo-Bereitschaft" zu vermeiden): Sobald die Schlussfolgerung zur Ebenenreichweite = B oder C ist, muss die Ein-Satz-Definition und die P1-Story zurückgeschrieben werden, sodass sie nur das tatsächliche Lieferobjekt dieser Runde beschreiben (z.B. "Diese Runde liefert SDK-Stub + Signatur, die tatsächliche Beam-Fähigkeit hängt von Firmware Q4 ab"), auf keinen Fall die vollständige Fähigkeit gemäß der ursprünglichen Kundenanforderung als P1 schreiben – sonst stimmt das vom Entwicklungsteam/Kunden gelesene Bereitschaftsdokument nicht mit dem tatsächlich Lieferbaren überein, und das ist die gefährlichste Art von Pseudo-Bereitschaft. Wenn die untere Ebene "nicht unterstützt und nicht eingeplant" ist, muss im Abschnitt "Ebenenübergreifende Implementierung und abteilungsübergreifende Zusammenarbeit" ein Degradierungs-/Stufenplan angegeben werden (Mock-Stub / begrenzte Stufe / Simulation zuerst), nicht nur [bestätigen].

   Frühzeitiger Ausstieg bei Schlussfolgerung C und wenn die 2nd-Level-Entwicklung in dieser Runde kein unabhängig lieferbares Objekt (einschließlich Stub) hat: Wenn die Widerlegung ergibt, dass dieses Feature eigentlich eine Änderung auf unterer Ebene/Hardware ist und die 2nd-Level-Entwicklung nicht einmal einen sinnvollen Stub bieten kann, nicht mit den Klärungsschritten 5 und 6 fortfahren (das würde nur eine leere Hülle voller [bestätigen] produzieren, die Gesprächsressourcen verschwenden und gegen die Bereichsdisziplin selbst verstoßen). Stattdessen direkt eine kompakte „Ebenenübergreifende Routing-Schlussfolgerung" ausgeben: Schlussfolgerung zur Ebenenreichweite + Ebenenübergreifende Zerlegungstabelle + Ebenenübergreifende Blockierung und Eskalationspfad + Formulierung für den Kunden, und explizit kennzeichnen: "Diese Anforderung ist derzeit keine Aufgabe für die 2nd-Level-Entwicklungsebene, wird zur Projektinitiierung an weitergeleitet."

Ausgabeform: Ein Feature = eine MD (aufgeteilt nach Lesergruppen). Unabhängig davon, ob das Feature eine einzelne oder mehrere Ebenen umfasst, jedes Feature erzeugt nur ein Anforderungsdokument; ebene-/abteilungsübergreifende Inhalte werden nicht in mehrere Dateien aufgeteilt, sondern innerhalb derselben MD nach Lesergruppen in Abschnitte unterteilt (Produkt/Review, 2nd-Level-Entwicklungs-SDK, Firmware, Algorithmen, Hardware), und am Anfang des Dokuments wird eine Leseanleitung eingefügt, die klar macht: "Lesergruppe → Welche Abschnitte sollten gelesen werden → Wofür ist diese Gruppe verantwortlich", um eine vollständige Nachverfolgung in einem Anforderungsdokument zu ermöglichen. Die Vorlagen für die nach Lesergruppen unterteilten Abschnitte und die Leseanleitung finden Sie in references/cross-layer-routing.md unter Neun.

Die Ausgabe füllt den Abschnitt Ebenenübergreifende Implementierung und abteilungsübergreifende Zusammenarbeit der Ausgabevorlage.

Das Ergebnis dieses Schritts überschreibt die Liste der in den Schritten 5 und 6 zu stellenden Fragen: Fordert der Kunde beispielsweise das set_microphone_beam_angle-Interface für Beamforming, und ergibt dieser Schritt, dass die Firmware Beamforming noch nicht unterstützt, muss in Schritt 5 zuerst geklärt werden, "ob eine Kaskadierung zu Algorithmen/Hardware akzeptabel ist und ob der Umfang dieser Runde nur darin besteht, einen SDK-Platzhalter zu erstellen", anstatt direkt nach der Schnittstellensignatur zu fragen.

Warum als separater Schritt und vor der Positionierung: Eine Anforderung, die "eigentlich die Firmware ändern muss", würde, wenn sie als normales 2nd-Level-Entwicklungs-Feature durchlaufen wird, ein Dokument produzieren, das "aussieht, als könnte das Entwicklungsteam es übernehmen, aber die tieferen Ebenen haben diese Fähigkeit nicht" – das ist die gefährlichste Fehlerart. Wenn dieser Schritt vorgezogen wird, wird vor der DoR die "Pseudo-2nd-Level-Entwicklungs-Eigenschaft" abgefangen.

**Befolgt dennoch die Interaktiven Klärungsregeln: ** Alle Owner, die Frage, ob eine Änderung einer Ebene erforderlich ist, und ob die untere Ebene unterstützt wird, sind Annahmen, diese ausnahmslos mit [bestätigen] versehen und als Klärungsfragen einzeln an den Benutzer zurückgeben (eine Frage pro Runde, mit Antwortoptionen), niemals angenommene Abteilungen/Owner/Abhängigkeiten als bestätigt in die Tabelle eintragen – dieser Schritt verleitet Sie natürlich dazu, die Owner-Tabelle auf einmal vollständig auszufüllen, aber das wäre, als würden Sie für den Benutzer entscheiden, "wer der Owner ist, welche Ebene geändert werden muss".

Schritt 5: Erste Klärungsstufe – Positionierung (grob)

Verwenden Sie die "Erste Stufe · Positionierungsdimensionen" als Checkliste, gehen Sie Punkt für Punkt durch das Fragment, listen Sie die nicht beantworteten Dimensionen auf und fragen Sie sie gemäß den Interaktiven Klärungsregeln einzeln ab. Diese Stufe legt die Form des Features fest: Was ist es? Welcher Ebene/Domäne gehört es an? Wo sind seine Grenzen? Welche Form hat es? Pro Runde nur eine Frage stellen.

Unterteilen Sie die Lücken in zwei Kategorien:

• Blockierende Lücken: Ohne sie kann nicht mit der Klassifizierung oder der Definition der Grenzen fortgefahren werden (z.B.: Für welche Rolle ist es gedacht? Was ist das Kernverhalten?).
• Nicht blockierende Lücken: Sie beeinträchtigen die Vollständigkeit, aber nicht den Hauptstrang (z.B.: Ein bestimmter Randfehlercode, die Dokumentationsform).

Schritt 6: Zweite Klärungsstufe – Funktionsdetails (fein)

Nach der Klärung der Positionierung ist die Form des Features bekannt, aber das Entwicklungsteam kann noch nicht loslegen – denn es weiß noch nicht, wie es sich "konkret verhält". Diese Stufe nutzt die "Zweite Stufe · Dimensionen der Funktionsdetails", um die Verhaltensspezifikation zu vertiefen: Wie läuft der normale Ablauf? Welche Zustände gibt es? Wie wird mit Fehlern umgegangen? Was passiert in Grenzfällen? Welche Werte haben die Parameter?

Die Fragen der zweiten Stufe müssen nach Feature-Typ variieren: Bei navigationsartigen Features nach Pfaden und Stopper-Logik fragen, bei wahrnehmungsartigen Features nach Fehlerkennung und Konfidenz, bei datenartigen Features nach Schema und Größenordnung. Die spezifische, nach Typen unterteilte Frageliste finden Sie in references/detail-probes.md – bestimmen Sie zuerst, zu welchem Prototyp das Feature gehört, und rufen Sie dann die entsprechende Sondierungsliste auf.

Schritt 7: Anforderungsdokument erstellen (einschließlich Selbstprüfungs-Gate der Produktprinzipien)

Nachdem die blockierenden Lücken geschlossen wurden, zuerst das Selbstprüfungs-Gate der Produktprinzipien durchlaufen, dann gemäß der Ausgabevorlage die Ausgabe erstellen.

Vorlagenauswahl: Reine 2nd-Level-Entwicklungseinzelfeatures mit wenigen Lücken verwenden die Kurzvostlage (Ein-Satz-Definition, Quelle und Hintergrund, Fähigkeitspositionierung, Bereich und Grenzen, Story+MVP, Verhaltensspezifikation, Schnittstellenvertrag, Abhängigkeiten, Auswirkungsanalyse, Selbstprüfung der Produktprinzipien (einzeilige Schlussfolgerung), Entscheidungsprotokoll, Offene Punkte, wobei der Abschnitt Ebenenübergreifende Implementierung und abteilungsübergreifende Zusammenarbeit und die meisten nach Bedarf NFRs übersprungen werden); ebeneübergreifende oder bedeutende Features verwenden die Vollständige Vorlage. Beide Vorlagen teilen sich denselben Satz obligatorischer Felder und dieselbe DoR.

Vor der Ausgabe obligatorisch: Selbstprüfungs-Gate der Produktprinzipien. Nehmen Sie den Abschnitt D. Produktprinzipien aus dem Konfigurationsbereich (wenn nicht ausgefüllt, die 10 integrierten Standardprinzipien aus references/product-principles.md verwenden), vergleichen Sie jedes Prinzip mit diesem Feature und geben Sie eine von drei Zustandsbewertungen ab: ✓ Konform / ⚠ Verstoß mit Kompromiss / — Nicht zutreffend. Details zu den Kriterien für die drei Bewertungen, eine Liste häufiger roter Flaggen und die Konfliktpriorität finden Sie in references/product-principles.md. Bei jeder ⚠-Bewertung muss im Abschnitt Selbstprüfung der Produktprinzipien eine Abwägung erfolgen und im Abschnitt Wichtige Entscheidungen ein Eintrag mit der Quelle "Produktprinzipienkonflikt-Abwägung" und der Angabe der betreffenden Prinzipiennummer erfolgen. Bei leichten Features, die nur ✓/— haben, kann die Selbstprüfung auf eine einzeilige Schlussfolgerung komprimiert werden, ohne die Tabelle auszubreiten.

Das Gate besteht nicht darin, dass der Skill selbst ein Häkchen setzt, sondern darin, dass nicht bestandene Punkte in Klärungsfragen oder [bestätigen]-Markierungen umgewandelt und an den Benutzer zurückgegeben werden. Bei allem, was eine Abwägung erfordert (z.B. ob eine Fähigkeit für Kompatibilität geopfert werden soll, welches Feature bei Budgetüberschreitung gestrichen wird, ob gefährliche Aktionen mit einer Berechtigungsstufe versehen werden sollen), muss nach den Interaktiven Klärungsregeln eine Frage pro Runde mit Antwortoptionen gestellt und zur Entscheidung an den Benutzer zurückgegeben werden.

Harte DoR-Anforderungen:

• Ist ein Prinzip mit ⚠ bewertet und im Dokument fehlen die entsprechende Abwägung und der Entscheidungsprotokolleintrag → DoR nicht bestanden, das Feature darf nicht als "entwicklungsteam kann übernehmen / wartet auf Review" gekennzeichnet werden.
• Ist die Schlussfolgerung zur Ebenenreichweite in Schritt 4 B oder C, verspricht die Ein-Satz-Definition oder die P1-Story jedoch immer noch die vollständige, auf den unteren Ebenen nicht bereite Fähigkeit → DoR nicht bestanden (es muss zuerst gemäß Schritt 4, Punkt 5 auf den tatsächlichen Liefergegenstand zurückgeschrieben werden).

Nach bestandenem Gate das Dokument gemäß der ausgewählten Vorlage generieren und in das Standard-Ausgabeverzeichnis feature-specs/<Feature-Name>/<Feature-Name>.md schreiben (nicht nur im Chat anzeigen; die Verzeichnisvereinbarung finden Sie in der Ausgabevorlage); die noch nicht gelösten, nicht blockierenden Lücken in den Abschnitt Offene Punkte setzen und die betroffenen Felder im Haupttext mit [bestätigen] markieren, niemals erfinden.

Warum zwei Stufen in zwei Durchgängen: Zu viele Fragen in einer Sitzung ermüden (siehe Obergrenze der Gesamtmenge in den Klärungsregeln). Es wird empfohlen, nach der ersten Stufe (Schritt 5) eine Version zu erstellen, die "positioniert, aber Verhalten noch ergänzungsbedürftig" ist, und die zweite Stufe (Schritt 6) als nachfolgenden Vertiefungsdurchgang zu nutzen, um die Verhaltensspezifikation zu vervollständigen und auf die entwicklungsreife Version 1.0 zu aktualisieren. Beide Stufen halten sich an ihre jeweilige Obergrenze und beißen sich nicht gegenseitig. Wenn die Anforderung sehr klein ist und nur wenige Lücken hat, können beide Stufen auch in einem Durchgang abgeschlossen werden.

---

Erste Stufe · Positionierungsdimensionen (grob)

Bestimmen der "Form" des Features. Gehen Sie das Fragment Punkt für Punkt durch; was fehlt, muss geklärt werden. Aufgeteilt in zwei Gruppen.

Gruppe A · Wesen der Anforderung (Was / Warum / Grenzen)

1. Rolle und Szenario: Wer verwendet es? In welchem Szenario wird es ausgelöst? (Endbenutzer / Integratorentwickler / Betrieb…)
2. Kernverhalten: Welche spezifische Aktion führt diese Funktion aus? Welche Eingabe, welches Ergebnis?
3. Bereich und Grenzen: Was ist enthalten, was ist explizit nicht enthalten (dieser Punkt wird am leichtesten übersehen und kann am besten verhindern, dass das Entwicklungsteam den Umfang selbst ergänzt).
4. Erfolgskriterium: Wann gilt es als "richtig gemacht"? Welches beobachtbare Maß wird verwendet?

Gruppe B · SDK-Engineering-Positionierung

5. Zugehörigkeit zur Fähigkeitsebene: Auf welcher L1/L2/L3-Ebene liegt es?
6. Positionierung in den fünf Domänen: Zu welcher Fähigkeitsdomäne gehört es? Domänenübergreifend? Wen betrifft die Domänenüberschneidung?
7. Schnittstellenauswirkung: Welche Schnittstellen müssen hinzugefügt/geändert werden? Wird das API-Budgetlimit überschritten?
8. Basisabhängigkeiten: Von welchen bestehenden Fähigkeiten ist es abhängig? Welche existieren noch nicht und müssen zuerst aufgebaut werden?
9. Anwendbare Form: Simulation, echtes Gerät oder beides? Die Abnahmekriterien können sich unterscheiden.
10. Integratorverfügbarkeit: Für welche Integratorstufe ist es gedacht? Die entsprechende Kapselungs-/Dokumentationskomplexität ist unterschiedlich.
11. Rückwärtskompatibilität: Zerstört es bestehende Schnittstellenvereinbarungen? Ist eine Versionierung oder ein Migrationspfad erforderlich? Wenn ein Break festgestellt wird, muss nebenbei geklärt werden, welche betroffenen Bestandsintegratoren/versionsbereiche es gibt und welcher akzeptable Abkündigungszeitraum gilt – nicht nur "ob Break" notieren.
12. Dokumentations- und Zertifizierungsauswirkungen: Ist neue Entwicklerdokumentation erforderlich? Fällt es in den Prüfungsbereich der Integratorzertifizierung?
13. Sicherheit und Berechtigungen (einschließlich physischer Modifikationen): Für welche Integratorstufe/Rolle ist diese Fähigkeit freigegeben? Betrifft es gefährliche oder hochprivilegierte Aktionen? Es gibt zwei Arten von Sicherheitsrisiken, beide müssen einmal zwingend abgefragt werden, nicht standardmäßig freigeben –
    • Gefährliche Softwareaufrufe: Geschwindigkeits-/Drehmomentgrenzen entsperren, Not-Aus aufheben, direkte Chassis-/Gelenksteuerung, Sicherheitszäune überwinden → Fragen "Wer darf aufrufen? Ist eine doppelte Bestätigung/Überwachung/Berechtigungsstufe erforderlich?".
    • Gefährliche physische Modifikationen (Hardware-Endeffektor/Modifikations-Features, Prototyp J): Der Kunde schließt selbstgebaute Hardware an einen Roboter an, der sich bewegt und verletzen kann → Fragen nach Gewichts-/Drehmoment-/Stromversorgungs-Grenzen und Folgen einer Überschreitung, verbotenen Änderungsbereichen (welche Schnittstellen, wenn geändert, heben Not-Aus/Sicherheitsmechanismen auf), ob nach Änderung des Endeffektors eine Last-Neukalibrierung erforderlich ist, Modifikationsberechtigungs-/Qualifikationsschwellen, Garantie- und Haftungsgrenzen, Haftungsausschluss- und Compliance-Erklärungen, Umfang der freigegebenen Informationen (Rollendifferenzierung/Gating). Eine falsche physische rote Linienzahl = Personensicherheit + rechtliche Haftung.

---

Zweite Stufe · Dimensionen der Funktionsdetails (fein)

Bestimmen, wie sich das Feature "konkret verhält". Dies ist der Schlüssel, um die Anforderung wirklich entwicklungsreif zu machen – wenn nicht jede der folgenden Dimensionen klar ist, muss das Entwicklungsteam bei der Umsetzung selbst entscheiden. Dies sind allgemeine Dimensionen, die anhand der Feature-Typen aus references/detail-probes.md mit typspezifischen Sonden konkretisiert werden.

1. Normalablauf Schritt für Schritt: Das Kernverhalten in geordnete Schritte zerlegen, mit Eingabe, Ausgabe und Vorbedingung pro Schritt.
2. Zustände und Lebenszyklus: Welche Zustände gibt es? Wie erfolgt der Zustandsübergang? Die Semantik von start / pause / resume / stop / cancel und welche Operationen in welchem Zustand erlaubt sind.
3. Auslöser und Vorbedingungen: Unter welchen Bedingungen kann es gestartet werden? Voraussetzungen an System/Ressourcen? Wie wird mit wiederholtem und gleichzeitigem Auslösen umgegangen?
4. Fehler- und Ausnahmebehandlung: Für jeden Schritt mögliche Fehlerpunkte auflisten und einzeln Gegenmaßnahmen festlegen – Wiederholung / Degradierung / Abbruch / Meldung, sowie wer sich darum kümmert und wie der Zustand abgeschlossen wird.
5. Grenz- und Randfälle: Verhalten bei Leereingabe, Extremwerten, Unterbrechung, Ressourcenknappheit (Akku/Rechenleistung), plötzlichen Änderungen der äußeren Bedingungen.
6. Parameterdetails: Für jeden konfigurierbaren Parameter: Einheit, Wertebereich, Standardwert, Validierung bei ungültigen Werten.
7. Zeit- und Leistungsbeschränkungen: Antwortzeit, Timeout-Schwellwert, Durchsatz, Echtzeitanforderungen.
8. Parallelität und Wiedereintrittsfähigkeit: Können mehrere Instanzen parallel betrieben werden? Was passiert, wenn der Aufrufer dieselbe Schnittstelle mehrfach aufruft?
9. Beobachtbarkeit: Welche Zustandsabfragen, Ereignisse/Rückrufe, Protokolle oder Metriken benötigt der Aufrufer, um den Betriebszustand des Features zu erfassen. Die Beobachtbarkeit muss auf zwei Ebenen erfragt werden – aufruferorientiert (Zustandsabfragen/Ereignisrückrufe/lokalisierbare Protokolle, die dem Integrator dienen, um den Betriebszustand zu erfassen) und plattformbetriebsorientiert (welche Metriken/Instrumentierungsdaten werden nach der Bereitstellung verwendet, um die Gesundheit, Akzeptanzrate und Fehlerverteilung dieses Features zu beurteilen, dienen der Fehlerbehebung und Entscheidungsfindung), letztere wird oft vergessen.

Es ist nicht notwendig, alle 9 Punkte vollständig abzufragen. Entscheiden Sie, welche für dieses Feature kritisch sind (Fehlerbehandlung ist für langlaufende Aufgaben fast immer kritisch, Parameterdetails können für reine Abfragen leichtgewichtig sein). Fragen Sie die kritischen Punkte ab, lassen Sie den Rest vernünftigerweise als Standard oder markieren Sie ihn mit [bestätigen].

Drei orthogonale Achsen, die überlagert werden können: Die obigen neun Dimensionen + die "Feature-Prototypen A~J" aus detail-probes sind eine Achse, die nach Feature-Typ schneidet (H = Ökosystem-Integration/Referenzimplementierung/Dokumentation; I = Verpacken/Verteilen/Offline-Installation/Bereitstellung; J = Hardware-Endeffektor/physikalische Schnittstellenspezifikation und Modifikationsdokumentation, der externe Vertrag sind mechanische/elektrische physikalische Schnittstellen); ob ein Feature auch ebenenübergreifend zerlegt werden muss (Ebenen außerhalb der 2nd-Level-Entwicklung betroffen, einschließlich der beiden Nicht-Runtime-Ebenen "Dokumentationsportal-Ebene / Build·Distributions-Infrastruktur-Ebene" sowie der externen Abhängigkeits-/EOL-Achse) ist die zweite Achse, siehe Schritt 4 und references/cross-layer-routing.md; welche nicht-funktionalen Anforderungen (NFR) und Produktprinzipien durchlaufen werden müssen, ist die dritte Achse, siehe references/product-principles.md. Die drei ersetzen einander nicht, bei Überschneidung werden sie überlagert.

---

Interaktive Klärungsregeln

Dies ist der Motor, der "einfach" in "vollständig" verwandelt. Bitte beachten:

• Eine Frage pro Runde. Nach dem Stellen einer Frage anhalten, auf die Antwort des Benutzers warten, dann die nächste Frage stellen. Nicht mehrere Fragen auf einmal stellen.
• Blockierende zuerst. Zuerst blockierende Lücken abfragen (Rolle, Kernverhalten, Bereich und Grenzen, Fähigkeitszugehörigkeit), dann nicht blockierende.
• Jede Frage mit "Warum wird gefragt" und Antwortmöglichkeiten. Beispiel: "Welche Rolle bedient diese Funktion hauptsächlich? (Dies bestimmt, auf welcher Ebene sie gekapselt werden sollte) A. Direkt vom Endbenutzer verwendbar B. Vom Integrator zur Weiterentwicklung verwendbar C. Für interne Tests verwendbar". Die Angabe von Antwortmöglichkeiten senkt den Antwortaufwand erheblich, der Benutzer kann auch "keines der oben genannten" wählen und ergänzen.
• Gesamtmenge kontrollieren, Ermüdung vermeiden. Pro Stufe in einer Sitzung möglichst nicht mehr als 7~8 Fragen stellen (die beiden Stufen zählen unabhängig voneinander, sie beißen sich nicht gegenseitig). Wenn zu viele Lücken vorhanden sind, zuerst die blockierenden ergänzen, den Rest mit [bestätigen] markieren und den Benutzer darauf hinweisen, dass die restlichen Punkte markiert sind und später ergänzt werden können. Besonders die zweite Stufe (Detailfragen) kann schnell die Menge überschreiten, wählen Sie die für dieses Feature kritischen Fragen aus.
• Nach jeder Antwort paraphrasieren und bestätigen. Nach der Antwort des Benutzers das Verständnis in einem Satz paraphrasieren, bevor fortgefahren wird, um sicherzustellen, dass nichts falsch verstanden wurde.
• Nie eigenmächtig für den Benutzer entscheiden. Fragen, die eine Abwägung erfordern (ob eine Grenze implementiert wird, welche Form verwendet wird, wer der Owner ist, welche Ebene geändert werden muss), müssen gestellt werden, nicht als Standard annehmen. "Noch nicht Bestätigtes" explizit als [bestätigen] markieren, nicht stillschweigend einen plausiblen Wert eintragen.

---

Schreib- und Lesbarkeitsregeln (Ausgabe muss erfüllen)

Das Anforderungsdokument ist für Menschen geschrieben, die es im Review prüfen – nicht nur, um die Gedankenpunkte zusammenzutragen. Vor der Ausgabe anhand dieser drei Punkte prüfen:

• In verständlicher Sprache, logisch kohärent. Sätze flüssig, Absätze mit roter Linie, nicht Fragmente zusammenstellen, wie sie in den Sinn kommen. Beim ersten Auftreten eines Fachbegriffs/Abkürzung entweder kurz erklären oder im "Glossar" sammeln – den Leser nicht über unbekannte Begriffe stolpern lassen. Lieber einen zusätzlichen Satz in einfacher Sprache als einen Fachjargon.
• Gesamthintergrund + Rollenabschnitte + Glossar, Dreiteilung. Ein Dokument = ① Gesamthintergrund (alle lesen zuerst: Was ist das? Warum? Für wen? Was wird geliefert? = Ein-Satz-Definition + Quelle und Hintergrund + Glossar) + ② Rollenabschnitte (die Leseanleitung teilt die nachfolgenden Abschnitte nach Lesergruppen auf, jede Rolle liest nur ihren Teil, kein Team soll in für ihn irrelevanten Details ertrinken) + ③ Glossar (Fachbegriffe separat erklären, für diejenigen, die sie nicht verstehen).
• Externen Lieferumfang festlegen, interne technische Details freigeben. Die Anforderung nagelt "was extern geliefert wird" fest – Schnittstellensignatur, Produktform, Liefergegenstandsform, unterstützte Plattformen/Umgebungen, Abnahmekriterien; aber sie schreibt nicht übermäßig vor, "wie intern implementiert wird" – welche Bibliothek, welche Architektur, welches Build-/Compilertool, das bleibt dem Entwicklungsteam überlassen. Bei jedem geschriebenen Satz sich fragen: "Ist das ein externer Vertrag oder eine interne Implementierung?" Wenn es eine interne Implementierung ist, durch "durch Entwicklungsteam festzulegen" ersetzen oder auf "Empfehlung (nicht zwingend)" herabstufen, die Anforderung nicht als Designvorschlag schreiben.
• Einfache Sprache für Verständlichkeit, nicht für Unschärfe – externe Verträge müssen präzise sein. Den Text in einfacher Sprache, aber alles, was externe Ausgabestandards betrifft – Schnittstellendefinition (Signatur/Parameter/Rückgabe/Fehler), Nachrichten- und Datenformate, unterstützte Plattformmatrix vollständig pro Zelle auflisten, Liefergegenstandsform, Abnahmekriterien – muss präzise, unmissverständlich und anhand derer überprüfbar sein, bei Bedarf Signaturen angeben, Matrix vollständig auflisten. Verständlichkeit ja, Vertrag nicht aufweichen. Bei der Gliederung nach Rollen die präzisen Verträge in die Kategorie "Externer Vertrag" zusammenfassen, damit Entwicklung/Test sie umsetzen und verifizieren können.

Ausgabevorlage

Nachdem die blockierenden Lücken geschlossen wurden (und das Selbstprüfungs-Gate der Produktprinzipien in Schritt 7 bestanden wurde), streng nach dieser Vorlage ausgeben. Die Vorlage enthält eine Definition of Ready (DoR) – nur wenn jeder Abschnitt ausgefüllt (oder explizit mit [bestätigen] markiert) ist, gilt die Anforderung als "entwicklungsteam kann übernehmen".

Vereinbarungen:

• Abschnitte werden nicht mehr nummeriert, konsistent nach Abschnittsnamen referenziert, um eine Verschiebung der Abschnittsnummern beim Einfügen von Abschnitten zu vermeiden.
• Kurzvostlage = die gleichen Abschnitte wie die Vollständige Vorlage, jedoch ohne den Abschnitt Ebenenübergreifende Implementierung und abteilungsübergreifende Zusammenarbeit und ohne optionale NFR-Dimensionen; für reine 2nd-Level-Entwicklungseinzelfeatures; Vollständige Vorlage für ebenenübergreifende oder bedeutende Features.
• Schnittstellen-/Parameternamen durchgängig: Nur Kleinschreibung mit Unterstrich (snake_case), semantisch vollständig und präzise, keine Abkürzungen (z.B. mic→microphone, cfg→config, num→count) und mit bestehenden Schnittstellen derselben Domäne konsistent.
• Ein Dokument trägt nur ein Feature, und ein Feature erzeugt nur eine MD-Datei; mehrere Features werden unabhängig voneinander dokumentiert (niemals zusammengeworfen), aber ein Feature wird auch bei Ebenenüberschreitung nicht in mehrere Dateien aufgeteilt – ebene-/abteilungsübergreifende Inhalte werden innerhalb derselben MD nach Lesergruppen in Abschnitte unterteilt.
• Ausgabeort (Standard-Ausgabeverzeichnis, muss eingehalten werden): Die Ausgabe wird in eine Datei geschrieben (nicht nur im Chat angezeigt) – im Ausgabeverzeichnis feature-specs/<Feature-Name>/<Feature-Name>.md (relativ zum aktuellen Arbeitsverzeichnis/Repository-Stamm; Standard-Stammverzeichnis feature-specs/, kann vom Team im Konfigurationsbereich geändert werden). Ein Feature, ein Unterverzeichnis (zur Aufnahme von zugehörigen Abbildungen/Unterergebnissen), Dateiname = Feature-Name. Mehrere Features haben jeweils eigene Unterverzeichnisse; verwandte Features verweisen mit relativen Links aufeinander.
• Ebenenübergreifende Features (Schlussfolgerung B/C): Am Anfang dieser Vorlage eine Leseanleitung (nach Lesergruppen) einfügen und im Abschnitt Ebenenübergreifende Implementierung und abteilungsübergreifende Zusammenarbeit die Inhalte der einzelnen Ebenen nach dem Schema "Lesezielgruppe: Gruppe X" in Abschnitte unterteilen (Vorlage siehe references/cross-layer-routing.md Neun) – alles innerhalb dieser einen MD-Datei, keine separate Datei.

# Feature-Anforderung: [Feature-Name]

> Status: Entwurf / Wartet auf Review / Bestätigt | Eingebracht von: [Kunde/Partner] | Datum: YYYY-MM-DD | Vorlage: Vollständig / Kurz

## Leseanleitung (nach Lesergruppen)
> **Wie lesen**: Zuerst den **Gesamthintergrund** lesen (_Ein-Satz-Definition_, _Quelle und Hintergrund_, _Glossar_, alle lesen); die restlichen Abschnitte gemäß der folgenden Tabelle **nur für die eigene Gruppe lesen**, nicht das gesamte Dokument. Für ebenen-/abteilungsübergreifende Features ist diese Tabelle obligatorisch; für reine Einzelebenen-Features kann die Tabelle verkürzt werden, aber der Gesamthintergrund und das _Glossar_ müssen vorhanden sein.
| Lesergruppe | Welche Abschnitte | Wofür verantwortlich |
| --- | --- | --- |
| Produkt / Review | Ein-Satz-Definition, Quelle & Hintergrund, Fähigkeitspositionierung, Bereich & Grenzen, Story+Abnahme, Auswirkungsanalyse, Produktprinzipien-Selbstprüfung, Entscheidungen, Offene Punkte | Bereich/Priorität/Kompromisse bestätigen |
| 2nd-Level-Entwicklungs-SDK | Schnittstellenvertrag, Verhaltensspezifikation, _Ebenenübergreifende Implementierung · SDK-Abschnitt_ | Externe Kapselung & Schnittstellenvertrag |
| Firmware | _Ebenenübergreifende Implementierung · Firmware-Abschnitt_, Ebenenübergreifender Übergabevertrag | Schnittstellen der unteren Ebene bestätigen/freigeben |
| Algorithmen | _Ebenenübergreifende Implementierung · Algorithmen-Abschnitt_ | Algorithmusfähigkeiten bereit/anpassen |
| Hardware | _Ebenenübergreifende Implementierung · Hardware-Abschnitt_ | Hardwareform/physikalische Grenzen |
| Test / QA | Abnahmekriterien, Externer Vertrag (Schnittstellen/Nachrichten/Plattformmatrix), Zu bestätigende Punkte | Tests gemäß Abnahmekriterien & Vertrag entwerfen, alle Plattformmatrizen abdecken |
(Rollen **nach Feature-Typ wählen**: Runtime-Features = Implementierungsebenen; Liefer-/Integrations-/Installations-Features = Packaging·DevOps/Dokumentation/Test usw. **Test/QA immer als eine Rolle aufnehmen** – es betrifft, wie die Abnahme getestet wird, welche Plattformen abgedeckt werden müssen, ob der externe Vertrag testbar ist. Nicht betroffene Rollenzeilen komplett löschen. **Haupttext möglichst nach Rollen gliedern**, damit jede Rolle ihren Teil in einem Block lesen kann.)

## Ein-Satz-Definition
[Was – Was macht dieses Feature, in einem Satz klar beschreiben. ⚠ Wenn die Schlussfolgerung zur Ebenenreichweite in Schritt 4 B oder C ist, hier nur das tatsächliche Lieferobjekt dieser Runde beschreiben, nicht die vollständige, auf den unteren Ebenen nicht bereite Fähigkeit]

## Quelle und Hintergrund (Warum)
- Ursprünglicher Wunsch: [Das erste Zitat des Kunden/Partners, sinngemäß erhalten]
- Geschäftsszenario: [Wer, in welchem Szenario, welches Problem lösen]
- Wert: [Warum es sich zu tun lohnt]

## Glossar (Fachbegriffe)
> Fachbegriffe/Abkürzungen, die im Dokument verwendet werden und für Leser außerhalb des Fachgebiets unverständlich sein könnten, jeweils einen Satz in einfacher Sprache erklären (für verschiedene Rollen, nicht davon ausgehen, dass alle sie verstehen); wenn keine unbekannten Begriffe, "Keine" schreiben.
| Fachbegriff | Erklärung in einem Satz |
| --- | --- |
| … | … |

## Fähigkeitspositionierung
- Ebene: L1 / L2 / L3 [Wenn Konfigurationsbereich Gruppe A nicht ausgefüllt, `[bestätigen]` setzen; **bei Liefer-/Verteilungs-/Installations-/Dokumentations-Features (Nicht-Runtime) `N/A (kein Fähigkeits-Feature, fällt nur auf die Implementierungsebene-Achse)` setzen**]
- Fähigkeitsdomäne: [Eine der fünf Domänen, oder "Domänenübergreifend: X + Y", oder N/A]
- Domänenübergreifende Auswirkung: [Welche anderen Domänen/Teams werden betroffen?]
- Ebenenübergreifende Schlussfolgerung (Schritt 4): Einzelebenen-Feature (2nd-Level-Entwicklungs-SDK) / ⚠ Nicht unabhängig von der 2nd-Level-Entwicklungsebene lieferbar: Niedrigste Änderung auf <Ebene>, <Abteilung> muss zuerst <Fähigkeit> liefern, bevor die 2nd-Level-Entwicklungsebene kapseln kann

## Bereich und Grenzen
- In Scope:
  - …
- Out of Scope (Explizit nicht enthalten):   ← Obligatorisch, verhindert, dass das Entwicklungsteam den Umfang erweitert
  - …
- Platzhalter für verwandte Features (aus Anforderungsaufteilung, werden in dieser Runde nicht gemacht):
  - …

## Ebenenübergreifende Implementierung und abteilungsübergreifende Zusammenarbeit
> Nur obligatorisch, wenn in Schritt 4 festgestellt wurde, dass dieses Feature mehrere Implementierungsebenen umfasst (über die 2nd-Level-Entwicklungs-SDK-Ebene hinaus); reine 2nd-Level-Entwicklungseinzelfeatures schreiben "Einzelebenen-Feature (2nd-Level-Entwicklungs-SDK), keine abteilungsübergreifende Zusammenarbeit" und überspringen diesen Abschnitt (die Kurzvostlage enthält diesen Abschnitt nicht standardmäßig).
> **Ausgabeform:** Ein Feature erzeugt nur eine MD-Datei; dieser Abschnitt enthält

…

[Der Rest der Vorlage folgt sinngemäß, aber aufgrund der Länge hier abgebrochen.]