ID: SOP_000001 | Version: 0.2.2 | Status: Draft
By: Codex (GPT-5)

# 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:

1. Anforderung → Story/Bug anlegen → Epic zuordnen
2. Epic erstellen → Stories definieren → Abhängigkeiten prüfen → CHANGELOG updaten
3. 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! 👻☕