تعریف انجام‌شدن
هر پروژه‌ی Lore یک تعریف انجام‌شدن (DoD) را حمل می‌کند: استاندارد کیفیتی که یک سند پیش از تحویل باید از آن عبور کند. چند بخش از آن بازدارنده هستند، یعنی اگر هر بخش بازدارنده‌ای ناموفق باشد، کار انجام‌نشده است.
DoD در مخزن مصرف‌کننده می‌ماند تا هر محصول بتواند آن را تنظیم کند، اما شکلش مشترک است:
| ناحیه | چه می‌خواهد |
|---|---|
| همه‌ی منابع را تمام کن (بازدارنده) | پیش از نوشتن، هر ورودی موجود را بررسی کن؛ هرگز بدون بررسی آنچه داری ننویس. هر اجرا آنچه را خوانده، از جمله تک‌تک منابع مورد اعتماد پیکربندی‌شده، در یک سرشماری منبع قابل حسابرسی ثبت می‌کند تا هیچ منبعی بی‌سروصدا رد نشود. آنچه یک سطر را معتبر می‌کند، قواعد شواهد پایین همین صفحه است. |
| منابع مورد اعتماد (بازدارنده) | همه‌چیز را بر منابع تأییدشده بنا کن؛ حقیقت اختراع نکن و به منابع ثالث تأییدنشده تکیه نکن. |
| محدوده و ساختار | frontmatter معتبر؛ سند از قالب مرجع پیروی می‌کند. |
| نقش‌های کاربری | از نام‌های نقش تأییدشده‌ی محصول استفاده کن؛ تفاوت‌های نقش را توضیح بده. |
| سناریوها (بازدارنده) | هدف، پیش‌شرط‌ها، جریان و پس‌شرط‌ها؛ تصاویر درون‌متنی در گام درست. |
| دقت | اصطلاحات سازگار؛ برچسب‌های رابط کاربری با منبع می‌خوانند؛ قواعد صریح‌اند، نه مبهم. |
| اعتبار فنی (بازدارنده) | لینک‌های سالم، مسیرهای درست تصویر، نبود تصویر جابه‌جا، یک build تمیز. |
| زبان و سبک | محتوا به زبان پروژه؛ نام فایل و دایرکتوری انگلیسی؛ لحن محصول‌محور. |
| گزارش نهایی (بازدارنده) | یک گزارش پایانی از منابع استفاده‌شده، ابزارهای استفاده‌شده، و یک خلاصه. |
شواهد، نه ادعا
قاعده‌ی «همه‌ی منابع را تمام کن» پیش‌تر با نوشتن یک جمله ادا می‌شد، و هیچ جمله‌ای هرگز با یک واقعیت ماشین‌خوانا سنجیده نمی‌شد. عبارت «هیچ چیز مرتبطی نبود، جست‌وجو تأیید شد» یکسان خوانده می‌شود، چه منبع با دقت خوانده شده باشد چه هرگز باز نشده باشد؛ و همان عاملی که آن را رد کرده، همان است که این جمله را می‌نویسد. پس همیشه قبول می‌شد.
چهار زیرقاعده این ادعا را ابطال‌پذیر می‌کنند. هر چهار بازدارندهاند:
| قاعده | چه می‌خواهد |
|---|---|
| رسیدها | سطر سرشماری یک ادعا است، و ادعا بدون رسید بی‌ارزش است: کاوشی که اجرا شد، وضعیت HTTP آن، تعداد بایتی که برگشت، و مسیر روی دیسک پاسخ خام ذخیره‌شده. واژه‌های تأیید شد، بررسی شد و چک شد هیچ‌جا هیچ وزن اثباتی ندارند. مستندات منتشرشده‌ی خودتان هم ندارند: صفحه‌ای که خودتان نوشته‌اید شاهدی درباره‌ی محصول نیست، هرچقدر هم شبیه یک منبع به نظر برسد. یک اصلاح هم خودش یک ادعای تازه است و همان تعهدی را دارد که ادعای جایگزین‌شده داشت. |
| نتایج منفی | صفر ارزان‌ترین نتیجه برای تولید است و همان که بی‌صدا محتوا را کم می‌کند: کاوش خراب و منبع واقعاً خالی رشته‌ی یکسانی برمی‌گردانند. صفر فقط کنار رسیدی موفق و یک هم‌سنجی از خود پاسخ خام معتبر است. اگر پاسخ خام داده را دارد و تجزیه چیزی برنگردانده، این شکست تجزیه است، نه غیاب. و پیش از آنکه هر «یافت نشد» باور شود، باید یک کنترل از آزمون بگذرد: همان جست‌وجو، روی همان مسیرها، برای چیزی که می‌دانیم آنجا هست. یک جست‌وجو ممکن است خالی برگردد چون از پوشه‌ای رد شده یا چون متن به شکل گریزدار ذخیره شده، و هر دو دقیقاً شبیه منبع خالی به نظر می‌رسند. |
| بدون فرض دسترس‌ناپذیری | منبع را فقط بر پایه‌ی کد وضعیت مشاهده‌شده یا دیوار ورود می‌توان «نیازمند ورود» یا «در دسترس نیست» نامید؛ هرگز با استنتاج از جای یک لینک، یک نام، یا یک حدس. |
| قرارداد اجرا | دستورهایی که در گفت‌وگو می‌دهید («وضعیت واردشده را هم پوشش بده»، «نمای موبایل را هم بگیر») به‌اندازه‌ی هر منبع پیکربندی‌شده الزام‌آورند، و آسان‌ترین چیز برای گم‌شدن، چون هیچ چیزی روی دیسک آن‌ها را به یاد نمی‌آورد. این‌ها در پیش‌پرواز به‌صورت سطرهای شماره‌دار نوشته می‌شوند و هرکدام باید اجرا را انجام‌شده، با شواهد تمام کند، یا صراحتاً با تأیید شما کنار گذاشته شود. |
سرشماری اختیاری نیست: اجرایی که مستند تولید کرده و سرشماری‌ای بر جا نگذاشته، چیزی را اثبات نکرده و تحویلش مسدود می‌شود. آنچه این قواعد را واقعی می‌کند نه آرمانی، این است که در برابر آرتیفکت‌هایی سنجیده می‌شوند که هوک‌های کنترلی نوشته‌اند، نه در برابر نثر.
خوداعتبارسنجی
پیش از تحویل، خروجی در برابر DoD اعتبارسنجی می‌شود. اگر یک ناحیه‌ی بازدارنده ناموفق باشد، کار تحویل نمی‌شود؛ خطا همراه با آنچه برای رفعش لازم است گزارش می‌شود. اسکیل lore:doc-reviewer و ساب‌اجنت lore:doc-validator هر دو همین استاندارد دقیق را اعمال می‌کنند، پس چه یک انسان درخواست بازبینی کند و چه یک اسکیل تولیدکننده در پایان خودبررسی کند، همان استاندارد اعمال می‌شود.
آن بازبینی اول روال عادی است. آنچه بعد از آن می‌آید عمداً کرانمند است: حکم سبز پایان همان تحویل است، اصلاح‌ها یکجا اعمال می‌شوند و پس از آن یک بازبینی محدود می‌آید، و هر ویرایشی که پس از حکم سبز انجام شود همراه با ریسکش به شما برمی‌گردد، نه اینکه خودبه‌خود دور دیگری راه بیندازد. دو دور پیاپی که یافته‌هایشان از اصلاح‌های دور قبل آمده باشد، فرآیند را برای تصمیم انسانی متوقف می‌کند. برای اینکه در عمل چطور پیش می‌رود، بازبینی و اعتبارسنجی را ببینید.
درس‌های آموخته‌شده
مسائلی که در طول یک کار رخ می‌دهند به‌شکل درس‌های ماندگار با ریشه و راه‌حلشان ثبت می‌شوند، سپس پیش از کار مشابه در آینده بررسی می‌شوند، تا همان اشتباه دوبار رخ ندهد.