# 06 – Abdeckungsprüfung: Sind die Architekturfragen beantwortbar?

Prüfung vor der Implementierung: Jede der neun Zielfragen des Discovery-Tools wird auf Kapitel, Prüffragen und abgeleitete Fähigkeiten abgebildet. Generiert aus dem Katalog; Ergänzungen kursiv.

Katalog: 211 Fragen (A: 13, B: 12, C: 41, D: 29, E: 21, F: 24, G: 8, H: 12, I: 9, J: 12, K: 12, L: 18), 104 Fähigkeiten (SERVER: 36, SECURITY: 11, DATABASE: 13, NETWORK: 23, CLIENT: 21), 38 Client-Tests.

| # | Architekturfrage | Kapitel/Fragen | Fähigkeiten | Beantwortbar? |
|---|---|---|---|---|
| 1 | Welche Webtechnologien können tatsächlich betrieben werden? | C (Handler, Pools, Module), D (Laufzeiten technisch/organisatorisch) | rt_*, iis_own_site, iis_arr, iis_websocket | ja – Stackvarianten nur aus GRÜN/GELB |
| 2 | Was ist bereits installiert? | A01, C01–C02, C08, C15, D_*_tech = installiert, E01, E16, H01 | rt_* (installiert), iis_* | ja – mit Kommandoausgabe als Nachweis |
| 3 | Was wäre technisch installierbar? | D_*_tech = installierbar, C02 (Available), C13, C26–C29 | levels.extend („Box erweitern“) | ja |
| 4 | Was ist organisatorisch für Produktion zugelassen? | D_*_org, C30, G01–G04, H08, J12, Antwortstatus forbidden | techOrg → G nur bei prod_freigegeben; sec_forbidden | ja – Trennung technisch/organisatorisch im Modell |
| 5 | Einschränkungen aus Server, IIS, AD, Netzwerk, Security, Rechten? | A07–A09, B01–B12, C18–C24, C35–C40, J01–J12, L01–L11 | srv_*, sec_*, iis_delegation, iis_rest_verbs, net_* | ja |
| 6 | DB-, API-, Hintergrundprozess-, Realtime-, Datei-, Logging-, Monitoring-Möglichkeiten? | E01–E21, F01–F13, G01–G08, C27, I01–I09, Client-Tests ws/sse/upload/download | db_*, int_*, bg_*, log_*, ct_ws, ct_sse, ct_upload, ct_download | ja – Realtime nur Ende-zu-Ende |
| 7 | Welche Deploymentwege existieren? | H01–H12, C38, D_pkg, D_devtools | dep_*, pkg_sources | ja |
| 8 | Welche Architekturvarianten sind realistisch? | Bewertung: stacks(), levels(), frontend (L4/L5) | alle | ja – drei Varianten mit Status der Voraussetzungen; Frontend nur nach Client-Tests |
| 9 | Welche Informationen fehlen noch? | openQuestions(): unbeantwortet / Unbekannt / später prüfen; Gates | gates.essentialOpen | ja – automatisch als Restfragen mit Befehl |

## Abdeckung der Anforderungen aus Kapitel L

| Anforderung | Umsetzung |
|---|---|
| L1 geführte Client-Bestandsaufnahme | Fragen L01–L11 + Profilformular im Client-Test (mit „So ermitteln Sie unbekannte Angaben“) |
| L2 reale Capability-Testseite | `site/clienttest/` – 38 Tests, jeder mit Erfolg/Fehler/Unbekannt, Fehlermeldung, Erklärung, Auswirkung, Notiz |
| L3 Profile vergleichen | Profile mit Pflicht-Flag, Vergleichsmatrix Feature × Profil × Entscheidung, kleinster gemeinsamer Nenner |
| L4 Progressive Enhancement | Bewertung A/B/C/GRAU aus Kernfähigkeiten und Gates |
| L5 Frontend-Entscheidung | sechs Varianten mit den geforderten Kriterien; SPA nie ohne Nachweis |
| L6 Tailwind/Assets | Asset-Strategie aus css_local/font_local vs. external/cdn; Build-Time-Modell im Bericht |
| L7 No-JS-Baseline | `site/clienttest/nojs.html` + Fragen L20–L26 |
| L8 Netz-/Tunnelverhalten | Tests fetch/fetch_post/websocket/sse/long_request/big_response/upload/download/session_lifetime/connection_drop; keine Last-/Pentests |
| L9 Client Capability Report | Bericht Abschnitt 8.1–8.10 |

## Lücken / bewusste Grenzen

- Ergebnisse sind nur so belastbar wie Nachweise: Das Tool erzwingt keine Evidenz, markiert aber „durch IT bestätigt“ und zeigt Nachweise in der Matrix.
- Dynamische Client-Tests (POST, SSE, WebSocket, Upload, Timeout, Session) brauchen den Probe-Server im realen Pfad; ohne ihn liefern sie **Unbekannt**, nie ein falsches GRÜN.
- Organisatorische Fragen (Freigaben, Prozesse) lassen sich nicht per Befehl belegen – sie erhalten den Status über „durch IT bestätigt“ und Ticket-/Ansprechpartner-Nachweis.