जानिए 'बदलें नहीं' प्रॉम्प्ट पैटर्न जिससे आप एक छोटा परिवर्तन कर सकें जबकि मुख्य UI फ्लो, बिजनेस रूल्स और महत्वपूर्ण व्यवहार जमे रहें ताकि कुछ भी अनपेक्षित रूप से बदल न जाए।
एक “छोटा” बदलाव शायद ही कभी छोटा ही रहता है। आप एक बटन लेबल बदलने के लिए कहते हैं, और अचानक पेज लेआउट बदल जाता है, कोई फॉर्म सही तरह से वेलिडेट नहीं करता, या चेकआउट स्टेप अलग तरह से व्यवहार करने लगता है। ऐप्स जुड़े हुए सिस्टम होते हैं। UI, लॉजिक, डेटा और इंटीग्रेशन एक-दूसरे पर निर्भर करते हैं।
अक्सर इसका कारण अस्पष्ट सीमाएँ होती हैं। अगर अनुरोध कहता है “साइनअप सरल बनाओ,” तो बिल्डर (मानव या AI) को अंदाज़ लगाना पड़ता है कि “सरल” का क्या मतलब है। अंदाज़ लगाने से अतिरिक्त संपादन होते हैं: फील्ड हटाना, स्टेप बदलना, कॉपी बदलना, या वेलिडेशन को फिर से लिखना। एक और कारण छिपी निर्भरताएँ हैं। एक छोटा UI बदलाव किसी ऐसे कॉम्पोनेंट का उपयोग कर सकता है जो पाँच अन्य स्क्रीन पर भी दिखता हो।
एक सुरक्षित इटरेशन का मतलब है कि आप जो एक अपेक्षित सुधार चाहते हैं वह मिल जाए और बाकी सब प्रभावी रूप से बिल्कुल वैसा ही बना रहे। गैर-तकनीकी टीम के लिए इसका मतलब है कि वर्कफ़्लो उपयोगकर्ताओं के लिए वही महसूस होना चाहिए, सपोर्ट स्क्रिप्ट्स वही मेल खाती रहें, और रिपोर्टिंग समझ में आती रहे। तकनीकी टीम के लिए इसका मतलब है कि कोई अनपेक्षित बदलाव रूट्स, डेटा शेप्स, API कांट्रैक्ट्स, या एज-केस व्यवहार में न हो।
इसे संभव बनाने के लिए, आपको उन हिस्सों को फ्रीज़ करना होगा जो नहीं हिलने चाहिए। व्यवहार में, यह आम तौर पर क्रिटिकल फ्लोज़ (उपयोगकर्ता जो सटीक स्टेप्स लेते हैं), UI और UX विवरण (लेआउट, स्पेसिंग, इंटरैक्शन व्यवहार), बिज़नेस रूल्स (प्राइसिंग, परमिशन्स, वेलिडेशन), डेटा व्यवहार (क्या स्टोर होता है और कब), और इंटीग्रेशन (analytics इवेंट्स, ईमेल, पेमेंट्स, बाहरी APIs) को शामिल करता है।
यह “बदलें नहीं” प्रॉम्प्ट पैटर्न जोखिम कम करता है क्योंकि यह अंदाज़बाज़ी हटाकर बदलाव को सीमित रखता है। यह गारंटी नहीं है। अगर मूल व्यवहार कमजोर तरीके से परिभाषित है, अगर बदलाव साझा कॉम्पोनेंट्स को छूता है, या अगर आप परिणाम सत्यापित नहीं करते, तब भी ड्रिफ्ट हो सकता है। लक्ष्य कम आश्चर्य और तेज़ अनुमोदन है।
बदलें नहीं प्रॉम्प्ट पैटर्न एक साधारण तरीका है जिससे आप एक विशिष्ट अपडेट मांगते हैं और बाकी सब कुछ स्पष्ट रूप से लॉक कर देते हैं। आप उस एक बदलाव को नाम देते हैं जो आप चाहते हैं, फिर आप एक छोटी फ्रीज़ सूची लिखते हैं उन हिस्सों की जो अपडेट के बाद बिल्कुल समान बने रहने चाहिए।
यह महत्वपूर्ण है क्योंकि मॉडल अक्सर सहायक बनने की कोशिश में कोड को रिफैक्टर, रीनेम, फ़ाइलों को पुनर्गठित या लॉजिक “क्लीनअप” कर देते हैं जबकि वे कोड छूते हैं। भले ही आउटपुट अभी भी काम करे, ये अतिरिक्त बदलाव बग ला सकते हैं, व्यवहार बदल सकते हैं, या रिव्यू को कठिन बना सकते हैं।
इन दो अनुरोधों की तुलना कीजिए:
“Make the settings page better.” यह डिजाइन बदलाव, नई कॉपी, लेआउट शिफ्ट्स, और लॉजिक ट्वीक को आमंत्रित करता है।
“Change only the label text from ‘Phone’ to ‘Mobile phone’. Do not change layout, validation, or the save behavior.” यह संकुचित, टेस्टेबल और सुरक्षित है।
एक ठोस फ्रीज़ सूची आम तौर पर तीन क्षेत्रों को कवर करती है:
जब आप इस पैटर्न का उपयोग किसी चैट-आधारित बिल्ड टूल जैसे Koder.ai में करते हैं, तो इटरेशन्स तेज़ होते हैं क्योंकि मॉडल एकल एडिट पर फोकस करता है बजाय इसके कि वह व्यापक “सुधार” करे जो आपने नहीं मांगे।
यह पैटर्न सबसे अच्छा तब काम करता है जब आपका अनुरोध एक छोटे कॉन्ट्रैक्ट की तरह पढ़े: एक स्पष्ट लक्ष्य, एक फ्रीज़ सूची जो बताए कि क्या समान रहना चाहिए, और कुछ चेक्स परिणाम की पुष्टि के लिए।
यह टेम्पलेट कॉपी करके ब्रैकेट में भरें। संक्षिप्त रखें, पर विशिष्ट।
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -> checkout -> receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
एक ठोस उदाहरण: अगर आप चेकआउट बटन का रंग बदलना चाहते हैं, तो आपका लक्ष्य होगा “Update the primary checkout button color to #1A73E8.” आपकी DO NOT CHANGE आइटम्स को पूरा चेकआउट फ्लो, बटन टेक्स्ट, और प्राइसिंग कैलकुलेशन को फ्रीज़ करना चाहिए।
अगर आप Koder.ai का उपयोग कर रहे हैं, यह फॉर्मेट रिव्यूज़ को तेज़ बनाता है क्योंकि आप स्वीकार्यता चेक्स की तुलना प्रीव्यू और चेंज समरी से कर सकते हैं इससे पहले कि आप कुछ भी अप्रूव करें।
जब आप एक छोटा बदलाव मांगते हैं, तो सिर्फ यह न कहें “किसी भी चीज़ को मत तोड़ो।” उनके बजाय उन सटीक उपयोगकर्ता यात्राओं का नाम लें जो समान व्यवहार करनी चाहिए, पहली क्लिक से अंतिम परिणाम तक। आप पूरी ऐप को फ्रीज़ नहीं कर रहे हैं; आप उन हिस्सों को फ्रीज़ कर रहे हैं जिनमें रिग्रेशन से नुकसान होता है।
शुरू करें क्रिटिकल फ्लोज़ को सादा भाषा में सूचीबद्ध करके: लॉगिन (पासवर्ड रिसेट सहित), ऑनबोर्डिंग, चेकआउट, सेटिंग्स। हर फ्लो के लिए बताइए कि “डन” कैसा दिखता है। उदाहरण: “यूज़र ईमेल + पासवर्ड से लॉगिन कर सकता है, Dashboard पर पहुंचता है, और रिफ्रेश के बाद साइन इन बना रहता है।”
फिर उन एज-केसेस को लॉक करें जिन्हें लोग भूल जाते हैं। बैक बटन व्यवहार ड्रिफ्ट का क्लासिक स्रोत है: “Back from Checkout returns to Cart (not Home), and cart items remain.” त्रुटि अवस्थाएँ कॉल आउट करें (“गलत पासवर्ड वही संदेश दिखाता है”), खाली अवस्थाएँ (“कोई प्रोजेक्ट नहीं दिखने पर वही empty screen copy दिखे”), और लोडिंग अवस्थाएँ (“200ms के अंदर स्पिनर दिखाई दे, कोई लेआउट जंप न हो”)।
यदि प्रदर्शन और सुरक्षा अपेक्षाएँ मायने रखती हैं, तो उन्हें भी फ्रीज़ करें। यदि आप उनका उल्लेख नहीं करते, मॉडल “सुधार” करते हुए अतिरिक्त रिक्वेस्ट, नया लॉगिंग, या ऑथ चेक जोड़ सकता है।
संक्षेप में एक सख्त तरीका:
डेटा फ्लो के बारे में एक वाक्य प्रति आइटम में विशिष्ट हों। उदाहरण: “Address केवल Save दबाने पर सेव होता है, user profile record में स्टोर होता है, और logout/login के बाद भी बरकरार रहना चाहिए।” इस स्तर का विवरण स्वत:सेव, नए फील्ड, या टाइमिंग परिवर्तन रोकता है जो असली उपयोगकर्ताओं को तोड़ सकते हैं।
UI ड्रिफ्ट अक्सर इसलिए होता है क्योंकि मॉडल “सहायता” के नाम पर स्टाइल्स, स्पेसिंग, या कॉम्पोनेंट स्ट्रक्चर क्लीनअप कर देता है। इसका उपाय वही है जो बिज़नेस लॉजिक के साथ किया जाता है: बताइए क्या बिल्कुल समान रहना चाहिए, और सिर्फ एक चीज़ बताइए जिसे बदलने की अनुमति है।
दृश्यमान संरचना पिन करें। लेआउट (कॉलम/रो, हेडर और फुटर की जगह), स्पेसिंग नियम (padding, gaps, alignment), और कॉम्पोनेंट व्यवहार (hover, disabled state, loading spinners, error messages) को कॉल आउट करें। यदि किसी कॉम्पोनेंट का एक खास महसूस है, तो उसे साफ़ कहें: “Button size, radius, and color must stay exactly the same.”
रेस्पॉन्सिव व्यवहार के लिए स्पष्ट नियम दें। अगर आप मोबाइल का उल्लेख नहीं करते, टूल्स इसे “बेहतर” बना सकते हैं। बताइए किन ब्रेकपॉइंट्स की परवाह है और प्रत्येक पर क्या होना चाहिए: stacking order, hidden elements, fixed bars, और tap targets।
शब्दों को भी फ्रीज़ करें। मॉडल को कहें कि सभी कॉपी, लेबल, प्लेसहोल्डर, और हेल्पर टेक्स्ट वही रहने चाहिए, सिवाय उस एक लेबल के जिसे आप बदल रहे हैं। यह चुपचाप पुनर्लेखन को रोकता है जो अर्थ बदल सकता है।
एक संक्षिप्त प्रॉम्प्ट आप बदलने के अनुरोध में पेस्ट कर सकते हैं:
यदि संभव हो, before/after स्क्रीनशॉट्स माँगें। अगर स्क्रीनशॉट उपलब्ध नहीं हैं, तो एक छोटा “UI diff” वर्णन माँगें (क्या हिला, क्या रिसाइज़ हुआ, क्या रंग बदला) ताकि आप विश्वास के साथ अप्रूव कर सकें।
बिज़नेस रूल्स एक छोटा UI बदलाव चुपचाप रिग्रेशन पैदा कर सकता है। एक लेबल अपडेट गलत तरीके से गणना बदल सकता है, स्टेट ट्रांज़िशन बदल सकता है, या यह निर्धारित कर सकता है कि कौन रिकॉर्ड देख सकता है। नियमों और डेटा व्यवहार को फ्रीज़ कॉन्ट्रैक्ट की तरह मानें।
शुरू करें उन कुछ नियमों को नाम देकर जिनके डिफ्ट होने से सबसे ज्यादा नुकसान होगा। उन्हें टेस्ट की तरह लिखें: इनपुट्स, आउटपुट्स, और कौन क्या कर सकता है।
“प्राइसिंग को उसी तरह रखें” कहने के बजाय उसे पिन कर दें:
संवाद में एक न्यूमेरिक उदहारण जोड़ें ताकि इंटरप्रेटेशन न रहे। उदाहरण: “Order subtotal $120, discount 10% (applies before tax), tax 8.25% on discounted amount. Expected total = (120 - 12) * 1.0825 = $116.91. Rounding to 2 decimals only at the final total.”
रोल-आधारित विजिबिलिटी को भी कॉल आउट करें, सिर्फ एक्शन्स ही नहीं। उदाहरण: “Support agents ऑर्डर स्टेटस और कस्टमर ईमेल देख सकते हैं, पर पूरी कार्ड डिटेल्स नहीं देखनी चाहिए। केवल admins ही रिफंड कर सकते हैं।”
यदि वेलिडेशन मायने रखती है, तो उन्हें स्पष्ट रूप से फ्रीज़ करें। सटीक ट्रिगर और यूज़र-फेसिंग संदेश उल्लेख करें: “If start date is after end date, block save and show: ‘End date must be after start date.’ Do not change this wording.”
ऐप के बाहर के साइड-इफेक्ट्स को न भूलें। अगर आप ईमेल, वेबहुक, या थर्ड-पार्टी APIs कॉल करते हैं, तो फ्रीज़ करें कि क्या समान रहना चाहिए: इवेंट नाम, पेलोड फील्ड्स, टाइमिंग (इमीडिएट बनाम डिले), और idempotency व्यवहार (रिट्राई पर डुप्लिकेट भेजा न जाए)।
एक छोटे अपडेट को एक मिनी कॉन्ट्रैक्ट की तरह ट्रीट करें। पैटर्न सबसे अच्छा तब काम करता है जब बदलाव संकुचित हो और बाकी सब कुछ स्पष्ट रूप से फ्रीज़ हो।
परिवर्तन को एक टेस्टेबल वाक्य में लिखें। “On the settings page, add a toggle to enable dark mode” टेस्टेबल है। “Improve the settings UI” नहीं है। अगर आप 30 सेकंड में टेस्ट नहीं कर सकते, तो यह अभी भी बहुत व्यापक है।
उन हिस्सों के लिए एक फ्रीज़ सूची लिखें जिनमें डिफ्ट होने से नुकसान होगा: यूज़र फ्लो, प्रमुख UI एलिमेंट्स, बिज़नेस रूल्स, डेटा व्यवहार, और कोई APIs या DB टेबल जिन्हें वही रहना चाहिए।
स्वीकार्यता चेक्स और एक छोटा टेस्ट प्लान जोड़ें। यह वह जगह है जहाँ आप “it works on my side” के सरप्राइज़ रोकते हैं। चेक्स में शामिल करें: नया टॉगल दिखाई देता है, मौजूदा सेटिंग्स अभी भी सेव होती हैं, और पेज पर कुछ नहीं हिलता।
किसी भी एडिट से पहले असिस्टेंट से कहें कि वह आपकी सीमाओं को दोहराए। उसे पुष्टि करनी चाहिए कि क्या बदलेगा और क्या समान रहेगा। अगर समरी गलत है, तो बदलाव की अनुमति देने से पहले प्रॉम्प्ट को सुधारें।
सबसे छोटा संभव इम्प्लीमेंटेशन माँगें: कोई रिफैक्टर नहीं, कोई रीनेमिंग नहीं, कोई फ़ॉर्मैटिंग पास नहीं, कोई डिपेंडेंसी अपडेट नहीं। आप एक बदलाव खरीद रहे हैं, पूरा मेकओवर नहीं।
एक छोटा रिव्यू चेकलिस्ट:
यह Koder.ai में विशेष रूप से अच्छा काम करता है: फ्रीज़ सूची को Planning Mode में पेस्ट करें, उसे कन्स्ट्रेंट्स echo करने दें, फिर सबसे छोटा पैच जनरेट करें।
अधिकांश “छोटे” संपादन उसी कारण से गलत होते हैं: अनुरोध लक्ष्य की रक्षा करता है, पर व्यवहार की नहीं। एक मॉडल आपके लक्ष्य को एक नए तरीके से पूरा कर सकता है जो चुपचाप स्क्रीन, लॉजिक, या डेटा बदल दे।
एक आम जाल है परिणाम को फ्रीज़ करना (“onboarding को आसान बनाओ”) बजाय सटीक क्लिक-बाय-क्लिक फ्लो और अपेक्षित नतीजों को फ्रीज़ करने के। एक और है “सब कुछ समान रखें” लिखना और यह मान लेना कि सिस्टम जानता है इसका क्या मतलब है।
सबसे अक्सर होने वाली गलतियाँ:
एक छोटा उदाहरण: आप कहते हैं “बटन ज़्यादा दिखने वाला बनाओ” और रंग फ्रीज़ कर देते हैं, पर डिसेबल्ड स्टेट फ्रीज़ करना भूल जाते हैं। अपडेट ऐसा हो सकता है कि बटन हमेशा एनेबल रहे, जिससे व्यवहार बदल जाए और आप बाद में ही नोटिस करें।
क्या मदद करता है: जो नहीं बदलना चाहिए उसे जितना संभव हो उतना विशिष्ट बनाएं। स्वीकार करने से पहले एक त्वरित रिग्रेशन पास करें:
अगर इनमें से कोई भी अलग है, तो अनुरोध में एक फ्रीज़ डिटेल मिसिंग था—यह “खराब कोडिंग” नहीं है।
एक आम सुरक्षित इटरेशन छोटा UI पोलिश होता है जहाँ वर्कफ़्लो नहीं बदलना चाहिए।
परिदृश्य: एक संस्थापक के पास एक साधारण साइनअप स्क्रीन है जिसमें छोटा फॉर्म है (Name, Email, Company size) और एक प्राथमिक बटन जो फॉर्म सबमिट करता है और फिर उपयोगकर्ताओं को Dashboard पर ले जाता है।
सटीक परिवर्तन अनुरोध (एक वाक्य): “Rename the primary button from 'Create account' to 'Continue' and change the 'Company size' field from a free-text input to a dropdown.”
अब पैटर्न लागू करें और फ्रीज़ करें जो समान रहना चाहिए:
स्वीकृति चेक्स जिन्हें आप मिनटों में चला सकते हैं:
एक अच्छे असिस्टेंट का उत्तर फ्रीज़ किए गए आइटमों को दोहराना चाहिए, किसी भी अस्पष्टता (जैसे dropdown विकल्प और कौन सा मूल्य स्टोर होगा) की पुष्टि करनी चाहिए, और फिर केवल न्यूनतम कोड/UI बदलाव करना चाहिए। उसे यह भी बताना चाहिए कि उसने जानबूझकर क्या नहीं छुआ (रूटिंग, वैलिडेशन लॉजिक, पेलोड शेप)।
“छोटे बदलाव” स्वीकार करने से पहले एक तेज़ पास करें जो चुपचाप ड्रिफ्ट को खोजे। लक्ष्य पूरा QA नहीं है। यह पुष्टि करना है कि आपकी “बदलो मत” कही गई जगहों पर ऐप वही व्यवहार कर रहा है सिवाय उस एक बदलाव के।
इन्हें हर बार एक ही क्रम में चलाएँ। यह रिव्यू को शांत बनाता है और रिग्रेशन को ढूँढना आसान बनाता है।
अगर कोई भी फ्रीज़ आइटम बदला है तो रिवर्ट कर दें, भले ही ऐप “काम कर रहा हो।” बदला हुआ लेबल, नया फील्ड, या थोड़ा अलग नियम संकेत है कि मॉडल ने अतिरिक्त स्वतंत्रता ली।
फिर से अनुरोध जारी करें और सीमाएँ और कसी हुई बनाएं: अकेले एक वाक्य में एकल परिवर्तन दोहराएँ, फ्रीज़ किए गए फ्लोज़ और स्क्रीन को नाम दें, और जोड़ें “no schema changes, no endpoint changes, no behavior changes outside X.” अगर आप Koder.ai उपयोग कर रहे हैं, बदलाव से पहले स्नैपशॉट लेना रोलबैक को एक-स्टेप कर देता है अगर कुछ ड्रिफ्ट हो।
यदि आप Koder.ai में बिल्ड कर रहे हैं, तो बदलाव-न-करें प्रॉम्प्ट पैटर्न आदत बनाते हुए सबसे अच्छा काम करता है: एक छोटा बदलाव, बाकी सब लॉक, और अगर कुछ ड्रिफ्ट हो तो साफ़ वापसी का तरीका।
बदलाव मांगने से पहले Planning Mode में स्विच करें और असिस्टेंट से कहें कि वह आपकी स्कोप को सरल शब्दों में दोहराए। उससे दो बातें दोहराने को कहें: (1) सटीक परिवर्तन, और (2) एक स्पष्ट फ्रीज़ सूची (फ्लोज़, UI विवरण, और बिज़नेस रूल्स जो नहीं बदलने चाहिए)।
एक अच्छा प्लानिंग प्रॉम्प्ट: “Restate my request. Then list what must not change. If anything is unclear, ask questions before editing.”
हर परिवर्तन अनुरोध को एक चेकपॉइंट की तरह मानें। अपडेट लागू करने से पहले एक स्नैपशॉट बनाएं, फिर सत्यापन के बाद दूसरा स्नैपशॉट। अगर कुछ टूटता है, तो रोलबैक नए बदलाव को पैच करने से तेज़ है।
उदाहरण वर्कफ़्लो:
Koder.ai वेब (React), बैकएंड (Go + PostgreSQL), और मोबाइल (Flutter) जनरेट कर सकता है। पैटर्न उसी तरह काम करता है भले ही कोड अलग हो। वे हिस्से फ्रीज़ करें जो व्यवहार को परिभाषित करते हैं, न कि सिर्फ फाइल नाम।
अगर आप एक बैकएंड एंडपॉइंट बदल रहे हैं, तो request/response shape, validation rules, और data writes फ्रीज़ करें। यदि आप मोबाइल स्क्रीन बदल रहे हैं, तो navigation order, field defaults, और error messages फ्रीज़ करें। यदि आप DB लॉजिक बदल रहे हैं, तो मौजूदा रोज़ के अर्थ को फ्रीज़ करें और माईग्रेशन्स सुरक्षित रखें।
अपना टेम्पलेट कॉपी करें, आज एक छोटा बदलाव चलाएँ, और चेकलिस्ट से सत्यापित करने के बाद ही अपडेट स्वीकार करें। हर बार एक ही टेम्पलेट रखें और अगला परिवर्तन उसी पैटर्न से करें।
Use it whenever you want one specific change and you care that everything else stays the same. It’s especially useful for checkout, auth, billing, or any flow where small drift creates real user issues.
Because parts of an app share components, data, and rules. A tiny UI edit can touch a reused component, which can shift layouts elsewhere, alter validation, or change API payloads without you noticing until later.
Write one clear goal, then list what must remain identical after the change. The key is to freeze behavior (flows, rules, data, integrations) and visible UI details, not just say “don’t break anything.”
Keep it short but specific: critical flows, UI/UX details that must not move, business rules, data behavior, and integrations. If you can’t name what must stay the same, the model has to guess, and guessing causes drift.
Scope it to the smallest area that still protects you. For example, freeze the checkout flow and its shared components, but don’t freeze the entire app if you’re only changing a label on one screen.
Name the journeys step-by-step and define what “done” looks like. Add the common edge cases like back button behavior, error messages, empty states, and refresh behavior so the flow stays identical in the places users notice most.
Explicitly freeze layout structure, spacing, component states (hover/disabled/loading), and all copy except the one string you’re changing. Without that, models may “clean up” styles or rewrite text in ways that change meaning or layout.
Freeze contracts: request/response shapes, validation rules, permissions, calculations, and what gets stored and when. Add one numeric example for sensitive rules like pricing so there’s no interpretation during implementation.
Ask for acceptance checks you can run fast, plus a brief diff-style summary of what changed and where. Then verify the frozen flows end-to-end, trigger at least one error state, and confirm data/integrations didn’t change.
Take a snapshot before the change, run a planning pass that repeats the scope and freeze list, then apply the smallest patch. After verifying, snapshot again so rollback is one step if anything drifted.