معماری چندکسبوکاری، تجاری و تجارت الکترونیک · فصل ۴ — IA، Configurator، Lead، Audit و Research · 245
Website Audit Engine
Build a website audit engine contract that fixes audit target and scope, records tool/version and raw evidence, keeps automated findings separate from manual review, classifies severity and confidence, links findings to page/content identities, and verifies remediation by rerunning the same evidence-producing check rather than trusting a score change alone. میتواند «Website Audit Engine» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
Lesson summary
Build a website audit engine contract that fixes audit target and scope, records tool/version and raw evidence, keeps automated findings separate from manual review, classifies severity and confidence, links findings to page/content identities, and verifies remediation by rerunning the same evidence-producing check rather than trusting a score change alone.
میتواند «Website Audit Engine» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
This lesson produces
میتواند «Website Audit Engine» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
Who it is for
Foundation
Use a field map, one worked scenario and explicit state vocabulary before independent construction.
Repair
Identify the failed evidence dimension, use the smallest mutated fixture and rerun only the affected gate.
Experienced
Compress definitions; require trade-off defense, counterexample analysis and changed-context transfer.
Prerequisites
1) The problem this lesson solves
A single “site health” score is not an audit. Without target URL, scope, tool version, raw finding and execution context, two runs are not reproducibly comparable and remediation cannot be proven.
2) Lesson boundary
The owned artifact is Website Audit Evidence Engine Contract v1. This lesson does not own CRM handoff or niche research, and it does not crawl or mutate a live client site.
3) Fact: what Lighthouse is
Lighthouse is an automated page-auditing tool with categories such as Performance, Accessibility, Best Practices and SEO. A failed audit is an improvement indicator, not a complete verdict on website quality.
4) Fact: do not use one score as the performance oracle
Chrome recommends the Performance panel for deeper performance debugging. Treat a Lighthouse performance score as summary evidence, not as the only diagnostic truth.
5) Inference: reproducibility depends on context
Chrome documents that setup, device conditions, extensions and throttling can influence results. Each run therefore needs explicit scope, execution context and tool/version provenance.
6) Design: finding-level evidence
MAKNOW gives each finding an identity, raw evidence, severity, confidence, automated/manual provenance, owner, remediation and rerun. Aggregate scores summarize; they do not replace findings.
7) Lock scope before interpreting scores
target_url, canonical_page_id and crawl_scope define what the finding applies to. A fix deployed to one template cannot verify the entire site.
8) Preserve tool provenance
Store tool_name, tool_version and check_id. If a new tool version removes a check, absence is not equivalent to remediation.
9) Keep raw result separate from severity
Historical raw evidence stays stable. Severity and confidence can change after policy or manual review without rewriting the original observation.
10) Automated and manual evidence are different
An automated accessibility or SEO signal does not fabricate human review. automated_or_manual and reviewer evidence preserve accountability.
11) A composite score cannot hide a critical finding
If the aggregate score rises from 72 to 95 while a critical finding remains unresolved, the audit is not verified. Finding-level blockers are non-compensable.
12) Core Evidence Contract
The artifact has 22 dimensions, 18 critical. The compact table below shows a traceable baseline; JSON/CSV retains the full field set.
| finding_id | page | category | severity | confidence | provenance | owner | verification_state |
|---|---|---|---|---|---|---|---|
| F-001 | PAGE-PRICING | Performance | HIGH | HIGH | AUTOMATED | frontend-team | VERIFIED |
| F-002 | PAGE-PRICING | Accessibility | CRITICAL | MEDIUM | AUTOMATED | design-system | DISPUTED |
| F-003 | PAGE-PRICING | Content | HIGH | HIGH | MANUAL | content-owner | OPEN |
13) Verification means rerunning the evidence-producing check
After remediation, preserve a new rerun_ref and compatible comparison context. A higher score alone is not verification.
14) False positive and dispute states
A manual dispute requires reviewer identity and evidence. Without both, a finding cannot be promoted to FALSE_POSITIVE; it remains DISPUTED.
15) Lab and transfer
The lab has eight fixtures and 48 assertions. In transfer, a diagnostic changes, only one page template is fixed, and a reviewer disputes a high-severity finding. Recompute from changed evidence instead of copying the old score.
Assessment
There is no answer key in this lesson pack; answer it yourself and mark honestly. "Needs review" sends the lesson to your review queue.
COM-004-S1 retrieval
What does COM-004 own, and why is a site-health score insufficient?
COM-004-S2 application
Build Website Audit Evidence Engine Contract v1 for the baseline synthetic audit.
COM-004-S3 diagnosis
Device profile changes between baseline and rerun but is not recorded. Which state must block verification and what evidence repairs it?
COM-004-S4 transfer
The tool changes a diagnostic, only one page template is fixed, and a reviewer disputes a high-severity finding. Recompute confidence, severity and verification.
Assessment rubric
Blocking dimensions: scope identity, tool/version/context, raw evidence, severity/confidence separation, automated/manual provenance, ownership, remediation, rerun evidence, and finding-level verification. Composite score gains cannot compensate for an unresolved critical finding.
References & freshness
Case studies
Lesson visuals
Target and scope flow through tool/version context, raw finding, severity/confidence and remediation before same-check rerun yields verified or non-success states.
Lab files
python run_checks.py را اجرا کنید. هشت fixture مصنوعی context اجرا، finding بحرانی، حذف check، dispute دستی، evidence مفقود، remediation ناقص و transfer را تست میکنند. شبکه یا credential لازم نیست.