Zum Hauptinhalt springen

Feature-Liste — Medidentas (wird gebaut, nicht gepflegt)

Kernaussage: Was die App heute kann, steht in den GitHub-Issues mit Label Feature-Liste — die Issue-Nummer ist die Feature-ID, der Status kommt aus dem Issue. Diese Seite ist nur der Wegweiser; die vollständige Liste wird aus zwei Quellen gebaut und liegt nicht im Repository (MED-D-362, Vorbild jico).

QuelleWas sie beiträgt
feature.d/<Position>-<Schlagwort>.mdText, Modul, Zugang, „Seit“-Version und Issue-Nummer, optional eine Anmerkung — eine Datei je Feature
GitHub-Issues mit Label Feature-Listeden Status: geschlossen = ✅ · geschlossen als not planned = ⛔ (verworfen) · offen mit Label teilweise = 🟡 · sonst offen = ⛔

So bekommst du die Liste​

  • Sofort, ohne Bau: offene Features · teilweise gebaut · gebaut
  • Als Tabelle: GH_TOKEN=… python3 scripts/feature_liste_bauen.py schreibt build/Feature-Liste.md. Nach jedem Merge baut .github/workflows/dokumente-nachziehen.yml sie ebenfalls und legt sie als Artefakt feature-liste ab.

Was wo hingehört (verbindlich)​

  • Ein neues Feature beginnt mit dem Issue (Vorlage „Feature“), nicht mit der Zeile. Der PR legt feature.d/<Position>-<Schlagwort>.md an: erste Zeile abschnitt: <Name aus feature.d/_abschnitte.md>, optional anmerkung: <Text>, darunter eine Zeile | Feature | Modul | Zugang | Seit | #<Issue> |.
  • Der Status steht nie im Fragment. Ist ein Feature fertig, wird sein Issue geschlossen (Closes #n); teilweise gebaut = Issue offen lassen + Label teilweise.
  • Rohre in einer Zelle (auch in Code-Spans) als \| schreiben. Die CI prüft die Fragmente ohne Netz (python3 scripts/feature_liste_bauen.py --offline, Job doc-consistency).

Fachliche Spezifikation: Lastenheft.md · chronologischer Trail: CHANGELOG.md · Testabdeckung: ../betrieb/Test-Uebersicht.md.