04 – Bewertungslogik

Alle Bewertungen sind reine Funktionen über { answers, profiles } (rules.js → evaluate(state)), reproduzierbar und im Export enthalten.

Status

Code	Label	Symbol	Bedeutung
G	GRÜN	✔	bestätigt verfügbar und zulässig
Y	GELB	?	technisch wahrscheinlich oder organisatorisch ungeklärt
R	ROT	✖	nicht verfügbar oder nicht zulässig
X	GRAU	–	nicht geprüft

Status wird nie ausschließlich über Farbe dargestellt (Label + Symbol in UI, Markdown und JSON). Rangfolge für Kombinationen (worst): R < X < Y < G.

Capability-Ableitung

Jede Fähigkeit (CAPS) nennt die Fragen (ids), aus denen sie abgeleitet wird, eine eval-Funktion, meaning und je Status eine consequence. Wiederkehrende Ableitungen:

ynu(id): ja → G, nein → R, unbekannt → Y, leer → X
techOrg(base): _org = verboten oder _tech = nicht_installierbar → R; installiert + prod_freigegeben → G; sonst Y (installierbar, nur erlaubt, ungeklärt); nichts → X
single(id, map): Optionswert → Status laut Tabelle, sonst Y
Kombinationen über worst(...) (z. B. HTTPS = Zertifikatsquelle ∧ MDM-Vertrauen L11)
Overrides: Antwortstatus forbidden/na auf einer referenzierten Frage → R; J12-Verbote → R für Client-Capabilities

Client-Capabilities (CT_CAPS) werden aus den Profilen aggregiert (profileStatus): Pflichtprofile (sonst alle); ein Fehler → R; ein Unbekannt/fehlend → Y; alle Erfolg → G; keine Profile/kein Test → X. Nachweis = Liste der betroffenen Profile.

Fähigkeiten mit essential: true (z. B. Server-Support, Backup, HTTPS, Paketquellen, Git, Audit-Modell, SSO, Datenschutzrahmen, MySQL-Version/-Erreichbarkeit/-Backup, Zugriffspfade, MDM-Doku, JavaScript, Fetch/POST, Cookies, lokale CSS) blockieren Gates, solange sie GRAU sind.

Architecture Gates

Gates: SERVER (A, C, D, G, H, I), CLIENT (K + Client-Tests), NETWORK (F, L + Netz-Tests), SECURITY (B, J), DATABASE (E).

ready = coverage ≥ 0,70 ∧ keine essenzielle Fähigkeit GRAU, mit coverage = geprüfte (≠ GRAU) / alle Fähigkeiten des Gates. Ein Gate mit ROT-Einträgen kann „belastbar geprüft“ sein – geprüft heißt nicht positiv. Erst wenn CLIENT und NETWORK ready sind, darf die Frontend-Bewertung C („moderne dynamische Webanwendung“) vergeben werden.

Frontend-Baseline (L4)

Kernfähigkeiten: JavaScript, ES2020+, Fetch (GET), Fetch-POST, Cookies, lokale CSS.

Bewertung	Bedingung
GRAU	keine Client-Tests vorhanden → Arbeitsannahme B, Entscheidung unzulässig
A	JavaScript oder Fetch auf einem Pflichtclient ROT, oder Richtlinie K04/L07 = blockiert
C	alle Kernfähigkeiten GRÜN ∧ LocalStorage nicht ROT ∧ (SSE oder WebSocket GRÜN) ∧ Gates CLIENT und NETWORK ready
B	sonst

Asset-Strategie (L6): lokale CSS GRÜN ∧ extern/CDN nicht GRÜN → self-hosted zwingend; beides GRÜN → self-hosted empfohlen; ungeprüft → Arbeitsannahme self-hosted.

Frontend-Optionen (L5) werden mit festen Eigenschaften beschrieben und anhand der Testergebnisse eingestuft; Rangfolge: A → SSR-HTML zuerst; sonst SSR + Tailwind (Build-Time) + minimales Vanilla JS zuerst; HTMX nur nach bestätigtem Fetch; Blazor Server nur bei WebSocket Ende-zu-Ende + Hosting Bundle; SPA nur bei C und fachlichem Bedarf – nie ohne Ende-zu-Ende-Nachweis.

Stackvarianten

Drei Varianten werden datengetrieben zusammengesetzt:

Bevorzugt – ASP.NET Core LTS In-Process (Status = Hosting Bundle). Auth aus SSO/LDAPS, Jobs aus Service/Scheduler/In-Process, Realtime aus SSE/WS/Polling, Logging aus Datei/EventLog/zentral, Deployment aus H01; Frontend laut L4.
Konservativ – ASP.NET MVC 5 auf .NET Framework 4.8 (nur wenn rt_netfx ≠ ROT).
Alternativ – PHP/FastCGI (wenn PHP nicht ROT/GRAU), sonst Kestrel/Node hinter ARR (wenn ARR GRÜN), sonst statisches Frontend + Core-API.

Jede Variante listet Backend, Frontend, DB, Auth, API, Jobs, Realtime, Logging, Deployment, Testbarkeit, Voraussetzungen (mit aktuellem Status), Vor-/Nachteile.

Drei Ebenen

Innerhalb der Box: alle GRÜNEN Fähigkeiten.
Box erweitern: kuratierte Liste kleiner Anträge (Hosting Bundle, WebSocket-Rolle, URL Rewrite, AlwaysRunning-Pool, FRT, Windows Service, gMSA, LDAPS, Test-Site, internes Git, MySQL-TLS, Dump-Backup, WebDAV/Verben, Delegation, Event-Log-Quelle, CA-Verteilung per MDM) – nur die noch nicht GRÜNEN werden angezeigt, mit aktuellem Status. Ausdrücklich als Administrator-Aufgaben markiert, nie ausgeführt.
Außerhalb der Box: statische Beschreibung einer idealen Architektur ohne heutige Restriktionen.

Blocker und Restfragen

Blocker = ROT (essenziell zuerst) + nicht bereite Gates (mit Abdeckung und offenen essenziellen Fähigkeiten). Restfragen siehe 02-branching-logik.md.