چرخه‌ی کنترل‌شده‌ی کار با AI — از درخواست تا پذیرش یا رد

تغییر تولیدشده کافی نیست؛ باید بتوانید آن را کنترل و داوری کنید

یک Vertical Slice پذیرفته‌شده از فیلتر کارهای ناتمام آماده است. اگر فقط به یک عامل بگویید «فیلتر را پیاده کن» و در پایان چند فایل تغییرکرده و چند تست سبز ببینید، هنوز نمی‌دانید آیا عامل scope را گسترش داده، requirement تازه‌ای حدس زده، refactor نامرتبط انجام داده یا evidence کافی برای پذیرش تغییر فراهم کرده است.

در این درس یک AI Work Record v1 می‌سازید و یک work unit را از پنج ایستگاه عبور می‌دهید:

AI task contract → Context and plan gate → Bounded execution → Evidence bundle and diff review → Human accept/reject and record

خروجی این درس یک chat log نیست. یک record قابل review است که goal، context، constraints، plan، change surface، evidence، deviationها و تصمیم انسانی را به هم متصل نگه می‌دارد.

این درس خواندن عمیق یک repository ناآشنا را آموزش نمی‌دهد؛ آن مهارت متعلق به FND-004 است. اینجا فرض می‌کنیم context لازم برای work unit قابل جمع‌آوری است و تمرکز روی کنترل run است.

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

این درس برای شماست اگر: یک Vertical Slice مشخص دارید و می‌خواهید یک تغییر کدنویسی با AI را بدون گسترش پنهان scope، self-certification یا پذیرش خودکار اجرا و ثبت کنید.

این درس برای این کارها نیست: repository reading عمیق، سپردن تصمیم نهایی به AI/CI، refactor نامرتبط، یا یکی‌گرفتن permission محیط با engineering scope.

پیش‌نیاز سخت — FND-002: باید بتوانید یک Vertical Slice Plan v1 bounded را بدون تصمیم پنهان بازسازی کنید.

پروب کوتاه پیش‌نیاز

این packet را بخوانید:

• Spec: کاربر بتواند بین All و Unfinished جابه‌جا شود.
• AC-01: در حالت Unfinished فقط taskهای ناتمام دیده شوند.
• AC-02: بازگشت به All نمای عادی را برگرداند.
• Constraint: schema و معنی status تغییر نکند.
• Work unit: WU-01 — Vertical Slice
• Outcome: رفتار All ↔ Unfinished end-to-end قابل مشاهده شود.
• Evidence: mixed-status، return-to-All، all-completed.
• Rollback boundary: فقط مسیر انتخاب/filter.
• Next unit: verification support برای constraint/regression.

در چند خط توضیح دهید چرا WU-01 یک smallest useful vertical slice است، dependency/evidence آن چیست و rollback boundary کجاست.

PASS: بدون افزودن requirement تازه، outcome، criterion، evidence و rollback را درست بازسازی کنید.

اگر این packet برای شما روشن نیست، فقط مهارت شکننده‌ی FND-002 را repair کنید. یک AI run نباید ambiguity decomposition را پنهان کند.

مقدار راهنمایی مناسب را انتخاب کنید

همه‌ی مسیرها به همان AI Work Record v1، همان lab و همان evidence bar می‌رسند.

پروب پنج‌مفهومی مسیر

1. AI task contract چه چیزی را قبل از run روشن می‌کند؟
2. Context and plan gate چه چیزی را پیش از edit متوقف می‌کند؟
3. چرا sandbox/permission همان change boundary نیست؟
4. Evidence bundle چه چیزی بیشتر از «tests are green» دارد؟
5. چرا final acceptance حتی با CI سبز انسانی می‌ماند؟

۵/۵ → Fast Path؛ ۳–۴/۵ → repair هدفمند؛ ۰–۲/۵ → مسیر پایه.

• مسیر پایه: مثال فیلتر task + قالب record + lab مرحله‌به‌مرحله.
• مسیر repair: فقط misconception همان مفهوم شکننده.
• مسیر باتجربه/Fast Path: مستقیم به کیس مستقل با deviation و false-green evidence؛ معیار پذیرش تغییر نمی‌کند.

مدل ذهنی: AI Work Record یک زنجیره‌ی کنترل است

request به‌تنهایی کافی نیست. هر مرحله باید چیزی را برای مرحله‌ی بعد ثابت کند:

1. AI task contract — goal، context، constraints و done/evidence را bounded می‌کند.
2. Context and plan gate — عامل قبل از edit context لازم را inspect می‌کند، uncertainty را ثبت می‌کند و plan را برای review ارائه می‌دهد.
3. Bounded execution and change boundary — فقط plan تأییدشده اجرا می‌شود؛ actual diff با scope مقایسه و deviation ثبت می‌شود.
4. Evidence bundle and diff review — diff، test/build output و behavior observation به criteria/constraints وصل می‌شوند.
5. Human accept/reject and record — انسان یکی از ACCEPT / MODIFY / REJECT را با rationale، residual uncertainty و next action ثبت می‌کند.

نکته‌ی کلیدی: permission می‌گوید عامل از نظر محیط «می‌تواند» کاری را انجام دهد؛ change boundary می‌گوید برای این task «مجاز است چه تغییری را به‌عنوان بخشی از solution انجام دهد». این دو یکی نیستند.

پنج مفهوم پایه

۱. قرارداد کار با AI / AI task contract

یک بسته‌ی کوتاه و کامل برای شروع run است: goal، ورودی/context لازم، constraints، non-goals، allowed change surface و تعریف done/evidence. قرارداد خوب الزاماً طولانی نیست؛ کم‌ابهام و scope-aware است.

۲. دروازه‌ی Context و Plan

در task پیچیده یا ambiguous، edit قبل از inspect و plan متوقف می‌شود. عامل می‌تواند فایل‌ها و رفتار مرتبط را بررسی کند، uncertainty را گزارش کند و plan بدهد؛ انسان plan را approve یا revise می‌کند.

مرز با FND-001-P04: آن درس خودِ مهارت نقد و اصلاح plan را آموزش می‌دهد. در FND-003 آن مهارت بالادستی را داخل یک coding run سرتاسری به‌عنوان plan gate به کار می‌برید: context لازم inspect می‌شود، plan در برابر spec review می‌شود، انسان APPROVE یا REVISE می‌کند و فقط بعد bounded execution شروع می‌شود. اینجا FND-001-P04 را جایگزین یا دوباره آموزش نمی‌دهیم.

۳. اجرای محدود و مرز تغییر

بعد از تأیید plan، run در branch/worktree یا محیط reversible انجام می‌شود. هر فایل/رفتار تغییرکرده با approved plan و change boundary مقایسه می‌شود. refactor یا cleanup نامرتبط باید توضیح داده و در صورت خارج‌بودن از scope revert شود.

۴. بسته‌ی شواهد و بازبینی diff

وجود code output evidence نیست. evidence باید هم behavior و هم boundary/regression risk را پوشش دهد: relevant tests، build/checkها، diff review، behavior observation و trace از criterion/constraint به شاهد.

۵. پذیرش، رد و ثبت انسانی

AI یا CI می‌تواند signal تولید کند، اما final acceptance این درس انسانی است. record باید version/spec، evidence، risk یا uncertainty باقی‌مانده، verdict و next action را ثبت کند.

AI Work Record v1 را پر کنید

قالب record هفت بخش دارد:

A. Record identity

• Work Record ID
• Spec/Slice ID و version
• repository/worktree identity
• reviewer/decision owner

B. AI task contract

• bounded goal
• relevant context
• constraints
• non-goals
• allowed change surface
• done/evidence required

C. Context and plan gate

• inspected context
• uncertainties/assumptions
• proposed plan
• expected files/behaviors touched
• human plan decision: APPROVE / REVISE

D. Bounded execution

• commands/actions actually run
• files/behaviors actually changed
• deviations from approved plan
• deviation disposition: explained / reverted / re-approved

E. Evidence bundle

• criterion/constraint
• evidence type
• exact evidence/result
• source/command/observation
• gap or unresolved item

F. Diff review

• expected change surface vs actual
• unrelated edit check
• regression-risk review
• rollback readiness

G. Human decision record

• ACCEPT / MODIFY / REJECT
• rationale
• residual uncertainty/risk
• next action

AI می‌تواند plan، code/test candidate یا evidence gap پیشنهاد دهد؛ اما requirement پنهان، evidence oracle و final acceptance نمی‌شود.

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

Task contract

• Goal: اجرای WU-01 برای All ↔ Unfinished.
• Constraint: schema/status semantics تغییر نکند.
• Non-goal: persistence، redesign، unrelated cleanup.
• Done: AC-01 و AC-02 + preservation checks + diff review.

Context/plan gate

عامل پس از inspect پیشنهاد می‌کند برای ساده‌کردن state یک migration کوچک هم اضافه شود. این پیشنهاد با constraint تضاد دارد.

Human plan decision: REVISE

Plan اصلاح می‌شود: فقط مسیر view-selection/filter و تست‌های همان رفتار؛ migration حذف.

Bounded execution

عامل تغییر را در worktree محلی انجام می‌دهد. actual diff فقط فایل‌های مرتبط با filter behavior و test را لمس می‌کند. اگر rename نامرتبط ظاهر شود، قبل از ادامه revert می‌شود.

Evidence bundle

• AC-01 → mixed-status test/observation.
• AC-02 → return-to-All test/observation.
• Constraint → schema diff inspection.
• Regression risk → existing list behavior + all-completed + empty-state.
• Boundary → actual diff با approved change surface مقایسه می‌شود.

Human decision

اگر همه‌ی evidenceهای لازم موجود و diff bounded باشد: ACCEPT. اگر criterion یا evidence ناقص باشد: MODIFY. اگر change خارج از scope یا critical criterion ناموفق باشد: REJECT.

دلیل و uncertainty باقی‌مانده باید داخل record نوشته شود؛ «AI says done» دلیل پذیرش نیست.

پنج شکست رایج

شکست ۱: prompt مبهم

«هرطور صلاح می‌دانی درستش کن.» Repair: goal، constraints، non-goals و done/evidence را قبل از run bounded کنید.

شکست ۲: plan تشریفاتی

عامل plan می‌دهد اما قبل از review edit را شروع می‌کند. Repair: برای taskهای این درس، plan gate باید واقعاً progression را متوقف کند.

شکست ۳: permission را scope فرض کردن

عامل چون write access دارد یک rename گسترده انجام می‌دهد. Repair: allowed change surface مستقل از sandbox permission ثبت شود.

شکست ۴: false green

تست‌های موجود سبزند اما diff یک فایل نامرتبط را حذف کرده یا criterion مهمی اصلاً تست نشده است. Repair: test signal + diff review + criterion/evidence mapping را با هم ببینید.

شکست ۵: self-certification

عامل می‌گوید «همه چیز درست است» و record را ACCEPT می‌بندد. Repair: AI report یک input است؛ verdict نهایی و rationale باید انسانی باشد.

پل مسیر باتجربه: deviation و evidence سبز اما ناکافی

در run واقعی، plan و actual work همیشه صددرصد یکسان نمی‌مانند. مسئله این نیست که deviation صفر باشد؛ مسئله این است که deviation پنهان نباشد.

فرض کنید plan فقط دو فایل را پیش‌بینی کرده اما برای پاس‌کردن build، یک فایل config هم باید تغییر کند. سه راه وجود دارد:

• deviation خارج از scope است → revert؛
• deviation لازم و داخل goal است → قبل از پذیرش توضیح/بازتصویب شود؛
• uncertainty هنوز حل نشده → run متوقف و plan اصلاح شود.

همچنین «green» بودن یک suite ممکن است کافی نباشد. اگر suite شرط no-schema-change یا behavior failure path را نمی‌سنجد، evidence gap باقی است. Fast Path باید دقیق‌تر record کند، نه اینکه gateها را حذف کند.

گزینه‌ها و بده‌بستان‌ها

• Direct edit برای task کوچک و کاملاً روشن: سریع‌تر است؛ اما در task complex/ambiguous این درس plan gate را حذف نمی‌کنیم.
• Plan-first: هزینه‌ی شروع کمی بیشتر، اما فرض‌های پنهان و scope drift زودتر دیده می‌شوند.
• Context گسترده: ممکن است dependency بیشتری کشف کند، ولی noise و دسترسی غیرضروری را بالا می‌برد.
• Context حداقلی: تمرکز را بالا می‌برد، اما اگر evidence لازم حذف شود plan ناقص می‌شود.
• AI-generated tests: می‌تواند coverage candidate بدهد، ولی test تولیدشده توسط همان agent به‌تنهایی oracle نیست.
• CI: signal مهم است، اما domain/scope acceptance را کامل نمی‌کند.

ابزارها متفاوت‌اند؛ invariant این درس vendor-specific نیست: contract روشن، plan review، execution bounded، evidence مستقل و decision انسانی.

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

تمرین هدایت‌شده — Order search

Slice پذیرفته‌شده:

• exact order-number search
• no fuzzy/customer-name search
• order schema unchanged
• existing list preserved
• AC-01 exact match
• AC-02 clear no-match
• AC-03 list regression-free

یک AI Work Record v1 بنویسید: task contract، context to inspect، plan gate criteria، allowed change surface، evidence bundle و human decision conditions. سپس یک plan نامناسب که customer-name search هم اضافه کرده diagnose و فقط همان scope violation را repair کنید.

پل خواندن و اجرای برنامه — اگر syntax پایه هنوز برایت ناآشناست

این بخش قابل رد کردن است. اگر بدون کمک می‌توانی fixture پایین را توضیح بدهی، command تست را اجرا کنی، failure را بخوانی و بگویی کدام branch باید تغییر کند، مستقیم به LAB-01 برو. اگر نه، همین fixture واقعی Lab را به‌عنوان bridge استفاده کن؛ هیچ زبان یا پروژهٔ جداگانه‌ای لازم نیست.

۱) value، نام و نوع ساده را در همان fixture ببین

در تست‌ها داده‌ای شبیه این وجود دارد:

TASKS = [
    {"id": 1, "title": "A", "completed": False},
    {"id": 2, "title": "B", "completed": True},
    {"id": 3, "title": "C", "completed": False},
]

1 و 3 عددند، "A" رشته است و False/True مقدار boolean هستند. نام TASKS به یک list وصل شده است. هر عضو list یک record/dict است که با کلیدهایی مثل "id" و "completed" به value می‌رسد. در task["completed"]، متغیر task در هر دور به یک record از list اشاره می‌کند.

برای این bridge کافی است این مدل را بفهمی: نام → value؛ list چند value مرتب را نگه می‌دارد؛ record چند field نام‌دار را کنار هم نگه می‌دارد. لازم نیست هنوز دربارهٔ memory model پیشرفته چیزی بدانی.

تبدیل با اعتبارسنجی یکی نیست. تبدیل عمداً representation را عوض می‌کند؛ مثلاً int("2") تلاش می‌کند رشتهٔ عددی را به عدد تبدیل کند. اعتبارسنجی می‌پرسد آیا value فعلی از قبل شکل/قید مورد انتظار را دارد یا نه. int("two") هم نشان می‌دهد هر ورودی قابل تبدیل نیست. در این Lab نیازی به conversion نداری؛ فقط از همین حالا این دو ادعا را یکی نگیر.

۲) function، parameter، local name و return

starter واقعی Lab این است:

def filter_tasks(tasks, mode="all"):
    if mode == "all":
        return list(tasks)
    if mode == "unfinished":
        # starter defect
        return list(tasks)
    raise ValueError("unsupported mode")

• filter_tasks نام function است: یک قطعه رفتار قابل فراخوانی.
• tasks و mode parameter هستند: ورودی‌هایی که هنگام call مقدار می‌گیرند.
• mode="all" یعنی اگر caller مقدار دوم ندهد، مقدار پیش‌فرض "all" استفاده می‌شود.
• return نتیجه را به caller برمی‌گرداند و اجرای همان call را تمام می‌کند.
• اگر داخل تابع نامی مثل result = [] بسازی، آن نام برای محاسبهٔ همان تابع یک local name است.

یک call ساده:

visible = filter_tasks(TASKS, "unfinished")

اینجا visible نامی است که به value برگشتی وصل می‌شود؛ خود function با parameterها کار می‌کند و یک value برمی‌گرداند.

۳) comparison، if و یک الگوی سادهٔ iteration/filter

if mode == "unfinished": یک comparison می‌سازد. نتیجه comparison یک boolean است و if فقط وقتی branch را اجرا می‌کند که شرط true باشد.

Repair مورد انتظار را حفظ نکن؛ منطقش را بفهم. یک شکل صریح از filtering می‌تواند چنین الگویی داشته باشد:

result = []
for task in tasks:
    if task["completed"] is False:
        result.append(task)
return result

for اعضای list را یکی‌یکی می‌بیند. if فقط رکوردهای unfinished را انتخاب می‌کند. append رکورد انتخاب‌شده را به result اضافه می‌کند. سپس return list جدید را برمی‌گرداند. بعداً می‌توان همین ایده را با syntax فشرده‌تر نوشت، اما برای bridge مهم‌تر است که flow را ببینی: iterate → compare → keep/reject → return.

۴) import یعنی استفاده از کدی که در فایل/ماژول دیگری تعریف شده

تست واقعی Lab این خط را دارد:

from src.filtering import filter_tasks

یعنی test نمی‌خواهد function را دوباره تعریف کند؛ آن را از module موجود در src/filtering.py وارد می‌کند. در این مرحله import را به همین اندازه بفهم: «نامی را از یک module دیگر برای استفاده در این فایل در دسترس قرار بده.» جزئیات package resolution در درس‌های ابزار و محیط عمیق‌تر می‌شود.

۵) source file، data file و in-memory value را قاطی نکن

• src/filtering.py source file است: متن کدی که ویرایش می‌کنی.
• یک JSON/fixture یا constant مثل TASKS دادهٔ نمونه را نمایش می‌دهد.
• وقتی test اجرا می‌شود، Python از این متن‌ها object/valueهایی در حافظه می‌سازد. tasks داخل function همان value زمان اجراست، نه خود فایل.

وقتی source را edit می‌کنی، برای دیدن اثرش باید برنامه/test را دوباره اجرا کنی. تغییر فایل به‌تنهایی evidence رفتار جدید نیست.

۶) command و چرخهٔ run را حداقلی یاد بگیر

از پوشهٔ lab/LAB-01/learner/fixture command تست را اجرا کن:

python -m unittest discover -s tests -v

اگر سیستم شما command دیگری برای Python دارد، همان interpreter محیط خودت را استفاده کن؛ هدف bridge حفظ‌کردن نام executable نیست. سه چیز را پیدا کن:

1. command از کدام working directory اجرا شد؛
2. کدام test ok یا FAIL/ERROR شد؛
3. اولین پیام مفیدی که تفاوت expected و actual یا محل خطا را نشان می‌دهد کجاست.

چرخهٔ پایه همیشه این است:

edit → run → observe → diagnose → repair → rerun

هیچ مرحله‌ای را با «فکر می‌کنم درست شد» جایگزین نکن.

۷) چهار خانوادهٔ failure را از هم تشخیص بده

برای شروع همین طبقه‌بندی کافی است:

• syntax/parse failure: برنامه حتی ساختار کد را نمی‌تواند بخواند؛ معمولاً قبل از اجرای test behavior متوقف می‌شوی.
• import/setup failure: test به module/path/dependency لازم دسترسی پیدا نمی‌کند؛ هنوز دربارهٔ behavior تابع نتیجه نگرفته‌ای.
• runtime error: کد شروع می‌شود اما هنگام اجرا exception می‌دهد.
• assertion/test failure: کد اجرا شده، اما observed value با expected value فرق دارد.

این تمایز مهم است، چون repair برای هرکدام متفاوت است. PASS فقط یعنی oracleهای اجراشده در همان run مخالفتی پیدا نکرده‌اند؛ mastery یا صحت کلی محصول را ثابت نمی‌کند.

۸) unittest را به‌عنوان expected-versus-actual evidence بخوان

یکی از تست‌های واقعی می‌خواهد:

result = filter_tasks(TASKS, "unfinished")
self.assertEqual([t["id"] for t in result], [1, 3])

سمت راست [1, 3] expected behavior این test است. سمت چپ از اجرای واقعی function می‌آید. starter فعلی برای mode unfinished کل list را برمی‌گرداند، پس این oracle باید تفاوت را آشکار کند. هدف bridge این نیست که output خطا را حفظ کنی؛ هدف این است که بتوانی از report به این زنجیره برسی:

test → expected → actual → branch مسئول → تغییر محدود → rerun.

micro-readiness check — قبل از ورود به LAB-01

بدون نگاه به پاسخ آماده، این پنج کار را انجام بده:

1. در یک جمله بگو tasks، mode و result/visible چه نقشی دارند.
2. روی یک record مثل {"id": 2, "completed": True} پیش‌بینی کن شرط completed is False چه می‌کند.
3. توضیح بده چرا src/filtering.py source است ولی value ورودی function خود فایل نیست.
4. command تست را اجرا کن و اولین failure مفید را پیدا کن.
5. قبل از edit بنویس کدام branch کوچک‌ترین change surface برای behavior unfinished است و بعد از edit چه testهایی باید دوباره اجرا شوند.

اگر این پنج مورد را می‌توانی انجام دهی، bridge بسته است و وارد LAB-01 شو. اگر نه، فقط همان بند نامطمئن را دوباره بخوان و probe را تکرار کن. Evidence bar اصلی LAB-01 تغییر نکرده است: bridge فقط hidden prerequisite را می‌بندد؛ task contract، bounded execution، diff review و human verdict همچنان باید کامل انجام شوند.

اجرای مستقل — LAB-01

در repository مصنوعی داخل labs/LAB-01/fixture/، slice فیلتر task را با یک AI coding assistant یا نقش‌آفرینی عامل/انسان اجرا کنید.

الزام‌ها:

• قبل از edit، AI Work Record v1 و plan gate را ثبت کنید.
• تغییر را به fixture محلی محدود کنید.
• تست‌های visible را اجرا کنید و evidence را ثبت کنید.
• diff را برای edit نامرتبط بررسی کنید.
• no-schema-change را جداگانه بررسی کنید.
• verdict انسانی ACCEPT / MODIFY / REJECT + rationale + residual uncertainty + next action بدهید.
• AI output را oracle یا final decision تلقی نکنید.

اگر ابزار AI در دسترس نیست، همین loop را با یک «candidate change» دستی اجرا کنید؛ skill مورد سنجش کنترل workflow و evidence است، نه برند ابزار.

چه زمانی AI Work Record قابل قبول است؟

قبل از ACCEPT بررسی کنید:

1. goal/context/constraints/done قبل از run قابل استخراج بوده‌اند.
2. برای task پیچیده‌ی این درس edit قبل از plan review شروع نشده است.
3. actual change surface با approved plan/scope مقایسه شده است.
4. deviationها توضیح، revert یا دوباره تأیید شده‌اند.
5. evidence هم behavior و هم boundary/regression risk را پوشش می‌دهد.
6. criterion/constraintها به evidence مشخص map شده‌اند.
7. diff برای unrelated edit خوانده شده است.
8. AI report یا CI به‌تنهایی final acceptance نشده است.
9. انسان verdict، rationale، residual uncertainty و next action را ثبت کرده است.
10. FND-004 boundary حفظ شده و repository reading عمیق به این درس کشیده نشده است.

machine checks لازم‌اند اما کافی نیستند.

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

ارزیابی پنج لایه دارد: retrieval، application/run، diagnosis، human decision و transfer.

برای PASS در سؤال‌های blocking باید:

• هر پنج مفهوم در record قابل مشاهده باشند؛
• contract و plan gate واقعی باشند، نه متن تشریفاتی؛
• change boundary از permission جدا بماند؛
• evidence شامل diff و behavior/constraint evidence باشد؛
• final verdict انسانی و قابل دفاع باشد؛
• در domain جدید همان invariantها حفظ شوند بدون کپی‌کردن wording مثال filter.

Evidence نهایی این درس: AI Work Record v1 + LAB-01 run/evidence + human decision record.

منابع فنی و وضعیت جاری

ISO/IEC/IEEE 29148:2018 همچنان Edition 2 منتشرشده است و ISO آن را در مرحله‌ی «to be revised» نشان می‌دهد. Edition 3 هنوز Draft International Standard و under development است و جایگزین منتشرشده‌ی 2018 نشده است.

راهنمای فعلی OpenAI Codex بر context مناسب، دستورهای repository-level، test/check و diff review پیش از پذیرش تأکید دارد. راهنمای GitHub Copilot task workflow روی taskهای well-scoped، acceptance criteria، research/plan پیش از تغییر و build/test/validate تأکید می‌کند. Claude Code نیز plan mode پیش از edit و run/verify tests را مستند می‌کند.

این منابع نشان می‌دهند چند ابزار امروزی الگوهای مشابهی برای context، plan و verification دارند؛ اما هیچ vendor workflow در این درس authority جهانی مهندسی نیست. پنج مفهوم و AI Work Record v1 از authority منجمد همین درس می‌آیند.