Mitwirken¶

Andere Sprachen¶

Erfahren Sie, wie Sie zum Symbiont-Projekt beitragen koennen -- von der Meldung von Problemen bis zur Einreichung von Codeaenderungen.

Inhaltsverzeichnis¶

Ueberblick¶

Symbiont freut sich ueber Beitraege aus der Community! Ob Sie Bugs beheben, Features hinzufuegen, Dokumentation verbessern oder Feedback geben -- Ihre Beitraege helfen, Symbiont fuer alle besser zu machen.

Moeglichkeiten zur Mitwirkung¶

• Fehlerberichte: Helfen Sie, Probleme zu identifizieren und zu loesen
• Feature-Anfragen: Schlagen Sie neue Faehigkeiten und Verbesserungen vor
• Dokumentation: Verbessern Sie Anleitungen, Beispiele und API-Dokumentation
• Code-Beitraege: Beheben Sie Bugs und implementieren Sie neue Features
• Sicherheit: Melden Sie Sicherheitsluecken verantwortungsvoll
• Testen: Fuegen Sie Testfaelle hinzu und verbessern Sie die Testabdeckung

Erste Schritte¶

Voraussetzungen¶

Stellen Sie vor der Mitwirkung sicher, dass Sie Folgendes haben:

• Rust 1.88+ mit cargo
• Git fuer Versionskontrolle
• Docker fuer Tests und Entwicklung
• Grundkenntnisse in Rust, Sicherheitsprinzipien und KI-Systemen

Entwicklungsumgebung einrichten¶

1. Repository forken und klonen

   # Repository auf GitHub forken, dann Ihren Fork klonen
   git clone https://github.com/YOUR_USERNAME/symbiont.git
   cd symbiont
   
   # Upstream-Remote hinzufuegen
   git remote add upstream https://github.com/thirdkeyai/symbiont.git
   

2. Entwicklungsumgebung einrichten

   # Rust-Abhaengigkeiten installieren
   rustup update
   rustup component add rustfmt clippy
   
   # Pre-Commit-Hooks installieren
   cargo install pre-commit
   pre-commit install
   
   # Projekt bauen
   cargo build
   

3. Tests ausfuehren

   # Alle Tests ausfuehren
   cargo test --workspace
   
   # Spezifische Testsuiten ausfuehren
   cargo test --package symbiont-dsl
   cargo test --package symbiont-runtime
   
   # Mit Coverage ausfuehren
   cargo tarpaulin --out html
   

4. Entwicklungsdienste starten

   # Erforderliche Dienste mit Docker Compose starten
   docker-compose up -d redis postgres
   
   # Dienste ueberpruefen
   cargo run --example basic_agent
   

Entwicklungsrichtlinien¶

Code-Standards¶

Rust-Code-Stil: - rustfmt fuer konsistente Formatierung verwenden - Rust-Namenskonventionen befolgen - Idiomatischen Rust-Code schreiben - Umfassende Dokumentation einschliessen - Unit-Tests fuer alle neuen Funktionalitaeten hinzufuegen

Sicherheitsanforderungen: - Gesamter sicherheitsrelevanter Code muss ueberpieft werden - Kryptographische Operationen muessen zugelassene Bibliotheken verwenden - Eingabevalidierung ist fuer alle oeffentlichen APIs erforderlich - Sicherheitstests muessen Sicherheitsfeatures begleiten

Performance-Richtlinien: - Performance-kritischen Code benchmarken - Unnoetige Allokationen in Hot Paths vermeiden - async/await fuer I/O-Operationen verwenden - Speichernutzung fuer ressourcenintensive Features profilen

Code-Organisation¶

symbiont/
├── dsl/                    # DSL-Parser und Grammatik
│   ├── src/
│   ├── tests/
│   └── tree-sitter-symbiont/
├── runtime/                # Kern-Laufzeitsystem
│   ├── src/
│   │   ├── api/           # HTTP-API (optional)
│   │   ├── context/       # Kontextverwaltung
│   │   ├── integrations/  # Externe Integrationen
│   │   ├── rag/           # RAG-Engine
│   │   ├── scheduler/     # Aufgabenplanung
│   │   └── types/         # Kern-Typdefinitionen
│   ├── examples/          # Anwendungsbeispiele
│   ├── tests/             # Integrationstests
│   └── docs/              # Technische Dokumentation
├── enterprise/             # Enterprise-Features
│   └── src/
└── docs/                  # Community-Dokumentation

Commit-Richtlinien¶

Commit-Nachrichtenformat:

<type>(<scope>): <description>

[optionaler Textkörper]

[optionale Fußzeile]

Typen: - feat: Neues Feature - fix: Fehlerbehebung - docs: Dokumentationsaenderungen - style: Code-Stilaenderungen (Formatierung, etc.) - refactor: Code-Refactoring - test: Hinzufuegen oder Aktualisieren von Tests - chore: Wartungsaufgaben

Beispiele:

feat(runtime): add multi-tier sandbox support

Implements Docker, gVisor, and Firecracker isolation tiers with
automatic risk assessment and tier selection.

Closes #123

fix(dsl): resolve parser error with nested policy blocks

The parser was incorrectly handling nested policy definitions,
causing syntax errors for complex security configurations.

docs(security): update cryptographic implementation details

Add detailed documentation for Ed25519 signature implementation
and key management procedures.

Arten von Beitraegen¶

Fehlerberichte¶

Bitte geben Sie beim Melden von Fehlern Folgendes an:

Erforderliche Informationen: - Symbiont-Version und Plattform - Minimale Reproduktionsschritte - Erwartetes vs. tatsaechliches Verhalten - Fehlermeldungen und Logs - Umgebungsdetails

Fehlerbericht-Vorlage:

## Fehlerbeschreibung
Kurze Beschreibung des Problems

## Reproduktionsschritte
1. Schritt eins
2. Schritt zwei
3. Schritt drei

## Erwartetes Verhalten
Was passieren sollte

## Tatsaechliches Verhalten
Was tatsaechlich passiert

## Umgebung
- OS: [z.B. Ubuntu 22.04]
- Rust-Version: [z.B. 1.88.0]
- Symbiont-Version: [z.B. 1.0.0]
- Docker-Version: [falls zutreffend]

## Zusaetzlicher Kontext
Alle weiteren relevanten Informationen

Feature-Anfragen¶

Prozess fuer Feature-Anfragen: 1. Vorhandene Issues nach aehnlichen Anfragen pruefen 2. Detailliertes Feature-Anfrage-Issue erstellen 3. An Diskussion und Design teilnehmen 4. Feature gemaess den Richtlinien implementieren

Feature-Anfrage-Vorlage:

## Feature-Beschreibung
Klare Beschreibung des vorgeschlagenen Features

## Motivation
Warum wird dieses Feature benoetigt? Welches Problem loest es?

## Detailliertes Design
Wie soll dieses Feature funktionieren? Beispiele einschliessen, wenn moeglich.

## Betrachtete Alternativen
Welche anderen Loesungen wurden in Betracht gezogen?

## Implementierungshinweise
Technische Ueberlegungen oder Einschraenkungen

Code-Beitraege¶

Pull-Request-Prozess:

1. Feature-Branch erstellen

   git checkout -b feature/descriptive-name
   

2. Aenderungen implementieren

3. Code gemaess den Stilrichtlinien schreiben
4. Umfassende Tests hinzufuegen
5. Dokumentation bei Bedarf aktualisieren

6. Sicherstellen, dass alle Tests bestehen

7. Aenderungen committen

   git add .
   git commit -m "feat(component): descriptive commit message"
   

8. Pushen und PR erstellen

   git push origin feature/descriptive-name
   # Pull Request auf GitHub erstellen
   

Pull-Request-Anforderungen: - [ ] Alle Tests bestehen - [ ] Code entspricht den Stilrichtlinien - [ ] Dokumentation ist aktualisiert - [ ] Sicherheitsimplikationen sind beruecksichtigt - [ ] Performance-Auswirkungen sind bewertet - [ ] Breaking Changes sind dokumentiert

Dokumentationsbeitraege¶

Dokumentationstypen: - Benutzeranleitungen: Helfen Benutzern, Features zu verstehen und zu verwenden - API-Dokumentation: Technische Referenz fuer Entwickler - Beispiele: Funktionierende Codebeispiele und Tutorials - Architekturdokumentation: Systemdesign und Implementierungsdetails

Dokumentationsstandards: - Klare, praegnante Prosa schreiben - Funktionierende Codebeispiele einschliessen - Konsistente Formatierung und Stil verwenden - Alle Codebeispiele testen - Verwandte Dokumentation aktualisieren

Dokumentationsstruktur:

---
layout: default
title: Seitentitel
nav_order: N
description: "Kurze Seitenbeschreibung"
---

# Seitentitel

Kurzer Einleitungsabsatz.

## Inhaltsverzeichnis


---

## Inhaltsabschnitte...

Testrichtlinien¶

Testtypen¶

Unit-Tests: - Einzelne Funktionen und Module testen - Externe Abhaengigkeiten mocken - Schnelle Ausfuehrung (<1s pro Test)

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_policy_evaluation() {
        let policy = Policy::new("test_policy", PolicyRules::default());
        let context = PolicyContext::new();
        let result = policy.evaluate(&context);
        assert_eq!(result, PolicyDecision::Allow);
    }
}

Integrationstests: - Komponenteninteraktionen testen - Wo moeglich echte Abhaengigkeiten verwenden - Moderate Ausfuehrungszeit (<10s pro Test)

#[tokio::test]
async fn test_agent_lifecycle() {
    let runtime = test_runtime().await;
    let agent_config = AgentConfig::default();

    let agent_id = runtime.create_agent(agent_config).await.unwrap();
    let status = runtime.get_agent_status(agent_id).await.unwrap();

    assert_eq!(status, AgentStatus::Ready);
}

Sicherheitstests: - Sicherheitskontrollen und Policies testen - Kryptographische Operationen verifizieren - Angriffsszenarien testen

#[tokio::test]
async fn test_sandbox_isolation() {
    let sandbox = create_test_sandbox(SecurityTier::Tier2).await;

    // Versuch, auf eingeschraenkte Ressource zuzugreifen
    let result = sandbox.execute_malicious_code().await;

    // Sollte durch Sicherheitskontrollen blockiert werden
    assert!(result.is_err());
    assert_eq!(result.unwrap_err(), SandboxError::AccessDenied);
}

Testdaten¶

Test-Fixtures: - Konsistente Testdaten ueber Tests hinweg verwenden - Wo moeglich fest codierte Werte vermeiden - Testdaten nach der Ausfuehrung aufraeumen

pub fn create_test_agent_config() -> AgentConfig {
    AgentConfig {
        id: AgentId::new(),
        name: "test_agent".to_string(),
        security_tier: SecurityTier::Tier1,
        memory_limit: 512 * 1024 * 1024, // 512MB
        capabilities: vec!["test".to_string()],
        policies: vec![],
        metadata: HashMap::new(),
    }
}

Sicherheitsueberlegungen¶

Sicherheitsueberpruefungsprozess¶

Sicherheitsrelevante Aenderungen: Alle Aenderungen, die die Sicherheit betreffen, muessen einer zusaetzlichen Ueberpruefung unterzogen werden:

• Kryptographische Implementierungen
• Authentifizierung und Autorisierung
• Eingabevalidierung und Bereinigung
• Sandbox- und Isolationsmechanismen
• Audit- und Protokollierungssysteme

Sicherheitsueberpruefungs-Checkliste: - [ ] Bedrohungsmodell bei Bedarf aktualisiert - [ ] Sicherheitstests hinzugefuegt - [ ] Kryptographische Bibliotheken sind zugelassen - [ ] Eingabevalidierung ist umfassend - [ ] Fehlerbehandlung gibt keine Informationen preis - [ ] Audit-Protokollierung ist vollstaendig

Meldung von Sicherheitsluecken¶

Verantwortungsvolle Offenlegung: Wenn Sie eine Sicherheitsluecke entdecken:

1. Erstellen Sie KEIN oeffentliches Issue
2. Senden Sie eine E-Mail an security@thirdkey.ai mit Details
3. Geben Sie Reproduktionsschritte an, wenn moeglich
4. Lassen Sie Zeit fuer Untersuchung und Behebung
5. Koordinieren Sie den Offenlegungszeitplan

Sicherheitsbericht-Vorlage:

Betreff: Sicherheitsluecke in Symbiont

Komponente: [betroffene Komponente]
Schweregrad: [kritisch/hoch/mittel/niedrig]
Beschreibung: [detaillierte Beschreibung]
Reproduktion: [Reproduktionsschritte]
Auswirkung: [moegliche Auswirkung]
Vorgeschlagene Behebung: [falls zutreffend]

Ueberpruefungsprozess¶

Code-Review-Richtlinien¶

Fuer Autoren: - Aenderungen fokussiert und atomar halten - Klare Commit-Nachrichten schreiben - Tests fuer neue Funktionalitaeten hinzufuegen - Dokumentation bei Bedarf aktualisieren - Zeitnah auf Review-Feedback reagieren

Fuer Reviewer: - Auf Korrektheit und Sicherheit des Codes achten - Einhaltung der Richtlinien pruefen - Testabdeckung auf Angemessenheit verifizieren - Aktualisierung der Dokumentation sicherstellen - Konstruktiv und hilfreich sein

Review-Kriterien: - Korrektheit: Funktioniert der Code wie beabsichtigt? - Sicherheit: Gibt es Sicherheitsimplikationen? - Performance: Ist die Performance akzeptabel? - Wartbarkeit: Ist der Code lesbar und wartbar? - Testen: Sind die Tests umfassend und zuverlaessig?

Merge-Anforderungen¶

Alle PRs muessen: - [ ] Alle automatisierten Tests bestehen - [ ] Mindestens eine genehmigende Review haben - [ ] Aktualisierte Dokumentation enthalten - [ ] Codierungsstandards befolgen - [ ] Angemessene Tests enthalten

Sicherheitsrelevante PRs muessen: - [ ] Vom Sicherheitsteam ueberprueft werden - [ ] Sicherheitstests enthalten - [ ] Bedrohungsmodell bei Bedarf aktualisieren - [ ] Audit-Trail-Dokumentation haben

Community-Richtlinien¶

Verhaltenskodex¶

Wir sind bestrebt, eine einladende und integrative Umgebung fuer alle Mitwirkenden zu schaffen. Bitte lesen und befolgen Sie unseren Verhaltenskodex.

Grundprinzipien: - Respekt: Alle Community-Mitglieder mit Respekt behandeln - Inklusion: Vielfaeltige Perspektiven und Hintergruende willkommen heissen - Zusammenarbeit: Konstruktiv zusammenarbeiten - Lernen: Lernen und Wachstum unterstuetzen - Qualitaet: Hohe Standards fuer Code und Verhalten aufrechterhalten

Kommunikation¶

Kanaele: - GitHub Issues: Fehlerberichte und Feature-Anfragen - GitHub Discussions: Allgemeine Fragen und Ideen - Pull Requests: Code-Review und Zusammenarbeit - E-Mail: security@thirdkey.ai fuer Sicherheitsprobleme

Kommunikationsrichtlinien: - Klar und praegnant sein - Beim Thema bleiben - Geduldig und hilfsbereit sein - Inklusive Sprache verwenden - Unterschiedliche Standpunkte respektieren

Anerkennung¶

Mitwirkende¶

Wir erkennen alle Formen von Beitraegen an und schaetzen sie:

• Code-Mitwirkende: Aufgefuehrt in CONTRIBUTORS.md
• Dokumentations-Mitwirkende: In der Dokumentation erwaehnt
• Fehlermeldende: In Release-Notes erwaehnt
• Sicherheitsforscher: In Sicherheitshinweisen erwaehnt

Mitwirkungsstufen¶

Community-Mitwirkender: - Pull Requests einreichen - Bugs und Issues melden - An Diskussionen teilnehmen

Regelmaessiger Mitwirkender: - Konsistente qualitativ hochwertige Beitraege - Bei der Ueberpruefung von Pull Requests helfen - Neue Mitwirkende betreuen

Maintainer: - Kern-Teammitglied - Merge-Berechtigungen - Release-Management - Projektrichtung

Hilfe erhalten¶

Ressourcen¶

• Dokumentation: Vollstaendige Anleitungen und Referenzen
• Beispiele: Funktionierende Codebeispiele in /examples
• Tests: Testfaelle, die das erwartete Verhalten zeigen
• Issues: Vorhandene Issues nach Loesungen durchsuchen

Support-Kanaele¶

Community-Support: - GitHub Issues fuer Bugs und Feature-Anfragen - GitHub Discussions fuer Fragen und Ideen - Stack Overflow mit dem Tag symbiont

Direkter Support: - E-Mail: support@thirdkey.ai - Sicherheit: security@thirdkey.ai

FAQ¶

F: Wie fange ich an, mitzuwirken? A: Beginnen Sie mit der Einrichtung der Entwicklungsumgebung, lesen Sie die Dokumentation und suchen Sie nach Labels fuer "good first issue".

F: Welche Faehigkeiten brauche ich, um mitzuwirken? A: Rust-Programmierung, grundlegende Sicherheitskenntnisse und Vertrautheit mit KI/ML-Konzepten sind hilfreich, aber nicht fuer alle Beitraege erforderlich.

F: Wie lange dauert das Code-Review? A: Typischerweise 1-3 Werktage fuer kleine Aenderungen, laenger fuer komplexe oder sicherheitsrelevante Aenderungen.

F: Kann ich ohne Code zu schreiben beitragen? A: Ja! Dokumentation, Tests, Fehlerberichte und Feature-Anfragen sind wertvolle Beitraege.

Release-Prozess¶

Entwicklungsworkflow¶

graph LR
    A[Feature Branch] --> B[Pull Request]
    B --> C[Code Review]
    C --> D[Testing]
    D --> E[Merge to Main]
    E --> F[Release Candidate]
    F --> G[Security Review]
    G --> H[Release]

Versionierung¶

Symbiont folgt der Semantischen Versionierung:

• Major (X.0.0): Breaking Changes
• Minor (0.X.0): Neue Features, rueckwaertskompatibel
• Patch (0.0.X): Fehlerbehebungen, rueckwaertskompatibel

Release-Zeitplan¶

• Patch-Releases: Bei Bedarf fuer kritische Fehlerbehebungen
• Minor-Releases: Monatlich fuer neue Features
• Major-Releases: Vierteljaehrlich fuer signifikante Aenderungen

Naechste Schritte¶

Bereit mitzuwirken? So beginnen Sie:

1. Entwicklungsumgebung einrichten
2. Ein gutes erstes Issue finden
3. Der Diskussion beitreten
4. Technische Dokumentation lesen

Vielen Dank fuer Ihr Interesse, zum Symbiont-Projekt beizutragen! Ihre Beitraege helfen, die Zukunft sicherer, KI-nativer Softwareentwicklung aufzubauen.