114 lines
4.8 KiB
Markdown
114 lines
4.8 KiB
Markdown
ID: SOP_000001 | Version: 0.2.3 | 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! 👻☕
|