क्या डुप्लिकेट gateway instances आपकी audit trail को बांट सकते हैं?

किसी ऐप bundle की कॉपी बनाना दूसरा स्थानीय गेटवे बनाने का सुरक्षित तरीका नहीं है। यह जांच है कि macOS के सामने दो विश्वसनीय दावेदार होने पर सॉफ्टवेयर क्रेडेंशियल, अनुमतियों, revoke और प्रमाण पर एक ही अथॉरिटी बनाए रख सकता है या नहीं।

खतरनाक विफलता हमेशा crash नहीं होती। Crash साफ दिखाई देता है। शांत विफलता तब होती है जब दो प्रोसेस स्वस्थ दिखते हैं, दोनों एजेंट अनुरोध स्वीकार करते हैं और दोनों उस व्यक्ति को भरोसा दिलाने के लिए पर्याप्त प्रमाण छोड़ते हैं जिसने उन्हें शुरू किया था। फिर क्रेडेंशियल बदलने, revoke करने या incident review के समय split सामने आता है: एक प्रोसेस को वह बात पता थी जो दूसरे को नहीं थी।

Sallyport को एक signed, हमेशा चलने वाले macOS menu-bar ऐप के रूप में बनाया गया है, जिसका vault core उसी प्रोसेस में चलता है। इसलिए stable, beta और copied bundles को साथ चलाना सामान्य काम नहीं, बल्कि जानबूझकर किया गया concurrency और identity test होना चाहिए। टेस्ट का लक्ष्य एक सीमित सवाल का जवाब देना है: क्या सिस्टम डुप्लिकेट को रोकता है, सुरक्षित रूप से coordinate करता है, या उसे चलने देता है और फिर भी एक authoritative vault तथा एक verifiable history बनाए रखता है?

दो bundles का मतलब अपने-आप दो identities नहीं होता

इस प्रयोग में Finder का नाम identity का सबसे कमजोर संकेत है। Sallyport.app, Sallyport Beta.app और Sallyport Copy.app इंसान को तीन अलग ऐप लग सकते हैं, जबकि उनके bundles के भीतर bundle identifier और signing identity एक ही हो सकते हैं।

Apple bundle identifier को macOS द्वारा ऐप-स्तर की पहचान के लिए इस्तेमाल किया जाने वाला identifier बताता है। उसके code-signing दस्तावेज बताते हैं कि designated requirement सिस्टम को updates के दौरान code को उसी application के रूप में पहचानने का तरीका देती है। ये अवधारणाएं उपयोगी हैं, लेकिन इनमें से कोई भी आपके असली सवाल का उत्तर नहीं देती। macOS द्वारा identity पहचान लेना यह साबित नहीं करता कि दो live processes state को सुरक्षित ढंग से own कर रहे हैं।

सबसे पहले दर्ज करें कि आपने वास्तव में क्या लॉन्च किया। यह vault खोलने, agent जोड़ने या किसी चीज को approve करने से पहले करें।

APP_A="/Applications/Sallyport.app"
APP_B="$HOME/Desktop/Sallyport Beta.app"

for app in "$APP_A" "$APP_B"; do
  echo "=== $app ==="
  plutil -p "$app/Contents/Info.plist" | grep -E 'CFBundleIdentifier|CFBundleShortVersionString|CFBundleVersion'
  codesign -dvv "$app" 2>&1 | grep -E 'Identifier=|TeamIdentifier=|Authority='
  codesign -d -r- "$app" 2>&1 | grep 'designated =>'
done

आउटपुट का आकार सटीक text से अधिक महत्वपूर्ण है:

=== /Applications/Sallyport.app ===
"CFBundleIdentifier" => "..."
"CFBundleShortVersionString" => "..."
Identifier=...
TeamIdentifier=...
designated => identifier "..." and anchor ...

इस artifact को टेस्ट रिकॉर्ड के साथ रखें। यदि दोनों intact bundles एक ही identifier और designated requirement बताते हैं, तो उन्हें एक code identity की दो कॉपियां कहें। यदि वे अलग हैं, तो उन्हें अलग code identities कहें। “stable” और “beta” जैसे labels को इन तथ्यों का विकल्प न बनाएं।

एक और अंतर है जिसे टीमें अक्सर मिला देती हैं: code identity, storage identity नहीं होती। एक ही designated requirement वाले दो प्रोसेस से उम्मीद हो सकती है कि वे वही protected material पढ़ें। अलग requirements वाले दो प्रोसेस को सिस्टम से अलग permissions मिल सकती हैं। इनमें से कोई परिणाम यह नहीं बताता कि वे encrypted vault को सुरक्षित रूप से साझा कर सकते हैं या audit chain में जोड़ सकते हैं। Storage ownership की अलग जांच करनी होगी।

विभाजित audit trail अधूरे log से भी खराब है

अधूरा journal बताता है कि प्रमाण गायब है। Split journal दो अंदरूनी तौर पर consistent कहानियां बता सकता है, जिनमें हर कहानी में दूसरे प्रोसेस के रिकॉर्ड गायब हों। इससे incident review धीमा होता है और एक process के नजरिए से revoked session भी valid दिखाई दे सकता है।

Action gateway के लिए journal को बाद में इन ठोस सवालों का जवाब देना चाहिए:

• किस agent process ने action मांगा?
• किस gateway process ने उसे authorize या deny किया?
• किस credential reference का इस्तेमाल हुआ, बिना secret दिखाए?
• क्या इंसान ने session approve किया था या individual call?
• Revoke action से पहले हुआ या बाद में?

यदि process A और process B अलग-अलग sequence लिखते हैं, तो दोनों sequences अपने-अपने स्तर पर verify हो सकते हैं। यह पर्याप्त नहीं है। Cryptographic chain की verification यह दिखाती है कि उस chain के मौजूद records में बिना पकड़े बदलाव नहीं हुआ। यह अपने-आप साबित नहीं करती कि किसी अन्य legitimate writer ने कहीं दूसरी chain शुरू नहीं की।

इसीलिए tamper evidence और completeness के बीच फर्क महत्वपूर्ण है। Hash chain उस chain में मौजूद records के बीच संबंध को सुरक्षित रखती है। Completeness के लिए स्पष्ट ownership rule, एक append point या हर accepted branch तथा उसके reconciliation का टिकाऊ प्रमाण चाहिए। यदि यह गलत हुआ, तो operator verification सफलतापूर्वक चला सकता है और फिर भी आधी कार्रवाइयां miss कर सकता है।

बात केवल logs तक सीमित नहीं है। Split audit trail अक्सर split authority के बाद आता है:

• एक process मानता है कि vault locked है, जबकि दूसरे में unlocked session है।
• एक process agent run को revoke करता है, जबकि दूसरा उसे स्वीकार करता रहता है।
• एक process per-call approval दर्ज करता है, जबकि दूसरा पूछने की जरूरत नहीं समझता।
• एक process final action result लिखता है, जबकि दूसरा केवल request लिखता है।

टेस्ट का मूल्यांकन इस आधार पर न करें कि दोनों कॉपियां HTTP call या SSH command पूरा कर सकती हैं या नहीं। सफल call केवल यह साबित करती है कि कोई रास्ता मौजूद है। टेस्ट तब पास होता है जब बाद का reviewer पूरी action history बिना यह अनुमान लगाए दोबारा बना सके कि missing state किस कॉपी के पास थी।

रेस शुरू करने से पहले ownership contract तय करें

Expected invariants के बिना duplicate-instance test केवल किस्से पैदा करता है। पहले contract लिखें, फिर उसे तोड़ने की कोशिश करें।

स्थानीय gateway copies के लिए तीन उचित contracts हैं।

1. Exclusive ownership। पहला process vault और journals का owner होता है। बाद की कॉपियां काम करने से मना करती हैं, पहले ऐप को सामने लाती हैं या स्पष्ट कारण के साथ exit करती हैं।
2. Handoff के साथ एक active process। बाद का launch owner को खोजता है और उससे requested work करने को कहता है। नया process खुद unlock, approve या append नहीं करता।
3. Coordinated multi-process ownership। एक से अधिक process चल सकते हैं, लेकिन सभी जानबूझकर बनाए गए shared-state protocol का इस्तेमाल करते हैं, जो atomic vault changes और एक auditable event order बनाए रखता है।

High-consequence state रखने वाले desktop application के लिए पहला contract आमतौर पर समझना सबसे आसान है। तीसरा valid हो सकता है, लेकिन इसके लिए कहीं अधिक मजबूत proof चाहिए। “दोनों एक ही folder की ओर point करते हैं” coordination protocol नहीं है।

टेस्ट से पहले expected outcomes को table में लिखें। हर outcome को observable रखें।

शब्दों का महत्व है। “Copies को conflict नहीं करना चाहिए” testable नहीं है। “किसी existing owner द्वारा वही agent run revoke करने के बाद copied bundle successful action response नहीं लौटा सकता” testable है।

Product behavior और test harness behavior को भी अलग रखें। Shell script दो launches को गलती से रोक सकता है, लेकिन इससे यह साबित नहीं होता कि ऐप उन्हें रोकता है। Reverse proxy requests को serialize कर सकता है, लेकिन इससे यह साबित नहीं होता कि local vault simultaneous requests संभालता है। Harness को उस bug को हल न करने दें जिसे आप ढूंढना चाहते हैं।

बदले हुए artifacts से पहले intact copies लॉन्च करें

साफ प्रयोग intact app bundles से शुरू होता है। Application bundle को उसके अंदर की files बदले बिना copy करें, कॉपियों को अलग सामान्य locations में रखें और हर path दर्ज करें। पहले executable या Info.plist बदलने पर code signing अक्सर invalid हो जाती है और प्रयोग signature-validation test बन जाता है।

Apple का TN3127 बताता है कि यह सीमा क्यों महत्वपूर्ण है: macOS यह तय करने के लिए designated requirements पर निर्भर करता है कि code स्थापित identity को पूरा करता है या नहीं। यदि bundle में बदलाव के बाद उसका signature validate नहीं होता, तो refusal सही हो सकता है, लेकिन उससे valid builds के बीच duplicate ownership के बारे में कुछ पता नहीं चलता।

एक छोटी launch worksheet इस्तेमाल करें। इसमें केवल वे facts रखें जिन्हें आप देख सकते हैं:

Test ID: duplicate-owner-01
Build A path: /Applications/Sallyport.app
Build B path: /Users/tester/Desktop/Sallyport Beta.app
Bundle IDs: [recorded value A] / [recorded value B]
Designated requirements: [recorded value A] / [recorded value B]
Launch order: A first, B second
Vault state before launch: locked
Agent process IDs: [record after start]
Expected contract: exclusive ownership

फिर A लॉन्च करें, उसके idle state तक पहुंचने की प्रतीक्षा करें और B लॉन्च करें। कुछ और करने से पहले परिणाम दर्ज करें। Refusal इतनी स्पष्ट होनी चाहिए कि operator जान सके कि state का owner कौन-सा existing process है। Silent exit support tickets पैदा करता है और लोगों को तब तक retry करने के लिए उकसाता है जब तक race न बन जाए।

ऐप विंडो के बजाय operating system से वास्तविक process separation की पुष्टि करें। दूसरी window उसी process की हो सकती है, जबकि background helper दूसरी process बना सकता है, भले ही केवल एक menu-bar item दिखाई दे।

pgrep -alf 'Sallyport|sp mcp|sp-ssh'
ps -axo pid,ppid,start,command | grep -E 'Sallyport|sp mcp|sp-ssh' | grep -v grep

आउटपुट को timeline artifact मानें। हर launch phase के तुरंत बाद इसे save करें। जहां संभव हो, parent process IDs भी शामिल करें। इससे यह समझने में मदद मिलेगी कि दूसरी action independent app process, agent-launched shim या child helper से आई थी।

इस काम के लिए production credentials इस्तेमाल न करें। HTTP requests को ऐसे dedicated endpoint पर भेजें जो harmless method या controlled test service स्वीकार करे। SSH के लिए restricted command वाला dedicated account या ऐसा host इस्तेमाल करें जिसे production access न हो। आप process ownership और audit behavior जांच रहे हैं, destructive endpoint की जरूरत नहीं है।

Vault gate का एक स्पष्ट owner होना चाहिए

Vault gate तभी absolute boundary है जब हर action path उसी gate तक पहुंचता हो। यदि एक process दूसरे process के lock करने, quit करने या access खोने के बाद भी unlocked रह सकता है, तो “locked” असली system state के बजाय केवल एक window को बताता है।

पहले benign HTTP action के साथ यह sequence जांचें:

1. Copy A को vault locked होने पर शुरू करें।
2. एक agent process को local MCP shim से connect करें और harmless action का प्रयास करें। Denial की अपेक्षा रखें।
3. सामान्य local interaction से A को unlock करें, फिर action दोहराएं। सफल परिणाम और उसकी activity entry दर्ज करें।
4. A उपलब्ध रहते हुए copy B लॉन्च करें। B को अभी unlock न करें।
5. उसी agent process और एक नए agent process से B के reachable route के माध्यम से वही action करने का प्रयास कराएं, यदि ऐसा route मौजूद है।
6. A को lock करें या quit करें, फिर दोनों agents से requests दोहराएं।

Passing result ownership contract पर निर्भर करता है, लेकिन unsafe result को आसानी से पहचाना जा सकता है: B वह action इसलिए कर देता है क्योंकि उसने ऐसी authority रखी या खुद हासिल कर ली जिसे इंसान A को lock करते समय देख नहीं सकता था।

यहीं एक आम सलाह विफल होती है: “बस unlocked state साझा कर दो ताकि beta बार-बार न पूछे।” Development में बार-बार local authentication परेशान कर सकता है, इसलिए लोग ऐसा कहते हैं। यह तभी सही है जब shared state का defined owner, स्पष्ट lifetime और ऐसा revoke path हो जिसे हर process action से पहले देखता हो। सुविधा के लिए prompt बचाना किसी अदृश्य दूसरे unlock state को बनाने के लायक नहीं है।

Hardware-gated vault model एक उपयोगी test boundary देता है। Vault locked होने पर agent को placeholder secret, आधा तैयार request या ऐसा queued action नहीं मिलना चाहिए जो unlock के बाद चल जाए। Action gateway को approved action खुद execute करके उसका result लौटाना चाहिए। मानव के local state तय करने तक उसे agent को credential material नहीं देना चाहिए।

Action response और journal evidence दोनों दर्ज करें। History से गायब denial बाद की debugging को अनावश्यक रूप से कठिन बना देती है। Unlock या approval record के बिना दिखने वाली success इससे भी खराब है।

Session approval किसी process से जुड़ी हो, label से नहीं

Per-session authorization का उद्देश्य किसी खास agent run पर इंसान का निर्णय लेना है। जब दोनों runs का नाम मिलता-जुलता हो, वे एक ही terminal से चलें या copied bundle के जरिए connect हों, और authorization एक process से दूसरे में फैल जाए, तो इसका अर्थ खत्म हो जाता है।

Approval record से operator को इन सवालों का जवाब मिलना चाहिए: किस executable ने request की, उसे किसने sign किया, process कब शुरू हुआ और उसकी authority कब खत्म हुई? Process की code-signing authority खास तौर पर उपयोगी है, क्योंकि केवल terminal command उसके पीछे का code नहीं बताती।

यह test दो जानबूझकर अलग agent processes के साथ चलाएं। एक shell process को reuse करके उसे दो agents न कहें।

# Terminal 1
sp mcp

# Terminal 2
sp mcp

Commands जानबूझकर साधारण हैं। महत्वपूर्ण बात यह है कि वे आपके test harness में अलग agent processes से आएं और हर एक एक harmless call भेजे। पहले session को approve करें और दूसरे को unanswered छोड़ दें। यदि setup approval card में process details दिखाता है, तो दिखाई गई authority capture करें और उसे शुरू किए गए process से मिलाएं।

अब ये transitions आजमाएं:

• Approved agent process से exit करें, फिर उसी command के साथ replacement process शुरू करें।
• पहला session approved रहते हुए copied gateway launch या activate करें।
• Session journal से पहला run revoke करें।
• दोनों processes से एक और harmless request भेजने को कहें।

Expected rule सरल है: approval किसी run के exit होने तक उसी run की होती है, और revoke उस run की authority हर जगह खत्म करता है। Replacement process केवल परिचित दिखने के कारण approval inherit न करे। Copied gateway उसी agent connection को ऐसी permission न समझे जो उस निर्णय को bypass कर दे जिसकी जरूरत उसके peer को होती।

Per-session approval को per-call keys से न मिलाएं। Session approval यह तय करती है कि agent process अपने run के दौरान gateway इस्तेमाल कर सकता है या नहीं। Per-call key यह तय करती है कि इस specific credential के हर use पर नया मानवीय निर्णय चाहिए या नहीं। एक caller की lifetime के बारे में है, दूसरा credential की sensitivity के बारे में। Test notes में दोनों को मिलाने पर परिणाम गलत समझेंगे।

Per-call approval छिपे duplicate paths दिखाती है

हर use पर approval मांगने वाला credential duplicate-instance probe के लिए अच्छा है, क्योंकि इससे software को हर action का अलग हिसाब रखना पड़ता है। एक dedicated test credential या SSH target लें, उसकी per-call requirement सेट करें और दोनों candidate paths से एक साथ benign requests भेजें।

टेस्ट का सवाल “क्या मुझे दो prompts मिले?” नहीं है। दो prompts सही भी हो सकते हैं या यह दिखा सकते हैं कि दोनों कॉपियों ने अलग authority बना ली। सवाल यह है कि क्या हर completed action के साथ एक approval जुड़ी है और क्या कोई copy दूसरी copy की approval reuse कर सकती है।

टेस्ट के दौरान एक छोटा event ledger बनाएं:

अपने test endpoint या harness से बनाए गए request IDs इस्तेमाल करें। Windows दिखने के क्रम पर निर्भर न रहें। Desktop scheduling visible prompts का क्रम बदल सकती है और HTTP result बाद के request के बाद लौट सकता है।

खराब परिणाम शुरू में साफ-सुथरा लग सकता है: copy A में request A approve करें, फिर पता चले कि copy B अपनी approval के बिना request B पूरा कर सकती है। इसका अर्थ है कि approval state operator के निर्णय के बिना boundary पार कर गई। उलटी विफलता भी गंभीर है: B को approve करें, लेकिन result A की activity stream में दर्ज हो और यह स्पष्ट न हो कि A ने काम क्यों किया।

Vault lock करने, एक copy quit करने और पहले agent run revoke करने के बाद race दोहराएं। ये transitions stale in-memory state पकड़ते हैं। सबसे revealing bugs अक्सर state change के बाद सामने आते हैं, जब एक process ने अपना view refresh कर लिया हो और दूसरे ने नहीं।

Audit verification को before-and-after proof चाहिए

“Log ठीक दिखा” वाली test report प्रमाण नहीं है। Baseline capture करें, controlled actions बनाएं, run के बाद verify करें और expected records की observed records से तुलना करें।

इस gateway के लिए बताए गए audit design का एक लाभ है: वही write-blind encrypted, hash-chained log Sessions journal और Activity journal दोनों में दिखाई देता है। इसलिए journals एक ही history के दो views होने चाहिए, दो अलग-अलग maintain किए गए records नहीं जो केवल एक जैसे लगते हों।

Empty या स्पष्ट रूप से bounded test period से शुरू करें। Starting time लिखें, फिर ज्ञात sequence बनाएं: locked रहते denial, approved session action, per-call approved action, per-call denial, session revoke और revoke के बाद denied action। Sequence इतना छोटा रखें कि हर event का हिसाब दे सकें।

इसके बाद offline verifier चलाएं:

sp audit verify

पूरा command output रखें, failure होने पर nonzero exit status भी। Verifier को ciphertext chain जांचने के लिए vault access की जरूरत नहीं होनी चाहिए। इससे investigator credential store unlock किए बिना integrity verify कर सकता है, और duplicate-process test बिगड़ने पर यही चाहिए।

Verification केवल पहला check है। तीन views की तुलना करें:

1. आपका external test ledger, जिसमें हर request ID और expected result हो।
2. Sessions journal, जिसमें approvals, run exits और revokes हों।
3. Activity journal, जिसमें हर action attempt और result हो।

हर ledger event को उचित journal view से map होना चाहिए। Bounded test period की हर journal event का संबंध उस चीज से होना चाहिए जिसे आपने जानबूझकर generate किया था। Extra records की जांच करें, भले ही chain verify हो। Unexpected successful action retry, queued request या इस बात का प्रमाण हो सकता है कि दूसरी process आपके exit समझने के बाद भी active थी।

यदि दो independent chains verify हो जाएं, तो इसे history completeness की विफलता मानें, जब तक documented multi-process design parent relationship और deterministic merge दर्ज न करता हो। टेस्ट के बाद exported logs को जोड़कर इसे ठीक न करें। Manual merge report बनाता है, audit trail नहीं।

Recovery behavior तय करता है कि duplicate bug incident बनेगा या नहीं

Ownership attempts के बीच interruption की उम्मीद रखें। लोग beta builds को force-quit करते हैं। Laptops sleep में चले जाते हैं। Test harness approval और action result के बीच process को kill कर देता है। Application को इन स्थितियों को इस तरह संभालना चाहिए कि abandoned owner हमेशा के लिए काम को न रोके और replacement owner यह मानकर न चले कि कोई action हुआ ही नहीं।

कम से कम चार interruption points जांचें:

• Request मिलने के बाद, approval मिलने से पहले copy A को kill करें।
• Approval के बाद, external action पूरा होने से पहले copy A को kill करें।
• Action पूरा होने के बाद, result agent को दिखाई देने से पहले copy A को kill करें।
• हर interruption के तुरंत बाद copy B launch करें।

हर case के लिए safe recovery rule पहले लिखें। एक उचित rule यह हो सकता है कि B तब तक refuse करे जब तक वह यह स्थापित न कर दे कि A exit कर चुका है और durable state recover हो गई है। दूसरा विकल्प यह हो सकता है कि B केवल committed audit records से resume करे और uncertain action को success या failure कहने के बजाय unknown के रूप में दर्ज करे। सही rule implementation पर निर्भर है, लेकिन अनुमान लगाना कभी स्वीकार्य नहीं है।

Uncertainty न छिपाएं। Local process के मरने के साथ external system HTTP request या SSH command पूरा कर सकता है। यदि gateway साबित नहीं कर सकता कि operation पूरा हुआ या नहीं, तो उसे इस ambiguity को evidence में बनाए रखना चाहिए। Unknown write को retry करने पर असली दुनिया में दूसरा action हो सकता है। पहले action के न होने का दिखावा करने पर audit story झूठी बनती है।

यहीं instant revoke की भी जांच करें। एक agent run revoke करें, तुरंत बाद current owner terminate करें, copy launch करें और उसी agent से वही action करने का प्रयास करें। यदि replacement process missing in-memory state को fresh session समझता है, तो revoke पर्याप्त durable नहीं था। ऐसा revoke जिस पर भरोसा केवल तब तक किया जा सके जब एक process जीवित हो, failure के दौरान भरोसेमंद revoke नहीं है।

जब तक sharing जानबूझकर न हो, stable और beta tests अलग रखें

Stable और beta साथ चलाने का आकर्षण रहता है क्योंकि दोनों उपयोगी हैं। Stable में असली काम होता है और beta को realistic pressure चाहिए। बिना deliberate compatibility contract के दोनों को उसी vault और journals पर चलाने से experiment की observability के साथ production के risks मिल जाते हैं।

दो arrangements में से एक चुनें। सुरक्षित arrangement में beta को dedicated test vault, test credentials, test agents और अलग evidence set दें। इससे beta behavior की जांच होगी और experimental process production action record का हिस्सा नहीं बनेगा।

कठिन arrangement में stable और beta जानबूझकर state साझा करते हैं। इसे तभी चुनें जब cross-version continuity खुद test का विषय हो। इस स्थिति में version skew दोनों दिशाओं में जांचें: stable state own करे फिर beta launch हो, beta state own करे फिर stable launch हो, एक process upgrade करे जबकि दूसरा खुला रहे और एक process rollback करे जब दूसरा नई history लिख चुका हो। दर्ज करें कि हर transition refuse, handoff या coordinate होता है।

Sallyport के लिए fixed decision ladder एक उपयोगी acceptance frame देती है: vault gate absolute रहता है, नए agent process को default रूप से अपना session authorization मिलता है और per-call approval वाली credentials हर use पर फिर पूछती हैं। Implementation exclusive ownership या safe handoff चुन सकती है, लेकिन दो bundles को सुविधाजनक बनाने के लिए इन controls को चुपचाप कमजोर नहीं कर सकती।

टेस्ट का अंत ऐसे स्पष्ट statement से करें जिसे दूसरा engineer चुनौती दे सके: vault का owner कौन था, दूसरी copy आने पर क्या हुआ, क्या कोई action approval या revoke boundary पार कर गया और क्या एक offline verification ने हर generated event को cover किया। यदि उत्तर इस बात पर निर्भर करता है कि आपने संयोग से कौन-सी window देखी, तो टेस्ट फिर चलाएं। प्रमाण अभी पर्याप्त अच्छा नहीं है।