PIGA ORTHO 3D — GLASSBOX STUDIO v0.2 | 25.10.2026 Technische Evaluationsausgabe — NICHT FÜR KLINISCHEN PRODUKTIVBETRIEB. START: 1. Die Hauptseite /piga-ortho-3d/ via HTTPS öffnen. 2. Auf Android in Chrome „Zum Startbildschirm hinzufügen“ nutzen, sobald HTTPS-PWA verfügbar. 3. Offline nach einmaligem erfolgreichen Laden der Service-Worker-Dateien nutzbar (STL und Glassbox). 4. Für rein lokale Ansicht Dateien mit statischem Webserver öffnen: python -m http.server 8080 STL: - Binary- und ASCII-STL bis 25 MB. - Rotierbares 3D-Flächenmodell (Sampling max. 12000 Dreiecke für Rendering); Hash SHA-256. - Bounding-Box-Werte entsprechen unkalibrierten STL-Einheiten; keine automatischen mm. - Technischer Plausibilitätscheck, nicht chirurgisch/klinisch. DRUCKER: - OctoPrint-Server im privaten IPv4-Netz; API-Key wird ausschließlich im RAM gehalten. - Echtzeitstatus: GET /api/version und GET /api/job. - Geräteaktionen: POST /api/job start | pause (action=pause) | cancel. - Keine STL-direkt-an-Drucker-Funktion; vorher per geeignetem Slicer erzeugtes G-Code, in OctoPrint ausgewählt. - Jede Wirkung benötigt Bedienerbestätigung, PIGA Gate 2 und Readback; keine automatischen Wiederholungen. - Der öffentliche HTTPS-Browser kann HTTP-LAN-Aufrufe aufgrund Mixed Content / Private Network Access blockieren. - Android-Debug-APK per reproduzierbarem GitHub Actions Build verfügbar; HTML/CSS/JS-Assets in der APK bytegenau geprüft. Hardwaretests stehen aus. Hersteller-Resindrucker mit anderem API-Protokoll benötigen einen Adapter. GOVERNANCE: - Gate1: technisch plausibles STL (ALLOW/DELAY/UNKNOWN), KEINE Behandlungsfreigabe. - Gate2: nur konkrete Aktion, erneute Autoritäts- und Gerätestatusprüfung. - Glassbox: lokale verkettete SHA-256-Ereignisse, exportierbar, aber ohne externen Zeitstempel/Signatur. - Finite–Infinite: endlich viele bewusst begrenzte Analysezyklen; keine selbstständigen Druckbefehle. - A7SEM Reverse: Readback nach Aktion; bei Unklarheit UNKNOWN, kein Blind-Retry. - Fünf-Engines-Invariante: keine zusätzliche PIGA Engine. ENTWICKLUNGSZIELE (nicht implementiert): DICOM/CBCT, Zahnsegmentierung, klinische 3D-Planung, automatische Staging, herstellerspezifische Resindrucker, Slicerintegration, geprüfter Android-Native-Adapter, validierte revisionssichere Speicherung, regulatorische und versicherungsseitige Prüfung. PIGA Forschungsprojekt – im Auftrag von Mounir Akarkach. Entwickelt von Mounir Akarkach für Herrn Dr. med. dent. Ibrahim Akarkach. PROZESSNAVIGATOR v0.3 --------------------- https://mounirakarkach04-pixel.github.io/ados/piga-ortho-3d/workflow.html Eine interaktive 12-Phasen-Prozessdarstellung mit farblich gekennzeichnetem Implementierungsstatus, Eingabe-/Prüf-/Ausgabekette, Gate 1/2, A7SEM Reverse und JSON-Export. Keine klinischen Berechnungen und keine Patientendatenverarbeitung im Navigator. V0.4 — DUAL-TRACK NAVIGATION User Route und Ergebnis-/Glassbox-Route als interaktive, barrierearme Prozessbahnen in workflow.html. Kein Patienten- oder Druckereingriff im Navigator; jede Stufe zeigt den tatsächlichen Implementierungsstatus. Im Audit-Blueprint Export sind beide Routen ausdrücklich enthalten. PIGA ORTHO v0.5 — PRAXIS WORKSPACE -------------------------------- praxis.html contains Supabase-backed registration/login, recovery request, employee approval, work-time records and server-RLS-protected owner costing. New staff signups are pending; the owner receives a single-use invitation out of band. Clinical patient data and eGK/KIM interfaces are blocked. See piga-ortho-3d/ORTHO_V05_AUTH_RLS.md for backend policies, testing and deployment limits. A web UI is not a CE-certified clinical product. PIGA ORTHO v0.6 — EMPLOYEE TRACEABILITY ---------------------------------------- Each account now has a unique, immutable, server-issued staff_code (e.g., KFO-001001), not an access password. New work events are server-generated START/END records tied to authenticated account, pseudonymous case reference and task. Each shift time is overwritten by Postgres server clocks, and employees cannot write events or modify start times. The owner-only handover timeline is RLS-restricted in the database, supports filtering by pseudonymous case and CSV export. Users must never enter real patient names or insurance identifiers. This task log does NOT substitute a complete statutory daily working-time system with breaks, corrections and legally compliant employee access. Version 0.6 remains technical evaluation. Owner activation, independent access test, real printer, clinical compliance remain pending. V0.7 UNIFIED UX --------------- dashboard.html is a new feature hub with responsive modules, safe local STL metadata/hash validation, a session-scoped print-readiness checklist, and drilldown into every existing tab. navigation.js and navigation.css provide one consistent adaptive rail/bottom navigation and Ctrl+K feature search across studio, office and workflow. No clinical patient data or automatic printer actions in dashboard. Readiness checklist is NOT a Gate-2 authorization. Offline service-worker cache includes all 19 web assets. PIGA ORTHO v0.8 — VERIFIED GREETING AND PRINTABLE GLASSBOX PASSPORT ------------------------------------------------------------------ 1. Dashboard greeting is generic until a previously signed-in same-tab authenticated session is validated by Supabase Auth /auth/v1/user and staff-row RLS. Only the verified recipient's unique email shows Guten Tag, Dr. Akarkach. Other verified accounts use their saved full name. Never infer owner privileges from the displayed greeting. 2. Praxis Workspace greeting is populated after successful logged-in profile retrieval. JWT token is held in sessionStorage for same-tab navigation with bounded expiry (maximum 1 hour); sessionStorage is cleared on sign-out. It is not a durable login solution. Subsequent production work should use HttpOnly cookie or another formally audited identity flow. 3. PIGA ORTHO 3D report.html accepts an optional one-time same-tab evidence snapshot from Studio or a user-selected local Glassbox JSON. It checks event sequence, previous hashes, terminal hash and SHA256 each event. Printing goes through browser print/PDF or explicit native Android PrintManager. The app NEVER automatically prints a physical dental workpiece. 4. Contents: model source and technical STL sizes in unverified STL units, user decisions, Gate 1 and Gate 2, operational A7SEM seven-stage evidence mapping, A7SEM Reverse observed effect, bounded Finite–Infinite monitoring cycles, event table and known unknowns. No medical measurements or authorization are fabricated. Demo journal is synthetic only. 5. SHA256 chain is not a digital signature, validated audit archive, or proof of actor identity. Synthetic evaluation only; PHI/eGK, real patient data, unbounded execution and unsupported clinical inference remain blocked. 6. Email correspondence preference: when sending to Dr. med. dent. Ibrahim Akarkach through the authorized Outlook account, end with exactly: Mit freundlichen Grüßen / PIGA / im Auftrag von Mounir Akarkach. Do not send Gmail attachments. V0.9 — DEVICE CENTER AND INTUITIVE NAVIGATION ============================================== The first dashboard displays four primary destinations: Devices, Practice, STL Studio and Guided Workflow. Secondary power-user modules are available through progressively disclosed details. Native Android interface exposes READ-ONLY network transport status, consented list of paired Bluetooth device names and system WiFi/BT settings. Android Storage Access Framework imports user-selected STL from local or USB. Browser shows only generic network information. No vendor-neutral Bluetooth scanner/3D printer driver exists; connection status does not equal manufacturer certification. Supported OctoPrint interface stays under explicit PIGA Gate2 and readback. Device Centre can generate an intentionally artificial 14-tooth-shaped binary STL for synthetic workflow demonstration; it explicitly omits anatomical/clinical meaning. Technical bounds are STL units until professionally calibrated. Android WebView DOM storage is enabled to fix sessionStorage-based sign-in/navigation; this is necessary but NOT proof of production-ready credential security. RELEASE V0.9 — DEVICE CENTER / FIXED ANDROID AUTH STORAGE 1. Devices: WLAN read-only via Android ConnectivityManager; Bluetooth permission BLUETOOTH_CONNECT is requested only after user activation and paired devices names are displayed without MAC addresses; system Wi-Fi/BT settings available. No blanket Bluetooth scan, scanner driver or data channel and no location permission. Bluetooth discovery only through system UI. 2. USB/SAF: scoped system document chooser enables local user-selected STL import from USB/external storage. Native vendor USB serial controller is NOT implemented. 3. Local binary STL geometric evaluation with SHA-256, triangle count, degenerates and bounding box in unverified STL units. Synthetic 14-tooth-shaped binary STL test can be generated without real patient data. Technical reports list Gate 1 DELAY and Gate 2 BLOCK. 4. OctoPrint Wi-Fi: preexisting restricted readback and operator-authorized job bridge remains separate. Any real resin 3D printer driver, scanners and manufacturing slicer adapter need per-device manufacturer validation. 5. Android WebView DOM Storage enabled (required by v0.8 browser Auth) and no true persistent session guarantee. All authentication and permission flows must be tested against signed-in role identities, independently and on real Android devices. V1.0: 5-step swipeable clinician-review assistant, three synthetic typodonts, 36-entry offline BEMA catalogue. No patient data or autonomous medical diagnosis. V1.1 HR STAFF & ACCOUNTANT PORTAL (CONTROLLED EVALUATION) - New team.html gives three server-gated roles: employee, owner, accountant. Accountant may only read owner-shared monthly payroll packages, never raw medical data or handbook acknowledgements. New signups pending, owner approves roles explicitly. E-mail delivery via default Supabase service is restricted and SMTP/redirect allowlist must be validated before real onboarding. - Annual handbook versions: two draft manuals prepared but NOT published until Dr. Akarkach checks/adapts and approves. Employee confirms review, uploads personally signed PDF to private 5MB PDF-only storage and creates version/year keyed record. This does not replace actual in-person hygiene/safety instruction or a qualified electronic signature. - HR time events, vacations/sickness without diagnosis, staff shift scheduling, in-app owner alerts and accountant-visible payroll EXPORT previews are implemented with RLS; not validated for payroll accounting completeness. - Authentication recovery callback auth.html supports verified token_hash or fragment access_token. Supabase must allow callback URL and have reliable SMTP sending, otherwise registration delivery cannot be called working. - Owner postal email push, DATEV API and clinical patient data are NOT connected. No real medical data in this evaluation app. VERSION 1.2 / MATERIAL & BESTELLPLANUNG ----------------------------------- 38 vorstrukturierte KFO-Verbrauchs- und Geräteverbrauchsartikel, reale Mengen absichtlich zunächst Null. Authentifizierter eigener Lagerbestand in Supabase mit Row Level Security, Inhaber-/Mitarbeiterdelegation, unveränderlichen Buchungsereignissen per serverautorisierter RPC und Kritisch-Alarm im Inhaber-Dashboard. Vertrauliche Einstandspreise getrennt (owner-only RLS). 4 Behandlungs- bzw. Terminarten, Mengenplanung aus selbst kalibrierten Faktoren pro Behandlungstermin, Tagesbedarf, Lieferzeit, Reserve, Mindestmenge, Packungsrundung, Bestell-CSV und nachvollziehbare Eingangs- und Entnahmebuchungen. Ein App-Alarm wird nach Unterschreiten des Mindestbestands angelegt; das Feld mail_delivery=NOT_CONFIGURED ist ABSICHTLICH. Bis Outlook/Microsoft Graph bzw. SMTP mit kostenfreier Autorisierung eingerichtet und real getestet sind, ist die Mailfunktion ein ausdrücklich manuell auszulösender Entwurf (mailto), KEIN automatischer Versand. Keine Bestellung wird eigenständig abgesandt. Katalog-SKU ist derzeit der Primärschlüssel, optionale LOT/Verfalldaten je Artikel sind nicht voll chargenscharf. Für sterile oder implantierbare Medizinprodukte wäre eine separate Chargenverwaltungs-/UDI-Komponente mit regulatorischer Prüfung erforderlich. Onlinezugriff für geteilte Bestände; nur die leere App-Oberfläche ist offline gecacht, keine Bestandsänderungen offline. PIGA-Gates und evidenzbasierter Readback bleiben maßgeblich. Produkt ist technische Evaluation, keine regulatorisch validierte Klinikfreigabe.