Onboarding: Arbeitsweise im Sound Architect Projekt

Willkommen im Team! Dieses Dokument erklärt, wie wir im Sound Architect Projekt arbeiten, Features planen und die Dokumentation pflegen. Wir folgen einer strikten SOP (Standard Operating Procedure) [cite: 1.1].

Grundprinzip: Documentation-First Development

Wichtig: Wir dokumentieren bevor wir coden. Jedes Feature durchläuft diesen Workflow:

Anforderung → Story/Bug anlegen → Epic zuordnen
Epic erstellen → Stories definieren → Abhängigkeiten prüfen → CHANGELOG updaten
Story starten → Tasks ausarbeiten → Feature Branch → Implementation → Tests → Commit → Merge → CHANGELOG updaten

WICHTIG: Neue Anforderungen behandeln

Wenn der Stakeholder/User eine neue Anforderung stellt:

NICHT sofort anfangen zu coden.
Entscheiden: Handelt es sich um ein Feature (Story US_NNNNNN) oder einen Fehler (Bug BUG_NNNNNN).
Dokumentieren in project-management/requirements/.
Loggen in der CHANGELOG.md im Root-Verzeichnis [cite: 1.2].

Verzeichnisstruktur (Management-Layer)

Alle administrativen Dateien liegen im project-management/ Ordner, außer dem Changelog und der README [cite: 1.1].

project-management/
├── PROJECT_STATUS.md      # Vision, Aktueller Fokus & Backlog (Nutzt TMP_STATUS_001)
├── ONBOARDING.md          # Diese SOP
└── requirements/          # Alle Anforderungen
    ├── epics/             # High-Level Features (Standard: STD_EPIC_001)
    ├── stories/           # User Stories (Standard: STD_STORY_001)
    ├── tasks/             # Technische Umsetzung (Standard: STD_TASK_001)
    └── bugs/              # Bug-Reports (Fehlerdokumentation)

CHANGELOG.md               # Root: Das tabellarische Logbuch (Die Wahrheit) [cite: 1.2]
VERSION                    # Root: Die zentrale Versionsdatei (Single Source of Truth)

Unsere Standards & Phasen

Dokument-Header Standard (PFLICHT)

Jedes Dokument (auch Anforderungen) muss mit folgendem Header beginnen. Der Header steht zusaetzlich zu bestehenden Template-Headern und bleibt immer die erste Zeile.

ID: [ID] | Version: [Inhalt aus /VERSION] | Status: [Draft/Review/Final]
By: [Name oder Agent]

Projekt-Status (PROJECT_STATUS_TEMPLATE.md)

Die PROJECT_STATUS.md folgt strikt dem bereitgestellten Template PROJECT_STATUS_TEMPLATE.md und weist die globale Projektversion aus. Die Header-Regel gilt auch hier (inkl. By-Zeile).

Phase 0: Dokumentations-Standards (Anforderungen)

EPIC (ID: STD_EPIC_001):

Mission Statement: Das große Ganze (Fakten).
Business Value & Metriken: Welchen KPI verbessern wir?
In-Scope vs. Out-of-Scope: Wo ist die rote Linie?
High-Level Akzeptanzkriterien: Definition of Done für das Epic.
Technische Constraints & Risiken: Was könnte explodieren?

USER STORY (ID: STD_STORY_001):

Format: "Als [Rolle] möchte ich [Funktion], damit [Nutzen]."
Akzeptanzkriterien (Gherkin-Style): Given / When / Then.
Qualitätsregeln: Objektiv prüfbar, eindeutig, unabhängig von Details.
Rückfrage-Pflicht: Wenn Kriterien nicht ableitbar sind → Rückfrage an Stakeholder stellen.

Phase 1: Planung & Log

Bei jeder Planung eines Epics oder einer Story muss die CHANGELOG.md im Root aktualisiert werden.

Format für Einträge:

| DD.MM.YYYY | 🏗️ Planning | ID: Kurze Beschreibung geplant. |

Hinweis: "ID: ..." ist ein Praefix im Beschreibungsfeld, kein eigenes Tabellenfeld. Ergaenze am Ende der Beschreibung immer den Hinweis By: <Name/Agent> (z.B. ID: ... By: Jane Doe), damit klar ist, wer die Aenderung gemacht hat.

Phase 2: Just-in-Time Tasks (ID: STD_TASK_001)

Technische Tasks werden erst bei Story-Start detailliert ausgearbeitet.

Feingranular: Max. 1–8 Arbeitsstunden pro Task.
Konkret: Technisch präzise und eindeutig abschließbar.
Inhalt: Titel, Outcome, Story-Bezug, Beschreibung & Definition of Done (DoD).

Phase 3: Versionierung & Release-Audit (BINDEND)

Wir arbeiten strikt nach dem Format Major.Minor.Small (z.B. 0.0.0).

Zentrale Datei: Die Datei VERSION im Root ist die einzige Quelle (SSOT).
Zwang: Die Version aus dieser Datei muss zwingend in alle Scripte, Dokumente (Header/Footer) und GUIs/TUIs eingebunden werden. Hardcoding ist verboten!
Doku-Audit-Pflicht: Bei jedem Major- und Minor-Release (X.Y.0) ist ein Audit zwingend:
- Prüfung auf inhaltliche Übereinstimmung mit dem neuen Stand.
- Aktualisierung veralteter Anweisungen/Beschreibungen.
- Verifizierung der Versions-IDs in allen Headern.

Die goldenen Regeln

CHANGELOG.md ist die Wahrheit. [cite: 1.2]
PROJECT_STATUS.md ist der Kompass.
VERSION ist das Gesetz.
ID-Pflicht für alles: Ohne ID existiert keine Anforderung.
Code-First ist verboten!

Let's build some ghosts! 👻☕

4.8 KiB Raw Blame History Unescape Escape