‏وقتی ایجنت کد رو تا سبز شدن تست‌ها درست می‌کنه، تاریخچه‌اش کجا می‌ره؟

این مقاله قسمت سوم یه سری نوشته درباره‌ی ایجنت‌ها و CI هست. نویسنده می‌گه وقتی ایجنت خودش حلقه‌ی verification-and-repair رو دست می‌گیره (یعنی تست می‌گیره، خطا می‌بینه و کد رو تا سبز شدن عوض می‌کنه)، آخرش فقط یه چیز باقی می‌مونه: attestation، یعنی سندی که می‌گه سر فلان کامیت این چک‌ها اجرا شدن و پاس شدن. تلاش‌های شکست‌خورده و کدهای میانی دور ریخته می‌شن.

به گفته‌ی نویسنده، تو Swamp که خودشون هم با همین مدل کار می‌کنن، attestation جزئیات خوبی داره: هر کنترلی که اجرا شده با نتیجه و مدت زمانش، هش کامیت و checksum فایل‌های کانفیگ. ولی باز هم مسیر رسیدن به اون نقطه توش نیست. آدم‌ها موقع کد نوشتن ردپا جا می‌ذارن، تاریخچه‌ی کامیت، بحث زیر PR، ترد اسلک و حتی حافظه‌ی ریویوئر. حلقه‌ی ایجنت فقط یه کامیت نهایی جا می‌ذاره.

نویسنده معتقده سؤال «اگه ایجنت کد رو نوشته، کی مسئوله؟» اون‌قدرها هم سخت نیست: همون آدمی که دستور داده، معیار verify رو تعریف کرده و تصمیم گرفته شیپ کنه. مرکز CodeX دانشکده حقوق استنفورد فوریه‌ی ۲۰۲۶ این وضع رو یه خلأ مسئولیت دونسته، و نویسنده قبول داره که سر مرز فروشنده و مشتری حق با اوناست، ولی می‌گه برای خود مهندس ماجرا روشنه. مسئله‌ی سخت‌تر اینه که اون آدم ابزار جواب دادن نداره.

مقاله سه‌تا خاصیت رو از هم جدا می‌کنه. configuration integrity می‌گه آیا همون قوانین و پرامپت‌های مورد انتظار روی اجرا حاکم بودن یا نه. result integrity می‌گه آیا کنترل‌ها واقعاً اجرا شدن و همون نتیجه‌ای رو دادن که ادعا شده. iteration provenance یه سؤال دیگه‌ست: تو راه چی گذشت؟ این یکی ثابت نمی‌کنه تشخیص ایجنت از یه خطا درست بوده، فقط پروسه رو بعداً قابل بازرسی می‌کنه.

کمترین رکورد به‌دردبخور از نظر نویسنده اینه: برای هر تلاش، کامیت یا diff ورودی و خروجی، چک‌هایی که اجرا شدن و خطاهایی که برگردوندن، مدل و کانفیگ حاکم بر اون اجرا، و لینک به تلاش بعدی؛ همه وصل به attestation نهایی. کنارش metadata پوشش verify هم لازمه، چون سبز بودن تست‌ها نمی‌گه تست‌ها اصلاً مسیرهای تغییریافته رو پوشش دادن. ابزارهای بالغ زنجیره‌ی تأمین مثل in-toto و SLSA و Sigstore هم همگی فرض می‌کنن کد رو آدم می‌نویسه، پس به قول نویسنده زنجیره باید یه قدم عقب‌تر کشیده بشه.

نکات کلیدی:

• attestation رایج فقط وضعیت نهایی رو نگه می‌داره: چک‌های اجراشده، نتیجه و مدتشون، هش کامیت و checksum کانفیگ
• iteration provenance یعنی زنجیره‌ی تلاش‌ها: هر خطا، تغییر کدی که جوابش بوده و تلاش بعدی
• توضیح خود ایجنت از علت خطا ورودی تحقیقه، نه نتیجه‌ی قطعی درباره‌ی ریشه‌ی مشکل
• in-toto و SLSA (از L1 تا L3) و Sigstore مرحله‌ی build و deploy رو پوشش می‌دن، نه مرحله‌ی نوشتن کد
• بدون metadata پوشش، «امن» از «چک‌شده با مجموعه‌ی ناقص» جدا نمی‌شه