बदलाव की समीक्षा करना

OpenSpec का पूरा वादा यह है कि आप और आपका AI कोई भी कोड लिखने से पहले क्या बनाना है, इस पर सहमत हो जाएं। यह सहमति तभी किसी काम की है जब आप वास्तव में AI द्वारा तैयार किए गए दस्तावेज को पढ़ें। यह पेज उन दो मिनट के बारे में है जब आप यह करते हैं — क्या खोलना है, किस क्रम में, और क्या देखना है।

शर्त बहुत सरल है: एक पैराग्राफ की योजना में किसी गलत मोड़ को पकड़ना लगभग मुफ्त है। 300 लाइनों के कोड में उसी गलत मोड़ को पकड़ना ऐसा नहीं है। समीक्षा वह जगह है जहां आप इस शर्त पर जीतते हैं।

समीक्षा के दो क्षण

वे बिल्कुल दो हैं:

/opsx:propose ──► REVIEW THE PLAN ──► /opsx:apply ──► REVIEW THE CODE ──► /opsx:archive
                  (before any code)                    (/opsx:verify)

1. /opsx:propose के बाद (या /opsx:ff), /opsx:apply से पहले — जब योजना अभी बस शब्दों में हो, उसे पढ़ें।
2. निर्माण के बाद, /opsx:verify के साथ — जांचें कि कोड ने वास्तव में योजना में लिखा हुआ काम किया है या नहीं।

पहली समीक्षा वह है जो आपको सबसे ज्यादा बचाती है, और जिसे लोग अक्सर छोड़ देते हैं। यह पेज उस पर ज्यादा समय बिताता है।

इस क्रम में पढ़ें

एक बदलाव openspec/changes/<name>/ फोल्डर में सादे मार्कडाउन फाइलों का समूह है। उन फाइलों को उस क्रम में पढ़ें जिससे आप यदि कुछ गलत हो तो जल्दी से बाहर निकल सकें:

openspec/changes/add-dark-mode/
├── proposal.md      1. the intent and scope   ← if this is wrong, stop here
├── specs/…/spec.md  2. the requirements       ← the heart of the review
├── design.md        (only for bigger changes) — the technical approach
└── tasks.md         3. the plan of work

आपको हर लाइन पढ़ने की जरूरत नहीं है। आपको एक फाइल के लिए एक-एक सवाल का जवाब देना है, कुल तीन सवाल हैं।

प्रस्ताव: क्या यह सही समस्या है?

सबसे पहले proposal.md खोलें। यह "क्यों" और "क्या" को कैप्चर करता है — इरादा, स्कोप, एक या दो पैराग्राफ में तकनीकी दृष्टिकोण।

अच्छा क्या दिखता है: एक स्पष्ट इरादा, एक स्कोप जिसे आप पहचानें, और एक कारण कि यह अभी करने लायक क्यों है।

चेतावनी के संकेत:

• यह आपके द्वारा पूछे गए समस्या से थोड़ा अलग समस्या हल करता है।
• स्कोप बढ़ गया है — आपने थीम टॉगल मांगा था और प्रस्ताव में ऑथ को भी 'जब हम वहां हैं' के नाम पर छूता है।
• यह अस्पष्ट है। "सेटिंग पेज को सुधारें" कोई स्कोप नहीं है; "ऑपरेटिंग सिस्टम की प्राथमिकता का सम्मान करते हुए डार्क मोड टॉगल जोड़ें" एक स्कोप है।

जवाब देना है यह सवाल: क्या यह मेरे द्वारा वास्तव में पूछे गए बारे में मेल खाता है, और क्या कुछ छिपकर अंदर आ रहा है? यदि जवाब नहीं है, तो रुकें — आगे न पढ़ें, प्रस्ताव को ठीक करें (देखें पीछे धकेलना सस्ता है)।

स्पेक डेल्टा: क्या "पूर्ण" की परिभाषा सही है?

यह समीक्षा का हृदय है। specs/ के नीचे के डेल्टा स्पेक बताते हैं कि जब बदलाव शिप होगा तब क्या सत्य होगा — जरूरतें और उन्हें सिद्ध करने वाले परिदृश्य के रूप में:

## ADDED Requirements

### Requirement: Dark Mode Toggle
The system SHALL let a user switch between light and dark themes.

#### Scenario: Respects the OS preference on first load
- GIVEN a user who has never set a theme
- WHEN they open the app on a device set to dark mode
- THEN the app renders in dark mode

अच्छी जरूरत कैसी दिखती है: एक स्पष्ट SHALL/MUST कथन जिसे आप कोई टेस्टर को सौंप सकें, और कम से कम एक परिदृश्य जिसका GIVEN/WHEN/THEN वास्तव में उस कथन को टेस्ट करता हो।

चेतावनी के संकेत:

• एक अस्पष्ट जरूरत। "सिस्टम SHALL तेज हो" निर्मित या टेस्ट नहीं किया जा सकता। तेज क्या है?
• कोई परिदृश्य नहीं वाली जरूरत, या एक परिदृश्य जो उस जरूरत को टेस्ट नहीं करता जिसके नीचे वह है।
• सबसे मूल्यवान पकड़: जो कुछ गुम है। AI वास्तव में आपके कहे गए को ईमानदारी से लिखता है। आपका काम यह देखना है कि आपने क्या भूलकर कहा है। यदि आपको सबसे ज्यादा ऑपरेटिंग सिस्टम की प्राथमिकता के मामले की परवाह है और कोई परिदृश्य इसका उल्लेख नहीं करता है, तो यह समीक्षा ही अपना खर्च वापस ले रही है।

डेल्टा को पढ़ते समय यह सवाल पूछें क्या मैं खुश रहूंगा यदि सिस्टम बिल्कुल — और केवल — यही करता है? यहां अभी कोड की बात नहीं है, इसलिए इसे बदलना सस्ता ही रहेगा।

कार्य: क्या काम का योजना सही है?

आखिर में tasks.md खोलें। यह कार्यान्वयन चेकलिस्ट है जिससे AI काम करेगा।

अच्छा क्या दिखता है: क्रमबद्ध चरण, प्रत्येक जरूरत से ट्रेस करने योग्य, कोई रहस्यमय बात नहीं।

चेतावनी के संकेत:

• कोई मिलती-जुलती जरूरत नहीं वाला कार्य (यह कहां से आया?)।
• एक बड़ा "फीचर को लागू करें" कार्य जो सभी वास्तविक निर्णयों को छुपाता है।
• एक कार्य जो आपने अभी मंजूर की स्कोप से बाहर की किसी चीज को छूता है।

आप यहां अनुमान लगा रहे नहीं हैं या छोटी-छोटी बातों का प्रबंधन कर रहे नहीं हैं — आप जांच रहे हैं कि योजना उन जरूरतों से मेल खाती है जिन्हें आपने पहले ही स्वीकार कर लिया है।

पीछे धकेलना सस्ता है

यदि तीनों सवालों में से किसी का जवाब गलत आया है, तो ऐसा कहें। कोई फेज नहीं है और कुछ भी लॉक नहीं है — आप इसे ठीक करें और आगे बढ़ें। दो तरीके, बिल्कुल बदलाव संपादित करना में जैसे:

• फाइल को खुद संपादित करें। यह सादा मार्कडाउन है; स्कोप की लाइन बदलें, जरूरत को कठोर करें, कार्य को हटा दें।
• AI को बताएं कि क्या गलत है और उसे संशोधन करने दें: "ऑथ बदलावों को हटा दें — स्कोप से बाहर है," "जब उपयोगकर्ता पहले ही थीम चुन लेता है, उसके लिए एक परिदृश्य जोड़ें," "कार्य 3 को स्कीमा और UI में अलग करें।"

फिर बदले हुए हिस्से को फिर से पढ़ें। तब तक फिर से ड्राफ्ट करें जब तक यह एक ऐसी योजना न हो जाए जिस पर आप अपना हस्ताक्षर करने के लिए तैयार हों। यह आगे-पीछे की बातचीत ही उत्पाद काम कर रहा है।

कोड के बाद: सत्यापन करें

एक बार काम निर्मित हो जाने के बाद, /opsx:verify आपकी दूसरी समीक्षा है। यह आर्टिफैक्ट्स और कोड को फिर से पढ़ता है और तीन आयामों में बेमेलियों की रिपोर्ट करता है:

आयाम	यह क्या जांचता है
पूर्णता	हर कार्य पूरा हुआ, हर जरूरत लागू की गई, सभी परिदृश्यों का समावेश
सटीकता	कार्यान्वयन स्पेक के इरादे से मेल खाता है, किनारे के मामलों का समाधान किया गया है
संगतता	डिजाइन निर्णय वास्तव में कोड में दिखाई देते हैं

You: /opsx:verify

AI:  Verifying add-dark-mode...

     COMPLETENESS
     ✓ All 8 tasks in tasks.md are checked
     ✓ All requirements in specs have corresponding code
     ⚠ Scenario "Respects the OS preference on first load" has no test coverage

यह मुद्दों को CRITICAL, WARNING, या SUGGESTION के रूप में फ्लैग करता है, और यह आर्काइविंग को ब्लॉक नहीं करता — यह खाली जगहों को सामने लाता है और निर्णय आप पर छोड़ता है। यह "क्या AI ने कोड लिखा" और "क्या उसने हमारी सहमति के अनुसार बनाया" के बीच का अंतर है।

/opsx:verify विस्तारित प्रोफाइल में है। यदि आपके पास यह नहीं है, तो openspec config profile से इसे चालू करें (फिर openspec update चलाएं), या बस बदलाव और डिफ को खुद फिर से पढ़ लें।

समीक्षा को सही आकार दें

हर बदलाव पूरा पास नहीं करता है। एक फाइल में टाइपो फिक्स को बीस सेकंड का स्किम करना काफी है। जो बदलाव ऑथ, भुगतान या उस डेटा को छूता है जिसे आप वापस नहीं ले सकते, उसमें ऊपर दिए गए हर सवाल पूछने के लायक है। मुद्दा कभी समारोह नहीं था — यह तो यह है कि जहां एक गलती महंगी हो सकती है, वहां अपना ध्यान दें, और जहां नहीं, वहां स्किम करें।

दो मिनट की चेकलिस्ट

• [ ] प्रस्ताव का इरादा मेरे द्वारा पूछे गए से मेल खाता है।
• [ ] स्कोप में कुछ अतिरिक्त काम छिपकर नहीं आया है।
• [ ] हर जरूरत पर्याप्त रूप से विशिष्ट है कि उसे टेस्ट किया जा सके।
• [ ] हर जरूरत के पास एक परिदृश्य है जो वास्तव में उसे टेस्ट करता है।
• [ ] जिस मामले की मुझे सबसे ज्यादा परवाह है, उसका समावेश हो।
• [ ] कार्य जरूरतों से मैप होते हैं; कोई बात रहस्यमय नहीं है या स्कोप से बाहर नहीं है।
• [ ] यदि AI बिल्कुल यही और कुछ अधिक नहीं बनाता है तो मैं सहज महसूस करूंगा।

यदि सभी सात पॉइंट पास हो जाएं, तो आत्मविश्वास के साथ /opsx:apply चलाएं। यदि कोई फेल हो जाए, तो यह कोई पछतावा नहीं है — यह दो मिनट अपना काम कर रहे हैं।

आगे कहां जाएं

• अच्छे स्पेक लिखना — दूसरी तरफ: मान्य करने लायक जरूरतों और परिदृश्यों को कैसे ड्राफ्ट करें।
• बदलाव संपादित करना और उस पर चक्रण करना — शुरू करने के बाद योजना को बदलने की प्रक्रिया।
• वर्कफ्लो — बड़े लूप में समीक्षा कहां फिट होती है।