Das Discovery-Tool besteht aus drei Datenschichten, die strikt getrennt sind:
| Schicht | Datei | Inhalt | Änderbar durch |
|---|---|---|---|
| Prüfkatalog (statisch) | site/discovery/js/catalog.js |
Kapitel, Fragen, Befehle, Branching-Prädikate | Entwickler |
| Bewertungslogik (statisch) | site/discovery/js/rules.js |
Capabilities, Gates, Frontend-Bewertung, Stacks, drei Ebenen, Blocker, Restfragen | Entwickler |
| Zustand (dynamisch) | localStorage tdt.state.v1, Export-JSON |
Antworten, Nachweise, Notizen, Status, Clientprofile | Anwender |
SECTIONS)| ID | Titel | Gate |
|---|---|---|
| A | Windows Server | SERVER |
| B | Active Directory | SECURITY |
| C | IIS | SERVER |
| D | Laufzeiten | SERVER |
| E | Datenbanken | DATABASE |
| F | Schnittstellen | NETWORK |
| G | Hintergrundverarbeitung | SERVER |
| H | Deployment | SERVER |
| I | Logging / Monitoring / Audit | SERVER |
| J | Sicherheit / Datenschutz | SECURITY |
| K | Clients | CLIENT |
| L | Zugriffspfad / MobileIron / Tunnel (inkl. L7 No-JS-Baseline) | NETWORK |
Das Kapitel L2/L3 (Client Capability Test, Profile, Vergleichsmatrix) ist kein Fragebogenkapitel, sondern ein eigenes Modul (site/clienttest/), dessen Ergebnisse als Clientprofile in den Zustand importiert werden.
QUESTION)id String eindeutig; Präfix = Kapitel (A01, C27, D_php_tech, F05_det, L20)
sec String Kapitel-ID
title String Frage
why String „Warum wichtig?“
gui String GUI-/IIS-Menüpfad
cmd String ausschließlich LESENDER Befehl
cmdLang powershell | cmd | sql | text (text = organisatorische Frage / manueller Test)
expect String erwartbare Ergebnisse und Interpretation
type ynu | single | multi | number | version | text | check
options [{v,l}] für ynu/single/multi (ynu = Ja/Nein/Unbekannt)
impact String direkte Architekturauswirkung
showIf (v)=>bool optional; v(id) liefert den Wert einer anderen Antwort
tags [String] optional (Suche)
Wiederkehrende Optionsmengen:
AVAIL (technischer Status einer Laufzeit): installiert · installierbar · nicht_installierbar · unbekanntORG (organisatorischer Status): prod_freigegeben · erlaubt · verboten · unbekanntIFACE (Schnittstelle): verfuegbar_erlaubt · verfuegbar_ungeklaert · nicht_erreichbar · nicht_vorhanden · unbekanntLaufzeiten (Kapitel D) werden generisch als Tripel <base>_tech, <base>_org, <base>_ver erzeugt, um die geforderte Unterscheidung technisch vorhanden / technisch installierbar / administrativ erlaubt / produktiv freigegeben / unbekannt konsistent abzubilden. Schnittstellen (Kapitel F) als Paar <id> (Status) und <id>_det (Auth, Verantwortlicher, Doku).
ANSWER)value abhängig vom Typ: String | Number | Boolean | [String]
note Freitext
evidence Nachweis / Konsolenausgabe / Ticket-Nr.
status confirmed | open | na | forbidden
(bestätigt / ungeklärt / nicht verfügbar / organisatorisch verboten)
itConfirmed Boolean „durch IT bestätigt“
later Boolean „später prüfen“
updatedAt ISO-Zeitstempel
Regel: Ein Wert allein macht eine Fähigkeit nicht GRÜN. status = forbidden oder na setzt jede abhängige Fähigkeit auf ROT; later/open/„Unbekannt“ erzeugen automatisch eine Restfrage an die IT.
PROFILE, Schema cct-profile/1.0)id, name, deviceType, os, osVersion, browser, mdm, mdmVersion, accessPath, userGroup
mandatory Boolean Pflichtclient → zählt für den kleinsten gemeinsamen Nenner
ua, auto User-Agent und automatisch erkannte Eigenschaften (Screen, Touch, secure context …)
probeBase, probeAvailable
results { <testId>: { ok: true|false|null, detail, note, manual, autoOk, ts } }
createdAt, updatedAt
Die Test-IDs sind in rules.js (CLIENT_TESTS) und clienttest.js (TESTS) identisch definiert (38 Tests, Gruppen: Basis, JavaScript, Formulare, Netzwerk, Speicher, Realtime, PWA, Dateien, Geräte-APIs, Extern, Netz/Tunnel).
STATE){ version, meta: { project, interviewer, itContact, createdAt, updatedAt },
answers: { <questionId>: ANSWER }, profiles: [PROFILE] }