Anlass
Entscheidung aus #572 Punkt 4 (2026-09-08): Das Projekt arknet im Store ist das Produkt im Sinne von TERM-17 (System-of-Interest), nicht das Service-Repository. Das Claude-Code-Plugin (kogn-io/arknet-plugin) gehört damit zum modellierten System, sein Repository wird zweiter Anker des Projekts arknet (blockiert durch #576, weil der Pfad heute am Projekt arknet-plugin hängt). FR-9 (Bounded-Context-Audit nur an Sprachbrüchen) bleibt deshalb im Projekt arknet.
Das Modell trägt heute nur diese eine Anforderung an das Plugin. Die übrigen Skills (/arknet:adr, /arknet:req-interview, /arknet:context-map, /arknet:health-check, /arknet:init) und ihre Regeln (z.B. "der Skill schreibt erst nach bestätigtem, testbarem Verständnis", "health-check schreibt nie", "init wählt zwischen project_add/adopt/attach_anchor, weil ein Fehlgriff ein zweites Projekt anlegt") stehen nur in den SKILL.md-Dateien, nicht als Requirements, Akzeptanzkriterien oder Use Cases im Store.
Was zu tun ist
- Je Skill prüfen, welche Zusagen ein Requirement mit Akzeptanzkriterien sind (req_add, de+en) und welche Abläufe ein Use Case mit Rollen sind (uc_add, de+en); Rollen aus dem Actor-Register (ROLE-N), fehlende Rollen ergänzen.
- Bestehende Requirements (FR-9) und Use Cases einhängen (realises, usesTerm), Glossarbegriffe nachziehen, wo ein Skill Vokabular einführt, das das Glossar nicht kennt.
- Ergebnis gegen
orphan_check, trace_matrix und store_check prüfen.
Zusammenhang: #572 Punkt 5 (Rollen Architect/DDD Practitioner ohne Use Case) löst sich vermutlich zu einem großen Teil hier, weil die Skills genau diese Rollen bedienen.
Fertig, wenn
Jeder ausgelieferte Skill des Plugins auf mindestens ein Requirement mit Akzeptanzkriterium und einen Use Case im Projekt arknet zurückführbar ist und die Aufnahme in beiden Sprachen vorliegt.
prio:medium -- entscheidet, ob das eigene Modell das Produkt beschreibt oder nur den Service; reine Modellarbeit im Store, kein Code, darum Bahn Produkt.
Anlass
Entscheidung aus #572 Punkt 4 (2026-09-08): Das Projekt
arknetim Store ist das Produkt im Sinne von TERM-17 (System-of-Interest), nicht das Service-Repository. Das Claude-Code-Plugin (kogn-io/arknet-plugin) gehört damit zum modellierten System, sein Repository wird zweiter Anker des Projektsarknet(blockiert durch #576, weil der Pfad heute am Projektarknet-pluginhängt). FR-9 (Bounded-Context-Audit nur an Sprachbrüchen) bleibt deshalb im Projektarknet.Das Modell trägt heute nur diese eine Anforderung an das Plugin. Die übrigen Skills (
/arknet:adr,/arknet:req-interview,/arknet:context-map,/arknet:health-check,/arknet:init) und ihre Regeln (z.B. "der Skill schreibt erst nach bestätigtem, testbarem Verständnis", "health-check schreibt nie", "init wählt zwischen project_add/adopt/attach_anchor, weil ein Fehlgriff ein zweites Projekt anlegt") stehen nur in den SKILL.md-Dateien, nicht als Requirements, Akzeptanzkriterien oder Use Cases im Store.Was zu tun ist
orphan_check,trace_matrixundstore_checkprüfen.Zusammenhang: #572 Punkt 5 (Rollen Architect/DDD Practitioner ohne Use Case) löst sich vermutlich zu einem großen Teil hier, weil die Skills genau diese Rollen bedienen.
Fertig, wenn
Jeder ausgelieferte Skill des Plugins auf mindestens ein Requirement mit Akzeptanzkriterium und einen Use Case im Projekt
arknetzurückführbar ist und die Aufnahme in beiden Sprachen vorliegt.prio:medium -- entscheidet, ob das eigene Modell das Produkt beschreibt oder nur den Service; reine Modellarbeit im Store, kein Code, darum Bahn Produkt.