بازگشت به مهندسی مدرن و کار با هوش مصنوعی · فصل ۳ — Repository، Root Cause، Testing و Verification · 16
راستی‌آزمایی فنی و مهندسی مبتنی بر مستندات
مفهوم را می‌شناسد اما هنوز آن را به یک عادت مهندسی قابل اثبات در پروژه‌ی واقعی تبدیل نکرده است. موضوع جاری: «راستی‌آزمایی فنی و مهندسی مبتنی بر مستندات». می‌تواند در یک سناریوی محدود «راستی‌آزمایی فنی و مهندسی مبتنی بر مستندات» را اجرا کند، مرز ادعا را مشخص کند و evidence قابل بررسی تحویل دهد.
Verify technical engineering claims against authoritative documentation — en-US
خلاصهٔ درس
مفهوم را می‌شناسد اما هنوز آن را به یک عادت مهندسی قابل اثبات در پروژه‌ی واقعی تبدیل نکرده است. موضوع جاری: «راستی‌آزمایی فنی و مهندسی مبتنی بر مستندات».
می‌تواند در یک سناریوی محدود «راستی‌آزمایی فنی و مهندسی مبتنی بر مستندات» را اجرا کند، مرز ادعا را مشخص کند و evidence قابل بررسی تحویل دهد.
خروجی این درس
می‌تواند در یک سناریوی محدود «راستی‌آزمایی فنی و مهندسی مبتنی بر مستندات» را اجرا کند، مرز ادعا را مشخص کند و evidence قابل بررسی تحویل دهد.
زمان فعال تقریبی: ۵۵ دقیقه خروجی قابل دفاع: Documentation Verification Record v1
پیدا کردن پاسخ با اثبات یک ادعا یکی نیست
دو توضیح دربارهٔ یک فرمان Git با هم اختلاف دارند. یک نتیجهٔ جست‌وجو یا پاسخ تولیدشده، دامنهٔ فرمان را بسیار گسترده توصیف می‌کند؛ منبع دیگری همان موضوع را محدودتر بیان می‌کند. مشاهدهٔ محلی هم ظاهراً یکی از آن‌ها را تأیید می‌کند. وسوسهٔ اصلی این است که همین مشاهده را به یک گزارهٔ فنیِ عمومی تبدیل کنیم.
این درس جلوی همین جهش را می‌گیرد. هر ادعای فنی باید به مرز ادعا، مرجعیت منبع، نشانگر دقیق، نسخه و بافت، اعتبار زمانی، گزارهٔ منبع و مشاهدهٔ محلی وصل شود. این اجزا شواهد (Evidence) قابل بازبینی‌اند. سپس فقط قوی‌ترین تصمیمی صادر می‌شود که همین شواهد واقعاً پشتیبانی می‌کنند.
خروجی درس Documentation Verification Record v1 است. بازبین باید بدون حدس زدن بفهمد کدام گزاره از مستندات آمده، چه چیزی فقط در محیط ثبت‌شده مشاهده شده، این دو کجا هم‌جهت یا متعارض‌اند، چه عدم‌قطعیتی باقی مانده و منبع چه زمانی باید دوباره بررسی شود.
این درس ادعا نمی‌کند مستندات رسمی همیشه بی‌خطا هستند، یک اجرای محلی رفتار همهٔ محیط‌ها را ثابت می‌کند، رتبهٔ جست‌وجو برابر با مرجعیت است یا توضیح AI منبع اصلی محسوب می‌شود. همچنین راستی‌آزمایی مستندات را به آزمایش اجرای فرمان، تحلیل علت ریشه‌ای (Root Cause) یا یک راهبرد آزمون (Test Strategy) کامل تبدیل نمی‌کند.
سه مسیر پشتیبانی، یک معیار شواهد
- مسیر پایه: تعریف‌های روشن، یک مثال پیوسته و یک رکورد نیمه‌ساخت‌یافته. این پشتیبانی پیش از تمرین انتقال حذف می‌شود.
- مسیر ترمیم: فقط بُعد شکننده، مانند مرجعیت منبع یا جداسازی گزارهٔ مستندات از مشاهدهٔ محلی، دوباره تمرین می‌شود. معیار نهایی پایین نمی‌آید.
- مسیر باتجربه: توضیح‌های پایه سریع‌تر طی می‌شوند، اما مرز ادعا، منشأ و ردپای منبع (Provenance)، نسخه و بافت، اعتبار زمانی، عدم‌قطعیت، انتقال و تصمیم انسانی همچنان الزامی‌اند.
برای محدود کردن ادعا به اندازهٔ کافی، باید بافت محلی پروژه را بدانید: ابزار، نسخه/پلتفرم ثبت‌شده، گزارهٔ دقیق مورد بررسی و مشاهدهٔ محلی موجود. انضباط اشکال‌زدایی کمک می‌کند مشاهده را با توضیح یکی نکنید، اما این درس علت یک نقص را تشخیص نمی‌دهد.
مدل ذهنی: یک ادعا، چند واحد شواهدی مستقل
شواهد را یک متن یکپارچه نبینید. آن‌ها را به واحدهای جدا تقسیم کنید:
- ادعا: دقیقاً چه گزاره‌ای ممکن است پذیرفته، محدود یا رد شود؟
- مرز ادعا: گزاره کدام ابزار، نسخه، پلتفرم، فرمان و شرایط را پوشش می‌دهد؟
- مرجعیت منبع: آیا این منبع برای همین نوع ادعا معتبر است؟ راهنمای رسمی یک فرمان می‌تواند برای معنای همان فرمان از یک گزیدهٔ جست‌وجو معتبرتر باشد، بدون اینکه مرجع معماری زمان اجرا شود.
- نشانگر + نسخه/بافت: محل دقیق گزاره در منبع و شرایطی که آن گزاره در آن قابل اعمال است.
- گزارهٔ منبع: آنچه منبع واقعاً پشتیبانی می‌کند، نه استنباط گسترده‌تر ما.
- مشاهدهٔ محلی: آنچه در محیط ثبت‌شده دیده شده است. حتی در صورت توافق با مستندات، یک واحد جدا باقی می‌ماند.
- اعتبار زمانی: تاریخ بازیابی و موعد بازبینی منبع.
- تصمیم + عدم‌قطعیت:
ACCEPT،MODIFY،REJECTیاBOUNDED_DEFERهمراه با محدودیت و گزارهٔ اثبات‌نشده.
زنجیرهٔ ثابت این است:
ادعای محدود → مرجع مناسب → نشانگر دقیق و بافت → گزارهٔ منبع || مشاهدهٔ محلی → وضعیت پشتیبانی → تصمیم انسانی محدود.
دو خط عمودی عمدی‌اند: گزارهٔ منبع و مشاهدهٔ محلی در یک واحد ادغام نمی‌شوند.
پیش از مثال حل‌شده، دسته‌بندی خود را بررسی کنید
برای سناریوی آغاز درس یک ادعای محدود بنویسید، نوع منبعی را که باید آن ادعا را پشتیبانی کند مشخص کنید، مشاهدهٔ محلی را جدا نگه دارید و دست‌کم یک شواهدِ مفقود را نام ببرید. اگر نمی‌توانید شواهد مفقود را مشخص کنید، پیش از ادامه ادعا را محدودتر کنید.
لایهٔ پایه: Documentation Verification Record v1 چه چیزی ثبت می‌کند؟
۱) ادعایی بنویسید که واقعاً قابل راستی‌آزمایی باشد
ضعیف: «Git این فایل را نمی‌بیند.» قابل بازبینی‌تر: «برای فرمان، نسخه/بافت و دامنهٔ مستندشدهٔ ثبت‌شده، آیا این محتوا در دامنهٔ جست‌وجو قرار می‌گیرد و مشاهدهٔ محلی چه بوده است؟»
اگر شواهد فقط یک محیط را پوشش می‌دهد، نتیجه نباید بی‌صدا به همهٔ محیط‌ها تعمیم داده شود.
۲) مرجع را بر اساس نوع ادعا انتخاب کنید
برای معنای فرمان‌های Git، منابع اصلی ثبت‌شدهٔ این درس راهنماهای رسمی git-ls-files و git-grep هستند. مرجعیت آن‌ها محدود به موضوعی است که واقعاً تعریف می‌کنند. نتیجهٔ git grep به‌تنهایی دسترسی یا وابستگی برنامه در زمان اجرا را ثابت نمی‌کند.
پیش از آنکه جست‌وجو یا AI مسیر یافتن منبع را پیشنهاد دهد، ابتدا خودتان ادعا را محدود کنید و نخستین گام لازم برای بازیابی منبع اصلی و تشخیص اولیه را کامل کنید. پس از آن، جست‌وجو، توضیح ثانویه یا AI می‌تواند با افشای استفاده مسیر را سریع‌تر کند، اما جای شواهد اصلیِ قابل اعمال یا قضاوت شما دربارهٔ کفایت شواهد را نمی‌گیرد.
۳) نسخه و بافت را ثبت کنید
«طبق مستندات» کافی نیست. نشانگر دقیق، نسخه/بافت راهنما، تاریخ بازیابی، نسخه و پلتفرم نصب‌شده یا فرمان محلی، و هر محدودیت کاربردپذیری را ثبت کنید.
۴) دو ستون را جدا نگه دارید
- گزارهٔ منبع: آنچه منبع در دامنهٔ خودش پشتیبانی می‌کند.
- مشاهدهٔ محلی: آنچه در محیط ثبت‌شده رخ داده است.
اگر با هم اختلاف دارند، اختلاف را در رکورد نگه دارید. همسان‌سازی حدسی آن‌ها راستی‌آزمایی نیست.
۵) رکورد را آمادهٔ تصمیم کنید
رکورد نهایی دست‌کم باید شامل ادعا، مرز، مرجع، نشانگر، نسخه/بافت، اعتبار زمانی، گزارهٔ منبع، مشاهدهٔ محلی، وضعیت پشتیبانی، عدم‌قطعیت، گزارهٔ اثبات‌نشده، اقدام/بازبینی بعدی، افشای استفاده از پشتیبانی یا AI و تصمیم نهایی انسانی باشد.
برای دیدن همهٔ این اجزا در یک ردیف قابل بازبینی، از جدول فارسیِ دفتر ثبت راستی‌آزمایی مستندات استفاده کنید. نمایش فارسی از نسخهٔ نمایشی مخصوص fa-IR استفاده می‌کند؛ تعریف ماشینیِ جدول فقط مرجع داخلیِ ساختار است.
توضیح عمیق: مرجعیت مطلق نیست
مرجعیت به نوع ادعا وابسته است
راهنمای رسمی برای معنایی که واقعاً تعریف می‌کند شواهد قوی است. در منابع ثبت‌شدهٔ این درس، git-ls-files برای وضعیت فایل‌های tracked/index/worktree به کار می‌رود و مرجع معماری مخزن نیست. git-grep نیز برای معنای جست‌وجوی الگو در دامنهٔ مستندشدهٔ خود به کار می‌رود و به‌تنهایی شواهدی دربارهٔ وابستگی زمان اجرا نیست.
پرسش درست این نیست که «کدام منبع در کل معتبرتر است؟»؛ پرسش این است که «کدام نوع منبع مستقیماً این ادعا را پوشش می‌دهد و مرجعیت آن کجا تمام می‌شود؟»
نشانگر دقیق جلوی خطای حافظه را می‌گیرد
«مستندات Git» نشانگر کافی نیست. بازبین باید بتواند به همان بخش منبع برسد و ببیند کدام گزاره به کدام ادعا وصل شده است. اگر فقط یک گزیده یا خلاصه باقی مانده باشد، منشأ و ردپای منبع کامل نیست.
نسخه و بافت جلوی تعمیم ناخواسته را می‌گیرد
مستندات آنلاین و محیط نصب‌شده ممکن است به‌دلیل نسخه، پلتفرم یا پیکربندی متفاوت باشند. این اختلاف را با حدس حل نکنید. ادعا را محدود کنید، MODIFY را انتخاب کنید یا تا تکمیل شواهد از BOUNDED_DEFER استفاده کنید.
اعتبار زمانی بخشی از شواهد است
رسمی بودن به معنی بی‌زمان بودن نیست. برای منابعی که با ابزار جاری تغییر می‌کنند، تاریخ بازیابی و موعد بازبینی ثبت می‌شود. پس از رسیدن موعد، بررسی دوباره بخشی از سلامت انتشار است.
وضعیت پشتیبانی با تصمیم نهایی یکی نیست
یک ردیف شواهد می‌تواند SUPPORTED، RESTRICTED، CONFLICT یا INSUFFICIENT باشد. تصمیم نهایی را یادگیرنده صادر می‌کند. AI یا ابزار می‌تواند مواد ارائه‌شده را خلاصه کند یا مسیر یافتن منبع را پیشنهاد دهد، اما منشأ منبع را اختراع نمی‌کند و جای قضاوت انسانی دربارهٔ کفایت شواهد را نمی‌گیرد.
مثال حل‌شده: «هیچ تطبیقی پیدا نشد» دقیقاً چه چیزی را ثابت می‌کند؟
یک تیم می‌خواهد این جمله را منتشر کند:
«چونgit grepبرایlegacy_modeهیچ تطبیقی گزارش نکرد، برنامه در هیچ‌جا نمی‌تواند بهlegacy_modeوابسته باشد.»
این جمله چند ادعای متفاوت را در هم فشرده است: معنای فرمان، دامنهٔ محتوایی که فرمان جست‌وجو می‌کند، یک مشاهدهٔ محلی و نتیجه‌ای دربارهٔ رفتار زمان اجرا.
گام ۱ — ادعا را محدود کنید
نسخهٔ قابل بازبینی‌تر:
«در فرمان و محیط ثبت‌شده، آیا git grep برای legacy_mode در دامنهٔ جست‌وجوی مستندشدهٔ خود تطبیقی گزارش می‌کند؟»
این پرسش هنوز چیزی دربارهٔ وابستگی زمان اجرا نمی‌گوید.
گام ۲ — مرجع مناسب را دقیق ثبت کنید
برای معنای فرمان، منبع اصلی این مثال راهنمای رسمی Git برای git-grep نسخه 2.55.0، بخش DESCRIPTION است:
https://git-scm.com/docs/git-grep/2.55.0#_description
نسخهٔ صفحه در 2026-06-29 به‌روزرسانی شده و نشانگر گزاره در 2026-09-06 دوباره بررسی شده است.
گام ۳ — گزارهٔ منبع و مشاهده را جدا کنید
- گزارهٔ منبع: در بخش
DESCRIPTION، Git دامنهٔgit-grepرا جست‌وجوی الگوهای مشخص‌شده در فایل‌های ردیابی‌شدهٔ درخت کاری، blobهای index یا blobهای tree objectهای داده‌شده ــ بسته به شیوهٔ فراخوانی ــ توصیف می‌کند. این گزاره دربارهٔ وابستگی برنامه در زمان اجرا نیست. - مشاهدهٔ محلی: در سناریوی آموزشی، فرمان ثبت‌شده برای
legacy_modeهیچ تطبیقی گزارش نمی‌کند.
هیچ‌کدام از این دو واحد شواهدی جملهٔ «برنامه هرگز نمی‌تواند به این مقدار وابسته باشد» را ثابت نمی‌کند.
گام ۴ — وضعیت پشتیبانی را از تصمیم نهایی جدا کنید
نسخه و پلتفرم Git نصب‌شده در سناریوی آموزشی عمداً داده نشده است. بنابراین:
- برای ادعای کلی دربارهٔ وابستگی زمان اجرا، وضعیت شواهد
INSUFFICIENTاست؛ زیرا دامنهٔ راهنما و مشاهدهٔ ارائه‌شده رفتار زمان اجرا را پوشش نمی‌دهند. - اگر ادعا را فقط به دامنهٔ جست‌وجوی مستندشدهٔ فرمان محدود کنیم، شواهد می‌تواند
RESTRICTEDباشد؛ چون انطباق با نصب مشخص هنوز کامل نشده است. - تصمیم نهایی انسانی دربارهٔ جملهٔ عمومی اولیه
MODIFYاست: ادعای قابل انتشار را محدود کنید یا برای پرسش زمان اجرا شواهد متفاوت جمع‌آوری کنید.
گام ۵ — عدم‌قطعیت و گزارهٔ اثبات‌نشده را نگه دارید
عدم‌قطعیت: نسخه، پلتفرم و پیکربندی Git نصب‌شده مشخص نیست؛ بنابراین انطباق با یک نصب مشخص تا ثبت آن بافت باز می‌ماند. گزارهٔ اثبات‌نشده: نبودن تطبیق در این فرمان ثابت نمی‌کند عبارت در داده‌های تولیدشده، بیرونی یا فقط موجود در زمان اجرا وجود ندارد یا برنامه به آن دسترسی ندارد.
همین منطق دربارهٔ git ls-files نیز برقرار است: خروجی آن می‌تواند دربارهٔ وضعیت فایل در دامنهٔ مستندشده شواهد بدهد، اما صرف حضور یا غیاب یک مسیر، معماری زمان اجرا را ثابت نمی‌کند.
سه میان‌بُر که حرفه‌ای به نظر می‌رسند اما راستی‌آزمایی را خراب می‌کنند
۱) «اولین نتیجهٔ جست‌وجو جواب را گفته است»
رتبه‌بندی برای یافتن منبع است، نه تعیین مرجعیت. اگر منبع اصلیِ قابل اعمال وجود دارد، گزیدهٔ جست‌وجو یا مقالهٔ ثانویه باید نقش راهنما برای یافتن منبع را داشته باشد، نه رأی نهایی.
۲) «روی سیستم من تکرار شد؛ پس مستندات همین را می‌گویند»
تکرارپذیری محلی ارزشمند است، اما مشاهدهٔ محلی را به گزارهٔ مستندات تبدیل نمی‌کند. رکورد باید محیط را ثبت کند و ادعا را به همان بافت محدود نگه دارد.
۳) «رسمی است؛ پس تاریخ مهم نیست»
راهنمای رسمی یک ابزار می‌تواند تغییر کند. بدون تاریخ بازیابی و موعد بازبینی، بازبین نمی‌داند شواهد چه زمانی باید دوباره بررسی شود.
مورد مقایسه‌ای
یک پاسخ AI اثر یک گزینهٔ فرمان را درست حدس می‌زند، اما نشانگر دقیق یا نسخه ندارد. حتی اگر بعداً مشاهدهٔ محلی با آن هم‌جهت شود، درست بودن نتیجه، پاسخ AI را به منبع اصلی تبدیل نمی‌کند. ترمیم درست این است: منبع اصلی را پیدا کنید، گزارهٔ محدود آن را ثبت کنید، مشاهده را جدا نگه دارید و استفاده از پشتیبانی را افشا کنید.
میان‌بُر را بررسی کنید
دقیقاً توضیح دهید چرا «پاسخ AI در اجرای محلی درست بود» هنوز راه نامعتبر برای تعیین مرجعیت است؛ سپس یک گام شواهدی بعدی پیشنهاد دهید که این ضعف را تفکیک کند. پاسخ معتبر باید مرز ادعایی را که این میان‌بُر نقض کرده است نام ببرد.
برای افراد باتجربه: عادت‌های خوب را به رکورد قابل بازبینی تبدیل کنید
ممکن است از قبل راهنمای رسمی را باز کنید، یادداشت انتشار را بخوانید، کد منبع را مقایسه کنید، --version را ثبت کنید، فرمان محلی اجرا کنید یا برای یافتن واژهٔ درست از AI کمک بگیرید. همهٔ این‌ها می‌توانند مفید باشند، اما نقش هرکدام باید روشن باشد.
- راهنمای رسمی یا مشخصات استاندارد: مرجع بالقوه برای همان محصول/استاندارد و همان دامنهٔ ادعا.
- یادداشت انتشار/تغییرات: برای تفاوت‌های نسخه‌ای مفید است، اما باید به ادعای مشخص وصل شود.
- اجرای محلی: مشاهدهٔ محیط شماست، نه گزارهٔ منبع.
- کد منبع: می‌تواند برای پیاده‌سازی یک نسخه شواهد باشد، اما نباید بی‌مرز به همهٔ نسخه‌ها تعمیم داده شود.
- جست‌وجو/AI: برای یافتن مسیر و خلاصه‌سازی با افشای استفاده؛ نه مرجع نهایی.
مسیر سریع یعنی زودتر ادعا را محدود و منبع اصلی را پیدا کنید؛ نه اینکه منشأ منبع، اعتبار زمانی یا تصمیم انسانی را حذف کنید.
چه وقت محدود کنیم، چه وقت تعویق محدود یا رد کنیم؟
- اگر منبع اصلی و مشاهدهٔ محلی هم‌جهت‌اند و نسخه/بافت نیز روشن است، ادعای محدود می‌تواند
ACCEPTشود. - اگر شواهد بخش اصلی ادعا را پشتیبانی می‌کند ولی دامنهٔ اولیه بزرگ‌تر از شواهد است،
MODIFYو محدودسازی ادعا مناسب است. - اگر نتیجهٔ پیشنهادی مستقیماً با منبع قابل اعمال یا شواهد ثبت‌شده ناسازگار است،
REJECTکنید. - اگر قابلیت انطباق منبع، نگاشت نسخه یا محیط ناقص است،
BOUNDED_DEFERاز قطعیت ساختگی بهتر است.
اگر اختلاف مستندات و رفتار به پرسش «چرا این رفتار رخ می‌دهد؟» تبدیل شد، وارد اشکال‌زدایی علّی می‌شوید. اگر پرسش به «برای این ریسک چه شواهد آزمونی لازم است؟» تبدیل شد، موضوع وارد راهبرد آزمون می‌شود. هر روش باید در مرز خودش بماند.
تمرین هدایت‌شده، سپس انتقال مستقل
تمرین هدایت‌شده
با نسخهٔ فارسیِ نیمه‌ساخت‌یافتهٔ Documentation Verification Record v1 شروع کنید. این فایل فقط دسته‌ها و راهنماهای مجاز را از پیش قرار می‌دهد و معیار نهایی را ساده‌تر نمی‌کند.
برای ادعای مربوط به git grep این موارد را کامل کنید:
- ادعای اولیه و ادعای محدودشده؛
- ردهٔ منبع و دلیل انتخاب مرجع؛
- نشانگر دقیق؛
- نسخه/بافت منبع و محیط محلی؛
- گزارهٔ محدود منبع؛
- مشاهدهٔ محلیِ جداگانه؛
- وضعیت پشتیبانی؛
- عدم‌قطعیت و گزارهٔ اثبات‌نشده؛
- تصمیم نهایی انسانی؛
- اقدام یا بازبینی بعدی.
در دور دوم به نسخهٔ فارسیِ خالی رکورد بروید. راهنماهای پیشنهادی حذف شده‌اند و باید نقش هر واحد شواهدی را مستقل تشخیص دهید.
پیش از انتقال، یکپارچگی رکورد را بررسی کنید
رکوردی را که با فرم خالی ساخته‌اید بررسی کنید: هر نتیجهٔ مهم باید قابل ردگیری باشد، گزارهٔ منبع و مشاهدهٔ محلی جدا بمانند، وضعیت پشتیبانی جای تصمیم نهایی ننشیند، دست‌کم یک محدودیت یا گزارهٔ اثبات‌نشده باقی بماند و تصمیم نهایی را خودتان صادر کنید. اگر یک بُعد شکست خورد، همان بُعد را اصلاح و این بررسی را دوباره اجرا کنید.
تمرین مستقل در زمینهٔ جدید
از پروندهٔ فارسیِ تغییرزمینهٔ ExampleCLI استفاده کنید. این پرونده یک سناریوی ساختگی و غیرقابل‌اجرا با منبع، نشانگر/بافت، توضیح ثانویه و مشاهدهٔ محلیِ مستقل است. هیچ مسیر، فرمان یا پاسخ از مثال Git را کپی نکنید.
یک Documentation Verification Record v1 تازه بسازید و نشان دهید:
- ادعای جدید واقعاً به بافت ابزار جدید محدود شده است؛
- مرجع بر اساس نوع ادعا انتخاب شده، نه شباهت با مثال قبل؛
- گزارهٔ منبع و مشاهده جدا مانده‌اند؛
- منشأ و اعتبار زمانی شواهد کامل است؛
- تصمیم نهایی و محدودیت را خودتان دفاع می‌کنید.
چه چیزی برای پذیرش Documentation Verification Record کافی است؟
بازبین باید بتواند بدون بازسازی ذهنی داستان، این پنج بُعد بحرانی را ببیند:
- دقت مرز ادعا: ادعا دقیقاً به اندازهٔ شواهد است.
- انتخاب مرجع منبع: ردهٔ منبع با نوع ادعا تناسب دارد و منبع اصلی بدون دلیل کنار گذاشته نشده است.
- اتصال نسخه و بافت: نشانگر، بافت منبع، محیط محلی و کاربردپذیری صریح‌اند.
- جداسازی گزارهٔ منبع و مشاهدهٔ محلی: این دو حتی هنگام توافق، دو واحد جدا هستند.
- کامل بودن اعتبار زمانی و منشأ منبع: نشانگر، تاریخ بازیابی، موعد بازبینی، منشأ، عدم‌قطعیت و افشای استفاده از پشتیبانی قابل بررسی‌اند.
علاوه بر این، هر نتیجهٔ مسدودکننده باید به شواهد و مرز ادعا وصل باشد، دست‌کم یک محدودیت/گزارهٔ اثبات‌نشده صریح بماند، استفاده از پشتیبانی یا AI افشا شود و تصمیم نهایی انسانی باشد. هیچ میانگین عددی نمی‌تواند شکست یک بُعد بحرانی را جبران کند.
این درس آزمایش اجرایی مستقل ندارد. اجرای محلی فقط در صورت نیاز یک ردیف شواهد تولید می‌کند؛ مهارت اصلی، راستی‌آزمایی ادعا و ساخت رکورد قابل بازبینی است، نه اجرای فرمان به‌عنوان هدف درس.
ارزیابی: از تشخیص دسته تا دفاع از تصمیم
ارزیابی نهایی پنج نوع عملکرد را می‌سنجد:
- بازیابی: مرز ادعا، مرجعیت منبع و مشاهدهٔ محلی را در یک پروندهٔ کوتاه از هم جدا کنید.
- کاربرد: بخش مرکزی Documentation Verification Record v1 را از پروندهٔ کاربردی ارائه‌شده بسازید.
- تشخیص: اولین جایی را پیدا کنید که یک تیم شواهد ضعیف را به ادعای قوی‌تر ارتقا داده است.
- تصمیم: بین
ACCEPT،MODIFY،REJECTوBOUNDED_DEFERتصمیم بگیرید و شواهد، محدودیت و گزارهٔ اثبات‌نشده را ذکر کنید. - انتقال: همین روش را با پروندهٔ ExampleCLI و شواهد جدید اجرا کنید.
در تکلیف‌های مسدودکننده، پاسخ رواییِ صرف کافی نیست. بازبین باید بتواند ادعا، منبع، نشانگر، بافت، مشاهده، وضعیت پشتیبانی، عدم‌قطعیت و تصمیم را به‌صورت قابل بررسی دنبال کند.
منابع، اعتبار زمانی و مرز ادعا
دو منبع رسمی اصلی برای این درس ثبت شده‌اند:
- راهنمای
git-ls-filesبرای معنای مربوط به وضعیت فایل‌های tracked/index/worktree؛ نه معماری مخزن. - راهنمای
git-grepبرای معنای جست‌وجوی الگو در دامنهٔ مستندشدهٔ فرمان؛ نه شواهد مستقل دربارهٔ وابستگی زمان اجرا. برای مثال حل‌شده، بخشDESCRIPTIONنسخه 2.55.0 با نشانگرhttps://git-scm.com/docs/git-grep/2.55.0#_descriptionدر 2026-09-06 دوباره بررسی شده است.
موعد بازبینی ثبت‌شده 2026-10-17 است. اگر موعد فرا برسد، راهنما یا ابزار به‌طور مادی تغییر کند، یا ادعای جاریِ تازه‌ای بیرون از مرز ثبت‌شده وارد شود، منبع باید دوباره بررسی شود.
دو قاعدهٔ «جست‌وجو/AI فقط برای یافتن مسیر» و «جدا نگه‌داشتن گزارهٔ منبع از مشاهدهٔ محلی» قواعد طراحی این درس‌اند؛ آن‌ها را به‌عنوان نقل‌قول از مستندات Git معرفی نکنید.
گزاره‌های صریحِ اثبات‌نشده ثابت‌اند: مستندات رسمی بی‌خطا فرض نمی‌شوند؛ یک اجرای محلی رفتار جهانی را ثابت نمی‌کند؛ رتبهٔ جست‌وجو مرجعیت نیست؛ و توضیح تولیدشده توسط AI منبع اصلی نیست.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
FND-006-S1 retrieval
یک بریده از نتایج جست‌وجو دربارهٔ دامنهٔ یک فرمان، ادعایی گسترده مطرح می‌کند؛ راهنمای رسمی در دسترس است و اجرای محلی نیز نتیجه‌ای نشان داده است. این سه مورد را به «مرز ادعا»، «مرجعیت منبع» و «مشاهدهٔ محلی» تفکیک کنید و سپس یک ادعای محدود و قابل راستی‌آزمایی بنویسید.
FND-006-S2 application
با استفاده از پروندهٔ کاربردی ارائه‌شده، بخش مرکزی Documentation Verification Record v1 را بسازید: ادعا و مرز آن، رده و شناسهٔ منبع، نشانگر دقیق، نسخه/بافت، تاریخ بازیابی و بازبینی، گزارهٔ منبع، مشاهدهٔ محلی، وضعیت پشتیبانی، عدم‌قطعیت، گزارهٔ اثبات‌نشده، اقدام بعدی، افشای استفاده از پشتیبانی و تصمیم نهایی انسانی.
FND-006-S3 diagnosis
تیمی می‌گوید چون صفحهٔ رسمی و نتیجهٔ محلی هم‌جهت‌اند، ادعا برای همهٔ نسخه‌ها و محیط‌ها ثابت شده است. نخستین تعمیم بدون شواهد را مشخص کنید و اصلاح لازم را بنویسید.
FND-006-S4 decision
یک رکورد در حال بررسی، منبع رسمی و مشاهدهٔ محلی دارد، اما نسخهٔ نصب‌شده و بافت آن کامل ثبت نشده و قابلیت انطباق نامطمئن است. میان ACCEPT، MODIFY، REJECT یا BOUNDED_DEFER تصمیم بگیرید و شواهد، یک محدودیت و یک گزارهٔ صریح دربارهٔ آنچه اثبات نشده است ذکر کنید.
FND-006-S5 transfer
با استفاده از پروندهٔ تغییرزمینهٔ ExampleCLI، یک Documentation Verification Record v1 تازه بسازید. از منبع، نشانگر، بافت و خروجی ارائه‌شدهٔ همان سناریو استفاده کنید، پاسخ مثال Git را کپی نکنید و مرجعیت منبع را برای ادعای جدید توجیه کنید.
ملاک‌های ارزیابی (rubric)
| Dimension | Frozen critical dimension | Blocking hard condition | Sufficient evidence | Blocking failure |
|---|---|---|---|---|
| Claim-boundary precision | Yes | Yes | Claim is no broader than source applicability and recorded local context. | Local or source evidence is promoted to a universal claim. |
| Source-authority selection | Yes | Yes | Source class is justified for the claim type; applicable primary authority is used or a reason for not using it is recorded. | Search rank, secondary commentary, or generated text is accepted as primary authority without justification. |
| Version/context binding | Yes | Yes | Locator, source context, installed/local context, and applicability are explicit. | “According to the docs” is used with no version/context boundary. |
| Separation of source statement and local observation | Yes | Yes | Documentation and local observation remain separate evidence atoms and may disagree visibly. | One is silently rewritten as the other. |
| Freshness/provenance completeness | Yes | Yes | Locator, retrieval date, review_due, origin, uncertainty, and support disclosure are inspectable. | Provenance or freshness boundary is missing on a current tool claim. |
| Evidence traceability | No | Yes | Every blocking conclusion traces to bounded source/local evidence and a support status. | Narrative-only conclusion or unexplained verdict. |
| Human judgment and limitations | No | Yes | Learner makes final bounded decision and states limitation/non-claim. | Decision is delegated to AI/tool output or uncertainty is hidden. |
| Transfer | No | Yes | Changed-context work creates new evidence and selects authority for the new claim. | Git paths/answers or prior evidence are copied instead of adapting. |
Exactly five dimensions are frozen as critical. Evidence traceability, human judgment/limitations, and transfer remain blocking hard conditions but are not additional critical dimensions. No arithmetic average can compensate for failure on any frozen critical dimension or blocking hard condition.