# ADR 0001 — Ausbau zum offenen Standard: Lizenzen, Versionsregister, Prozess **Status:** akzeptiert · **Datum:** 2026-08-11 · **Update 2026-08-11:** Website-first — siehe unten ## Kontext Das oPJD soll eine tragende Säule der Krebsregistrierung werden und wird dafür vom Projektartefakt zum community-gepflegten offenen Standard ausgebaut. Die Governance-Seite der Website versprach bereits SemVer, einen fünfstufigen Änderungsprozess, Rollen und „Open Specification" — ohne die Infrastruktur dahinter. Als Vorbilder dienen erprobte Hausmuster: der duale Lebenszyklus der ValiQon-Prüfsets (Freigabe-Snapshot, Einfrieren, Gültigkeitsfenster), die onco-fabric-Registry (SemVer-Fachsemantik, nichts löschen, stabile IDs, ADR-Prozess) und der PubliFlow-Agentenvertrag (manifest/guide/feedbackContract). ## Entscheidung 1. **Lizenzsplit:** Apache-2.0 für Schemas, Beispiele und Code; CC BY 4.0 für Spezifikationstexte, Dictionary-Inhalte und Dokumentation. Root-`LICENSE` = Apache-2.0, `LICENSE-CC-BY-4.0` daneben; Mapping im README. 2. **SemVer mit Domänensemantik:** MAJOR = Bedeutungsänderung oder Strukturbruch, MINOR = additive Erweiterung/Präzisierung, PATCH = redaktionell. Sonderregel 0.x: auch Minor darf brechen (BREAKING-markiert im Changelog). 3. **Versionsregister mit Lebenszyklus:** `public/schema/versions.json` führt alle Versionen mit Status `draft → review → released → deprecated → retired`; `released` ist byte-eingefroren (SHA-256, CI-erzwungen) und eine Einbahnstraße; nichts wird gelöscht — `retired`-Artefakte bleiben abrufbar. 4. **Versionierte Ablage als Quelle der Wahrheit:** `public/schema//…`; die unversionierten Pfade sind committete, per `sync-latest` erzeugte und in CI byte-verifizierte Latest-Kopien. 5. **Dictionary als normatives Artefakt:** je Schemaversion ein maschinenlesbares Dictionary (`dictionary.json`) mit stabilen `opjd://`-Term-IDs (`opjd:///[/]`); Terme werden nie gelöscht, sondern `deprecated_in`/`superseded_by` geführt. 6. **MCP-Server als npm-Paket:** `@kerscher-lab/opjd-mcp` im Unterordner `mcp/` (kein Workspace; Daten per prepack eingebettet, keine Netzwerkzugriffe zur Laufzeit). 7. **GitHub-Prozess:** Discussion → Proposal (`docs/proposals/NNNN-….md`) → Review (fachlich + technisch getrennt dokumentiert; Fristen 14 Tage Minor / 30 Tage Major) → Entscheidung (Status + ggf. ADR) → Release-Train (0.x nach Bedarf, ab 1.0 max. 2 Minor-Releases/Jahr). Die 1.0-Freigabe erfolgt durch den OncoFlow-AP1-Konsensworkshop. ## Konsequenzen - Das Repository wird öffentlich; Lizenz-, Community- und CI-Infrastruktur müssen vor dem Umschalten vollständig sein. - Jede Schemaänderung erzeugt Folgepflichten (Dictionary, Beispiele, CHANGELOG, versions.json inkl. SHA, sync-latest) — CI erzwingt die Konsistenz. - Externe Gremien-Governance (BZKF/OncoFlow) trifft die Projektion oPJD, nicht das onco-fabric-Substrat (vgl. onco-fabric ADR 0001); der Community-Prozess spiegelt Gremienbeschlüsse, ersetzt sie nicht. - Risiko Pflegeaufwand: bewusst kleines Kernmodell und zwei Dictionary-Eintragstiefen; Vollständigkeit wird maschinell geprüft statt redaktionell erhofft. ## Update 2026-08-11 — Website-first statt GitHub-first Entscheidung des Maintainers: **Community und Transparenz laufen über die Website (opjd.kerscher-lab.org), nicht über GitHub; das Repository bleibt vorerst privat.** Konsequenzen: Governance-Dokumente, Entscheidungen, Release Notes, Proposal-Vorlage und Code of Conduct werden bei jedem Build nach `/docs/` veröffentlicht; das Changelog als Seite `/changelog`; öffentlicher Einreichungskanal ist die strukturierte E-Mail an alexander.kerscher@kerscher-lab.org nach dem Feedback-Kontrakt (das MCP-Werkzeug `opjd_propose_change` erzeugt vorbefüllte Entwürfe); eine Web-Einreichung direkt auf der Website ist als Ausbaustufe geplant. Punkt 7 der Entscheidung liest sich entsprechend als interner Verarbeitungsweg; die Konsequenz „Das Repository wird öffentlich" ist aufgehoben. Die GitHub-Community-Dateien bleiben ungenutzt im Repo erhalten, falls es später geöffnet wird.