‏gittifacts: پلتفرم گیت برای دنیای ایجنت‌ها

Jovi De Croock بعد از اینکه Cloudflare از برنامه‌نویس‌ها خواست «پلتفرم گیت بعدی» رو بسازن، یه هفته وقت گذاشت و gittifacts رو ساخت. این یه پلتفرم گیت agent-native هست، یعنی از اول برای وقتی طراحی شده که چند ایجنت هوش مصنوعی هم‌زمان روی یه مخزن کار می‌کنن. نویسنده می‌گه Pull Request فرض می‌کنه دیف رو یه آدم نوشته، پس یه آدم هم باید بخونتش. ولی وقتی ایجنت تو چند دقیقه ۵۰۰ خط می‌نویسه، یا آدم گلوگاه می‌شه یا فقط چشمی رد می‌کنه.

قانون اصلی پروژه یه جمله‌ست: آدم‌ها نیت رو تأیید می‌کنن، ماشین‌ها انطباق رو ثابت می‌کنن. واحد کار به جای PR یه Change هست، یعنی نیت به‌علاوه دیف به‌علاوه مدرک. اول ایجنت یه Plan می‌نویسه (نیت، معیارهای پذیرش، چیزایی که خارج از محدوده‌ست و مسیرهایی که دست می‌زنه) و یه آدم تأییدش می‌کنه. خوندن یه پاراگراف نیت خیلی ارزون‌تر از خوندن دیفه. بعد ایجنت با start_change یه fork جدا با توکن push مخصوص همون fork می‌گیره، پس هیچ ایجنتی نمی‌تونه مستقیم به main پوش کنه:

create_plan({ repoId, title, intent, acceptanceCriteria, scopePaths })
start_change({ repoId, planId, title, category: 'fix' })
// git push to the fork
wait_for_change({ changeId, until: 'evidence_ready', timeoutSec: 50 })
request_review({ changeId })

بعد از هر push، CI و یه سری مرحله‌ی مدرک‌گیری اجرا می‌شه: اثبات red/green برای فیکس‌ها (یعنی تست جدید روی کامیت پایه فیل می‌شه و روی کامیت جدید پاس)، coverage و mutation score روی خط‌های تغییرکرده، دیف API عمومی و وابستگی‌ها، و یه preview deploy. نتیجه امضا می‌شه و به شکل git note روی کامیت ذخیره می‌شه. بعد یه تابع خالص (بدون I/O) تغییر رو تو یکی از سه مسیر می‌ذاره: Auto-merge وقتی همه‌چی ثابت شده و ریسکی نیست، Quick review برای تغییرات متوسط، و Full review برای چیزایی مثل breaking API، auth، migration یا وابستگی جدید.

اگه آدم بررسی کنه، دیف خام نمی‌بینه. یه ایجنت بازبین جدا که خلاصه‌ی نویسنده رو ندیده، یه توضیح مرتب‌شده بر اساس ریسک می‌نویسه و هر ادعاش به مدرک اشاره داره. فقط merge queue حق نوشتن روی main رو داره و تداخل‌های متنی رو به یه ایجنت حل‌کننده می‌ده. هر Change پشت فیچر فلگ خودش منتشر می‌شه و اگه خطاها بالا بره، پلتفرم فلگ رو خاموش می‌کنه و یه Change برای revert باز می‌کنه. نویسنده معتقده Auto-merge فقط به خاطر همین برگشت‌پذیری قابل‌قبوله.

چند اصل دیگه هم داره: ادعای ایجنت فقط یه ورودیه و مدرک لازمه؛ سیگنال نامعلوم یا خطادار فقط مسیر رو سخت‌تر می‌کنه، هیچ‌وقت آسون‌تر؛ هیچ‌کس، چه آدم چه ایجنت، کار خودش رو تأیید نمی‌کنه و ایجنت‌ها اصلاً حق تأیید ندارن. Auto-merge هم اولش خاموشه تا پلتفرم بسنجه چقدر با نظر بازبین‌های واقعی هم‌خونی داره. دلیل هر تغییر هم با یه note امضاشده تو refs/notes/why تو خود گیت می‌مونه.

بیشتر کد رو خود ایجنت‌ها نوشتن و تصمیم‌ها تو فایل DECISIONS.md ثبت شده که الان بیشتر از ۳۵۰۰ خطه. وقتی خود gittifacts رو روی gittifacts بردن، شش Change ازش رد شد و پنج باگ پلتفرم پیدا شد. نویسنده ضعف‌ها رو هم صادقانه گفته: Auto-merge هنوز به محیط تست نویسنده اعتماد می‌کنه، مدرک‌گیری روی همین مخزن ۱۳ تا ۱۷ دقیقه برای هر Change طول کشید، و اگه Plan بد باشه، فقط سریع‌تر به نتیجه‌ی اشتباه می‌رسی.

نکات کلیدی:

• gittifacts متن‌باز با لایسنس MIT هست و بدون حساب Cloudflare هم لوکال اجرا می‌شه.
• واحد کار Change هست: نیت + دیف + مدرک، و نقطه‌ی اصلی تأیید انسانی Plan هست.
• سه مسیر بررسی: Auto-merge (Lane 0)، Quick review (Lane 1) و Full review (Lane 2).
• قضاوت LLM فقط می‌تونه Change رو به بررسی سخت‌تر ببره، نه برعکس.
• مدرک‌گیری روی مخزن خود پروژه ۱۳ تا ۱۷ دقیقه برای هر Change طول کشید.