এজেন্টের কোন pull request gate merge আটকাবে?

একটি এজেন্ট পরিচ্ছন্ন diff, বিশ্বাসযোগ্য বর্ণনা এবং দ্রুত review পেরোনো কোড তৈরি করেও অ্যাপকে ঝুঁকিতে বা পুনরুদ্ধারের অযোগ্য অবস্থায় রেখে যেতে পারে। তাই merge করার সিদ্ধান্ত এজেন্ট কত আত্মবিশ্বাসী বা patch কত ছোট তার ওপর নয়, repository যে প্রমাণ মাপতে পারে তার ওপর নির্ভর করা উচিত।

আমি সাতটি বাধ্যতামূলক gate ব্যবহার করি: test, CodeQL, dependency review, secret scanning, authorization check, migration rehearsal এবং rollback verification। প্রতিটি আলাদা ব্যর্থতার প্রশ্নের উত্তর দেয়। সব test সবুজ হলেও নতুন package নিরাপদ প্রমাণ হয় না, আর static analysis পরিষ্কার হলেও ব্যস্ততম table migration-এর সময় lock হবে কি না তা জানা যায় না।

এই gate মানুষ ও এজেন্ট উভয়ের পরিবর্তনে প্রযোজ্য। এজেন্ট ভুলের পরিমাণ, গতি ও ধরন বদলায়, কিন্তু দুর্বল আলাদা পথের যুক্তি দেয় না। অন্য pull request-এর মতো একই প্রমাণ দিতে না পারলে পরিবর্তনটি merge-এর জন্য প্রস্তুত নয়।

Gate পরামর্শ নয়, প্রমাণ দেবে

Merge gate-কে protected branch-এ যাওয়া নির্দিষ্ট commit-এর জন্য পুনরুৎপাদনযোগ্য pass বা fail দিতে হবে। “এই dependency review করুন” লেখা comment পরামর্শ। Package, version, advisory এবং severity threshold দেখানো required check হলো প্রমাণ।

এই পার্থক্য জরুরি, কারণ অনেক security feature সিদ্ধান্ত নেওয়ার সময় পেরিয়ে যাওয়ার পর শুধু report করে। Scanner alert, email বা issue বানাতে পারে, অথচ merge button খোলা থাকে। তখন দল বলে scanning “চালু”, যদিও তা পরিবর্তন আটকাতে পারে না। প্রতিটি gate-এর চারটি বৈশিষ্ট্য পরীক্ষা করুন:

• এটি pull request-এর বর্তমান head commit-এ চলে।
• Branch protection তার নির্দিষ্ট result বাধ্যতামূলক করে।
• Skipped, timeout বা crashed job pass হিসেবে ধরা হয় না।
• Result-এ সিদ্ধান্ত পুনরুৎপাদনের মতো তথ্য থাকে।

Policy repository-তে রাখুন। শুধু administrator-দের জানা settings-এর চেয়ে ছোট manifest review করা সহজ:

merge_gates:
  tests: required
  codeql: required
  dependency_review: required
  secret_scan: required
  authorization: required
  migration_rehearsal: required_when_changed
  rollback_verification: required

required_when_changed কোনো ফাঁক নয়। Gate আগে প্রাসঙ্গিক file শনাক্ত করবে, তারপর rehearsal চালাবে অথবা স্পষ্ট “not applicable” result লিখবে। Path filter যেন required check-কে অনন্তকাল pending না রাখে এবং এজেন্ট যেন নিজের ঝুঁকিপূর্ণ পরিবর্তনকে বাদ দেওয়ার সিদ্ধান্ত না নেয়।

প্রতিটি job-এর workflow permission ন্যূনতম রাখুন। Pull request-এর code অবিশ্বস্ত input, branch আপনার organization-এর হলেও। যে gate পরীক্ষাধীন code-কে write token বা production secret দেয়, সেটি যে সমস্যা ধরতে এসেছিল তার চেয়ে বড় সমস্যা তৈরি করতে পারে।

Check-এর logic-এর মতো তার পরিচয়ও সুরক্ষিত করুন। Branch rule সাধারণত status name চায়, তাই একই name report করা দুটি workflow-এর দুর্বলটি rule পূরণ করতে পারে। Policy job-কে অনন্য name দিন, workflow কারা বদলাতে পারে তা সীমিত করুন এবং file owner-এর review নিন। Merge queue নতুন merge commit বানালে সেই commit-এ gate আবার চালান বা queued revision-এর সঙ্গে result বেঁধে দিন। গতকালের head-এর প্রমাণ আজকের merge-এর প্রমাণ নয়।

Gate configuration-কেও sensitive code হিসেবে ধরুন। Threshold বদলানো, path সরানো, query pack নামানো বা exception যোগ করা pull request পরের সব green result-এর অর্থ বদলে দেয়। Policy diff স্পষ্ট দেখান এবং সংশ্লিষ্ট control বোঝেন এমন maintainer-এর review নিন। এজেন্ট পরিবর্তন প্রস্তাব করতে পারে, কিন্তু যে বিচারব্যবস্থা তাকে যাচাই করছে সেটি edit করলেই সহজে পার পাওয়া উচিত নয়।

Test দৃশ্যমান regression আটকায়

Test gate-কে supported runtime ও database version-এ নির্ধারিত behavior ভাঙা যেকোনো পরিবর্তন আটকাতে হবে। Merge commit যে build input ব্যবহার করবে, locked dependency, generated file, feature flag ও schema state-সহ ঠিক সেগুলোতেই test চলবে।

এজেন্ট কাছের assertion সন্তুষ্ট করতে দক্ষ। একটি fallback দিয়ে এক test সবুজ করেও error handling, pagination, concurrency বা পাশের API contract ভাঙতে পারে। Behavior বদলালে test যোগ বা পরিবর্তন চাইুন, কিন্তু নতুন test line গুনে quality মাপবেন না। Implementation মুছে বা revert করলে test ব্যর্থ হবে কি না দেখুন।

ভালো test gate-এ আলাদা নামে কয়েকটি layer থাকে:

• Local logic ও boundary case-এর unit test।
• Database, queue, cache ও external service contract-এর integration test।
• Public request ও response shape-এর contract test।
• Built artifact-এর ছোট smoke test।

Flaky test-কে বারবার retry দিয়ে green না করে ঠিক করুন। একটি retry diagnostic evidence নিতে পারে, তবে final status-এ প্রথম failure দেখা উচিত। নইলে এজেন্ট এমন code merge করতে পারে যার একমাত্র প্রমাণ হলো সেটি মাঝে মাঝে কাজ করে।

Smoke test artifact চালু করবে, health endpoint ও একটি গুরুত্বপূর্ণ write path পরীক্ষা করবে, তারপর পরিষ্কারভাবে বন্ধ করবে। Packaged app চালু না করে শুধু source test করলে missing file, খারাপ environment default, broken migration ও startup panic ধরা পড়ে না। Web service result এমন সংক্ষিপ্ত হতে পারে:

{"commit":"abc123","build":"pass","startup_ms":842,"health":200,"write_read_cycle":"pass"}

একটি universal coverage percentage-কে মূল gate করবেন না। Coverage untested change দেখাতে পারে, কিন্তু দুর্বল assertion দিয়েও উচ্চ হার পাওয়া যায়। Required suite ও changed behavior-এর ওপর gate করুন, আর coverage movement review evidence হিসেবে রাখুন।

Test যে implementation বিচার করছে, তার কাছ থেকে test-কে রক্ষা করুন। Pull request একই সঙ্গে rule ও assertion বদলে নতুন result মানিয়ে নিলে contract নীরবে সরে যেতে পারে। Changed test-কে public API, issue বা acceptance rule-এর সঙ্গে তুলনা করান। Parser, validator, billing ও access check-এর জন্য mutation test বা ইচ্ছাকৃত ভুল input দিন। প্রশ্ন হলো suite যুক্তিসঙ্গত ভুল implementation প্রত্যাখ্যান করে কি না, এজেন্ট নিজের লেখা assertion মেটাতে পারে কি না তা নয়।

Gate fail করলে test artifact রাখুন। Random test-এর failing seed, নির্দিষ্ট database image, secret বাদ দেওয়া service log এবং reproduction command সংরক্ষণ করুন। Reproduction data ছাড়া status পরের engineer বা agent-কে আবার অনুমান করতে বাধ্য করে। Repository data policy অনুযায়ী retention বেঁধে দিন এবং সহজ reproduction-এর জন্য production snapshot upload করবেন না।

CodeQL পরিচিত vulnerability path আটকায়

CodeQL gate-কে CodeQL সত্যিই বিশ্লেষণ করা language ও generated artifact-এ নতুন, উচ্চ confidence finding আটকাতে হবে। Clean result পুরো app নিরাপদ প্রমাণ করে এমন ধারণা দেওয়া যাবে না।

GitHub-এর ভাষায় CodeQL code-কে query করা যায় এমন database-এ compile করে এবং তার ওপর query চালায়। এতে সন্দেহজনক text মেলানোর বদলে code-এর ভেতর data flow অনুসরণ করা যায়। তবে language support, build success, query selection ও analysis-এর সময় থাকা code এর সীমা ঠিক করে। Database build কোনো service নীরবে বাদ দিলে green result reviewer-এর ধারণার চেয়ে কম code ঢাকে।

Language ও query policy স্পষ্ট করে workflow লিখুন:

name: codeql
on: [pull_request]
permissions:
  contents: read
  security-events: write
jobs:
  analyze:
    strategy:
      matrix:
        language: [javascript-typescript, go]
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
          queries: security-extended
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

বাস্তব repository-তে third party action reviewed commit digest-এ pin করুন। Tag example পড়া সহজ করে, কিন্তু mutable tag required security job-এর trust boundary বাড়ায়।

প্রথম alert আসার আগেই কী block করবে ঠিক করুন। সাধারণত repository-র severity ও precision threshold অনুযায়ী নতুন finding block করা উচিত, আর পুরোনো debt baseline-এ দৃশ্যমান থাকবে। প্রথম দিনেই সব historical result block করলে mass dismissal বাড়ে। পুরোনো result চিরকাল উপেক্ষা করলে স্থায়ী blind spot হয়। Baseline-এর owner ও due date রাখুন।

Service, language বা build command বদলালে analyzed file set দেখুন। নতুন mobile client, generated resolver বা আলাদা backend নতুন analyzer বা build step চাইতে পারে। Reviewer কী পরীক্ষা হয়েছে বলতে না পারলে “CodeQL passed” কথাটির সীমা অস্পষ্ট।

Analysis failure ও clean analysis আলাদা রাখুন। Autobuild package compile করতে না পারলে job infrastructure বা configuration failure দেবে, zero finding নয়। Database creation log ও language অনুযায়ী analyzed source count রাখুন। Base branch-এর সঙ্গে তুলনা করে ব্যাখ্যাহীন বড় পতন ধরুন। Build edit vulnerable module বাদ দিলে analysis দ্রুত ও green হয়, কারণ scanner কম code দেখেছে, এই সাধারণ failure এতে ধরা পড়ে।

Dismissal-কে cleanup নয়, policy change হিসেবে review করুন। False positive-এর explanation code path ও query-র সঙ্গে বাঁধা থাকবে। Suppression comment সংকীর্ণ, owned এবং diff-এ দৃশ্যমান হবে। Generated file-এর repository-wide exclusion ঠিক হতে পারে, তবে সেখানে মানুষের রক্ষণাবেক্ষণ করা template বা generator input নেই তা আগে নিশ্চিত করুন।

Dependency review install-এর আগেই ঝুঁকি থামায়

Dependency diff স্পষ্ট policy ভাঙা package বা version যোগ করলে dependency review pull request আটকাবে। Policy-তে advisory severity, denied license, অপ্রত্যাশিত package source এবং owner ছাড়া direct dependency থাকতে পারে।

এটি repository vulnerability alert-এর সমান নয়। Alert বলে branch-এ vulnerable dependency আছে। Dependency review জিজ্ঞেস করে এই pull request graph খারাপ করছে কি না। GitHub dependency review manifest ও lockfile-এর পরিবর্তন তুলনা করে, তাই সিদ্ধান্ত সময়মতো ও নির্দিষ্ট change-এর সঙ্গে যুক্ত হয়।

Lockfile consistency বাধ্যতামূলক করুন। এজেন্ট package.json বদলে lockfile না বদলালে বা matching manifest change ছাড়া lockfile বদলালে job fail করবে। CI-তে fresh version resolve করা install command nondeterministic এবং reviewer যে graph দেখেছেন তার বদলে অন্য graph test করতে পারে।

সংক্ষিপ্ত policy এমন হতে পারে:

dependency_policy:
  fail_on_severity: high
  deny_licenses:
    - AGPL-3.0
  allow_sources:
    - registry.npmjs.org
    - proxy.golang.org
  require_owner_for_direct_additions: true

ঠিক license list আইনি ও product decision, অন্ধভাবে copy করার value নয়। গুরুত্বপূর্ণ হলো repository এটি ঘোষণা করে এবং check trigger করা package print করে।

Package-এর নাম প্রস্তাবিত library-র মতো বলে auto approve করবেন না। এজেন্ট package name বানিয়ে ফেলতে, abandoned fork নিতে বা ছোট helper-এর জন্য বড় client যোগ করতে পারে। Review output-এ direct ও transitive package, registry, resolved version, license ও advisory status দেখান। Reviewer তখন existing code বা ছোট dependency যথেষ্ট কি না জিজ্ঞেস করতে পারেন।

Dependency service diff বানাতে না পারলে fail closed করুন। Advisory feed না থাকলে merge থামানো যুক্তিসঙ্গত, uncertainty-কে green করা নয়। Emergency override-এ named maintainer, নথিবদ্ধ কারণ এবং commit-এর সঙ্গে record চাই।

Approved registry ছাড়া network access নেই এমন isolated job-এ install behavior পরীক্ষা করুন। Lifecycle script ও build plugin install-এর সময় code চালায়, তাই app import না করলেও package বিপজ্জনক হতে পারে। নতুন dependency install script, native binary বা অচেনা registry যোগ করে কি না record করুন। Publishing credential, cloud token বা trusted build-এর writable shared cache দেবেন না।

Vendored code ও container image-ও একই সিদ্ধান্তে পড়ে, যদিও সাধারণ manifest review সেগুলো মিস করতে পারে। Image digest, base image name, Git submodule ও checked-in archive তুলনা করুন। Release input-এর immutable digest চাইুন। latest tag-এর byte অন্য diff ছাড়াই বদলাতে পারে, ফলে পরে pull request পুনরুৎপাদন করা যায় না।

Secret scanning diff ও history দুটোই দেখবে

Test fixture, deleted file, generated bundle বা আগের commit-এ থাকলেও pull request credential pattern বা যাচাই করা live secret যোগ করলে scanning gate merge আটকাবে।

Push protection ও pull request scanning সম্পর্কিত কিন্তু আলাদা সমস্যা সমাধান করে। Push protection পরিচিত secret remote-এ যাওয়ার আগে থামাতে পারে। Pull request gate ইতিমধ্যে পৌঁছানো content দেখে এবং push protection বাদ দেওয়া contributor বা token type ধরতে পারে। Branch protection-এ required নয় এমন alert merge আটকায় না।

Final filesystem নয়, base branch থেকে পুরো commit range scan করুন। এজেন্ট এক commit-এ token যোগ করে পরেরটিতে সরালেও তা Git history, log বা cache-এ থেকে যায়। একে exposed ধরুন। Credential revoke বা rotate করুন, proposed history থেকে সরান এবং check আবার চালান।

Authenticate করতে পারে না এমন synthetic fixture ব্যবহার করুন। Fixture স্পষ্টভাবে test হিসেবে চিহ্নিত হবে এবং real cloud key অনুকরণ না করে local test pattern মেলাবে। Broad allowlist বিপজ্জনক, কারণ ভুল বা আক্রমণকারী একদিন ignored directory ব্যবহার করবে। Exception exact, reviewed ও detector config-এর কাছে রাখুন।

Pattern detector-এর সঙ্গে entropy check এবং provider নিরাপদে দিলে credential verification মিলিয়ে নিন। Pattern matching-এর disclosure risk কম, কিন্তু custom token মিস করে। Verification uncertainty কমাতে পারে, তবে candidate secret-এর অংশ অন্য service-এ পাঠায় এবং pull request দেওয়া untrusted endpoint-এ চলবে না। কোন detector verify করে, কোনটি local থাকে এবং CI থেকে কী data বের হয় নথিবদ্ধ করুন।

প্রতিটি random string-কে credential না ধরে common encoding ও generated output scan করুন। Base64, URL encoding ও minified bundle source step-এর plain secret লুকাতে পারে। Tested fixture দিয়ে blocking threshold ঠিক করুন এবং detector update-কে policy change হিসেবে review করুন। Noisy scanner dismissal শেখায়, আর silent scanner মিথ্যা নিরাপত্তা দেয়।

Output location দেখাবে, secret নয়:

{"result":"fail","detector":"generic-api-token","commit":"abc123","path":"config/dev.env","line":7,"fingerprint":"sha256:8f2c..."}

CI log বা comment-এ full match print করবেন না। Scanner output দেওয়ার পর masking দেরি হয়ে যেতে পারে, কারণ log system, notification ও artifact সেটি copy করে।

Secret scanning repository permission review-এর বদলি নয়। Workflow diff-এ secret না রেখেও production credential পড়তে পারে, আর এজেন্ট deployment job বদলে তা বের করতে পারে। Pull request job থেকে secret দূরে রাখুন, workflow permission সীমিত করুন এবং CI definition change-এ human review নিন।

Authorization check নিষিদ্ধ action নিষিদ্ধই রাখে

Authorization gate প্রমাণ করবে প্রতিটি protected operation service boundary-তে ভুল actor-কে প্রত্যাখ্যান ও intended actor-কে অনুমতি দেয়। শুধু login test authorization test নয়।

দল authentication, authorization এবং UI visibility গুলিয়ে ফেলে। Authentication বলে request কে পাঠিয়েছে। Authorization বলে সেই identity এই object-এ action নিতে পারে কি না। React-এ admin button লুকিয়ে Go API-র সিদ্ধান্ত বদলায় না। Backend request নিলে app exposed।

Changed endpoint ও business action-এর permission matrix বানান, ownership ও tenant boundary-সহ:

read_private_project:
  anonymous: deny
  member: deny
  other_tenant: deny
  owner: allow
  admin: allow
update_project:
  anonymous: deny
  other_tenant: deny
  owner: allow

Matrix থেকে test generate করুন বা service language-এ table-driven case লিখুন। প্রতিটি deny case realistic identifier দিয়ে real handler ডাকবে। Authorization middleware mock করলে route কাজ করে প্রমাণ হলেও পরীক্ষাধীন control বাদ পড়ে।

শুধু role নয়, object-level access test করুন। একই member role-এর দুই user আলাদা organization-এ থাকতে পারে। Resource ও tenant identifier আলাদাভাবে বদলে insecure direct object reference ধরুন। Bulk endpoint, export, background job ও GraphQL resolver-ও test করুন, কারণ এগুলো সাধারণ REST check এড়াতে পারে।

নতুন protected route-এর policy mapping না থাকলে gate fail করুন। Missing authorization reviewer-এর অনুমান না থেকে measurable defect হবে। Server default deny রাখুন। কয়েকটি bad case নিষেধ করা ছড়ানো code-এর চেয়ে explicit allow rule audit করা সহজ।

এজেন্ট কাছের handler reuse করে happy path রেখে ownership check ফেলে দিতে পারে। Matrix omission দৃশ্যমান করে এবং পরে role বা tenant rule বদলালে stable contract দেয়।

Input normalization-এর পর authorization পরীক্ষা করুন। Letter case, alternate identifier, duplicate query parameter ও nested reference একই request-কে আলাদা code path-এ পাঠাতে পারে। Direct endpoint এবং একই operation-এ পৌঁছানো batch বা import route test করুন। Background worker final write করলে actor ও tenant context job-এ পাঠান, worker-কে সর্বক্ষম trusted user ধরবেন না।

Expected decision ও policy rule record করুন, private object data নয়। ভালো failure actor class, action, object class ও expected status বলে; access token বা full record dump করে না। এতে reviewer broken fixture ও সত্যিকারের privilege change আলাদা করতে পারেন।

Migration rehearsal lock ও reversibility মাপে

Migration gate proposed schema change production-shaped copy-তে প্রয়োগ করবে, compatibility probe চালাবে এবং merge-এর আগে সময়, lock ও rollback behavior record করবে। Empty test database-এ সফল migration খুব কমই প্রমাণ করে।

Similar table size, index, constraint ও data skew-সহ sanitized snapshot বা generated dataset ব্যবহার করুন। Exact production data pull request infrastructure-এ যাবে না। লক্ষ্য confidential record copy না করে operational pressure পুনরায় তৈরি করা।

বাস্তব deployment sequence rehearse করুন। Migration চলার সময় old app instance থাকলে old code নতুন schema-তে এবং new code transitional schema-তে test করুন। Nullable column যোগ করা সাধারণত compatible। এক ধাপে column rename করলে request serve করা সব old instance ভেঙে যেতে পারে।

Machine-readable evidence রাখুন:

{"migration":"20260727_add_project_state","apply_ms":18420,"max_lock_ms":310,"old_app_probe":"pass","new_app_probe":"pass","down":"pass"}

Database ও table class অনুযায়ী threshold দিন। 300 millisecond lock এক table-এ harmless, অন্যটিতে disruptive। Reviewer measured result-এর পাশে selected limit ও rehearsal database version দেখবেন।

PostgreSQL-এ table rewrite, constraint validation বা write block করে index build করা operation দেখুন। Expand and contract change নিন: নতুন shape যোগ করুন, দুই shape বোঝা code deploy করুন, controlled batch-এ backfill করুন, read বদলান, পরে old shape সরান। Outage-এ improvisation-এর চেয়ে অতিরিক্ত pull request সস্তা।

সব migration-এর safe down সম্ভব নয়। Column drop data হারায়, transformation reverse অস্পষ্ট হতে পারে। তখন tested forward recovery ও backup restore point চাইুন। Down file আছে বলে irreversible migration-কে rollback safe বলা অসৎ।

Retry ও partial failure পরীক্ষা করুন। Index বানানোর পর migration complete record করার আগে deploy থামতে পারে; পরের চেষ্টা state corrupt বা স্থায়ী fail করবে না। Controlled boundary-তে rehearsal থামিয়ে rerun করুন এবং schema ও ledger মিলেছে দেখুন। Long backfill recorded cursor থেকে resume করবে এবং একই batch দুইবার চালালে duplicate বা delete হবে না।

Elapsed time-এর সঙ্গে disk ও replication effect মাপুন। Table rewrite temporary space, write ahead log ও replica delay বাড়াতে পারে। Perfect production forecast লাগবে না, তবে rehearsal dataset-এর মান database owner-এর limit-এর সঙ্গে তুলনা করুন। না হলে দ্রুত local migration-ও production volume শেষ করতে পারে।

Rollback verification recovery path চালাবে

Rollback gate isolated environment-এ candidate deploy করবে, representative state বানাবে, supported rollback চালাবে এবং previous version সঠিকভাবে read ও write করতে পারে প্রমাণ করবে। লেখা rollback plan verification নয়।

Application rollback ও data rollback আলাদা করুন। আগের binary-তে traffic ফেরাতে seconds লাগতে পারে, destructive schema বা data transformation ফেরানো অসম্ভব হতে পারে। Gate দুটোই report করবে। Old app নতুন schema-তে না চললে candidate nonreversible লিখে staged deployment plan চাইুন।

একটি বাস্তব sequence:

1. Current main commit deploy করে representative record seed করুন।
2. Pull request artifact-এ upgrade করে changed path চালান।
3. Upgraded state-এ নতুন record বানান।
4. Documented control দিয়ে previous artifact বা snapshot restore করুন।
5. Read, write, queue ও background job probe চালান।

Check artifact ID, snapshot ID, timestamp ও probe result রাখবে, credential বা copied customer data নয়। Recovery time নিজের operating target-এর evidence, universal promise নয়।

Snapshot কাজে আসে যদি application-এর দরকারি সবকিছু তাতে আছে প্রমাণ হয়। File, object storage, queue state, schema change ও external side effect server snapshot-এর বাইরে থাকতে পারে। Result-এ boundary লিখুন। ইতিমধ্যে পাঠানো payment, email বা webhook database restore করে ফেরানো যায় না।

Rollback probe health check-এর চেয়ে শক্ত করুন। Upgrade-এর আগে ও পরে বানানো record পড়ুন, compatibility দিলে দুটো update করুন, এবং দুই app version-এর queued job process করুন। শুধু status code নয়, user-visible output তুলনা করুন। New field ফেলে বা enum ভুল পড়েও 200 দেওয়া server recover করেনি।

On-call ব্যক্তি যে control ব্যবহার করবেন সেটিই test করুন। Production rollback-এ artifact select, snapshot restore বা traffic switch লাগলে isolated rehearsal একই interface ও permission path ব্যবহার করবে। এক engineer-এর laptop-এর private script operational control নয়। Designated operator role permanent admin access ছাড়াই recovery করতে পারে এমন evidence চাই।

Koder.ai source export, deployment ও hosting, snapshot এবং rollback সমর্থন করে, তাই সেখানে তৈরি app recovery-কে pull request-এর paragraph না বানিয়ে gate-এ concrete artifact ব্যবহার করতে পারে। যেকোনো platform-এ rule একই: recovery control চালান ও restored app probe করুন।

একটি required check সাতটিই সারসংক্ষেপ করবে

Final merge decision একটি stable policy check চাইবে যা exact head commit-এর সাত result যাচাই করে। Job name বদলায়, matrix job বাড়ে এবং optional path কাজ skip করে। ছোট aggregator branch protection-কে policy থেকে সরে যেতে দেয় না।

প্রতিটি gate commit, policy version, outcome ও evidence location-সহ signed বা platform-attested result দেবে। Aggregator missing, stale, neutral বা cancelled result প্রত্যাখ্যান করবে। Report না করা job থেকে success অনুমান করবে না।

{
  "commit": "abc123",
  "policy": "merge-gates-v3",
  "results": {
    "tests": "pass",
    "codeql": "pass",
    "dependency_review": "pass",
    "secret_scan": "pass",
    "authorization": "pass",
    "migration_rehearsal": "not_applicable",
    "rollback_verification": "pass"
  },
  "decision": "allow"
}

Emergency-এর জন্য সংকীর্ণ override path দিন। Named maintainer, দ্বিতীয় approver, written reason, expiry ও follow-up issue চাইুন। এজেন্ট নিজের exception চাইবে বা approve করবে না। Ordinary gate result-এর জায়গাতেই override report রাখুন, যাতে incident-এর পরও দেখা যায়।

কিছু pull request-এ এই check কয়েক minute এবং migration change-এ আরও সময় যোগ করবে। নির্দিষ্ট evidence পেলে তা গ্রহণযোগ্য। Cheap gate আগে চালান, superseded commit cancel করুন, trusted build input cache করুন এবং full environment rehearsal relevant path-এ রাখুন। Dashboard দ্রুত green করতে gate দুর্বল করবেন না।

বর্তমান behavior দৃশ্যমান করে শুরু করুন। একটি policy file-এ সাতটি name রাখুন, প্রতিটিকে required result-এর সঙ্গে বাঁধুন এবং skipped কাজকে ব্যাখ্যা দিতে বাধ্য করুন। যে প্রথম agent pull request record দিতে পারে না, সেটি production-এর আগে delivery system-এর ফাঁক ধরেছে।