एप्लिकेशन एकीकरण स्वीकृति

खाता-मोड जाँच अब अल्पकालिक पहचान assertions प्राप्त करती हैं। नकारात्मक Launch खरीद स्थिति केवल खरीद का प्रमाण है, Licentivo रनटाइम अस्वीकृति का नहीं। रनटाइम प्रमाण के लिए आधिकारिक SDK जाँच आवश्यक है; इससे उत्पादन डिप्लॉयमेंट या SDK प्रकाशन निहित नहीं होता। खाता सीमा देखें।

प्रमाण के दो अलग स्तर हैं: नियंत्रित स्थानीय स्वचालित जाँच और बाहरी व्यापारी-sandbox जाँच। टेस्ट डबल, सफल कैटलॉग रीड, जेनरेट कॉन्फ़िगरेशन या सफल हेल्थ चेक वास्तविक भुगतान, लाइसेंस जारीकरण या सक्रियण कभी साबित नहीं करते। इस विकास पुनरावृत्ति में बाहरी सेवा कॉन्फ़िगरेशन स्पष्ट रूप से स्थगित था।

स्थानीय स्वचालित जाँच

रिपॉज़िटरी रूट से चलाएँ:

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

MySQL सहायक .cache के भीतर नया अलग सर्वर और डेटाबेस बनाता है; इसे ग्राहक डेटाबेस पर निर्देशित नहीं करना चाहिए। साधारण go test ./... अलग DSN न दिए जाने पर डेटाबेस परिदृश्य छोड़ता है। SDK/पैकेज परीक्षण और बिल्ड integration-packages.md में वर्णित हैं। रिलीज़ रिकॉर्ड के साथ परीक्षण आउटपुट और टूल संस्करण सुरक्षित रखें।

स्थानीय मैट्रिक्स में प्रमाणीकरण, सशर्त ईमेल सत्यापन, उत्पाद/वातावरण स्वामित्व, pending/expired/suspended स्थिति, भुगतान इवेंट रीप्ले, लाइसेंसिंग मिलान, नवीनीकरण/रिफ़ंड, खाता बदलाव, संरक्षित सत्र स्थायित्व और ऑफ़लाइन फ़ॉलबैक निर्णय शामिल हैं। जीवनचक्र परीक्षण नियंत्रित रनटाइम उपयोग करते हैं; वास्तविक क्रिप्टोग्राफ़िक रनटाइम सत्यापन आधिकारिक SDK की ज़िम्मेदारी है और रिलीज़ से पहले अलग परीक्षण होता है।

संचालन उपकरण → AI त्वरित एकीकरण के लिए सभी नौ भाषा विकल्प, प्लेटफ़ॉर्म/प्रोजेक्ट/सुविधा चयन, कॉन्फ़िगर न हुआ ड्राफ़्ट और सत्यापित सार्वजनिक कॉन्फ़िगरेशन से बना प्रॉम्प्ट जाँचें। दृश्य प्रॉम्प्ट के अनुसार कॉपी और डाउनलोड जाँचें और सुनिश्चित करें कि उत्पाद या वातावरण बदलने पर पुराना सत्यापित कॉन्फ़िगरेशन न रहे। प्रॉम्प्ट में सत्र, पासवर्ड, रनटाइम लाइसेंस/डिवाइस क्रेडेंशियल और प्रबंधन कुंजी नहीं होनी चाहिए; प्रॉम्प्ट बनाना या कॉपी करना AI सेवा कॉल नहीं करना चाहिए। ऊपर स्रोत-बंडल Node परीक्षण कमांड शुद्ध जनरेटर जाँचता है। जेनरेट प्रॉम्प्ट या बाद में AI टूल से बना कोड भी भाषा परीक्षण और नीचे बाहरी स्वीकृति चरण माँगता है।

बाहरी sandbox स्वीकृति तैयार करें

1. पहुँच योग्य HTTPS ओरिजिन और प्रदाता वेबहुक वाला समर्पित Launch परीक्षण इंस्टेंस डिप्लॉय करें। live बिक्री अक्षम रखें।
2. एक भुगतान प्रदाता के sandbox क्रेडेंशियल और Licentivo रीड/राइट कनेक्शन कॉन्फ़िगर करें। भुगतान sandbox रिकॉर्ड अलग हैं, लेकिन कॉन्फ़िगर Licentivo सेवा उपयोग करते हैं और वास्तविक परीक्षण लाइसेंस/डिवाइस रिकॉर्ड बना सकते हैं। समर्पित परीक्षण उत्पाद/नीति और परीक्षण ग्राहक उपयोग करें।
3. sandbox प्लान प्रकाशित करें और ऐप एकीकरण से launch-config.json और सत्यापित product.json को .local/acceptance/ में निर्यात करें।
4. केवल समीक्षित Launch Python पैकेज स्थानीय रूप से इंस्टॉल करें: python -m pip install ./sdk/python, या उसका wheel इंस्टॉल करें। उसका निजी SDK कार्यान्वयन शामिल है।
5. export जैसी बिना मीटर की परीक्षण सुविधा उपयोग करें। --activate आधिकारिक SDK शुरू करता है, सिंक्रोनस रूप से refresh_online() कॉल करता है, सक्रिय ऑनलाइन स्थिति आवश्यक करता है और उसका संरक्षित-कार्रवाई API चलाता है। अकेला कैश किया ऑफ़लाइन ग्रांट यह जाँच पास नहीं कर सकता; यह जाँच मीटरिंग नहीं करती।

क्रेडेंशियल बिना इको के माँगे जाते हैं। ऑटोमेशन अपने निजी प्रक्रिया वातावरण में LAUNCH_ACCEPTANCE_EMAIL और LAUNCH_ACCEPTANCE_PASSWORD दे सकता है। पासवर्ड कमांड आर्गुमेंट, रिपोर्ट, स्क्रीनशॉट या कमिट फ़ाइलों में न रखें। टूल हर प्रमाणित जाँच के बाद अपना अस्थायी डेस्कटॉप सत्र निरस्त करता है, लेकिन सामान्य निकास पर डिवाइस निष्क्रिय नहीं करता।

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

टूल live वातावरण कॉन्फ़िगरेशन, गैर-loopback HTTP, क्रेडेंशियल वाले रीडायरेक्ट, बेमेल उत्पाद और रनटाइम सीक्रेट वाले सार्वजनिक कॉन्फ़िगरेशन अस्वीकार करता है। अनुरोध करने से पहले verify के बाहर सक्रियण/ऑर्डर assertions और checkout के बाहर चेकआउट निर्माण विकल्प अस्वीकार करता है। मौजूदा रिपोर्ट कभी ओवरराइट नहीं होतीं। रिपोर्ट में अनुमति-सूची वाले प्रमाण होते हैं, कच्ची प्रतिक्रिया, एक्सेस टोकन या लाइसेंस कुंजी नहीं। सर्वर या SDK न मिलने पर विफल जाँच बनती है, कृत्रिम सफलता नहीं।

स्थानीय व्यापारी जाँच scope: local_sandbox_probe और licensing_scope: not_called उपयोग करती हैं। verify --activate व्यापारी localhost पर होने पर भी आधिकारिक बाहरी लाइसेंसिंग सेवा से संपर्क करता है; यह संयोजन local_merchant_external_licensing_probe के रूप में licensing_scope: official_external_service सहित दर्ज होता है।

पहला भुगतान और सक्रियण

व्यापारी वेबसाइट पर परीक्षण चेकआउट बनाएँ, या स्थिर कार्रवाई UUID से बनाएँ:

$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

प्रदाता और प्लान संस्करण अपने प्रकाशित sandbox प्लान से बदलें। अनिश्चित चेकआउट निर्माण के पुनः प्रयास में वही कार्रवाई UUID रखें और दोबारा उपयोग करें। टूल ऑर्डर ID प्रिंट करता है। उस अपने ऑर्डर को व्यापारी खाता केंद्र में प्रदाता के आधिकारिक sandbox चेकआउट से पूरा करें। जाँच जानबूझकर प्रदाता UI इंटरैक्शन का अनुकरण नहीं करती।

प्रदाता द्वारा भुगतान की पुष्टि और वेबहुक प्राप्त होने के बाद:

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

यह प्रमाणित खाता, स्वामित्व वाला sandbox ऑर्डर, एंटाइटलमेंट, क्रेडेंशियल/उत्पाद मेल और वास्तविक आधिकारिक SDK संरक्षित कार्रवाई जाँचता है। लंबित प्राधिकरण सीमित अवधि में अधिकतम पाँच बार आज़माया जाता है (डिफ़ॉल्ट 30 सेकंड, अधिकतम 120), Retry-After का पालन करते हुए। अप्रत्याशित प्राधिकरण विफलता SDK का कच्चा त्रुटि पाठ प्रकट किए बिना दर्ज होती है।

जीवनचक्र स्वीकृति मैट्रिक्स

हर जारी भाषा/OS जोड़ी के लिए स्रोत संशोधन, Launch/client/SDK संस्करण, प्रदाता वातावरण, अनाम ग्राहक लेबल, ऑर्डर ID, अपेक्षित परिणाम, देखा परिणाम और संबंधित रिपोर्ट फ़ाइल नाम वाला दिनांकित रिकॉर्ड रखें। न चले पंक्तियों को not run चिह्नित करें। पहले भुगतान की जाँच से पूरे मैट्रिक्स को सफल न चिह्नित करें।

पहले जारी ऑफ़लाइन ग्रांट पर रिफ़ंड/निलंबन प्रभाव आधिकारिक SDK की हस्ताक्षरित ऑफ़लाइन नीति से सीमित रहते हैं। डिस्कनेक्ट रहते तत्काल निरस्तीकरण का दावा नहीं है। अनुबंध समाप्ति पर लंबी Launch बाधा अपस्ट्रीम निलंबन में देरी कर सकती है; अनुबंध सीमाएँ देखें।

पूर्णता और सुरक्षित प्रमाण

हर जाँच रिपोर्ट जानबूझकर acceptance_complete: false सेट करती है: वह केवल उसी बार वास्तव में चलाई जाँच दर्ज करती है। रिलीज़ स्वीकारने से पहले मैट्रिक्स और प्रदाता रिकॉर्ड जाँचें। बाहरी सेवाएँ बाद में कॉन्फ़िगर कर ऊपर के कमांड फिर चलाएँ; लापता परिणाम को सफल फ़्लैग से न बदलें या केवल स्थानीय परीक्षण सफल होने पर live बिक्री सक्षम न करें।