dox দিয়ে AGENTS.md স্বয়ংক্রিয়ভাবে আপডেট রাখুন

তিন সপ্তাহ পরে আপনার AGENTS.md কেন ভুল

AGENTS.md ফাইল stale হয়ে যায়, কারণ এটিকে code-এর সঙ্গে সংযুক্ত রাখার কোনো ব্যবস্থা নেই। repository যে অবস্থায় ছিল, সেই দিনের snapshot দেখে আপনি হাতে একবার এটি লেখেন। এরপর test runner পরিবর্তিত হয়, কোনো package-এর নাম বদলে যায়, কোনো service মুছে ফেলা হয়, কিন্তু ফাইলটি তখনও জুন মাসের অবস্থা বর্ণনা করে। কিছুই ব্যর্থ হয় না, কারণ কোনো build step এটি পড়ে না।

agent এটি পড়ে এবং তথ্যটি সঠিক বলে ধরে নেয়। সমস্যার মূল খরচ এখানেই। কোনো AGENTS.md না থাকা repository-তে coding agent কাজ শুরু করার আগে পরিস্থিতি যাচাই করে। ভুল AGENTS.md থাকা repository-তে agent আর যাচাই করে না, কারণ তার কাছে ইতিমধ্যেই একটি উত্তর আছে। এটি আপনার ফাইলে উল্লেখ করা command চালায়, shell Missing script: "test" উত্তর দেয়, এবং তখন agent অনুমান করতে শুরু করে। অনেক সময় আপনার documentation-এ প্রতিশ্রুত script যোগ করতে এটি package.json সম্পাদনা করে। stale ফাইলটি নীরবে ব্যর্থ হয়নি। এটি এমন একটি edit ঘটিয়েছে, যা আপনি চাননি।

dox এর একটি সমাধান দেয়। এটি agent-এর জন্য লেখা এক সেট নিয়ম। এই নিয়ম documentation update-কে কাজ শেষ করার অংশ করে, যাতে যে code ফাইলটিকে ভুল করেছে, সেই code-এর commit-এই documentation ফাইলটিও পরিবর্তিত হয়।

dox কী এবং এটি কী নয়

dox একটি একক Markdown ফাইল। Repository হলো agent0ai/dox, এর লাইসেন্স MIT, এবং 11 August 2026 অনুযায়ী পুরো project-এ একটি 3906-byte AGENTS.md, একটি README, একটি LICENSE এবং দুটি image আছে। Install করার মতো কোনো package নেই এবং কোনো runtime-ও নেই।

এটি গুরুত্বপূর্ণ, কারণ generator শব্দটি এমন একটি program বোঝায় যা আপনার code parse করে। কিছুই আপনার code parse করে না। dox হলো আপনার coding agent যে contract পড়ে: আপনার agent-ই generator, আর dox হলো সেই instruction set যা agent-কে বলে কখন docs পড়তে হবে, কখন সেগুলো rewrite করতে হবে এবং প্রতিটি document-এর কাঠামো কেমন হবে।

ফাইলটিতে দশটি section আছে এবং এর মধ্যে দুটি মূল কাজ করে। "সম্পাদনার আগে পড়ুন" agent-কে বলে repository root থেকে সে যেসব path পরিবর্তন করার পরিকল্পনা করেছে, সেগুলোর প্রতিটি পর্যন্ত যেতে এবং প্রতিটি route-এ থাকা সব AGENTS.md বর্তমান session-এ পড়তে; memory-এর ওপর নির্ভর করা যাবে না। "সম্পাদনার পরে update করুন" জানায় যে প্রতিটি অর্থপূর্ণ পরিবর্তনের জন্য একটি DOX pass আবশ্যক। অর্থাৎ task সম্পন্ন হয়েছে বলে গণ্য করার আগে documentation update step চালাতে হবে। Purpose, structure, workflow, permissions বা user preferences পরিবর্তিত হলে এই pass সবচেয়ে কাছের owning document update করে।

বাকিগুলো কাঠামো নির্ধারণ করে। একটি child AGENTS.md-তে default section order হলো: Purpose, Ownership, Local Contracts, Work Guidance, Verification এবং Child DOX Index। root file-এ project-wide rules এবং top-level Child DOX Index থাকে। এর মাধ্যমেই agent child document-গুলো খুঁজে পায়। "Closeout" হলো task-এর শেষে agent যে checklist চালায়: chain-এর সঙ্গে পরিবর্তিত path-গুলো আবার যাচাই করা, সবচেয়ে কাছের owning docs update করা, প্রভাবিত প্রতিটি index refresh করা, contradiction মুছে ফেলা, বিদ্যমান verification চালানো এবং ইচ্ছাকৃতভাবে কোন docs অপরিবর্তিত রাখা হয়েছে তা report করা।

main-এর পরিবর্তে একটি commit-এ dox pin করুন

Repository-তে কোনো tag বা release নেই, তাই pin করার মতো কোনো version number নেই। এর পরিবর্তে commit-টি pin করুন। বর্তমান AGENTS.md হলো commit f34ec7ad1055d3393887e5a2670e8cb7320c9165, যার তারিখ 1 August 2026।

mkdir -p .agent
curl -fsSL -o .agent/dox-f34ec7a.md \
  https://raw.githubusercontent.com/agent0ai/dox/f34ec7ad1055d3393887e5a2670e8cb7320c9165/AGENTS.md
wc -c .agent/dox-f34ec7a.md

wc -c-এর output হিসেবে 3906 দেখানো উচিত। ভিন্ন কোনো number দেখালে বুঝবেন, এই guide-এ বর্ণিত file fetch করা হয়নি। তাই file-টি যাচাই না করে বিশ্বাস করবেন না। Commit hash ভুল লিখলে -f curl-কে curl: (22) The requested URL returned error: 404 দিয়ে থামিয়ে দেয় এবং কোনো content লেখে না। এরপর wc -c 0 দেখায়। কোনো file না থাকার চেয়ে আংশিক file বেশি বিপজ্জনক, কারণ agent অর্ধেক contract অনুসরণ করে, কিন্তু তা সম্পূর্ণ নয়—এটি বুঝতে পারে না।

cp .agent/dox-f34ec7a.md AGENTS.md
git add AGENTS.md .agent/dox-f34ec7a.md
git commit -m "Add DOX rules (agent0ai/dox @ f34ec7a)"

এই cp এমন repository-এর জন্য, যেখানে এখনো কোনো AGENTS.md নেই। আগে থেকেই একটি থাকলে সেটি overwrite করবেন না। বিদ্যমান content-এর ওপরে dox section-গুলো রাখুন, নিজের rules নিচে রাখুন, এবং ফলাফলটি শুরু থেকে শেষ পর্যন্ত একবার পড়ুন। পরস্পরবিরোধী দুটি document থাকলে agent সর্বশেষ পড়া line-টি অনুসরণ করতে পারে।

এরপর repository-এর ভেতরে আপনার agent-কে প্রথম pass তৈরি করতে বলুন। README-তে সঠিক wording দেওয়া আছে:

Initialize DOX tree for this project now.

এটি child AGENTS.md file এবং সেগুলোর দিকে নির্দেশ করা index তৈরি করে। বিশ্বাস করার আগে এটি কী করেছে তা যাচাই করুন:

git status --short
find . -name AGENTS.md -not -path './.git/*' | sort

ওই find output-এর প্রতিটি file-এর নাম উপরের কোথাও একটি Child DOX Index-এ থাকা উচিত। কোনো index-এ উল্লেখ না থাকা child document agent এড়িয়ে যেতে পারে, কারণ যে document agent যে path দিয়ে এগোচ্ছে তার সরাসরি ওপরের অংশে নেই, সেটি খুঁজে পাওয়ার উপায় হলো index।

dox কী দেখতে পারে এবং কী জানতে পারে না

আপনার inventory তৈরি করা agent repository পড়ে। তাই repository-তে থাকা যেকোনো তথ্য inventory-তে যুক্ত হতে পারে: directory layout, package manifest ও lockfile, package.json, Makefile বা pyproject.toml-এর script, CI workflow file, Dockerfile, entry point এবং আপনার থাকলে CODEOWNERS। এগুলো থেকে তৈরি inventory সত্যিই নিজে রক্ষণাবেক্ষণযোগ্য। কোনো package সরলে পরবর্তী pass-এ সেটি বর্ণনা করা line-ও সরে যায়।

নিচের প্রতিটি বিষয় আপনাকেই উল্লেখ করতে হবে, কারণ এগুলো repository-তে নেই এবং পড়া যায় না:

• কোনো rule কেন আছে; এটাই agent-কে সেটিকে অপ্রয়োজনীয় জটিলতা ভেবে সরিয়ে ফেলা থেকে বিরত রাখে
• কাজ করা দুটি path-এর মধ্যে কোনটি সমর্থিত এবং কোনটি সরিয়ে ফেলার অপেক্ষায় আছে
• repository-এর বাইরের যেকোনো বিষয়, যেমন staging environment বা কোনো dependency-কে দুই version পিছনে pin করে রাখার কারণ
• আগামী সপ্তাহে আপনি কী করতে চান; এটিই নির্ধারণ করে কোনো file কেবল বর্তমান অবস্থার বর্ণনা দেবে, নাকি বাস্তবে উপযোগী হবে

dox নিজের এই সীমাবদ্ধতা জানে। এর নিজস্ব rule-এ বলা আছে, Work Guidance-এ project-এর বর্তমান standard বা user-এর instruction প্রতিফলিত হতে হবে। এখনো কোনোটি না থাকলে section-টি খালি রাখতে হবে। Verification-এ বিদ্যমান check প্রতিফলিত হতে হবে। তাই repository-তে test framework না থাকলে সেটিও খালি থাকবে, যতক্ষণ না test framework যোগ হয়। কোনো standard বানিয়ে ফেলা generated file খালি section-এর চেয়ে খারাপ, কারণ তখন agent সেই বানানো standard প্রয়োগ করবে।

উৎপন্ন inventory-তে হাতে লেখা অভিপ্রায় রাখবেন না

এটাই সেই ব্যর্থতা, যার কারণে মানুষ generated documentation তৈরি করা ছেড়ে দেয়। আপনি একটি paragraph লিখলেন যে jobs queue-তে single consumer বজায় রাখতে হবে। তিন সপ্তাহ পরে একটি pass file-টি আবার লিখল, এবং আপনার paragraph হারিয়ে গেল। এটি এমন একটি diff-এর মধ্যে ঘটল, যেখানে 40টি line-এর বেশির ভাগই শুধু file name-এর বিন্যাস বদলেছে, আর কেউ বিষয়টি ধরতে পারেনি।

দুটি ব্যবস্থা নিন, এবং দুটিই ব্যবহার করুন।

প্রথমে, স্থায়ী অভিপ্রায় একটি আলাদা file-এ রাখুন। Design decision এবং তার পেছনের reasoning agent-এর জন্য লেখা DESIGN.md-তে রাখুন, আর মানুষের জন্য থাকা notes AGENTS.md থেকে HUMAN.md-তে আলাদা করুন। AGENTS.md-তে তখন inventory এবং local contract থাকবে। Code পরিবর্তিত হলে মূলত এই অংশই পরিবর্তন হওয়া উচিত।

দ্বিতীয়ত, AGENTS.md-র ভেতরেই যে অভিপ্রায় রাখতে হবে, সেটিকে সুরক্ষিত করুন। সেটিকে marker দিয়ে ঘিরে human-owned block হিসেবে বিবেচনা করুন:

## User Preferences

<!-- dox:keep start -->
The jobs queue stays single consumer. Ordering is the reason this service exists.
Deploys ship on Tuesday. A Friday deploy is a human decision, not an agent decision.
<!-- dox:keep end -->

Markdown comment page-এ render হয় না, কিন্তু agent সেগুলো পড়তে পারে। এবার block-টি টিকে আছে কি না তা পরীক্ষা করার ব্যবস্থা করুন, যাতে কোনো pass সেটি মুছে ফেললে স্পষ্টভাবে ব্যর্থ হয়। প্রতিটি pull request-এ CI (continuous integration)-তে এটি চালান:

git fetch -q origin main
sed -n '/dox:keep start/,/dox:keep end/p' AGENTS.md > /tmp/keep.head
git show origin/main:AGENTS.md | sed -n '/dox:keep start/,/dox:keep end/p' > /tmp/keep.base
diff -u /tmp/keep.base /tmp/keep.head

Block অপরিবর্তিত থাকলে diff কিছু print করে না এবং 0 exit code দিয়ে শেষ হয়। কোনো output পাওয়া গেলে বুঝবেন pass human-owned text পুনরায় লিখেছে। তখন কোনো ব্যক্তি সেটি approve করবেন অথবা revert করবেন। কাউকে এটি মনে রাখতে না হলেও এই check কার্যকর থাকবে।

টাইমারের ভিত্তিতে নয়, pull request-এ পরিবর্তনের সময় regenerate করুন

কোনো document ভুল হয়ে যাওয়ার কারণ যে commit-এ তৈরি হয়, সেটিই document refresh করার সেরা সময়। Structural change-এর একই pull request-এ DOX pass রাখুন। তাহলে diff এত ছোট থাকে যে তা বাস্তবে পড়া যায়।

এটি প্রয়োগ করার জন্য একটি blocking check:

#!/usr/bin/env bash
set -euo pipefail
git fetch -q origin main
base=$(git merge-base origin/main HEAD)
changed=$(git diff --name-only "$base" HEAD)
if grep -qE '^(src|apps|packages)/' <<<"$changed" && ! grep -q 'AGENTS\.md$' <<<"$changed"; then
  echo "Code changed but no AGENTS.md was touched. Run a DOX pass, or say why not."
  exit 1
fi

আপনার repository অনুযায়ী path পরিবর্তন করুন। এর সুবিধা হলো, branch-এই check ব্যর্থ হয়, যেখানে fix করা সহজ। ব্যর্থতার কারণও এমন থাকে, যার ভিত্তিতে reviewer ব্যবস্থা নিতে পারেন।

Schedule হলো backup, mechanism নয়। একটি weekly job branch-এ কেউ লক্ষ্য না করা বিষয়গুলো ধরতে পারে: rebase-এর কারণে সরানো file, merge-এ মুছে যাওয়া package, অথবা এমন document যেখানে আর বিদ্যমান নয় এমন directory-এর নাম আছে। এটি একটি ছোট box-এ চালান। আপনি যে একই box-এ VPS-এ coding agent চালাতে পারেন, সেটিই ব্যবহার করতে পারেন। এটি main-এ push না করে একটি pull request খুলবে।

#!/usr/bin/env bash
set -euo pipefail
cd /srv/src/myapp
git fetch -q origin
git switch -c "dox/refresh-$(date +%Y%m%d)" origin/main
# Your agent CLI goes on the next line, in whatever non-interactive mode it offers.
# Prompt: "Run a DOX pass over this repository. Change AGENTS.md files only."
git add '*AGENTS.md'
git commit -m "dox: refresh AGENTS.md tree" || { echo "nothing to refresh"; exit 0; }
git push -q -u origin HEAD
gh pr create --fill

এই comment-টি ইচ্ছাকৃতভাবে placeholder হিসেবে রাখা হয়েছে। প্রতিটি agent-এর নিজস্ব CLI (command line interface) এবং নিজস্ব non-interactive flag থাকে। আপনার version-এর সঙ্গে না মেলা কোনো web page থেকে copy করা command cron-এর মধ্যে ব্যর্থ হবে, আর সেখানে error দেখার কেউ থাকবে না। এটি পূরণ করে schedule করার আগে script-টি একবার হাতে চালান। || exit 0-ও গুরুত্বপূর্ণ: tree ইতিমধ্যে current থাকলে git commit, nothing to commit, working tree clean সহ non-zero exit করে। set -e-এর অধীনে এটি একটি সফল run-কেও failure হিসেবে report করবে।

প্রতিটি pass-এর জন্য token খরচ হয়, কারণ "Read Before Editing" নিয়মে agent-কে প্রতিটি task-এ পুরো chain পড়তে হয়। এটাই trade-off। আপনি যদি ইতিমধ্যে আপনার agent চালানোর খরচ গুনে থাকেন, তাহলে এটি নজরে রাখা সার্থক।

Monorepo: অনেক contract, একটি index

চল্লিশটি package থাকা একটি repository-তে root-এ একটি AGENTS.md রাখলে এমন regeneration diff তৈরি হয়, যা কেউ পড়ে না। এ ছাড়া agent বর্তমানে যে কাজটি করছে, document-এর অধিকাংশই তার জন্য প্রাসঙ্গিক নয়। dox-এর সমাধান হলো Child DOX Index: root-এ repository-জুড়ে প্রযোজ্য নিয়ম থাকবে এবং child-গুলোর দিকে নির্দেশ করবে। প্রতিটি স্থায়ী boundary নিজের file-এর মালিক হবে। এই tree কীভাবে সাজাতে হবে এবং কোন tool nested file পড়ে, তা monorepo-র nested AGENTS.md file-এ ব্যাখ্যা করা হয়েছে।

dox যে পরিবর্তন আনে, তা হলো review surface। packages/api-এ পরিবর্তন করা একটি pull request-এর documentation diff শুধু packages/api-এর ভিতরে থাকা উচিত:

git diff --stat -- '*AGENTS.md'

একটি package-এ পরিবর্তনের জন্য ওই command যদি ছয়টি file দেখায়, তাহলে tree সঠিকভাবে সাজানো হয়নি। হয় boundary-গুলো অতিরিক্ত বড়, নয়তো root-এ থাকা উচিত এমন কোনো rule প্রতিটি child-এ কপি করা হয়েছে। dox সরাসরি সমাধানটি বলে: বিস্তৃত rule parent doc-এ রাখুন, আর নির্দিষ্ট বিবরণ child doc-এ রাখুন। Duplicate rule-ই একটি সাধারণ pass-কে সবকিছু rewrite করতে বাধ্য করে। একই rule যদি সত্যিই আলাদা repository-জুড়ে প্রযোজ্য হয়, তাহলে সেটি ভিন্ন সমস্যা; সে ক্ষেত্রে repository-গুলোর মধ্যে agent skill share করা বেশি উপযোগী tool।

কোডের মতো diff পর্যালোচনা করুন

পদ্ধতিগতভাবে তৈরি documentation diff না পড়েই অনুমোদন করা সহজ। এভাবেই ভুল file release পায়। Generated code পর্যালোচনার সময় যেমন সন্দেহপ্রবণ থাকেন, এটিও তেমনভাবে পড়ুন এবং চারটি বিষয় খুঁজুন।

• file-এ এখন উল্লেখ করা হয়েছে এমন কোনো command, যা merge করার আগে নিজে চালিয়ে দেখা উচিত। মনগড়া build instruction-ই সবচেয়ে সাধারণ ব্যর্থতার কারণ।
• intent বহন করা কোনো deleted line। Addition যোগ করা সহজ। ক্ষতি হয় deletion-এ।
• কোনো absolute path, hostname, internal URL অথবা credential-এর মতো দেখতে কোনো তথ্য
• এমন কোনো inventory entry, যা আর বিদ্যমান নেই এবং ls এটি এক সেকেন্ডেই নির্ণয় করে

এরপর wc -l AGENTS.md দিয়ে আকার পরীক্ষা করুন। দুইশোর বেশি line থাকা root file-কে বিভক্ত করার সংকেত হিসেবে ধরুন। কারণ এই chain-এর সম্পূর্ণ উপকার হলো agent যেন সবকিছু না পড়ে শুধু প্রাসঙ্গিক ছোট অংশটি পড়ে।

যখন এটি ব্যর্থ হয়

Pass আপনার intent block মুছে দিয়েছে। উপরের diff check মুছে যাওয়া লাইনগুলো দেখায়। git restore --source=origin/main AGENTS.md ব্যবহার করে branch point থেকে file পুনরুদ্ধার করুন। এরপর কোন section-গুলোতে পরিবর্তন করা যাবে তা স্পষ্টভাবে উল্লেখ করে pass আবার চালান।

দুটি branch-ই নতুন করে তৈরি করেছে। আপনি file-এর মধ্যে CONFLICT (content): Merge conflict in AGENTS.md এবং conflict marker <<<<<<< HEAD দেখতে পাবেন। Marker হাতে সম্পাদনা করবেন না। File-টি generated হওয়ায় সঠিক সমাধান হলো merged tree-এর ওপর নতুন করে pass চালানো।

Agent file-টি সম্পূর্ণ উপেক্ষা করছে। আপনার tool আসলে কোন filename পড়ে তা যাচাই করুন। এটি অন্য file পড়লে ln -s AGENTS.md CLAUDE.md ব্যবহার করে একই content-এর দিকে নির্দেশ করুন এবং symlink commit করুন। এতে পরস্পরের সঙ্গে অসামঞ্জস্যপূর্ণ দুটি document-এর বদলে একটি source বজায় থাকবে।

Tree-তে এমন child যুক্ত হয়েছে যেগুলো কেউ index করেনি। find . -name AGENTS.md output-এর সঙ্গে parent document-গুলোর index entry তুলনা করুন। কোনো index যে child-এর উল্লেখ করে না, agent সেটি সরাসরি এড়িয়ে যেতে পারে।

যখন generator ব্যবহার করা অতিরিক্ত হয়ে যায়

একটি package, একটি test command এবং repository সম্পর্কে সমানভাবে জানা দুইজন মানুষ থাকলে বিশটি line হাতে লিখুন। বিশ-লাইন-এর AGENTS.md এত দ্রুত পুরোনো হয় না যে তার জন্য tree, index, CI check এবং weekly job প্রয়োজন হবে। build পরিবর্তন করার সময় এটি আবার পড়ুন। এটাই সম্পূর্ণ maintenance cost, এবং এর চারপাশের machinery পরিচালনার cost-এর চেয়ে এটি কম।

repository-তে এমন boundary থাকলে dox ব্যবহার করা সার্থক, যেগুলো কোনো একক ব্যক্তি সম্পূর্ণভাবে মনে রাখতে পারেন না: ভিন্ন নিয়মের একাধিক package, অথবা এমন contributor, যিনি repository-টির প্রয়োজনীয় background ছাড়াই কাজ শুরু করেন। উপকার generated text-এ নয়। উপকার হলো documentation এমন কিছুর রূপ নেয়, যার কারণে একটি pull request fail করতে পারে। Repository-র কোনো file current থাকার একমাত্র কার্যকর কারণ এটিই।

FAQ

dox ব্যবহার করতে কি কিছু ইনস্টল করতে হবে?

না। dox একটি Markdown file, যার license MIT। 11 August 2026 পর্যন্ত repository-তে কোনো package বা release নেই। এর contents আপনার project-এর AGENTS.md-এ copy করুন, তারপর আপনার coding agent সেখানকার rules অনুসরণ করবে। আপনি যে commit copy করেছেন সেটি pin করুন, লেখার সময় যা হলো f34ec7ad1055d3393887e5a2670e8cb7320c9165, এবং commit message-এ সেটির নাম লিখুন। তাহলে পরে বোঝা যাবে, আপনার tree কোন version-এর rules-এর ভিত্তিতে তৈরি হয়েছিল।

regeneration-এর কারণে হাতে লেখা rules মুছে যাওয়া কীভাবে বন্ধ করব?

উদ্দেশ্য এবং inventory আলাদা রাখুন। স্থায়ী reasoning একটি আলাদা document-এ রাখুন। AGENTS.md-এর ভেতরে যেগুলো অবশ্যই রাখতে হবে, সেগুলো একটি চিহ্নিত block-এর মধ্যে রাখুন। এরপর CI-তে block-টি পরীক্ষা করুন: branch এবং origin/main থেকে এটি sed দিয়ে extract করুন, diff দিয়ে দুটির তুলনা করুন, এবং কোনো পার্থক্য থাকলে build ব্যর্থ করুন। বড় diff-এর মধ্যে পরিবর্তনটি অগোচরে চলে যাওয়ার বদলে একজন ব্যক্তি তখন সেটি approve বা revert করতে পারবেন।

কত ঘন ঘন AGENTS.md পুনরায় তৈরি করা উচিত?

যে pull request-এ এটি ভুল হয়ে যায়, সেই pull request-এই। কোনো structural change এবং তার documentation একই diff-এ থাকা উচিত, কারণ উভয়টি review করার প্রাসঙ্গিক তথ্য তখনই থাকে। branch থেকে বাদ পড়া drift ধরার জন্য weekly scheduled pass একটি backup হিসেবে কাজ করবে। এটি main-এ commit না করে একটি pull request খোলা উচিত।

build command-গুলো root AGENTS.md-এ থাকবে, নাকি child document-এ?

যে document সেগুলোর মালিক, তার মধ্যে সবচেয়ে কাছের document-এ রাখুন। Repository-ব্যাপী rules এবং child index root-এ থাকবে। শুধু একটি package-এর জন্য প্রযোজ্য command সেই package-এর AGENTS.md-এ থাকবে। dox দূরত্ব অনুযায়ী conflict সমাধান করে: কাছের document স্থানীয় detail নিয়ন্ত্রণ করে, তবে কোনো child parent rule দুর্বল করতে পারে না। একই command প্রতিটি child-এ copy করলেই routine pass পুরো tree rewrite করে।

ছোট repository-এর জন্য dox কি উপযোগী?

সাধারণত নয়। একটি test command-সহ একটি package এবং বিশ লাইন-দৈর্ঘ্যের AGENTS.md ধীরে পুরোনো হয়। বিষয়টি বুঝতে পারার পরের মিনিটেই আপনি এটি ঠিক করতে পারেন। Repository-তে ভিন্ন rules-সহ একাধিক boundary থাকলে, অথবা background knowledge কম থাকা contributor থাকলে, dox-এর খরচ সার্থক হয়। কারণ তখন document-গুলোর chain এমন কাজ করে, যা কোনো একক ব্যক্তি একা করছেন না।