CI ব্যর্থতার জন্য Claude Code: ব্যর্থ আউটপুট উদ্ধৃত করতে বলুন, সবচেয়ে ক্ষুদ্র সমাধান সাজেস্ট করুন, এবং পুনরাবৃত্তি রোধের জন্য একটি রিগ্রেশন টেস্ট যোগ করুন।
একটি CI ব্যর্থতা সাধারণত রহস্যময় নয়। লগ বলে দেয় কোথায় থেমে গেছে, কোন কমান্ড ব্যর্থ হয়েছে, এবং এরর মেসেজ কী। একটি ভাল রান-এ স্ট্যাক ট্রেস, একটি কম্পাইলার এরর ফাইল ও লাইন নম্বরসহ, বা কোন assertion কে ব্যর্থ করেছে তা দেখানো টেস্ট রিপোর্ট থাকে। মাঝে মাঝে আপনি ডিফ-স্টাইল ক্লু পান যেমন "expected X, got Y" বা একটি পরিষ্কার ব্যর্থ ধাপ যেমন "lint", "build", বা "migrate database"।
কিন্তু প্রকৃত সমস্যা হল মানুষ (এবং AI) প্রায়ই লগটিকে ব্যাকগ্রাউন্ড শব্দ হিসেবে বিবেচনা করে। যদি আপনি একটি লম্বা লগ পেস্ট করে কেবল "একটি ফিক্স" চাইলে, অনেক মডেল শেষের অর্থবহ লাইনের পড়ার বদলে পরিচিত ব্যাখ্যায় লাফিয়ে পড়ে। যখন এরর সাধারণ দেখায় ("module not found", "timeout", "permission denied") অনুমান আরও খারাপ হয়। ফলে আপনি বড় রিরাইট, একটি নতুন ডিপেনডেন্সি, বা "সবকিছু আপডেট করে দেখুন"–রকম অনুপযোগী সমাধি পেতে পারেন।
লক্ষ্যটি "কিছুভাবে পাস করানো" নয়। এটি সহজ:
বাস্তবে, "সবচেয়ে ছোট ফিক্স" সাধারণত এদের একটিঃ কয়েক লাইনের কোড পরিবর্তন এক জায়গায়, একটি মিসিং ইম্পোর্ট বা ভুল পাথ, CI পরিবেশের জন্য স্পষ্টভাবে ভুল কনফিগ ভ্যালু, বা ডিজাইন না ভেঙে দুর্ঘটনাক্রমে করা একটি পরিবর্তন রিভার্ট করা।
একটি ফলো-আপ টেস্টও গুরুত্বপূর্ণ। একবার CI পাস করে নেওয়ার মানে পুনরাবৃত্তি রোধ করা নয়। যদি ব্যর্থতাটি একটি এজ কেস (null ইনপুট, টাইমজোন, রাউন্ডিং, পারমিশন) থেকে এসেছে, তাহলে এমন একটি রিগ্রেশন টেস্ট যোগ করুন যা ফিক্সের আগে ব্যর্থ হবে এবং পরে পাস করবে। এভাবে এককালীন উদ্ধার একটি গার্ডরেইলে পরিণত হয়।
অধিকাংশ খারাপ ফিক্সই প্রেক্ষাপট শুষ্ক হতে শুরু হয়। আপনি যদি কেবল শেষ লাল লাইন পেস্ট করে দেন, মডেলকে অনুমান করতে হবে আগে কি ঘটেছে, এবং অনুমানগুলো প্রায়ই রিরাইটে পরিণত হয়।
চেষ্টা করুন এত তথ্য দিন যাতে কেউ প্রথম প্রকৃত ত্রুটি থেকে শেষ পর্যন্ত ব্যর্থতা অনুসরণ করতে পারে, তারপর যতটা সম্ভব কম পরিবর্তন করতে পারে।
আপনার মেসেজে এগুলো (সম্ভব হলে শব্দসিদ্ধভাবে) কপি করুনঃ
go test ./..., npm test, flutter test, golangci-lint run)।স্পষ্ট ভাষায় সীমাবদ্ধতা যোগ করুন। আপনি যদি একটি ক্ষুদ্র ফিক্স চান, এটা বলুন: কোন রিফ্যাক্টর নয়, আচরণ পরিবর্তন নয় যদি না অত্যাবশ্যক হয়, প্যাচটিকে ব্যর্থ এলাকায় সীমাবদ্ধ রাখুন।
একটি সহজ উদাহরণ: CI একটি লিন্ট ধাপে ব্যর্থ করে ডিপেনডেন্সি বাম্পের পর। প্রথম সতর্কতার লাইন থেকে লিন্ট আউটপুট পেস্ট করুন, CI যে কমান্ডটি ব্যবহার করেছে সেটি অন্তর্ভুক্ত করুন, এবং একক প্যাকেজ ভার্সন পরিবর্তনটি জানিয়ে দিন। এটিই যথেষ্ট হবে একটি এক লাইনের কনফিগ টুইক বা ছোটো কোড পরিবর্তনের পরামর্শ দিতে, পুরো রিপো রিফরম্যাট করার পরিবর্তে।
যদি আপনি কপি-পেস্ট যোগ্য কিছু চান, এই স্ট্রাকচারটি সাধারণত যথেষ্টঃ
CI command:
Failing output (full):
Recent changes:
Constraints (smallest fix, no refactor):
Flaky? (runs attached):
যখন একটি মডেল CI ব্রেকে ঠিক করে উঠতে ব্যর্থ করে, সাধারণত কারণ আপনার প্রম্পট সেটি অনুমান করতে দেয়। আপনার কাজ হলো মডেলটিকে তার কাজ দেখাতে বাধ্য করা—CI আউটপুট ব্যবহার করে এবং তারপর এমন সবচেয়ে ছোট পরিবর্তন চাওয়া যা কাজটি সফল করবে।
প্রমাণ এবং একটি ছোট পরিকল্পনা দাবি করুন। একটি ভাল প্রম্পট পাঁচটি জিনিস জোর দেয়:
অনিশ্চয়তা ঠিক আছে—এটি গোপন অনিশ্চয়তা সময় নষ্ট করে।
আপনার CI প্রশ্নের শীর্ষে এটি পেস্ট করুন:
Use ONLY the evidence in the CI output below.
1) Quote the exact failing lines you are using.
2) Give ONE sentence: the most likely cause.
3) Propose the smallest fix: 1-3 edits, with file paths.
4) Do NOT do formatting/renames/refactors or "cleanup".
5) List uncertainties + the one extra detail that would confirm the diagnosis.
যদি লগ বলে "expected 200, got 500" এবং একটি স্ট্যাক ট্রেস user_service.go:142 এ থাকে, এই স্ট্রাকচারটি প্রতিক্রিয়াকে সেই ফাংশনের দিকে ঠেলে দেবে এবং একটি ছোট গার্ড বা এরর হ্যান্ডলিং পরিবর্তনের প্রস্তাব করবে, ডিজাইনের পুনর্নির্মাণ নয়।
দ্রুত বিজয়গুলো আসে এমন একটি প্রম্পট থেকে যা লগ উদ্ধৃতি বাধ্য করে, সীমাবদ্ধতার মধ্যে থাকে, এবং অনুপস্থিত হলে থেমে যায়।
You are helping me fix a CI failure.
Repo context (short):
- Language/framework:
- Test/build command that failed: <PASTE THE EXACT COMMAND>
- CI environment (OS, Node/Go/Python versions, etc.):
Failing output (verbatim, include the first error and 20 lines above it):
<PASTE LOG>
Constraints:
- Propose the smallest possible code change that makes CI pass.
- Do NOT rewrite/refactor unrelated code.
- Do NOT touch files you do not need for the fix.
- If behavior changes, make it explicit and justify why it is correct.
Stop rule (no guessing):
- If the log is incomplete or you need more info (missing stack trace, config, versions, failing test name), STOP and ask only the minimum questions needed.
Your response format (follow exactly):
1) Evidence: Quote the exact log lines that matter.
2) Hypothesis: Explain the most likely cause in 2-4 sentences.
3) Smallest fix: Describe the minimal change and why it addresses the evidence.
4) Patch: Provide a unified diff.
5) Follow-up: Tell me the exact command(s) to rerun locally to confirm.
Then, write ONE regression test (or tweak an existing one) that would fail before this fix and pass after it, to prevent the same failure class.
- Keep the test focused. No broad test suites.
- If a test is not feasible, explain why and propose the next-best guardrail (lint rule, type check, assertion).
দুইটি বিস্তারিত যা ব্যাক-ফোর্থ কমায়:
দ্রুত সময় বরবার হারানোর সবচেয়ে সহজ উপায় হল একটি "ক্লিনআপ" পরিবর্তন মেনে নেওয়া যা একসাথে পাঁচটি জিনিস বদলে দেয়। আগেই "ক্ষুদ্র" সংজ্ঞা দিন: ব্যর্থ কাজটি সফল করার সর্বনিম্ন ডিফ, সর্বনিম্ন ঝুঁকি এবং দ্রুত যাচাইয়ের পথ।
একটি সহজ নিয়ম কাজ করে: লক্ষণ প্রথমে ঠিক করুন, তারপর সিদ্ধান্ত নিন যে বড় রিফ্যাক্টর দরকার কি না। লগ যদি এক ফাইল, এক ফাংশন, এক মিসিং ইম্পোর্ট বা এক এজ কেস ইঙ্গিত করে, সেইদিকে যান। "এখানেই থাকাকালীন" পরিবর্তনগুলো এড়িয়ে চলুন।
যদি বিকল্প সত্যিই দরকার হয়, দুটোই চান: "সবচেয়ে নিরাপদ ক্ষুদ্র ফিক্স" বনাম "সবচেয়ে দ্রুত ক্ষুদ্র ফিক্স" — দুটোই শুধুই রাখুন। আপনি ট্রেডঅফ চান, মেনু নয়।
আরেকটি নিয়ম: লোকাল যাচাইয়ের জন্য CI যে একই কমান্ড চালায় সেটি চাইুন (বা কাছাকাছি) যাতে আপনি মিনিটের মধ্যে কনফার্ম করতে পারেন।
# run the same unit test target CI runs
make test
# or the exact script used in CI
npm test
যদি প্রতিক্রিয়া একটি বড় পরিবর্তন প্রস্তাব করে, চাপ দিন: “দেখান সবচেয়ে ছোট প্যাচ যা ব্যর্থ assertion ঠিক করে, কোনো অপ্রাসঙ্গিক ফরম্যাটিং বা রিনেম ছাড়া।”
একটা ফিক্স টেস্ট ছাড়া করা মানে আপনি বাজি ধরছেন যে একই সমস্যা আর হবে না। সবসময় একটি ফলো-আপ টেস্ট চাইুন যা ফিক্সের আগে ব্যর্থ হবে এবং পরে পাস করবে।
ভালো দেখার মানদণ্ড নির্দিষ্ট করুন:
একটি কার্যকর প্যাটার্ন: টেস্ট কোথায় রাখতে হবে, কী নাম দেবেন, কী আচরণ কভার করবে, এবং ২–৩ বাক্যে কেন এটি ভবিষ্যতে একই বাগ আটকাবে—এই চারটি বস্তু দাবি করুন।
কপি-রেডি যোগান:
উদাহরণ: CI-তে একটি প্যানিক দেখায় যখন একটি API হ্যান্ডলার একটি খালি স্ট্রিং ID পায়। শুধু “এই লাইনের জন্য টেস্ট” না চাইবেন; একটি টেস্ট চাইবেন যা অবৈধ ID (খালি, whitespace, ভুল ফরম্যাট) কভার করে। সবচেয়ে ছোট ফিক্স হয় একটি গার্ড ক্লজ যা 400 রেসপন্স দেয়। ফলো-আপ টেস্টটি একাধিক অবৈধ ইনপুটের জন্য আচরণ assert করবে, তাই ভবিষ্যতে কেউ পার্সিং রিফ্যাক্টর করলে CI তৎক্ষণাৎ ভেঙে পড়বে।
আপনার প্রোজেক্টে যদি টেস্ট কনভেনশন থাকে, সেগুলো বলুন। না থাকলে, নিকটস্থ টেস্টগুলোর মতো করে নতুন টেস্ট রাখুন—সহজ ও পাঠযোগ্য।
ফার্স্ট 20-40 লাইন লগসহ ত্রুটিটি পেস্ট করুন। একই সাথে CI যে সঠিক কমান্ড চালিয়েছে এবং গুরুত্বপূর্ণ পরিবেশ বিবরণ (OS, রানটাইম ভার্সন, গুরুত্বপূর্ণ ফ্ল্যাগ) দিন।
তারপর বলুন মডেলটি ব্যর্থতা সহজ ইংরেজিতে পুনর্বক্ত করুক এবং আউটপুটের সেই লাইনে টোকা দিন যা প্রমাণ করে। যদি তা লগ উদ্ধৃতি করতে না পারে, তাহলে এটা পড়েনি।
ব্যর্থ কমান্ড পাস করার জন্য সবচেয়ে ছোট কোড পরিবর্তন চাওয়া। রিফ্যাক্টরের বিরুদ্ধে চাপ দিন। প্রয়োগের আগে মডেলকে তালিকা করতে বলুন:
প্যাচ প্রয়োগ করে সঠিক ব্যর্থ কমান্ড লোকালেও চালান (বা একই CI জবে)। যদি এখনও ব্যর্থ হয়, কেবল নতুন ব্যর্থ আউটপুট পেস্ট করুন এবং পুনরাবৃত্তি করুন। ছোট কনটেক্সট প্রতিক্রিয়াকে ফোকাস রাখে।
একবার সব সবুজ হলে, একটি ফলো-আপ টেস্ট যোগ করুন যা ফিক্সের আগে ব্যর্থ এবং পরে পাস করে। লক্ষ্যমাত্রা: এক টেস্ট, এক কারণ।
নতুন টেস্টসহ আবার একই কমান্ড চালান নিশ্চিত করার জন্য যাতে আপনি কেবল ত্রুটিটি স্তিমিত করেননি।
ছোট একটি কমিট মেসেজ ও PR ডিসক্রিপশন চাওয়া: কি ব্যর্থ করেছিল, কি বদলেছে, কিভাবে যাচাই করেছেন, এবং কোন টেস্টটি পুনরাবৃত্তি প্রতিরোধ করবে। রিভিউয়াররা দ্রুত এগোতে চাইলে কারণ স্পষ্ট থাকলে সুবিধা হয়।
সাধারণ একটি ব্যর্থতা: লোকালেই সব কাজ করছিল, পরে একটি ছোট পরিবর্তন CI-তে টেস্ট ভাঙে। এখানে একটি সরল উদাহরণ Go API-র যেখানে একটি হ্যান্ডলার এখন শুধু তারিখ-মাত্রা (2026-01-09) গ্রহণ করছে কিন্তু কোড এখনও সম্পূর্ণ RFC3339 টাইমস্ট্যাম্প পার্স করে।
এটি এমন একটি স্নিপেট যা পেস্ট করা উচিত (ছোট রাখুন, কিন্তু এরর লাইনটি রাখুন):
--- FAIL: TestCreateInvoice_DueDate (0.01s)
invoice_test.go:48: expected 201, got 400
invoice_test.go:49: response: {"error":"invalid due_date: parsing time \"2026-01-09\" as \"2006-01-02T15:04:05Z07:00\": cannot parse \"\" as \"T\""}
FAIL
exit status 1
FAIL app/api 0.243s
এখন এমন একটি প্রম্পট ব্যবহার করুন যা প্রমাণ বাধ্য করে, একটি ক্ষুদ্র ফিক্স, এবং একটি টেস্ট দাবী করে:
You are fixing a CI failure. You MUST use the log to justify every claim.
Context:
- Language: Go
- Failing test: TestCreateInvoice_DueDate
- Log snippet:
<PASTE LOG>
Task:
1) Quote the exact failing line(s) from the log and explain the root cause in 1-2 sentences.
2) Propose the smallest possible code change (one function, one file) to accept both RFC3339 and YYYY-MM-DD.
3) Show the exact patch.
4) Add one regression test that fails before the fix and passes after.
Return your answer with headings: Evidence, Minimal Fix, Patch, Regression Test.
একটি ভালো উত্তর পার্সিং লেআউটের মিল-অমিল নির্দেশ করবে, তারপর একটি ছোট পরিবর্তন করবে (উদাহরণ: parseDueDate invoice.go-তে) যা RFC3339 প্রথমে ট্রাই করে যদি না হয় তাহলে 2006-01-02 লেআউট fallback করে। কোন রিফ্যাক্টর নয়, কোনো নতুন প্যাকেজ নয়।
রিগ্রেশন টেস্টই হচ্ছে গার্ডরেইল: due_date: "2026-01-09" পাঠিয়ে 201 আশা করুন। ভবিষ্যতে কেউ পার্সিং ফলো-আপ মুছলে CI আবার ভাঙবে।
খুব সংকুচিত ভিউ দেওয়া দ্রুত একটি ঘণ্টা নষ্ট করার সহজ উপায়। CI লগ শব্দপূর্ন, কিন্তু কার্যকর অংশ প্রায়ই শেষের 20 লাইনের উপরে থাকে।
একটি ফাঁদ হল কেবল শেষ লাল লাইন (যেমন "exit 1") পেস্ট করা যখন প্রকৃত কারণ আগেই আছে (মিসিং ENV var, ফেলিং স্ন্যাপশট, প্রথম ক্র্যাশ করা টেস্ট)। সমাধান: প্রথম ত্রুটি লাইনের সাথে সেই উইন্ডো দিন।
অন্যটি হল মডেলকে "টিডি আপ" করতে দেওয়া—অতিরিক্ত ফরম্যাটিং, ডিপেনডেন্সি বাম্প, বা রিফ্যাক্টরিং পর্যালোচনা কঠিন করে তোলে ও অন্য কিছু ভাঙাতে পারে। সমাধান: স্কোপ লক করুন।
কিছু প্যাটার্ন লক্ষ্য করুন:
যদি আপনি ফ্লাকি সন্দেহ করেন, রিট্রাই দিয়ে ঢাকা দেবেন না; অ-নির্ধারিততা সরান (স্থির সময়, সিড করা RNG, আইসোলেটেড টেম্প ডির) যাতে সিগনাল পরিষ্কার হয়।
পুশ করার আগে এক সংক্ষিপ্ত সমীক্ষা করুন। লক্ষ্য: পরিবর্তনটি বাস্তব, ক্ষুদ্র এবং পুনরাবৃত্তিযোগ্য তা নিশ্চিত করা।
শেষে, মূল ব্যর্থ জব ছাড়াও একটু বড় সেট রান করুন (উদাহরণ: লিন্ট + ইউনিট টেস্ট) কারণ একটা টার্গেট পাস করালেই অন্যটি ভেঙে যেতে পারে।
আপনি যদি চান এটি সপ্তাহে সপ্তাহে সময় বাঁচাক, আপনার প্রম্পট ও প্রতিক্রিয়া স্ট্রাকচারটিকে টিম প্রসেস হিসেবে ব্যবহার করুন। লক্ষ্য: পুনরাবৃত্ত ইনপুট, পুনরাবৃত্ত আউটপুট, এবং কম 'রহস্যময় ফিক্স' যা আর কিছু ভাঙায় না।
আপনার সেরা প্রম্পটটি একটি রেপো স্নিপেটে সংরক্ষণ করুন এবং টিম চ্যাটে পিন করে দিন। প্রক্রিয়াটি সারিতে রাখুন: লেবেল CI ব্যর্থতাগুলো (lint, unit, integration, packaging, deploy) এবং যখন কোনো লেবেল বারবার আসে, একটি টেস্ট বা চেক যোগ করুন যা আগে থেকে ধরত।
যদি আপনি চ্যাট-ফার্স্ট ওয়ার্কফ্লো পছন্দ করেন, একই ফিক্স-এবং-টেস্ট লুপ Koder.ai-তে চালাতে পারেন, পরীক্ষামূলক স্ন্যাপশট ব্যবহার করে এবং প্রস্তুত হলে সোর্স এক্সপোর্ট করে মূল রিপোতে মার্জ করতে পারেন।
প্রথমে প্রকৃত প্রথম ত্রুটিটি থেকে শুরু করুন, শেষের exit 1 থেকে নয়।
একে প্রমাণ করতে বলুন যে এটি লগটি পড়েছে।
নিম্নলিখিত সীমাবদ্ধতা ব্যবহার করুন:
ডিফল্টভাবে এমন ছোটতম প্যাচ নিন যা ব্যর্থ ধাপটিকে সফল করে তুলবে।
সাধারণত এটির মানে:
CI সবুজ না হওয়া পর্যন্ত “ক্লিনআপ” পরিবর্তন এড়িয়ে চলুন।
ব্যর্থতা পুনরায় তৈরি করার জন্য পর্যাপ্ত কনটেক্সট পেস্ট করুন—শুধু শেষ লাল লাইন নয়।
শামিল করুন:
go test ./..., npm test, flutter test ইত্যাদি)।হ্যাঁ—সীমানা স্পষ্টভাবে লেখা রাখা দরকার। উদাহরণ সীমাবদ্ধতা:
এটি প্রতিক্রিয়াকে ফোকাস রাখে এবং দ্রুত পর্যালোচনাযোগ্য করে।
প্রথম প্রকৃত ত্রুটিটিকে প্রথমে ঠিক করুন।
শঙ্কা হলে, মডেলকে লগ থেকে প্রথম ব্যর্থ ধাপ চিহ্নিত করতে বলুন এবং সেটিই ধরে এগোন।
ফ্লাকিনেসকে রিট্রাই দিয়ে ঢেকে রাখবেন না—অদৃশ্যতা কমান।
সাধারণ স্থিতিশীলকরণ:
পরে ডিটারমিনিস্টিক হলে “সবচেয়ে ক্ষুদ্র ফিক্স” পরিষ্কার হবে।
CI যে কমান্ড চালায় সেটি জিজ্ঞাসা করুন, তারপর সেটিই লোকালেও চালান।
লোকাল পুনরুত্পাদন কঠিন হলে, রিপোতে একটি মিনিমাল রেপ্রো জিজ্ঞাসা করুন (একটি টেস্ট বা টার্গেট) যা একই ত্রুটি ট্রিগার করে।
ফিক্সের পরে একটি ফোকাসড রিগ্রেশন টেস্ট লিখুন যা ফিক্সের আগে ব্যর্থ হবে এবং পরে পাস করবে।
ভালো টার্গেট:
যদি এটি লিন্ট/বিল্ড ত্রুটি হয়, সমতুল্য “টেস্ট” হতে পারে একটি লিন্ট রুল কড়া করা বা একটি চেক যোগ করা।
একই দিক থেকে দ্রুত পুনরাবৃত্তি করুন কিন্তু রেপোকে বিশৃঙ্খল না করতে স্ন্যাপশট/রোলব্যাক ব্যবহার করুন।
একটি ব্যবহারিক লুপ:
Koder.ai-তে কাজ করলে স্ন্যাপশট দ্রুত পরীক্ষা করতে এবং পরীক্ষামূলক এডিটগুলো আলাদা রাখতে সাহায্য করে।