# 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:

1. **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.
2. **Konservativ** – ASP.NET MVC 5 auf .NET Framework 4.8 (nur wenn `rt_netfx ≠ ROT`).
3. **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.