واژه‌نامه
موجودیت‌های هسته
بخش با عنوان “موجودیت‌های هسته”عامل: کارگری هوش مصنوعی با هویت، نقش، مهارت‌ها و آداپتور. دقیقاً به یک فضای کاری تعلق دارد. کنشگر اصلی در سیستم.
آداپتور: اجراکننده‌ای که یک نوبت عامل را می‌چرخاند. دو مورد عرضه می‌شود: Control Center (built-in) — هارنس درون‌فرایندی که با ارائه‌دهندگان مدل حرف می‌زند — و Claude Code از طریق claude -p. Cursor، Codex، Anthropic، OpenAI و بقیه ارائه‌دهنده‌هایی روی آداپتور داخلی‌اند، نه CLIهای جداگانه. مدیریت آداپتورها و مدل‌ها را ببینید.
فضای کاری: مستأجر ایزوله‌سازی سطح‌بالا. عامل‌ها، مخزن‌ها، فضاها، تیکت‌ها، حافظه و پایپ‌لاین‌ها را گروه می‌کند. ایزوله‌سازی ساختاری است، نه قراردادی: هر فضای کاری فایل SQLite خودش را دارد (<dataDir>/<workspaceId>/workspace.db)، پس یک خواندن میان‌فضاکاری کامپایل نمی‌شود. هر مسیر درون برنامه با /workspaces/:workspaceId شروع می‌شود — نقشهٔ مسیرها را ببینید.
میزبان کد: یک میزبان کد — GitHub، GitLab یا Bitbucket Cloud. میزبان کد ویژگی هر مخزن است، هنگام ثبت از ریموت origin آن خوانده می‌شود و آداپتور API و اعتبارنامهٔ آن مخزن را انتخاب می‌کند. یک فضای کاری می‌تواند مخزن‌هایی روی هر سه داشته باشد؛ سطوح تجمیع‌کننده (صندوق ورودی، صف PR) روی هر میزبان کد نماینده‌شده پخش می‌شوند، نتایج را ادغام می‌کنند و شکست‌ها را ایزوله نگه می‌دارند تا یک میزبان کد دور از دسترس هرگز بقیه را خالی نکند. میزبان‌های کد در پشتیبانی تفاوت دارند — جدول توانایی‌ها را در اتصال میزبان کد ببینید.
مخزن: یک مخزن Git که درون یک فضای کاری ثبت شده است. محدود به فضای کاری — همان checkout ثبت‌شده در دو فضای کاری دو ردیف مستقل با دو شناسه است؛ هویت مخزن میان فضاهای کاری با مسیر فایل‌سیستم تعیین می‌شود، نه با شناسه. ثبت به یک درخت کاری git نیاز دارد که ریموت origin آن به یک میزبان کد پشتیبانی‌شده اشاره کند. هر مخزن همان میزبان کد را حمل می‌کند (github / gitlab / bitbucket) که آداپتور API و اعتبارنامهٔ استفاده‌شده برای آن را انتخاب می‌کند.
مخزن ایزوله: یک worktree محدود به فضای کاری از یک مخزن ثبت‌شده. کپی‌هنگام‌نوشتن از طریق rift هر جا آن نسخهٔ بومی عرضه شود؛ git worktree در Windows. برای هر فضا آماده می‌شود — هر گفتگو در آن فضا یک checkout مشترک دارد — پس عامل‌ها هرگز منبع را تغییر نمی‌دهند.
فضا: یک محفظهٔ همکاری محدود به فضای کاری با مشارکت‌کنندگان انسانی و عاملی، یک Mode ماندگار، وضعیت آماده‌سازی و یک SpaceKind (topic / agentPeer / system / pr / slack) که تعیین می‌کند چگونه دسته‌بندی، بی‌صدا، نشان‌دار و پاک‌سازی خودکار شود. مالک worktreeهای ایزوله‌ای است که گفتگوهایش به اشتراک می‌گذارند (کپی‌هنگام‌نوشتن از طریق rift؛ git worktree در Windows).
گفتگو: یک جریان پیام درون یک فضا، با شناسه، تاریخچه و بافت اجرای عامل خودش. گفتگوها در یک فضا هم‌ترازند — جریان اصلی یا «main» وجود ندارد. هر کدام به‌عنوان یک زبانهٔ ویرایشگر باز می‌شود؛ وضعیت خوانده‌نشدهٔ یک فضا روی همهٔ آن‌ها تجمیع می‌شود.
رشته: گفتگویی که anchorMessageId آن تنظیم شده است: به یک پیام از گفتگویی دیگر در همان فضا لنگر انداخته، با بافت تازه‌ای از عامل که آن پیام لنگر بذرش را کاشته است. یک سطح عمق — رشته‌ها هرگز به رشته‌ها لنگر نمی‌اندازند.
تیکت: تجمیع واحد کار. مستقل از فروشنده: به‌طور پیش‌فرض local، با آداپتورهای همگام‌سازی برای Linear، GitHub Issues، Jira Cloud و ClickUp — هرچند هیچ سطحی در برنامه اتصال همگام‌سازی نمی‌سازد. از سلسله‌مراتب، پیوندها و واگذاری پشتیبانی می‌کند. واگذاری به یک عامل مالکیت را ثبت می‌کند و چیزی اعزام نمی‌کند؛ واگذاری به یک تیم استثناست (TeamRoutingService سرگروه را اعزام می‌کند).
پایپ‌لاین: یک گردش‌کار مبتنی بر DAG که گام‌ها (اعزام عامل، اسکریپت‌ها، شرط‌ها) را زنجیره می‌کند. قالب‌ها آن را تعریف می‌کنند؛ در قالب اجرا اجرا می‌شود.
اشیای مقدار
بخش با عنوان “اشیای مقدار”AgentRole: نقش شمارشی (CEO، coder، reviewer، QA، designer، security، devops، PM، general). پرسونا، دسترسی به حافظه و سلسله‌مراتب را تعیین می‌کند.
AgentSkills: مجموعه‌ای نامحساس به بزرگی و کوچکی حروف از شناسه‌های مهارت که هنگام اعزام بافت مرتبط را به پرامپت‌ها تزریق می‌کنند.
منبع مهارت: یک مخزن GitHub که به‌ازای هر فضای کاری به‌عنوان کاتالوگ مهارت ثبت می‌شود. از پایه نامطمئن است: فرادادهٔ مخزن فقط نمایشی است و هر نصب پیش از رسیدن هر محتوایی به دیسک یا پرامپت، از دروازهٔ اسکنِ «در نبود تأیید، رد کن» می‌گذرد. نصب و مدیریت مهارت‌ها را ببینید.
skills-lock.json: مانیفست مهارت‌های نصب‌شده به‌ازای هر فضای کاری: برای هر یک، مخزن منبع، مسیر مخزن، کامیتی که به آن پین شده و هش محتوای تجمیعی. نصب، به‌روزرسانی و حذف نصب آن را به‌روز نگه می‌دارد؛ verify_skills آن را با دیسک بررسی می‌کند.
دروازهٔ اجرای عامل: یک نقطهٔ پایانی loopback روی cc_server که سیاست کنش را درون سندباکس عامل اعمال می‌کند. هر پوش یک عامل به GitHub به این‌جا هدایت می‌شود، با قاعدهٔ پوش به یک ریموت سنجیده می‌شود و با توکن نوشتنی که عامل هرگز در دست ندارد عبور داده می‌شود؛ فرمان‌های Bash در Claude Code از طریق یک هوک روی همین نقطهٔ پایانی بررسی می‌شوند. سندباکس و امنیت را ببینید.
Mode: chat، plan، review یا orchestrate. به‌ازای هر فضا ذخیره می‌شود، پس یک عامل می‌تواند در فضاهای مختلف حالت‌های متفاوتی داشته باشد؛ هر گفتگو در یک فضا آن را به اشتراک می‌گذارد. پرامپت سیستمی، قواعد نوشتن سندباکس و فهرست مجاز ابزار MCP را دروازه‌بانی می‌کند. ویرایشگر پیام تنها chat، plan و orchestrate را پیشنهاد می‌دهد؛ برچسب chat «عامل» است.
SandboxBackend: microvm (یک VM محصور — تنها بک‌اندی با مرز کرنل، اعمال‌شده بر ترمینال‌های تعاملی)، native (Seatbelt در macOS، bubblewrap در Linux و WSL2) یا none. یک‌بار هنگام بوت بررسی می‌شود؛ native در صورت دسترس بودن بر اعزام عامل اعمال می‌شود و CLI مربوط به Claude Code و ابزار bash هارنس را می‌پیچد. Windows بک‌اند بومی ندارد و Linux به bwrap به‌علاوهٔ socat نیاز دارد، پس اجراها آنجا بدون پوشش‌اند؛ --sandbox off آگاهانه انصراف می‌دهد.
ریگ: یک ماشین دورریختنی که یک عامل در زمان واقعی می‌راند — یک مرورگر یا دسکتاپ Linux محصور، یک شبیه‌ساز Android یا iOS Simulator مدیریت‌شده توسط میزبان، یا یک ترمینال محصور. به‌صورت زنده روی خط تمام‌رزولوشن خودش تماشا می‌شود و تصاحب سمت سرور اعمال می‌شود. محدود به یک گفتگو تا زبانهٔ انسانی و فراخوان‌های browser_use / computer_use / mobile_use / ios_use عامل یک ماشین پیش‌فرض را خطاب کنند. ریگ‌ها و محفظه‌ها را ببینید.
محفظه: مرز قوی‌تر ریگ مبتنی بر VM — یک مرز کرنل، دیسک لایهٔ دورریختنی، دروازهٔ شبکهٔ «به‌طور پیش‌فرض رد کن» و کارگزار اعتبارنامه. ریگ‌های Android و iOS دورریختنی‌اند اما از شبکهٔ مدیریت‌شده توسط میزبان استفاده می‌کنند و این مرز را ادعا نمی‌کنند. راندن هر ریگ از کلاس گاردریل enclosureControl استفاده می‌کند.
RunCost: شمارش توکن/هزینه (توکن‌های ورودی، توکن‌های خروجی، هزینهٔ تخمینی به سنت) برای یک اجرای عامل.
WakeReason: چرایی اعزام یک عامل. شش مقدار: پیام کاربر، واگذاری تیکت، اعزام دوبارهٔ بازیابی پس از شکست، تکمیل تیکت فرزند، ضربان پیگیری زمان‌بندی‌شده و گام پایپ‌لاین.
پورت‌ها
بخش با عنوان “پورت‌ها”SandboxPort: چرخهٔ عمر سندباکس را مدیریت می‌کند (بررسی، اجرا، رویدادها، exec، نابودی).
CredentialBrokerPort: اعتبارنامه‌های محدوده‌دار را برای راه‌اندازی سندباکس ضرب می‌کند — فقط‌خواندنی در محیط عامل، نوشتن فقط در مسیر پوش سمت سرور — و هنگام برچیدن باطلشان می‌کند.
GitRepoInspectorPort: فراداده (مالک، مخزن، شاخه) را از یک مسیر مخزن Git محلی استخراج می‌کند.
EmbeddingPort: بردارهای امبدینگ متن با نرم واحد برای جستجوی معنایی تولید می‌کند.
NotificationPort: اعلان‌های بومی رومیزی را با رعایت دروازه‌بانی دسته/مسیر نشان می‌دهد.
TicketProviderPort: مرز مستقل از فروشنده به یک بک‌اند تیکتینگ (ایجاد، خواندن، فهرست، به‌روزرسانی، گذار، تخصیص).
PipelineEnginePort: یک اجرای پایپ‌لاین را از یک قالب شروع می‌کند و فراخوان‌ها را از موتور مشخص جدا می‌کند.
سرویس‌های دامنه
بخش با عنوان “سرویس‌های دامنه”AgentDispatchService: اجراهای عامل را آغاز می‌کند: مخزن‌های ایزوله را آماده می‌سازد، پرامپت‌ها را می‌سازد، لاگ‌های اجرا را ایجاد می‌کند و جریان‌های رویداد زنده را برمی‌گرداند.
TicketWorkflowService: موتور چرخهٔ عمر تیکت با دامنهٔ خالص، با یک گلوگاه جهشِ هم‌روندی خوش‌بینانه و اعمال ایزولاسیون فضای کاری. گراف گذاری که اعمال می‌کند تنها عامل‌ها و خودکارسازی را مقید می‌کند؛ تغییرات کاربرمحورِ رابط کاربری force: true را می‌فرستند و از آن عبور می‌کنند. هیچ اعزام‌کنندهٔ تیکتی برای واگذارشدهٔ عامل وجود ندارد — AgentDispatchService مالک اعزام است و واگذاری یک تیکت به یک عامل هیچ اجرایی را شروع نمی‌کند. واگذاری یک تیکت به یک تیم استثناست (TeamRoutingService سرگروه را اعزام می‌کند).
PipelineEngine: اجرای اجراها را ارکستر می‌کند: اجراها را شروع می‌کند، گام‌ها را زمان‌بندی می‌کند، وضعیت را ماندگار می‌کند، روترها/اتصال‌ها/ادامه-در-صورت-خطا را مدیریت می‌کند و اجراهای در جریان را پس از راه‌اندازی مجدد از سر می‌گیرد.
PipelineTriggerDispatcher: به رویدادهای دامنه مشترک می‌شود و اجراهای پایپ‌لاین منطبق را برای تریگرهای فعال خودکار شروع می‌کند.
MemoryAccessPolicy: مجوزهای حافظهٔ نقش عامل را روی دامنه‌ها حل و اعمال می‌کند.
HarnessCostCalculator: مصرف توکن هارنس داخلی را بر پایهٔ کاتالوگ models.dev به یک RunCost قیمت‌گذاری می‌کند. اعزام آن شمارش را روی لاگ اجرا ماندگار می‌کند.
BudgetEnforcementService: هزینهٔ ماهانهٔ هر عامل و یک مسدودسازی پیش از اعزام (checkInvocationBlock) را محاسبه می‌کند. آن مسدودسازی تنها توسط آشتی‌دهنده‌های بازیابی (OrphanRunReaper، StrandedTicketReconciler) بررسی می‌شود، هرگز توسط اعزام عادی یک کاربر یا عامل.
BudgetGovernanceService: هزینهٔ ماهانهٔ هر عامل را پس از هر اجرا ارزیابی می‌کند — یک آستانهٔ نرم رخداد هشدار ثبت می‌کند؛ تمام‌شدن بودجه رخداد سختی ثبت می‌کند و چرخهٔ عمر عامل را به paused برمی‌گرداند.
رویدادها
بخش با عنوان “رویدادها”DomainEventBus: باس انتشار/اشتراک پخش درون‌فرایندی برای ارتباط میان ویژگی‌ها. رویدادها نوع‌دارند؛ مشترک‌ها جریان‌های on<T>() را مصرف می‌کنند.
DomainEvent: رابط پایه. هر رویداد یک occurredAt دارد. دسته‌های کلیدی: فضای کاری/عامل، PR/بازبینی، پیام‌رسانی، تیکتینگ، پایپ‌لاین، جلسه‌ها/تقویم، هویت، ریگ‌ها، مشاهده‌پذیری.
جلسه‌ها و تقویم
بخش با عنوان “جلسه‌ها و تقویم”Meeting: یک نشست جلسه که به‌صورت محلی ضبط و رونویسی شده است. میکروفون و صدای سیستم را می‌گیرد، با یک مدل ASR قابل انتخاب روی دستگاه رونویسی می‌کند (به‌طور پیش‌فرض Parakeet TDT v3؛ Parakeet TDT v2، Whisper large-v3-turbo و Whisper base.en جایگزین‌هایند)، گویندگان را تفکیک می‌کند و به یادداشت، موارد اقدام و تصمیم‌ها خلاصه می‌کند. مدل ASR انتخاب‌شده هنگام بوت به‌اجبار نصب می‌شود و عملیات ضبط پس از یک راه‌اندازی مجدد فعال می‌شوند. محدود به فضای کاری؛ روی همان ماشین می‌ماند.
MeetingSegment: یک پنجرهٔ صوتی رونویسی‌شده، با برچسب گوینده (me/them) با یک برچسب تفکیک گوینده و آفست‌های میلی‌ثانیه‌ای.
MeetingActionItem / MeetingDecision: خروجی‌های ساخت‌یافته‌ای که پایپ‌لاین خلاصه‌سازی استخراج و به‌صورت ردیف‌های مجزا ذخیره می‌کند. موارد اقدام می‌توانند به یک تیکت پیوند بخورند.
CalendarEvent: یک ورودی همگام‌شدهٔ Google Calendar محدود به یک فضای کاری و حساب متصل. متمایز از جلسه: یک رویداد یک تعهد زمان‌بندی‌شده است؛ یک جلسه یک نشست ضبط‌شده. با یک MeetingCalendarLink یک‌به‌یک پیوند می‌خورد.
CalendarAccount: یک حساب Google متصل، به‌ازای هر فضای کاری و ایمیل. توکن‌های تازه‌سازی OAuth سمت سرور به‌صورت کلیدهای google_* در <dataDir>/secrets.json ذخیره می‌شوند و هرگز به کلاینت نمی‌رسند؛ جریان کد دستگاه روی سرور کامل می‌شود. یک پرچم authExpiredAt بنر اتصال دوباره را می‌گرداند.
اصطلاحات معماری
بخش با عنوان “اصطلاحات معماری”Clean Architecture: قاعدهٔ وابستگی: ارائه → کاربرد/ارائه‌دهنده‌ها → دامنه ← زیرساخت. دامنه هیچ import زیرساختی ندارد.
پورت‌ها و آداپتورها: دامنه رابط‌های انتزاعی (پورت) را تعریف می‌کند؛ زیرساخت پیاده‌سازی‌های مشخص (آداپتور) را فراهم می‌کند. ریشهٔ ترکیب آن‌ها را به هم می‌بندد.
هستهٔ مشترک: موجودیت‌ها، اشیای مقدار، پورت‌ها و سرویس‌های core/domain/ که میان ۳+ ویژگی به اشتراک گذاشته می‌شوند.
ویژگی-محور: کد بر اساس دامنهٔ کسب‌وکار سازمان می‌یابد (عامل‌ها، پایپ‌لاین‌ها، پیام‌رسانی)، نه بر اساس لایهٔ فنی.
چندنفره، هویت و سرعت
بخش با عنوان “چندنفره، هویت و سرعت”Principal: یک مقدار مهروموم‌شده که انسان‌ها و عامل‌ها را به‌عنوان تنها انتزاع کنشگر یکپارچه می‌کند — UserPrincipal(userId) یا AgentPrincipal(agentId). هر پیام، تیکت، بازبینی، برنامه و لاگ اجرا از طریق یک Principal نسبت داده می‌شود.
کاربر: یک هویت انسانی که در global.db ذخیره می‌شود و بنابراین سراسری میان فضاهای کاری است. کنشگری که یک فضای کاری را می‌سازد مالک آن می‌شود — با مهر روی Workspace.ownerUserId و یک سطر عضویت با نقش مالک در همان عملیات. دیگران با دعوت یا SSO می‌پیوندند.
WorkspaceMember / WorkspaceRole: یک سطر عضویت که یک کاربر را با یک نقش به یک فضای کاری می‌بندد (owner / admin / member / viewer / guest). عضویت — نه کلید جفت‌سازی — مرز دسترسی است. مجوزهای هر مخزن نمی‌گذارند عضویت از اختیارات میزبان کد فراتر برود.
ParticipantPresence: آگاهی زودگذر برای یک Principal (وضعیت، جایگاه، نشانگر، تایپ، وضعیت زنده و هزینهٔ در حال اجرای یک عامل). هرگز ماندگار نمی‌شود؛ هابش در سرور است؛ پیش از پخش با مجوز مخزن فیلتر می‌شود.
حالت دنبال‌کردن: روی یک آواتار کلیک کنید تا تا وقتی خودتان کاری کنید نما را همراهی کنید، سپس جدا شوید. برای انسان‌ها و عامل‌ها کار می‌کند («تماشای کار یک عامل»).
درجهٔ خودمختاری: یک کنترل به‌ازای هر فضا و هر عامل — propose-only / act-with-approval / act-freely — که به‌صورت پروفایلی نام‌دار روی مخزن گاردریل کنش پیاده می‌شود.
ActionClass: مجموعهٔ بسته‌ای از ۱۳ کلاس اثر (fileDelete، gitPush، prCreate، networkEgress، processSpawn، enclosureControl، …). هر ابزار تغییردهنده کلاس‌هایش را اعلام می‌کند؛ موتور گاردریل برای هر دامنه allow / prompt / deny را حل می‌کند (فضا > عامل > فضای کاری > پیش‌تنظیم حالت > پیش‌فرض داخلی).
WriteLedger / کلید خودتوانی: هر جهش یک کلید خودتوانی تولیدشده توسط کلاینت حمل می‌کند (UUIDv7، به‌ازای هر کنش منطقی). دفتر محدود به فضای کاری پیش از اجرای هندلر تکراری‌زدایی می‌کند؛ یک تکرار همان نتیجهٔ اصلی بایت‌به‌بایت را برمی‌گرداند. اتصال دوباره و چندکلاینتی را از پایه ایمن می‌کند.
صندوق ورودی نیازهای من: یک صف میان‌ستونی با قاعده‌ای سخت — یک مورد تنها وقتی ظاهر می‌شود که چیزی را مسدود کند (یک عامل، یک ادغام، یک همگام‌سازی) یا صراحتاً اپراتور را بخواهد.
Plan Studio: سطح برنامه‌ریزی تعاملی — برنامه‌های DAG نوع‌دار قابل‌ویرایش با هزینه، زمان و ریسک هر گام، و تأیید جزئی.
محاسبهٔ بازبینی: محاسبهٔ بازبینی سمت سرور (گروه‌های برگرفته از گراف، دیاگرام‌های نوع‌دار، دیف‌های بصری، دیف‌های قرارداد API، دروازه‌های چندمحوری) که روی review_studio.* سرو می‌شود و در زبانهٔ بازبینی جمع می‌شود.
فضای بازبینی: تنها فضای پشتیبان یک PR (حالت review، نوع pr) که خودتوان ساخته می‌شود و با یک ReviewSpaceAssociation به PR پیوند می‌خورد. هر بازبین یافته‌هایش را در آن ثبت می‌کند و همین آن‌ها را قابل مقایسه می‌کند؛ worktree ایزولهٔ آن، PR را روی head خود checkout دارد.
گرهٔ بازبینی: واحد ساخت‌یافتهٔ یک یافتهٔ بازبینی هوش مصنوعی: نوع (bug، suggestion، recommendation، question، ticket)، اولویت P0–P3، یک سه‌گانهٔ تریاژ دسته/شدت/تلاش، یک لنگر فایل-و-خط، اصلاح پیشنهادی اختیاری و یک امتیاز اطمینان. با add_review_node ثبت می‌شود؛ حکم از گره‌ها محاسبه می‌شود، نه از متن.
Consensus-ready: وضعیت گرهٔ بازبینی که تنها وقتی به آن می‌رسد که یک بازبین همتا یک یافته را تأیید کند — یک عامل نمی‌تواند یافتهٔ خودش را تأیید کند. دکمهٔ انتشار در GitHub زبانهٔ بازبینی هر یافتهٔ باز باقی‌مانده را می‌فرستد (selection: all_open)؛ ابزار MCP با نام publish_review_to_github هنوز به‌طور پیش‌فرض تنها یافته‌های تأییدشدهٔ همتا را می‌فرستد.
سطح بازبینی: سیاست فضای کاری (light، balanced، thorough) که تعیین می‌کند کدام بازبین‌ها پخش شوند (تنها مهندس؛ +qa+architect؛ +security+perf) و یافته‌های زیر آستانه کجا رندر شوند. هرگز یافته‌ای را حذف نمی‌کند.
محور بازبینی: یکی از پنج مسیر امتیازدهی هر بازبینی: correctness، security و testGap برگرفته از یافته‌های بازبین؛ visual و apiContract قطعی. محورهای دروازه‌بانی‌شده در حکم جمع می‌شوند و تنها می‌توانند آن را سخت‌تر کنند — یک دروازهٔ partial یا unavailable حکم را نگه می‌دارد به‌جای اینکه آن را بگذراند.
حکم بازبینی: ship، hold یا block. هر یافتهٔ P0 با اطمینان ≥ 0.7 مسدود می‌کند؛ هر P0 دیگر یا هر P1 نگه می‌دارد؛ در غیر این صورت ship. یک محور دروازه‌بانی‌شده که رد شود، block را تحمیل می‌کند و یافته‌ها نمی‌توانند با رأی بر آن غلبه کنند.
ناوگان و ارزیابی‌ها
بخش با عنوان “ناوگان و ارزیابی‌ها”cc_worker: یک باینری اجراکنندهٔ ناوگانِ Dart خالص و بدون رابط. با یک cc_server جفت می‌شود، توانایی‌های میزبانش را اعلام می‌کند، کارهای اجاره‌ای را می‌کشد، اجرایشان می‌کند و رویدادهای فرایند را بازمی‌گرداند. هیچ وضعیت ماندگاری نگه نمی‌دارد — یک سرور معتبر، N اندام ساده.
JobSpec: مشخصات نوع‌دار برای هر چیز اجراشدنی (اجرای عامل، گام پایپ‌لاین، ایندکس کد، رندر طلایی، بنچمارک، دستهٔ ارزیابی).
مجموعهٔ ارزیابی: یک تعریف ارزیابی محدود به فضای کاری (پرامپت، عامل و حالت هدف، ارزیاب‌ها). هنگام ساخت فضای کاری پنج نمونهٔ آغازین ساخته می‌شود؛ مشاهده‌پذیری → کیفیت آن‌ها را فهرست می‌کند.
استقرار و کلاینت‌ها
بخش با عنوان “استقرار و کلاینت‌ها”معماری کلاینت نازک: هیچ کلاینتی پایگاه داده را باز نمی‌کند؛ یک فرایند cc_server بدون رابط مالک داده است و آن را روی RPC مبتنی بر WebSocket سرو می‌کند. هر کلاینت (دسکتاپ، وب، تلفن) یک رندرکننده روی همان یک اتصال RPC است.
cc_server: باینری سرور بدون رابط (Dart خالص، بدون موتور Flutter). مالک پایگاه دادهٔ Drift/SQLite است، repo-RPC را روی WebSocket سرو می‌کند و سرویس‌های پس‌زمینه (پایپ‌لاین‌ها، MCP، آشتی‌دهنده‌ها) را اجرا می‌کند.
ServerConnectionMode: شیوهٔ رسیدن دسکتاپ به سرورش — local (راه‌اندازی یک cc_server روی همین ماشین، پیش‌فرض) یا remote (شماره‌گیری یکی در جای دیگر). کلاینت وب همیشه remote است.
RemoteRpcClient: کلاینت JSON-RPC مستقل از ترابری که هر کلاینت نازک برای صحبت با سرورش استفاده می‌کند — روی WSS، لوپ‌بک یا رلهٔ کارگزاری‌شده.
محدوده‌بندی فضای کاری برای هر فراخوان: سرور بی‌حالت است — هیچ اتصال فضای کاری به‌ازای نشست وجود ندارد، پس چند کلاینت روی یک سرور هرگز یک «فضای کاری جاری» مشترک ندارند. هر repo/call و sub/subscribe محدود به فضای کاری باید workspace_id را در آرگومان‌هایش حمل کند؛ شناسهٔ غایب یا ثبت‌نشده پیش از باز شدن هر پایگاه داده‌ای رد می‌شود. سپس دسترسی با عضویت و نقش در فضای کاری دروازه‌بانی می‌شود، نه با نشست.
cc_remote: کلاینت نازک تلفن — یک PWA وب Flutter که ناوگان را از طریق رلهٔ کارگزاری‌شده با سیاست ابزار «به‌طور پیش‌فرض رد کن» از راه دور کنترل می‌کند.
cc_signaling_server: یک کارگزار رلهٔ WebSocket بی‌حالت که اتاق‌های دعوت‌محور را میزبانی می‌کند — رله‌ای ساده که تنها فریم‌های سرتاسر-مهروموم‌شده را فوروارد می‌کند، هیچ دادهٔ برنامه‌ای نگه نمی‌دارد و هرگز PSK جفت‌سازی را نمی‌بیند.