Abnahme der Anwendungsintegration

Kontomodus-Prüfungen beziehen nun kurzlebige Identitäts-Assertions. Ein negativer Launch-Kaufstatus belegt nur den Kaufstatus, nicht die Laufzeitverweigerung durch Licentivo. Der Laufzeitnachweis erfordert die Prüfung mit dem offiziellen SDK; eine Produktionsbereitstellung oder SDK-Veröffentlichung ist nicht impliziert. Siehe Kontogrenze.

Es gibt zwei getrennte Nachweisebenen: kontrollierte lokale automatisierte Prüfungen und externe Händler-Sandbox-Prüfungen. Ein Testdouble, erfolgreiches Kataloglesen, erzeugte Konfiguration oder bestandene Integritätsprüfung belegt niemals echte Zahlung, Lizenzerstellung oder Aktivierung. Die Konfiguration externer Dienste wurde für diese Entwicklungsiteration ausdrücklich zurückgestellt.

Lokale automatisierte Prüfungen

Im Repository-Stammverzeichnis ausführen:

go test ./...
go vet ./...
node --check internal/httpapi/web/app.js
node --check internal/httpapi/web/integration.js
node --check internal/httpapi/web/integration-prompts.js
node --test scripts/integration-prompts.test.mjs scripts/integration-state.test.mjs
python scripts/test_acceptance.py
./scripts/test-mysql.ps1

Der MySQL-Helfer erstellt einen neuen isolierten Server und Datenbanken unter .cache; er darf nicht auf eine Kundendatenbank gerichtet werden. Ein einfaches go test ./... überspringt Datenbankszenarien, sofern die isolierten DSNs nicht angegeben werden. SDK-/Pakettests und Builds sind in integration-packages.md beschrieben. Testausgabe und Toolversionen mit dem Release-Nachweis aufbewahren.

Die lokale Matrix umfasst Authentifizierung, bedingte E-Mail-Verifikation, Produkt-/Umgebungszugehörigkeit, Status pending/expired/suspended, Wiederholung von Zahlungsereignissen, Lizenzierungsabgleich, Verlängerungen/Erstattungen, Kontowechsel, geschützte Sitzungspersistenz und Entscheidungen zum Offline-Fallback. Lebenszyklustests verwenden kontrollierte Laufzeitumgebungen; tatsächliche kryptografische Laufzeitprüfung bleibt Aufgabe des offiziellen SDK und wird vor der Veröffentlichung separat getestet.

Für Betriebswerkzeuge → KI-Schnellintegration alle neun Sprachauswahlen, Plattform-/Projekt-/Funktionsauswahl, einen unkonfigurierten Entwurf und einen aus validierter öffentlicher Konfiguration erzeugten Prompt prüfen. Kopieren und Herunterladen mit dem sichtbaren Prompt vergleichen und sicherstellen, dass ein Produkt- oder Umgebungswechsel keine zuvor validierte Konfiguration beibehält. Prompts müssen Sitzungen, Passwörter, Laufzeit-Lizenz-/Gerätezugangsdaten und Management-Schlüssel ausschließen; das Erzeugen oder Kopieren eines Prompts darf keinen KI-Dienst aufrufen. Der obige Node-Testbefehl des Quellbundles prüft den reinen Generator. Ein erzeugter Prompt oder von einem KI-Tool daraus erzeugter Code benötigt weiterhin die Sprachtests und die folgenden externen Abnahmeschritte.

Externe Sandbox-Abnahme vorbereiten

1. Eine dedizierte Launch-Testinstanz mit erreichbarem HTTPS-Origin und Anbieter-Webhooks bereitstellen. Live-Verkäufe deaktiviert lassen.
2. Sandbox-Zugangsdaten eines Zahlungsanbieters und eine Licentivo-Lese-/Schreibverbindung konfigurieren. Zahlungs-Sandbox-Datensätze sind isoliert, verwenden aber weiterhin den konfigurierten Licentivo-Dienst und können echte Testlizenzen/Gerätedatensätze erstellen. Ein dediziertes Testprodukt, eine Testrichtlinie und Testkunden verwenden.
3. Einen Sandbox-Plan veröffentlichen und mit Anwendungsintegration launch-config.json und validiertes product.json nach .local/acceptance/ exportieren.
4. Lokal nur das geprüfte Launch-Python-Paket installieren: python -m pip install ./sdk/python, oder sein Wheel installieren. Seine private SDK-Implementierung ist enthalten.
5. Eine nicht gemessene Testfunktion wie export verwenden. --activate startet das offizielle SDK, ruft synchron refresh_online() auf, erfordert einen aktiven Online-Status und ruft dessen API für geschützte Operationen auf. Eine zwischengespeicherte Offline-Berechtigung allein kann diese Prüfung nicht bestehen; diese Prüfung testet keine Verbrauchsmessung.

Zugangsdaten werden ohne Echo abgefragt. Automatisierung kann LAUNCH_ACCEPTANCE_EMAIL und LAUNCH_ACCEPTANCE_PASSWORD in ihrer privaten Prozessumgebung bereitstellen. Passwörter nicht in Befehlsargumente, Berichte, Screenshots oder eingecheckte Dateien aufnehmen. Das Tool widerruft seine temporäre Desktop-Sitzung nach jeder authentifizierten Prüfung, deaktiviert Geräte aber beim normalen Beenden nicht.

python scripts/acceptance.py preflight --config .local/acceptance/launch-config.json --report .local/acceptance/01-preflight.json
python scripts/acceptance.py verify --config .local/acceptance/launch-config.json --expect not_purchased --report .local/acceptance/02-no-purchase.json

Das Tool lehnt live-Umgebungskonfiguration, Nicht-Loopback-HTTP, Weiterleitungen mit Zugangsdaten, nicht passende Produkte und öffentliche Konfiguration mit Laufzeitgeheimnissen ab. Aktivierungs-/Bestell-Assertions außerhalb von verify und Checkout-Erstellungsoptionen außerhalb von checkout werden vor dem Senden von Anfragen abgelehnt. Bestehende Berichte werden niemals überschrieben. Berichte enthalten nur zugelassene Nachweise, keine Rohantworten, Zugriffstoken oder Lizenzschlüssel. Ein fehlender Server oder ein fehlendes SDK erzeugt eine fehlgeschlagene Prüfung, keinen künstlichen Erfolg.

Lokale Händlerprüfungen verwenden scope: local_sandbox_probe und licensing_scope: not_called. verify --activate kontaktiert den offiziellen externen Lizenzdienst selbst dann, wenn der Händler auf localhost läuft; diese Kombination wird als local_merchant_external_licensing_probe mit licensing_scope: official_external_service erfasst.

Erste Zahlung und Aktivierung

Einen Test-Checkout auf der Händlerwebsite erstellen oder mit einer stabilen Operations-UUID erstellen:

$operation = [guid]::NewGuid().ToString()
python scripts/acceptance.py checkout --config .local/acceptance/launch-config.json --provider stripe --plan-version-id PLAN_VERSION_UUID --operation-id $operation --report .local/acceptance/03-checkout.json

Anbieter und Planversion durch Ihren veröffentlichten Sandbox-Plan ersetzen. Bei Wiederholung einer ungewissen Checkout-Erstellung dieselbe Operations-UUID behalten und wiederverwenden. Das Tool gibt die Bestell-ID aus. Diese eigene Bestellung über das Kundencenter des Händlers mit dem offiziellen Sandbox-Checkout des Anbieters abschließen. Interaktionen mit der Anbieteroberfläche werden von der Prüfung absichtlich nicht simuliert.

Nachdem der Anbieter die Zahlung bestätigt und der Webhook eingegangen ist:

python scripts/acceptance.py verify --config .local/acceptance/launch-config.json --order-id ORDER_UUID --expect-order paid --expect active --activate --product-config .local/acceptance/product.json --feature export --report .local/acceptance/04-activation.json

Dies prüft das authentifizierte Konto, die eigene Sandbox-Bestellung, Berechtigung, Übereinstimmung von Zugangsdaten/Produkt und eine tatsächliche geschützte Operation des offiziellen SDK. Ausstehende Autorisierung wird höchstens fünfmal innerhalb eines begrenzten Zeitfensters versucht (Standard 30 Sekunden, Maximum 120), unter Beachtung von Retry-After. Unerwartetes Autorisierungsversagen wird erfasst, ohne den rohen Fehlertext des SDK offenzulegen.

Lebenszyklus-Abnahmematrix

Für jedes veröffentlichte Sprach-/OS-Paar einen datierten Datensatz mit Quellrevision, Launch-/Client-/SDK-Versionen, Anbieterumgebung, anonymisierter Kundenbezeichnung, Bestell-IDs, erwartetem Ergebnis, beobachtetem Ergebnis und relevantem Berichtsdateinamen speichern. Nicht ausgeführte Zeilen als nicht ausgeführt markieren. Die gesamte Matrix nicht aufgrund der Erstzahlungsprüfung als bestanden markieren.

Auswirkungen von Erstattung/Aussetzung auf eine bereits ausgestellte Offline-Berechtigung bleiben durch die signierte Offline-Richtlinie des offiziellen SDK begrenzt. Ein sofortiger Widerruf ohne Verbindung wird nicht behauptet. Ein langer Launch-Ausfall beim Vertragsablauf kann die vorgelagerte Aussetzung verzögern; siehe Vertragsbeschränkungen.

Abschluss und aufbewahrte Nachweise

Jeder Prüfbericht setzt absichtlich acceptance_complete: false: Er erfasst nur die bei diesem Aufruf tatsächlich ausgeführten Prüfungen. Matrix und Anbieterunterlagen vor der Release-Abnahme prüfen. Externe Dienste später konfigurieren und obige Befehle fortsetzen; fehlende Ergebnisse nicht durch ein bestanden-Flag ersetzen und Live-Verkäufe nicht allein wegen bestandener lokaler Tests aktivieren.