ankn/Orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Migrate all repos into monorepo context folders

Browse Source 
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
      Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
      Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)

Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
This commit is contained in:
ankn
2026-06-30 20:39:52 +02:00
parent 2f2b295531
commit a5f8fb49ab
1717 changed files with 447332 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
bahn/aisupport/steering/agent-behaviour.md
+2
View File
@@ -0,0 +1,2 @@
* If you're not certain about something, check the code.
* Ask clarifying questions until you are 95% sure we have a common understanding about the implementation.
bahn/aisupport/steering/codebase-summary.sop.md
+309
View File
@@ -0,0 +1,309 @@
# Codebase Summary
## Overview
This sop analyzes a codebase and generates comprehensive documentation including structured metadata files that describe the system architecture, components, interfaces, and workflows. It can create targeted documentation files like AGENTS.md (README for AI agents), README.md, CONTRIBUTING.md, or generate a complete documentation ecosystem. The documentation is organized to make it easy for AI assistants to understand the system and help with development tasks.
## Parameters
- **output_dir** (optional, default: ".agents/summary"): Directory where documentation will be stored
- **consolidate** (optional, default: true): Whether to create consolidated documentation files
- **consolidate_targets** (optional, default: "AGENTS.md"): Target files for consolidation, comma-separated (e.g., "AGENTS.md, README.md, CONTRIBUTING.md"). Only used if consolidate is true
- **consolidate_prompt** (optional): Description of how to structure the consolidated content for the target file type (e.g., Reference the AGENTS.md example below for the default "consolidate_prompt"). Only used if consolidate is true
- **check_consistency** (optional, default: true): Whether to check for inconsistencies across documents
- **check_completeness** (optional, default: true): Whether to identify areas lacking sufficient detail
- **update_mode** (optional, default: false): Whether to update existing documentation based on recent changes
- **codebase_path** (optional, default: current directory): Path to the codebase to analyze
**Constraints for parameter acquisition:**
- You MUST ask for all parameters upfront in a single prompt rather than one at a time
- You MUST support multiple input methods including:
- Direct input: Text provided directly in the conversation
- File path: Path to a local file containing codebase information
- Directory path: Path to the codebase to analyze
- Other methods: You SHOULD be open to other ways the user might want to specify the codebase
- You MUST use appropriate tools to access content based on the input method
- You MUST confirm successful acquisition of all parameters before proceeding
- You MUST validate that the codebase_path exists and is accessible
- If consolidate is false, you MUST inform the user that consolidate_targets and consolidate_prompt will be ignored
## Steps
### 1. Setup and Directory Structure
Initialize the analysis environment and create necessary directory structure.
**Constraints:**
- You MUST validate that the codebase_path exists and is accessible
- You MUST create the output_dir if it doesn't exist
- You MUST inform the user about the directory structure being created
- If update_mode is true, you MUST:
- Check if {output_dir}/.last_commit exists to determine the baseline commit
- Use git commands to review commits since the baseline and identify changes
- If update_mode is false or no previous documentation exists, you MUST inform the user that full analysis will be performed
- You MUST create subdirectories for organizing different types of documentation artifacts
### 2. Analyze Codebase Structure
Perform comprehensive analysis of the codebase to understand its structure, components, and relationships.
**Constraints:**
- You MUST use appropriate tools to gather information about the codebase structure
- You MUST identify all packages, modules, and major components in the codebase
- You MUST analyze file organization, directory structure, and architectural patterns
- You MUST identify supported and unsupported programming languages
- You MUST document the technology stack and dependencies
- You MUST create a hierarchical map of the codebase structure using Mermaid diagrams
- You MUST identify key interfaces, APIs, and integration points
- You MUST analyze code patterns and design principles used throughout the codebase
- You MUST use Mermaid diagrams for all visual representations instead of ASCII art
- You MUST document basic codebase information in {output_dir}/codebase_info.md
- If update_mode is true, you MUST:
- Analyze which packages and files were modified in recent commits
- Prioritize analysis of modified components
- Create a change summary document listing all relevant changes since last update
### 3. Generate Documentation Files
Create comprehensive documentation files for different aspects of the system.
**Constraints:**
- You MUST create a comprehensive knowledge base index file ({output_dir}/index.md) that:
- Provides explicit instructions for AI assistants on how to use the documentation
- Contains rich metadata about each file's purpose and content
- Includes a table of contents with descriptive summaries for each document
- Explains relationships between different documentation files
- Guides AI assistants on which files to consult for specific types of questions
- Contains brief summaries of each file's content to help determine relevance
- Is designed to be the primary file needed in context for AI assistants to effectively answer questions
- You MUST create documentation files for different aspects of the system:
- {output_dir}/architecture.md (system architecture and design patterns)
- {output_dir}/components.md (major components and their responsibilities)
- {output_dir}/interfaces.md (APIs, interfaces, and integration points)
- {output_dir}/data_models.md (data structures and models)
- {output_dir}/workflows.md (key processes and workflows)
- {output_dir}/dependencies.md (external dependencies and their usage)
- You MUST ensure each documentation file contains relevant information from the codebase analysis
- You MUST use Mermaid diagrams for all visual representations throughout the documentation
- You MUST NOT use ASCII art for any visual elements
- If update_mode is true, you MUST:
- Preserve existing documentation structure where possible
- Only update sections related to modified components
### 4. Review Documentation
Review the documentation for consistency and completeness.
**Constraints:**
- If check_consistency is true, you MUST check for inconsistencies across documents
- If check_completeness is true, you MUST identify areas lacking sufficient detail
- You MUST document any inconsistencies or gaps found in {output_dir}/review_notes.md
- You MUST specifically identify gaps resulting from language support limitations
- You SHOULD use insights from the codebase analysis to identify areas needing more detail
- You MUST provide recommendations for improving documentation quality
### 5. Consolidate Documentation
Create consolidated documentation files if requested.
**Constraints:**
- If consolidate is true, you MUST create consolidated documentation files for each target in consolidate_targets
- For each consolidate_target file that already exists, You MUST merge the new content with existing content rather than overwriting because this preserves valuable manually-curated content
- You MUST place consolidated files in the codebase root directory (outside of the output_dir)
- If consolidate_prompt is provided, you MUST use it to guide the structure and content of the consolidated files
- You MUST tailor the consolidated content to each target file type:
- AGENTS.md: Focus on AI assistant context, project and directory structure, development patterns, and assistant-specific instructions
- README.md: Focus on project overview, installation, usage, and getting started information
- CONTRIBUTING.md: Focus on development setup, coding standards, contribution workflow, and guidelines
- Other files: Adapt content based on filename and consolidate_prompt
- You MUST organize the consolidated content in a coherent structure appropriate for the target audience
- You MUST include a comprehensive table of contents with descriptive summaries
- You MUST add metadata tags to each section to facilitate targeted information retrieval
- You MUST include cross-references between related sections
- You MUST include information from all relevant documentation files
- If consolidate is false, you MUST skip this step and inform the user that no consolidated files will be created
### 6. Summary and Next Steps
Provide a summary of the documentation process and suggest next steps.
**Constraints:**
- You MUST save the current git HEAD commit hash to {output_dir}/.last_commit to enable future update_mode runs
- You MUST summarize what has been accomplished
- You MUST suggest next steps for using the documentation
- You MUST provide guidance on maintaining and updating the documentation
- You MUST include specific instructions for adding the documentation to AI assistant context:
- Recommend using the index.md file as the primary context file
- Explain how AI assistants can leverage the index.md file as a knowledge base to find relevant information
- Emphasize that the index.md contains sufficient metadata for assistants to understand which files contain detailed information
- Provide example queries that demonstrate how to effectively use the documentation
- If consolidate is true, you MUST provide guidance on using the consolidated files
- If update_mode was used, you MUST:
- Summarize what changes were detected and updated in the documentation
- Highlight any significant architectural changes
- Recommend areas that might need further manual review
## Examples
### Example Input (Default AGENTS.md)
```
output_dir: ".agents/summary"
consolidate: true
consolidate_targets: "AGENTS.md"
consolidate_prompt: "Create a comprehensive AGENTS.md file optimized for AI coding assistants. You MUST focus on information that is not already present in other documentation sources like README.md or CONTRIBUTING.md. Useful information for this file includes: File purpose, directory structure, Coding style patterns, file organization patterns, instructions on how to write and run tests, documentation guidelines, and package specific guidance."
codebase_path: "/path/to/project"
```
### Example Output (Generate Mode)
```
Setting up directory structure...
✅ Created directory .agents/summary/
✅ Created subdirectories for documentation artifacts
Analyzing codebase structure...
✅ Found 15 packages across 3 programming languages
✅ Identified 45 major components and 12 key interfaces
✅ Codebase information saved to .agents/summary/codebase_info.md
Generating documentation files...
✅ Created index.md with knowledge base metadata
✅ Generated architecture.md, components.md, interfaces.md
✅ Generated data_models.md, workflows.md, dependencies.md
Reviewing documentation...
✅ Consistency check complete
✅ Completeness check complete
✅ Review notes saved to .agents/summary/review_notes.md
Consolidating documentation...
✅ Created AGENTS.md optimized for AI coding assistants
✅ Included comprehensive project context and development guidance
Summary and Next Steps:
✅ Documentation generation complete!
✅ To use with AI assistants, add .agents/summary/index.md to context
✅ AGENTS.md provides comprehensive guidance for AI coding assistance
```
### Example Input (README.md)
```
consolidate_targets: "README.md"
consolidate_prompt: "Create a user-friendly README that explains the project purpose, installation, and usage"
```
### Example Input (No Consolidation)
```
consolidate: false
check_consistency: true
check_completeness: true
```
### Example Output (Update Mode)
```
Update mode detected - checking for changes...
✅ Found existing documentation
✅ Identified 8 commits since last update affecting 3 packages
Analyzing recent changes...
✅ Updated components: AuthService, DataProcessor, APIGateway
✅ Change summary saved to .agents/summary/recent_changes.md
Updating documentation...
✅ Updated architecture.md with new AuthService patterns
✅ Updated components.md with DataProcessor changes
✅ Updated interfaces.md with new API endpoints
Consolidating updated documentation...
✅ Updated AGENTS.md with recent changes
✅ Added "Recent Changes" section highlighting updates
Summary:
✅ Documentation updated based on 8 recent commits
✅ 3 major components updated in documentation
✅ Review .agents/summary/recent_changes.md for detailed change summary
```
### Example Output Structure
```
AGENTS.md (consolidated file in root directory)
.agents/summary/
├── .last_commit (git commit hash for update_mode baseline)
├── index.md (knowledge base index)
├── codebase_info.md
├── architecture.md
├── components.md
├── interfaces.md
├── data_models.md
├── workflows.md
├── dependencies.md
├── review_notes.md
└── recent_changes.md (if update_mode)
```
### Example Mermaid Diagram Types
The documentation will include various Mermaid diagram types:
**Architecture Overview:**
```mermaid
graph TB
A[Frontend] --> B[API Gateway]
B --> C[Auth Service]
B --> D[Business Logic]
D --> E[Database]
```
**Component Relationships:**
```mermaid
classDiagram
class UserService {
+authenticate()
+authorize()
}
class DataService {
+getData()
+saveData()
}
UserService --> DataService
```
**API Workflows:**
```mermaid
sequenceDiagram
Client->>API: Request
API->>Auth: Validate
Auth-->>API: Token Valid
API->>Service: Process
Service-->>API: Response
API-->>Client: Result
```
## Troubleshooting
### Large Codebase Performance
For very large codebases that take significant time to analyze:
- You SHOULD provide progress updates during analysis
- You SHOULD suggest focusing on specific directories or components if performance becomes an issue
- Consider running with consolidate=false to generate individual files faster
### Update Mode Issues
If update mode fails to detect changes correctly:
- Check if git history is available and accessible
- Try running with update_mode=false to generate fresh documentation
### Consolidation Issues
If consolidation fails or produces poor results:
- Check that consolidate_prompt provides clear guidance for the target file type
- Verify that all source documentation files were generated successfully
- Consider using a more specific consolidate_prompt for better results
### Missing Documentation Sections
If certain aspects of the codebase are not well documented:
- Check the review_notes.md file for identified gaps
- Consider running with check_completeness=true to identify missing areas
- Review the codebase analysis to ensure all components were properly identified
### Git Integration Problems
If git commands fail during update mode:
- Ensure the codebase_path is within a valid git repository
- Check that git is installed and accessible
- Verify that the user has appropriate permissions to read git history
bahn/aisupport/steering/einfachbahn-naming.md
+23
View File
@@ -0,0 +1,23 @@
---
inclusion: always
---
# Schreibweise: #Einfachbahn
Der Teamname wird **immer** mit vorangestelltem Hashtag und großem „E" geschrieben:
> **#Einfachbahn**
## Regeln
- Korrekt: `#Einfachbahn`
- Falsch: `einfachbahn`, `Einfachbahn`, `EinfachBahn`, `#einfachbahn`, `# Einfachbahn` (Leerzeichen nach `#`)
- Der Hashtag gehört direkt an das Wort, ohne Leerzeichen: `#Einfachbahn`.
- Gilt in Prosa, Dokumentation, Commit-Messages, READMEs und UI-Texten.
## Ausnahmen
- In technischen Bezeichnern (URLs, Repo-/Pfadnamen, Slugs, Code-Identifier) bleibt die
jeweils dort gültige Schreibweise erhalten, z. B. `einfachbahn-lab` in GitLab-Pfaden.
- In Markdown-Überschriften das `#` der Überschrift nicht mit dem Marken-Hashtag
verwechseln — die Marke schreibt sich dort `# #Einfachbahn ...`.
bahn/aisupport/steering/onboarding-dokumentation.md
+409
View File
@@ -0,0 +1,409 @@
---
inclusion: manual
---
# Onboarding-Dokumentation erstellen
> **Nutzung:** Referenziere diese Datei mit `#onboarding-dokumentation` im Chat und sage:
> "Erstelle eine Onboarding-Dokumentation für dieses Projekt anhand des Plans."
---
## Ziel
Automatische Erstellung einer Onboarding-/Migrationsdokumentation mit Fokus auf:
- Fachliche End-to-End-Flüsse
- Externe Schnittstellen
- Zentrale Datenobjekte
## Diagramm-Standard
**WICHTIG:** Alle Diagramme MÜSSEN als Mermaid-Diagramme erstellt werden. PlantUML ist NICHT erlaubt.
Mermaid-Diagramme werden direkt in Markdown-Dateien als Codeblöcke eingebettet ( `mermaid ).
Es werden KEINE separaten Diagramm-Dateien erzeugt.
## Ausgabestruktur
```
docs/
index.md # Überblick, Schnellstart
assumptionAndRisks.md # Annahmen, Risiken, offene Fragen
architecture/
context.md # Architekturkontext (mit eingebetteten Mermaid-Diagrammen)
domain/
data_model.md # Datenmodell (mit eingebetteten Mermaid-Diagrammen)
processes/
[prozessname].md # Je ein Dokument pro Fluss (mit eingebetteten Mermaid-Diagrammen)
interfaces/
external.md # Externe Schnittstellen
nfr.md # Nicht-funktionale Anforderungen
```
---
## Fortschritt
| Task | Status | Ergebnis |
|------|--------|----------|
| 1. Inventar & Autodetektion | Offen | - |
| 2. Architektur-Kontext | Offen | - |
| 3. Fachliche Flüsse | Offen | - |
| 4. Externe Schnittstellen | Offen | - |
| 5. Datenmodell | Offen | - |
| 6. NFRs & Monitoring | Offen | - |
| 7. Abschluss & Konsolidierung | Offen | - |
**Legende:** Offen | In Arbeit | Erledigt | Blockiert
**Ermittelte Systeminfos (Task 1 ausfüllen):**
- Systemname: _[wird ermittelt]_
- Systemtyp: _[wird ermittelt]_
- Haupttechnologien: _[wird ermittelt]_
---
## Task 1: Inventar & Autodetektion
### Aufgaben
- [ ] 1.1 Systemname ermitteln (aus pom.xml, package.json, .csproj, oder Verzeichnisname)
- [ ] 1.2 Systemtyp bestimmen (Integrationssystem / Microservices / Monolith / Batch)
- [ ] 1.3 Repository scannen nach Quellcode und Konfigurationen
- [ ] 1.4 Technologien erkennen (Sprachen, Frameworks, Integrationsplattformen)
- [ ] 1.5 Inventar-Tabelle erstellen
- [ ] 1.6 `docs/index.md` erstellen
- [ ] 1.7 `docs/assumptionAndRisks.md` erstellen
### Suchmuster für Technologien
| Typ | Dateien/Patterns |
|-----|------------------|
| Java | `.java`, `pom.xml`, `build.gradle` |
| .NET | `.cs`, `.csproj`, `.sln` |
| JavaScript/TypeScript | `.js`, `.ts`, `package.json` |
| Python | `.py`, `requirements.txt`, `pyproject.toml` |
| TIBCO | `.process`, `.xpdl`, Adapter-Configs |
| Integration | WSDL, XSD, JMS/JDBC/HTTP/FTP Configs |
### Systemtyp-Heuristik
| Indikator | Systemtyp |
|-----------|-----------|
| TIBCO .process, MuleSoft, Camel | Integrationssystem |
| Mehrere Services, Docker/K8s | Microservices |
| Ein Deployment, klare Module | Modularer Monolith |
| Ein Deployment, keine Module | Monolith |
| Scheduler, Jobs | Batch-System |
### Ausgabe: `docs/index.md`
```markdown
# Projektdokumentation: [Systemname]
## Überblick
| Attribut | Wert |
|----------|------|
| Systemname | ... |
| Systemtyp | ... |
| Hauptsprache(n) | ... |
| Frameworks | ... |
[2-3 Sätze zum Projektzweck]
## Modulübersicht
| Modul | Zweck | Technologie | Pfad |
|-------|-------|-------------|------|
## Dokumentation
- [Architektur](architecture/context.md)
- [Datenmodell](domain/data_model.md)
- [Prozesse](processes/)
- [Schnittstellen](interfaces/external.md)
- [NFRs](nfr.md)
```
Nach Abschluss: Status auf , Systeminfos eintragen, weiter mit Task 2
---
## Task 2: Architektur-Kontext
### Aufgaben
- [ ] 2.1 Externe Systeme identifizieren (HTTP, Messaging, DB, Datei, Mail)
- [ ] 2.2 Interne Komponenten gruppieren (Core, Integration, Data Access)
- [ ] 2.3 Kommunikationsarten dokumentieren (Protokoll, Richtung, sync/async)
- [ ] 2.4 `docs/architecture/context.md` erstellen (mit eingebetteten Mermaid-Diagrammen)
### Suchmuster
| Typ | Suche nach |
|-----|------------|
| HTTP/SOAP | URLs, WSDL, REST-Clients, `@WebService` |
| Messaging | JMS-Queues, Kafka-Topics, RV-Subjects |
| Datenbank | JDBC-URLs, DataSource-Configs |
| Datei/FTP | FTP-Hosts, SFTP-Configs, Dateipfade |
| Mail | SMTP/IMAP-Server |
### Mermaid-Template: Architekturkontext
```mermaid
graph TB
subgraph system["[Systemname]"]
core["Core Processing"]
integration["Integration Layer"]
data["Data Access"]
end
subgraph external["Externe Systeme"]
http["HTTP/SOAP Endpoint"]
mq["Message Broker"]
db[("Datenbank")]
end
integration -->|REST/SOAP| http
integration -->|JMS| mq
data -->|JDBC| db
```
Nach Abschluss: Status auf , weiter mit Task 3
---
## Task 3: Fachliche Flüsse
### Aufgaben
- [ ] 3.1 Zentrale End-to-End-Flüsse identifizieren (3-7 Stück)
- [ ] 3.2 Pro Fluss: Trigger, Schritte, Entscheidungen, Fehlerbehandlung analysieren
- [ ] 3.3 Pro Fluss: `docs/processes/[name].md` erstellen (mit eingebetteten Mermaid-Diagrammen)
### Priorisierung
1. Geschäftskritische Prozesse
2. Häufig ausgeführte Flüsse
3. Komplexe Integrationsflüsse
### Analyse pro Fluss
| Aspekt | Fragen |
|--------|--------|
| Trigger | Was startet den Fluss? |
| Eingaben | Welche Daten? |
| Schritte | Welche Verarbeitung? |
| Entscheidungen | Welche Verzweigungen? |
| Fehler | Wie behandelt? |
| Ausgaben | Was produziert? |
### Mermaid-Template: Prozessfluss (Flowchart)
**WICHTIG:** Prozessdiagramme MÜSSEN als Mermaid Flowcharts erstellt werden.
```mermaid
flowchart TD
start([Start]) --> trigger["Trigger empfangen<br/><i>System A</i>"]
trigger --> validate["Daten validieren<br/><i>System B</i>"]
validate --> check{Validierung OK?}
check -->|ja| transform["Daten transformieren<br/><i>System B</i>"]
transform --> external["Externe Verarbeitung<br/><i>System C</i>"]
external --> result["Ergebnis zurückliefern<br/><i>System C</i>"]
result --> process["Ergebnis verarbeiten<br/><i>System B</i>"]
process --> respond["Ergebnis an Aufrufer senden<br/><i>System A</i>"]
respond --> ende([Ende])
check -->|nein| logError["Fehler loggen<br/><i>System B</i>"]
logError --> notify["Fehlerbenachrichtigung<br/><i>System A</i>"]
notify --> fehlerEnde([Ende])
style start fill:#2d6a4f,color:#fff
style ende fill:#2d6a4f,color:#fff
style fehlerEnde fill:#d00000,color:#fff
style check fill:#ffd166,color:#000
```
### Alternativ: Mermaid Sequenzdiagramm (für Nachrichtenflüsse)
```mermaid
sequenceDiagram
participant A as System A
participant B as System B
participant C as System C
A->>B: Trigger senden
B->>B: Daten validieren
alt Validierung OK
B->>C: Externe Verarbeitung
C-->>B: Ergebnis
B-->>A: Erfolgsantwort
else Validierung fehlgeschlagen
B-->>A: Fehlerbenachrichtigung
end
```
### Mermaid Flowchart-Elemente
| Element | Syntax | Verwendung |
|---------|--------|------------|
| Start/Ende | `([Text])` | Prozessbeginn/-ende (Stadion-Form) |
| Aktion | `["Text"]` | Einzelner Schritt (Rechteck) |
| Entscheidung | `{Text}` | Verzweigung (Raute) |
| Richtung | `-->` / `-->|Label|` | Verbindung mit optionalem Label |
| Subgraph | `subgraph Name ... end` | Gruppierung/Swimlane |
| Styling | `style nodeId fill:#color` | Visuelle Hervorhebung |
Nach Abschluss: Status auf , weiter mit Task 4
---
## Task 4: Externe Schnittstellen
### Aufgaben
- [ ] 4.1 Alle Schnittstellen aus Task 2 detailliert dokumentieren
- [ ] 4.2 Pro Schnittstelle: Endpunkt, Format, Auth, Operationen erfassen
- [ ] 4.3 Fehlerbehandlung dokumentieren (Retry, DLQ, Timeout)
- [ ] 4.4 `docs/interfaces/external.md` erstellen
### Dokumentation pro Schnittstelle
| Feld | Beschreibung |
|------|--------------|
| ID | IF-001, IF-002, ... |
| Name | Sprechender Name |
| Typ | HTTP/JMS/JDBC/FTP/SMTP |
| Richtung | IN/OUT/BIDI |
| Endpunkt | URL/Queue/Tabelle/Pfad |
| Format | XML/JSON/CSV |
| Auth | Basic/OAuth/Cert |
| Fehlerbehandlung | Retry, Timeout, DLQ |
Nach Abschluss: Status auf , weiter mit Task 5
---
## Task 5: Datenmodell
### Aufgaben
- [ ] 5.1 Domänenobjekte identifizieren (Entities, Value Objects, DTOs)
- [ ] 5.2 Nach Domänenbereichen gruppieren
- [ ] 5.3 Beziehungen analysieren (Assoziation, Aggregation, Vererbung)
- [ ] 5.4 `docs/domain/data_model.md` erstellen (mit eingebetteten Mermaid-Diagrammen)
### Quellen
- Java/C# Klassen
- XML/XSD Schemata
- WSDL Types
- DB-Tabellen/Views
- JSON Schemas
### Mermaid-Template: Datenmodell (Klassendiagramm)
```mermaid
classDiagram
class Entity {
<<Entity>>
+String id
+String name
}
class ValueObject {
<<ValueObject>>
+Type field
}
Entity "1" *-- "*" ValueObject
note for Entity "Quelle: path/to/file"
```
### Mermaid-Template: Entity-Relationship-Diagramm
```mermaid
erDiagram
ENTITY ||--o{ VALUE_OBJECT : enthält
ENTITY {
string id PK
string name
}
VALUE_OBJECT {
string field
}
```
Nach Abschluss: Status auf , weiter mit Task 6
---
## Task 6: Nicht-funktionale Anforderungen & Monitoring
### Aufgaben
- [ ] 6.1 Performance-Configs suchen (Timeouts, Pools, Caching)
- [ ] 6.2 Resilienz-Configs suchen (Retry, Circuit Breaker, DLQ)
- [ ] 6.3 Sicherheits-Configs suchen (Auth, Verschlüsselung, Audit)
- [ ] 6.4 Observability-Configs suchen (Logging, Metriken, Health)
- [ ] 6.5 Monitoring & Alerting analysieren (siehe unten)
- [ ] 6.6 `docs/nfr.md` erstellen
**Wichtig:** Nur explizit konfigurierte NFRs dokumentieren!
### Monitoring & Alerting
**Hinweis:** Dieser Bereich wird nur dokumentiert, wenn im Projekt tatsächlich Monitoring- oder Alerting-Konfigurationen vorhanden sind. Nicht alle Projekte haben dies implementiert — das ist ein valides Ergebnis und sollte als Lücke in `docs/assumptionAndRisks.md` festgehalten werden.
#### Suchmuster
| Typ | Dateien/Patterns |
|-----|------------------|
| Metriken | Prometheus-Configs, Micrometer, `@Timed`, `@Counted`, Custom Metrics |
| Health Checks | `/actuator/health`, Liveness/Readiness Probes, Health-Endpoints |
| Alerting | Alert-Rules, Grafana-Dashboards, PagerDuty/OpsGenie-Configs |
| Logging | Log-Level-Configs, Structured Logging, ELK/Splunk-Configs |
| Tracing | OpenTelemetry, Jaeger, Zipkin, Correlation-IDs |
#### Dokumentation (falls vorhanden)
| Feld | Beschreibung |
|------|--------------|
| Metriken | Welche Metriken werden exponiert? |
| Dashboards | Gibt es vorkonfigurierte Dashboards? |
| Alerts | Welche Alert-Regeln sind definiert? |
| Health Checks | Welche Health-Endpoints existieren? |
| Log-Strategie | Structured Logging, Log-Level, Ziel-System |
Nach Abschluss: Status auf , weiter mit Task 7
---
## Task 7: Abschluss & Konsolidierung
### Aufgaben
- [ ] 7.1 `docs/assumptionAndRisks.md` aktualisieren mit Erkenntnissen aus allen Tasks
- [ ] 7.2 Alle `<!-- TODO: -->` aus Dokumenten sammeln
- [ ] 7.3 Querverweise zwischen Dokumenten prüfen
- [ ] 7.4 `docs/index.md` finalisieren
- [ ] 7.5 Gesamtdokumentation auf Vollständigkeit prüfen
### Checkliste für Annahmen/Risiken
| Task | Typische Themen |
|------|-----------------|
| 1 | Unklare Modulzwecke, veraltete Abhängigkeiten |
| 2 | Unbekannte externe Systeme |
| 3 | Fehlende Fehlerbehandlung, unklare Regeln |
| 4 | Fehlende Auth-Doku, unklare SLAs |
| 5 | Inkonsistente Schemata |
| 6 | Implizite Annahmen |
Nach Abschluss: Alle Status auf , Dokumentation fertig!
---
## Globale Regeln
### Diagramme
**Alle Diagramme MÜSSEN als Mermaid-Diagramme erstellt werden.** PlantUML ist NICHT erlaubt.
Diagramme werden direkt in die jeweiligen Markdown-Dokumente eingebettet keine separaten Diagramm-Dateien.
Empfohlene Mermaid-Diagrammtypen:
| Zweck | Mermaid-Typ | Syntax |
|-------|-------------|--------|
| Architekturübersicht | Flowchart | `graph TB` / `graph LR` |
| Komponentenbeziehungen | Klassendiagramm | `classDiagram` |
| Prozessflüsse | Flowchart | `flowchart TD` |
| Nachrichtenflüsse | Sequenzdiagramm | `sequenceDiagram` |
| Datenmodell | Klassendiagramm / ER | `classDiagram` / `erDiagram` |
| Zustandsübergänge | State-Diagramm | `stateDiagram-v2` |
### Quellenverweise
Jede Aussage mit Dateipfad belegen: `[Quelle: path/to/file:zeile]`
### Unklarheiten
Mit `<!-- TODO: Beschreibung -->` markieren
---
## Offene Fragen
| ID | Task | Frage | Priorität |
|----|------|-------|-----------|
| | | | |