shinkan-jinkendo/.claude/docs/functional/shinkan_anforderungsdokument_entwurf.md

# Shinkan – Anforderungsdokument (Entwurf)

## 1. Zielbild

Shinkan ist eine neue App für Karate- und Selbstverteidigungstrainer. Sie soll die bisherige, auf Semantic MediaWiki basierende Lösung fachlich ablösen und die heutigen Schwächen beheben:

- zu langsam
- zu umständlich in der Nutzung
- schwer verwaltbar
- fachlich und technisch nicht optimal für den Vereinsalltag

Shinkan soll als Teil einer bestehenden App-Familie entstehen und sich möglichst nahtlos in die bereits entwickelte Mitai-App einfügen.

## 2. Ziel des Dokuments

Dieses Dokument beschreibt schrittweise die fachlichen Anforderungen an Shinkan. Es dient später als Grundlage für die Umsetzung durch einen Coding-Agenten (z. B. Claude Code oder Cursor).

Der fachliche Entwurf entsteht interviewgestützt und wird iterativ verfeinert.

## 3. Fachliche Leitprinzipien

- hohe Geschwindigkeit in der täglichen Nutzung
- klare, trainerorientierte Bedienung
- gute Administrierbarkeit
- modular erweiterbar
- vereinsfähig und zugleich individuell nutzbar
- spätere KI-Unterstützung vorbereiten
- konsistente Einbettung in die bestehende App-Familie

## 4. Bisher identifizierte Fachblöcke

### 4.1 Reifegrad-Modell

Das Reifegradmodell definiert Entwicklungsstufen für unterschiedliche Stile, Schwerpunkte und Trainingstypen.

Beispiele:
- Karate Breitensport
- Karate Leistungssport
- Selbstverteidigung für Kinder
- Selbstverteidigung für Erwachsene
- Selbstverteidigung für Frauen
- Gewaltschutz / Selbstbehauptung / Gefahrenwahrnehmung / Gefahrenvermeidung

Das System soll offen und durch Administratoren erweiterbar sein.

Ein Reifegradmodell beschreibt Fähigkeits- bzw. Entwicklungsstufen und ist nicht zwingend an Gürtelgrade gebunden.

#### Beispielhafte Karate-Stufen
- **Level 1 – Basislevel**: Grundlegende Übungen, keine Vorkenntnisse erforderlich, geeignet als Einstiegsübung
- **Level 2 – Grundlagenlevel**: Fähigkeit kann selektiv eingesetzt werden, Bewegungs-/Handlungsmuster sind bekannt
- **Level 3 – Aufbaulevel 1**: semi-intuitiver Einsatz der Fähigkeit, Bewegungs-/Handlungsmuster werden größtenteils passend umgesetzt
- **Level 4 – Aufbaulevel 2**: intuitiver Einsatz der Fähigkeit, Bewegungs-/Handlungsmuster werden passend eingesetzt
- **Level 5 – Optimierungslevel**: Optimierung einer bereits vollständig ausgeprägten Fähigkeit, Spitzenleistungsniveau

Für jede Fähigkeit wird definiert, welche konkrete Ausprägung welcher Stufe entspricht.

Beispiel: **Dachi Waza**
- Stufe 1: stabiler Stand mit Schwerpunkt und richtiger Ausrichtung des Oberkörpers
- Stufe 2: Vorgehen in bestimmten Ständen, Wendungen
- Stufe 3: Beherrschung sämtlicher Stände, aus unterschiedlichen Ausgangssituationen einen stabilen Stand einnehmen
- usw.

Je nach Stil, Trainingsschwerpunkt und Trainingsziel können unterschiedliche Zielzustände pro Stufe gelten. Es können auch unterschiedliche Reifegradmodelle hinterlegt werden.

### 4.2 Übungen

Übungen sind ein zentrales Element der App.

Eine Übung beschreibt eine einzelne Trainingsübung und enthält u. a.:
- Beschreibung der Durchführung
- Zielbeschreibung
- Hinweise für den Trainer
- Vorbereitung
- Trainingsmethode
- Hilfsmittel
- Metadaten

Bereits genannte Metadaten:
- Übungstyp
- Zusammenfassung
- Schlüsselworte
- Gruppengröße
- Zielgruppe
- Altersgruppe
- minimale Graduierung
- Lernstufe
- Dauer

Zusätzlich gibt es eine Zuordnung:
- zu trainierten Fähigkeiten
- zum empfohlenen Level bzw. Reifegrad des Trainierenden

Über Metainformationen werden Übungen außerdem Sportarten, Typen, Schwerpunkten etc. zugeordnet.

### 4.3 Methoden

Der Methodenbereich beschreibt einzelne Trainingsmethoden.

Beispiele:
- Intervall-Training
- Rollenspiel
- plyometrische Übung
- Dauermethode
- extensive Intervall-Methode

### 4.4 Trainingsplanung

Die Trainingsplanung soll vereinsbezogen oder individuell möglich sein.

Anforderungen:
- Nutzung von Standardstrukturen / Templates möglich
- freie Planung ohne Templates ebenfalls möglich
- Trainings werden historisiert abgelegt
- Trainings können wiederverwendet werden
- Aufbau eines individuellen oder vereinsbezogenen Trainingsfundus / Trainingsprogramms
- konkrete Planung für bestimmte Tage und Trainingsgruppen
- Planung entweder auf Basis definierter Trainings oder individuell
- Trainings haben Ziel, Schwerpunkte, Dauer, Zielgruppe etc.

Wichtige Verwaltungsperspektiven:
- Trainer verwalten mehrere Trainingsgruppen
- Vereine verwalten Trainingstage, Trainingsgruppen, Trainer
- perspektivisch ggf. auch einzelne Sportler

Spätere KI-Unterstützung soll vorbereitet werden.

### 4.5 Feste Trainingsprogramme

Für bestimmte Administratoren soll es die Möglichkeit geben, feste Trainingsprogramme zu definieren und bereitzustellen.

## 5. Konsolidierter Produkt- und Rollenrahmen (Interviewstand)

### 5.1 Primäre Nutzer in der ersten Ausbaustufe

Shinkan richtet sich in der ersten Ausbaustufe an:
- Trainer
- Administratoren

Nicht primäre Nutzer in der ersten Stufe sind:
- Sportler
- Eltern
- Verbandsverantwortliche

Diese Gruppen sind perspektivisch als spätere Erweiterung denkbar, insbesondere für Individualtraining, Ferienprogramme oder leistungsorientierte Zusatzprogramme.

### 5.2 Abgrenzung zu Mitai

Mitai und Shinkan gehören zu einer gemeinsamen App-Familie, verfolgen jedoch unterschiedliche fachliche Schwerpunkte.

**Mitai** ist eine persönliche Tracking-App für Training, Körper, Fitness und ähnliche individuelle Themen.

**Shinkan** fokussiert auf die trainer- und vereinsbezogene Facharbeit, insbesondere:
- Übungen
- Methoden
- Trainingsplanung
- Trainingsprogramme
- perspektivisch Reifegrad- und Fähigkeitsentwicklung

#### Gemeinsame bzw. synchronisierte Grundlagen
Folgende technische und plattformbezogene Grundlagen sollen möglichst gemeinsam genutzt oder synchronisiert werden:
- Membership-System
- User-Management
- Designsystem
- iPhone-/PWA-Struktur
- Desktop-App
- PostgreSQL-Datenbank
- Server-Setup

#### Fachliche Leitlinie der Abgrenzung
- Mitai = persönliche Trainings- und Körperdaten
- Shinkan = fachliche Trainer- und Vereinsarbeit

Berührungspunkte sind möglich, aber die fachlichen Verantwortlichkeiten der beiden Apps sollen klar getrennt bleiben.

### 5.3 Zielmodell für Einsatz und Vermarktung

Shinkan soll grundsätzlich mehrere Einsatzformen unterstützen:
- Einzeltrainer
- einzelner Verein
- mehrere Vereine / mandantenfähige Nutzung
- spätere Membership-Version mit freischaltbaren Bereichen und Schwerpunkten

Der erste reale Einsatz erfolgt in einer Pilotphase im eigenen Verein.

Daraus ergibt sich eine zentrale fachliche Anforderung:

**Shinkan muss von Anfang an so modelliert werden, dass sowohl ein einfacher Pilotbetrieb als auch eine spätere skalierbare Membership- und Vereinslösung möglich ist, ohne das Kernmodell später grundlegend umbauen zu müssen.**

### 5.4 Rollen in der ersten Modellierung

Für die erste Modellierung werden mindestens folgende Rollen berücksichtigt:
- Superadmin
- Vereinsadmin
- Trainer
- Co-Trainer
- Redakteur / Inhaltsverantwortlicher

Aktuell werden keine allgemeinen Nutzer-, Sportler- oder Elternrollen für die erste Ausbaustufe eingeplant.

### 5.5 Sichtbarkeit und Freigabe von Inhalten

Inhalte sollen grundsätzlich in unterschiedlichen Sichtbarkeits- und Freigabestufen geführt werden können.

Aktuell identifizierte Ebenen:
- privat / nur für den Ersteller
- für bestimmte Personen
- für den eigenen Verein
- allgemein / global freigegeben
- offiziell bereitgestellte Standardinhalte

Zusätzlich soll es möglich sein, Inhalte fachlich oder lizenzbezogen einzuschränken, z. B.:
- Karate-Inhalte
- Selbstverteidigungs-Inhalte
- Gewaltschutz-Inhalte
- sonstige thematische Bereiche

Es ist denkbar, dass bestimmte Vereine oder Trainer keinen Zugriff auf einzelne Themenbereiche haben.

#### Vorläufige Produktentscheidung
Komplexe Rechte-, Membership- und Freischaltlogiken werden zunächst **nicht** vollständig ausmodelliert, sondern als spätere Ausbaustufe behandelt.

Für die erste fachliche Konzeption werden jedoch folgende Grundlagen festgehalten:
- Rollen werden definiert
- Sichtbarkeitsebenen werden vorgesehen
- Inhalte sollen grundsätzlich freigabefähig sein
- spätere feingranulare Rechte dürfen durch das Datenmodell nicht verbaut werden

### 5.6 Wichtigster Nutzungskern in Stufe 1

Der wichtigste Nutzungskern der ersten Stufe ist:
- Trainingsplanung
- Anlegen und Verwalten von Übungen

Perspektivisch wichtige Ausbaustufe:
- Nachverfolgung entwickelter Fähigkeiten einzelner Sportler
- Coaching- und Entwicklungsdokumentation

### 5.7 Erfolgsmaßstab

Shinkan ist fachlich gelungen, wenn insbesondere folgende Ziele erreicht werden:
- alle Trainer nutzen die App im Alltag
- Trainingsplanung ist schnell und praktikabel
- Übungen können effizient angelegt und wiedergefunden werden
- kein Pflegechaos wie im bisherigen Wiki
- Inhalte sind verwaltbar und strukturiert
- Standardisierung im Verein wird unterstützt

## 6. Erste fachliche Leitentscheidungen

Aus dem bisherigen Interviewstand ergeben sich bereits einige zentrale Leitentscheidungen:

1. **Trainerzentrierung vor Sportlerfokus**  
   Die erste Version optimiert konsequent die Arbeit von Trainern und Administratoren, nicht die direkte Nutzung durch Sportler.

2. **Übungen und Trainingsplanung sind der Kern**  
   Diese beiden Bereiche bilden das fachliche Zentrum der ersten Ausbaustufe und müssen deshalb im Datenmodell, in der Suche und in der Benutzerführung besonders stark berücksichtigt werden.

3. **Pilotfähig, aber von Anfang an skalierbar**  
   Obwohl der erste Einsatz im eigenen Verein stattfindet, darf die Fachlogik nicht nur für einen Einzelverein gedacht sein. Mandantenfähigkeit und Membership-Ausbau müssen später möglich sein.

4. **Klare Trennung zu Mitai**  
   Shinkan ist keine persönliche Tracking-App, sondern eine Trainings- und Inhaltsplattform für Trainer und Vereine.

5. **Rechte nicht übermodellieren, aber sauber vorbereiten**  
   Die erste Konzeption soll keine unnötig komplexe Rechtearchitektur erzwingen, muss aber spätere Freigabe-, Rollen- und Membership-Modelle ermöglichen.

## 7. Offene Punkte für die Interviewphase

### 7.1 Reifegradmodell
- Wie sind Stil, Schwerpunkt, Fähigkeit und Zielgruppe fachlich voneinander getrennt?
- Kann eine Fähigkeit in mehreren Modellen vorkommen?
- Können Stufenbeschreibungen versioniert werden?
- Wie erfolgt die Zuordnung zu Übungen?

### 7.2 Übungen
- Welche Pflichtfelder und optionale Felder gibt es?
- Wie wichtig sind Bilder, Videos, Anhänge und Ablaufskizzen?
- Wie stark soll die Suche / Filterung sein?
- Dürfen Übungen vereinsweit, privat oder rollenbasiert sichtbar sein?

### 7.3 Trainingsplanung
- Unterschied zwischen Training, Trainingsvorlage, Trainingseinheit und Trainingsprogramm
- Wie werden Gruppen, Trainer und Orte modelliert?
- Wie detailliert soll die Durchführung dokumentiert werden?
- Welche Wiederverwendungs- und Kopierfunktionen werden benötigt?

### 7.4 Governance / Administration
- Wer darf was anlegen, ändern, freigeben oder veröffentlichen?
- Gibt es Freigabe-Workflows?
- Gibt es Mandantenfähigkeit pro Verein?

## 8. Konsolidierung des Reifegradmodells (Interviewstand)

### 8.1 Fachliche Grundstruktur

Die derzeitige fachliche Struktur lässt sich wie folgt ordnen:

- **Sportart / Bereich**
  - z. B. Karate, Selbstverteidigung, Gewaltschutz
- **Stil**
  - z. B. Shotokan, Goju-Ryu
- **Zielgruppe**
  - z. B. Breitensportler, Leistungssportler, Kinder, Jugendliche, Erwachsene, Frauen, offen / gemischt

Diese Ebenen bilden den fachlichen Kontext, in dem Reifegradmodelle, Fähigkeiten, Übungen und Programme interpretiert werden.

### 8.2 Fachliche Bedeutung der zentralen Begriffe

#### Fähigkeit
Eine Fähigkeit ist ein trainierbarer fachlicher Entwicklungsgegenstand. Sie ist weder identisch mit einer Übung noch mit einer Trainingsmethode.

Beispiele:
- Dachi Waza
- Distanzkontrolle
- Beinarbeit
- Selbstbehauptung
- Gefahrenbewusstsein
- Aufmerksamkeit
- Reaktionsfähigkeit

#### Übung
Eine Übung ist eine konkrete didaktische Trainingsform zur Entwicklung, Überprüfung, Stabilisierung oder Anwendung von Fähigkeiten.

#### Methode
Eine Methode beschreibt die Art und Weise, wie trainiert wird, z. B. Intervalltraining, Rollenspiel oder Dauermethode.

#### Trainingsprogramm
Ein Trainingsprogramm ist eine aufeinander aufbauende Folge von Trainings mit definiertem Ziel und ggf. wiederkehrenden Fähigkeitsblöcken.

### 8.3 Grundsatz zur Modellierung von Fähigkeiten

Fähigkeiten sollen **nicht pro Modell dupliziert** werden, sondern als eigenständige fachliche Objekte geführt werden.

Eine Fähigkeit kann in mehreren Kontexten vorkommen, z. B.:
- Distanzgefühl in Karate und Selbstverteidigung
- stabiler Stand in Karate und Gewaltschutz
- Aufmerksamkeit / Wahrnehmung in verschiedenen Zielgruppenmodellen

Daraus folgt:

**Es gibt einen globalen Fähigkeitskatalog, aber die Ausprägung, Relevanz und Zielbeschreibung einer Fähigkeit wird kontextabhängig über ein Reifegradmodell beschrieben.**

### 8.4 Reifegradmodell als kontextbezogene Bewertungslogik

Ein Reifegradmodell beschreibt, wie eine Fähigkeit in einem bestimmten fachlichen Kontext entwickelt und bewertet wird.

Ein Modell ist damit immer an einen Kontext gebunden, z. B.:
- Karate → Shotokan → Breitensport
- Karate → Shotokan → Leistungssport
- Selbstverteidigung → Erwachsene
- Gewaltschutz → Frauen
- Gewaltschutz → Kinder

Ein Reifegradmodell enthält:
- Bezeichnung des Modells
- fachlichen Geltungsbereich
- variable Anzahl von Stufen
- optionale Lernstufen / Entwicklungsphasen
- Zielbeschreibungen je Stufe
- Zuordnung, welche Fähigkeiten im Modell geführt werden

### 8.5 Level-Logik

Ein Level beschreibt **nicht die Übung selbst**, sondern den erwarteten Ausprägungsgrad einer Fähigkeit innerhalb eines bestimmten Modells.

Daraus ergeben sich mindestens zwei unterschiedliche fachliche Bezüge:

1. **Vorausgesetztes Niveau**
   - Auf welchem Fähigkeitsniveau sollte ein Sportler ungefähr sein, damit eine Übung sinnvoll durchgeführt werden kann?

2. **Entwicklungswirkung der Übung**
   - Wie stark zahlt die Übung auf die Entwicklung einer Fähigkeit ein?
   - Auf welche Zielstufe oder welchen Entwicklungsbereich wirkt die Übung hin?

### 8.6 Variable Stufenanzahl

Reifegradmodelle müssen eine variable Anzahl an Stufen unterstützen.

Das System darf daher nicht auf genau fünf Level fest verdrahtet werden. Möglich sind z. B.:
- 3 Stufen
- 4 Stufen
- 5 Stufen
- 6 Stufen

Das heute existierende Karate-Modell mit 5 Leveln ist damit ein wichtiges Standardmodell, aber kein technischer Zwang für alle zukünftigen Modelle.

### 8.7 Standardmodelle je Kontext

Für jede Kombination aus Sportart/Bereich, Stil und Zielgruppe soll es zunächst ein definierbares Standardmodell geben.

Spätere Ausbaustufe:
- individuelle oder vereinsspezifische Modelle
- alternative Modellvarianten
- Versionierung von Modellen

### 8.8 Vorschlag für die Kernmodellierung

Um die spätere Komplexität beherrschbar zu halten, wird folgende fachliche Trennung empfohlen:

#### A. Fähigkeit (global)
Beschreibt die Fähigkeit selbst.

Beispielhafte Felder:
- ID
- Name
- Kurzbeschreibung
- Langbeschreibung / Glossartext
- fachliche Kategorie
- optionale Oberkategorie
- allgemeine Relevanz / Bedeutsamkeit
- Schlagworte
- Status

#### B. Reifegradmodell
Beschreibt das Entwicklungsmodell für einen fachlichen Kontext.

Beispielhafte Felder:
- ID
- Name
- Bereich / Sportart
- Stil
- Zielgruppe
- Beschreibung
- Anzahl Stufen
- optionale Lernphasen
- Gültigkeit / Version
- Status

#### C. Modell-Fähigkeit
Verknüpft eine Fähigkeit mit einem konkreten Modell.

Diese Entität ist fachlich zentral.

Sie beschreibt z. B.:
- ob die Fähigkeit in diesem Modell vorkommt
- welche Bedeutung sie in diesem Modell hat
- ob sie primär, sekundär oder ergänzend ist
- ob sie prüfungsrelevant ist
- ob sie optional oder verpflichtend ist

#### D. Modell-Fähigkeitsstufe
Beschreibt für eine Fähigkeit innerhalb eines Modells die konkrete Zielausprägung je Stufe.

Beispiel:
- Modell: Karate / Shotokan / Breitensport
- Fähigkeit: Dachi Waza
- Stufe 1: stabiler Stand mit Schwerpunkt und richtiger Ausrichtung
- Stufe 2: Vorgehen in bestimmten Ständen, Wendungen
- usw.

#### E. Übungs-Fähigkeitsbezug
Verknüpft eine Übung mit einer oder mehreren Fähigkeiten.

Hierüber wird beschrieben:
- welche Fähigkeit trainiert wird
- ob es Haupt- oder Nebenfähigkeit ist
- welche Entwicklungsintensität vorliegt
- ob die Übung eher Grundlagen-, Aufbau-, Vertiefungs-, Festigungs- oder Diagnosecharakter hat

### 8.9 Lösungsvorschlag für Übungen in mehreren Modellen

Dies ist einer der kritischsten Punkte des Gesamtsystems.

#### Problem
Eine Übung kann in mehreren fachlichen Kontexten sinnvoll sein. Gleichzeitig können dieselben Fähigkeiten je Modell unterschiedlich interpretiert und auf unterschiedlichen Stufen beschrieben werden.

#### Empfehlung
**Übungen sollen nicht direkt an ein einzelnes Reifegradmodell gebunden werden.**

Stattdessen wird empfohlen:

1. Übungen werden primär mit **globalen Fähigkeiten** verknüpft.
2. Zusätzlich erhält jede Übung je Fähigkeitsbezug eine fachliche Einordnung, z. B.:
   - Hauptfähigkeit / Nebenfähigkeit
   - Trainingscharakter (Grundlage, Aufbau, Vertiefung, Festigung, Diagnose)
   - Intensität / Entwicklungsbeitrag
   - geeignete Zielgruppen
3. Die konkrete Einordnung in ein bestimmtes Reifegradmodell erfolgt **indirekt** über den Abgleich zwischen:
   - den mit der Übung verknüpften Fähigkeiten
   - dem Standardmodell des gewählten Kontextes
   - dem gewünschten Leistungsstand der Trainingsgruppe

#### Vorteil dieses Ansatzes
- Übungen bleiben wiederverwendbar
- gleiche Übung kann in mehreren Kontexten genutzt werden
- Reifegradmodelle bleiben austauschbar
- KI-Planung und Suche können später kontextbezogen mappen
- spätere Erweiterungen werden nicht durch Modell-Duplikate blockiert

#### Zusätzliche empfohlene Erweiterung
Für besonders wichtige Fälle kann optional eine zusätzliche Feineinordnung erlaubt werden:
- „Übung X ist im Modell Karate/Shotokan/Leistungssport besonders geeignet für Fähigkeit Y auf Stufe 2 bis 3“

Diese Zuordnung sollte jedoch **optional** sein, nicht verpflichtend. Sonst entsteht ein hoher Pflegeaufwand.

### 8.10 Lernlogik und Abhängigkeiten

Das System soll perspektivisch fachliche Lern- und Planungslogiken unterstützen.

Dazu gehören insbesondere:
- Grundlagenübung
- Aufbauübung
- Vertiefungsübung
- Festigungsübung
- Diagnoseübung

Spätere Ausbaustufen sollten außerdem ermöglichen:
- Fähigkeit A ist Voraussetzung für Fähigkeit B
- Übung ist erst ab bestimmtem Niveau sinnvoll
- Übung entwickelt bevorzugt von Stufe X nach Y
- Übung ist eher Prüf- oder Beobachtungsformat als Aufbauformat

Diese Logiken sind besonders relevant für:
- intelligente Suche
- KI-gestützte Trainingsplanung
- spätere Sportlerentwicklung / Coaching

### 8.11 Zukunftssicherheit für Sportlerentwicklung

Das Reifegradmodell soll von Anfang an so entworfen werden, dass später auch eine individuelle Entwicklungsdokumentation für einzelne Sportler möglich ist.

Das bedeutet:
- Modelle und Fähigkeiten müssen stabil identifizierbar sein
- Stufen müssen pro Modell und Fähigkeit eindeutig referenzierbar sein
- spätere personenbezogene Bewertungen dürfen an das Modell anschließen können
- massive Refaktorierungen sollen vermieden werden

## 9. Vorläufige fachliche Entscheidung

Für Shinkan wird aktuell folgende Grundentscheidung empfohlen:

- **Globaler Fähigkeitskatalog** als stabile fachliche Basis
- **Kontextbezogene Reifegradmodelle** je Bereich / Stil / Zielgruppe
- **Stufenziele pro Fähigkeit innerhalb eines Modells**
- **Übungen werden primär an Fähigkeiten, nicht an starre Modelle gebunden**
- **Optionale modellbezogene Feineinordnung nur dort, wo sie fachlich wirklich nötig ist**

## 10. Konsolidierung des Übungsmodells (Interviewstand)

### 10.1 Fachliche Rolle der Übung

Übungen sind eines der zentralen Kernelemente von Shinkan.

Die Übung muss so dokumentiert sein, dass ein Trainer sie zuverlässig:
- versteht
- vorbereitet
- situativ einordnet
- praktisch durchführen kann

Die **Nachvollziehbarkeit für den Trainer** ist damit ein zentrales Qualitätskriterium des Übungsobjekts.

### 10.2 Zielbild der Übungsbeschreibung

Eine gute Übungsbeschreibung in Shinkan soll mindestens folgende Fragen beantworten:
- Was ist das Ziel der Übung?
- Wie wird sie konkret durchgeführt?
- Was muss vorher vorbereitet werden?
- Welche Hilfsmittel werden benötigt?
- Für welche Zielgruppen ist sie geeignet?
- Für welche Gruppengröße ist sie geeignet?
- Wie lange dauert sie ungefähr?
- Welche Fähigkeiten trainiert sie?
- Welchen Trainingscharakter hat sie?
- Welche Methode kommt zum Einsatz?

### 10.3 Vorläufige Pflichtinformationen einer Übung

Die folgenden Informationen sind nach aktuellem Stand fachlich sehr wahrscheinlich Pflichtfelder:

- Titel / Name der Übung
- Kurzbeschreibung / Zusammenfassung
- Ziel der Übung
- Beschreibung der Durchführung
- Hinweise für den Trainer
- Vorbereitung / Aufbau
- Dauer
- minimale Gruppengröße
- maximale Gruppengröße
- Altersgruppe / geeignete Altersstufen
- benötigte Hilfsmittel
- Methodenbezug / verwendete Trainingsmethode
- trainierte Fähigkeiten
- Trainingscharakter
- Sichtbarkeit / Freigabestatus
- Ersteller / Verantwortlicher

### 10.4 Altersgruppen

Aktuell genannte Alters- bzw. Zielgruppeneinstufungen:
- Minis
- Kinder
- Schüler
- Teenager
- Erwachsene

Später ist zu entscheiden, ob diese rein als feste Kategorien oder zusätzlich mit optionalen Altersintervallen modelliert werden.

### 10.5 Medienmodell

Medien sind fachlich sehr wichtig und sollen umfassend unterstützt werden.

Eine Übung soll deshalb mehrere Medienobjekte enthalten können.

Unterstützt werden sollen perspektivisch alle gängigen Medienformate, insbesondere:
- Bilder / Fotos
- Zeichnungen / Skizzen
- Videos
- ggf. Dokumente oder Anhänge

#### Fachliche Konsequenz
Eine Übung darf **nicht** nur ein einzelnes Bild oder ein einzelnes Video haben, sondern benötigt ein flexibles Medienmodell mit Mehrfachzuordnung.

Empfohlene Eigenschaften pro Medium:
- Medientyp
- Datei / Referenz
- Titel
- Beschreibung / Kommentar
- Reihenfolge
- optional Markierung als Hauptmedium
- optional fachlicher Bezug (z. B. Ablaufbild, Detailtechnik, Trainerhinweis)

### 10.6 Suche und Filterung

Die Übungssuche muss möglichst effektiv sein und gehört zu den wichtigsten Nutzungsfunktionen der App.

Dabei besteht ein Zielkonflikt:
- starke und verschachtelte Filter sind fachlich oft sinnvoll
- zu viele Filter erhöhen die Bedienkomplexität

Beispiel für komplexere Suchbedarfe:
- Leistungsgruppe
- Kumite
- Beinarbeit
- fortgeschritten

#### Vorläufige Produktentscheidung
Shinkan sollte deshalb **mehrstufige Sucheinstiege** unterstützen:

1. **Schnellsuche**
   - einfache Suche über Titel, Schlagworte und zentrale Metadaten

2. **Geführte Filtersuche**
   - strukturierte Auswahl häufiger Filter
   - z. B. Bereich, Zielgruppe, Fähigkeit, Dauer, Gruppengröße, Leistungsstand

3. **Erweiterte Suche**
   - für komplexe Kombinationen und verschachtelte Filter

4. **Smarte Suchunterstützung**
   - möglichst ohne zwingende externe KI-Calls
   - z. B. durch Synonyme, Suchvorschläge, Relevanzranking, gespeicherte Suchprofile oder semantische Näherungen auf lokaler Basis

Spätere Ausbaustufe:
- KI-gestützte Suchhilfe in natürlicher Sprache
- z. B. „Ich suche eine Kumite-Übung für fortgeschrittene Teenager mit Schwerpunkt Beinarbeit für 12 Personen in 15 Minuten“

### 10.7 Trainingscharakter

Der Trainingscharakter soll als fachliches Merkmal einer Übung geführt werden.

Aktuell identifizierte bzw. bereits diskutierte Kategorien:
- Grundlagenübung
- Aufbauübung
- Vertiefungsübung
- Festigungsübung
- Diagnoseübung

Dieser Aspekt ist wichtig für:
- Suche
- Trainingsplanung
- spätere KI-Unterstützung
- spätere Lern- und Entwicklungslogik

### 10.8 Fähigkeitsbezug einer Übung

Eine Übung trainiert üblicherweise mehrere Fähigkeiten auf unterschiedlichem Niveau.

Daher sollte der Übungs-Fähigkeitsbezug mindestens folgende Angaben ermöglichen:
- Fähigkeit
- Haupt- oder Nebenfähigkeit
- Stärke / Intensität des Beitrags
- optional erforderliches Eingangs-Niveau
- optional erwarteter Entwicklungsbeitrag

### 10.9 Erste fachliche Leitentscheidung zum Übungsobjekt

Das Übungsobjekt in Shinkan muss drei Dinge gleichzeitig leisten:

1. **Didaktische Verständlichkeit**
   - damit Trainer die Übung zuverlässig durchführen können

2. **Strukturierte Auffindbarkeit**
   - damit Übungen schnell gesucht, gefiltert und wiederverwendet werden können

3. **Fachliche Anschlussfähigkeit**
   - damit Übungen später in Reifegradmodelle, Trainingsplanung, KI-Planung und Sportlerentwicklung eingebunden werden können

## 11. Präzisierung des Übungsmodells (Interviewstand)

### 11.1 Pflichtfelder vs. wünschenswerte Felder

Nach aktuellem Interviewstand gelten für das Speichern einer Übung als echte Pflichtfelder:
- Titel
- Ziel
- Durchführung

Weitere Informationen sind fachlich sehr wichtig, sollen aber zunächst nicht zwingende technische Pflichtfelder sein. Sie sind insbesondere für Suche, Filterung und spätere KI-gestützte Planung wünschenswert:
- Dauer
- Altersgruppen
- Fähigkeitsbezug

#### Fachliche Bewertung
Diese Entscheidung ist für die erste Ausbaustufe pragmatisch sinnvoll, weil sie das Anlegen neuer Übungen nicht unnötig erschwert. Gleichzeitig muss das System sichtbar machen, wenn eine Übung fachlich noch unvollständig beschrieben ist.

### 11.2 Variantenlogik

Übungen sollen Varianten unterstützen.

Hintergrund:
Im heutigen Wiki ist dies ein Schwachpunkt. Varianten oder konkrete Anpassungen werden aktuell teilweise erst in der Trainingsplanung abgefangen, indem die Übung zugeordnet und die konkrete Ausführung im Plan angepasst wird.

Shinkan soll dieses Defizit fachlich besser lösen.

#### Empfohlene Modellierung
Eine Übung besteht aus:
- einer **Stammübung** als fachlicher Kern
- optional mehreren **Varianten**

Beispiele für Varianten:
- leicht / mittel / schwer
- mit Partner / ohne Partner
- mit Hilfsmittel / ohne Hilfsmittel
- kindgerechte Variante
- Kurzvariante
- fortgeschrittene Variante

Empfohlene Eigenschaften einer Variante:
- Titel / Variantenname
- Kurzbeschreibung
- abweichende Durchführung
- abweichende Dauer
- abweichende Hilfsmittel
- abweichender Fähigkeitsfokus
- abweichende Zielgruppen / Altersgruppen
- optional eigener Medienbezug

### 11.3 Qualitäts- und Bearbeitungsstatus

Ein Statusmodell für Übungen wird als sinnvoll angesehen.

Wichtige fachliche Zusatzanforderung:
Eigene Übungen müssen für den jeweiligen Ersteller oder verantwortlichen Trainer jederzeit separat einsehbar und verwaltbar sein, damit an begonnenen oder noch nicht freigegebenen Übungen weitergearbeitet werden kann.

#### Empfohlene Statusstufen
- Entwurf
- in Bearbeitung
- fachlich geprüft
- freigegeben
- archiviert

Spätere Ausbaustufe:
- Freigabe durch Redakteur oder Vereinsadmin
- offizielle Vereinsübung
- offizielle globale Standardübung

### 11.4 Mehrfachzuordnung zu Bereichen

Eine Übung kann mehreren Bereichen gleichzeitig zugeordnet werden.

Beispiele:
- Karate
- Selbstverteidigung
- Gewaltschutz

#### Empfehlung zur Modellierung
Trotz Mehrfachzuordnung sollte eine Übung optional einen **primären Bereich** besitzen, damit Suche, Sortierung und Standarddarstellungen einfacher steuerbar bleiben.

Zusätzlich können **sekundäre Bereiche** zugeordnet werden.

### 11.5 Methodenbezug

Typischerweise gibt es eine Hauptmethode, jedoch kann eine Mehrfachzuordnung fachlich sinnvoll sein.

Begründung:
Je nach Blickwinkel können gleichzeitig eine sportmethodische Hauptmethode und eine didaktische bzw. vermittlungsbezogene Methode relevant sein.

Das hochgeladene Methodenglossar bestätigt, dass Methoden heute bereits stark fachlich beschrieben und mit Fähigkeiten verknüpft werden. Dort werden z. B. Dauermethode, Rollenspiel, Koordinationstraining, strukturierte Übung oder plyometrisches Training jeweils mit Beschreibung, Kürzel und zugeordneten Fähigkeiten geführt. fileciteturn1file0

#### Empfohlene Modellierung
- genau **eine Hauptmethode**
- optional **weitere Nebenmethoden**

Optional kann später zusätzlich unterschieden werden zwischen:
- sportmethodische Hauptmethode
- didaktische / vermittlungsbezogene Zusatzmethode

### 11.6 Detaillierungsgrad der Übungsbeschreibung

Für Vorbereitung und Durchführung einer unbekannten Übung ist eine **sehr detaillierte Beschreibung** zielführend.

Gleichzeitig soll im ausgedruckten Trainingsplan eine **kürzere Variante** der Darstellung möglich sein.

#### Fachliche Konsequenz
Die Übung sollte daher zwei Darstellungsebenen unterstützen:
- **Langform** für Vorbereitung, Pflege und Detailverständnis
- **Kurzform** für Trainingsplanung, Ausdruck und schnellen Überblick

Die Langform sollte insbesondere folgende Inhalte aufnehmen können:
- Schrittfolge der Durchführung
- Trainerhinweise
- Aufbau / Vorbereitung
- Risiken / typische Fehler
- Variantenhinweise
- Medienbezug

### 11.7 Ableitung für das UX- und Datenmodell

Aus den bisherigen Entscheidungen ergeben sich für Shinkan mindestens folgende Produktanforderungen:

1. Übungen dürfen mit minimalen Pflichtfeldern schnell angelegt werden.
2. Unvollständige Übungen müssen später gezielt weiterbearbeitbar sein.
3. Eigene Entwürfe und in Arbeit befindliche Übungen brauchen einen eigenen Verwaltungsbereich.
4. Varianten müssen als echte Unterstruktur einer Übung abbildbar sein.
5. Die Übung muss Lang- und Kurzbeschreibung getrennt unterstützen.
6. Haupt- und Nebenmethoden sollen fachlich modellierbar sein.
7. Mehrfachzuordnungen zu Bereichen müssen möglich sein.

## 12. Ergänzende Erkenntnisse aus den hochgeladenen Fachunterlagen

Die hochgeladenen Unterlagen stützen die gewählte Richtung der Modellierung:

- Die **Fähigkeitsmatrix** zeigt, dass Fähigkeiten heute bereits stufenbezogen und kontextnah beschrieben werden, etwa für Dachi Waza, Beinarbeit, Distanzkontrolle oder Flexibilität. Gleichzeitig werden Lernstufen und Level getrennt dargestellt. fileciteturn0file0
- Das **Fähigkeitsglossar** zeigt, dass Fähigkeiten zusätzlich als eigenständige fachliche Objekte mit Definition und Bedeutsamkeit geführt werden, etwa Dachi Waza, Abwehr Konter, Aufmerksamkeit, Schnellkraft oder Uke Waza. fileciteturn0file1
- Das **Methodenglossar** zeigt, dass auch Methoden bereits eigenständig modellierbar sind und heute mit Fähigkeiten, Beschreibung und Nutzen verknüpft werden, z. B. Rollenspiel, Koordinationstraining, strukturierte Übung, Dauermethode oder plyometrisches Training. fileciteturn1file0

Diese Trennung zwischen Fähigkeit, Methode und Übung sollte in Shinkan bewusst beibehalten und technisch sauber umgesetzt werden.

## 13. Konsolidierung des Modells zur Trainingsplanung (Interviewstand)

### 13.1 Fachliche Trennung der Kernbegriffe

#### Trainingsvorlage
Eine Trainingsvorlage beschreibt die **Struktur** eines Trainings anhand von Trainingsabschnitten, z. B.:
- Aufwärmen
- Kihon
- Selbstschutz
- Kumite
- Kata
- Abschluss

Die Trainingsvorlage enthält also primär den Rahmen und die logische Gliederung, nicht zwingend bereits die finalen konkreten Übungen.

#### Konkretes Training
Ein konkretes Training besteht aus mehreren Abschnitten, die mit konkreten Übungen gefüllt sind.

#### Trainingstermin
Ein Trainingstermin ist das konkrete Datum bzw. der konkrete Zeitpunkt, an dem ein geplantes Training durchgeführt werden soll.

#### Trainingsprogramm
Ein Trainingsprogramm ist eine Gruppe aufeinander aufbauender Trainings ohne zwingend konkrete zeitliche Terminierung. Fachlich entspricht dies oft einem Kurs, Entwicklungsblock oder Programm über mehrere Wochen.

#### Trainingseinheit
Eine Trainingseinheit ist ein konkretes Training, das an einem bestimmten Tag für eine bestimmte Gruppe durchgeführt wird oder wurde.

### 13.2 Frei modellierbare Trainingsstruktur mit Standardvorlagen

Der Aufbau eines Trainings ist grundsätzlich frei.

Gleichzeitig soll Shinkan Standardvorlagen unterstützen, damit wiederkehrende Trainingslogiken und Vereinsstandards schnell nutzbar sind.

#### Produktentscheidung
Shinkan sollte daher **freie Trainingsstruktur + optionale Vorlagenunterstützung** kombinieren.

Das ist wichtig, weil:
- verschiedene Trainer unterschiedlich planen
- verschiedene Sportarten / Schwerpunkte andere Strukturen brauchen
- dennoch wiederverwendbare Standards im Verein sehr hilfreich sind

### 13.3 Primäre Planungsobjekte

Im Traineralltag wird voraussichtlich primär eine **einzelne Trainingseinheit** geplant.

Für verantwortliche Trainer, Cheftrainer oder Programmverantwortliche ist zusätzlich die Planung von:
- Trainingsserien
- Fähigkeitsblöcken
- mehrwöchigen Programmen

fachlich wesentlich.

#### Konsequenz
Shinkan muss mindestens zwei Planungsebenen unterstützen:

1. **Einzelplanung**
   - eine konkrete Einheit für einen bestimmten Termin und eine bestimmte Gruppe

2. **Programm- / Serienplanung**
   - mehrere aufeinander aufbauende Trainings ohne oder mit späterer zeitlicher Zuordnung

### 13.4 Wiederverwendung

Folgende Objekte sollen wiederverwendbar sein:
- ganze Trainings
- einzelne Blöcke / Abschnitte
- einzelne Übungen
- ganze Programme
- Vorlagen

Zusätzlich ist denkbar, dass Vorlagen nicht zwingend ein eigener Objekttyp sein müssen, sondern teilweise über Kennzeichnungen / Flags abgebildet werden können.

#### Fachliche Empfehlung
Trotz möglicher Flags sollte fachlich zwischen folgenden Dingen unterschieden werden:
- Vorlage
- wiederverwendbares Standardtraining
- konkrete Trainingseinheit

Nur so bleiben Suche, Wiederverwendung und spätere Auswertungen sauber.

### 13.5 Änderungslogik und Versionierung

Aktuell wird **keine vollständige technische Historisierung jeder einzelnen Änderung** als notwendig angesehen.

#### Interviewstand
- Eine Trainingseinheit darf nachträglich verändert werden.
- Wenn ein Standardtraining für einen konkreten Trainingstag angepasst wird, bleibt das Standardtraining erhalten; verändert wird nur die abgeleitete konkrete Einheit.
- Für Standards und Programme ist Versionierung sinnvoll, damit ältere Stände weiterhin zugänglich bleiben.

#### Fachliche Einschätzung
Diese Entscheidung ist aus Produktsicht sehr sinnvoll.

Eine vollständige Änderungs-Historie für jede kleine Anpassung würde die erste Ausbaustufe wahrscheinlich unnötig komplex machen.

Empfohlen wird daher:

1. **Keine Vollversionierung für jede Trainingseinheit**
2. **Ableitungslogik statt Überschreiben von Standards**
3. **Versionierung für Standardtrainings, Vorlagen und Programme**

#### Konkrete Produktempfehlung
- **Trainingseinheit**: keine feingranulare Versionshistorie erforderlich
- **Standardtraining**: versionierbar
- **Trainingsvorlage**: versionierbar
- **Trainingsprogramm**: versionierbar

Das ist aus meiner Sicht die richtige Balance zwischen Beherrschbarkeit und fachlicher Nachvollziehbarkeit.

### 13.6 Trainingsgruppe

Eine Trainingsgruppe ist zunächst die Gruppe von Sportlern, z. B.:
- Leistungsgruppe Kata – Level 1

Zu einer Trainingsgruppe gehören fachlich mindestens:
- Name der Gruppe
- fachlicher Zuschnitt / Schwerpunkt
- ggf. Level oder Leistungsstand
- zugeordnete Trainer
- ggf. mehrere Trainingstage bzw. Termine
- ggf. mehrere Wochentage und Uhrzeiten
- Standards für die Gruppe
- konkrete Planungen / Abweichungen

#### Wichtige fachliche Beobachtung
Die Trainingsgruppe ist **nicht identisch mit einem einzelnen Termin**. Sie ist ein dauerhaftes organisatorisches Objekt, auf das sich wiederkehrende Planungen und konkrete Einheiten beziehen.

### 13.7 Nutzung im Alltag

Die App soll im Trainingsalltag möglichst durchgängig nutzbar sein:
- zur Vorbereitung
- als Live-Spickzettel während des Trainings
- zur spontanen Anpassung während des Trainings
- zur Nachbereitung direkt danach

#### Produktkonsequenz
Shinkan braucht deshalb später unterschiedliche Nutzungssichten:
- **Planungssicht** für ausführliche Vorbereitung
- **Durchführungssicht** für schnelle mobile Nutzung im Training
- **Nachbereitungssicht** für Anpassungen und Notizen

### 13.8 Empfohlenes Domänenmodell für die Trainingsplanung

Aus dem bisherigen Stand ergibt sich folgende fachliche Struktur:

#### A. Trainingsvorlage
Beschreibt eine wiederverwendbare Struktur von Abschnitten.

#### B. Trainingsabschnitt
Ein logisch abgegrenzter Teil eines Trainings, z. B. Aufwärmen, Kumite oder Abschluss.

Ein Abschnitt kann enthalten:
- Titel
- Typ / Kategorie
- Reihenfolge
- optionale Zielsetzung
- optionale Soll-Dauer
- Übungen

#### C. Standardtraining
Ein wiederverwendbares, konkret ausgearbeitetes Training mit Abschnitten und Übungen, aber ohne zwingenden Terminbezug.

#### D. Trainingseinheit
Ein konkretes Training für eine bestimmte Gruppe an einem bestimmten Termin.

#### E. Trainingstermin
Das Datum / die Zeit einer Durchführung.

#### F. Trainingsprogramm
Eine aufeinander aufbauende Folge von Standardtrainings oder geplanten Einheiten mit fachlichem Gesamtziel.

#### G. Trainingsgruppe
Die organisatorische Gruppe von Sportlern mit zugehörigen Trainern, Rhythmen und Standards.

### 13.9 Ableitung statt Kopplungschaos

Ein zentraler Architekturgrundsatz sollte sein:

**Konkrete Trainingseinheiten werden aus Vorlagen, Standardtrainings oder Programmen abgeleitet, aber nicht hart mit ihnen gekoppelt überschrieben.**

Das verhindert, dass spätere Anpassungen an einer konkreten Einheit unbeabsichtigt die zugrunde liegende Standardlogik verändern.

### 13.10 Ergänzende Erkenntnisse aus den hochgeladenen Fachunterlagen

Die Unterlagen stützen die Notwendigkeit einer strukturierten Trainingsplanung:

- Die **Fähigkeitsmatrix** zeigt, dass Trainingsplanung perspektivisch auf Fähigkeitsstufen und Entwicklungslogik Bezug nehmen sollte, etwa über Level, Lernstufen und konkrete Zielbilder je Fähigkeit. fileciteturn0file0
- Das **Fähigkeitsglossar** zeigt, dass ein stabiler Fähigkeitskatalog als Grundlage für Schwerpunkte und Entwicklungsziele von Trainings sinnvoll ist. fileciteturn0file1
- Das **Methodenglossar** zeigt, dass Methoden wie Rollenspiel, Koordinationstraining, Strukturierte Übung, Zirkeltraining oder plyometrisches Training eigenständige fachliche Bausteine sind, die in Trainingsplanung und Übungsbeschreibung anschlussfähig sein sollten. fileciteturn1file0

## 14. Vorläufige fachliche Entscheidung zur Versionierung

Aktuell wird empfohlen:
- **keine Vollhistorisierung jeder Planänderung**
- **Versionierung nur für Standardobjekte**
- **konkrete Einheiten als abgeleitete und eigenständig bearbeitbare Objekte**

Diese Entscheidung reduziert Komplexität deutlich und adressiert gleichzeitig den Bedarf, ältere Stände von Programmen und Standards wieder aufrufen zu können.

## 15. Präzisierung des Planungs- und Durchführungsworkflows (Interviewstand)

### 15.1 Erweiterte Struktur von Trainingsabschnitten

Ein Trainingsabschnitt soll mindestens folgende Eigenschaften unterstützen:
- Titel
- Typ / Kategorie
- Reihenfolge
- optionale Dauer
- optionales Ziel
- zugeordnete Übungen
- optionale Notizen

Zusätzlich gibt es eine wichtige fachliche Eigenschaft:

- **Kombinations-Flag**

Dieses Flag bedeutet:

**Übungen in diesem Abschnitt werden als zusammenhängender Komplex behandelt.**

Damit lassen sich mehrere Übungen fachlich zu einem Gesamtblock bündeln, z. B.:
- Zirkel
- Parcours
- komplexe Intervallform
- methodischer Übungskomplex

Für einen solchen Abschnitt kann dann auf Abschnittsebene eine Gesamttrainingsmethode gesetzt werden, z. B. **Zirkeltraining**.

#### Fachliche Bedeutung
Das ist ein wichtiger Punkt, weil dadurch Übungen nicht nur einzeln, sondern auch als methodisch zusammenhängende Struktur geplant und durchgeführt werden können.

### 15.2 Planungsansichten

Die Planung erfolgt voraussichtlich primär für:
- eine bestimmte Gruppe
- an einem bestimmten Datum / einer bestimmten Uhrzeit

Gleichzeitig sollen unterschiedliche Planungsansichten unterstützt werden.

#### Benötigte Ansichten
- **Kalenderansicht**
  - anstehende Trainings
  - Markierung für bereits geplante / ungeplante Termine
- **Gruppenbezogene Listenansicht**
  - genaue Sicht auf eine bestimmte Trainingsgruppe
- perspektivisch weitere Sichten
  - Wochenansicht
  - Traineransicht
  - Programm-/Blocksicht

### 15.3 Mögliche Startpunkte der Planung

Ein neues Training kann aus unterschiedlichen Ausgangspunkten entstehen:
- komplett leer
- aus einer Trainingsvorlage
- aus einer Grundstruktur
- aus Standardblöcken
- aus einem alten Training per Kopie und Anpassung
- aus einem Programm- oder Schwerpunktblock

Zusätzlich plant der Nutzer selbst häufig in etwa **4-Wochen-Schwerpunkten**, sodass Struktur und Schwerpunkte für einen größeren Block im Voraus feststehen.

#### Fachliche Konsequenz
Shinkan sollte daher mehrere Einstiegspfade in die Planung unterstützen und keinen einzigen „richtigen“ Planungsweg erzwingen.

### 15.4 Nutzung während der Durchführung

Während des Trainings soll Shinkan aktiv nutzbar sein.

Benötigte Funktionen:
- Navigation zwischen den Übungen
- Anzeige eines Indikators für das Zeitmanagement
- kein restriktives Erzwingen von Zeitvorgaben
- Übung als durchgeführt markieren
- Notizen zur einzelnen Übung erfassen
- Notizen zum gesamten Training erfassen
- optional spontane Erfassung einer neuen Übung während des Trainings

#### Fachliche Konsequenz
Die Durchführungssicht muss schnell, fokussiert und mobil nutzbar sein. Gleichzeitig darf sie nicht so starr sein, dass spontane Trainerentscheidungen behindert werden.

### 15.5 Nachbereitung

Zur Nachbereitung sollen mindestens folgende Inhalte möglich sein:
- was wurde tatsächlich gemacht
- kurze Reflexion
- was hat gut funktioniert
- was sollte nächstes Mal geändert werden
- Kommentare zu einzelnen Übungen
- Kommentare zum gesamten Training

Besonders wichtig:
Kommentare sollen nicht nur im Trainingsplan verbleiben, sondern optional auch als Hinweis zur Übung selbst für Trainer oder Verein nutzbar werden können.

#### Fachliche Bedeutung
Damit wird Shinkan nicht nur ein Planungstool, sondern auch ein lernendes Vereinssystem, in dem Erfahrungswissen erhalten bleibt.

### 15.6 Druck und mobile Nutzung

Sowohl Druckansicht als auch mobile Nutzung sind wichtig.

Begründung:
- Nicht überall besteht beim Training Empfang.
- Nicht jeder Trainer hat während des Trainings ein Handy dabei.

#### Produktkonsequenz
Shinkan sollte daher mindestens unterstützen:
- gute Druckansicht / Ausdruck
- starke mobile Durchführungssicht
- Offline-taugliche oder offline-nahe Nutzung für zentrale Planungsinformationen

### 15.7 Primäre Sicht in Stufe 1

In der ersten Ausbaustufe ist die **Trainersicht** die primäre Perspektive.

Perspektivisch soll jedoch auch die Entwicklung einer Gruppe stärker berücksichtigt werden, z. B.:
- Hinweise auf zukünftige Schwerpunkte
- Ableitung aus Entwicklungspotenzialen
- spätere Turnierbegleitung

### 15.8 Empfohlener operativer Workflow in Shinkan

#### Phase 1 – Planung
Der Trainer oder Verantwortliche:
- wählt Gruppe und Termin
- startet leer oder aus Vorlage / Standard / Kopie / Programmblock
- definiert oder übernimmt Trainingsabschnitte
- ordnet Übungen und ggf. Übungskomplexe zu
- ergänzt Schwerpunkte, Methoden und Hinweise

#### Phase 2 – Durchführung
Während des Trainings:
- nutzt der Trainer eine kompakte Durchführungssicht
- navigiert zwischen Abschnitten und Übungen
- markiert durchgeführte Inhalte
- passt Training bei Bedarf spontan an
- ergänzt kurze Notizen

#### Phase 3 – Nachbereitung
Nach dem Training:
- ergänzt der Trainer Reflexionen
- dokumentiert Abweichungen vom Plan
- hält Erfahrungen zu einzelnen Übungen fest
- überführt relevante Hinweise optional zurück in die Übung oder in den Vereinskontext

### 15.9 Wichtige Produktentscheidungen aus diesem Block

1. Es gibt **mehrere Planungsansichten**, nicht nur eine.
2. Planung ist **gruppen- und terminbezogen**, aber auch block- und programmorientiert möglich.
3. Trainingsabschnitte können Übungen zu **methodischen Komplexen** bündeln.
4. Die Durchführungssicht muss **schnell, flexibel und nicht restriktiv** sein.
5. Nachbereitung soll **Erfahrungswissen systematisch zurückspielen** können.
6. Druck und mobile Nutzung sind **gleich wichtig**.
7. Offline-Aspekte müssen früh berücksichtigt werden.

## 16. Ergänzende Erkenntnisse aus den Fachunterlagen

Die hochgeladenen Unterlagen untermauern die Notwendigkeit einer strukturierten, fachlich reichen Trainingsplanung:

- Die **Fähigkeitsmatrix** zeigt auf mehreren Seiten stufenweise Entwicklungsziele und Fähigkeitsbereiche, etwa in Kihon, Kumite, Selbstverteidigung sowie allgemeinen sportlichen Fähigkeiten. Das spricht dafür, Trainingspläne später gezielt an Fähigkeitsblöcken und Entwicklungszielen auszurichten. fileciteturn0file0
- Das **Fähigkeitsglossar** zeigt, dass Fähigkeiten als eigenständige fachliche Referenzen mit Beschreibung und Bedeutsamkeit gepflegt werden können. Das stützt den Ansatz, Trainingsschwerpunkte und Übungszuordnungen auf einen stabilen Fähigkeitskatalog zu stützen. fileciteturn0file1
- Das **Methodenglossar** zeigt, dass methodische Formen wie Rollenspiel, Zirkeltraining, Koordinationstraining, strukturierte Übung oder plyometrisches Training eigene fachliche Qualität besitzen und sich daher nicht nur als Freitext, sondern als strukturierte Planungsbausteine eignen. fileciteturn1file0

## 17. Konsolidierung von Governance, Rollen und Freigabe (Stufe 1)

### 17.1 Rollen in Stufe 1

Für Stufe 1 werden folgende Rollen berücksichtigt:
- Systemadmin
- Vereinsadmin
- Spartenadmin
- Trainer
- Co-Trainer
- Redakteur / Inhaltsverantwortlicher

### 17.2 Grundprinzip der Rechtevergabe

Alle Trainer dürfen grundsätzlich Inhalte anlegen.

Die Freigabe und Veröffentlichung auf höheren Ebenen wird über Admin-Level gesteuert:
- Systemadmin = appweite Ebene
- Vereinsadmin = Vereinsebene
- Spartenadmin = Sparte innerhalb eines Vereins

Trainer außerhalb der Admin-Gruppen legen Inhalte in Stufe 1 primär für sich selbst oder für den eigenen Verein an.

### 17.3 Inhaltsbereiche in Stufe 1

Mindestens folgende Inhaltsbereiche werden benötigt:
- Meine Übungen
- Vereinsübungen
- Offizielle Inhalte

Spätere Ausbaustufe:
- globale Community-Inhalte
- archivierte Inhalte als eigener Sichtbereich

### 17.4 Änderungslogik für freigegebene Inhalte

Eine vereinsübergreifende oder offizielle Standardübung darf durch einen normalen Trainer nicht direkt überschrieben werden.

Erlaubte Aktionen:
- Übung für sich selbst anpassen
- abgeleitete Version mit Referenz auf die Standardübung anlegen
- Änderungsrequest stellen

Nicht erlaubt:
- direkte globale Änderung ohne entsprechende Freigaberechte

### 17.5 Offizielle Inhalte auf Vereinsebene

Ein Verein soll offizielle Inhalte definieren können, insbesondere:
- offizielle Vereinsübungen
- offizielle Vereinsvorlagen
- offizielle Vereinsprogramme

### 17.6 Einfaches Freigabemodell mit Ebenenlogik

Für eigene Inhalte reicht in Stufe 1 ein einfaches Statusmodell.

Empfohlene Basisstatus:
- Entwurf
- freigegeben
- archiviert

Zusätzlich braucht es eine Freigabelogik je Ebene, damit Inhalte kontrolliert von einer niedrigeren auf eine höhere Ebene gehoben werden können.

Beispielhafte Freigabeebenen:
- privat / eigener Arbeitsstand
- Verein
- Sparte
- offiziell / global

### 17.7 Ziel der Governance in Stufe 1

Die Governance soll in Stufe 1 vor allem diese Ziele absichern:
- Redundanz reduzieren
- Homogenität fördern
- Wildwuchs begrenzen
- ausreichenden Detailgrad sichern
- lokale Anpassung ermöglichen, ohne Standards zu zerstören

### 17.8 Kompakte Produktempfehlung

Für die erste Umsetzung wird empfohlen:
- einfache Rollenlogik
- klare Ebenen für Sichtbarkeit und Freigabe
- Änderungsrequests statt Direktänderung an Standardinhalten
- Ableitung lokaler Varianten mit Referenz auf Ursprungsinhalt
- keine ausufernde Membership-Logik in Stufe 1

## 18. Kompakte MVP-Empfehlung für Release 1

### 18.1 Grundprinzip

Der MVP soll **einen vollständigen Kernworkflow für Trainer** abbilden, aber keine breite Plattformlogik vorwegnehmen.

Empfohlener Kernworkflow:
- bestehende Inhalte aus dem MediaWiki übernehmen
- Übung suchen oder anlegen
- Training für Gruppe und Termin planen
- Training mobil oder per Ausdruck durchführen
- Notizen und Anpassungen festhalten
- Inhalte später wiederverwenden

### 18.2 Objekte, die in Release 1 enthalten sein sollten

#### Pflicht in Release 1
- Verein
- Sparte
- Trainingsgruppe
- Fähigkeit
- Methode
- Übung
- Übungsvariante (schlank)
- Trainingseinheit
- Trainingsprogramm (schlank)

#### Fachlich notwendig, aber technisch zusammenlegbar
- Trainingsvorlage
- Standardtraining

Empfehlung:
Diese beiden Konzepte können in Release 1 technisch als gemeinsames Objekt mit Typ-/Kind-Feld umgesetzt werden, um Komplexität zu reduzieren.

#### Nicht als separates Objekt in Release 1 nötig
- Trainingstermin

Empfehlung:
Datum/Uhrzeit werden in Release 1 direkt an der Trainingseinheit geführt.

### 18.3 Pflichtfunktionen in Release 1

- MediaWiki-Import für bestehende Inhalte
- Übung anlegen und bearbeiten
- Übungsvarianten pflegen
- Fähigkeit- und Methodenbezüge pflegen
- Übung suchen und filtern
- Trainingseinheit planen
- Training aus Vorlage / Standard / alter Einheit / Programm ableiten
- Trainingsabschnitte inkl. Kombinations-Flag verwalten
- Druckansicht
- mobile Durchführungssicht
- Notizen zu Training und Übung
- einfache Freigabelogik für privat / Verein / offiziell

### 18.4 Funktionen, die bewusst nicht in Release 1 gehören

- KI-Trainingsplanung
- KI-Suche mit externen Calls
- Sportlerentwicklung / Coaching auf Individualebene
- Turnierbegleitung
- Community-/Marktplatzlogik
- komplexe Membership-Logik
- feingranulare Rechte-Matrix
- Vollhistorisierung jeder Planänderung
- bidirektionale Synchronisation mit dem MediaWiki

### 18.5 Empfehlung zur Mandantenfähigkeit

Release 1 sollte fachlich bereits auf mehrere Vereine vorbereiten, aber produktiv zunächst auf den Pilotverein fokussiert bleiben.

Empfehlung:
- Datenmodell mandantenfähig vorbereiten
- UI und Rechte zunächst einfach halten
- keine komplexe Multi-Tenant-Administration in Release 1

### 18.6 Empfehlung zu Offline und Mobilität

Release 1 sollte noch keine vollständige Offline-Synchronisation erzwingen.

Empfehlung:
- starke mobile Ansicht
- gute Druckansicht
- zentrale Trainingsinformationen lokal bzw. offline-nah verfügbar machen, soweit technisch einfach umsetzbar
- echte komplexe Offline-Sync als spätere Ausbaustufe behandeln

### 18.7 Empfehlung zum MediaWiki-Import

Der Import aus dem bestehenden MediaWiki sollte in Release 1 aufgenommen werden, aber bewusst begrenzt.

Empfehlung:
- **einseitiger Import nach Shinkan**
- **keine bidirektionale Synchronisation**
- **keine fortlaufende Live-Kopplung**
- Import zunächst für:
  - Fähigkeiten
  - Methoden
  - Übungen
- Programme und Trainings nur dann importieren, wenn die Datenqualität dafür ausreicht

Zusätzliche technische Empfehlungen:
- Quelle und externe ID speichern
- Importstatus speichern
- Inhalte nach Import überprüfbar markieren
- Standardinhalte nach Import in Shinkan weiterpflegen, nicht im Wiki

### 18.8 Warum diese MVP-Abgrenzung empfohlen wird

Diese Abgrenzung reduziert das Risiko, in Release 1 zu viel Infrastruktur und Sonderlogik zu bauen.

Gleichzeitig werden die später wichtigen Kernachsen bereits sauber vorbereitet:
- Fähigkeitskatalog
- Methodenkatalog
- Übungssystem
- Gruppen- und Trainingsplanung
- Ableitung statt Überschreiben
- Freigabelogik
- Importpfad aus dem Bestandssystem

### 18.9 Ergänzende Begründung aus den vorhandenen Fachunterlagen

Die Empfehlung, Fähigkeit und Methode bereits in Release 1 als eigenständige Objekte mitzunehmen, wird durch die vorhandenen Unterlagen gestützt:

- Die Fähigkeitsmatrix zeigt, dass Fähigkeiten bereits heute stufenbezogen und systematisch beschrieben werden. fileciteturn0file0
- Das Fähigkeitsglossar zeigt, dass Fähigkeiten bereits als eigenständiger Katalog mit Definitionen und Bedeutsamkeit vorliegen. fileciteturn0file1
- Das Methodenglossar zeigt, dass auch Methoden bereits als eigenständiger Katalog mit Beschreibungen und Fähigkeitsbezug existieren. fileciteturn1file0

## 19. Nächster Arbeitsschritt

Im nächsten Schritt sollte aus diesem Stand eine **ultrakompakte Umsetzungsfassung für einen Coding-Agenten** erstellt werden:
- Scope
- Kernobjekte
- Kernworkflows
- MVP-Abgrenzung
- spätere Ausbaustufen
- Annahmen / Nicht-Ziele