CI ব্যর্থতার জন্য Claude Code: ক্ষুদ্র সমাধান ও রিগ্রেশন টেস্টের প্রম্পট

CI ব্যর্থতা ঘটলে কী ভুল হয় এবং AI অনুমান করলে কি হয়

একটি CI ব্যর্থতা সাধারণত রহস্যময় নয়। লগ বলে দেয় কোথায় থেমে গেছে, কোন কমান্ড ব্যর্থ হয়েছে, এবং এরর মেসেজ কী। একটি ভাল রান-এ স্ট্যাক ট্রেস, একটি কম্পাইলার এরর ফাইল ও লাইন নম্বরসহ, বা কোন assertion কে ব্যর্থ করেছে তা দেখানো টেস্ট রিপোর্ট থাকে। মাঝে মাঝে আপনি ডিফ-স্টাইল ক্লু পান যেমন "expected X, got Y" বা একটি পরিষ্কার ব্যর্থ ধাপ যেমন "lint", "build", বা "migrate database"।

কিন্তু প্রকৃত সমস্যা হল মানুষ (এবং AI) প্রায়ই লগটিকে ব্যাকগ্রাউন্ড শব্দ হিসেবে বিবেচনা করে। যদি আপনি একটি লম্বা লগ পেস্ট করে কেবল "একটি ফিক্স" চাইলে, অনেক মডেল শেষের অর্থবহ লাইনের পড়ার বদলে পরিচিত ব্যাখ্যায় লাফিয়ে পড়ে। যখন এরর সাধারণ দেখায় ("module not found", "timeout", "permission denied") অনুমান আরও খারাপ হয়। ফলে আপনি বড় রিরাইট, একটি নতুন ডিপেনডেন্সি, বা "সবকিছু আপডেট করে দেখুন"–রকম অনুপযোগী সমাধি পেতে পারেন।

লক্ষ্যটি "কিছুভাবে পাস করানো" নয়। এটি সহজ:

• ব্যর্থ আউটপুট পড়ুন।
• সবচেয়ে ছোট পরিবর্তন নির্ধারণ করুন যা ব্যর্থ ধাপকে সফল করবে।
• বাকি সব একই রাখুন।

বাস্তবে, "সবচেয়ে ছোট ফিক্স" সাধারণত এদের একটিঃ কয়েক লাইনের কোড পরিবর্তন এক জায়গায়, একটি মিসিং ইম্পোর্ট বা ভুল পাথ, CI পরিবেশের জন্য স্পষ্টভাবে ভুল কনফিগ ভ্যালু, বা ডিজাইন না ভেঙে দুর্ঘটনাক্রমে করা একটি পরিবর্তন রিভার্ট করা।

একটি ফলো-আপ টেস্টও গুরুত্বপূর্ণ। একবার CI পাস করে নেওয়ার মানে পুনরাবৃত্তি রোধ করা নয়। যদি ব্যর্থতাটি একটি এজ কেস (null ইনপুট, টাইমজোন, রাউন্ডিং, পারমিশন) থেকে এসেছে, তাহলে এমন একটি রিগ্রেশন টেস্ট যোগ করুন যা ফিক্সের আগে ব্যর্থ হবে এবং পরে পাস করবে। এভাবে এককালীন উদ্ধার একটি গার্ডরেইলে পরিণত হয়।

সাহায্য চাইবার আগে কি জোগাড় করবেন

অধিকাংশ খারাপ ফিক্সই প্রেক্ষাপট শুষ্ক হতে শুরু হয়। আপনি যদি কেবল শেষ লাল লাইন পেস্ট করে দেন, মডেলকে অনুমান করতে হবে আগে কি ঘটেছে, এবং অনুমানগুলো প্রায়ই রিরাইটে পরিণত হয়।

চেষ্টা করুন এত তথ্য দিন যাতে কেউ প্রথম প্রকৃত ত্রুটি থেকে শেষ পর্যন্ত ব্যর্থতা অনুসরণ করতে পারে, তারপর যতটা সম্ভব কম পরিবর্তন করতে পারে।

আপনার মেসেজে এগুলো (সম্ভব হলে শব্দসিদ্ধভাবে) কপি করুনঃ

• প্রথম ত্রুটি লাইনের থেকে শেষ পর্যন্ত সম্পূর্ণ ব্যর্থ লগ (শুধু ফাইনাল স্ট্যাক ট্রেস নয়)।
• CI যে নির্দিষ্ট কমান্ড চালিয়েছে (উদাহরণ: go test ./..., npm test, flutter test, golangci-lint run)।
• এররে উল্লেখিত ফাইলপাথগুলো এবং প্রাসঙ্গিক কনফিগ (টেস্ট কনফিগ, লিন্টার কনফিগ, বিল্ড স্ক্রিপ্ট)।
• সাম্প্রতিক কি পরিবর্তন হয়েছে: PR ডিফ সারসংক্ষেপ, ডিপেনডেন্সি আপডেট, CI কনফিগ এডিট।
• এটি কি ফ্লাকি: যদি আপনার কাছে দুটো-তিনটি ফেলিং রান এবং একটি পাসিং রান থাকে।

স্পষ্ট ভাষায় সীমাবদ্ধতা যোগ করুন। আপনি যদি একটি ক্ষুদ্র ফিক্স চান, এটা বলুন: কোন রিফ্যাক্টর নয়, আচরণ পরিবর্তন নয় যদি না অত্যাবশ্যক হয়, প্যাচটিকে ব্যর্থ এলাকায় সীমাবদ্ধ রাখুন।

একটি সহজ উদাহরণ: CI একটি লিন্ট ধাপে ব্যর্থ করে ডিপেনডেন্সি বাম্পের পর। প্রথম সতর্কতার লাইন থেকে লিন্ট আউটপুট পেস্ট করুন, CI যে কমান্ডটি ব্যবহার করেছে সেটি অন্তর্ভুক্ত করুন, এবং একক প্যাকেজ ভার্সন পরিবর্তনটি জানিয়ে দিন। এটিই যথেষ্ট হবে একটি এক লাইনের কনফিগ টুইক বা ছোটো কোড পরিবর্তনের পরামর্শ দিতে, পুরো রিপো রিফরম্যাট করার পরিবর্তে।

যদি আপনি কপি-পেস্ট যোগ্য কিছু চান, এই স্ট্রাকচারটি সাধারণত যথেষ্টঃ

CI command:

Failing output (full):

Recent changes:

Constraints (smallest fix, no refactor):

Flaky? (runs attached):

মডেলকে ব্যর্থ আউটপুট পড়তে বাধ্য করার প্রম্পট নিয়ম

যখন একটি মডেল CI ব্রেকে ঠিক করে উঠতে ব্যর্থ করে, সাধারণত কারণ আপনার প্রম্পট সেটি অনুমান করতে দেয়। আপনার কাজ হলো মডেলটিকে তার কাজ দেখাতে বাধ্য করা—CI আউটপুট ব্যবহার করে এবং তারপর এমন সবচেয়ে ছোট পরিবর্তন চাওয়া যা কাজটি সফল করবে।

মডেলকে সততা বজায় রাখতে বলার নিয়ম

প্রমাণ এবং একটি ছোট পরিকল্পনা দাবি করুন। একটি ভাল প্রম্পট পাঁচটি জিনিস জোর দেয়:

• CI লগ থেকে সঠিক ব্যর্থ লাইনে উদ্ধৃতি দিন (এরর, স্ট্যাক ট্রেস, file:line) এবং স্পষ্টভাবে বলুন “আমি এই লাইনের উপর কাজ করছি।”
• এক বাক্যে ব্যাখ্যা দিন, সন্দেহভাজন ছাড়া।
• 1–3টি এডিট সহ একটি মিনি প্যাচ প্ল্যান প্রস্তাব করুন, নির্দিষ্ট করে কোন ফাইল টাচ করবে।
• অপ্রাসঙ্গিক পরিবর্তনগুলি এড়ান (কোন ফরম্যাটিং, রিনেম, রিফ্যাক্টর, ডিপেনডেন্সি বাম্প) যদি না আপনি অনুমোদন করেন।
• কী সম্পর্কে অনিশ্চয় সেটা তালিকা করুন এবং একক তথ্য যা নিশ্চিত করবে সেই অনুমান।

অনিশ্চয়তা ঠিক আছে—এটি গোপন অনিশ্চয়তা সময় নষ্ট করে।

কপি-রেডি প্রম্পট ফ্র্যাগমেন্ট

আপনার 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 এ থাকে, এই স্ট্রাকচারটি প্রতিক্রিয়াকে সেই ফাংশনের দিকে ঠেলে দেবে এবং একটি ছোট গার্ড বা এরর হ্যান্ডলিং পরিবর্তনের প্রস্তাব করবে, ডিজাইনের পুনর্নির্মাণ নয়।

CI ব্যর্থতার জন্য একটি কপি-পেস্ট প্রম্পট টেমপ্লেট

দ্রুত বিজয়গুলো আসে এমন একটি প্রম্পট থেকে যা লগ উদ্ধৃতি বাধ্য করে, সীমাবদ্ধতার মধ্যে থাকে, এবং অনুপস্থিত হলে থেমে যায়।

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 ঠিক করে, কোনো অপ্রাসঙ্গিক ফরম্যাটিং বা রিনেম ছাড়া।”

পুনরাবৃত্তি রোধকারী ফলো-আপ টেস্টের জন্য প্রম্পট

একটা ফিক্স টেস্ট ছাড়া করা মানে আপনি বাজি ধরছেন যে একই সমস্যা আর হবে না। সবসময় একটি ফলো-আপ টেস্ট চাইুন যা ফিক্সের আগে ব্যর্থ হবে এবং পরে পাস করবে।

ভালো দেখার মানদণ্ড নির্দিষ্ট করুন:

• যদি ব্যর্থতা একটি ইউনিট টেস্ট ক্র্যাশ হয়, নতুন টেস্ট বা শক্ত অ্যাসারশন প্রয়োজন।
• যদি ব্যর্থতা বিল্ড, লিন্ট, বা ফরম্যাটিং নিয়ম হয়, একটি চেক চাইুন যা সেই নিয়মটি জোরদার করে।

একটি কার্যকর প্যাটার্ন: টেস্ট কোথায় রাখতে হবে, কী নাম দেবেন, কী আচরণ কভার করবে, এবং ২–৩ বাক্যে কেন এটি ভবিষ্যতে একই বাগ আটকাবে—এই চারটি বস্তু দাবি করুন।

কপি-রেডি যোগান:

• একটি রিগ্রেশন টেস্ট লিখুন যা বর্তমান main ব্রাঞ্চে ফেল করবে এবং আপনার ফিক্সের পরে পাস করবে।
• পরীক্ষাটি একই ব্যর্থতার ক্লাসকে টার্গেট করবে, শুধু ভাঙা লাইনের প্রতি নির্ভর করবে না।
• টেস্ট রাখুন: <path or folder>। নামকরণ পালন করুন: <your convention>।
• যদি এটি একটি লিন্ট/বিল্ড নিয়ম হয়, একটি চেক যোগ করুন বা রুল কড়া করুন।
• 2-3 বাক্যে ব্যাখ্যা করুন কেন এই টেস্ট ভবিষ্যতে একই বাগ ধরবে।

উদাহরণ: CI-তে একটি প্যানিক দেখায় যখন একটি API হ্যান্ডলার একটি খালি স্ট্রিং ID পায়। শুধু “এই লাইনের জন্য টেস্ট” না চাইবেন; একটি টেস্ট চাইবেন যা অবৈধ ID (খালি, whitespace, ভুল ফরম্যাট) কভার করে। সবচেয়ে ছোট ফিক্স হয় একটি গার্ড ক্লজ যা 400 রেসপন্স দেয়। ফলো-আপ টেস্টটি একাধিক অবৈধ ইনপুটের জন্য আচরণ assert করবে, তাই ভবিষ্যতে কেউ পার্সিং রিফ্যাক্টর করলে CI তৎক্ষণাৎ ভেঙে পড়বে।

আপনার প্রোজেক্টে যদি টেস্ট কনভেনশন থাকে, সেগুলো বলুন। না থাকলে, নিকটস্থ টেস্টগুলোর মতো করে নতুন টেস্ট রাখুন—সহজ ও পাঠযোগ্য।

পুনরায় ব্যবহারযোগ্য ধাপে ধাপে ওয়ার্কফ্লো

1) ব্যর্থতা যেমন আছে তেমন দিন

ফার্স্ট 20-40 লাইন লগসহ ত্রুটিটি পেস্ট করুন। একই সাথে CI যে সঠিক কমান্ড চালিয়েছে এবং গুরুত্বপূর্ণ পরিবেশ বিবরণ (OS, রানটাইম ভার্সন, গুরুত্বপূর্ণ ফ্ল্যাগ) দিন।

তারপর বলুন মডেলটি ব্যর্থতা সহজ ইংরেজিতে পুনর্বক্ত করুক এবং আউটপুটের সেই লাইনে টোকা দিন যা প্রমাণ করে। যদি তা লগ উদ্ধৃতি করতে না পারে, তাহলে এটা পড়েনি।

2) সবচেয়ে ছোট প্যাচটি দাবী করুন

ব্যর্থ কমান্ড পাস করার জন্য সবচেয়ে ছোট কোড পরিবর্তন চাওয়া। রিফ্যাক্টরের বিরুদ্ধে চাপ দিন। প্রয়োগের আগে মডেলকে তালিকা করতে বলুন:

• কোন ফাইল(গুলি) স্পর্শ করবে
• কোন আচরণ পরিবর্তিত হবে (নির্দিষ্টভাবে)
• কী কিছু পরিবর্তন করা হবে না

3) একই কমান্ড আবার চালান, লুপটি টাইট রাখুন

প্যাচ প্রয়োগ করে সঠিক ব্যর্থ কমান্ড লোকালেও চালান (বা একই CI জবে)। যদি এখনও ব্যর্থ হয়, কেবল নতুন ব্যর্থ আউটপুট পেস্ট করুন এবং পুনরাবৃত্তি করুন। ছোট কনটেক্সট প্রতিক্রিয়াকে ফোকাস রাখে।

4) ব্যর্থতার ক্লাসের জন্য একটি রিগ্রেশন টেস্ট যোগ করুন

একবার সব সবুজ হলে, একটি ফলো-আপ টেস্ট যোগ করুন যা ফিক্সের আগে ব্যর্থ এবং পরে পাস করে। লক্ষ্যমাত্রা: এক টেস্ট, এক কারণ।

নতুন টেস্টসহ আবার একই কমান্ড চালান নিশ্চিত করার জন্য যাতে আপনি কেবল ত্রুটিটি স্তিমিত করেননি।

5) একটি পরিষ্কার PR প্যাকেট দিয়ে শেষ করুন

ছোট একটি কমিট মেসেজ ও 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, ফেলিং স্ন্যাপশট, প্রথম ক্র্যাশ করা টেস্ট)। সমাধান: প্রথম ত্রুটি লাইনের সাথে সেই উইন্ডো দিন।

অন্যটি হল মডেলকে "টিডি আপ" করতে দেওয়া—অতিরিক্ত ফরম্যাটিং, ডিপেনডেন্সি বাম্প, বা রিফ্যাক্টরিং পর্যালোচনা কঠিন করে তোলে ও অন্য কিছু ভাঙাতে পারে। সমাধান: স্কোপ লক করুন।

কিছু প্যাটার্ন লক্ষ্য করুন:

• কেবল শেষ এরর লাইন পেস্ট করা: প্রথম ত্রুটি ও ব্যর্থ কমান্ড অন্তর্ভুক্ত করুন।
• এটি অনুমোদন করা যে ডিপ/ফাইল পরিবর্তন করবে: প্রতিটি স্পর্শ করা ফাইলের কারণ দাবি করুন।
• CI কমান্ডের বিরুদ্ধে যাচাই না করা: একই কমান্ড চালান ও কনফার্ম করুন।
• এমন টেস্ট লেখা যা বাগ ফিরলে আবারও পাস করে: টেস্টটি পুরানো কোডে ফেলবে এবং নতুন কোডে পাস করবে এমন শর্ত চাইুন।
• ফ্লাকি টেস্ট মিশানো: ডিসকর্ড করুন এটি কি টাইমিং/নেটওয়ার্ক জনিত নাকি স্থায়ী লজিক ইস্যু, তারপর উপযুক্ত ব্যবস্থ গ্রহণ করুন।

যদি আপনি ফ্লাকি সন্দেহ করেন, রিট্রাই দিয়ে ঢাকা দেবেন না; অ-নির্ধারিততা সরান (স্থির সময়, সিড করা RNG, আইসোলেটেড টেম্প ডির) যাতে সিগনাল পরিষ্কার হয়।

পুশ করার আগে দ্রুত চেকলিস্ট

পুশ করার আগে এক সংক্ষিপ্ত সমীক্ষা করুন। লক্ষ্য: পরিবর্তনটি বাস্তব, ক্ষুদ্র এবং পুনরাবৃত্তিযোগ্য তা নিশ্চিত করা।

• প্রমাণ: ব্যাখ্যাটি কি সঠিক ব্যর্থ লাইনে উদ্ধৃতি দেয়?
• স্কোপ: পরিবর্তনগুলো কেবল প্রয়োজনীয় কি?
• কারণতা: কেন এই পরিবর্তনটি ব্যর্থকে পাসে বদলে দেয় তা বোঝায় কি?
• পুনরুত্পাদন: একই CI কমান্ড লোকালেও চালিয়েছেন কি?
• রিগ্রেশন: নতুন টেস্ট ফিক্সের আগে ফেলেছে এবং পরে পাস করে কি?

শেষে, মূল ব্যর্থ জব ছাড়াও একটু বড় সেট রান করুন (উদাহরণ: লিন্ট + ইউনিট টেস্ট) কারণ একটা টার্গেট পাস করালেই অন্যটি ভেঙে যেতে পারে।

পরবর্তী ধাপ: এই ওয়ার্কফ্লোকে অভ্যাস করুন

আপনি যদি চান এটি সপ্তাহে সপ্তাহে সময় বাঁচাক, আপনার প্রম্পট ও প্রতিক্রিয়া স্ট্রাকচারটিকে টিম প্রসেস হিসেবে ব্যবহার করুন। লক্ষ্য: পুনরাবৃত্ত ইনপুট, পুনরাবৃত্ত আউটপুট, এবং কম 'রহস্যময় ফিক্স' যা আর কিছু ভাঙায় না।

আপনার সেরা প্রম্পটটি একটি রেপো স্নিপেটে সংরক্ষণ করুন এবং টিম চ্যাটে পিন করে দিন। প্রক্রিয়াটি সারিতে রাখুন: লেবেল CI ব্যর্থতাগুলো (lint, unit, integration, packaging, deploy) এবং যখন কোনো লেবেল বারবার আসে, একটি টেস্ট বা চেক যোগ করুন যা আগে থেকে ধরত।

যদি আপনি চ্যাট-ফার্স্ট ওয়ার্কফ্লো পছন্দ করেন, একই ফিক্স-এবং-টেস্ট লুপ Koder.ai-তে চালাতে পারেন, পরীক্ষামূলক স্ন্যাপশট ব্যবহার করে এবং প্রস্তুত হলে সোর্স এক্সপোর্ট করে মূল রিপোতে মার্জ করতে পারেন।