# بسته بازبینی مستقل ODAD — درخواست از بازبین مجزا

**وضعیت: آماده شده؛ بازبینی انجام نشده است.** این سند شرط G5 را برآورده نمی‌کند. نویسنده پیاده‌سازی و خودبازبینی داخلی، بازبین مستقل محسوب نمی‌شود.

## هدف بازبینی

به‌طور مستقل بررسی شود که runner آزمایشی ODAD و خط لوله شواهد در برابر ورودی خصمانه fail-closed هستند، شواهد تست ادعاها را پشتیبانی می‌کنند و پیش از هر استفاده تولیدی چه اصلاحاتی لازم است. آمادگی تولید را از پیش مفروض نگیرید.

## محدوده

- `src/aicp/application/services/odad_bounded_executor.py`
- `src/aicp/application/services/odad_execution_ledger.py`
- `src/aicp/application/services/odad_task_plan.py`
- `src/aicp/application/services/odad_canonical_link.py`
- `src/aicp/application/services/opportunity_qualification.py`
- `tools/odad_e2e_qualification.py`
- تست‌های متناظر `tests/unit/test_odad_*.py` و `tests/unit/test_opportunity_*.py`
- `docs/quality/ODAD-INTERNAL-SECURITY-REVIEW.json`
- `docs/quality/ODAD-E2E-QUALIFICATION-REPORT.json`

## فرمان‌های بازتولید

از ریشه worktree ایزوله اجرا کنید:

```bash
python3 -m pytest -q
python3 -m compileall -q src tools tests
git diff --check
python3 tools/odad_e2e_qualification.py --help
```

اجرای زنده E2E به گزینه صریح `--live` نیاز دارد و یک درخواست محدود خواندنی به GitHub عمومی می‌فرستد. اگر محیط بازبینی شبکه را مجاز نمی‌داند آن را اجرا نکنید. اقدام تولیدی، انتشار یا استفاده از ارائه‌دهنده پولی جزو محدوده نیست.

## تازگی شواهد و محدوده دقیق

درست پیش از بازبینی، `python3 tools/odad_review_attestation.py --manifest` را اجرا و خروجی آن را همراه رکورد بازبینی نگه دارید. این manifest محدوده دقیق و جاری SHA-256/اندازه فایل‌هاست؛ به timestamp گزارش قدیمی یا revision اعلام‌نشده اتکا نکنید. مطمئن شوید regression مربوط به هویت اسکریپت در snapshot و نتیجه فعلی کل تست‌ها در محدوده‌اند. اگر فایلی در طول بازبینی تغییر کرد، manifest را دوباره تولید کنید و بازبینی را از نو شروع کنید یا تغییر محدوده را صریح ثبت کنید. گزارش پذیرش محلی جاری `docs/quality/ODAD-LOCAL-ACCEPTANCE-REPORT.json` است؛ PASS فقط یعنی بررسی‌های فنی محلی موفق بوده‌اند، در حالی که تحویل همچنان مسدود و غیرمجاز است.

## پرسش‌های خصمانه الزامی

۱. آیا جایگزینی مسیر workspace، ترفندهای symlink/hardlink، فایل ویژه تو‌در‌تو یا تغییر هم‌زمان می‌تواند snapshot اجراشده را عوض کند یا از سقف‌ها عبور کند؟
۲. آیا فرایند فرزند می‌تواند به اسرار میزبان، home، خروجی شبکه، مسیرهای قابل‌نوشتن میزبان یا منابع نامحدود CPU/حافظه/دیسک/فرایند دسترسی پیدا کند؟
۳. آیا timeout/termination کل درخت فرایند را واقعاً متوقف و فایل‌های موقت را پاک می‌کند؟
۴. آیا قطع دفتر، دست‌کاری رکورد، کلید idempotency تکراری، نویسندگان هم‌زمان، JSON نامعتبر یا فیلد حساس می‌تواند شواهد جعلی ایجاد کند؟
۵. آیا چرخه وابستگی، وظیفه مفقود، دروازه جزئی/نامعلوم، شواهد کهنه یا مجوز غیر Boolean می‌تواند PASS کاذب ایجاد کند؟
۶. آیا تست‌ها ادعاهای ارجاع‌شده را واقعاً اثبات می‌کنند؟ تست منفی یا فرض پلتفرمیِ مفقود را مشخص کنید.
۷. آیا ادعاهای رقابتی و درآمدی به‌درستی فرضیه معرفی شده‌اند، نه شواهد تقاضای اثبات‌شده؟

## قالب یافته‌ها

برای هر یافته ثبت کنید: شناسه پایدار؛ شدت؛ فایل/خط؛ شواهد بازتولیدپذیر و فرمان دقیق؛ قابلیت سوءاستفاده/اثر؛ اصلاح لازم؛ تست تأیید؛ ریسک باقیمانده؛ وضعیت (`OPEN`، `MITIGATED`، `ACCEPTED_BY_AUTHORITY` یا `NOT_APPLICABLE`). یافته را بدون اجرای دوباره بازتولید آن، رفع‌شده علامت نزنید.

## استقلال و پذیرش

بازبین باید فردی مجزا یا فرایند بازبینی با کنترل مستقل باشد. هویت/نقش بازبین، تاریخ، revision و digest دقیق کد، محدوده، ابزارها، فرمان‌ها، یافته‌ها، محدودیت‌ها و تصمیم نهایی ثبت شود. بازبینی دوباره توسط همان نویسنده، خودبازبینی یا تلاش مدل بدون خروجی، شواهد مستقل نیست.

## به‌روزرسانی شواهد اخیر (۲۰۲۶-۱۰-۱۲)

- آخرین پذیرش کامل محلی پس از سخت‌گیری در تجزیه JSON دفتر ثبت و تطبیق هویت/URL در کشف GitHub: PASS با ۱۶۶۲ تست موفق. compileall، diff-check، راهنمای CLI، صحت دفتر ثبت، JSONها، یکپارچگی سیگنال بازار، مسدود ماندن fail-closed دروازه تحویل و بهداشت فایل‌های متنی همگی PASS هستند. این شواهد متعلق به پیاده‌سازی است، نه بازبینی مستقل.
- ابهام بازتولیدشده در دفتر ثبت اصلاح شد: کلیدهای تکراری JSON و ثابت‌های غیراستاندارد رد می‌شوند و تست رگرسیون دارند. کشف GitHub اکنون مسیر URL ناسازگار با هویت canonical یعنی `full_name`، query/fragment، اسلش انتهایی/تکراری، جداکننده مسیر کدگذاری‌شده با درصد، پورت نامعتبر/غیراستاندارد و userinfo خالی را رد می‌کند. مرز دامنه نیز مستقلاً همین قرارداد محدود را اجرا می‌کند. این اصلاحات محلی‌اند؛ بازبینی مستقل همچنان باز است.

- آخرین پذیرش کامل محلی PASS است: ۱۶۳۹ تست و ۳۸ تست executor/E2E موفق شدند؛ compileall و diff check نیز موفق‌اند. این شواهد متعلق به مرحله پیاده‌سازی است، نه بازبینی مستقل.
- تست واقعی flood در sandbox اکنون تأیید می‌کند محدودیت kernel یعنی RLIMIT_FSIZE نویسنده را متوقف می‌کند و خروجی بازگشتی زیر سقف تنظیم‌شده می‌ماند. stdout و stderr در دو فایل موقت جدا هستند؛ سقف تقریبی فعلی فضای فایل تجمیعی با محدودیت یک مگابایت برای هر فایل، ۲ مگابایت است. حسابداری تجمیعی دیسک همچنان باز است.
- مشاهده صرفاً خواندنی میزبان: سرویس aicommander-agent.service در /system.slice/aicommander-agent.service با Delegate=no و User=root اجرا می‌شود؛ هیچ تنظیم سرویس یا cgroup تغییر نکرد.

- اجرای مجدد پس از افزودن آزمون خصمانهٔ پرشدن هم‌زمان stdout/stderr: پذیرش کامل محلی PASS با ۱۶۵۷ تست؛ آزمون جدید و مجموعه‌های متمرکز executor/attestation موفق‌اند. هر دو نویسندهٔ جریان خروجی تحت RLIMIT_FSIZE جداگانهٔ به‌ارث‌رسیده متوقف می‌شوند و متن بازگشتی زیر سقف capture می‌ماند. این نتیجه وجود سهمیهٔ واحد و تجمیعی دیسک را اثبات نمی‌کند؛ ODAD-SEC-008 برای حسابداری تجمیعی و ارزیابی مستقل همچنان OPEN است.

- اعتبارسنجی زمان attestation اکنون زمان مشاهده‌ای را که بیش از پنج دقیقه در آینده باشد رد می‌کند (با تحمل محدود اختلاف ساعت)؛ آزمون رگرسیون زمان یک ساعت جلوتر را بررسی می‌کند. بنابراین امضای معتبر به‌تنهایی نمی‌تواند زمان آیندهٔ ناموجه را قابل قبول کند. این سخت‌سازی محلی است، نه بازبینی مستقل.

## مسائل باز شناخته‌شده

- mitigation مربوط به snapshot تازه اضافه شده و تست محلی دارد؛ تغییر هم‌زمان و رفتار پلتفرم نیازمند بررسی مستقل است.
- هم‌زمانی میزبان مشترک، پاک‌سازی درخت فرایند و کنترل DoS برای تولید احراز نشده‌اند.
- دفتر از قفل advisory در POSIX استفاده می‌کند و هماهنگی توزیع‌شده نیست.
- G4 جزئی و G5/G6 مسدود هستند. اجرای تولیدی مجاز نشده است.


## تکمیل شواهد فنی (۲۰۲۶-۱۰-۱۲)

- بارگذار مخزن اعتماد بازبینی مستقل سخت‌گیرانه‌تر شد: فایل با `O_NOFOLLOW` باز و همان descriptor اعتبارسنجی می‌شود و پوشهٔ والد در مسیر production باید متعلق به root و غیرقابل‌نوشتن برای group/others باشد. آزمون‌های متمرکز این کنترل را بررسی می‌کنند. این تغییر، بازبینی مستقل محسوب نمی‌شود؛ چون trust store خارجی هنوز provision نشده، G5 همچنان BLOCKED است.

- قرارداد رمزنگاری بازبین نیز سخت‌گیرانه شد: ثبت اثرانگشت کلید عمومی اکنون کلیدهای غیر `Ed25519` را رد می‌کند و آزمون رگرسیون، رد کلید RSA را تأیید می‌کند. آزمون‌های متمرکز executor و attestation: ۴۸ موفق. این تغییر جای بازبینی مستقل را نمی‌گیرد و G5 همچنان مسدود است.

- تجزیهٔ JSON در ابزار اعتبارسنجی attestation سخت‌گیرانه شد: کلیدهای تکراری در objectها و ثابت‌های غیر استاندارد مانند NaN هم در مخزن اعتماد و هم در ورودی attestation رد می‌شوند. تست‌های رگرسیون، کلید تکراری در attestation، کلید تکراری در schema مخزن اعتماد و NaN را پوشش می‌دهند. این شواهد پیاده‌سازی‌اند و جای بازبینی مستقل را نمی‌گیرند.

- اعتبارسنجی artifactهای پذیرش، کنترل سیگنال‌های بازار و خواندن گزارش دروازهٔ تحویل نیز اکنون از تجزیهٔ سخت‌گیرانهٔ JSON استفاده می‌کنند؛ کلیدهای تکراری و ثابت‌های غیر استاندارد به‌طور یکسان رد می‌شوند. دو تست رگرسیون، کلید تکراری و NaN را پوشش می‌دهند. این اصلاح ناهمسانی تفسیر JSON بین مسیر پذیرش و attestation را برطرف می‌کند؛ بازبینی مستقل همچنان انجام نشده است.

- آزمون مرز حاکمیت: امضای معتبر بازبین به‌تنهایی نمی‌تواند یافته‌ای با وضعیت `ACCEPTED_BY_AUTHORITY` را بدون مجوز HAO که جداگانه قابل‌اعتبارسنجی باشد به G5 PASS تبدیل کند. اعتبارسنج BLOCKED برمی‌گرداند و یک تست امضاشده این حالت را پوشش می‌دهد. این کار اصل `ACCEPTED ≠ AUTHORIZED ≠ IMPLEMENTED` را حفظ می‌کند؛ artifact مجوز HAO در این تغییر پیاده‌سازی نشده است.

- آزمون ورودی بدساخت: اعتبارسنج attestation اکنون پیش از بررسی عضویت در مجموعه، نوع فیلدهای decision، severity و disposition را کنترل می‌کند؛ بنابراین آرایه یا شیء JSON در فیلدهای enum به‌جای ایجاد `TypeError`، نتیجهٔ کنترل‌شدهٔ `FAIL` می‌دهد. تست‌های پارامتری این مقادیر نامعتبر را پوشش می‌دهند.


- سخت‌سازی پل canonical: اکنون `ODADCanonicalLink` کنترل می‌کند شناسهٔ خود Task، WorkSession و Artifact برگشتی از repository دقیقاً با شناسهٔ درخواستی برابر باشد؛ سپس lineage را می‌پذیرد. سه آزمون رگرسیون عدم تطابق هویت برگشتی را پوشش می‌دهند و ثابت می‌کنند ledger نوشته نمی‌شود. این مورد با شناسهٔ `ODAD-SEC-016` ثبت شد؛ در سطح محلی اصلاح شده اما بازبینی مستقل همچنان باز است.

- سخت‌سازی محدودیت فرایند sandbox: فرمان Bubblewrap اکنون `CAP_SYS_ADMIN` و `CAP_SYS_RESOURCE` را حذف می‌کند تا capabilityهایی که ایجاد فرایند را از `RLIMIT_NPROC=8` معاف می‌کنند، این محدودیت را بی‌اثر نکنند. آزمون متمرکز محدودیت فرایند و پذیرش کامل محلی با مالک غیرممتاز مورد انتظار worktree موفق شدند. این شواهد، محدودیت تجمیعی cgroup/PID یا صلاحیت مستقل برای production را ثابت نمی‌کند.

- شواهد با اطمینان صفر (`ODAD-SEC-018`): پیش‌تر شواهد متصل و تازه حتی با اطمینان اعلام‌شدهٔ صفر می‌توانستند در دروازه‌های عملیاتی و امتیاز استفاده شوند. اصلاح محلی برای شواهد عملیاتی و شواهد امتیاز، اطمینان بزرگ‌تر از صفر را لازم می‌کند؛ شش آزمون این مسیرها را پوشش می‌دهند. سیاست کالیبراسیون/آستانهٔ اطمینان و بازبینی مستقل همچنان باز است.
- تطبیق نوع شواهد در ارزیابی فرصت (`ODAD-SEC-017`): جست‌وجوی زیررشته می‌توانست `unlicensed_claim` را شواهد مثبت مجوز تلقی کند. اکنون برچسب‌ها توکن‌بندی می‌شوند و قیدهای منفی/نامطمئن صریح پیش از تطبیق پیشوند رد می‌شوند. آزمون‌ها مواردی مانند `license_not_verified`، `revoked_license` و `license_expired` را پوشش می‌دهند؛ دروازهٔ مجوز UNKNOWN و ارزیابی DEFERRED باقی می‌ماند. ابهام برچسب آزاد، واژگان حاکمیتی و بازبینی مستقل همچنان باز هستند. بازبینی مستقل و تعریف واژگان حاکمیتی انواع شواهد همچنان باز است.

- شواهد متناقض (`ODAD-SEC-019`): پیش‌تر یک رکورد مثبت مرتبط کافی بود، حتی اگر رکورد جاری دیگری برای همان دروازه نوع صریحاً منفی/نامطمئن داشت. اکنون وجود چنین رکورد متناقضی نتیجه را به UNKNOWN/DEFERRED می‌برد. شش آزمون تعارض شواهد مجوز اضافه شد. واژگان نوع شواهد آزاد و بازبینی مستقل همچنان باز هستند.

- **ODAD-SEC-020 — بازتولید تأییدشده، تصمیم سیاستی باز:** یک رکورد مرکب `OpportunityEvidence` از `github / owner/repo` با نوع `license_risk_cost_demand_provider_scoring_evidence` به هر پنج دروازهٔ عملیاتی و شواهد امتیاز متصل شد؛ ارزیاب `INVESTIGATE`، وضعیت `PASS` برای هر هشت بررسی و امتیاز `80.0` برگرداند. چون قرارداد فعلی صریحاً رکوردهای متمایز یا منابع مستقل را الزامی نمی‌کند، محدودیت استقلال منبع اضافه نشد. HAO/حاکمیت باید دانه‌بندی شواهد، هویت/استقلال منبع و واژگان کنترل‌شدهٔ نوع شواهد را تعیین کند. این وضعیت فقط محرک پژوهش است، نه مجوز یا اثبات اعتبار حقوقی/تجاری. بازبینی مستقل همچنان باز است.

- **ODAD-SEC-021 — بازتولید تأییدشده، کاهش ریسک محلیِ جزئی، باز:** مدل دامنه قبلاً شواهد `source=github`، `kind=repository_metadata`، `source_record_id=owner/repo` و `url=https://github.com/other/repo` را می‌پذیرفت. اکنون قرارداد دامنه همین نوع محدودِ فرادادهٔ مخزن GitHub را به URL از نوع HTTPS در `github.com/{owner}/{repo}` متصل می‌کند و عدم‌تطابق، query/fragment و پورت غیرپیش‌فرض را رد می‌کند و مسیر دقیقاً دو‌بخشی می‌خواهد (بدون اسلش انتهایی/تکراری یا جداکنندهٔ مسیر کدگذاری‌شده با درصد). آزمون‌های ساخت مستقیم این حالت‌ها را پوشش می‌دهند. در مرز فرصت والد نیز همین نوع محدود `repository_metadata` از GitHub باید اکنون با `source_record_id` فرصت والد، بدون حساسیت به بزرگی حروف، یکسان باشد؛ آزمون‌ها عدم‌تطابق، تطابق و مستثنا بودن منابع/انواع دیگر را پوشش می‌دهند. قرارداد سایر منبع/نوع‌ها، قواعد گسترده‌تر نرمال‌سازی/redirect/تغییر نام و بازبینی مستقل همچنان باز هستند. در بازتولید فقط‌خواندنی ۱۴ اکتبر ۲۰۲۶، ساخت مستقیم دامنه همچنین این دو مورد را پذیرفت: `pypi / sample-pkg / https://www.npmjs.com/package/attacker / package_metadata` و `npm / @acme/widget / https://pypi.org/project/other-package/ / package_metadata`. آداپترهای فعلی URL رجیستری متناظر خود را تولید می‌کنند؛ این شکاف قرارداد در مرز دامنه است، نه مدرک تولید این عدم‌تطابق توسط آداپتر. سیاست هویت رجیستری هنوز باز است؛ تغییری در پیاده‌سازی انجام نشد.

- **ODAD-SEC-025 — بازتولید تأییدشده، کاهش ریسک محلی، بازبینی مستقل باز:** خطاهای مستقیم connectorهای PyPI/npm با `source=unknown` ثبت می‌شدند و timeout/reset گذرا با `retryable=false` طبقه‌بندی می‌شد. اکنون `PackageRegistryDiscovery` مقدار `source` را ارائه می‌کند، خطاهای HTTP/URL/timeout/I/O را با `PackageRegistryDiscoveryError` و پیام امن، status و retryability صریح می‌پیچد و orchestrator این نوع را می‌شناسد. تست‌های رگرسیون timeout، reset، URL error، HTTP 429/503 و 404 غیرقابل retry و اتصال درست منبع را پوشش می‌دهند. retry خودکار اضافه نشده است. بازبین مستقل باید طبقه‌بندی 403 دارای rate-limit و سیاست retry در caller را بررسی کند؛ این اصلاح محلی گواهی G5 نیست.

## گسترش دامنه — گردآورندهٔ محدود شواهد GitHub (۱۴ اکتبر ۲۰۲۶)

مانیفست فعلی ابزار اعتبارسنجی مرجع قطعی دامنه و SHA-256 است. فایل‌های افزوده‌شده: `tools/odad_github_snapshot_collector.py`، `tests/unit/test_odad_github_snapshot_collector.py`، `tools/odad_source_acquisition.py`، `tests/unit/test_odad_source_acquisition.py` و دو سند انگلیسی/فارسی `ODAD-GITHUB-SOURCE-COLLECTOR-2026-10-14`.

بازبین باید ساخت URL با مبدأ ثابت، تغییرمسیر و URL نهایی، وضعیت پاسخ، Content-Type، UTF-8/JSON، سقف بدنه و timeout و تطبیق هویت پاسخ (`number`، `html_url`، `repository_url`، عنوان و وضعیت) را به‌صورت خصمانه بررسی کند. کنترل طول و digest و رفتار در برابر symlink/race را بررسی و تشخیص دست‌کاری را از ذخیره‌سازی WORM جدا کند. اطمینان یابد دادهٔ ثبت‌شده به ادعای احرازشدهٔ ناشر، صلاحیت shortlist، مجوز اجرا یا مدرک درآمد واقعی تبدیل نمی‌شود. افشای اطلاعات و ذخیره/گزارش نامحدود را نیز ارزیابی کند. متن مسئلهٔ GitHub ورودی غیرقابل‌اعتماد است.

شواهد مجری: یک GET محدود و فقط‌خواندنی برای مسئلهٔ `4` در `warpspeedopen-source/warpspeed-bounties`؛ digest پاسخ ذخیره‌شده دوباره بررسی شد. متن جایزهٔ مشروط، تأمین مالی، قصد خرید، پرداخت تضمین‌شده یا درآمد دریافت‌شده را ثابت نمی‌کند. پس از آن کار روی نامزد، نظر، PR، ارسال، تماس، پرداخت، commit، push یا deployment انجام نشد. پذیرش محلی ۱٬۸۶۲ موفق و ۲ ردشده گزارش کرد؛ این بازبینی مستقل نیست. ذخیره‌سازی snapshot، WORM نیست و امضا/ریشهٔ اعتماد بیرونی یا حفاظت replay ندارد. G4 ناقص و G5/G6 مسدود هستند؛ تحویل مجاز نیست.

درست پیش از بازبینی `python3 tools/odad_review_attestation.py --manifest` را اجرا و خروجی کامل را نگه دارید. اگر هر فایل دامنه تغییر کرد، بازبینی را از نو آغاز یا دامنه را رسماً محدود کنید. آزمون آفلاین اولویت دارد مگر آنکه محیط بازبینی صریحاً شبکه را مجاز بداند. پیکربندی ریشهٔ اعتماد را در این کار تغییر ندهید.

## گسترش محدوده — منشأ ادعاهای تجاری و کشف کار پولی (۲۰۲۶-۱۰-۱۴)

محدودهٔ canonical بازبینی از ۷۲ به ۸۳ فایل گسترش یافت؛ زیرا manifest قبلی قراردادهای پیوند ادعا/تصویر ثابت منبع، سرویس‌های دروازهٔ تجاری/اقتصاد/تناسب درآمد و آداپتور کشف issue پولی به‌همراه تست‌های رگرسیون آن‌ها را شامل نمی‌شد. این فایل‌ها اکنون در `REVIEW_SCOPE` و manifest بازتولیدشده قرار دارند. تست رگرسیون محدوده الزام می‌کند که مسیرهای امنیتیِ پیاده‌سازی و تست در محدوده باقی بمانند. manifest جاری مرجع دقیق است؛ پس از هر تغییر در فایل‌های محدوده دوباره تولید شود. این اصلاح محدوده، اصالت شواهد را اثبات نمی‌کند، سیاست HAO را تصویب نمی‌کند، ریشهٔ اعتماد provision نمی‌کند و بازبینی مستقل انجام نمی‌دهد. G5 همچنان BLOCKED است.


## به‌روزرسانی شواهد اصلاح G4/G5 (۲۰۲۶-۱۰-۱۵ — الزاماً در بازبینی مستقل لحاظ شود)

اکنون `REVIEW_SCOPE` شش سند را نیز به subject امضاشده متصل می‌کند: `ODAD-G4-SBOM-2026-10-15.cdx.json`، `ODAD-G4-PRODUCT-RUNTIME-SBOM-2026-10-15.cdx.json`، `ODAD-G4-SUPPLY-CHAIN-SCAN-2026-10-15.json`، `ODAD-G4-HOST-SECURITY-ASSESSMENT-2026-10-15.json` و گزارش‌های نقطهٔ کنترل انگلیسی/فارسی `ODAD-G4-G5-REMEDIATION-CHECKPOINT-2026-10-15`. یک تست رگرسیون الزام می‌کند هر شش فایل در subject امضاشده بمانند. درست پیش از بازبینی `python3 tools/odad_review_attestation.py --manifest` را اجرا و هش/اندازهٔ تمام فایل‌ها را تأیید کنید؛ subject قدیمی ۸۳ فایلی را امضا نکنید.

راستی‌آزمایی تازه: ۳۱ تست attestation موفق؛ مجموعهٔ کامل ۱٬۹۰۵ تست موفق؛ `git diff --check` موفق. SBOM محیط میزبان با قالب CycloneDX 1.6 شامل ۷۹ توزیع قابل مشاهده برای مفسر پایتون سیستم است. SBOM جداگانهٔ زمان اجرای محصول تنها وابستگی اعلام‌شده (PyYAML 6.0.1 مشاهده‌شده) را ثبت و تصریح می‌کند که نسخه pin نشده و منشأ artifact تأیید نشده است. OSV هر ۷۹ مورد را بدون خطای API بررسی کرد و ۱۱۶ رکورد هشدار برای ۱۷ بسته برگرداند؛ این‌ها رکورد هشدار نیازمند تعیین تکلیف‌اند، نه ۱۱۶ آسیب‌پذیری منحصربه‌فرد و تأییدشده در AICP. برای PyYAML 6.0.1 هیچ رکورد منطبقی یافت نشد؛ برای وابستگی آزمون pytest 7.4.4 دو رکورد وجود داشت. این اسکن، ممیزی کامل وابستگی‌های قفل‌شدهٔ محصول یا منشأ ساخت نیست.

مانع میزبان تأیید شده است: `systemd-analyze security aicommander-agent.service` مقدار `9.6 UNSAFE` گزارش می‌کند؛ سرویس با root و capabilityهای گسترده اجرا می‌شود و سقف متناهی CPU/حافظه ندارد. Ubuntu Pro متصل نیست؛ `pro security-status --format json` صفر به‌روزرسانی امنیتی استاندارد و ۴۷ به‌روزرسانی ESM Apps در وضعیت `pending_attach` گزارش می‌کند، بنابراین این به‌روزرسانی‌های ESM فعلاً برای نصب فعال نیستند. نسخهٔ دقیق بسته‌های Ubuntu برای هر ۱۷ توزیع Python علامت‌گذاری‌شده توسط OSV نگاشت شد؛ نتایج OSV بر اساس نسخهٔ upstream باید پیش از تعیین قابلیت سوءاستفاده با backportهای Ubuntu CVE/USN تطبیق داده شوند. چون این سرویس مسیر فعال مدیریت از راه دور است و مسیر کنترل جایگزین/rollback مستقلاً تأیید نشده، هیچ تغییر سرویس، restart یا ارتقای بسته‌ای انجام نشد. G4 همچنان ناقص/مسدود است. مخزن اعتماد محافظت‌شدهٔ `/etc/aicp/odad-trusted-reviewers.json` همچنان وجود ندارد؛ G5 مسدود است. بازبین باید سخت‌سازی میزبان و تعیین تکلیف OSV را مستقلاً بررسی کند و subject دقیق تازه را با کلید Ed25519 که از مسیر خارج از باند ثبت شده امضا کند. بازبینی شبیه‌سازی‌شده یا امضای خودی پذیرفته نیست.