Website Audit Engine

1) مسئله‌ای که این درس حل می‌کند

یک «امتیاز سلامت سایت» به‌تنهایی audit نیست. اگر URL هدف، scope، نسخهٔ ابزار، raw finding و شرایط اجرا ثبت نشوند، دو عدد قابل مقایسه نیستند و remediation هم قابل اثبات نیست.

2) مرز درس

خروجی این درس Website Audit Evidence Engine Contract v1 است. این درس مالک CRM handoff یا niche research نیست و سایت واقعی مشتری را crawl یا mutate نمی‌کند.

3) Fact: Lighthouse چیست؟

Lighthouse یک ابزار automated برای audit صفحه است و دسته‌هایی مثل Performance، Accessibility، Best Practices و SEO دارد. failed audit یک indicator برای بهبود است، نه رأی نهایی دربارهٔ کل کیفیت سایت.

4) Fact: برای Performance فقط به یک score تکیه نکن

Chrome برای debugging عمیق performance، Performance panel را نسبت به Lighthouse توصیه می‌کند. بنابراین score را evidence summary می‌گیریم، نه oracle.

5) Inference: reproducibility به context وابسته است

Chrome توضیح می‌دهد که setup، device، extension و throttling می‌تواند نتیجه را تحت تأثیر قرار دهد. پس هر run باید scope و execution context و tool/version مستقل داشته باشد.

6) Design: finding-level evidence

در MAKNOW هر finding یک هویت، raw evidence، severity، confidence، provenance خودکار/دستی، owner، remediation و rerun دارد. aggregate score فقط summary است.

7) Scope را قبل از score قفل کن

target_url، canonical_page_id و crawl_scope تعیین می‌کنند finding به چه چیزی مربوط است. اگر fix فقط یک template را پوشش دهد، کل سایت VERIFIED نمی‌شود.

8) Tool provenance را ذخیره کن

tool_name و tool_version همراه check_id ثبت می‌شوند. اگر نسخهٔ جدید check را حذف کند، absence معادل remediation نیست.

9) Raw result را از severity جدا نگه دار

raw result تاریخی باید ثابت بماند. severity/confidence می‌تواند بعداً با policy یا manual review عوض شود، بدون rewrite کردن evidence اصلی.

10) Automated و Manual یکی نیستند

یک automated accessibility finding یا SEO signal، review انسانی را جعل نمی‌کند. automated_or_manual و reviewer evidence مرز مسئولیت را حفظ می‌کنند.

11) Composite score نمی‌تواند critical finding را پنهان کند

اگر score از 72 به 95 برسد ولی یک finding بحرانی unresolved باشد، state هنوز success نیست. non-compensation rule روی finding-level evidence اعمال می‌شود.

12) Evidence Contract

این قرارداد 22 بُعد دارد که 18 بُعد آن critical است. جدول زیر یک baseline کوتاه است؛ JSON/CSV مجموعهٔ کامل فیلدها را نگه می‌دارد.

13) Verification یعنی rerun همان evidence-producing check

بعد از remediation باید rerun_ref جدید داشته باشیم و context لازم برای مقایسه روشن باشد. افزایش score به‌تنهایی verification نیست.

14) False positive و dispute

manual dispute باید reviewer identity و evidence داشته باشد. بدون آن نمی‌توان finding را FALSE_POSITIVE کرد؛ state باید DISPUTED بماند.

15) Lab و Transfer

Lab هشت fixture و 48 assertion دارد. در transfer، diagnostic عوض می‌شود، fix فقط یک template را پوشش می‌دهد و reviewer یک finding high-severity را dispute می‌کند. نتیجه را از evidence جدید recompute کن، نه از score قدیمی.