# WEB010-LAB1 — آزمایشگاه شواهد Responsive Layout

## هدف

fixture مربوط به فهرست محصول را در constraint عریض و باریک و در هر دو جهت `ltr` و `rtl` اصلاح و از تصمیم خود دفاع کنید. هدف فقط «خوب دیده‌شدن» صفحه نیست. باید یک تصمیم layout محدود و قابل دفاع بگیرید، رفتار واقعی Browser/DOM را مشاهده کنید، یک failure mutation عمدی اجرا کنید، آن را repair کنید و evidence را در **Responsive Layout Evidence Matrix v1** ثبت کنید.

## وضعیت شروع

Starter عمداً کامل نیست و چند انتخاب ظاهراً معقول اما ناامن دارد. کل fixture را با framework یا صفحه‌ای کاملاً متفاوت جایگزین نکنید. در همین مرز محدود کار کنید تا evidence قبل و بعد از repair قابل مقایسه بماند.

Starter عمداً به شما نمی‌گوید کدام ناحیه باید Grid یا Flexbox باشد، مقدار دقیق breakpoint چه باشد یا کدام declaration تنها repair صحیح است. این تصمیم‌ها باید از constraint واقعی layout و مشاهده شما به‌دست بیایند.

## Stateهای اجباری

حداقل این چهار حالت را بررسی کنید:

1. عریض + `ltr`
2. باریک + `ltr`
3. عریض + `rtl`
4. باریک + `rtl`

برای تغییر جهت از کنترل داخل صفحه استفاده کنید. عرض Browser یا container را تغییر دهید و نام یک دستگاه را علت breakpoint در نظر نگیرید.

## Failure Probeهای اجباری

هر سه probe را اجرا کنید و قبل از مشاهده، نتیجه را پیش‌بینی کنید.

- **Long identifier** را فعال کنید. بررسی کنید آیا intrinsic/min-content sizing باعث horizontal overflow بحرانی می‌شود و boundary ایجادکننده مشکل کجاست.
- بین `ltr` و `rtl` جابه‌جا شوید. بررسی کنید spacing و placement واقعاً intent منطقی start/end را بیان می‌کند یا به left/right فیزیکی وابسته است.
- **Visual reorder mutation** را فعال کنید. visual sequence را با DOM/source sequence مقایسه کنید. semantic source order را با visual reordering «تعمیر» نکنید.

## Evidence اجباری

فایل `Responsive_Layout_Evidence_Matrix_v1_template.json` را به فایل evidence کاری خود کپی کنید و این موارد را ثبت کنید:

- region و source-order contract؛
- layout problem واقعی؛
- chosen model و rationale محدود آن؛
- constraint ایجادکننده responsive state؛
- تصمیم مربوط به Logical Properties؛
- overflow و visual order مشاهده‌شده؛
- DOM/source order و default focus sequence مشاهده‌شده؛
- یک mutation عمدی و نتیجه واقعی آن؛
- کوچک‌ترین repair آزمایش‌شده و نتیجه واقعی repair؛
- یک residual limitation؛
- نتیجه یک changed-context transfer مستقل.

**Observation** را از **Inference/Decision** جدا نگه دارید.

## مرز پذیرش

یک submission قوی، بدون لو دادن answer key پنهان، این موارد را اثبات می‌کند:

- در stateهای repairشده، critical horizontal overflow وجود ندارد؛
- تغییر direction نیازمند stylesheet جداگانه left/right نیست؛
- ترتیب منطقی DOM/source قابل دفاع باقی می‌ماند؛
- انتخاب Grid/Flex/normal flow از geometry مسئله می‌آید نه عادت؛
- حداقل یک failure mutation واقعاً مشاهده و repair شده است؛
- transfer fixture به‌صورت مستقل حل شده است؛
- حداقل یک residual limitation ثبت شده است.

## اجرای محلی

فایل `starter/index.html` را در یک Browser استاندارد باز کنید. Network، package manager، build system، server، account یا credential لازم نیست.

`run_checks.py` فقط Public Structural/Evidence Check انجام می‌دهد: Required File/Probe، اعتبار JSON، همه Fieldهای Public Row Contract و Completion Flagها. Browser Geometry را اجرا نمی‌کند، درباره Semantic Correctness خود CSS حکم نمی‌دهد و Hidden Expected Solution را در خود ندارد.


## فرمان Public Checker

از همین پوشه `learner/` پیش از ویرایش `python run_checks.py --structure-only` را اجرا کنید. پس از تکمیل `evidence/learner_evidence.json`، فرمان `python run_checks.py` را اجرا کنید. Checker همچنان فقط Structural/Evidence Check است و مشاهده‌های Browser باید توسط فراگیر ثبت شوند.