Claude Code ਲਈ Go API ਸਕੈਫੋਲਡਿੰਗ: ਸਥਿਰ ਹੈਂਡਲਰ ਅਤੇ ਸੇਵਾਵਾਂ

ਜਦੋਂ ਪੈਟਰਨ ਸ਼ੁਰੂ ਵਿੱਚ ਫਿਕਸ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ ਤਾਂ Go APIs ਕਿਉਂ ਗੰਦੇ ਹੋ ਜਾਂਦੇ ਹਨ

Go APIs ਆਮ ਤੌਰ 'ਤੇ ਸਾਫ਼ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ: ਕੁਝ ਐਂਡਪੌਇੰਟ, ਇੱਕ-ਦੋ ਲੋਕ, ਅਤੇ ਸਭ ਕੁਝ ਸਿਰ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਫਿਰ API ਵਧਦਾ ਹੈ, ਫੀਚਰ ਜਲਦੀ ਸ਼ਿਪ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਛੋਟੇ-ਛੋਟੇ ਫਰਕ ਹੋ ਕੇ ਅੰਦਰ ਆ ਜਾਂਦੇ ਹਨ। ਹਰ ਇਕ ਫਰਕ ਨੋ-ਪ੍ਰਾਬਲਮ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਕੱਠੇ ਹੋ ਕੇ ਇਹ ਹਰ ਭਵੀਖੀ ਤਬਦੀਲੀ ਨੂੰ ਸੁਸਤ ਕਰ ਦਿੰਦੇ ਹਨ।

ਇੱਕ ਆਮ ਉਦਾਹਰਨ: ਇੱਕ ਹੈਂਡਲਰ JSON ਨੂੰ struct ਵਿੱਚ ਡੀਕੋਡ ਕਰਦਾ ਹੈ ਅਤੇ 400 ਲੌਟਾਉਂਦਾ ਹੈ ਇੱਕ ਸਹਾਇਕ ਸੁਨੇਹੇ ਨਾਲ, ਦੂਜਾ 422 ਵੱਖ-ਵੱਖ ਆਕਾਰ ਨਾਲ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੀਜਾ errors ਨੂੰ ਵੱਖਰੇ ਫਾਰਮੇਟ ਵਿੱਚ ਲੌਗ ਕਰਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਵਿਚੋਂ ਕੋਈ ਵੀ ਕੰਪਾਇਲੇਸ਼ਨ ਤੋੜਦਾ ਨਹੀਂ; ਪਰ ਹਰ ਵਾਰੀ ਤੁਹਾਨੂੰ ਨਿਰੀਣ ਲੈਣਾ ਪੈਂਦਾ ਅਤੇ ਨਿੱਕੀ-ਨਿੱਕੀ ਛੇੜਛਾੜ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।

ਤੁਸੀਂ ਇਹ ਗੰਦਗੀ ਇੱਥੇ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ:

• ਐਂਡਪੌਇੰਟਾਂ 'ਤੇ ਵੱਖ-ਵੱਖ error bodies, ਤਾਂ clients ਨੂੰ ਖ਼ਾਸ ਕੇਸ ਬਣਾਉਣੇ ਪੈਂਦੇ ਹਨ।
• ਸੇਵਾਵਾਂ ਕਦੇ raw database errors ਵਾਪਸ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਕਦੇ “ਮਿੱਤਰ” errors।
• ਨਾਂਕਰਨ ਵਿੱਚ ਭਟਕਾਅ (CreateUser, AddUser, RegisterUser) ਜੋ search ਨੂੰ ਔਖਾ ਕਰ ਦਿੰਦਾ ਹੈ।
• ਵੈਲੀਡੇਸ਼ਨ ਵੱਖ-ਵੱਖ ਥਾਂਗਾਂ ਤੇ ਹੋਣਾ, ਜਿਸ ਨਾਲ ਓਹੇ bugs ਵਾਪਸ ਆਉਂਦੇ ਰਹਿੰਦੇ ਹਨ।

ਇੱਥੇ "Scaffolding" ਦਾ ਮਤਲਬ ਹੈ: ਨਵੇਂ ਕੰਮ ਲਈ ਇੱਕ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਟੈਂਪਲੇਟ: ਕੋਡ ਕਿੱਥੇ ਜਾਵੇਗਾ, ਹਰ ਲੇਅਰ ਕੀ ਕਰੇਗੀ, ਅਤੇ responses ਕਿਸ ਰੂਪ ਵਿੱਚ ਹੋਣਗੇ। ਇਹ ਜ਼ਿਆਦਾ ਕੋਡ ਜਨਰੇਟ ਕਰਨ ਬਾਰੇ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਸਥਿਰ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰਨ ਬਾਰੇ ਹੈ।

Claude ਵਰਗੇ ਟੂਲ ਨਵੇਂ ਐਂਡਪੌਇੰਟ ਤੇਜ਼ੀ ਨਾਲ scaffold ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਉਹਦੋਂ ਹੀ ਲਾਭਦਾਇਕ ਰਹਿੰਦੇ ਹਨ ਜਦ ਤੁਸੀਂ ਪੈਟਰਨ ਨੂੰ ਇੱਕ ਨਿਯਮ ਵਾਂਗ ਰੱਖਦੇ ਹੋ। ਤੁਸੀਂ ਨਿਯਮ ਨਿਰਧਾਰਤ ਕਰੋ, ਹਰ diff ਦੀ ਸਮੀਖਿਆ ਕਰੋ, ਅਤੇ ਟੈਸਟ ਚਲਾਓ। ਮਾਡਲ ਸਧਾਰਨ ਹਿੱਸੇ ਭਰਦਾ ਹੈ; ਉਹ ਤੁਹਾਡੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਨਵਾਂ ਰੂਪ ਦੇਣ ਨਹੀਂ ਪਾਉਂਦਾ।

ਇੱਕ ਲੇਅਰ ਵੰਡ ਚੁਣੋ: handler, service, ਅਤੇ data access

ਜਦ ਹਰ request ਇੱਕੋ ਹੀ ਰਾਹ ਅਨੁਸਾਰ ਚੱਲਦੀ ਹੈ ਤਾਂ Go API ਅਸਾਨੀ ਨਾਲ ਵਧਦਾ ਹੈ। ਨਵੇਂ ਐਂਡਪੌਇੰਟ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਲੇਅਰ ਵੰਡ ਚੁਣੋ ਅਤੇ ਉਸ 'ਤੇ ਕਾਇਮ ਰਹੋ।

ਜ਼ਿੰਮੇਵਾਰੀਆਂ, ਸਧਾਰਾ ਰੱਖੋ

ਹੈਂਡਲਰ ਦਾ ਕੰਮ ਸਿਰਫ਼ HTTP ਹੈ: request ਪੜ੍ਹੋ, service ਨੂੰ ਕਾਲ ਕਰੋ, ਅਤੇ response ਲਿਖੋ। ਇਸ ਵਿੱਚ business rules, SQL, ਜਾਂ "ਸਿਰਫ਼ ਇਹ ਖਾਸ ਕੇਸ" ਲਾਜਿਕ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।

ਸੇਵਾ use case ਦੀ ਮਾਲਕੀ ਰੱਖਦੀ ਹੈ: business rules, ਫੈਸਲੇ, ਅਤੇ repositories ਜਾਂ ਬਾਹਰੀ ਕਾਲਾਂ ਦੀ orchestration। ਇਸਨੂੰ HTTP ਦਰਸ਼ਨ-ਚਿੰਤਾਵਾਂ ਜਿਵੇਂ status codes, headers, ਜਾਂ errors ਦੇ ਰੈਂਡਰਿੰਗ ਦਾ ਗਿਆਨ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।

ਡਾਟਾ ਐਕਸੈਸ (repository/store) persistence ਵੇਰਵੇ ਦੀ ਮਾਲਕੀ ਰੱਖਦਾ ਹੈ। ਇਹ service ਦੀ ਨੀਅਤ ਨੂੰ SQL/ਕੁਐਰੀ/ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਵਿੱਚ ਤਰਜਮਾ ਕਰਦਾ ਹੈ। ਇਹ business rules ਨੂੰ ਬੇਸਿਕ ਡੇਟਾ ਇਨਟੀਗ੍ਰਿਟੀ ਤੋਂ ਅੱਗੇ ਨਹੀਂ ਲਗਾਉਣਾ ਚਾਹੀਦਾ, ਅਤੇ API responses ਨੂੰ shape ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ।

ਇੱਕ ਵਿਭਾਜਨ ਚੈਕਲਿਸਟ ਜੋ ਵਿਹਾਰਕ ਰਹੇ:

• Handler: input parse ਕਰੋ, service ਕਾਲ ਕਰੋ, errors ਨੂੰ HTTP ਨਾਲ ਮੈਪ ਕਰੋ, JSON ਲਿਖੋ
• Service: business rules ਲਗਾਓ, repos ਕਾਲ ਕਰੋ, domain results ਜਾਂ typed errors ਵਾਪਸ ਕਰੋ
• Data access: ਕੁਐਰੀ ਚਲਾਓ, rows ਨੂੰ structs ਵਿੱਚ ਮੈਪ ਕਰੋ, storage errors ਵਾਪਸ ਕਰੋ
• Shared: ਆਮ error types ਅਤੇ response helpers
• ਕੋਈ ਲੇਅਰ ਦੂਜੇ ਨੂੰ ਛੱਡ ਕੇ ਨਹੀਂ ਜਾਵੇ (handler ਕਦੇ ਸਿੱਧਾ repo ਨੂੰ ਕਾਲ ਨਾ ਕਰੇ)

ਵੈਲੀਡੇਸ਼ਨ ਲਈ ਇੱਕ ਨਿਯਮ

ਇੱਕ ਨਿਯਮ ਚੁਣੋ ਅਤੇ ਇਸਨੂੰ ਨਾ ਮੋੜੋ।

ਸਧਾਰਨ ਤਰੀਕਾ:

• Handlers "shape validation" ਕਰਦੇ ਹਨ (ਜ਼ਰੂਰੀ ਫੀਲਡ, ਬੁਨਿਆਦੀ ਫਾਰਮੈਟ)।
• Services "meaning validation" ਕਰਦੀਆਂ ਹਨ (permissions, invariants, ਸਟੇਟ)।

ਉਦਾਹਰਨ: handler ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ email ਮੌਜੂਦ ਹੈ ਅਤੇ ਈਮੇਲ ਵਰਗਾ ਲੱਗਦਾ ਹੈ। service ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ email ਮਨਜ਼ੂਰ ਹੈ ਅਤੇ ਪਹਿਲਾਂ ਵਰਤਿਆ ਨਹੀਂ ਗਿਆ।

ਕਿਹੜੇ ਚੀਜ਼ਾਂ ਲੇਅਰਾਂ ਦੇ ਵਿਚਕਾਰ ਜਾਂਦੀਆਂ ਹਨ

ਸ਼ੁਰੂ ਵਿੱਚ ਨਿਰਣਾ ਕਰੋ ਕਿ services domain types ਜਾਂ DTOs ਵਾਪਸ ਕਰਦੀਆਂ ਹਨ।

ਇੱਕ ਸਾਫ਼ ਡਿਫੌਲਟ: handlers request/response DTOs ਵਰਤਦੇ ਹਨ, services domain types ਵਰਤਦੇ ਹਨ, ਅਤੇ handler domain ਨੂੰ response ਵਿੱਚ ਮੈਪ ਕਰਦਾ ਹੈ। ਇਹ service ਨੂੰ ਸਥਿਰ ਰੱਖਦਾ ਹੈ ਚਾਹੇ HTTP contract ਬਦਲੇ।

ਜੇ mapping ਭਾਰੀ ਲੱਗਦਾ ਹੈ, ਫਿਰ ਵੀ ਸਥਿਰ ਰੱਖੋ: service ਇੱਕ domain type ਅਤੇ ਇੱਕ typed error ਵਾਪਸ ਕਰੇ, ਅਤੇ JSON shaping handler ਵਿੱਚ ਹੀ ਰਹੇ।

ਇੱਕ ਮਿਆਰੀ error response ਅਤੇ status code ਮੈਪ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ generated endpoints ਇੱਕੋ ਜਿਹਾ ਮਹਿਸੂਸ ਹੋਣ, ਤਾਂ early ਹੀ error responses ਨੂੰ ਲਾਕ ਕਰੋ। ਜਨਰੇਸ਼ਨ ਸਭ ਤੋਂ ਵਧੀਆ ਤਦ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦ output ਫਾਰਮੈਟ ਅਣ-ਵਿੱਚਾਰਯੋਗ ਹੋ: ਇੱਕ JSON ਆਕਾਰ, ਇੱਕ status-code ਮੈਪ, ਅਤੇ ਇੱਕ ਨਿਯਮ ਕਿ ਕੀ expose ਕੀਤਾ ਜਾਵੇ।

ਇੱਕ single error envelope ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਹਰੇਕ endpoint failure 'ਤੇ ਵਾਪਸ ਕੀਤਾ ਜਾਵੇ। ਇਸਨੂੰ ਛੋਟਾ ਤੇ ਅਨੁਮਾਨਯੋਗ ਰੱਖੋ:

{
  "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 ਵਿੱਚ ਰੱਖੋ। validation ਲਈ, details.fields ਦਾ ਸਾਦਾ map ਜਨਰੇਟ ਕਰਨ ਲਈ ਆਸਾਨ ਅਤੇ ਕਲਾਇਂਟਾਂ ਨੂੰ input ਦੇ ਨੇੜੇ ਦਿਖਾਉਣ ਲਈ ਸਹਾਇਕ ਹੁੰਦਾ ਹੈ।

ਅਗਲਾ ਕੰਮ ਹੈ status code ਮੈਪ ਲਿਖਣਾ ਅਤੇ ਉਸਨੂੰ ਕਾਇਮ ਰੱਖਣਾ। ਹਰ ਐਂਡਪੌਇੰਟ 'ਤੇ ਘੱਟ ਤਰਕ-ਵਿਵਾਦ ਹੋਵੇਗਾ। ਜੇ ਤੁਸੀਂ 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

ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਲੌਗ ਕਰਦੇ ਹੋ বনਾਮ ਕੀ ਵਾਪਸ ਕਰਦੇ ਹੋ। ਇੱਕ ਚੰਗਾ ਨਿਯਮ: clients ਨੂੰ ਸੁਰੱਖਿਅਤ ਸੁਨੇਹਾ ਅਤੇ ਇੱਕ request ID ਮਿਲੇ; logs ਵਿੱਚ ਪੂਰਾ error ਅਤੇ ਅੰਦਰੂਨੀ ਸੰਦਰਭ (SQL, upstream payloads, user IDs) ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਕਦੇ ਲੀਕ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ।

ਆਖ਼ਿਰ ਵਿੱਚ, request_id ਨੂੰ ਸਧਾਰਨ ਰੱਖੋ। ਜੇ incoming ID header ਹੈ ਤਾਂ ਉਸਨੂੰ ਸਵੀਕਾਰ ਕਰੋ (API gateway ਤੋਂ ਆ ਸਕਦਾ ਹੈ), ਨਹੀਂ ਤਾਂ edge (middleware) 'ਤੇ ਇੱਕ ਬਣਾਓ। ਇਸਨੂੰ context ਨਾਲ ਜੁੜੋ, logs ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰੋ, ਅਤੇ ਹਰੇਕ error response ਵਿੱਚ ਵਾਪਸ ਕਰੋ।

ਫੋਲਡਰ ਲੇਆਊਟ ਅਤੇ ਨਾਂਕਰਨ ਜੋ generation ਨੂੰ ਅਨੁਮਾਨਯੋਗ ਬਣਾਉਂਦੇ ਹਨ

ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ scaffolding ਸਥਿਰ ਰਹੇ, ਤਾਂ ਤੁਹਾਡਾ ਫੋਲਡਰ ਲੇਆਊਟ ਬੋਰਿੰਗ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਫਾਇਲਾਂ ਵਿਖਰੀਆਂ ਹਨ ਜਾਂ ਨਾਮ ਹਰ ਫੀਚਰ ਲਈ ਵੱਖਰੇ ਹਨ ਤਾਂ generators ਭਟਕ ਜਾਂਦੇ ਹਨ।

ਇੱਕ ਨਾਂਕਰਨ ਰਿਵਾਜ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਨਾਂ ਮੋੜੋ। ਹਰ ਚੀਜ਼ ਲਈ ਇੱਕ ਸ਼ਬਦ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਰੱਖੋ: 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

ਸਾਂਝੇ types ਕਿੱਥੇ ਰਹਿਣਗੇ, ਇਹ ਫੈਸਲਾ ਕਰੋ, ਕਿਉਂਕਿ ਇੱਥੇ ਪ੍ਰਾਜੈਕਟ ਆਮ ਤੌਰ 'ਤੇ ਗੰਦੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਕ ਉਪਯੋਗੀ ਨਿਯਮ:

• API request/response types internal/apitypes ਵਿੱਚ (JSON ਅਤੇ validation ਲੋੜਾਂ ਨੂੰ ਮਿਲਾਉਂਦੇ ਹੋਏ)।
• Domain types service ਲੇਅਰ ਦੇ ਨੇੜੇ ਹੀ (business rules ਨੂੰ ਮਿਲਾਉਣ ਲਈ)।

ਜੇ ਕਿਸੇ type ਵਿੱਚ JSON tags ਹਨ ਅਤੇ ਉਹ clients ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਤਾਂ ਇਸਨੂੰ API type ਸਮਝੋ।

.handlers ਦੀਆਂ dependencies ਘੱਟ ਰੱਖੋ ਅਤੇ ਇਹ ਨਿਯਮ ਸਪਸ਼ਟ ਕਰੋ:

• Handlers ਸਿਰਫ਼ import ਕਰਨ: routing/http, context, apitypes, ਅਤੇ services
• Services import: domain types ਅਤੇ data access
• Data access imports: database driver ਅਤੇ query helpers
• ਕੋਈ handler ਸਿੱਧਾ database ਪੈਕੇਜ import ਨਾ ਕਰੇ

ਰੀਪੋ ਰੂਟ ਵਿੱਚ ਇੱਕ ਛੋਟਾ pattern doc ਲਿਖੋ (ਸਧਾਰਣ Markdown ਠੀਕ ਹੈ)। ਫੋਲਡਰ ਟਰੀ, ਨਾਂਕਰਨ ਨਿਯਮ, ਅਤੇ ਇੱਕ ਛੋਟੀ example flow (handler -> service -> repo, ਅਤੇ ਹਰ ਟੁਕੜੇ ਦੀ ਫਾਇਲ) ਸ਼ਾਮਿਲ ਕਰੋ। ਇਹ ਉਹ ਸਹਿੱਟਾ ਹੈ ਜੋ ਤੁਸੀਂ ਆਪਣੇ generator ਵਿੱਚ ਪੇਸਟ ਕਰਦੇ ਹੋ ਤਾਂ ਨਵੇਂ endpoints ਹਰ ਵਾਰੀ structure ਨਾਲ ਮਿਲਦੇ ਹਨ।

ਇੱਕ ਰੇਫਰੇਂਸ ਐਂਡਪੌਇੰਟ ਬਣਾਓ ਜੋ ਪੈਟਰਨ ਸੈੱਟ ਕਰੇ

ਦਸ ਐਂਡਪੌਇੰਟ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਐਂਡਪੌਇੰਟ ਬਣਾਓ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰਦੇ ਹੋ। ਇਹ ਗੋਲਡ ਸਟੈਂਡਰਡ ਹੈ: ਉਹ ਫਾਇਲ ਜਿਸ ਦੀ ਓਰ ਤੁਸੀਂ ਇਸ਼ਾਰਾ ਕਰਕੇ ਕਹਿ ਸਕਦੇ ਹੋ, "ਨਵਾਂ ਕੋਡ ਇੰਝ ਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।" ਤੁਸੀਂ ਇਸਨੂੰ scratch ਤੋਂ ਲਿਖ ਸਕਦੇ ਹੋ ਜਾਂ ਮੌਜੂਦਾ ਇੱਕ ਨੂੰ refactor ਕਰਕੇ ਇਹ ਮਿਆਰ ਬਣਾਉ।

ਹੈਂਡਲਰ ਪਤਲਾ ਰੱਖੋ। ਇੱਕ ਛੋਟੀ ਚਾਲ ਜੋ ਬਹੁਤ ਮਦਦ ਕਰਦੀ ਹੈ: handler ਅਤੇ service ਵਿਚਕਾਰ interface ਰੱਖੋ ਤਾਂ handler ਕਿਸੇ concrete struct 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੇ।

ਰੈਫਰੇਂਸ ਐਂਡਪੌਇੰਟ ਵਿੱਚ ਜਿੱਥੇ ਭਵਿੱਖGenerated ਕੋਡ ਭਟਕ ਸਕਦਾ ਹੈ, ਉੱਥੇ ਥੋੜੇ ਟਿੱਪਣੀ ਜੋੜੋ। ਫੈਸਲਿਆਂ ਦੀ ਵਜ੍ਹਾ ਦੱਸੋ (ਕਿਉਂ 400 vs 422, ਕਿਉਂ create 201 ਵਾਪਸ ਕਰਦਾ ਹੈ, ਕਿਉਂ ਅੰਦਰੂਨੀ errors ਨੂੰ generic ਸੁਨੇਹੇ ਦੇ ਪਿੱਛੇ ਛੁਪਾਇਆ ਜਾਂਦਾ ਹੈ)। ਉਦੋਂ-ਉਦੋਂ ਟਿੱਪਣੀਆਂ ਜੋ ਸਿਰਫ਼ ਕੋਡ ਦੋਹਰਾਉਂਦੀਆਂ ਹਨ, ਛੱਡ ਦਿਉ।

ਜਦੋਂ reference endpoint ਕੰਮ ਕਰਨ ਲੱਗੇ, helpers ਨਿਕਾਲੋ ਤਾਂ ਹਰ ਨਵੇਂ endpoint ਵਿੱਚ drift ਘੱਟ ਹੋਵੇ। ਸਭ ਤੋਂ reused helpers ਆਮ ਤੌਰ 'ਤੇ:

• JSON bind ਅਤੇ malformed bodies ਨੂੰ handle ਕਰਨਾ
• ਇਨਪੁਟ validate ਕਰਨਾ ਅਤੇ field errors ਵਾਪਸ ਕਰਨਾ
• JSON responses ਲਗਾਤਾਰ ਲਿਖਣਾ
• domain errors ਨੂੰ HTTP status codes ਨਾਲ ਮੈਪ ਕਰਨਾ

ਹੇਠਾਂ "thin handler + 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)
}

ਇਸਨੂੰ ਕੁਝ tests ਨਾਲ ਲਾਕ ਕਰੋ (ਹੇਠਾਂ error mapping ਲਈ ਸਰਲ table test)। ਜਨਰੇਸ਼ਨ ਉਸ ਸਮੇਂ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦ ਉਸਦੇ ਕੋਲ ਇੱਕ ਸਾਫ਼ ਨਿਸ਼ਾਨਾ ਨਿਰਧਾਰਤ ਹੋਵੇ।

ਕਦਮ-ਬ-ਕਦਮ: Claude ਤੋਂ ਨਵਾਂ ਐਂਡਪੌਇੰਟ ਜਨਰੇਟ ਕਰਵਾਉਣਾ ਜੋ ਮਿਲਦਾ-ਜੁਲਦਾ ਹੋ

ਸਥਿਰਤਾ ਉਸ ਚੀਜ਼ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਜੋ ਤੁਸੀਂ ਪੇਸਟ ਕਰਦੇ ਹੋ ਅਤੇ ਜੋ ਤੁਸੀਂ ਮਨ੍ਹਾਂ ਕਰਦੇ ਹੋ। ਨਵੇਂ ਐਂਡਪੌਇੰਟ ਲਈ ਦੋ ਚੀਜ਼ਾਂ ਦਿਓ:

1. ਤੁਹਾਡਾ reference endpoint ("perfect" example)
2. ਇੱਕ ਛੋਟੀ pattern ਨੋਟ ਜੋ ਪੈਕੇਜਾਂ, ਫੰਕਸ਼ਨਾਂ, ਅਤੇ helpers ਦੇ ਨਾਂ ਦੱਸੀਦਾ ਕਰੇ

1) ਪਹਿਲਾਂ ਸੰਦਰਭ ਦਿਓ (reference + ਨਿਯਮ)

ਹੈਂਡਲਰ, ਸੇਵਾ ਮੈਥਡ, request/response types, ਅਤੇ ਕੋਈ ਸਾਂਝੇ helpers ਸ਼ਾਮਿਲ ਕਰੋ। ਫਿਰ ਸਪਸ਼ਟ ਸ਼ਰਤ ਦਿਓ:

• Route + method (ਉਦਾਹਰਣ: POST /v1/widgets)\n- Request JSON fields (required vs optional)\n- Response JSON shape\n- Error ਕੇਸ ਅਤੇ status codes\n- ਉਹ ਫਾਈਲਾਂ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ (ਅਤੇ ਸਿਰਫ ਉਹ ਫਾਇਲਾਂ)

ਜੋ ਚੀਜ਼ਾਂ ਮਿਲਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਉਸ ਬਾਰੇ ਖਾਸ ਹੋਵੋ: naming, package paths, ਅਤੇ helper functions (WriteJSON, BindJSON, WriteError, ਤੁਹਾਡਾ validator)।

2) ਉਸੇ ਬਿਲਕੁਲ ਉਸ ਰੂਪ ਵਿੱਚ output ਮੰਗੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ

ਇੱਕ ਟਾਈਟ prompt "ਸਹਾਇਕ ਰੀਫੈਕਟ" ਰੋਕਦਾ ਹੈ। ਉਦਾਹਰਣ:

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.

ਜੇ ਤੁਸੀਂ tests ਵਰਤਦੇ ਹੋ, ਉਹਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਮੰਗੋ (ਅਤੇ test ਫਾਇਲ ਦਾ ਨਾਮ ਦਿਓ)। ਨਹੀਂ ਤਾਂ ਮਾਡਲ ਉਹਨਾਂ ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ ਜਾਂ ਨਵਾਂ test setup ਰਚ ਸਕਦਾ ਹੈ।

ਜਨਰੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਝਲਕ-ਤੁਲਨਾ (diff) ਜਲਦੀ ਚੈਕ ਕਰੋ। ਜੇ ਇਹ shared helpers, router ਰਜਿਸਟ੍ਰੇਸ਼ਨ, ਜਾਂ আপনার standard error response ਨੂੰ ਬਦਲਦਾ ਹੈ, ਤਾਂ output reject ਕਰੋ ਅਤੇ "do not change" ਨਿਯਮ ਹੋਰ ਸਖਤ ਤਰੀਕੇ ਨਾਲ ਦੁਹਰਾਓ।

ਇਕ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲਾ ਪ੍ਰੰਪਟ ਟੈਮਪਲੇਟ consistent endpoint scaffolds ਲਈ

ਆਉਟਪੁੱਟ ਉਸੇ ਹਦ ਤੱਕ ਸਹੀ ਹੈ ਜਿੱਥੇ ਇਨਪੁੱਟ ਸਪਸ਼ਟ ਹੈ। ਹਰ ਵਾਰੀ ਇੱਕ ਪਰੰਪਟ ਟੈਮਪਲੇਟ ਦੁਹਰਾਉਣਾ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਤੁਹਾਡੇ ਰੀਪੋ ਤੋਂ ਇੱਕ ਛੋਟਾ ਸੰਦਰਭ ਟੁਕੜਾ ਪੇਸਟ ਕੀਤਾ ਜਾਵੇ।

ਪ੍ਰੰਪਟ ਟੈਮਪਲੇਟ

ਕਾਪੀ ਕਰੋ, ਪੇਸਟ ਕਰੋ, ਅਤੇ placeholders ਭਰੋ:

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.

ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤਿੰਨ ਚੀਜ਼ਾਂ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ: ਇੱਕ context block (jo ਮੌਜੂਦ ਹੈ), ਇੱਕ constraints block (ਕੀ ਨਾ ਕਰਨਾ ਹੈ), ਅਤੇ concrete JSON ਉਦਾਹਰਨ (ਤਾਂ ਕਿ shapes drift ਨਾ ਹੋਣ)। ਆਖਰੀ ਹਦਾਇਤ ਤੁਹਾਡੀ safety catch ਹੈ: ਜੇ ਮਾਡਲ ਨੂੰ ਸ਼ੱਕ ਹੈ, ਤਾਂ ਉਹ ਕੋਈ ਨਿਰਣੈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਵਾਲ ਪੁੱਛੇ।

ਹਕੀਕਤੀ ਉਦਾਹਰਨ: ਆਉਟਪੁੱਟ ਦੀ ਸ਼ੈਲੀ ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ Create endpoint ਜੋੜਨਾ

ਕਹੋ ਤੁਸੀਂ ਇੱਕ "Create project" ਐਂਡਪੌਇੰਟ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਲਕੜੀ ਸਧਾਰਨ ਹੈ: ਨਾਮ ਲਓ, ਕੁਝ ਨਿਯਮ ਲਗਾਓ, ਸਟੋਰ ਕਰੋ, ਅਤੇ ਨਵਾਂ ID ਵਾਪਸ ਕਰੋ। ਮੁਸ਼ਕਲ ਗੱਲ ਇਹ ਹੈ ਕਿ handler-service-repo ਵਿਭਾਜਨ ਅਤੇ ਓਹੀ error JSON ਵਰਤਿਆ ਜਾਵੇ।

ਇੱਕ ਮਿਲਦੀ-ਜੁਲਦੀ flow ਇੰਝ ਦਿਖਦੀ ਹੈ:

• Handler: JSON bind ਕਰੋ, ਬੁਨਿਆਦੀ field validation ਕਰੋ, service ਨੂੰ ਕਾਲ ਕਰੋ
• Service: business rules ਲਗਾਓ (ਜਿਵੇਂ uniqueness), repo ਨੂੰ ਕਾਲ ਕਰੋ, domain result ਵਾਪਸ ਕਰੋ
• Repo: Postgres ਵਿੱਚ ਲਿਖੋ, generated ID ਵਾਪਸ ਕਰੋ

ਹੇਠਾਂ handler ਰਿਕਵੇਸਟ ਨੁਮੂਨਾ ਜਿਸਨੂੰ ਹੈਂਡਲਰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ:

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

ਸਫਲਤਾ 'ਤੇ 201 Created ਵਾਪਸ ਕਰੋ। ID ਇੱਕ ਹੀ ਜਗ੍ਹਾ ਤੋਂ ਆਉਣੀ ਚਾਹੀਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Postgres ਨੂੰ ID generate ਕਰਨ ਦਿਓ ਅਤੇ repo ਉਸਨੂੰ ਵਾਪਸ ਕਰੇ:

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

ਦੋ ਹਕੀਕਤੀ failure paths:

ਜੇ validation fail ਹੋਵੇ (ਗਾਇਬ ਜਾਂ ਬਹੁਤ ਛੋਟਾ ਨਾਮ), ਤਾਂ field-level error ਆਪਣੇ standard shape ਤੇ ਵਾਪਸ ਕਰੋ:

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

ਜੇ ਨਾਮ owner ਦੇ ਲਈ unique ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੋਵੇ ਅਤੇ service ਮੌਜੂਦਾ ਪ੍ਰੋਜੈਕਟ ਲੱਭ ਲਏ, ਤਾਂ 409 Conflict ਵਾਪਸ ਕਰੋ:

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

ਇੱਕ ਫੈਸਲਾ ਜੋ pattern ਨੂੰ ਸਾਫ਼ ਰੱਖਦਾ ਹੈ: handler ਜਾਂਚਦਾ ਹੈ "ਕੀ ਇਹ ਰਿਕਵੇਸਟ ਢਾਂਚਾ ਸਹੀ ਹੈ?" ਜਦکہ service ਮਾਲਕੀ ਰੱਖਦਾ ਹੈ "ਕੀ ਇਹ ਆਗਿਆਤ ਹੈ?" ਇਹ ਵੰਡ generated endpoints ਨੂੰ ਅਨੁਮਾਨਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।

consistency ਤੋੜਨ ਵਾਲੀਆਂ ਆਮ ਗਲਤੀਆਂ (ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਬਚਣ ਦੇ ਤਰੀਕੇ)

ਜਨਰੇਟਰ ਨੂੰ improvise ਕਰਨ ਦਿੰਦੇ ਹੋਏ ਤੁਸੀਂ ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ consistency ਗੁੰਵਾਉਂਦੇ ਹੋ।

ਇੱਕ ਆਮ drift ਨਵਾਂ error shape ਬਣਾਉਣਾ ਹੈ। ਇੱਕ endpoint {error: "..."} ਵਾਪਸ ਕਰਦਾ ਹੈ, ਦੂਜਾ {message: "..."}, ਅਤੇ ਤੀਜਾ nested object ਜੋੜਦਾ ਹੈ। ਇਸਨੂੰ ਇੱਕ tempat error envelope ਅਤੇ ਇੱਕ status code ਮੈਪ ਰਹਿਤ ਰੱਖ ਕੇ ਠੀਕ ਕਰੋ ਜੋ ਇਕ ਹੀ ਥਾਂ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਹੋਵੈ ਅਤੇ ਨਵੀਆਂ endpoints ਨੂੰ import path ਅਤੇ function name ਰਾਹੀਂ reuse ਕਰਨ ਦੀ ਲੋੜ ਰੱਖੋ। ਜੇ generator ਕੋਈ ਨਵਾਂ field propose ਕਰੇ, ਉਸਨੂੰ ਇੱਕ API change request ਸਮਝੋ ਨਾ ਕਿ ਸੁਵਿਧਾ।

ਹੋਰ drift handler bloat ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ ਛੋਟਾ: validate, ਫਿਰ permission checks, ਫਿਰ DB query, ਫਿਰ business branching। ਜਲਦੀ ਹਰ handler ਵੱਖਰਾ दिखਣ ਲੱਗਦਾ ਹੈ। ਇੱਕ ਨਿਯਮ ਰੱਖੋ: handlers HTTP ਨੂੰ typed inputs ਅਤੇ outputs ਵਿੱਚ translate ਕਰਨ; services ਫੈਸਲੇ ਕਰਨ; data access queries ਦੀ ਮਾਲਕੀ ਰੱਖੇ।

ਨਾਮਕਰਨ mismatch ਵੀ ਸਮੇਂ ਨਾਲ ਵੱਧ ਜਾਂਦਾ ਹੈ। ਜੇ ਇੱਕ endpoint CreateUserRequest ਵਰਤਦਾ ਹੈ ਅਤੇ ਦੂਜਾ NewUserPayload, ਤਾਂ ਤੁਸੀਂ types ਲੱਭਣ ਵਿੱਚ ਸਮਾਂ ਗਵਾਓਗੇ। ਇੱਕ ਨਾਂਕਰਨ ਸਕੀਮ ਚੁਣੋ ਅਤੇ ਨਵੇਂ ਨਾਂਸਿਰਫ਼ ਤਦ ਮੰਨੋ ਜਦੋਂ ਜ਼ਬਰਦਸਤ ਕਾਰਨ ਹੋਵੇ।

ਕਦੇ ਵੀ raw database errors clients ਨੂੰ ਵਾਪਸ ਨਾ ਕਰੋ। ਇਹ ਨਾ ਸਿਰਫ internals ਲੀਕ ਕਰਦਾ ਹੈ, ਬਲਕਿ inconsistent messages ਅਤੇ status codes ਵੀ ਬਣਾਉਂਦਾ ਹੈ। ਅੰਦਰੂਨੀ errors ਨੂੰ wrap ਕਰੋ, ਕਾਰਨ logs ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਇੱਕ ਸਥਿਰ public error code ਵਾਪਸ ਕਰੋ।

ਨਵੇਂ libraries "ਸਿਰਫ਼ ਸੁਵਿਧਾ ਲਈ" ਨਾ ਜੋੜੋ। ਹਰ ਇਕ ਨਵਾਂ validator, router helper, ਜਾਂ error package ਹੋਰ ਇੱਕ style ਬਣਾਉਂਦਾ ਜਿਸਨੂੰ ਮਿਲਾਉਣਾ ਪੈਂਦਾ ਹੈ।

ਜਿਆਦਾਤਰ ਟੁੱਟ-ਫੱਟ ਰੋਕੇ ਜਾਣ ਵਾਲੇ ਗਾਰਡਰੇਲਜ਼:

• ਨਵੇਂ endpoints ਨੂੰ ਮੌਜੂਦਾ error types ਅਤੇ helpers reuse ਕਰਨ ਦੀ ਲੋੜ ਰੱਖੋ।
• Handlers ਨੂੰ business rules ਅਤੇ database access ਤੋਂ ਮੁਕਤ ਰੱਖੋ।
• Request ਅਤੇ response structs ਲਈ ਇੱਕ ਨਾਂਕਰਨ convention ਲਾਗੂ ਕਰੋ।
• ਅੰਦਰੂਨੀ errors ਨੂੰ public error codes 'ਤੇ ਮੈਪ ਕਰੋ; ਕਦੇ raw errors ਨਾ ਭੇਜੋ।
• ਨਵੀਆਂ dependencies ਕੇਵਲ ਸਪਸ਼ਟ, ਲਿਖਤ ਕਾਰਨ ਨਾਲ ਹੀ ਜੋੜੋ।

ਜੇ ਤੁਸੀਂ ਦੋ endpoints ਨੂੰ diff ਨਹੀਂ ਕਰ ਸਕਦੇ ਤੇ ਇੱਕੋ ਹੀ ਆਕਾਰ (imports, flow, error handling) ਨਹੀਂ ਵੇਖਦੇ, ਤਾਂ prompt ਕੱਠਾ ਕਰੋ ਅਤੇ merge ਤੋਂ ਪਹਿਲਾਂ ਦੁਬਾਰਾ generate ਕਰੋ।

generated endpoint merge ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਝੱਟ ਚੈਕਲਿਸਟ

ਕਿਸੇ generated ਚੀਜ਼ ਨੂੰ merge ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਹਿਲਾਂ structure ਚੈਕ ਕਰੋ। ਜੇ ਆਕਾਰ ਠੀਕ ਹੈ, ਤਾਂ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਲੋਜਿਕ ਬਗਸ ਨੂੰ ਵੇਖਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।

Structure ਚੈਕ:

• Handler flow consistent ਹੈ: bind input, validate, call service, map domain errors to HTTP, write response।
• Service ਕੋਡ ਵਿੱਚ ਸਿਰਫ਼ business rules ਹਨ: ਕੋਈ HTTP ਜਾਂ JSON ਕੰਮ ਨਹੀਂ।
• Success responses ਤੁਹਾਡੇ ਘਰ-ਸਟਾਈਲ ਨਾਲ ਮਿਲਦੇ ਹਨ (ਹਰ ਜਗ੍ਹਾ shared envelope ਜਾਂ direct JSON)।
• Error responses ਯੂਨੀਫਾਰਮ ਹਨ: ਇੱਕੋ JSON fields, ਇੱਕੋ codes, ਇੱਕੋ request_id ਬਿਹੈਵਿਅਰ।
• Nāmkaran ਅਤੇ placement ਬੋਰਿੰਗ ਲੱਗਦੇ ਹਨ: ਫਾਇਲ ਨਾਂ, ਫੰਕਸ਼ਨ ਨਾਂ, ਅਤੇ ਰੂਟ ਨਾਂ ਮੌਜੂਦਾ endpoints ਨਾਲ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਸਾਰਾ ਕੁਝ gofmt ਕੀਤਾ ਹੋਇਆ ਹੈ।

ਵਹਿਵਾਰ ਚੈਕ:

• ਟੈਸਟ ਚਲਾਓ ਅਤੇ ਨਵੇਂ handler/service branch ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਛੋਟਾ ਟੈਸਟ ਜੋੜੋ।
• ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ validation failures ਉਹੀ ਕੋਡ ਅਤੇ status ਵਾਪਸ ਕਰਦੇ ਹਨ ਜੋ ਮਿਲਦੇ-ਜੁਲਦੇ endpoints ਦੇ ਹਨ।
• ਇੱਕ ਜਾਣਿਆ service error (ਜਿਵੇਂ "not found" ਜਾਂ "conflict") trigger ਕਰੋ ਅਤੇ HTTP status ਅਤੇ JSON shape ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
• copy-paste ਰਹਿਤ ਚੀਜ਼ਾਂ ਲਈ ਸਕੈਨ ਕਰੋ: ਗਲਤ route path, ਗਲਤ log message, mismatched DTO names।
• build ਅਤੇ server ਨੂੰ local 'ਤੇ ਇੱਕ ਵਾਰੀ ਚਲਾਓ ਤਾਂ wiring ਅਤੇ imports ਠੀਕ ਹਨ।

ਅਗਲੇ ਕਦਮ: ਪੈਟਰਨ ਨੂੰ ਸਮਰਥਿਤ ਕਰੋ, ਫਿਰ ਜਨਰੇਸ਼ਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਧਾਓ

ਆਪਣੇ ਪੈਟਰਨ ਨੂੰ ਇੱਕ ਸਾਂਝਾ contract ਸਮਝੋ, ਨਾ ਕਿ ਇੱਕ ਪਸੰਦ। "ਕਿਵੇਂ ਅਸੀਂ ਐਂਡਪੌਇੰਟ ਬਣਾਉਂਦੇ ਹਾਂ" ਦਾ doc ਆਪਣੇ ਕੋਡ ਦੇ ਨੇੜੇ ਰੱਖੋ, ਅਤੇ ਇੱਕ reference endpoint ਜੋ ਪੂਰਾ ਦਿੱਖਾਉਂਦਾ ਹੈ, ਇਕ-ਇੱਕ ਤਬਦੀਲੀ ਵਿੱਚ ਅਪਡੇਟ ਕਰੋ।

ਜਨਰੇਸ਼ਨ ਨੂੰ ਛੋਟੇ ਬੈਚਾਂ ਵਿੱਚ scale ਕਰੋ। 2-3 endpoints(generate) ਕਰੋ ਜੋ ਵੱਖ-ਵੱਖ ਕਿਨਾਰੇ ਨੂੰ ਟੱਚ ਕਰਦੇ ਹਨ (ਸਧਾਰਨ read, create with validation, update with not-found)। ਫਿਰ ਰੁੱਕੋ ਅਤੇ ਸੁਧਾਰ ਕਰੋ। ਜੇ reviews ਵਿੱਚ ਵਾਰ-ਵਾਰ same style drift ਮਿਲਦਾ ਹੈ, ਤਾਂ baseline doc ਅਤੇ reference endpoint ਪਹਿਲਾਂ ਅਪਡੇਟ ਕਰੋ ਫਿਰ ਹੋਰ ਜਨਰੇਟ ਕਰੋ।

ਇੱਕ ਲੂਪ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾਉਂਦੇ ਰਹੋ:

• ਬੇਸਲਾਈਨ ਲਿਖੋ: file names, function names, request/response structs, error codes, ਅਤੇ validation ਕਿੱਥੇ ਹੁੰਦੀ ਹੈ।
• ਇੱਕ endpoint "golden" ਰੱਖੋ, ਅਤੇ ਜਦ pattern ਬਦਲੇ ਤਾਂ ਪਹਿਲਾਂ ਉਸਨੂੰ ਅਪਡੇਟ ਕਰੋ।
• ਕੁਝ endpoints ਬੈਚ-ਜਨਰੇਟ ਕਰੋ, consistency ਲਈ review ਕਰੋ, ਫਿਰ prompt ਅਤੇ pattern doc ਸੁਧਾਰੋ।
• ਪੁਰਾਣੇ endpoints ਨੂੰ ਹਿੱਸਿਆਂ ਵਿੱਚ refactor ਕਰੋ ਅਤੇ rollback path ਰੱਖੋ ਜੇ ਵਿਵਹਾਰ ਬਦਲਦਾ ਹੈ।
• ਇੱਕ ਹਫਤਾ ਲਈ ਇੱਕ ਮੈਟਰਿਕ track ਕਰੋ: endpoint ਜੋੜਨ ਦਾ ਸਮਾਂ, merge ਤੋਂ ਬਾਅਦ bug ਦਰ, ਜਾਂ review ਸਮਾਂ।

ਜੇ ਤੁਸੀਂ tighter build-review loop ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai (koder.ai) ਵਰਗਾ vibe-coding platform ਤੁਹਾਡੇ ਲਈ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ: chat-driven workflow ਵਿੱਚ scaffolding ਤੇ ਤੁਰੰਤ iteration, ਫਿਰ ਜਦ ਉਹ ਤੁਹਾਡੇ ਮਿਆਰ ਨਾਲ ਮਿਲੇ ਤਾਂ source code export ਕਰੋ। ਟੂਲ ਘੱਟ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ—ਨਿਯਮ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ।