آپدیت خودکار AGENTS.md با ابزار dox

چرا فایل AGENTS.md شما پس از سه هفته اشتباه است

فایل AGENTS.md به این دلیل قدیمی می‌شود که هیچ ارتباطی با کد ندارد. شما آن را یک‌بار و به‌صورت دستی در روزی که مخزن وضعیت خاصی دارد، می‌نویسید. سپس runner تست تغییر می‌کند، نام یک پکیج عوض می‌شود، یک سرویس حذف می‌گردد، اما فایل همچنان وضعیت ماه ژوئن را توصیف می‌کند. هیچ‌چیز با شکست مواجه نمی‌شود، چون هیچ مرحله‌ای از build آن را نمی‌خواند.

عامل (agent) آن را می‌خواند و باور می‌کند. این همان بخشی است که برای شما هزینه دارد. مخزنی که فاقد AGENTS.md باشد، باعث می‌شود عامل کدنویسی پیش از اقدام، محیط را بررسی کند. مخزنی که AGENTS.md اشتباه دارد، باعث می‌شود عامل از بررسی دست بکشد، چون از قبل پاسخ را در اختیار دارد. عامل دستوری که در فایل شما نام برده شده را اجرا می‌کند، shell پاسخ Missing script: "test" را برمی‌گرداند و حالا عامل شروع به حدس زدن می‌کند. اغلب اوقات، عامل فایل package.json را ویرایش می‌کند تا اسکریپتی که در مستندات وعده داده شده بود را اضافه کند. فایل قدیمی به‌آرامی شکست نخورد؛ بلکه باعث ویرایشی شد که شما نمی‌خواستید.

dox یکی از پاسخ‌ها به این مشکل است. این ابزار مجموعه‌ای از قوانین است که برای عامل نوشته شده و به‌روزرسانی مستندات را به بخشی از پایان کار تبدیل می‌کند، به‌طوری که فایل در همان commit تغییر می‌کند که کدِ تغییریافته در آن قرار دارد.

dox چیست و چه چیزی نیست

dox یک فایل Markdown واحد است. مخزن آن agent0ai/dox است، تحت مجوز MIT منتشر شده و تا تاریخ 11 August 2026، کل پروژه شامل یک AGENTS.md به حجم 3906 بایت، یک فایل README، یک فایل LICENSE و دو تصویر است. هیچ بسته‌ای برای نصب و هیچ runtimeای وجود ندارد.

این موضوع اهمیت دارد، زیرا کلمه «generator» (مولد) ممکن است برنامه‌ای را در ذهن تداعی کند که کد شما را تجزیه (parse) می‌کند. هیچ چیزی کد شما را تجزیه نمی‌کند. dox یک قرارداد است که عامل (agent) برنامه‌نویسی شما آن را می‌خواند: عامل شما همان مولد است و dox مجموعه‌دستورالعملی است که به آن می‌گوید چه زمانی مستندات را بخواند، چه زمانی آن‌ها را بازنویسی کند و هر سند چه ساختاری داشته باشد.

این فایل ده بخش دارد که دو بخش آن وظیفه اصلی را بر عهده دارند. بخش "Read Before Editing" به عامل دستور می‌دهد که از ریشه مخزن تا هر مسیری که قصد تغییر در آن را دارد حرکت کند و در هر نشست (session)، بدون تکیه بر حافظه، تمام فایل‌های AGENTS.md را در طول مسیر بخواند. بخش "Update After Editing" به عامل می‌گوید که هر تغییر معنادار نیازمند یک مرحله DOX است؛ به این معنی که پیش از آنکه یک تسک «انجام‌شده» تلقی شود، باید یک مرحله به‌روزرسانی مستندات اجرا گردد. این مرحله، نزدیک‌ترین سند مالک را در صورتی که هدف، ساختار، گردش‌کار، مجوزها یا ترجیحات کاربر تغییر کرده باشد، به‌روز می‌کند.

بقیه بخش‌ها مربوط به ساختار هستند. یک فایل AGENTS.md فرزند، ترتیب بخش‌های پیش‌فرضی دارد: هدف، مالکیت، قراردادهای محلی، راهنمای کار، تاییدیه و فهرست DOX فرزند. فایل ریشه شامل قوانین کل پروژه به همراه فهرست DOX فرزند در سطح بالا است که عامل از طریق آن اسناد فرزند را کشف می‌کند. "Closeout" چک‌لیستی است که عامل در پایان یک تسک اجرا می‌کند: بررسی مجدد مسیرهای تغییریافته در زنجیره، به‌روزرسانی نزدیک‌ترین اسناد مالک، تازه‌سازی تمام فهرست‌های تحت‌تاثیر، حذف تناقضات، اجرای تاییدیه موجود و گزارش اینکه کدام اسناد را عمداً تغییر نداده است.

پین کردن مستندات به یک commit مشخص، نه به main

این مخزن هیچ تگ یا release ندارد، بنابراین شماره نسخه‌ای برای پین کردن وجود ندارد. در عوض، commit را پین کنید. فایل 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 باید مقدار 3906 را چاپ کند. هر عدد متفاوتی به این معناست که شما فایلی که این راهنما توصیف می‌کند را دریافت نکرده‌اید؛ پس پیش از اعتماد به آن، راهنما را مطالعه کنید. اگر هش commit را اشتباه تایپ کنید، -f باعث می‌شود curl با خطای curl: (22) The requested URL returned error: 404 متوقف شده و هیچ محتوایی ننویسد، سپس wc -c مقدار 0 را چاپ می‌کند. یک فایل ناقص (truncated) از نبود فایل بدتر است، زیرا عامل (agent) بدون اطلاع، نیمی از یک قرارداد را اجرا می‌کند.

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 برای مخزنی است که هنوز AGENTS.md ندارد. اگر از قبل فایلی دارید، آن را بازنویسی نکنید. بخش‌های مستندات (dox) را بالای محتوای فعلی خود قرار دهید، قوانین خود را در پایین نگه دارید و نتیجه را یک‌بار از ابتدا تا انتها بخوانید. دو سند که با هم تناقض دارند، عاملی تولید می‌کنند که از آخرین خطی که خوانده است پیروی می‌کند.

سپس در داخل مخزن، از عامل خود بخواهید اولین مرحله را انجام دهد. فایل README عبارت دقیق آن را ارائه می‌دهد:

Initialize DOX tree for this project now.

این دستور فایل‌های AGENTS.md فرزند و نمایه‌هایی (index) که به آن‌ها اشاره می‌کنند را ایجاد می‌کند. پیش از اعتماد به نتیجه، بررسی کنید که چه کاری انجام داده است:

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

هر فایلی که در خروجی find دیده می‌شود باید در یک نمایه مستندات فرزند (Child DOX Index) در جایی بالاتر از آن ظاهر شود. سند فرزندی که در هیچ نمایه‌ای ذکر نشده باشد، ممکن است توسط عامل نادیده گرفته شود، زیرا نمایه تنها راهی است که عامل از طریق آن اسنادی را که مستقیماً در مسیر پیمایش او قرار ندارند، پیدا می‌کند.

آنچه dox می‌بیند و آنچه نمی‌تواند بداند

عاملی که درخت شما را می‌سازد، مخزن را می‌خواند؛ بنابراین هر چیزی در مخزن می‌تواند وارد فهرست موجودی شود: ساختار دایرکتوری، مانیفست‌های بسته و فایل‌های lock، اسکریپت‌های موجود در package.json یا Makefile یا pyproject.toml، فایل‌های گردش کار CI، فایل‌های Dockerfile، نقاط ورود (entry points) و CODEOWNERS اگر یکی داشته باشید. فهرست موجودی که از این موارد ساخته شود، به‌طور واقعی خودنگهدار است. وقتی بسته‌ای جابه‌جا می‌شود، اجرای بعدی، خطی که آن را توصیف می‌کند نیز جابه‌جا می‌کند.

همه موارد زیر بر عهده شماست که بیان کنید، زیرا در مخزن وجود ندارند تا خوانده شوند:

• دلیل وجود یک قانون؛ این همان چیزی است که مانع از آن می‌شود که عامل، آن را به عنوان پیچیدگی غیرضروری حذف کند.
• اینکه کدام‌یک از دو مسیر کاری پشتیبانی می‌شود و کدام‌یک در انتظار حذف است.
• هر چیزی خارج از مخزن، مانند محیط staging یا دلیلی که یک وابستگی (dependency) دو نسخه عقب‌تر پین شده است.
• آنچه قصد دارید هفته آینده انجام دهید؛ این تفاوت بین فایلی است که به‌روز است و فایلی که مفید است.

dox این موضوع را درباره خودش می‌داند. قوانین خودِ آن می‌گویند که راهنمای کار (Work Guidance) باید منعکس‌کننده استانداردهای فعلی پروژه یا دستورالعمل‌های کاربر باشد و اگر هنوز هیچ‌کدام وجود ندارند، باید آن بخش را خالی بگذارید. تأییدیه (Verification) باید منعکس‌کننده یک بررسی موجود باشد، بنابراین اگر چارچوب تستی در مخزن نباشد، آن بخش تا زمانی که چارچوبی ایجاد نشود، خالی می‌ماند. یک فایل تولیدشده که استانداردی را از خود می‌سازد، بدتر از یک بخش خالی است، زیرا عامل پس از آن، همان استاندارد ابداعی را اعمال خواهد کرد.

حفظ قصد و نیت انسانی خارج از موجودی تولیدشده

این همان شکستی است که باعث می‌شود افراد از مستندات تولیدشده ناامید شوند. شما پاراگرافی می‌نویسید که توضیح می‌دهد صف کارها باید تک‌مصرف‌کننده باقی بماند. سه هفته بعد، یک پردازش فایل را بازنویسی می‌کند و پاراگراف شما از بین می‌رود، آن هم در میان یک diff چهل‌خطی که عمدتاً نام فایل‌ها را جابه‌جا کرده است و هیچ‌کس متوجه آن نمی‌شود.

دو مکانیزم وجود دارد و شما به هر دو نیاز دارید.

نخست، قصد و نیت پایدار را به فایلی متفاوت منتقل کنید. تصمیمات طراحی و استدلال‌های پشت آن‌ها متعلق به یک فایل DESIGN.md نوشته‌شده برای عامل است و یادداشت‌هایی که برای انسان‌ها وجود دارند، متعلق به جایی هستند که شما فایل HUMAN.md را از AGENTS.md جدا می‌کنید. در نتیجه، فایل AGENTS.md موجودی و قراردادهای محلی را در خود نگه می‌دارد که دقیقاً همان بخشی است که با تغییر کد باید تغییر کند.

دوم، قصد و نیتی که باید داخل AGENTS.md باقی بماند را محصور کنید. آن را در نشانگرها قرار دهید و با آن بلوک به عنوان محتوای تحت مالکیت انسان رفتار کنید:

## 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 در صفحه نمایش داده نمی‌شوند و عامل همچنان آن‌ها را می‌خواند. حالا بقای این بلوک را قابل بررسی کنید تا پردازشی که آن را حذف می‌کند، با صدای بلند شکست بخورد. این دستور را در CI (یکپارچه‌سازی مداوم) در هر pull request اجرا کنید:

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

دستور diff در صورتی که بلوک دست‌نخورده باقی بماند، هیچ خروجی چاپ نمی‌کند و با کد 0 خارج می‌شود. هرگونه خروجی به این معنی است که پردازش، متن تحت مالکیت انسان را بازنویسی کرده است، بنابراین یک شخص باید آن را تأیید یا بازگردانی (revert) کند. این بررسی بدون نیاز به اینکه کسی آن را به خاطر بسپارد، برقرار می‌ماند.

بازسازی در pull request، نه بر اساس زمان‌بندی

بهترین زمان برای به‌روزرسانی یک سند، همان commitای است که باعث قدیمی شدن آن شده است. مرحله DOX را در همان pull request مربوط به تغییرات ساختاری قرار دهید تا تفاوت (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) خود تنظیم کنید. ارزش این کار در این است که در همان branch شکست می‌خورد، جایی که اصلاح آن کم‌هزینه است و به دلیلی شکست می‌خورد که بازبین (reviewer) می‌تواند برای آن اقدام کند.

زمان‌بندی (schedule) یک پشتیبان است، نه مکانیزم اصلی. یک job هفتگی مواردی را پیدا می‌کند که کسی در branch متوجه نشده است: فایل‌هایی که با rebase جابه‌جا شده‌اند، بسته‌ای که در یک merge حذف شده، یا سندی که به دایرکتوری‌ای اشاره می‌کند که دیگر وجود ندارد. آن را روی یک ماشین کوچک اجرا کنید، همان ماشینی که ممکن است برای اجرای یک عامل کدنویسی روی VPS استفاده کنید، و به جای push کردن مستقیم به main، آن را وادار کنید یک 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

آن کامنت عمداً یک جای‌نگهدار (placeholder) است. هر عامل (agent) دارای CLI (رابط خط فرمان) و flag غیرتعاملی مخصوص به خود است، و دستوری که از یک صفحه وب کپی شده و با نسخه شما مطابقت ندارد، در cron شکست می‌خورد و هیچ‌کس متوجه خطا نمی‌شود. آن را تکمیل کنید و پیش از زمان‌بندی، اسکریپت را یک بار به‌صورت دستی اجرا کنید. مقدار || exit 0 نیز اهمیت دارد: git commit در صورتی که درخت (tree) از قبل به‌روز باشد با nothing to commit, working tree clean خارج می‌شود (exit non-zero)، و تحت set -e این موضوع یک اجرای سالم را به عنوان شکست گزارش می‌کند.

هر مرحله هزینه توکن دارد، زیرا "خواندن پیش از ویرایش" باعث می‌شود عامل در هر وظیفه، کل زنجیره را بخواند. این یک بده‌بستان است و اگر در حال حاضر هزینه‌های اجرای عامل خود را محاسبه می‌کنید، ارزش نظارت دارد.

مخازن یکپارچه (Monorepos): قراردادهای متعدد، یک فهرست

وجود یک فایل AGENTS.md در ریشهٔ مخزنی با 40 بسته، منجر به ایجاد یک diff برای بازتولید می‌شود که هیچ‌کس آن را نمی‌خواند و سندی تولید می‌کند که در لحظهٔ فعالیت عامل (agent)، عمدتاً بی‌ارتباط است. پاسخ dox در اینجا «فهرست فرزند DOX» است: ریشه شامل قوانین کلی مخزن است و به فرزندان خود اشاره می‌کند، و هر مرز پایدار، فایل اختصاصی خود را دارد. نحوهٔ چیدمان این درخت و ابزارهایی که فایل‌های تو در تو را می‌خوانند، در فایل‌های AGENTS.md تو در تو برای مخازن یکپارچه پوشش داده شده است.

آنچه dox تغییر می‌دهد، سطح بازبینی است. یک pull request که packages/api را تغییر می‌دهد، باید فقط یک diff مستندات در داخل packages/api ایجاد کند و نه جای دیگر:

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

اگر این دستور برای تغییری در یک بسته، 6 فایل را فهرست کند، ساختار درخت اشتباه است. یا مرزها بیش از حد کلی هستند، یا قانونی که متعلق به ریشه است در تمام فرزندان کپی شده است. dox راه‌حل را مستقیماً بیان می‌کند: قوانین گسترده در مستندات والد و جزئیات ملموس در مستندات فرزند قرار می‌گیرند. قوانین تکراری همان چیزی هستند که باعث می‌شوند یک بازنویسی روتین، همه چیز را تغییر دهد. اگر قوانین یکسانی واقعاً در مخازن جداگانه اعمال می‌شوند، این یک مسئله متفاوت است و به‌اشتراک‌گذاری مهارت‌های عامل بین مخازن ابزار بهتری برای آن است.

بازبینی تفاوت‌ها (diff) مانند کد

تأیید کردن تفاوت‌های تولیدشده در مستندات بدون خواندن آن‌ها آسان است، که همین امر باعث انتشار فایل‌های اشتباه می‌شود. تفاوت‌ها را با همان بدبینی که نسبت به کدهای تولیدشده دارید بخوانید و به چهار مورد زیر توجه کنید:

• دستوری که فایل اکنون نام می‌برد؛ پیش از ادغام (merge)، باید خودتان آن را اجرا کنید. دستورالعمل‌های ساخت (build) ابداعی، رایج‌ترین عامل شکست هستند.
• خط حذف‌شده‌ای که حاوی یک هدف یا قصد خاص بوده است. اضافه کردن خطوط هزینه کمی دارد، اما حذف کردن جایی است که اطلاعات از دست می‌رود.
• مسیر مطلق (absolute path)، نام میزبان (hostname)، آدرس URL داخلی یا هر چیزی که شبیه به اعتبارنامه (credential) باشد.
• ورودی موجودی (inventory) برای چیزی که دیگر وجود ندارد؛ موردی که ls در یک لحظه آن را حل‌وفصل می‌کند.

سپس حجم فایل را با wc -l AGENTS.md بررسی کنید. یک فایل ریشه (root file) با بیش از 200 خط، نشانه‌ای برای تقسیم کردن آن است؛ زیرا تمام ارزش این زنجیره در این است که عامل (agent) به جای خواندن همه چیز، بخش کوچک و مرتبط را مطالعه کند.

هنگام بروز خطا

فرایند، بلوک هدف شما را حذف کرده است. بررسی diff در بالا، خطوط حذف‌شده را نمایش می‌دهد. فایل را از نقطه شاخه با استفاده از git restore --source=origin/main AGENTS.md بازیابی کنید، سپس فرایند را با دستوری محدودتر که بخش‌های مجاز برای تغییر را نام می‌برد، دوباره اجرا کنید.

هر دو شاخه بازتولید شده‌اند. شما با CONFLICT (content): Merge conflict in AGENTS.md و نشانگرهای تداخل <<<<<<< HEAD در داخل فایل مواجه می‌شوید. نشانگرها را به‌صورت دستی ویرایش نکنید. از آنجا که فایل تولیدشده است، راه حل صحیح، اجرای مجدد فرایند روی درخت ادغام‌شده است.

عامل (Agent) فایل را کاملاً نادیده می‌گیرد. بررسی کنید ابزار شما در واقع کدام نام فایل را می‌خواند. اگر فایل متفاوتی را می‌خواند، با استفاده از ln -s AGENTS.md CLAUDE.md آن را به همان محتوا ارجاع دهید و symlink را commit کنید تا به‌جای دو سند که به‌مرور با هم اختلاف پیدا می‌کنند، یک منبع واحد داشته باشید.

درخت، فرزندانی ایجاد کرده که هیچ‌کس آن‌ها را نمایه‌سازی نکرده است. خروجی find . -name AGENTS.md را با ورودی‌های نمایه در اسناد والد مقایسه کنید. فرزندی که در هیچ نمایه‌ای ذکر نشده، فرزندی است که عامل از کنار آن به‌سادگی عبور می‌کند.

چه زمانی استفاده از generator زیاده‌روی است

یک پکیج، یک دستور تست، و دو نفر که هر دو مخزن را می‌شناسند: بیست خط کد را دستی بنویسید. یک فایل AGENTS.md بیست خطی آن‌قدر سریع دچار فرسودگی نمی‌شود که توجیه‌کننده ایجاد یک درخت، ایندکس، بررسی CI و یک job هفتگی باشد. هنگام تغییر build، آن را دوباره بخوانید. این تمام هزینه نگهداری است و از هزینه ماشین‌آلات پیرامون آن کمتر است.

هزینه کردن برای ابزارهای مستندسازی (dox) زمانی ارزشمند است که مخزن دارای مرزهایی باشد که هیچ‌کس به‌تنهایی در ذهن خود ندارد: چندین پکیج با قوانین متفاوت، یا مشارکت‌کنندگانی که بدون پیش‌زمینه وارد می‌شوند. ارزش کار در متن تولیدشده نیست. ارزش در این است که مستندات به چیزی تبدیل می‌شوند که یک pull request می‌تواند به دلیل آن رد شود؛ و این تنها دلیلی است که هر فایلی در یک مخزن به‌روز باقی می‌ماند.

FAQ

آیا برای استفاده از dox نیاز به نصب چیزی دارم؟

خیر. dox یک فایل Markdown واحد با مجوز MIT است و تا تاریخ 11 August 2026، این مخزن هیچ پکیج یا release ارائه نمی‌دهد. شما محتوای آن را در فایل AGENTS.md پروژه خود کپی می‌کنید و coding agent شما از قوانین موجود در آن پیروی می‌کند. commit کپی‌شده را که در زمان نگارش این متن f34ec7ad1055d3393887e5a2670e8cb7320c9165 است، pin کنید و آن را در پیام commit خود ذکر کنید تا بعداً بتوانید تشخیص دهید که درخت کد شما تحت کدام نسخه از قوانین ساخته شده است.

چگونه از حذف قوانین دست‌نویس خود هنگام بازتولید (regeneration) جلوگیری کنم؟

قصد (intent) و موجودی (inventory) را از هم جدا نگه دارید. استدلال‌های پایدار را در یک سند جداگانه قرار دهید و هر چیزی که باید حتماً داخل AGENTS.md باقی بماند را درون یک بلوک نشان‌گذاری‌شده قرار دهید. سپس آن بلوک را در CI بررسی کنید: آن را از branch و از origin/main با استفاده از sed استخراج کنید، این دو را با diff مقایسه کنید و در صورت وجود هرگونه تفاوت، build را با خطا مواجه کنید. در این صورت، یک شخص تغییر را تأیید یا رد می‌کند، به‌جای آنکه تغییرات به‌صورت ناخواسته در یک diff بزرگ نادیده گرفته شوند.

هر چند وقت یک‌بار باید AGENTS.md را بازتولید کنم؟

در pull requestی که باعث نادرست شدن آن شده است. یک تغییر ساختاری و مستندات مربوط به آن باید در یک diff واحد باشند، زیرا این تنها لحظه‌ای است که فردی زمینه کافی برای بازبینی هر دو را دارد. یک اجرای زمان‌بندی‌شدهٔ هفتگی برای اصلاح انحرافاتی که از چشم branchها دور مانده‌اند، نقش پشتیبان را دارد و بهتر است به‌جای commit مستقیم به main، یک pull request باز کند.

آیا دستورات build باید در AGENTS.md ریشه باشند یا در یک فایل فرزند؟

در نزدیک‌ترین سندی که مالک آن‌هاست. قوانین سراسری مخزن و فهرست فرزندان در ریشه قرار می‌گیرند. دستوری که فقط برای یک پکیج اعمال می‌شود، در AGENTS.md همان پکیج قرار می‌گیرد. dox تداخل‌ها را بر اساس فاصله حل می‌کند: سند نزدیک‌تر جزئیات محلی را کنترل می‌کند و هیچ فرزندی نمی‌تواند قانون والد را تضعیف کند. کپی کردن یک دستور مشابه در تمام فرزندان، همان چیزی است که باعث می‌شود یک اجرای روتین، کل درخت را بازنویسی کند.

آیا استفاده از dox برای یک مخزن کوچک ارزش دارد؟

معمولاً خیر. یک پکیج با یک دستور تست و یک فایل AGENTS.md بیست‌خطی به‌کندی دچار فرسایش می‌شود و می‌توانید آن را در همان دقیقه‌ای که متوجه شدید، اصلاح کنید. dox زمانی هزینه خود را جبران می‌کند که مخزن دارای چندین مرز با قوانین متفاوت باشد، یا مشارکت‌کنندگانی داشته باشد که پیش‌زمینه کافی ندارند؛ زیرا در آن صورت، زنجیره اسناد کاری را انجام می‌دهد که هیچ فرد واحدی قادر به انجام آن نیست.