Prilog Software-Manifest

Pflicht-Mindeststandards für jedes Feature in Prilog — von der ersten Idee bis zum echten Schul-Use. Verbindlich für alle, die an der Software bauen.

Warum dieses Manifest

Prilog ist kritische Schul-Infrastruktur. Wenn eine Schule am Tag der Zeugnisausgabe feststellt, dass kein Lehrer einen Beitrag schreiben kann, weil die Stundenplan-Bridge keine Zuordnung gefunden hat, ist das kein Software-Bug — das ist ein organisatorischer Notfall für die Schule. Damit so etwas nicht passiert, gibt es dieses Manifest.

Es entstand aus konkreten Vorfällen (siehe 02-lessons-aus-prilog.md), aus Industrie-Standards die wir noch nicht nutzen (03-industrie-standards.md) und aus fortgeschrittenen Praktiken, die langfristig den Unterschied zwischen „läuft" und „läuft auch unter Stress" machen (04-fortgeschritten.md).

Aufbau

Datei	Inhalt	Wer liest das?
01-pflicht-checkliste.md	DIE Checkliste für jeden Sprint: P0-Freeze → Implementierung → Tests → LIVE. Stempel-Liste, abhaken vor dem Release.	Jeder, vor jedem Sprint-Ende
02-lessons-aus-prilog.md	Konkrete Vorfälle aus der eigenen Geschichte und welche Regel daraus wurde.	Onboarding, Nachschlag bei Bauchschmerzen
03-industrie-standards.md	Was die Software-Industrie macht und wir noch nicht. Mit Priorisierung „Pflicht / Sollte / Wäre schön".	Tech-Lead, Planung mittelfristig
04-fortgeschritten.md	Praktiken aus dem Senior-Engineering-Bereich, die Prilog ab einer bestimmten Größe braucht. Mit „Wann wird das relevant"-Trigger.	Tech-Lead, vor Skalierungs-Entscheidungen
05-templates.md	Skelette: Spec, PR-Beschreibung, Postmortem, ADR. Copy + ausfüllen.	Jeder, beim Anlegen neuer Specs/PRs
06-glossar.md	Begriffe die intern benutzt werden (P0-Freeze, ADR, RPO/RTO, …).	Onboarding, Disambiguation

Drei Grundregeln

Die alles andere unterordnet sich. Wenn etwas mit diesen drei kollidiert, muss eine dieser drei nachgeben — nicht umgekehrt.

1. Realität schlägt Test

Tests grün heißt nicht Feature funktioniert. Bevor irgendetwas „LIVE" heißt, muss es per Hand durch alle betroffenen Rollen geklickt worden sein — gegen echte Daten auf einem echten Tenant. Mock-Tests sind notwendig, aber sie haben uns schon mehrmals falsche Sicherheit gegeben (siehe Zeugnis-Sprint 5/6).

2. Wenn der Nutzer nicht weiterkommt, ist die Software schuld

Stilles Hängen ist immer ein Bug. Jede UI, die einen Zustand erlaubt in dem nichts passiert (Generator-Button macht nichts, Klick auf Schüler öffnet leeres Slide-Over, 404 ohne Erklärung) bekommt einen Diagnose-Hinweis mit konkretem nächsten Schritt.

Negativbeispiele aus unserer Vergangenheit:

• „HTTP 404" als Toast → User weiß nicht, ob er falsch klickt, falsch eingeloggt ist oder ob das System kaputt ist
• Generator-Button erzeugt leeren Text → User merkt es nicht, schreibt weiter mit leerem Vorschlag
• „Zum Admin machen"-Button setzt DB-Flag aber JWT bleibt alt → User klickt, nichts passiert, kein Hinweis dass Logout nötig

3. Datenschutz ist kein Feature, sondern Voraussetzung

Jede neue Domain (Zeugnisse, Mitarbeiter, Schüler, Krisenmanagement) braucht vor der ersten Zeile Code:

• DSFA (Datenschutz-Folgenabschätzung) als Muster — Schule signiert, lädt hoch
• Capability-Flags pro Rolle
• Sicht-Resolver pro Resource (Lehrer sieht nur seine Klassen etc.)
• Audit-Log für sensible Aktionen
• Break-Glass-Pfad für Notfälle (mit Pflicht-Begründung + Zeit-Limit)
• Pseudonymisierung im Standard-Audit-View

Das ist nicht „nice to have", das ist gesetzliche Pflicht (Art. 9 + 32 + 35 DSGVO).

Wie dieses Manifest gepflegt wird

• Jeder erkannte Vorfall oder neue Erkenntnis → Eintrag in 02-lessons-aus-prilog.md mit Datum, Symptom, Regel
• Jede Aufnahme einer neuen Praktik → Eintrag in 03-industrie-standards.md oder 04-fortgeschritten.md
• Änderungen an 01-pflicht-checkliste.md sind bewusste Owner- Entscheidungen, nicht stilles Drift. PR-Beschreibung soll erklären, warum.
• Aktualisierungs-Frequenz: nach jedem Sprint einmal querlesen — passt noch, fehlt was?

Sprach-Konvention

Deutsch — passt zur Mehrheit der Stakeholder + zur Schul-Domain. Englisch nur wo es Begriffs-Standards sind („Capability", „Audit Log", „ADR").

Verbindlichkeitsgrad

Kennzeichnung	Bedeutung
MUSS	Pflicht. Wenn nicht erfüllt → kein LIVE-Stempel, Sprint zurück auf in_progress.
SOLL	Sehr starke Empfehlung. Abweichung braucht dokumentierte Begründung.
KANN	Empfehlung. Frei zu entscheiden je nach Kontext.