Go API स्कैफ़ोल्डिंग के लिए Claude Code: सुसंगत हैंडलर और सर्विस

जब पैटर्न पहले तय नहीं होते तो Go APIs गड़बड़ क्यों हो जाते हैं

Go APIs अक्सर साफ़ शुरू होते हैं: कुछ एंडपॉइंट्स, एक-दो लोग, और सब कुछ सबके सिर में रहता है। फिर API बड़ा होता है, फीचर्स दबाव में शिप होते हैं, और छोटे-छोटे अंतर चुपके से आ जाते हैं। हर एक अलग दिखता है, लेकिन साथ मिलकर ये हर भविष्य के बदलाव को धीमा कर देते हैं।

एक सामान्य उदाहरण: एक हैंडलर JSON को एक struct में डिकोड करता है और सहायक संदेश के साथ 400 लौटाता है, दूसरा 422 के साथ अलग आकार लौटाता है, और तीसरा त्रुटियों को अलग फॉर्मैट में लॉग करता है। इन सब से कंपाइल टूटता नहीं है। बस हर बार कुछ नया जोड़ने पर लगातार निर्णय और छोटे-छोटे राइटराइट्स होने लगते हैं।

आप गड़बड़ी इन जगहों पर महसूस करेंगे:

• अलग-अलग एंडपॉइंट्स पर त्रुटि बॉडीज़, जिससे क्लाइंट्स को विशेष केस लिखने पड़ते हैं।
• सर्विस कभी-कभी कच्चे डेटाबेस एरर लौटाती है और कभी "फ्रेंडली" एरर।
• नामकरण का रिसाव (CreateUser, AddUser, RegisterUser) जिससे सर्च मुश्किल हो जाती है।
• वैलिडेशन इधर-उधर होने से वही बग बार-बार लौट आते हैं।

यहां "Scaffolding" का मतलब नए काम के लिए एक दोहराने योग्य टेम्पलेट है: कोड कहाँ जाएगा, हर लेयर क्या करेगी, और प्रतिक्रियाएँ कैसी दिखेंगी। यह बहुत सारा कोड जनरेट करने के बारे में नहीं है, बल्कि एक सुसंगत रूप तय करने के बारे में है।

Claude जैसे टूल नए एंडपॉइंट्स को तेजी से स्कैफोल्ड कर सकते हैं, लेकिन वे तभी उपयोगी रहते हैं जब आप पैटर्न को एक नियम की तरह मानें। आप नियम तय करते हैं, हर डिफ़ की समीक्षा करते हैं, और टेस्ट चलाते हैं। मॉडल मानक भाग भरता है; उसे आपकी आर्किटेक्चर फिर से परिभाषित नहीं करने दें।

एक लेयर विभाजन चुनें: handler, service, और data access

जब हर रिक्वेस्ट एक ही रास्ता अपनाती है तो Go API बढ़ाना आसान रहता है। नए एंडपॉइंट्स जेनरेट करने से पहले एक लेयर विभाजन चुनें और उस पर टिके रहें।

जिम्मेदारियाँ, सरल रखी गईं

हैंडलर का काम केवल HTTP है: रिक्वेस्ट पढ़ना, सर्विस को कॉल करना, और रिस्पॉन्स लिखना। इसमें बिजनेस नियम, SQL, या "सिर्फ यह एक खास केस" लॉजिक नहीं होना चाहिए।

सर्विस उपयोग केस की जिम्मेदारी रखता है: बिजनेस नियम, निर्णय, और रिपोजिटरीज़ या बाहरी कॉल्स का समन्वय। इसे HTTP चिंताओं जैसे स्टेटस कोड, हेडर्स, या त्रुटियों के कैसे रेंडर होंगे, के बारे में नहीं पता होना चाहिए।

डेटा एक्सेस (repository/store) पर्सिस्टेंस विवरण की जिम्मेदारी रखता है। यह सर्विस की मंशा को SQL/क्वेरीज़/ट्रांज़ैक्शंस में अनुवाद करता है। इसे बेसिक डेटा इंटीग्रिटी से आगे बिजनेस नियम लागू नहीं करना चाहिए, और न ही API प्रतिक्रियाओं को आकार देना चाहिए।

एक पृथक्करण चेकलिस्ट जो व्यावहारिक रहे:

• Handler: इनपुट पार्स करें, सर्विस को कॉल करें, एरर्स को HTTP में मैप करें, JSON लिखें
• Service: बिजनेस नियम लागू करें, रिपोज़ को कॉल करें, डोमेन परिणाम या टाइप्ड एरर्स लौटाएँ
• Data access: क्वेरी चलाएँ, rows को structs में मैप करें, स्टोरेज एरर्स लौटाएँ
• साझा: सामान्य एरर प्रकार और रिस्पॉन्स हेल्पर्स
• कोई लेयर दूसरी को स्किप न करे (हैंडलर कभी सीधे repo को न कॉल करे)

वैलिडेशन के लिए एक नियम

एक नियम चुनें और उसे न मोड़ें।

एक सरल तरीका:

• हैंडलर "shape validation" करें (आवश्यक फ़ील्ड, बुनियादी फ़ॉर्मेट)।
• सर्विस "meaning validation" करे (परमिशन्स, इनवेरिएंट्स, स्थिति)।

उदाहरण: हैंडलर चेक करे कि email मौजूद है और ईमेल जैसा दिखता है। सर्विस चेक करे कि वह ईमेल अनुमति योग्य है और पहले से उपयोग में नहीं है।

लेयर्स के बीच क्या चलता है

आरंभ में यह तय करें कि सर्विस डोमेन टाइप्स लौटाती है या DTOs।

एक साफ़ डिफ़ॉल्ट: हैंडलर request/response DTOs का उपयोग करें, सर्विस डोमेन टाइप्स का उपयोग करे, और हैंडलर डोमेन को रिस्पॉन्स में मैप करे। इससे जब HTTP कॉन्ट्रैक्ट बदले तब भी सर्विस स्थिर रहती है।

यदि मैपिंग भारी लगे, तो भी इसे सुसंगत रखें: सर्विस एक डोमेन टाइप प्लस एक टाइप्ड एरर लौटाए, और JSON शेपिंग हैंडलर में रखें।

एक मानक एरर रिस्पॉन्स और स्टेटस-कोड मैप पर निर्णय लें

अगर आप चाहते हैं कि जेनरेटेड एंडपॉइंट्स वैसे ही लगें जैसे किसी एक ही व्यक्ति ने लिखे हों, तो एरर रिस्पॉन्स को जल्द लॉक कर दें। जेनरेशन तब सबसे अच्छा काम करता है जब आउटपुट फ़ॉर्म नॉन-नेगोशिएबल हो: एक JSON शेप, एक स्टेटस-कोड मैप, और एक नियम कि क्या एक्सपोज़ होगा।

एक सिंगल एरर एनवेलप से शुरू करें जिसे हर एंडपॉइंट विफलता पर लौटाएगा। इसे छोटा और पूर्वानुमेय रखें:

{
  "code": "validation_failed",
  "message": "One or more fields are invalid.",
  "details": {
    "fields": {
      "email": "must be a valid email address",
      "age": "must be greater than 0"
    }
  },
  "request_id": "req_01HR..."
}

code मशीनों के लिए रखें (स्थिर और पूर्वानुमेय) और message इंसानों के लिए (संक्षिप्त और सुरक्षित)। वैकल्पिक संरचित डेटा details में रखें। वैलिडेशन के लिए, एक सरल details.fields मैप जेनरेट करना और क्लाइंट्स के लिए इनपुट के बगल में दिखाना आसान है।

फिर, एक स्टेटस-कोड मैप लिखकर उस पर लगे रहें। जितना कम बहस हर एंडपॉइंट पर होगा, उतना बेहतर। अगर आप 400 और 422 दोनों चाहते हैं, तो विभाजन स्पष्ट रखें:

• bad_json -> 400 Bad Request (malformed JSON)
• validation_failed -> 422 Unprocessable Content (well-formed JSON, invalid fields)
• not_found -> 404 Not Found
• conflict -> 409 Conflict (duplicate key, version mismatch)
• unauthorized -> 401 Unauthorized
• forbidden -> 403 Forbidden
• internal -> 500 Internal Server Error

निर्धारित करें कि आप क्या लॉग करते हैं और क्या रिटर्न करते हैं। एक अच्छा नियम: क्लाइंट्स को सुरक्षित संदेश और एक request ID मिले; लॉग में पूरा एरर और आंतरिक संदर्भ (SQL, अपस्ट्रीम पेलोड्स, यूज़र IDs) रखें जो आप कभी लीक नहीं करना चाहेंगे।

अंत में, request_id को मानकीकृत करें। अगर इनकमिंग ID हेडर मौजूद है (API गेटवे से), तो उसे स्वीकार करें; अन्यथा एज पर (middleware) एक जेनरेट करें। इसे context से जोड़ें, लॉग्स में शामिल करें, और हर एरर रिस्पॉन्स में लौटाएँ।

फोल्डर लेआउट और नामकरण जो जनरेशन को पूर्वानुमेय बनाए

अगर आप चाहते हैं कि स्कैफोल्डिंग सुसंगत रहे, तो आपका फोल्डर लेआउट उबाऊ और दोहराने योग्य होना चाहिए। जनरेटर उन्हीं पैटर्न्स का पालन कर सकते हैं जो दिखते हैं, पर जब फ़ाइलें बिखरी हों या नाम हर फीचर के साथ बदलें तो drift आ जाता है।

एक नामकरण सम्मेलन चुनें और न मोड़ें। हर चीज़ के लिए एक शब्द चुनें और उसे रखें: handler, service, repo, request, response। अगर रूट POST /users है, तो फ़ाइलों और टाइप्स का नाम users और create के आसपास रखें (न कि कभी register, कभी addUser)।

एक सरल लेआउट जो सामान्य लेयर्स से मेल खाता है:

internal/
  httpapi/
    handlers/
    users_handler.go
  services/
    users_service.go
  data/
    users_repo.go
  apitypes/
    users_types.go

निर्धारित करें कि साझा प्रकार कहाँ रहते हैं, क्योंकि यही वह जगह है जहाँ प्रोजेक्ट अक्सर गड़बड़ हो जाते हैं। एक उपयोगी नियम:

• API request/response प्रकार internal/apitypes में रहें (JSON और वैलिडेशन आवश्यकताओं से मेल खाएं)।
• डोमेन प्रकार सर्विस लेयर के नज़दीक रहें (बिजनेस नियम से मेल खाएं)।

अगर किसी प्रकार में JSON टैग्स हैं और वह क्लाइंट्स के लिए डिज़ाइन किया गया है, तो उसे API प्रकार के रूप में देखें।

हैंडलर निर्भरताओं को न्यूनतम रखें और उस नियम को स्पष्ट बनाएं:

• Handlers केवल import करें: routing/http, context, apitypes, और services
• Services import करें: domain types और data access
• Data access import करे: डेटाबेस ड्राइवर और क्वेरी हेल्पर्स
• कोई भी हैंडलर सीधे डेटाबेस पैकेज को इम्पोर्ट न करे

रेपो रूट में एक छोटा पैटर्न डॉक लिखें (सादा Markdown ठीक है)। फ़ोल्डर ट्री, नामकरण नियम, और एक छोटा उदाहरण फ्लो (handler -> service -> repo, और हर पीस किस फ़ाइल में है) शामिल करें। यही सटीक संदर्भ आप अपने जनरेटर में पेस्ट करते हैं ताकि नए एंडपॉइंट हर बार उसी संरचना से मिलें।

एक संदर्भ एंडपॉइंट बनाएं जो पैटर्न सेट कर दे

दस एंडपॉइंट जेनरेट करने से पहले एक एंडपॉइंट बनाएं जिस पर आप भरोसा करते हैं। यह गोल्ड स्टैंडर्ड है: वह फ़ाइल जिसे आप दिखाकर कह सकें, "नया कोड ऐसा ही दिखना चाहिए।" आप इसे scratch से लिख सकते हैं या किसी मौजूदा को पुनर्गठित कर सकते हैं जब तक वह मैच न करे।

हैंडलर को पतला रखें। एक चाल जो बहुत मदद करती है: हैंडलर और सर्विस के बीच एक interface रखें ताकि हैंडलर किसी कॉन्ट्रैक्ट पर निर्भर हो, न कि एक कंक्रीट struct पर।

संदर्भ एंडपॉइंट में केवल उन जगहों पर छोटे कमेंट्स जोड़ें जहाँ भविष्य में जनरेट किया गया कोड अटक सकता है। निर्णय समझाएँ (क्यों 400 बनाम 422, क्यों create 201 लौटाता है, क्यों आप आंतरिक त्रुटियों को एक सामान्य संदेश के पीछे छिपाते हैं)। ऐसे कमेंट्स छोड़ें जो केवल कोड दोहराते हों।

एक बार संदर्भ एंडपॉइंट काम करने लगे, तो हेल्पर्स निकालें ताकि हर नया एंडपॉइंट के पास ड्रिफ्ट की कम चीज़ें रहें। सबसे पुन: उपयोग योग्य हेल्पर्स अक्सर होते हैं:

• JSON बाइंड करना और malformed बॉडी हैंडल करना
• इनपुट वैलिडेट करना और फ़ील्ड एरर लौटाना
• JSON रिस्पॉन्स को सुसंगत तरीके से लिखना
• डोमेन एरर्स को HTTP स्टेटस कोड में मैप करना

यहाँ "पतला हैंडलर + interface" व्यवहार में कैसा दिख सकता है:

type UserService interface {
	CreateUser(ctx context.Context, in CreateUserInput) (User, error)
}

func (h *Handler) CreateUser(w http.ResponseWriter, r *http.Request) {
	var in CreateUserRequest
	if err := BindJSON(r, &in); err != nil {
		WriteError(w, ErrBadJSON) // 400: malformed JSON
		return
	}
	if err := Validate(in); err != nil {
		WriteError(w, err) // 422: validation details
		return
	}
	user, err := h.svc.CreateUser(r.Context(), in.ToInput())
	if err != nil {
		WriteError(w, err)
		return
	}
	WriteJSON(w, http.StatusCreated, user)
}

इसे कुछ टेस्ट्स के साथ लॉक कर दें (भले ही सिर्फ एरर मैपिंग के लिए एक छोटा टेबल टेस्ट हो)। जेनरेशन सबसे अच्छा तब काम करता है जब उसके पास नकल करने के लिए एक साफ़ लक्ष्य हो।

कदम‑दर‑कदम: Claude से एक नया एंडपॉइंट बनवाएँ जो मेल खाए

सुसंगतता उसी चीज़ से शुरू होती है जो आप पेस्ट करते हैं और क्या आप मना करते हैं। नए एंडपॉइंट के लिए, दो चीजें दें:

1. आपका रेफ़रेंस एंडपॉइंट ("परफेक्ट" उदाहरण)
2. एक छोटा पैटर्न नोट जो पैकेजेज़, फ़ंक्शंस और हेल्पर्स के नाम बताता है जिनका पालन करना है

1) पहले संदर्भ दें (reference + rules)

हैंडलर, सर्विस मेथड, request/response टाइप्स, और कोई भी साझा हेल्पर शामिल करें जिनका एंडपॉइंट उपयोग करता है। फिर अनुबंध सादा शब्दों में बताएं:

• Route + method (उदाहरण: POST /v1/widgets)
• Request JSON फ़ील्ड्स (required vs optional)
• Response JSON शेप
• एरर केस और स्टेटस कोड
• आप किन फाइलों की अपेक्षा करते हैं (और केवल वही फाइलें)

बताएं कि किन चीज़ों का मिलान ज़रूरी है: नामकरण, पैकेज पाथ, और हेल्पर फ़ंक्शंस (WriteJSON, BindJSON, WriteError, आपका validator)।

2) आउटपुट उसी आकार में मांगे जो आप चाहते हैं

एक सख्त प्रॉम्प्ट "मददगार" रीफैक्टर करने से रोकता है। उदाहरण:

Using the reference endpoint below and the pattern notes, generate a new endpoint.
Contract:
- Route: POST /v1/widgets
- Request: {"name": string, "color": string}
- Response: {"id": string, "name": string, "color": string, "createdAt": string}
- Errors: invalid JSON -> 400; validation -> 422; duplicate name -> 409; unexpected -> 500
Output ONLY these files:
1) internal/http/handlers/widgets_create.go
2) internal/service/widgets.go (add method only)
3) internal/types/widgets.go (add types only)
Do not change: router setup, existing error format, existing helpers, or unrelated files.
Must use: package paths and helper functions exactly as in the reference.

अगर आप टेस्ट्स का उपयोग करते हैं, तो उन्हें स्पष्ट रूप से मांगें (और टेस्ट फाइल का नाम दें)। अन्यथा मॉडल उन्हें छोड़ सकता है या एक काल्पनिक टेस्ट सेटअप बना सकता है।

जनरेशन के बाद एक त्वरित डिफ़ चेक करें। अगर इसने साझा हेल्पर्स, राउटर रजिस्ट्रेशन, या आपका स्टैंडर्ड एरर रिस्पॉन्स बदल दिया है, तो आउटपुट अस्वीकार करें और "do not change" नियमों को और सख्ती से दोहराएँ।

दोहराने योग्य प्रॉम्प्ट टेम्पलेट ताकि एंडपॉइंट स्कैफोल्ड्स सुसंगत रहें

आउटपुट उतना ही सुसंगत है जितना इनपुट। "करीब सही" कोड से बचने का सबसे तेज़ तरीका हर बार एक ही प्रॉम्प्ट टेम्पलेट का उपयोग करना है, जिसमें आपके रेपो से एक छोटा संदर्भ स्नैपशॉट रखा गया हो।

प्रॉम्प्ट टेम्पलेट

कॉपी करें, पेस्ट करें, और प्लेसहोल्डर्स भरें:

You are editing an existing Go HTTP API.

CONTEXT
- Folder tree (only the relevant parts):
  <paste a small tree: internal/http, internal/service, internal/repo, etc>
- Key types and patterns:
  - Handler signature style: <example>
  - Service interface style: <example>
  - Request/response DTOs live in: <package>
- Standard error response JSON:
  {
    "error": {
      "code": "invalid_argument",
      "message": "...",
      "details": {"field": "reason"}
    }
  }
- Status code map:
  invalid_json -> 400
  invalid_argument -> 422
  not_found -> 404
  conflict -> 409
  internal -> 500

TASK
Add a new endpoint: <METHOD> <PATH>
- Handler name: <Name>
- Service method: <Name>
- Request JSON example:
  {"name":"Acme"}
- Success response JSON example:
  {"id":"123","name":"Acme"}

CONSTRAINTS
- No new dependencies.
- Keep functions small and single-purpose.
- Match existing naming, folder layout, and error style exactly.
- Do not refactor unrelated files.

ACCEPTANCE CHECKS
- Code builds.
- Existing tests pass (add tests only if the repo already uses them for handlers/services).
- Run gofmt on changed files.

FINAL INSTRUCTION
Before writing code, list any assumptions you must make. If an assumption is risky, ask a short question instead.

यह काम करता है क्योंकि यह तीन चीज़ें मजबूर करता है: एक संदर्भ ब्लॉक (क्या मौजूद है), एक प्रतिबंध ब्लॉक (क्या न करें), और ठोस JSON उदाहरण (ताकि शेप्स नहीं भटके)। अंतिम निर्देश आपका सुरक्षा जाल है: अगर मॉडल अनिश्चित है, तो कोड लिखने से पहले पूछे।

वास्तविक उदाहरण: शैली नहीं तोड़े बिना Create एंडपॉइंट जोड़ना

मान लीजिए आप एक "Create project" एंडपॉइंट जोड़ना चाहते हैं। लक्ष्य सरल है: एक नाम स्वीकार करें, कुछ नियम लागू करें, स्टोर करें, और एक नया ID लौटाएँ। कठिन हिस्सा वही है: हैंडलर–सर्विस–रिपो विभाजन और वही एरर JSON बनाए रखना।

एक सुसंगत फ्लो ऐसा दिखता है:

• Handler: JSON बाइंड करें, बुनियादी फ़ील्ड वैलिडेशन करें, सर्विस को कॉल करें
• Service: बिजनेस नियम लागू करें (जैसे यूनिकनेस), repo को कॉल करें, डोमेन परिणाम लौटाएँ
• Repo: Postgres में लिखें, जनरेटेड ID लौटाएँ

यहाँ वह रिक्वेस्ट है जिसे हैंडलर स्वीकार करता है:

{ "name": "Roadmap", "owner_id": "u_123" }

सफलता पर 201 Created लौटाएँ। ID हर बार एक ही जगह से आनी चाहिए। उदाहरण के लिए, Postgres से उसे जनरेट करवाएँ और repo से वापस लें:

{ "id": "p_456", "name": "Roadmap", "owner_id": "u_123", "created_at": "2026-01-09T12:34:56Z" }

दो वास्तविक विफलता पाथ:

अगर वैलिडेशन फेल हो (नाम गायब या बहुत छोटा), तो अपने स्टैंडर्ड शेप और चुने हुए स्टेटस कोड का उपयोग कर फ़ील्ड-लेवल एरर लौटाएँ:

{ "error": { "code": "VALIDATION_ERROR", "message": "Invalid request", "details": { "name": "must be at least 3 characters" } } }

अगर नाम मालिक के लिए यूनिक होना चाहिए और सर्विस पहले से मौजूद प्रोजेक्ट पाए, तो 409 Conflict लौटाएँ:

{ "error": { "code": "PROJECT_NAME_TAKEN", "message": "Project name already exists", "details": { "name": "Roadmap" } } }

एक निर्णय जो पैटर्न को साफ़ रखता है: हैंडलर चेक करे "क्या यह रिक्वेस्ट सही रूप में है?" जबकि सर्विस यह तय करे "क्या यह अनुमत है?" यह विभाजन जनरेट किए गए एंडपॉइंट्स को पूर्वानुमेय बनाता है।

ऐसी सामान्य त्रुटियाँ जो सुसंगति तोड़ देती हैं (और कैसे बचें)

सबसे तेज़ तरीका सुसंगति खोने का यह है कि जनरेटर को इम्प्रोवाइज़ करने दें।

एक सामान्य ड्रिफ्ट नई एरर शेप है। एक एंडपॉइंट {error: "..."}, दूसरा {message: "..."}, और तीसरा एक नेस्टेड ऑब्जेक्ट जोड़ देता है। इसे रोकें एक ही एरर एनवेलप और एक ही स्टेटस-कोड मैप रख कर, एक जगह पर और नए एंडपॉइंट्स को वही इम्पोर्ट पाथ और फ़ंक्शन नामों से री-यूज़ करने की आवश्यकता बताकर। अगर जनरेटर नया फ़ील्ड प्रस्तावित करे, तो उसे API चेंज रिक्वेस्ट समझें, सुविधा नहीं।

दूसरा ड्रिफ्ट हैंडलर का बढ़ना है। यह छोटा शुरू होता है: वैलिडेट, फिर परमिशन्स चेक, फिर DB क्वेरी, फिर बिजनेस ब्रांच। जल्द ही हर हैंडलर अलग दिखेगा। एक नियम रखें: हैंडलर HTTP को टाइप्ड इनपुट और आउटपुट में ट्रांसलेट करें; सर्विस निर्णयों की मालिक हो; डेटा एक्सेस क्वेरीज़ का मालिक हो।

नामकरण में असंगति भी जोड़ देती है। अगर एक एंडपॉइंट CreateUserRequest उपयोग करता है और दूसरा NewUserPayload, तो आप टाइप्स खोजने और glue लिखने में समय बर्बाद करेंगे। एक नामकरण योजना चुनें और नए नाम अस्वीकार करें जब तक मज़बूत कारण न हो।

कभी भी क्लाइंट्स को कच्चे डेटाबेस एरर न लौटाएँ। इससे ना केवल अंदरूनी जानकारी लीक होती है, बल्कि यह असंगत संदेश और स्टेटस कोड भी बनाती है। आंतरिक एरर्स को रैप करें, कारण लॉग करें, और एक स्थिर सार्वजनिक एरर कोड लौटाएँ।

"सुविधा के लिए" नई लाइब्रेरी जोड़ने से बचें। हर अतिरिक्त validator, router helper, या error पैकेज एक और स्टाइल बन जाता है जिसे मिलाना पड़ेगा।

रोक-गार्ड्स जो ज़्यादातर ब्रेकेज रोकते हैं:

• नए एंडपॉइंट्स को मौजूदा एरर टाइप्स और हेल्पर्स री-यूज़ करने की आवश्यकता रखें।
• हैंडलर्स को बिजनेस नियमों और DB एक्सेस से मुक्त रखें।
• रिक्वेस्ट और रिस्पॉन्स structs के लिए एक नामकरण कन्वेंशन लागू करें।
• आंतरिक एरर्स को सार्वजनिक एरर कोड में मैप करें, कभी कच्चे एरर नहीं।
• नई dependencies तभी जोड़ें जब लिखित कारण स्पष्ट हो।

अगर आप दो एंडपॉइंट्स के बीच डिफ़ नहीं देख सकते (imports, flow, error handling), तो प्रॉम्प्ट तंग करें और मर्ज करने से पहले पुन:जनरेट करें।

जनरेट किए गए एंडपॉइंट को मर्ज करने से पहले त्वरित चेकलिस्ट

कुछ भी मर्ज करने से पहले पहले संरचना चेक करें। अगर शेप सही है, तो लॉजिक बग्स ढूँढ़ना आसान होगा।

संरचना चेक्स:

• हैंडलर फ्लो सुसंगत है: इनपुट बाइंड, वैलिडेट, सर्विस कॉल, डोमेन एरर्स का HTTP में मैप, रिस्पॉन्स लिखना।
• सर्विस कोड में केवल बिजनेस नियम हैं: कोई सीधे HTTP या JSON काम नहीं।
• सफलता रिस्पॉन्स आपके हाउस स्टाइल से मेल खाते हैं (या तो साझा एनवेलप हर जगह या डायरेक्ट JSON हर जगह)।
• एरर रिस्पॉन्स एक समान हैं: वही JSON फ़ील्ड्स, वही कोड्स, वही request_id व्यवहार।
• नामकरण और प्लेसमेंट उबाऊ दिखते हैं: फ़ाइल नाम, फ़ंक्शन नाम, और रूट नाम मौजूदा एंडपॉइंट्स से मेल खाते हों, और सब gofmt-फॉर्मैटेड हो।

व्यवहार चेक्स:

• टेस्ट चलाएँ और नए हैंडलर/सर्विस ब्रांच के लिए कम से कम एक छोटा टेस्ट जोड़ें।
• पुष्टि करें कि वैलिडेशन फेल्योर समान कोड और स्टेटस लौटाते हैं जैसे समान एंडपॉइंट्स।
• एक ज्ञात सर्विस एरर (जैसे not found या conflict) ट्रिगर करें और सुनिश्चित करें कि HTTP स्टेटस और JSON शेप सही हैं।
• copy-paste बचे हुए हिस्सों की खोज करें: गलत रूट पाथ, गलत लॉग संदेश, mismatched DTO नाम।
• बिल्ड करें और लोकली सर्वर चलाकर वायरिंग और इम्पोर्ट्स सुनिश्चित करें।

अगले कदम: पैटर्न को मानकीकृत करें, फिर सुरक्षित तरीके से जनरेशन बढ़ाएँ

अपने पैटर्न को एक साझा अनुबंध के रूप में व्यवहार करें, न कि केवल एक पसंद के रूप में। "हम किस तरह एंडपॉइंट बनाते हैं" डॉक को अपने कोड के पास रखें, और एक रेफ़रेंस एंडपॉइंट बनाए रखें जो पूरी प्रक्रिया end-to-end दिखाता हो।

जनरेशन को छोटे बैचों में स्केल करें। 2-3 एंडपॉइंट जेनरेट करें जो अलग किनारों को छुएँ (एक सरल पढ़ना, एक क्रिएट जिसे वैलिडेशन है, एक अपडेट जिसमें not-found केस है)। फिर रुके और परिष्कृत करें। अगर समीक्षाएँ बार-बार वही स्टाइल ड्रिफ्ट पाएं, तो बेसलाइन डॉक और रेफ़रेंस एंडपॉइंट को अपडेट करें उससे पहले कि और जेनरेट करें।

एक दोहराने योग्य लूप:

• बेसलाइन लिखें: फ़ाइल नाम, फ़ंक्शन नाम, रिक्वेस्ट/रिस्पॉन्स structs, एरर कोड, और जहाँ वैलिडेशन होता है।
• एक एंडपॉइंट को "golden" रखें, और पैटर्न बदलने पर पहले उसे अपडेट करें।
• कुछ एंडपॉइंट्स बैच-जनरेट करें, सुसंगतता की समीक्षा करें, फिर प्रॉम्प्ट और पैटर्न डॉक को एडजस्ट करें।
• पुराने एंडपॉइंट्स को टुकड़ों में रीफैक्टर करें और व्यवहार बदलने पर रोलबैक पाथ रखें।
• एक मीट्रिक एक हफ्ते के लिए ट्रैक करें: एंडपॉइंट जोड़ने का समय, मर्ज के बाद बग रेट, या समीक्षा समय।

अगर आप एक तंग बिल्ड‑रीव्यू लूप चाहते हैं, तो एक vibe-coding प्लेटफ़ॉर्म जैसे Koder.ai (koder.ai) आपको चैट‑ड्रिवन वर्कफ़्लो में तेज़ी से स्कैफोल्ड और इटरेट करने में मदद कर सकता है, फिर जब यह आपके स्टैण्डर्ड से मेल खाए तो सोर्स एक्सपोर्ट कर लें। टूल कम मायने रखता है—नियम ज़्यादा मायने रखता है: आपकी बेसलाइन नियंत्रण में रहे।