# Der oPJD-Änderungsprozess

**Grundsatz:** Normativ ist das Repository — die Markdown-Dokumente unter `docs/` und die
maschinenlesbaren Artefakte unter `public/schema/`. Die Website ist die lesbare Projektion.
Jede inhaltliche Änderung an Schema, Dictionary oder Spezifikationstext durchläuft diesen
Prozess.

## Der Weg eines Vorschlags

Der Prozess bildet die fünf Schritte der Governance ab (Vorschlag → fachliche Bewertung →
technische Prüfung → Entscheidung → Kommunikation). Der öffentliche Kanal ist die
Website samt E-Mail-Eingang; die interne Verarbeitung läuft im (derzeit privaten)
Repository:

### 1. Idee

Eine **strukturierte E-Mail** an alexander.kerscher@kerscher-lab.org nach dem
Feedback-Kontrakt des Manifests — formlos ist ebenso willkommen. Offen für alle:
Kliniker:innen, Tumordokumentar:innen, Implementierer:innen, KI-Agenten (das
MCP-Werkzeug `opjd_propose_change` erzeugt einen vorbefüllten E-Mail-Entwurf).

### 2. Proposal

Der Vorschlag wird als `docs/proposals/NNNN-kebab-titel.md` ausgearbeitet (Vorlage:
[`0000-template.md`](../proposals/0000-template.md), nächste freie vierstellige Nummer)
und mit Status `entwurf` geführt; die Bearbeitung läuft intern als Pull Request. Der Proposal-Text beantwortet: Problem und klinische Begründung,
konkreter Vorschlag, oBDS-Bezug, Kompatibilität (SemVer-Einstufung), Auswirkung auf
Implementierer, Datenschutz, erwogene Alternativen.

### 3. Review

Status `in-review`. Zwei Prüfpfade müssen **dokumentiert** bestanden sein:

- **Fachlich**: klinische Relevanz, oBDS-Bezug, Versorgungsnutzen, Passung zu den
  Evolutionsprinzipien (Kernmodell klein, Erweiterungen modular).
- **Technisch**: Schema-Konsistenz, SemVer-Einstufung, Migrationsaufwand,
  Dictionary-/Beispiel-Folgeänderungen.

**Mindestkommentierungsfristen:** Patch/redaktionell: keine (normaler PR-Review).
Minor (additiv): **14 Tage**. Major (Bedeutungsänderung/Bruch): **30 Tage** plus aktive
Information der Implementierungspartner (siehe [ROLLEN.md](ROLLEN.md)).

> Bis zur Erweiterung des Maintainer-Kreises erfolgen beide Prüfungen durch den
> Maintainer und werden getrennt als Review-Kommentare dokumentiert.

### 4. Entscheidung

Der Proposal-Status wird auf `angenommen`, `abgelehnt` oder `zurückgestellt` gesetzt
(Dokumentkopf). Bei Architektur-Tragweite entsteht zusätzlich eine ADR in
[`docs/decisions/`](../decisions/) (Format siehe dort; Updates in place). Angenommene
Proposals und alle Entscheidungen werden auf der Website unter `/docs/` veröffentlicht.

### 5. Aufnahme & Kommunikation

Der Umsetzungs-PR ändert zusammenhängend: Schema + Beispiele + Dictionary + CHANGELOG +
`versions.json` (inkl. `sha256`) und führt `npm run sync:latest` aus. Release gemäß
Release-Train; Kommunikation über Changelog und Website sowie direkte Information
der Implementierungspartner.

## Proposal-Status

`entwurf` | `in-review` | `angenommen` | `abgelehnt` | `zurückgestellt` — im Dokumentkopf.

## Versionierung & Release-Train

- **SemVer mit Domänensemantik**: MAJOR = Bedeutungsänderung oder Strukturbruch
  (Migration erforderlich), MINOR = additive Erweiterung oder Präzisierung ohne Bruch,
  PATCH = redaktionell. Sonderregel 0.x: auch Minor darf brechen (BREAKING-markiert).
- **0.x-Phase**: Sammel-Releases nach Bedarf. **Ab 1.0**: gebündelte Minor-Releases
  maximal zweimal pro Jahr; Patches jederzeit.
- **Lebenszyklus** je Version: `draft → review → released → deprecated → retired`
  (Definitionen in [`versions.json`](../../public/schema/versions.json) und
  [KONFORMITAET.md](KONFORMITAET.md)). `released` ist eine Einbahnstraße; die Schemadatei
  ist ab dann byte-eingefroren (SHA-256 CI-erzwungen) — Korrekturen erzeugen eine neue Version.
- **Release-Notes**: `docs/releases/<version>.md` entsteht spätestens beim Statuswechsel
  nach `review`, Pflicht ab `released`; bei Breaking Changes zeigt `migration_url` darauf.
- **Git-Tags** `spec/vX.Y.Z` erst ab Status `released`.

## Verzahnung mit OncoFlow / BZKF

Der öffentliche Prozess bereitet Entscheidungen vor und dokumentiert sie. Beschlüsse der
OncoFlow-Gremien (AP1-Konsensgremium, AG Krebsregister) werden als Proposals bzw. ADRs in
das Repository gespiegelt. **Die Freigabe der Version 1.0 erfolgt durch den nationalen
Konsensworkshop (AP1); der Maintainer setzt sie um.** Der Community-Prozess ersetzt die
Gremien nicht — er macht ihre Arbeit öffentlich anschlussfähig.