जब क्लाउड कोड को बिना निगरानी के (hands-off) चलाया जाता है, तो सत्यापन (verification) क्यों आवश्यक है?	क्योंकि आपने उस काम की निगरानी नहीं की, इसलिए आपको यह सुनिश्चित करने के लिए एक तरीका चाहिए कि काम सही हुआ है।
अनसुपरवाइज्ड (unsupervised) रन के लिए सत्यापन का स्तर कैसा होना चाहिए?	सत्यापन का स्तर उस जोखिम (rope) के अनुपात में होना चाहिए जो आपने रन को दिया है।
किसी अनसुपरवाइज्ड रन की जाँच शुरू करने के लिए सबसे पहले क्या देखना चाहिए?	क्लाउड सारांश (summary) के बजाय सीधे कोड के अंतर (diff) को देखना चाहिए।
कोड समीक्षा में "साफ सारांश" (tidy summary) का क्या खतरा है?	यह खतरनाक हो सकता है क्योंकि यह उन फ़ाइलों में बदलाव को छिपा सकता है जिनकी योजना नहीं थी।
एक अनसुपरवाइज्ड रन के लिए वास्तविक गेट (real gate) क्या है?	यह है कि क्या टेस्ट पास हुए और क्या क्लाउड ने वास्तव में उन्हें चलाया, न कि केवल यह दावा किया।
स्वचालित रूप से जाँच लागू करने के लिए किस तकनीक का उपयोग किया जाता है?	हुक (hooks) का उपयोग किया जाता है, जैसे कि स्टॉप हुक या पोस्ट टूल यूज़ हुक।
कौन सा हुक टेस्ट चलाता है और विफलता (failure) होने पर प्रक्रिया को समाप्त होने से रोकता है?	स्टॉप हुक (Stop hook)।
कोड में बदलाव की "ठंडी दूसरी राय" (cold second opinion) कैसे ली जा सकती है?	एक फ्रेश सेशन या सबएजेंट (subagent) खोलकर बदलाव की समीक्षा करनी चाहिए, जिसमें कोड निर्माण की कोई याद न हो।
हेडलेस (headless) रन की जाँच कैसे की जाती है?	उनके JSON परिणाम (JSON result) के माध्यम से सत्यापित किया जाता है।
अनसुपरवाइज्ड रन के दौरान अनुमतियों (permissions) के साथ क्या करना चाहिए?	अनुमतियों को बायपास करने के बजाय उन्हें ऑटो मोड (auto mode) में रखना चाहिए।