# Auftrag: Feature-Sicht und Kern aggregieren Unten stehen alle Einheiten des Projekts `` (ID + Ein-Satz-Beschreibung). Aggregiere daraus die **Feature-Sicht** (was kann das Projekt aus Betreibersicht?) und den **Kern** (was trägt das Projekt?). Beschreibe NUR, was die Einheiten belegen — erfinde nichts aus Weltwissen. WICHTIG — Zielgruppe ist die GESCHÄFTSFÜHRUNG, nicht Entwickler: - Beschreibe, WAS das Produkt kann und WOZU es gut ist — NIE, wie es im Code umgesetzt ist. - Verboten: Code-Begriffe und Jargon (Funktions-/Modul-/Dateinamen, Backticks, Wörter wie Präfix, Spawn, Semaphore, CLI, Cache, Payload, Thread, Lock, Registry, Callback, Endpoint). Wenn du so ein Wort brauchst, beschreibe stattdessen die Wirkung in Alltagssprache. - Titel und Sätze so, dass sie jemand ohne Programmierkenntnisse sofort versteht. Beispiel: statt „Markiert einen Schlüssel-Präfix global als abgebrochen" → „Laufende Arbeiten lassen sich gezielt stoppen". - Die `einheiten:`-Referenzzeilen bleiben unverändert technisch (exakte IDs) — sie sind Maschinen-Verweise, keine Leser-Texte. ## Ausgabeformat (exakt einhalten; zuerst der Kern, dann die Bereiche) ``` # Kern: <2-4 Sätze: wofür das Projekt existiert und was es im Kern tut> tragende-einheiten: , , … # Bereich: beschreibung: ## Feature: [kern|rand] beschreibung: ### einheiten: , ``` Regeln: - 3–10 Bereiche; MECE je Ebene: Bereiche zerlegen das Projekt, Features ihren Bereich, Teilfeatures ihr Feature — vollständig, überschneidungsfrei. - Braucht ein Titel „und", mach zwei Bereiche/Features daraus. - `[kern]` = trägt das Projekt, `[rand]` = Komfort/Beiwerk. - `einheiten:` listet NUR IDs, die unten wirklich vorkommen (exakte Schreibweise); jedes Teilfeature hat mindestens eine. Jede Einheit sollte in mindestens einem Teilfeature auftauchen; reine interne Helfer dürfen unreferenziert bleiben. - Schreibe auf Deutsch. Gib NUR das Markdown aus, ohne Code-Fences drumherum. ## Einheiten von ``