Auswertung Store-Review 2026-09-08: offene Modellpunkte (Glossar, Requirements, Use Cases)

[hauschel]

Anlass

Auswertung des Store-Reviews vom 2026-09-08 (docs/store-review-2026-09-08.md) am 2026-09-09. Was mechanisch eindeutig war, ist direkt im Store korrigiert; was eine Werkzeug- oder Metamodell-Anderung braucht, steht in #585 bis #589 und kogn-io/arknet-plugin#178. Was bleibt, braucht Modellarbeit oder eine Entscheidung und steht hier als eine Liste, damit es nicht in zwolf Einzel-Issues zerfallt. Gleicher Zuschnitt wie #572, das die Vorrunde tragt.

Bereits erledigt (2026-09-09, nicht mehr Teil dieses Issues): broader:TERM-14 fur TERM-10/11/13/19/27/28/31 nachgezogen (G3); die fehlenden Kanten der ADR-Familie TERM-29 <-> TERM-30/31 und der Use-Case-Familie TERM-27 <-> TERM-10/11/13 gesetzt (G4, G5); die Fehlverknupfung FR-5 -> TERM-30 (Consequence fur das Alltagswort "Konsequenz") gelost; FR-6 -> TERM-16 (Group Actor) nachgezogen.

Punkte

1. Glossar-Zirkel im Zentrum (G1). TERM-1 (Metamodell) definiert sich uber "Modell", TERM-12 (Architekturmodell) uber "Metamodell", TERM-12 uber "Ressourcen" und TERM-14 uber "Architekturmodell". Zwei geschlossene 2er-Zirkel; ein Leser, der keinen der drei Begriffe kennt, kommt nirgends heraus. Ein Anker ausserhalb (was ist ein Modell?) fehlt.
2. "Domain" fehlt als Term (G2). arkddd:Domain ist eine modellierte Klasse, arkddd:Subdomain rdfs:subClassOf arkddd:Domain, und arknet-shapes.ttl verlangt fur jeden BoundedContext ein partOf auf Domain oder Subdomain. Trotzdem gibt es keinen Term. TERM-33 definiert Subdomain gegen "Gesamtdomane", TERM-19 gegen "Domanenmodell" -- beides undefinierte Worter.
3. Drei Definitionen nennen das Produkt (G8). TERM-1, TERM-12 und TERM-17 definieren uber "mit arknet erstellt/erfasst/beschrieben". Ein Metamodell, ein Architekturmodell und ein Projekt sind keine arknet-Begriffe; die Werkzeugbindung macht die Definition gegenuber dem Werkzeug zirkular. Leicht zu heilen.
4. TERM-23 Dataset und TERM-26 Component gehoren so nicht ins Glossar (G9). Dataset definiert sich uber Speichereinheit, Abfragegrenze und reservierte Registry -- drei Architekturentscheidungen in einer Bedeutungsdefinition. Component hat uberhaupt keine Gattung und keine Ontologie-Klasse. Von allen 27 ist TERM-26 die einzige Definition, die die Grundregel (Gattung + unterscheidendes Merkmal) formal verfehlt.
5. Kleinere Glossarbefunde (G6, G7, G10, G12, G13, G14). Actor-Geschwister asymmetrisch verkantet und redundant zur gemeinsamen broader-Kante; funf doppelt gefuhrte Abgrenzungslisten; "Anforderung" vs. "Requirement" in derselben Sprache (TERM-21); TERM-33 sagt "Core/Supporting/Generic Subdomain", die Ontologie labelt "Core Domain" usw.; TERM-11 Constraint zu eng definiert (haengt im Modell auch an Use Cases); funf externe Bedeutungskollisionen ohne Abgrenzung (Resource/Dataset/Constraint/Component/Actor), wo TERM-17 Project das Vorbild ist.
6. Fehlende tragende Begriffe. "Status" und "Prioritat" (zentral in FR-1/3/5, kein Term), "Sprachbruch" (das einzige Kriterium von FR-9), "Modellbestand"/"Leseflache" (FR-8).
7. Redundanz im Requirement-Korpus. "Eine Anderung/Verknupfung ist unabhangig vom Status moglich" steht in FR-3, FR-4 und (aus der Gegenrichtung) FR-5 AC6; "denselben Detailgrad wie das gezielte Nachschlagen" in FR-2 AC1 und FR-8 AC4; Zweck-/Begrundungssatze stehen in der description von FR-4 und NFR-1, obwohl rationale dasselbe sagt oder leer ist.
8. FR-2 widerspricht sich intern. Die description bindet das Nachschlagen an den Business-Code, rationale und AC4 setzen mehrere Kennungsformen samt Mehrdeutigkeitsprufung voraus.
9. FR-7 gegen FR-1/FR-3. FR-7 fordert die Herkunft als Feld eines Requirements; FR-1 und FR-3 zahlen die Felder beim Anlegen und Andern auf und lassen sie beide aus. (Werkzeugseite: Herkunftskante vom Requirement zur Rolle (FR-7) #345.)
10. Rollen und Use Cases decken nur den Requirement-Lifecycle. ROLE-2 (Architect) und ROLE-3 (DDD Practitioner) treiben keinen Use Case und tragen kein Requirement; ROLE-4 (Coding AI Agent) ist in UC1 allein primar und verdeckt dort den Bedarfstrager. Sechs von elf Requirements haben keinen realisierenden Use Case, kein UC nennt ein NFR. Uberschneidet sich mit Modell: Use Cases des eigenen arknet-Modells vollständig erfassen (Architect, DDD Practitioner, Requirements ohne UC) #579 und Modell: die Plugin-Skills als Requirements und Use Cases des Produkts arknet erfassen #577 -- dort wird der Bestand erganzt, hier geht es um die Schieflage der vorhandenen vier.
11. Null Constraints, wahrend funf Requirements Verhalten an ihnen zusagen. FR-2 verspricht Nachschlagen und Auflisten, FR-3/4/5 sichern zu, dass Constraint-Verknupfungen unangetastet bleiben. Kein einziges Exemplar, kein erzeugendes Requirement -- die Zusagen sind an keiner Instanz je abgenommen worden.
12. Use-Case-Befunde (8.3 des Berichts). scope ist in allen vier UCs leer; UC1/2/3 tragen den Namen der Systemoperation statt eines Rollenziels; die Extension "Business-Code existiert nicht" steht dreimal nahezu wortgleich; die Fehlerbilder aus FR-1/2/3/4 haben kein Gegenstuck im Ablauf.

Ursache und Vorbeugung

Die Punkte 1-6 haben dieselbe Ursache: das Glossar ist gewachsen, wahrend die Ontologie sich anderte, und ein Begriff wurde jeweils dort definiert, wo er gebraucht wurde -- gegen die Nachbarbegriffe, nicht gegen einen Anker ausserhalb. Vorbeugung ist keine neue Regel, sondern der Full-Set-Durchgang von /arknet:req-interview, der genau diese Klasse findet, und die Ontologie als Quelle statt der Prosa (Punkt 2 ware beim grep in die Vokabular-Quelle sofort aufgefallen).

Die Punkte 7-12 entstehen daraus, dass Requirements und Use Cases je einzeln erhoben und nie als Menge gelesen wurden. Kein Werkzeug findet eine Aussage, die an drei Stellen steht; das findet nur ein Leser, der den ganzen Bestand am Stuck liest. Vorbeugung ist die Kadenz: /arknet:store-review regelmassig fahren, nicht ein weiterer Check.

Fertig, wenn

Jeder Punkt entweder im Store umgesetzt oder mit Begrundung verworfen ist.