Laborunterlagen, Versuchsnotizen, Gel-Abbildungen, Berechnungen, Aufgaben und Termine…

Problem: Laborunterlagen, Versuchsnotizen, Gel-Abbildungen, Berechnungen, Aufgaben und Termine liegen in getrennten Werkzeugen. Das Übertragen von Probenbezeichnungen und Messwerten kostet Zeit, erschwert die Nachvollziehbarkeit und begünstigt Fehler.

Ziel: Ein gemeinsamer, verständlicher Arbeitsbereich bündelt diese Tätigkeiten. Der Gel-Annotator bleibt zusätzlich als eigenständige Website nutzbar. Vorhandene Abläufe und wissenschaftlich relevante Originaldaten sollen erhalten bleiben.

Erfolgskriterien – vorgeschlagene Produktziele, noch keine Nutzungsstudie:

• Eine eingewiesene Person findet einen bekannten Versuchstag oder eine Notiz in höchstens 30 Sekunden.
• Ein vorhandenes Gel-Projekt kann ohne erneute Dateneingabe geöffnet, bearbeitet und als beschriftete Abbildung exportiert werden.
• Eingaben und Ausgaben der Laborrechner bestehen definierte Referenztests inklusive Einheiten.
• Alle fünf Hauptmodule sind erreichbar; Seitenleiste und Inhalte funktionieren auch bei schmalen Fenstern.
• Originalgel-Pixel bleiben im unveränderten Gelbereich des Exports erhalten. Beschriftungen werden davon getrennt gerendert.
• Exportdateien entstehen erst bei Bedarf; die Bearbeitung löst keine unnötige vollständige Exporterzeugung aus.

Vorliegende technische Evidenz: Beim früheren lokalen Beispieltest sank der erste Editor-Durchlauf von etwa 1,7 auf 0,7 Sekunden. Das ist ein einzelner lokaler Messwert, keine Garantie für Cloud-Startzeiten. Zuletzt bestanden 177 Tests für den vollständigen Lab Assistant und 88 für den separaten Gel-Annotator.

Primäre Zielgruppe: Studierende in biologischen beziehungsweise biochemischen Praktika und Laborpersonen, die Versuche dokumentieren, SDS-PAGE-Gele beschriften und wiederkehrende Berechnungen durchführen.

Sekundäre Zielgruppe – Annahme: Betreuende, die exportierte Protokolle oder Abbildungen prüfen. Für diese Gruppe ist aktuell kein eigener Rollenbereich erforderlich.

Vorhandener Nutzungsmodus: Lokale Nutzung durch eine Person; der separate Gel-Annotator ist ohne persönliches Konto erreichbar. Die bestehende Oberfläche enthält keine fertig umgesetzte Benutzer- und Rechteverwaltung.

Gewünschter künftiger Mehrbenutzerbetrieb: Persönliche Daten müssen pro Person getrennt sein. Browser-Sitzungen und getrennte Session-Caches ersetzen keine serverseitige Autorisierung. Eine öffentlich bereitgestellte vollständige Anwendung darf deshalb nicht ohne zusätzliche Prüfung als sicher getrennte Mehrbenutzerplattform bezeichnet werden.

Rollenentscheidung für eine spätere Cloud-Version – offen: Persönliche Konten und gegebenenfalls ausdrücklich freigegebene Inhalte. Administratorrechte, Laborgruppen und Betreuerrollen sind noch zu entscheiden.

A. Praktikum und Notizen: Startseite öffnen → Praktikumsordner anlegen oder auswählen → Versuchstag öffnen → Notizen und Dateien ergänzen → Änderungen speichern → bei Bedarf ein Protokoll erzeugen und exportieren.

B. Gel-Annotation: PNG, JPEG oder TIFF laden beziehungsweise Beispielgel auswählen → Zuschnitt, Perspektive und Bildanpassungen prüfen → Spuren, Probenlabels und Gruppenüberschriften festlegen → Bedingungsmatrix erfassen → Marker kalibrieren → Zielbanden markieren → Export-Reiter öffnen → Abbildung oder Projektdatei herunterladen.

C. Notizen mit Gel verbinden: Versuchstag mit passenden Notizen und Bild öffnen → Gel-Brücke auslösen → erkannte Spuren und Beschriftungen kontrollieren → im Gel-Editor nacharbeiten. Bestehende Gel-Arbeit darf nicht ohne Bestätigung überschrieben werden.

D. Laborberechnung: Rechner auswählen → Werte mit Einheiten eingeben → plausibles Ergebnis und gegebenenfalls benötigte Volumina ablesen. Ungültige Eingaben dürfen kein scheinbar gültiges Ergebnis erzeugen.

E. Kalender und Aufgaben: Monat beziehungsweise Jahr direkt auswählen → Termin mit Wichtigkeit anlegen → Aufgaben mit optionalem Fälligkeitsdatum verwalten → optional ICS-Datei importieren/exportieren oder einen ausdrücklich ausgewählten Kalenderfeed synchronisieren.

F. Wiederaufnahme: Gespeichertes Gel-Projekt als JSON erneut laden beziehungsweise lokalen Datenordner mit Notizbuch und Kalender wiederverwenden. JSON-Projektdateien müssen enthaltene Bilddaten wiederherstellen können.

FR-01 Übersicht: Praktikumsordner, Schnellstart, Kalender und Aufgaben; Navigation zu Übersicht, Notizen, Gel-Editor, Laborrechner und Kalender.
FR-02 Laborbuch: Farbige Ordner, Versuchstage, Text-/Markdown-Notizen, Suche, Medien, Anhänge und gespeicherte Protokollversionen.
FR-03 Protokolle: Quellenbezogene Berichte mit Ziel, Methoden, Rohdaten, Ergebnissen, Diskussion und Quellenanhang; Markdown-/PDF-/DOCX-Export. Grundfunktionen ohne KI; OCR, Transkription und KI optional nach Einrichtung und bewusster Auswahl.
FR-04 Gel-Geometrie: PNG/JPEG/TIFF importieren, zuschneiden, drehen, spiegeln, begradigen und Perspektive korrigieren; Helligkeit, Kontrast, Gamma und Invertierung. Quelldateien erhalten.
FR-05 Beschriftung: Variable, verschiebbare Spuren, obere/untere Labels, Typografie, Hoch-/Tiefstellungen, Gruppenüberschriften und Bedingungsmatrix.
FR-06 Marker/Zielbanden: Markerwerte und Positionen, kDa, Kalibrierung und Zielbanden mit Pfeilen. Automatische Hilfen bleiben manuell korrigierbar.
FR-07 Matrixzeichen: Plus/Minus unabhängig von Server-Schriften zeichnen; gespeicherte Werte und zusammengesetzte Texte unverändert lassen.
FR-08 Export: Mehrere Panels kombinieren; PNG, TIFF, PDF, CSV/JSON, Projekt-JSON mit Bildern und ZIP ausgeben. Qualität erhalten; Exportdateien erst bei Bedarf erzeugen.
FR-09 Rechner: Neubauer, Molarität/Einwaage, Verdünnung, PCR-/Enzym-Mastermix, Einheiten und qPCR.
FR-10 Kalender: Monat/Jahr direkt wählen; Termine und Aufgaben; Wichtigkeit blau/gelb/rot und textlich kennzeichnen. ICS-Import/-Export, Feed-Abgleich manuell.
FR-11 Bedienung: Deutsch/Englisch, Hell-/Dunkelmodus, Beispielgel, Tutorial, Hilfe, responsive Inhalte und einklappbare Seitenleiste.
FR-12 Varianten: Vollständiger Lab Assistant und separater Gel-Annotator eigenständig startbar. Vorhandene Funktionen nach Änderungen erneut prüfen.

Must: Bestehenden Produktumfang erhalten und absichern.

• Die fünf Module des vollständigen Lab Assistants einschließlich vorhandener Rechner und Exporte erhalten.
• Separaten Gel-Annotator ohne unnötige Laborbuch-/Kalenderabhängigkeiten anbieten.
• Kleine Fenster, einklappbare Seitenleiste, stabile Beschriftung und korrekte Matrixzeichen unterstützen.
• Bestehende Ladeoptimierungen beibehalten: gemeinsame Vorschauen, Export erst beim Öffnen des Exportbereichs.
• Originaldaten und Projekt-Kompatibilität schützen; Fehler nachvollziehbar melden.
• Keine eigens hochgeladenen Favicon-/Header-Bilder erneut einführen; diese wurden ausdrücklich entfernt.

Later: Später beziehungsweise vor einer Mehrbenutzerfreigabe zu planen: Verifizierte Benutzertrennung, Authentifizierung nach Betriebsmodell, dauerhafte Cloud-Datenablage, Backups/Wiederherstellung, ausdrückliche Freigaben, Kalenderverbindungen zwischen Personen und definierte Speichergrenzen.

Never: Im Auftrag dieses PRDs nicht bauen beziehungsweise nicht zusagen:

• Keinen vollständigen Neuaufbau mit React/Supabase ohne gesonderte Architekturentscheidung.
• Keine verpflichtende Migration nach Vercel und keine ungeprüfte Reduktion des Funktionsumfangs.
• Kein kommerzielles Abonnementmodell ohne eigene Produktentscheidung.
• Keinen Veröffentlichungstermin oder Wartungsumfang als bereits zugesagt darstellen.

Dauerhafte Grenzen: Keine automatische Veröffentlichung privater Labordaten, kein stilles Überschreiben von Originalen, keine erfundenen Messwerte und keine nicht bestätigten externen Übertragungen durch optionale KI-Dienste.

Vollständige Anwendung: Übersicht; Praktikumsordner/Versuchstage; Notizbuch mit Import und Protokollen; Gel-Editor; Laborrechner; Kalender; globale Einstellungs- und Hilfepopovers.

Gel-Editor: Fünf Hauptreiter: 1. Import & Geometrie, 2. Spuren & Labels, 3. Marker & Leiter, 4. Zielbanden, 5. Multi-Gel & Export. Im zweiten Reiter gibt es zusätzlich die Typografie-Einstellungen.

Bedienkonzept: Aktive Navigation deutlich markieren. In der vollständigen Anwendung stehen Gel-Optionen am Editor; in der Einzelanwendung sind sie in der eigenen Seitenleiste angeordnet. Pfeile zum Schließen und Wiederöffnen der Leiste bleiben erreichbar.

Responsivität: Breite Ansichten dürfen Bild und Bedienung nebeneinander zeigen. Bei geringerer verfügbarer Inhaltsbreite werden sie untereinander angeordnet; fixierte beziehungsweise getrennt scrollende Bereiche werden dort aufgehoben. Reiter bleiben horizontal scrollbar. Prüfgrößen: 390 und 760 Pixel sowie eine normale Desktopansicht.

Zustände: Leerer Start ohne Fehlermeldung, Beispielprojekt, laufende Verarbeitung, vorhandenes Projekt, ungültiger Upload, fehlender Anhang, nicht erreichbarer externer Dienst und erfolgreicher Download. Bestätigungen sollen das Layout möglichst nicht verschieben.

Festgelegte Richtung: Heller, leicht beigegrauer Hintergrund; ruhige wissenschaftliche Oberfläche; blaue Akzente, Umrandungen und dünne Unterstreichungen. Kein durchgehend blau gefüllter Arbeitsbereich.

Vorhandene Light-Tokens: Hintergrund #f8f8f6, Panel #fafaf8, Eingabeflächen #f0f0f0, Text #20241f, Sekundärtext #787b75, Rahmen #d2d2d2, Akzent #60a5fa, Akzenttext #2563a6.

Vorhandene Dark-Tokens: Hintergrund #111925, Panel #182333, Eingabeflächen #202f44, Text #e7eef8, Rahmen #34465e, Akzent #93c5fd.

Komponenten: Abgerundete Buttons und Felder, meist etwa 9 Pixel Radius; Ordnerkarten mit farbiger Registerkante und abgerundeten Ecken; lesbare serifenlose Schrift; einheitliche Icons. Ordnerfarben dürfen variieren, ohne die Grundgestaltung zu verändern.

Reiter: Eine dünne aktive Linie von 2 Pixeln ohne verzögerte Wanderanimation. Formulare brauchen klare Beschriftungen und sichtbaren Tastaturfokus.

Abnahmeziel Barrierearmut: Kontraste einschließlich Sekundärtext und Fokuszuständen messen und gegebenenfalls nachbessern. Die vorhandene Farbpalette ist kein bereits durchgeführter WCAG-Konformitätsnachweis. Keine eigene Favicon-Bilddatei und kein zusätzliches Logo-Upload als Pflichtbestandteil.

Regeln: Koordinaten liegen relativ zwischen 0 und 1. Originalbild und gerenderte Beschriftung sind getrennt. JSON kann Bilder eingebettet enthalten. Fehlende neue Felder benötigen abwärtskompatible Defaults. Die lokale Ablage muss über LAB_ASSISTANT_DATA_DIR konfigurierbar bleiben.

Erweiterung für eine künftige Cloud-Version: Eigentümer-ID und serverseitige Zugriffskontrolle an jedem privaten Datensatz und jeder Datei ergänzen. Dafür ist noch kein bestimmtes Datenbanksystem verbindlich festgelegt.

Vorhanden: Dateibasierter Austausch über Projekt-JSON, PNG, TIFF, PDF, CSV und ZIP; Protokoll-Export zusätzlich Markdown/DOCX. ICS-Dateien und veröffentlichte HTTP(S)-Kalenderfeeds unterstützen den Kalenderaustausch.

Kalendergrenzen: Abgleich nur auf Knopfdruck; keine behauptete bidirektionale Google-/Microsoft-/iCloud-Kontosynchronisation. Vorhandener ICS-Parser importiert wiederkehrende Ereignisse nur eingeschränkt, insbesondere die erste Occurrence. Diese Grenze muss sichtbar dokumentiert bleiben.

Optionale Dienste: Tesseract für OCR, faster-whisper für lokale Transkription, Ollama beziehungsweise OpenAI für ausgewählte KI-Verarbeitung. Verfügbarkeit, Einrichtung und ausdrückliche Auswahl sind Voraussetzung. Formeln und Gel-Brücke benötigen keine KI.

Entwicklung/Bereitstellung: GitHub hält die beiden Codevarianten. Streamlit-Hosting betreibt den Python-Gel-Annotator online. Eine statische Vercel-Auslieferung kann nicht unverändert die vollständige Streamlit-Anwendung ersetzen.

Nicht automatisch aktiv: Externe Analytik, Hintergrund-Kalenderabfragen, kostenpflichtige KI-Aufrufe und Veröffentlichung von Projekten. Zusätzliche API-Integrationen gehören in einen gesonderten Beschluss.

Ist-Stand: Lokale Anwendung ohne verpflichtendes Konto; eigenständiger Gel-Annotator ebenfalls ohne Anmeldung. Das ist eine bewusste einfache Bedienung, aber kein Nachweis einer sicheren Trennung privater Daten bei gemeinsamem Online-Server.

Abnahmeziel für öffentliche Nutzung: Sitzungsdaten, Dateiablage und Projektverwaltung müssen auf mögliche Zugriffe zwischen Personen geprüft werden. Private Projekte dürfen nicht über eine gemeinsame Projektliste oder erratbare Pfade sichtbar werden. Bis zur Klärung keine Zusage „getrennte Daten pro Person“ für den vollständigen Cloud-Betrieb.

Falls Konten eingeführt werden: Zugriff standardmäßig nur für Eigentümer, explizite und widerrufbare Freigaben, Prüfung jeder Datei-/Datenanfrage auf dem Server. Kontenanbieter, Passwort-/SSO-Verfahren und Rollenmodell sind offen.

Vorhandene Schutzmaßnahmen beziehungsweise Produktregeln: Größen-/Typprüfung bei Uploads, Ausschluss ausführbarer Anhänge im Laborbuch, interne Dateinamen, Prüfsummen, keine Geheimnisse im Repository. Diese Maßnahmen sind kein vollständiger Sicherheits-Audit.

Schlüssel: KI-Schlüssel und andere Secrets nur über geeignete Laufzeitkonfiguration beziehungsweise kurzzeitig im Speicher verwenden; nicht in Projektdateien, Logs, Beispielkonfigurationen oder Git-Commits einbetten.

Vorhandene Performance-Maßnahmen: Bearbeitungsmodi teilen identische Vorschaubilder. Verarbeitete Bilder und Ausgaben werden pro Sitzung begrenzt zwischengespeichert. Export-Rendering und PNG-/TIFF-/PDF-/ZIP-Erzeugung werden bis zum Öffnen des Exportbereichs aufgeschoben. Ladezeitoptimierung darf keine Original- oder Exportqualität reduzieren.

Vorgeschlagene Messziele: Warme Startseite auf definierter Referenzumgebung unter 2 Sekunden; übliche Bearbeitungsänderungen möglichst unter 1 Sekunde. Vor Freigabe Referenzbild, Hardware, Netzwerk und mindestens 20 Messungen festlegen. Kalte Cloud-Starts getrennt ausweisen, nicht mit lokalen Messwerten gleichsetzen.

Datenschutz: Lokale Notizen und Medien bleiben lokal, soweit keine externe Verarbeitung ausdrücklich gewählt wurde. Eine gehostete Streamlit-App verarbeitet Uploads auf dem Hosting-Server; „ohne Login“ bedeutet nicht „nur im Browser“. Für Onlinebetrieb sind Löschfristen, Backup-Regeln und Speicherort noch festzulegen.

Barrierearmut – Abnahmeziele: Tastaturbedienbare Navigation, sichtbarer Fokus, verständliche Formularlabels, ausreichende Kontraste und Fehlermeldungen in der gewählten Sprache. Kalenderwichtigkeit muss über Text/Legende zusätzlich zur Farbe verständlich sein. Gel-Bearbeitung mit komplexem Canvas benötigt eine gesonderte Zugänglichkeitsprüfung.

PWA/Offline: Die lokale Python-Anwendung kann ohne Internet arbeiten. Die zwischengespeicherte PWA-Hülle allein macht die gehostete Python-Verarbeitung nicht offline verfügbar.

Bestehender Stack: Python, Streamlit, Pillow, NumPy, pandas, Pydantic; SQLite für Laborbuch und Kalender. Python 3.12 ist die bisher empfohlene Laufzeit. Die Streamlit-Version ist in den aktuellen Anforderungen auf 1.66.1 festgelegt.

Frontend-Spezifika: Streamlit-Oberfläche mit gemeinsamen CSS-Tokens und lokalen SVG-Symbolen; Canvas-/Beschriftungs-/Tutorial-Komponenten als HTML/JavaScript-Komponenten in iframes. Das ist kein reines statisches Frontend.

Lokaler PWA-Zugang: Tornado-Gateway vor dem Streamlit-Backend; zusätzliche statische Dateien für Darstellung und PWA-Hülle. Ein laufender Python-Prozess bleibt erforderlich.

Optional: OCR, Transkription, lokale oder externe Sprachmodelle und Desktop-Paketierung bringen eigene Abhängigkeiten mit. Diese gehören nicht automatisch zum minimalen Online-Gel-Annotator.

Grenzen: Vercel-only erfordert eine gesonderte Architekturentscheidung und einen geprüften Umbau. Ein Wechsel darf nicht unter der Bezeichnung „gleiches Programm“ vorhandene Funktionen, Datenschutzanforderungen oder Exportqualität stillschweigend entfernen.

Verbindliche bestehende Codebasen:

• Vollständiger Arbeitsbereich: https://github.com/t0001-t/Lab-Assistant-Complete
• Eigenständiger Gel-Annotator: https://github.com/t0001-t/Lab-Assistant
• Bekannte gehostete Einzelanwendung: https://gel-annotator.streamlit.app

Einstieg: In beiden GitHub-Repositories startet app.py die jeweilige Anwendung. Im vollständigen Repository führt der Einstieg über pwa_entrypoint.py zur Shell lab_assistant.py; der interne Gel-Editor liegt in gel_app.py. Im Einzelrepository ist app.py direkt der Gel-Editor. Das gesamte jeweilige Repository wird benötigt.

Wichtige Module: models.py, image_processing.py, canvas_renderer.py, workflow.py, die Editor-/Label-/Tutorial-Komponenten und ihre Tests. In der vollständigen Variante zusätzlich die lab_*-Module für Dashboard, Notizbuch, Rechner, Kalender, Exporte und Synthese.

Nicht verändern ohne begründeten, geprüften Auftrag: Originalgel-Daten, relative Koordinaten, Projekt-JSON-Kompatibilität, Rich-Text-Syntax, Marker-/Spurenlogik, wissenschaftliche Rechenformeln, Quellenanhänge und bestehende Exportformate. Ein Plus-/Minus-Darstellungsfix darf keine Rohdaten umdeuten.

Erhalten: Deutsch/Englisch, beide Themes, Ordnerfarben, responsive Navigation, getrennte Varianten und Ladeoptimierungen. Die entfernten Bild-Favicons dürfen nicht unbeabsichtigt wieder eingeführt werden.

Quellenhierarchie: Die tatsächliche aktuelle Implementierung und bestätigte Nutzerentscheidungen gehen älteren Planungsdokumenten vor. Frühere Spezifikationen enthalten zum Teil überholte Einstiegspfade oder unbestätigte Cloud-Annahmen.

Das Produkt ist bereits gebaut. Die folgende Reihenfolge beschreibt die weitere Absicherung und Entwicklung, keine bereits zugesagte Roadmap mit Terminen.

1. Bestehenden Stand und Veröffentlichung sichern: Beide Varianten getrennt dokumentieren; aktuelle Tests und Beispielprojekte reproduzierbar prüfen; keine privaten Dateien einchecken. Installation, Hostingkonfiguration, Wiederherstellung und Rückweg dokumentieren. Ergebnis ist eine weiterhin eigenständig startbare bestehende Anwendung.
2. Aktuelle Nutzung stabilisieren: Ladezeit, Matrixzeichen, responsive Darstellung, Sidebar, Projekt-Roundtrip und Exporte in lokaler und gehosteter Umgebung prüfen.
3. Datenhaltung klären: Gewünschten Einzel-/Mehrbenutzerbetrieb festlegen; serverseitige Projektablage, Benutzertrennung, Export/Backup und Löschung testen.
4. Falls Mehrbenutzerbetrieb gewünscht: Konten, Dateiberechtigungen und dauerhafte Ablage zuerst bauen; danach private Notizen und Kalender öffentlich als Dienst freigeben.
5. Optionales Zusammenarbeiten: Explizite Ordnerfreigaben und Kalenderverbindungen samt Widerruf und Tests ergänzen.
6. Optionale Zusatzdienste: OCR, Transkription und KI-Protokolle kontrolliert einrichten; Auswirkungen auf Datenschutz, Kosten und Fehlerbehandlung prüfen.

Jede Ausbaustufe muss die bestehende Anwendung lauffähig lassen und eine eigene Abnahme erhalten. Spätere Stufen hängen von den offenen Betriebsentscheidungen ab.

• AC-01: Vollständiges Repository über app.py starten: Übersicht und alle fünf Hauptmodule erreichbar.
• AC-02: Einzelrepository über app.py starten: Gel-Annotator mit benötigten Hilfen und Optionen.
• AC-03: Bei 390/760 Pixeln und Desktopgröße: keine Seitenüberbreite; Sidebar und Reiter erreichbar.
• AC-04: Plus/Minus ohne passende Systemschrift: Vorschau und Export korrekt, ASCII-/Unicode-Minus gleich; gespeicherte Daten unverändert.
• AC-05: Unveränderter Gelbereich im Export pixelidentisch; Beschriftungen getrennt gerendert.
• AC-06: Bei geschlossenem Export-Reiter keine Exportdateien erzeugen; identische Vorschauen wiederverwenden.
• AC-07: Projekt-JSON speichern/laden: Bilder, Spuren, Labels, Marker, Bedingungen und Exportoptionen wiederhergestellt.
• AC-08: PNG/TIFF/PDF/CSV/JSON/ZIP lesbar; Inhalte, Einheiten und Auflösung korrekt.
• AC-09: Praktikum, Tag, Notiz und Termin nach Neustart korrekt laden; Anhänge zugeordnet.
• AC-10: Sprach-/Themewechsel erhält Arbeit und verständliche DE-/EN-Bedienung.
• AC-11: Kalenderwichtigkeit visuell unterscheidbar und textlich verständlich.
• AC-12: Ungültige Dateien, Rechnerwerte und Dienstfehler kontrolliert behandeln; vorhandene Daten erhalten.
• AC-13: Künftiger Mehrbenutzerbetrieb: B erhält ohne ausdrückliche Freigabe weder Datensätze noch Dateien von A. Vor Cloud-Freigabe ergänzen und prüfen.
• AC-14: Keine eigenen Favicon-/Gel-Header-Bilder eingebunden.

Rechenreferenzen: Neubauer: lebende Zellen [100,120,80,100], tote [10,10,10,10], Verdünnung 2 → 2.000.000 lebende und 200.000 tote Zellen/mL. Molarität: 0,1 mol/L × 0,01 L × 100 g/mol → 0,1 g. Verdünnung: 1 mL mit Konzentration 1 auf 0,1 → 10 mL Endvolumen. Mastermix: 2 µL × 10 Ansätze × 1,1 → 22 µL.

Bisheriger Prüfstand: 177 bestandene Tests vollständig, 88 separat; Ruff fehlerfrei. Nach relevanten Änderungen erneut prüfen und tatsächlichen Stand dokumentieren. Diese Regressionstests ersetzen keine Sicherheits-, Usability- oder Accessibility-Prüfung.

Lokal vollständig: Repository vollständig installieren, pip install -r requirements.txt; Start entweder über streamlit run app.py oder für den PWA-Zugang über python pwa_server.py --port 8502 --backend-port 8503. Im bisher genutzten lokalen Arbeitsablauf waren die Ports 8916/8918 konfiguriert; Ports sind keine Produktvorgabe.

Lokal separat: Einzelrepository installieren und streamlit run app.py starten.

Streamlit-Hosting: Passendes Repository auswählen, Branch main, Hauptdatei app.py. Vollständige und einzelne Anwendung dürfen nicht verwechselt werden. Abhängigkeiten, Python-Version und statische Komponenten müssen mit bereitgestellt werden. Die tatsächliche Online-Version nach einem GitHub-Update erneut prüfen; ein Commit allein beweist keine erfolgreiche Bereitstellung.

Dauerhafte Daten: Lokale SQLite-/Medienablage und LAB_ASSISTANT_DATA_DIR dokumentieren. Für Cloud-Hosting erst klären, ob das verwendete Dateisystem nach Neustart fortbesteht. Ohne Prüfung kein dauerhaftes Cloud-Backup versprechen.

Umgebungen: Entwicklung und Tests mit temporären Datenverzeichnissen; Produktivdaten nicht für Testläufe verwenden. Releases nachvollziehbar versionieren; für einen Rückweg die Git-Historie erhalten.

Secrets und Artefakte: Keine API-Schlüssel, .env-Geheimnisse, Streamlit-Secrets, Notizbuchdatenbanken, private Medien, gespeicherten Nutzerprojekte, virtuellen Umgebungen oder fertigen App-Binaries in Quellcode-Uploads aufnehmen. Externe Dienstschlüssel nur in der jeweiligen sicheren Laufzeitkonfiguration verwalten.

O-01 – Betriebsmodell: Soll der vollständige Lab Assistant primär lokal/persönlich bleiben oder als dauerhaft öffentliches Mehrbenutzerprodukt laufen? Für den separaten Gel-Annotator ist die Nutzung ohne persönliches Konto bereits gewünscht.

O-02 – Persönliche Cloud-Daten: Wie werden Identität, getrennte Dateiablage, Zugriffsrechte, Backups und Löschung umgesetzt? Die Anforderung „getrennte Daten pro Person“ bleibt vor Freigabe nachweisbar zu erfüllen.

O-03 – Zusammenarbeit: Werden Kalender- und Ordnerfreigaben benötigt? Wenn ja: welche Inhalte, wer darf freigeben, wie werden Freigaben widerrufen? Noch nicht als umgesetzt behandeln.

O-04 – Hosting: Bleibt Python-/Streamlit-Hosting verbindlich, oder soll später eine gesonderte Vercel-kompatible Variante entstehen? Der bestehende Funktionsumfang darf nicht versehentlich reduziert werden.

O-05 – Speicher und Verfügbarkeit: Zulässige Datei-/Projektgrößen, Aufbewahrung, Löschfristen und Wiederherstellungsziel für Onlinebetrieb sind noch festzulegen.

O-06 – Optionale KI: Welche Verarbeitung darf lokal erfolgen und welche extern? Modellanbieter, Schlüsselverwaltung, Einwilligung und Kostenrahmen sind noch zu entscheiden. Die Grundfunktionen bleiben ohne KI nutzbar.

O-07 – Abnahmemessung: Referenzgerät, Referenzgel, Browser, Netzwerk und Zielzeiten noch gemeinsam festlegen. Bisherige lokale Geschwindigkeitswerte nicht als Cloud-Garantie verwenden.

O-08 – Produktfreigabe: Verantwortliche für finale Abnahme, Termin, Budget und Wartung sind nicht benannt. Dieses PRD erfindet dafür keine Zusagen.

Annahmen für dieses Dokument: Hauptsprache Deutsch mit englischer UI-Alternative; vorhandenen Python-Code weiterentwickeln; fachliche Kontrolle durch die nutzende Laborperson; individuelle Daten und Dateien sind standardmäßig privat zu behandeln. Eine Freigabe dieses PRDs ersetzt weder die Sicherheitsprüfung noch eine Entscheidung zu den offenen Punkten.

Grundlagen: Bisherige Nutzerentscheidungen zum Lab Assistant und Gel-Annotator; aktuelle README-/Spezifikations-/Moduldateien der bestehenden Anwendung; zuletzt durchgeführte Tests. Strukturquelle: https://prd.32dots.de/new. Öffentliche Beispiel-PRDs wurden nur zur Prüfung des Exportformats genutzt; deren abweichende Produktentscheidungen wurden nicht übernommen.