Entwurf der Vertragsanlage
Diese vollständige Leistungsbeschreibung soll mit derselben Version Anlage der B2B-AGB werden. Sie ist eine veröffentlichte Arbeitsfassung, keine bereits vereinbarte Leistung oder Vertragsaktivierung. Die Paketübersicht nennt die bestätigten Nettopreise zuzüglich gesetzlich anfallender Umsatzsteuer. Kauf und Testabo bleiben deaktiviert.
Alle Beispiele sind illustrativ und keine echten VLDX7-Messungen. Offene Kontingent- und Betriebsfragen stehen getrennt im Reviewabschnitt C. Eine Endfassung bedarf der ausdrücklichen Freigabe nach anwaltlicher Prüfung.
A1. Gegenstand und Arbeitsweise
VLDX7 ist ein webbasiertes System für automatisierte technische Readiness-Prüfungen. Du kannst berechtigte Projekte anlegen und die im vereinbarten Paket enthaltenen Prüfungen auslösen. VLDX7 stellt beobachtete technische Signale, nachvollziehbare Befunde, Angaben zur Messabdeckung und konkrete Bearbeitungshinweise bereit. Gegenstand ist die ordnungsgemäße Bereitstellung der vereinbarten Prüf- und Ausgabefunktionen; nicht geschuldet ist ein bestimmter Score oder die rechtliche, sicherheitstechnische oder wirtschaftliche Freigabe deiner Anwendung.
Ein Website-Scan ist ein beauftragter, in die Verarbeitung eingereihter Prüflauf für eine konkrete öffentliche Zieladresse. Er ist kein automatischer Vollcrawl der Domain. Die gemeinsame Basis beobachtet Erreichbarkeit, HTTPS und die Antwortdauer eines begrenzten Abrufs. Ein erreichbarer HTTP-Status beweist weder eine funktionierende Anmeldung noch erfolgreiche Geschäftsprozesse. Eine einzelne Antwortdauer ist kein Lasttest, kein kontinuierliches Verfügbarkeitsmonitoring und keine umfassende Performancebewertung.
Browserabhängige Prüfungen setzen voraus, dass die betreffende Seite tatsächlich geladen und gemessen werden kann. VLDX7 unterscheidet gemessene Befunde, unklare Ergebnisse, fehlende Messungen und technische Fehler. Ressourcenblockaden, Frames, Zeitlimits oder andere Abdeckungsgrenzen werden bei der Ergebnisinterpretation berücksichtigt. Eine fehlende oder unvollständige Messung wird nicht als erfolgreiche Prüfung ausgegeben.
A2. Privacy — Datenschutz- und Einwilligungssignale
Privacy sucht auf der untersuchten Seite nach erkennbaren Links zu Datenschutzhinweisen, sichtbaren Einwilligungsbedienelementen und Hinweisen auf Cookies, Browser-Speicher, Drittanbieterressourcen sowie Kategorien von Formularfeldern. Die statische Prüfung wertet die ausgelieferte Oberfläche und relevante Antwortinformationen aus. Bei ausgeführter Browsermessung kommen zeitlich und funktional begrenzte Beobachtungen zu Einwilligungssteuerung, Speicher und Drittanbietern hinzu. Dabei können vorgesehene Einwilligungsbedienelemente begrenzt betätigt werden; es werden keine allgemeinen Formularprozesse ausgefüllt oder abgesendet.
Du erhältst Einzelbefunde mit beobachtetem Signal, Einordnung, technischer Evidenz und nächstem Prüfschritt. Beispielsweise kann ein nicht beobachteter Datenschutzlink Anlass sein, den Footer und die Erreichbarkeit deiner Hinweise manuell zu prüfen. Dieses Beispiel ist illustrativ, keine echte VLDX7-Messung.
Privacy bewertet nicht vollständig den Text deiner Datenschutzerklärung, die Rechtsgrundlage sämtlicher Datenverarbeitungen, Verträge mit Dienstleistern oder die Rechtmäßigkeit jedes Cookies. Ein statischer Speicherhinweis beweist nicht, dass der betreffende Code tatsächlich ausgeführt wurde. Ein erkanntes Ablehnen-Feld beweist nicht die Wirksamkeit einer Einwilligungslösung. Die Ergebnisse ersetzen keine Datenschutzprüfung und keine Rechtsberatung.
A3. Shield — technische Sicherheitskonfiguration
Shield prüft HTTPS und ausgewählte Browser-Sicherheitsrichtlinien in HTTP-Antworten. Dazu gehören HSTS, Content Security Policy, Schutz vor MIME-Sniffing, Referrer-Policy, Schutz vor unerwünschter Einbettung, Cross-Origin-Opener-Policy und Permissions-Policy. Die Befunde beschreiben fehlende, auffällige oder nach den jeweiligen Prüfregeln unzureichende Einstellungen und geben Konfigurationshinweise.
Du erhältst zu beobachteten Auffälligkeiten Schweregrad, begrenzte beziehungsweise redigierte technische Evidenz und Handlungsempfehlungen. Beispielsweise kann ein fehlendes X-Content-Type-Options: nosniff Anlass sein, den Header zu ergänzen und danach benötigte Dateiauslieferungen zu testen. Dieses Beispiel ist illustrativ.
Shield ist kein Penetrationstest, kein vollständiger Schwachstellenscan und kein Nachweis erfolgreicher oder ausgeschlossener Angriffe. SQL-Injection-Tests, Credential-Angriffe, Lasttests oder sonstige aktive Sicherheitsprüfungen sind nicht Bestandteil dieser sechsmoduligen Leistungsbeschreibung. Eine strengere Richtlinie kann benötigte Integrationen beeinträchtigen; deshalb sind Änderungen vor produktivem Einsatz fachlich zu prüfen. Die Pflicht von DANWUCON, die vereinbarten Prüfungen ordnungsgemäß zu erbringen, bleibt bestehen.
A4. Access — automatisch erkennbare Barrieren
Access untersucht den geladenen Zustand der konkreten Zielseite mit einer lokal eingebundenen automatisierten Prüfengine. Die Prüfung erfolgt vor der automatischen Einwilligungsinteraktion. Sie unterscheidet verletzte, unklare, bestandene und nicht anwendbare Regeln; Einzelbefunde werden insbesondere für verletzte und unklare Regeln ausgegeben. Die Darstellung enthält zusätzlich einen Messstatus und eine Zusammenfassung der Abdeckung.
Du erhältst Regelbezüge, begrenzte technische Hinweise auf betroffene Elemente, zusammengefasste Knotenzahlen und Bearbeitungshinweise. Auch bei null ausgegebenen Verstößen bleibt erkennbar, ob überhaupt und mit welcher Abdeckung gemessen wurde. Beispielsweise kann ein Feld ohne zugeordnete Beschriftung Anlass sein, ein sichtbares, programmatisch verbundenes Label zu ergänzen. Dieses Beispiel ist illustrativ.
Access prüft keine vollständige Website, keine angemeldeten Benutzerabläufe und keine Formularstrecken. Je nach tatsächlicher Messabdeckung können zugängliche Same-Origin-Frames einbezogen werden; unzugängliche Frames und andere Messhindernisse begrenzen das Ergebnis. Entscheidend bleibt die ausgewiesene tatsächliche Abdeckung des jeweiligen Laufs. Historische oder nicht ausgeführte Messungen sind nicht als bestanden zu interpretieren. Eine automatisierte Prüfung ersetzt insbesondere keine manuelle Tastatur-, Screenreader- und Gebrauchstauglichkeitsprüfung und bestätigt weder vollständige WCAG-Erfüllung noch BFSG- oder sonstige Rechtskonformität.
A5. API — öffentliche Schnittstellenbeschreibung
API ruft begrenzt die öffentliche OpenAPI-JSON-Beschreibung unter /openapi.json auf derselben Origin ab und prüft unterstützte OpenAPI-3.0-/3.1-Beschreibungen. Untersucht werden vorhandene Operationen, dokumentierte Antwortverträge und Erfolgs-/Fehlerfälle, Benennungen und Beschreibungen sowie deklarierte Sicherheitsanforderungen.
Du erhältst strukturierte Scanbefunde zu erkannten Merkmalen oder Dokumentationslücken. Beispielsweise kann das Fehlen dokumentierter Fehlerantworten Anlass sein, erwartete Fehlerfälle im OpenAPI-Vertrag zu ergänzen. Dieses Beispiel ist illustrativ. Ist eine passende Beschreibung nicht verfügbar oder ungültig, wird dies als entsprechende Nichtverfügbarkeit oder Ungültigkeit ausgewiesen, nicht als erfolgreich abgeschlossene API-Prüfung.
API prüft die Beschreibung, nicht das tatsächliche Verhalten sämtlicher Endpunkte. Es bestätigt weder wirksame Authentifizierung noch vollständige Geschäftslogik, Lastfestigkeit oder Sicherheit der API. Es werden keine unbegrenzten externen Referenz- oder Weiterleitungsketten als Discoveryverfahren verfolgt.
A6. Repo — öffentliche GitHub-Projektinformationen
Repo ermöglicht die projektbezogene Zuordnung eines öffentlichen GitHub-Repositorys und einen bewussten separaten Abruf strukturierter Metadaten. Die Ausgabe umfasst Repositoryidentität und Zustand, sichtbare Projektfunktionen, Vorhandensein bestimmter Root-Manifeste, Dokumentationsdateien, Struktur-, Automations-, Deployment- und Toolingmerkmale sowie Angaben zur letzten sichtbaren CI-Aktivität. Zusammengehörige Rootinformationen werden an die ausgewiesene Quellidentität gebunden.
Du erhältst eine separate Zusammenfassung im Projektbereich. Beispielsweise kann eine nicht vorgefundene Security Policy Anlass sein, einen Meldeweg für Sicherheitsprobleme zu dokumentieren. Dieses Beispiel ist illustrativ. Ein nicht vorhandener CI-Lauf wird als solcher dargestellt und nicht als erfolgreicher Build.
Repo ist kein Quellcodeaudit, kein SAST- oder Secret-Scan und keine Abhängigkeits-, CVE- oder Lizenzkonformitätsanalyse. Ein Dateiname belegt weder gute Inhalte noch funktionierende Automation. Private Repositories sind nicht enthalten. Der Repo-Abruf ist kein Website-Scan; sein Ergebnis gehört nicht zum JSON-Scanexport. Ein eigener Repo-Download, ein PDF-Bericht und eine dauerhafte vollständige Repositoryhistorie werden nicht zugesagt.
A7. AI — deklarierte Agent-Schnittstellenmerkmale
AI verarbeitet eine projektgebundene Endpunktkonfiguration und ruft nach bewusster Auslösung begrenzt die öffentliche A2A-1.0-Agent-Card unter /.well-known/agent-card.json derselben Origin ab. Das Speichern der Konfiguration allein löst diese Zielabfrage noch nicht aus. Ausgewertet werden unterstützte deklarierte Schnittstellenbindungen, Kommunikationsmerkmale, Anzahl deklarierter Skills und vorhandene Sicherheitssignale. Vorhandene Signaturen werden dabei nicht kryptografisch verifiziert.
Du erhältst eine vorübergehend angezeigte strukturierte Beobachtung oder einen verständlichen Nichtverfügbarkeits-/Ungültigkeitshinweis. Beispielsweise bedeutet „Streaming deklariert“, dass die Agent Card diese Eigenschaft angibt, nicht dass ein Streamingauftrag erfolgreich durchgeführt wurde. Dieses Beispiel ist illustrativ.
AI führt keine Modelle, Agentenaufträge oder deklarierten Skills aus. Es sendet keine Testprompts und bewertet weder Halluzinationen, Bias, Modellqualität noch rechtliche KI-Konformität. Die Beobachtung ist keine zugesagte dauerhafte Historie und wird nicht als Capability-Ergebnis gespeichert oder in den Scanexport aufgenommen. Diese Produktgrenze ist keine Aussage darüber, ob technische Request-/Fehlerlogs entstehen; deren tatsächliche Inhalte und Fristen sind gesondert zu klären.
A8. Ausgaben, Historie und Score
Für Website-Scans stellt VLDX7 Status und Zeitbezug, verständliche Einzelbefunde mit Schweregrad, Einordnung und Handlungshinweis sowie separat zugängliche technische Evidenz bereit. Die Oberfläche zeigt die fünf neuesten Scans pro Projekt. Diese Anzeigegrenze ist weder eine Löschfrist noch die Zusage eines vollständigen Langzeitarchivs. Bei geeigneten vorhandenen abgeschlossenen Scans ist ein Vergleich hinzugekommener, behobener, geänderter und unveränderter Befunde vorgesehen. Unterschiedliche Scanbedingungen können die Vergleichbarkeit begrenzen; aus dem Vergleich folgt keine Prognose.
Der JSON-Scanexport enthält die tatsächlich vorliegenden Scan- und Befunddaten, Scannerinformationen sowie vorhandene Browser-/Access-Messzusammenfassungen und eine VLDX7-Herkunftsangabe. Er enthält keine nie ausgeführte Messung und nicht die separaten Repo-/AI-Ergebnisse. Ein gestalteter PDF-Bericht, Zertifikat, Gütesiegel oder White-Label-Bericht ist nicht vereinbart.
Ein Score verdichtet regelbasierte Beobachtungen zur Priorisierung. Er ist kein Prozentsatz rechtlicher Konformität, Sicherheit, Vollständigkeit oder Erfolgswahrscheinlichkeit. Maßgeblich für die weitere Bearbeitung sind konkrete Befunde, Prüfumfang, Zeitpunkt und ausgewiesene Grenzen. Fehlerfreie vereinbarte Mess- und Darstellungsfunktionen bleiben geschuldet; der Hinweis auf Automationsgrenzen entschuldigt keine fehlerhafte Implementierung dieser Funktionen.
A9. Paket- und Betriebsgrenzen
Core umfasst Privacy, Shield und Access für ein Projekt mit fünf enthaltenen Website-Scans je vereinbartem bezahltem Monatszeitraum. Pro umfasst alle sechs Module für drei Projekte mit 25 enthaltenen Website-Scans je vereinbartem bezahltem Monatszeitraum. Die Agency-Konzeption umfasst alle sechs Module für zehn Projekte mit 100 enthaltenen Website-Scans; sie wird erst nach tatsächlicher Bereitstellung und gesonderter Beschreibung des Team-/Kundenprojektablaufs angeboten. Aus Projektzahlen folgen keine zusätzlichen Benutzerplätze, Rollen oder Kundenportale.
Repo- und AI-Abrufe sind separate Vorgänge. Weder ihre Anrechnung auf das Scankontingent noch unbegrenzte Abrufe werden zugesagt. Verbindliche Abrufgrenzen, Trialkontingent, Zählweise fehlgeschlagener Scans, Übertragbarkeit ungenutzter Kontingente, Gültigkeit bezahlter Zusatzscans und Umgang mit Tarifwechseln sind vor Verkauf anhand des Reviewabschnitts C festzulegen. Ohne diese Festlegung ist die Vertragsanlage nicht verkaufsfertig.