# 🛡️ Antigravity Shield — Workspace Rules & Behavioral Invariants

### 🎨 قاعده یکپارچگی تم‌های پویا و ایزولاسیون هویت برند (Dynamic Accent Theme Integrity & Brand Shield Invariant)

۱. **ممنوعیت مطلق کلاس‌های رنگی هاردکد در عناصر تعاملی (Zero Hardcoded Accent Classes):**
   در کلیه کامپوننت‌ها، کارت‌ها، تب‌ها، فیلترها، دکمه‌های اکشن (مانند Install)، رینگ‌های فوکوس و بج‌های وضعیتی، استفاده مستقیم از کلاس‌های رنگی ثابت (مانند `sky-500`، `blue-600`، `cyan-500`) برای مؤلفه‌های استیت‌دار اکیداً ممنوع است. تمام این عناصر باید مستقیماً از متغیرهای داینامیک CSS استخراج شوند:
   - پس‌زمینه و هاور دکمه‌ها: `var(--color-primary-btn)` و `var(--color-primary-btn-hover)`
   - خطوط مرزی، آیکون‌های هایلایت و متون شاخص: `var(--color-accent)`
   - پس‌زمینه و بردر بج‌ها: `var(--color-badge-bg)` و `var(--color-badge-border)`
   - هاله‌ها و سایه‌ها: `var(--color-accent-glow)`

۲. **ایزولاسیون نفوذناپذیر لوگو و هویت برند (Brand Identity Immunity):**
   لوگوها، نشان‌های شیلد و نمادهای هویت سازمانی هسته سیستم (مانند `NavLogo.tsx` و برچسب‌های PRO/SHIELD رسمی) از سامانه تغییر رنگ UI کاملاً ایزوله هستند و تحت هیچ شرایطی نباید با متغیرهای تم دستخوش تغییر شوند.

۳. **گیت اعتبارسنجی فیزیکی چندرنگه پیش از استقرار (Multi-Accent Physical Inspection Gate):**
   پیش از اعلام نهایی شدن پیاده‌سازی یا رفع باگ تم، دستیار موظف است تمام زیرماژول‌ها و تب‌های درونی (Ecosystem, McpTab, RulesTab, Modals) را حداقل در دو تم متضاد (مثلاً Seafoam در برابر Crimson Rose) به‌صورت فیزیکی ممیزی کند تا از عدم وجود خطای فانتوم و عدم نشت رنگ استاتیک اطمینان حاصل شود.

### 🔒 قاعده حفاظت از اسرار تجاری و ممنوعیت افشای لوله‌کشی داخلی (Proprietary IP Shield & Anti-Reverse Engineering Invariant)

۱. **ممنوعیت مطلق افشای دیاگرام‌ها و نام‌های لوله‌کشی داخلی (Zero Internal Plumbing Exposure):**
   در اسناد عمومی، مارکتینگ، `README.md`، `CHANGELOG` و توضیحات پروپوزال، افشای موارد زیر به رقبا و عموم اکیداً و مطلقاً ممنوع است:
   - نام دیتابیس‌های خصوصی و محلی (مانند `token_stats.db`، `security.db`، `proxy.db`).
   - پورت‌های لوپ‌بک و ارتباطات بریج داخلی (مانند پورت `8765` یا IPC داخلی).
   - مسیرهای محرمانه واچر و رصدگرها (مانند `~/.gemini/antigravity/brain/`).
   - اسامی توابع و مکانیزم‌های ضدسندباکس (`Virtual DeviceProfile` و ترفندهای مهندسی معکوس بالادست).

۲. **الزام استفاده انحصاری از دیاگرام‌های انتزاعی بلک‌باکس (Abstract Black-Box Architecture Only):**
   هرگونه دیاگرام معماری در مستندات بیرونی باید صرفاً در بالاترین سطح انتزاعی (کلاینت‌ها ➔ گیت‌وی شیلد ➔ سرویس‌های بالادست AI) ترسیم شود و تنها ارزش تجاری، کارکرد کلی و مزیت رقابتی را بیان کند؛ نه نقشه لوله‌کشی و راهنمای کپی‌برداری برای رقبا.

### 🌐 قاعده استعلام لایو مدل‌های هوش مصنوعی (AI Model Discovery & Reality Grounding)

۱. **ممنوعیت مطلق اتکا به حافظه پارامتریک در ادعای عدم وجود مدل:**
   هوش مصنوعی هرگز حق ندارد بر اساس اطلاعات از پیش‌آموخته خود ادعا کند مدلی وجود ندارد یا منتشر نشده است.
۲. **پروتکل سه‌مرحله‌ای اعتبارسنجی مدل:**
   - بازرسی کاتالوگ لوکال پروژه (`latest_models_catalog.json`).
   - اجرای وب‌سرچ زنده برای بررسی آخرین تغییرات نام‌گذاری گوگل، آنتروپیک و اوپن‌ای‌آی.
   - در صورت مشاهده خطای ۴۲۹، علت باید «عدم دسترسی یا اتمام سهمیه اکانت‌های موجود برای این مدل» گزارش شود، نه نفی وجود خود مدل.

### 🔕 قاعده محافظت در برابر طوفان نوتیفیکیشن (Alert Storm Suppression Invariant)

۱. **قانون پیام واحد (Single Consolidated Alert):**
   هیچ رویدادی (اعم از انقضای سهمیه، خطای اتصال یا قطعی) نباید بیش از ۱ نوتیفیکیشن دسکتاپ و ۱ توست در بازه ۱۵ دقیقه‌ای تولید کند و هشدارهای مربوط به تارگت‌های مختلف (IDE و Platform) باید به صورت تجمیعی ارسال شوند.
۲. **ایزولاسیون پروب‌های تشخیصی (Canary Probe Isolation):**
   ابزارهای تست سلامت و پروب‌های دستی باید در حالت ایزوله اجرا شوند و شکست آن‌ها هرگز نباید آلارم سراسری، نوتیفیکیشن‌های اسپم یا چرخش تهاجمی در کل رابط کاربری نرم‌افزار ایجاد کند.

### 🌐 قاعده سه‌گانه دسترسی‌های آنتی‌گرویتی و اجرای خودکار بدون توقف (Antigravity Three-Tier Security & Zero-Prompt Invariant)

۱. **تفکیک سه لایه امنیتی:**
   - **لایه اول (سیستم‌عامل و ترمینال):** `Terminal Auto Execution` و `File Access` که توسط پریست Full Access باز می‌شوند.
   - **لایه دوم (خواندن وب و شبکه):** لایه SSRF Guard مستقل که توسط `browserAllowlist.txt` و `chat.tools.urls.autoApprove` کنترل می‌شود و نیازمند ستاره (`*`) برای حالت بدون توقف است.
   - **لایه سوم (ساب‌ایجنت مرورگر و اجرای اکشن):** کنترل‌شده توسط `browserJsExecutionPolicy` که حتی در حالت Full Access دیفالت آن روی `ALWAYS_ASK` می‌ماند و برای اتوماسیون کامل باید روی `TURBO` قرار گیرد.

۲. **الزام پیکربندی سه‌گانه برای حالت تمام‌خودکار (Full Autonomous):**
   هیچ ایجنتی نباید در مواجهه با توقف‌های وب سردرگم شود یا فرض کند تنظیم Full Access ناقص اعمال شده است؛ ایجنت باید آگاه باشد که باز کردن مرورگر و خواندن وب نیازمند ستاره (`*`) در لیست مجاز دامنه‌ها و تنظیم سیاست اجرای جاوااسکریپت روی `TURBO` است.

### 📊 قاعده تفکیک تله‌متری سیستمی از استنتاج و ایزولاسیون خطاهای روتینگ (Telemetry & Error Invariant)

۱. **تفکیک قطعی ترافیک سیستمی از استنتاج مدل (Strict Inference vs System Segregation):**
   در کلیه ماژول‌های مانیتورینگ، لاگر و لاگ‌های دیتابیس، ترافیک استنتاج هوش مصنوعی (`/v1/chat/completions`, `/v1/messages`) باید از درخواست‌های دوره‌ای سیستمی (پینگ هلث‌چک، رفرش سهمیه، سوییچ اکانت) کاملاً تفکیک شوند. شمارنده‌های خطای سرویس هرگز نباید خطاهای ۴۰۴ روتینگ کلاینت‌های محلی را به عنوان خطای مدل یا شکست ارائه‌دهنده شمارش کنند.

۲. **ممنوعیت انتساب خطاهای روتینگ گیت‌وی به مسدودی حساب‌ها (Zero False Attributions Gate):**
   هوش مصنوعی و لایه مانیتورینگ حق ندارند بالا بودن آمار خطاها را بدون بررسی مستقیم کد وضعیت (`status`) و ستون اکانت (`account_email`)، به ارائه‌دهنده بالادست یا مسدودی حساب‌ها نسبت دهند. خطاهای فاقد اکانت (`account_email = null`) باید صراحتاً در دسته خطاهای زیرساختی گیت‌وی (Gateway Route Errors) برچسب‌گذاری شوند.

۳. **مکانیزم ترمز و دیبانس درخواست‌های رفرش (Refresh Throttling Guard):**
   اندپوینت‌های رفرش سهمیه باید دارای محدودیت نرخ (Rate Limit) و دیبانس در سطح اکانت (حداکثر ۱ درخواست در ۳۰ ثانیه برای هر اکانت) باشند تا باگ‌های کلاینت یا لوپ‌های ناخواسته افزونه‌ها نتوانند هزاران خطای ۴۰۴ در کسری از ثانیه ثبت کنند.