بازگشت به مهندسی مدرن و کار با هوش مصنوعی · فصل ۱ — از خواسته‌ی مبهم تا قرارداد قابل اجرا · 9

تمام‌شدن یعنی چه؟ معیار پذیرش و روش اثبات

نمی‌داند «تمام‌شدن» را با چه evidence و acceptance condition باید اثبات کند. یک Done Matrix می‌سازد که هر معیار را به روش اثبات متصل می‌کند.

خلاصهٔ درس

نمی‌داند «تمام‌شدن» را با چه evidence و acceptance condition باید اثبات کند.

یک Done Matrix می‌سازد که هر معیار را به روش اثبات متصل می‌کند.

خروجی این درس

یک Done Matrix می‌سازد که هر معیار را به روش اثبات متصل می‌کند.

پیش‌نیازها

FND-001-P02

قبل از کد، «تمام‌شدن» را قابل اثبات کنید

در دو درس قبل، ابتدا مسئله را روشن کردید و بعد مرز تغییر را بستید. حالا یک خطر دیگر باقی مانده است: ممکن است کد نوشته شود، یک screenshot خوب به نظر برسد یا مجموعه‌ای از testها سبز شود، اما هنوز معلوم نباشد دقیقاً چه چیزی باید درست باشد و چه شاهدی آن را ثابت می‌کند.

در این درس Done Matrix v1 می‌سازید. این artifact برای هر رفتار مهم چهار چیز را کنار هم می‌گذارد: معیار پذیرش قابل مشاهده، روش اثبات، مثال‌های مثبت/منفی/مرزی، و وضعیت evidence که اجازه می‌دهد یا نمی‌دهد تغییر را Done اعلام کنید.

این درس نه مسیر فنی را انتخاب می‌کند و نه آن را ارزیابی می‌کند. اگر بعداً AI یا توسعه‌دهنده یک مسیر فنی پیشنهادی شامل فایل، component، query یا architecture ارائه کند، FND-001-P04 همان مسیر پیشنهادی را پیش از کد ارزیابی می‌کند. اینجا فقط قراردادِ «چه چیزی باید ثابت شود» را می‌بندیم.

زمان فعال تقریبی: ۴۵ دقیقه.

این درس مناسب شماست اگر: برای یک تغییر می‌توانید scope را توضیح دهید، اما هنوز «Done» را با جمله‌هایی مثل «درست کار کند»، «tests pass» یا «ظاهرش خوب است» می‌سنجید و دو reviewer ممکن است دربارهٔ pass/fail به نتیجهٔ متفاوت برسند.

این درس برای این کارها نیست: تبدیل criterion به syntax یک test framework، یکی‌گرفتن یک screenshot یا یک test با evidence کامل، تعریف Definition of Done سازمانی، یا بررسی implementation plan.

پیش‌نیاز سخت — FND-001-P02: باید بتوانید یک Scope Box v1 محدود بسازید و scope، constraint، non-goal و dependency boundary را بدون تصمیم پنهان جدا کنید.

پروب کوتاه پیش‌نیاز FND-001-P02

کیس: در task list باید کاربر بتواند بین «همهٔ taskها» و «فقط ناتمام‌ها» جابه‌جا شود. ساختار ذخیره‌سازی فعلی نباید در این تغییر عوض شود. redesign کامل صفحه و persistence انتخاب فیلتر خارج از محدوده‌اند. رفتار فیلتر به status موجود taskها تکیه دارد؛ تغییر قرارداد مشترک status در اختیار این task نیست.

در چهار خط بنویسید: in-scope behavior، constraint، non-goal، dependency boundary. هنوز معیار پذیرش یا test ننویسید.

PASS فقط با ۴/۴: (۱) scope رفتاری است نه فهرست فایل؛ (۲) constraint قابل بررسی است؛ (۳) non-goal اثر اجرایی دارد؛ (۴) dependency لازم را با مالکیت تغییر یکی نمی‌گیرد.

اگر یکی از این چهار مورد شکست خورد، فقط همان بخش Scope Box را در FND-001-P02 ترمیم کنید و probe را دوباره انجام دهید. Done Matrix روی scope مبهم، فقط ابهام را با ظاهر دقیق‌تر پنهان می‌کند.

مسیر مناسب خودتان را انتخاب کنید

همهٔ مسیرها به همان Done Matrix v1 و همان evidence bar می‌رسند؛ فقط مقدار توضیح و scaffold فرق می‌کند.

پروب چهارمفهومی مسیر

بدون نگاه‌کردن به بخش‌های بعد، برای هر مورد یک پاسخ کوتاه بدهید:

Acceptance criterion: چرا «یک test برای فیلتر بنویس» criterion نیست؟
Verification method: چرا «فیلتر نباید completed نشان دهد» به‌تنهایی روش اثبات را مشخص نمی‌کند؟
Positive / negative / boundary examples: چرا یک happy path برای پوشش rule کافی نیست؟
Evidence-backed done: اگر screenshot درست است اما test مرتبط fail است، آیا می‌توان Done اعلام کرد؟ چرا؟

هر پاسخ فقط وقتی PASS است که مفهوم را از چیزی که معمولاً با آن اشتباه می‌شود جدا کند. ۴/۴ → مسیر باتجربه/Fast Path؛ ۲ یا ۳/۴ → ترمیم فقط برای مفهوم‌های شکست‌خورده؛ ۰ یا ۱/۴ → مسیر پایه.

مسیر پایه: کیس مشترک را با قالب کامل Done Matrix جلو ببرید.
مسیر ترمیم: فقط contrast مربوط به مفهوم شکننده را بخوانید و همان ستون/ردیف artifact را بازسازی کنید.
مسیر باتجربه / Fast Path: مستقیم به کیس مستقل بروید و بدون راهنمای مرحله‌به‌مرحله matrix را بسازید.

تجربه معیار را پایین نمی‌آورد. مسیر سریع فقط scaffold را حذف می‌کند، نه evidence را.

مدل ذهنی: از «رفتار لازم» تا «شاهد کافی»

Done Matrix یک جدولِ ردیابی است، نه فهرست testها. هر ردیف یک رفتار یا قاعدهٔ قابل داوری را تا شاهد نهایی دنبال می‌کند:

جزء	سؤال اصلی	خط مرزی
Acceptance criterion	چه نتیجهٔ قابل مشاهده‌ای باید درست باشد؟	criterion با test case یکی نیست.
Verification method	با چه روش ازپیش‌تعریف‌شده‌ای دربارهٔ criterion شاهد جمع می‌کنیم؟	روش اثبات با خود معیار یکی نیست.
Positive / negative / boundary examples	rule در حالت رخ‌دادن، رخ‌ندادن و مرز تغییر رفتار چه شکلی دارد؟	مثال با syntax یا implementation یک framework یکی نیست.
Evidence-backed done	آیا همهٔ معیارهای بحرانی و constraintهای مرتبط evidence کافی دارند؟	«کد نوشته شد»، «AI گفت تمام شد» یا یک screenshot به‌تنهایی Done نیست.

هدف این جدول این نیست که همه‌چیز را executable کند. هدف این است که قبل از کد، معیار و روش اثبات را آن‌قدر روشن کند که بعداً evidence را روی هدفی ثابت بسنجید، نه روی هدفی که بعد از دیدن نتیجه جابه‌جا شده است.

چهار مفهوم پایه

۱) معیار پذیرش / Acceptance criterion

معیار پذیرش شرطی قابل مشاهده و قابل داوری است که می‌گوید یک بخش از رفتار موردنیاز پذیرفتنی است یا نه.

ضعیف: «فیلتر درست کار کند.» بهتر: «وقتی نمای ناتمام فعال است، هیچ task completed در فهرست نمایش داده نشود.»

criterion قرارداد رفتاری است. یک test case می‌تواند آن را بررسی کند، اما خود criterion نیست.

۲) روش اثبات / Verification method

روش اثبات از قبل مشخص می‌کند برای داوری criterion چه شاهدی جمع می‌کنیم؛ مثل automated test مرتبط، smoke test، مشاهدهٔ UI، diff inspection یا artifact inspection.

مثال: برای criterion «completed نمایش داده نشود»، روش اثبات می‌تواند یک dataset کنترل‌شده با taskهای completed و unfinished و بررسی خروجی نمای ناتمام باشد.

معیار می‌گوید چه چیزی باید درست باشد؛ روش اثبات می‌گوید چطور دربارهٔ آن شاهد جمع می‌کنیم.

۳) مثال مثبت، منفی و مرزی

مثال‌ها rule را در موقعیت‌های مشخص می‌کشند بیرون:

مثبت: چیزی که باید رخ دهد؛
منفی: چیزی که نباید رخ دهد؛
مرزی: حالتی که در آن رفتار عوض می‌شود یا ambiguity معمولاً پنهان می‌ماند، مثل empty state.

این مثال‌ها لازم نیست از ابتدا Gherkin یا code باشند. ابتدا rule را روشن می‌کنند؛ بعداً می‌توانند به test یا executable specification تبدیل شوند.

۴) پایان قابل اثبات / Evidence-backed done

Done یعنی معیارهای مربوط و constraintهای مرتبط با شاهد کافی بررسی شده‌اند. اگر یک criterion بحرانی بدون evidence است یا evidence آن failed است، Done صادر نمی‌شود.

این مفهوم با Definition of Done سازمانی فرق دارد. این درس دربارهٔ «تمام‌شدن همین تغییر» است، نه سیاست عمومی تیم برای همهٔ کارها.

Done Matrix v1 را چگونه بسازیم؟

از Scope Box v1 شروع کنید و فقط رفتارها و constraintهای مربوط به همین تغییر را وارد کنید. سپس برای هر رفتار مهم یک ردیف بسازید.

قالب پیشنهادی:

فیلد	چه چیزی ثبت می‌شود؟
Trace type / source	مشخص کنید ردیف از Acceptance criterion می‌آید یا Relevant constraint؛ منبع آن را در Scope Box قابل ردیابی نگه دارید.
Criterion / constraint	برای criterion: condition/context + observable expected result؛ برای constraint: همان قاعدهٔ محدودکننده، بدون تبدیل‌کردنش به رفتار ساختگی.
Proof method	روش ازپیش‌تعریف‌شدهٔ جمع‌آوری evidence برای همان criterion یا constraint
Positive / compliance example	برای criterion نمونهٔ رخ‌دادن؛ برای constraint نمونهٔ رعایت قاعده
Negative / violation example	برای criterion نمونهٔ نباید؛ برای constraint نمونهٔ نقض قاعده
Boundary example	edge/empty/boundary که rule یا constraint را روشن می‌کند
Critical?	آیا شکست یا نبود evidence این ردیف Done را block می‌کند؟
Evidence / result	NOT_RUN، PASS، FAIL یا BLOCKED + اشاره به شاهد

چهار قاعدهٔ ساخت:

Observable first: criterion را از بیرون سیستم یا از سطح قابل داوری بنویسید، نه با حدس دربارهٔ implementation.
Proof before code: روش اثبات را قبل از دیدن نتیجه تعیین کنید تا goalpost بعداً جابه‌جا نشود.
Examples cover the rule: فقط happy path کافی نیست؛ حداقل occurrence، non-occurrence و یک boundary مهم را بررسی کنید.
Done is a conclusion, not a mood: evidenceهای مرتبط را جمع کنید؛ اگر ردیف بحرانی gap یا FAIL دارد، status کل تغییر هنوز Done نیست.

AI کجا کمک می‌کند و کجا نه؟

AI می‌تواند criterion مبهم را پیدا کند، counterexample پیشنهاد دهد، proof methodهای احتمالی را مقایسه کند یا matrix را برای missing boundary نقد کند. اما AI نمی‌تواند authority پذیرش را جعل کند، evidence اجرا نشده را PASS بنامد یا failing evidence را با یک توضیح خوش‌بینانه خنثی کند. اعلام نهایی Done یک تصمیم انسانیِ traceable است.

مثال حل‌شده: Done Matrix فیلتر کارهای ناتمام

Scope Box قبلی این تغییر را محدود کرده است: کاربر باید بتواند بین «همهٔ taskها» و «فقط ناتمام‌ها» جابه‌جا شود؛ ساختار ذخیره‌سازی تغییر نمی‌کند؛ persistence انتخاب فیلتر و redesign کامل صفحه خارج از scope هستند.

یک Done Matrix مختصر می‌تواند چنین باشد:

Trace type / source	Criterion / constraint	Proof method	Positive/compliance · negative/violation · boundary	Critical	Evidence state
Acceptance criterion ← in-scope filter behavior	وقتی نمای ناتمام فعال است، completed نمایش داده نشود	dataset با completed+unfinished و مشاهدهٔ خروجی	+ unfinished دیده می‌شود؛ − completed دیده نمی‌شود؛ مرز: همه completed هستند و نتیجه صفر task است	بله	NOT_RUN قبل از پیاده‌سازی
Acceptance criterion ← in-scope switch behavior	با برگشت به All، taskهای completed و unfinished دوباره قابل مشاهده باشند	smoke test روی همان dataset	+ هر دو نوع برمی‌گردند؛ − item حذف دائمی نمی‌شود؛ مرز: list فقط یک نوع status دارد	بله	NOT_RUN
Relevant constraint ← storage structure unchanged	ساختار ذخیره‌سازی فعلی تغییر نکند	diff/schema inspection	رعایت: بدون migration/schema diff؛ نقض: schema change بدون Change Request؛ مرز: کشف نیاز واقعی به schema change → BLOCKED/ارجاع	بله	NOT_RUN

نکته: این matrix هنوز نمی‌گوید کدام component یا function باید تغییر کند. چنین انتخابی خارج از P03 است؛ اگر یک مسیر فنی مشخص پیشنهاد شد، FND-001-P04 آن مسیر پیشنهادی را پیش از کد ارزیابی می‌کند.

بعد از implementation، ستون Evidence/Result با شاهد واقعی پر می‌شود. اگر screenshot درست باشد ولی test مرتبط fail کند، ردیف بحرانی PASS نیست و تغییر Done نیست.

چهار خطای محتمل و روش ترمیم

خطا ۱: criterion به شعار تبدیل می‌شود

«فیلتر خوب کار کند» هیچ pass/fail مستقل نمی‌سازد. ترمیم: condition و نتیجهٔ observable را بنویسید تا دو reviewer بتوانند روی نتیجه توافق کنند.

خطا ۲: proof method با criterion یکی می‌شود

«tests pass» نه criterion است و نه proof method کافی، مگر معلوم باشد کدام test مرتبط با کدام criterion است. ترمیم: روش و evidence item را به ردیف مشخص bind کنید.

خطا ۳: فقط happy path داریم

یک نمونهٔ معمولی ممکن است empty state، non-occurrence یا boundary را پنهان کند. ترمیم: برای rule حداقل یک مثبت، یک منفی و یک boundary معنادار بسازید.

خطا ۴: یک شاهد خوب، شاهد بد را می‌پوشاند

یک screenshot مطلوب نمی‌تواند failing test مرتبط را پاک کند. ترمیم: evidence متعارض را نگه دارید؛ تا وقتی criterion بحرانی FAIL یا بدون شاهد است، Done صادر نکنید.

پل مسیر باتجربه: شواهد متناقض و هدف‌های در حال جابه‌جایی

در پروژهٔ واقعی ممکن است PR بگوید «همه testها سبز»، یک screenshot نتیجهٔ درست را نشان دهد، اما test مرتبط اصلاً اجرا نشده باشد یا یک edge case شکست بخورد. همچنین ممکن است بعد از implementation کسی criterion را طوری بازنویسی کند که خروجی موجود ناگهان PASS شود.

مسیر باتجربه باید دقیقاً برعکس عمل کند: criterion و proof method را قبل از نتیجه freeze کند، evidence متناقض را حذف نکند، و اگر شاهد کافی نیست status را BLOCKED یا NOT_RUN نگه دارد. اگر برای اثبات criterion به مسیر فنی دیگری نیاز به نظر می‌رسد، این نیاز را از Done contract جدا نگه دارید؛ هر مسیر فنی پیشنهادی باید در P04 پیش از کد ارزیابی شود. اینجا contract را برای توجیه plan دستکاری نکنید.

روش‌های مختلف بیان معیار و بده‌بستان‌های آن‌ها

Done Matrix به یک syntax خاص وابسته نیست:

جملهٔ condition → observable result: سریع و framework-neutral است، اما باید مراقب ambiguity باشید.
مثال‌های سناریویی: rule را با context و outcome ملموس می‌کنند. مستندات جاری Gherkin از ساختارهایی مثل Given/When/Then برای بیان context، event و expected outcome استفاده می‌کند؛ این فقط یک notation ممکن است، نه الزام این درس.
test case مستقیم: برای proof مفید است، اما اگر criterion فقط از روی code/test استخراج شود، قرارداد رفتاری ممکن است در implementation دفن شود.

انتخاب مطلوب این درس: criterion باید مستقل از ابزار قابل فهم باشد و proof method بتواند بعداً به ابزار مناسب bind شود. اگر تیم Gherkin، unit test، UI test یا manual review استفاده می‌کند، Done Matrix همچنان لایهٔ بالاترِ traceability را حفظ می‌کند.

همچنین Done Matrix را با Definition of Done سازمانی یکی نکنید. یک تیم ممکن است ruleهای عمومی مثل review یا documentation داشته باشد؛ این درس فقط evidence لازم برای همین تغییر محدود را می‌بندد.

تمرین هدایت‌شده و مستقل

تمرین هدایت‌شده

کیس order search:

In scope: جست‌وجو فقط با شمارهٔ کامل سفارش انجام می‌شود.
رفتارهای مشاهده‌پذیرِ همین کیس: (۱) شمارهٔ کاملِ موجود، همان سفارش متناظر را قابل مشاهده می‌کند؛ (۲) شمارهٔ کاملِ ناموجود، هیچ سفارش دیگری را به‌عنوان match برنمی‌گرداند؛ (۳) شمارهٔ ناقص، match موفق محسوب نمی‌شود و fuzzy/partial matching فعال نمی‌کند.
Constraint: schema سفارش در این تغییر عوض نمی‌شود.
Out of scope: جست‌وجوی نام مشتری، redesign صفحه و fuzzy search.
Dependency: شمارهٔ سفارش از قبل در دادهٔ قابل دسترس وجود دارد.

یک Done Matrix v1 با سه criterion، یکی برای هر رفتار مشاهده‌پذیر بالا بسازید. برای هر criterion proof method و positive/negative/boundary example بنویسید. حداقل یک constraint را هم به روش inspection/evidence وصل کنید. هیچ implementation plan پیشنهاد ندهید.

تمرین مستقل — مقصد Fast Path

کیس upload تکلیف — فقط از همین بستهٔ مرجع استفاده کنید:

Problem: بعضی کاربران چون از موفقیت upload مطمئن نیستند، فایل را دوباره می‌فرستند.
رفتار تأییدشدهٔ داخل محدوده: وقتی تلاش upload موجود یک signal نهاییِ موفق یا ناموفق دریافت کرد، همان وضعیت باید برای همان تلاش به‌صورت قابل مشاهده روشن شود. تلاش بعدی نباید وضعیت نهایی تلاش قبلی را به ارث ببرد.
Constraint: storage provider فعلی عوض نمی‌شود.
Out of scope: retry خودکار، refactor کل upload subsystem، notification redesign.
Dependency: سرویس موجود می‌تواند signal نهایی success یا failure برگرداند، اما پیش از رسیدن signal نهایی ممکن است در حالت processing بماند.
دو یادداشت متناقضِ فعلی: یک یادداشت stakeholder می‌گوید «اگر بعد از ۱۰ ثانیه signal نهایی دیده نشد، failure نشان بده»؛ یادداشت service owner می‌گوید «کندبودن processing به معنی failure نیست؛ بدون signal نهایی failure برچسب نزن». هیچ‌کدام به‌عنوان نسخهٔ جایگزین یا برترِ دیگری تأیید نشده است.
Unknown صریح: در این task هیچ rule تأییدشده‌ای وجود ندارد که بگوید بعد از ۱۰ ثانیه، وقتی سرویس هنوز processing است، UI چه ادعایی باید نشان دهد.

بدون اینکه حدس بزنید کدام یادداشت برنده است، Done Matrix v1 بسازید. از رفتارهای تأییدشدهٔ بالا حداقل سه ردیف acceptance criterion با proof method، مثال مثبت/منفی/مرزی و وضعیت اولیهٔ evidence بسازید. یک ردیف جدا هم برای تعارض ۱۰ ثانیه/processing ثبت کنید و تا زمان تعیین authority آن را BLOCKED با evidence=NOT_RUN نگه دارید. Unknown را بی‌صدا به criterion تبدیل نکنید. در پایان یک خط بنویسید که P03 چه تصمیم فنی‌ای را نمی‌گیرد و FND-001-P04 دربارهٔ یک مسیر فنی پیشنهادی چه کاری انجام می‌دهد.

چطور بفهمیم Done Matrix کافی است؟

چهار بعد بحرانی را بررسی کنید:

Concept closure: criterion، proof method، example coverage و evidence-backed done حاضرند و با هم قاطی نشده‌اند.
Artifact traceability: هر criterion به behavior/constraint در Scope Box برمی‌گردد و proof/evidence به همان criterion وصل است.
Neighbor boundary: matrix دربارهٔ «چه چیزی باید ثابت شود» تصمیم می‌گیرد، نه «چطور کدش کنیم»؛ P04 جذب نشده است.
Human evidence discipline: evidence gap، FAIL یا contradiction پنهان نمی‌شود و AI/tool output به‌تنهایی authority Done نیست.

شاهد کافی برای عبور از این درس: Done Matrix v1 مستقل + توضیح یک تصمیم pass/fail + نشان‌دادن مرز P04. machine validation می‌تواند consistency را بررسی کند، اما تصمیم نهایی acceptance انسانی باقی می‌ماند.

ارزیابی و انتقال

ارزیابی پنج حرکت را می‌سنجد: یک distinction مفهومی، ساخت Done Matrix برای case تازه، تشخیص artifact failure، تصمیم انسانی روی evidence مبهم/متناقض، و انتقال artifact به دامنه‌ای متفاوت.

در سؤال‌های blocking، پاسخ باید self-contained و قابل داوری باشد: criterionهای روشن، proof methodهای مرتبط، example coverage، evidence status و مرز P04. صرف گفتن «tests pass» یا «به نظر درست است» evidence کافی نیست.

در transfer، invariantها را حفظ کنید ولی wording کیس task list را کپی نکنید.

منابع و تازگی

تعریف‌های اصلی این درس از قرارداد آموزشی همین درس می‌آیند؛ هیچ استاندارد خارجی یا ابزار تست، قالب Done Matrix v1 را برای MAKNOW تعریف نمی‌کند.

برای زمینهٔ requirements engineering، وضعیت ISO/IEC/IEEE 29148 در 2026-09-05 دوباره بررسی شد: Edition 2 سال 2018 همچنان International Standard منتشرشده است و در stage 90.92 — to be revised قرار دارد. Edition 3 هنوز Draft International Standard و under development است؛ بنابراین جایگزین normative نسخهٔ 2018 نشده است.

مستندات رسمی Cucumber/Gherkin نیز در همین تاریخ recheck شدند. آن‌ها نشان می‌دهند سناریوهای Gherkin می‌توانند context، event و expected outcome را به‌صورت executable specification بیان کنند. این درس Gherkin را الزام نمی‌کند و criterion را با syntax یک framework یکی نمی‌گیرد.

اگر در نسخهٔ آینده claim جاری دربارهٔ standard یا tool اضافه شود، همان claim باید دوباره با primary source روز بررسی شود؛ در غیر این صورت باید محدود یا حذف شود.

ارزیابی

پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.

Q1 retrieval

Acceptance criterion و Verification method را از هم جدا کنید؛ سپس برای criterion «وقتی نمای ناتمام فعال است، completed نمایش داده نشود» یک proof method مناسب پیشنهاد دهید.

lesson ✗AI ✗notes ✗

Q2 application

کیس تازه — Order search. Scope Box می‌گوید: in scope = جست‌وجو فقط با شمارهٔ کامل سفارش؛ رفتارهای مشاهده‌پذیر = (۱) شمارهٔ کامل موجود همان سفارش متناظر را قابل مشاهده می‌کند، (۲) شمارهٔ کامل ناموجود هیچ سفارش دیگری را match نمی‌کند، (۳) شمارهٔ ناقص match موفق نیست و fuzzy/partial matching را فعال نمی‌کند؛ constraint = schema سفارش تغییر نکند؛ out of scope = جست‌وجوی نام مشتری، redesign و fuzzy search؛ dependency = شمارهٔ سفارش از قبل در داده موجود است. یک Done Matrix v1 با دقیقاً سه criterion، یکی برای هر رفتار supplied بسازید. برای هر criterion proof method و positive/negative/boundary example بنویسید؛ constraint را نیز به evidence وصل کنید. implementation plan ننویسید.

lesson ✗AI ✗notes ✗

Q3 diagnosis

این Done Matrix معیوب است: Criterion = «فیلتر درست کار کند»؛ Proof = «tests pass»؛ Example = فقط یک happy path؛ Evidence = screenshot خوب، درحالی‌که test مرتبط با empty state FAIL شده. چهار failure را تشخیص دهید و برای هر کدام repair مشخص بنویسید.

lesson ✗AI ✗notes ✗

Q4 decision

AI می‌گوید تغییر Done است چون screenshot درست است و «بقیهٔ tests سبز هستند». evidence log نشان می‌دهد test مستقیم criterion بحرانی اصلاً اجرا نشده و یک edge-case check قبلی FAIL بوده است. دربارهٔ claim «Done» فقط یکی از تصمیم‌های ACCEPT/MODIFY/REJECT را انتخاب کنید و با evidence توضیح دهید.

lesson ✗AI ✗notes ✗

Q5 transfer

دامنهٔ جدید — Assignment upload. Scope Box: in scope = بعد از هر upload موجود، success/failure همان تلاش قابل مشاهده شود؛ constraint = storage provider عوض نشود؛ out of scope = retry خودکار، refactor کل subsystem و notification redesign؛ dependency = سرویس موجود success/failure signal می‌دهد. Done Matrix v1 بسازید: حداقل سه criterion، proof method، positive/negative/boundary examples و evidence state اولیه. سپس دقیقاً بنویسید P03 چه تصمیم فنی‌ای را نمی‌گیرد و FND-001-P04 یک مسیر فنی پیشنهادی را پیش از کد چگونه ارزیابی می‌کند.

lesson ✗AI ✗notes ✗

ملاک‌های ارزیابی (rubric)

Canonical evidence descriptors are stored in questions.json; this Markdown index does not override them.