Graft: coding agent-এর জন্য codebase map

কোডিং এজেন্টের জন্য codebase map কী

কোডিং এজেন্টের জন্য codebase map হলো আপনার repository-এর একটি স্থায়ী index। নতুন প্রতিটি session-এ agent শূন্য থেকে grep করে অনুসন্ধান না করে এই index থেকে প্রয়োজনীয় তথ্য খুঁজে নেয়। Graft এই ধারণার একটি implementation। এটি tree-sitter ব্যবহার করে আপনার code parse করে, পরস্পর-সংযুক্ত markdown node-এর একটি folder এবং প্রতিটি symbol-এর wiring graph তৈরি করে, আর MCP (model context protocol, coding agent-গুলোর বাইরের tool কল করার standard interface)-এর মাধ্যমে retrieval tool সরবরাহ করে।

Graft proxy নয় এবং gateway-ও নয়। আপনার agent ও model API-এর মধ্যে কোনো মধ্যবর্তী স্তর থাকে না। Map হলো disk-এর একটি folder, যেটি agent পড়ে। এই পার্থক্যটি নির্ধারণ করে আপনি কোন সমস্যার সমাধান করছেন: self-hosted token gateway আপনার ইতিমধ্যে পাঠানো request-এর পরিমাণ হিসাব করে এবং সেগুলোর routing নিয়ন্ত্রণ করে, আর map নির্ধারণ করে মোট কতগুলো request পাঠাতে হবে।

এই কৌশলটি এই tool-এর চেয়ে পুরোনো এবং tool-টি আর না থাকলেও কৌশলটি ব্যবহার করা যাবে। প্রথমে কৌশলটি শিখুন, তারপর এর প্রয়োগপদ্ধতি শিখুন।

কেন coding agent-গুলো বারবার repository-এর কাঠামো নতুন করে খুঁজে context নষ্ট করে

একটি agent-কে এমন একটি repository-তে কাজ শুরু করতে দেখুন, যেটি সে ইতিমধ্যে পঞ্চাশবার দেখেছে। সে directory তালিকাভুক্ত করে। কোনো symbol খুঁজতে grep চালায়। function-টি কোন file-এ সংজ্ঞায়িত হয়েছে তা জানতে তিনটি file খোলে, তারপর কে সেটিকে call করে তা জানতে চতুর্থ file খোলে। এর কোনোটিই মূল কাজ নয়। এগুলো orientation-এর ধাপ, এবং প্রতিটি session-এ এর জন্য input token খরচ হয়।

কারণটি সরল। session-এর মধ্যে একটি model-এর কোনো memory থাকে না। আপনার layout সম্পর্কে agent যা শিখেছিল, তা session শেষ হলে বাতিল হওয়া context window-তেই ছিল। তাই একই discovery আবার zero থেকে শুরু হয় এবং প্রতিবার পুরো মূল্য দিতে হয়। বড় repository-তে orientation phase-এর খরচ edit-এর চেয়ে বেশি হয়: code খুঁজতে দশটি tool call, পরিবর্তন করতে একটি। এই খরচের এক অর্ধ orientation এবং অন্য অর্ধ edit। তাই agent-কে কার্যকর সবচেয়ে ছোট পরিবর্তনে সীমাবদ্ধ রাখে এমন একটি skill map-এর সঙ্গে ব্যবহার করা, যেকোনো একটি বেছে নেওয়ার চেয়ে বেশি কার্যকর।

একটি map discovery-এর কাজ model থেকে disk-এ সরিয়ে এই পুনরাবৃত্তি বন্ধ করে। একটি parser একবার repository পরিদর্শন করে, কোন symbol কোথায় সংজ্ঞায়িত এবং কোন symbol কোনটিকে call করে তা নথিভুক্ত করে, তারপর code পরিবর্তিত হলে সেই record হালনাগাদ রাখে। agent একটি প্রশ্ন করে এবং file ও line-সহ উত্তর পায়। বারবার exploration করা একটি সস্তা lookup-এ পরিণত হয়।

আপনি ইতিমধ্যে এর একটি দুর্বল সংস্করণ ব্যবহার করেন। আপনার conventions নির্দিষ্ট করা একটি AGENTS.md agent-কে প্রতিবার আপনার conventions নতুন করে নির্ধারণ করা থেকে বিরত রাখে। একটি generated map agent-কে আপনার structure নতুন করে নির্ধারণ করা থেকে বিরত রাখে। পার্থক্য হলো, এটি কে লেখে। আপনি instruction file হাতে লেখেন, তাই সেটি ছোট থাকে। একটি parser map তৈরি করে, তাই এটি দশ হাজার file কভার করতে পারে। একটি session-এর মধ্যে budget আসলে কোথায় খরচ হয়, সে হিসাবের জন্য Claude Code কীভাবে তার context window ব্যবহার করে দেখুন।

Graft আসলে যা তৈরি করে

সবকিছু repository root-এর একটি graft/ folder-এর মধ্যে থাকে। এখানে দুটি artefact তৈরি হয়।

প্রথমটি linked markdown হিসেবে লেখা একটি node graph; প্রতিটি node-এর জন্য একটি করে file থাকে। প্রতিটি node-এ সাধারণ ইংরেজিতে লেখা একটি summary, source থেকে নেওয়া গুরুত্বপূর্ণ logic line-গুলোর "crux", content hash-সহ exact source file, অন্য node-এর দিকে typed wikilink (depends_on, part_of, uses, implements), এবং একটি notes section থাকে। regeneration-এর পরও notes section বজায় থাকে, যাতে parser যে context নির্ণয় করতে পারে না তা আপনি লিখে রাখতে পারেন।

দ্বিতীয়টি হলো graft/.graph/wiring.json, tree-sitter যে per-symbol structural graph extract করে। এতে definition, reference এবং symbol-গুলোর মধ্যকার call edge থাকে।

এই বিভাজন গুরুত্বপূর্ণ, কারণ দুটি অংশের মধ্যে শুধু একটির জন্য model প্রয়োজন। graft build সম্পূর্ণভাবে tree-sitter নির্ভর এবং কখনও LLM (large language model) কল করে না। তাই এটি deterministic এবং এর কোনো খরচ নেই। graft build --deep লিখিত summary ও per-symbol crux যোগ করে। এগুলোর জন্য model call লাগে এবং সেই call-এর জন্য আপনাকে অর্থ দিতে হয়।

Language support tier অনুযায়ী বিভক্ত। এই tier থেকেই বোঝা যায় call graph-কে কতটা নির্ভরযোগ্য ধরে নেওয়া যাবে। TypeScript, JavaScript, Python, Go এবং Java scope-aware cross-file resolution পায়। Rust, C, C++, C#, Ruby, PHP, Kotlin, Scala, Swift, Elixir, Solidity, OCaml, Zig এবং Dart symbols ও generic call edge পায়। অর্থাৎ কোনো edge resolved reference-এর বদলে name match-ও হতে পারে। Compiler-grade edge পেতে --lsp এবং rust-analyzer বা gopls-এর মতো একটি language server opt-in করতে হয়।

Graft ইনস্টল করুন এবং version নির্দিষ্ট করুন

Graft-এর জন্য Node.js 20 বা তার নতুন version প্রয়োজন এবং এটি MIT license-এর অধীনে প্রকাশিত। August 2026 অনুযায়ী বর্তমান release হলো 0.10.1, আর প্রথম প্রকাশিত version 0.1.0-এর তারিখ July 2026। এটিকে নতুন software হিসেবে বিবেচনা করুন।

npm install -g @nanonets/graft@0.10.1
npm ls -g @nanonets/graft

npm ls -g-এর output হওয়া উচিত @nanonets/graft@0.10.1। ইচ্ছাকৃতভাবে ওই version নির্দিষ্ট করুন। শুধু npm install -g @nanonets/graft ব্যবহার করলে আপনি command চালানোর সময় latest tag-এর বর্তমান version পান। কোনো project-এ প্রতি মাসে একাধিক minor release প্রকাশিত হলে এতে Tuesday-তে আপনি যে tool পান, তা Monday-তে আপনার সহকর্মী ইনস্টল করা tool-এর চেয়ে আলাদা হতে পারে। নির্দিষ্ট version ব্যবহার করলে সবার জন্য CLI flag এবং graph format একই থাকে। ফলে আপনি সিদ্ধান্ত নেওয়ার সময়ই upgrade করতে পারেন।

এরপর আপনার মালিকানাধীন repository-তে এটি যুক্ত করুন:

cd /path/to/your/repo
graft init --dry-run
graft init

graft init আপনার কোন coding agent-গুলোর সঙ্গে wiring করতে চান তা জানতে চায়। এরপর এটি graph তৈরি করে। প্রথমে --dry-run চালিয়ে কোন file-গুলোতে পরিবর্তন করার পরিকল্পনা করা হয়েছে তার তালিকা পড়ুন। কারণ এগুলোর কিছু repository-এর বাইরেও থাকতে পারে। graft init idempotent এবং বিদ্যমান config overwrite করে না। তাই এটি দ্বিতীয়বার চালানো নিরাপদ।

August 2026 অনুযায়ী এই wiring Claude Code, Cursor, Codex, GitHub Copilot, Google Gemini, Kiro, Windsurf এবং AdaL সমর্থন করে। Claude Code-এর integration সবচেয়ে বিস্তৃত। এতে একটি MCP server entry, graph-এর আকার ও পুরোনো হওয়ার অবস্থা দেখানো statusline, graph পুনর্নির্মাণের post-edit hook এবং .claude/-এর অধীনে একটি skill file থাকে। অন্য agent-গুলোর জন্য এমন একটি instruction বা rule file তৈরি হয়, যা agent-কে জানায় যে tool-গুলো রয়েছে। তাই "Supported" বলতে বোঝায় Graft wiring লিখে দেয়। কোনো agent নিজের rules file অনুসরণ না করলে সেটিও map ব্যবহার করবে না। সাধারণত এ কারণেই agent-রা তাদের জন্য লেখা নির্দেশনা উপেক্ষা করে, এবং এই ক্ষেত্রেও একই বিষয় প্রযোজ্য।

রিপোজিটরিতে কী যোগ হবে এবং git-এ কী থাকবে না

graft init-এর পরে এগুলো থাকবে:

• graft/: markdown node graph এবং graft/.graph/wiring.json। আপনার জন্য .gitignore-এ যোগ করা হবে।
• .mcp.json: graft MCP server নিবন্ধন করে, যাতে Claude Code এটি চালু করতে পারে।
• .claude/settings.json: নির্দিষ্ট স্থানে merge করা হবে এবং statusline ও post-edit hooks যোগ করবে।
• AGENTS.md, GEMINI.md, .github/copilot-instructions.md, .cursor/rules/graft.mdc, .kiro/steering/graft.md, .windsurf/rules/graft.md এবং .adal/skills/graft/SKILL.md: আপনি যে agent বেছে নিয়েছেন, তার সঙ্গে মেলে এমন ফাইলগুলোর শেষে marker-fenced section হিসেবে যোগ হবে।
• ~/.codex/config.toml, ~/.codex/hooks.json এবং ~/.codex/hooks/graft/graft-hooks.cjs: এগুলো পুরো মেশিনে প্রযোজ্য এবং আপনি Codex নির্বাচন করলেই লেখা হবে। graft init --no-global এগুলো বাদ দেয়, আর graft init --no-hooks নিজে hook shim বাদ দেয়।

Graph হলো node_modules-এর মতো একটি cache। এটি commit করবেন না। এটি code থেকে কয়েক সেকেন্ডে আবার তৈরি হয় এবং প্রায় প্রতিটি edit-এর পর পরিবর্তিত হয়। এটি commit করলে একটি এক-লাইনের fix কয়েকশো ফাইলের diff-এ পরিণত হয়, যা কোনো reviewer পড়বেন না। এর পরিবর্তে wiring commit করুন, যার মধ্যে AGENTS.md এবং .mcp.json-ও রয়েছে। কোনো teammate repository clone করে graft build চালালে নিজের local graph পেয়ে যাবে।

প্রথম commit করার আগে ignore rule যোগ হয়েছে কি না যাচাই করুন:

grep -n graft .gitignore
git status --short

grep-এর output-এ graft/-সম্বলিত একটি line দেখা উচিত, এবং git status --short-এর output-এ graft/-এর অধীনে কিছুই তালিকাভুক্ত হওয়া উচিত নয়। ওই output-এ graft/-এর অধীনে কোনো file দেখা গেলে বুঝবেন ignore entry অনুপস্থিত, অথবা অন্য কোথাও তা override করা হয়েছে। Commit করার আগে এটি ঠিক করুন, কারণ কোনো file একবার যোগ হয়ে গেলে git সেটিকে tracking-এ রাখে, এবং পরে .gitignore edit করলেও সেটি tracking থেকে সরবে না।

আপনি যদি MCP server নিজে হাতে নিবন্ধন করতে চান, অথবা যে version install করেছেন সেটিতেই pin করতে চান, তাহলে entry-টি ছোট:

{
  "mcpServers": {
    "graft": {
      "command": "npx",
      "args": ["-y", "@nanonets/graft@0.10.1", "mcp"]
    }
  }
}

আপনার agent grep-এর পরিবর্তে যে retrieval tool-গুলো ব্যবহার করে

Graft MCP-এর মাধ্যমে ছয়টি tool প্রকাশ করে। graft_find_code একটি task description-এর জন্য file ও line-সহ rank করা node ফেরত দেয়। graft_file_api কোনো file-এর body ছাড়া প্রতিটি signature ফেরত দেয়। graft_trace_calls একাধিক level পর্যন্ত caller বা callee অনুসরণ করে। graft_find_all symbol অনুযায়ী group করা regex match ফেরত দেয়। graft_repo_map অপরিচিত repository সম্পর্কে প্রাথমিক ধারণা দেয়। graft_check_freshness graph এখনও code-এর সঙ্গে মিলে কি না তা জানায়।

প্রতিটি tool-এর একটি CLI সমতুল্যও আছে। আপনার agent-কে আসলে কী দেওয়া হচ্ছে, তা যাচাই করার এটাই পদ্ধতি:

graft map .
graft ask "where do we validate the refresh token"
graft skeleton src/auth/session.ts
graft callers validateRefreshToken
graft callers validateRefreshToken --direction out
graft grep "refresh_token" --json

graft ask-এর output-এ file contents-এর পরিবর্তে file:line reference-সহ rank করা node দেখা উচিত। পুরো প্রক্রিয়াটি এভাবেই কাজ করে: agent-কে একটি pointer দেওয়া হয় এবং সঠিকটি খুঁজতে দশটি file পড়ার পরিবর্তে সে একটি file খোলে। নিজে graph দেখতে চাইলে graft viz localhost-এ একটি interactive viewer খোলে। ত্রিশ সেকেন্ডে উত্তর দেওয়া সম্ভব এমন কোনো প্রশ্নে graft ask যদি উপযোগী কিছু না ফেরত দেয়, তাহলে graph stale, অথবা আপনার language broad tier-এ রয়েছে। সে ক্ষেত্রে map আপনার agent-কেও সাহায্য করবে না।

একটি খরচ সহজেই চোখ এড়িয়ে যায়। পুরো session জুড়ে প্রতিটি request-এর system prompt-এ ছয়টি tool definition inject করা হয়। agent map ব্যবহার করুক বা না করুক, এই খরচ আপনাকে দিতে হয়। Repository যদি context-এ রাখার মতো ছোট হয়, তাহলে exploration থেকে যে সাশ্রয় হয় তার চেয়ে এই fixed charge বেশি হতে পারে।

কোড পরিবর্তন হলে গ্রাফে কী ঘটে

Structural refresh দ্রুত এবং স্বয়ংক্রিয়। Graft git-এর পরিবর্তে আপনার working tree পড়ে। তাই commit না করা edit এবং staged edit—উভয়ই Graft-এর কাছে সমানভাবে দৃশ্যমান। কোনো query কেবল stat পরিবর্তিত হওয়া ফাইলগুলো পুনরায় parse করে। প্রকল্পের নথি অনুযায়ী এতে প্রায় 3 ms overhead হয়। turn-end rebuild শুধু সেই ফাইলগুলো প্রক্রিয়া করে যেখানে code সরানো হয়েছে। পুনরায় parse না করে disk-এ থাকা graph থেকে উত্তর দিতে GRAFT_NO_REFRESH=1 সেট করুন অথবা --no-refresh pass করুন। সবকিছু cold re-parse করতে --no-reuse pass করুন। Graft নিজেই upgrade করার পরে এটিই ব্যবহার করা উচিত।

Model লিখিত অংশটি ভিন্নভাবে কাজ করে। সমস্যাটি সাধারণত নীরবে এখানেই তৈরি হয়। Summary এবং crux cache করা থাকে। প্রতিটি node তার source-এর content hash সংরক্ষণ করে। তাই কোনো source file পরিবর্তিত হলে node-কে current হিসেবে দেখানোর বদলে stale হিসেবে চিহ্নিত করা হয়। তবে কোনো ব্যবস্থা নেওয়া না হলে এই flag কোনো কাজে আসে না। graft build --deep দিয়ে refresh করুন। এতে আবার model token খরচ হয়।

Staleness দৃশ্যমান করুন:

graft check .
echo $?

Exit status 0-এর অর্থ graph code-এর সঙ্গে মিলে গেছে। Exit status 1-এর অর্থ drift রয়েছে। এটি pre-push hook থেকে অথবা CI-তে branch-এর ওপর চালান। তাহলে ছয় মাস পুরোনো map March মাসে পুনর্লিখিত code সম্পর্কে আত্মবিশ্বাসের সঙ্গে উত্তর দিতে পারবে না।

প্রকাশিত benchmark-এর সংখ্যাগুলো সতর্কভাবে পড়ুন

Graft-এর মূল দাবি হলো, এটি “সর্বোচ্চ 4x সস্তা এবং 3x দ্রুত, correctness অপরিবর্তিত রেখে বা কোনো ক্ষতি ছাড়াই” কাজ করে। এই সংখ্যাগুলো প্রকল্পটির নিজস্ব benchmark থেকে নেওয়া, যা তার README-তে প্রকাশিত হয়েছে। নিচে উল্লিখিত দুটি run-এর সম্পূর্ণ বিবরণ দেওয়া হলো।

[
  {
    "label": "Controlled sweep",
    "run_count": 162,
    "token_saving_pct": 42,
    "tool_call_saving_pct": 46,
    "correctness_pct": 93,
    "baseline_correctness_pct": 93
  },
  {
    "label": "SWE-bench Verified",
    "run_count": 50,
    "token_saving_pct": 23,
    "tool_call_saving_pct": 25,
    "correctness_pct": 66,
    "baseline_correctness_pct": 54
  }
]

নিয়ন্ত্রিত sweep-এ দুটি repository নিয়ে 162টি run করা হয়েছে। এর একটি repository হলো Graft নিজেই, এবং প্রতিটি task-এর জন্য তিনটি trial নেওয়া হয়েছে। এতে 42% কম token এবং 46% কম tool call ব্যবহারের কথা বলা হয়েছে। SWE-bench Verified run-এ 50টি instance ছিল এবং উভয় arm-এ একই model ব্যবহার করা হয়েছে। সেখানে সাশ্রয় কম: 23% token এবং 25% tool call। তৃতীয় একটি run-এ পাঁচটি merged PocketBase pull request পুনরায় তৈরি করা হয়। এতে baseline-এর 13.91 US dollar-এর বিপরীতে খরচ হয়েছে 11.02 US dollar।

এগুলোকে vendor benchmark হিসেবে বিবেচনা করুন। এই ফলাফলগুলো কী জানাতে পারে, তা দুটি বিষয় সীমিত করে। নিয়ন্ত্রিত sweep-এ Graft-এর নিজস্ব repository রয়েছে। এটি সেই codebase, যার ওপর প্রকল্পটির নির্মাতারা tuning করেছেন। SWE-bench Verified হলো পরিচিত open-source Python project-এর issue নিয়ে তৈরি একটি public dataset। কোনো উদ্দেশ্য না থাকলেও public dataset-ই সাধারণত সেই data, যার জন্য tool-গুলো optimised হয়। এই ফলাফলগুলোর কোনোটিই আপনার private monorepo সম্পর্কে কোনো সিদ্ধান্ত দেয় না। আপনার monorepo-তে নিজস্ব naming convention এবং নিজস্ব dead code থাকতে পারে।

Correctness বিষয়টি আলাদাভাবে যাচাই করা দরকার। নিয়ন্ত্রিত sweep-এ এটি পরিবর্তিত হয়নি: map ব্যবহারে 93%, আর map ছাড়া 93%। 54% থেকে 66%-এ বৃদ্ধি শুধু SWE-bench Verified-এ দেখা যায়। কোনো tool token খরচ কমিয়ে quality অপরিবর্তিত রাখলে সেটিও ভালো trade-off। তবে SWE-bench-এর correctness ফলাফলকে sweep-এর token ফলাফলের সঙ্গে মিলিয়ে একটি যৌথ দাবি হিসেবে উদ্ধৃত করবেন না।

বিশ্বাস করার আগে নিজস্ব token delta পরিমাপ করুন

গুরুত্বপূর্ণ একমাত্র সংখ্যাটি আপনার repository থেকে পাওয়া সংখ্যা। এই পদ্ধতিতে একটি বিকেল সময় লাগবে।

এমন একটি কাজ বেছে নিন, যা হুবহু পুনরাবৃত্তি করা যায়। প্রশ্ন edit-এর চেয়ে ভালো, কারণ edit করলে repository পরিবর্তিত হয় এবং দ্বিতীয়বার চালানো আর একই পরীক্ষা থাকে না। “login route-এ rate limit কোন module প্রয়োগ করে” — প্রশ্নটি এই ধরনের হওয়া উচিত।

telemetry চালু করুন এবং নিজের terminal-এ পাঠান:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
claude

Console exporter metric record সংগ্রহের সঙ্গে সঙ্গে দেখায়। আপনার প্রয়োজন claude_code.token.usage, যেখানে type attribute-এর মান input, output, cacheRead অথবা cacheCreation। Orientation input এবং cacheRead-এ দেখা যায়, কারণ file content সেখানেই থাকে। এই দুটির যোগফল নিন।

Map সংযুক্ত রেখে, প্রতিবার নতুন session-এ কাজটি তিনবার চালান। এরপর .mcp.json থেকে graft entry সরিয়ে আবার তিনবার চালান। একক run-এর বদলে median তুলনা করুন, কারণ agent run-এর ফলাফলে বড় পার্থক্য হতে পারে এবং একটি দুর্ভাগ্যজনক run আপনাকে প্রকৃত ফলের বিপরীত ধারণা দিতে পারে। Tool-call count-ও লিখে রাখুন: tool call হলো প্রক্রিয়া, আর token হলো ফলাফল। তাই tool call না কমে token কমলে অন্য কোনো পরিবর্তন ঘটেছে।

এরপর benchmark-এ দেখানো হয় না এমন খরচ বাদ দিন। প্রতিটি full refresh-এ graft build --deep model token ব্যবহার করে। প্রতিটি request-এর সঙ্গে ছয়টি tool schema পাঠানো হয়। আপনার agent যদি ভাড়া করা server-এ চলে, agent খরচের সর্বোচ্চ সীমা নির্ধারণ করলে এটি অপ্রত্যাশিত ব্যয়ের বদলে বাজেটে পরিণত হয়। Exporter চালু করার পর machine থেকে আসলে কী বাইরে যায়, তা coding agent-এর telemetry আসলে কী report করে অংশে ব্যাখ্যা করা হয়েছে।

কোডবেসের map কখন আর কাজে সহায়তা করে না?

• Repository-টি ইতিমধ্যে context-এ ধরে। একটি ছোট service-এর জন্য map প্রয়োজন নেই। প্রতিটি request-এ ছয়টি tool schema-এর খরচ আপনাকেই দিতে হয়। Agent যদি আজ এক বা দুইটি tool call-এই যেকোনো file খুঁজে পায়, তাহলে এটি বাদ দিন।
• আপনার language broad tier-এ রয়েছে। Generic call edge-এর কারণে graft callers কোনো caller বাদ দিতে পারে, অথবা একই নামের সংঘর্ষে ভুল caller তৈরি করতে পারে। Blast radius-এ আস্থা রাখার আগে graft grep দিয়ে যাচাই করুন।
• Graph পুরোনো হয়ে গেছে, কিন্তু কেউ তা লক্ষ্য করেনি। Drift হলে graft check exit 1 দেয়। তবে এটি তখনই কার্যকর, যখন কোনো কিছু এটি চালায়। এটি অভ্যাসের ওপর নয়, hook বা CI step-এর ওপর নির্ভর করা উচিত।
• Monorepo-তে scoping প্রয়োজন। একটি single-git monorepo workspace file, go.mod, pyproject.toml বা Cargo.toml অনুযায়ী স্বয়ংক্রিয়ভাবে ভাগ হয়। graft ask "..." --in services/billing/ query-কে একটি sub-project-এর মধ্যে সীমাবদ্ধ করে। প্রতিটি package-এর জন্য nested AGENTS.md file ব্যবহারের যে নীতি প্রযোজ্য, map-এর ক্ষেত্রেও একই নীতি প্রযোজ্য।
• Agent wiring উপেক্ষা করছে। Map ব্যবহার করা হচ্ছে কি না বোঝার আগে একটি বাস্তব session-এ tool call-গুলো দেখুন। Agent যদি এখনও grep চালায়, তাহলে বোঝা যায় যে এটি rules file পড়েনি।

FAQ

graft/ ফোল্ডারটি কি git-এ commit করা উচিত?

না। graft build আপনার .gitignore-এ স্বয়ংক্রিয়ভাবে graft/ যোগ করে, কারণ graph হলো node_modules-এর মতো পুনরায় তৈরি করা যায় এমন cache। প্রায় প্রতিটি edit-এ এটি পরিবর্তিত হয়। তাই এটি commit করলে শত শত generated file-এর মধ্যে প্রকৃত diff খুঁজে পাওয়া কঠিন হয়। Agent-দের graph-এর অস্তিত্ব জানায় এমন wiring commit করুন, যার মধ্যে AGENTS.md এবং .mcp.json রয়েছে, এবং প্রত্যেক teammate-কে স্থানীয়ভাবে graft build চালাতে দিন। প্রথম commit-এর আগে grep -n graft .gitignore এবং git status --short দিয়ে যাচাই করুন। কারণ কোনো file একবার যোগ করার পর git সেটিকে track করতে থাকে, এবং পরে .gitignore edit করলেও tracking বন্ধ হয় না।

Graft চালাতে কি অর্থ খরচ হয়?

Structural অংশটির জন্য খরচ নেই। graft build, graft ask, graft check এবং ছয়টি MCP retrieval tool হলো tree-sitter operation, যেগুলো কখনও model call করে না। graft build --deep হলো paid অংশ। এটি LLM-এর মাধ্যমে plain-English summary এবং প্রতি symbol-এর crux লেখে। এটি GRAFT_PROVIDER, GRAFT_API_KEY এবং GRAFT_MODEL দিয়ে configure করা হয়। যেকোনো OpenAI-compatible endpoint-এর জন্য GRAFT_BASE_URL ব্যবহার করা যায়। আপনি শুধু structure নিয়ে Graft চালাতে পারেন এবং graph-এর জন্য কোনো token খরচ নাও করতে পারেন।

আমার repository-তে codebase map আসলে কতটা সাশ্রয় করবে?

পরিমাপ না করে কেউ আপনাকে বলতে পারবে না। Project-এর প্রতিবেদনে নিজের 162-run sweep-এ 42% কম token ব্যবহারের কথা বলা হয়েছে। SWE-bench Verified-এ এই হার 23%। উভয় ফলাফলই এমন baseline-এর সঙ্গে তুলনা করা হয়েছে যেখানে কোনো map ছিল না। এগুলো vendor benchmark। এর একটি আংশিকভাবে Graft-এর নিজের repository-তে চালানো হয়েছে। কোনোটিই আপনার private code সম্পর্কে ফলাফল দেয় না। একই repeatable question map-সহ 3 বার এবং map ছাড়া 3 বার চালান। CLAUDE_CODE_ENABLE_TELEMETRY=1 এবং OTEL_METRICS_EXPORTER=console সেট রাখুন। তারপর input এবং cacheRead type-এর জন্য claude_code.token.usage-এর median তুলনা করুন।

আমি refactor করলে graph-এর কী হয়?

Structure নিজে পুনরায় parse হয়। Graft working tree-এর অবস্থা পরীক্ষা করে এবং শুধু পরিবর্তিত file-গুলো পুনরায় parse করে। তাই পরবর্তী query-তে প্রায় 3 ms overhead-এর মধ্যে rename ধরা পড়ে। এটি uncommitted কাজও দেখতে পায়, কারণ এটি git history নয়, file পড়ে। Model-লিখিত summary-গুলোই stale হয়ে যায়। প্রতিটি node তার source-এর content hash সংরক্ষণ করে। কোনো source পরিবর্তিত হলে node-টি নতুন করে লেখার পরিবর্তে stale হিসেবে চিহ্নিত হয়। পরিবর্তন দেখতে graft check . চালান। এরপর লিখিত অংশ refresh করতে graft build --deep চালান।

বর্তমানে কোন coding agent Graft ব্যবহার করতে পারে?

August 2026 অনুযায়ী graft init Claude Code, Cursor, Codex, GitHub Copilot, Google Gemini, Kiro, Windsurf এবং AdaL-এর জন্য wiring তৈরি করে। Claude Code সবচেয়ে বেশি integration পায়: .mcp.json-এ একটি MCP server entry, একটি statusline, post-edit hook এবং .claude/-এর অধীনে একটি skill file। Codex-এর জন্য AGENTS.md section এবং ~/.codex/-এর অধীনে machine-wide entry তৈরি হয়। graft init --no-global এগুলো বাদ দেয়। অন্যগুলো rules বা steering file পায়। অন্য যেকোনো MCP client command npx -y @nanonets/graft@0.10.1 mcp register করে সরাসরি server ব্যবহার করতে পারে।