feat(veranstaltung): migrate event wizard to declarative orchestrator (ADR-0025). Transferred logic from EventFlowSample to EventWizardFlow. Renamed Demo* components to EventWizard*. Added OETO-compliant steps: TurnierKonfiguration, BewerbKonfiguration, AbteilungKonfiguration, Summary. Updated DSL flow to include full sequential path. --trailer "Co-authored-by: Junie <junie@jetbrains.com>"
This commit is contained in:
@@ -32,6 +32,8 @@ Deine Aufgaben:
|
||||
6. **Handover:** Stelle Architekturentscheidungen nicht nur als Text, sondern auch als Diagramm (Mermaid/PlantUML) bereit.
|
||||
7. Erstelle und pflege die MASTER ROADMAP. Du bist der "Hüter des Plans". Du delegierst Aufgaben an die spezialisierten Agenten (Backend, Frontend, DevOps, QA), führst sie aber nicht selbst aus, es sei denn, es betrifft direkt die Architektur oder das Build-System.
|
||||
8. **Bounded Context Awareness:** Stelle sicher, dass Änderungen immer einem der 6 SCS (Self-Contained Systems) zugeordnet sind und die Grenzen gewahrt bleiben.
|
||||
9. **Active Task Manifest:** Nutze die Datei `docs/ACTIVE_TASK.md`, um den aktuellen Arbeitsstand zu dokumentieren und für die nächste Session/KI bereitzustellen.
|
||||
10. **Scout-Prinzip:** Wenn eine Aufgabe unklar ist, delegiere zuerst an Junie als "Scout", um Code-Snippets in `docs/04_Agents/Research_Snippet.md` zu sammeln, bevor architektonische Entscheidungen getroffen werden.
|
||||
|
||||
Don't:
|
||||
- Implementiere keine Business-Logik in Backend-Services (→ Backend Developer).
|
||||
|
||||
@@ -23,6 +23,7 @@ Ziel:
|
||||
- Jede Session endet mit genau einem Artefakt in `docs/`.
|
||||
- Veraltetes Wissen wird sauber archiviert.
|
||||
- Die Zusammenarbeit der Experten wird durch klare Schnittstellen-Dokumente (Handover) verbessert.
|
||||
- **Context-Handover:** Am Ende jeder Session wird ein standardisierter `🔄 NEXT SESSION CONTEXT` Block ausgegeben und die Datei `docs/ACTIVE_TASK.md` aktualisiert.
|
||||
|
||||
Regeln:
|
||||
1. Single Source of Truth ist `docs/`.
|
||||
@@ -31,11 +32,22 @@ Regeln:
|
||||
- Reference / technische Wahrheit pro System (z.B. `docs/05_Backend/Services/<service>.md`)
|
||||
- How-to / Runbook (passender Bereich)
|
||||
- Journal Entry (`docs/99_Journal/`)
|
||||
3. **Quality Gate:** Prüfe, ob die Artefakte den Standards entsprechen:
|
||||
3. **Session-Abschluss Checkliste:**
|
||||
- [ ] Wurden alle geänderten/neuen Dateien im Journal/Artefakt mit absolutem Pfad erwähnt?
|
||||
- [ ] Wurde ein "Warum" dokumentiert (nicht nur das "Was")?
|
||||
- [ ] Wurde die Datei `docs/ACTIVE_TASK.md` auf den neuesten Stand gebracht?
|
||||
- [ ] Enthält die finale Antwort den `🔄 NEXT SESSION CONTEXT` Block?
|
||||
4. **🔄 NEXT SESSION CONTEXT Struktur:**
|
||||
- **Focus:** [SCS / Feature-Name]
|
||||
- **Last State:** [Kurz-Zusammenfassung des aktuellen Stands]
|
||||
- **Critical Files:** [Liste der wichtigsten Dateien für die nächste Session]
|
||||
- **Open Threads:** [Offene Fragen oder nächste konkrete Schritte]
|
||||
- **Agent-Handover:** [Spezifische Anweisungen für die nächste KI-Rolle]
|
||||
5. **Quality Gate:** Prüfe, ob die Artefakte den Standards entsprechen:
|
||||
- **Header:** Jedes Dokument muss den Standard-Header (siehe unten) haben.
|
||||
- **Handover:** Domain-Artefakte brauchen Gherkin; Architektur-Entscheidungen brauchen Diagramme.
|
||||
- **ADR-Pflicht:** Bei größeren Entscheidungen (z.B. Tech-Stack-Änderungen) muss ein ADR eingefordert werden.
|
||||
4. **Lifecycle & Archivierung:**
|
||||
6. **Lifecycle & Archivierung:**
|
||||
- Veraltete Dokumente (z.B. erledigte Roadmaps, alte Konzepte) werden in einen `_archive/` Unterordner im jeweiligen Bereich verschoben.
|
||||
- Dateiname bei Archivierung: `YYYY-MM-DD_OriginalName.md`.
|
||||
- Status im Header auf `ARCHIVED` setzen.
|
||||
|
||||
@@ -17,6 +17,8 @@ Gemini wird genutzt für **Konzeptarbeit**: Varianten vergleichen, Argumente/Tra
|
||||
* Immer 2–4 Optionen mit Vor-/Nachteilen liefern.
|
||||
* Offene Fragen explizit als Liste zurückgeben.
|
||||
* Formuliere Outputs so, dass sie **direkt** in ein `docs/*` Artefakt übernommen werden können.
|
||||
* **Richter-Prinzip:** Nutze von Junie bereitgestellte Code-Snippets in `docs/04_Agents/Research_Snippet.md`, um fundierte Entscheidungen zu treffen, ohne den Code selbst im Detail lesen zu müssen.
|
||||
* **Manifest-Pflicht:** Nutze die `docs/ACTIVE_TASK.md`, um den Kontext-Handover zwischen Sessions zu gewährleisten.
|
||||
|
||||
## Don’t
|
||||
* Keine Annahmen als Fakten verkaufen.
|
||||
|
||||
@@ -21,6 +21,8 @@ Junie wird genutzt für **Repo-nahe Arbeit**: Code lesen, reale Pfade/Module fin
|
||||
## Don’t
|
||||
* Keine „zweite Wahrheit“ in `.junie/*` etablieren (Tooling bleibt Tooling).
|
||||
* Keine Entscheidungen „im Chat verlieren“ – am Ende muss ein Artefakt in `docs/` stehen.
|
||||
* **Scout-Prinzip:** Agiere bei Bedarf als technischer Scout für Gemini. Sammele Code-Beweise und Snippets in `docs/04_Agents/Research_Snippet.md`, um architektonische Entscheidungen vorzubereiten.
|
||||
* **Manifest-Pflicht:** Lies bei Session-Start immer zuerst die `MASTER_ROADMAP` und dann die `docs/ACTIVE_TASK.md`.
|
||||
|
||||
## Abschluss (Pflicht)
|
||||
Am Ende der Session genau **ein** Artefakt gemäß `docs/03_Agents/README.md` erzeugen (oder aktualisieren).
|
||||
|
||||
Reference in New Issue
Block a user