# WEB010-LAB1 — Responsive layout evidence lab

## Goal

Repair and defend a responsive product-results fixture across wide and narrow constraints and both `ltr` and `rtl`. The goal is not to make the page merely look acceptable. You must make a bounded layout decision, observe browser/DOM behavior, run a deliberate failure mutation, repair it, and record the evidence in **Responsive Layout Evidence Matrix v1**.

## Starting condition

The starter is intentionally imperfect. It contains several plausible but unsafe choices. Do not replace the whole fixture with a framework or a completely different page. Work inside the bounded fixture so that evidence before and after each repair remains comparable.

The starter intentionally does **not** tell you which region must use Grid or Flexbox, which breakpoint value is correct, or which exact CSS declaration is the canonical repair. Those decisions must be justified from the layout constraints you observe.

## Required states

Evaluate at least these four combinations:

1. wide + `ltr`
2. narrow + `ltr`
3. wide + `rtl`
4. narrow + `rtl`

Use the direction control in the page. Resize the browser or its container rather than treating a device name as the reason for a breakpoint.

## Required failure probes

Run all three probes. Predict the result before observing it.

- Enable **Long identifier**. Determine whether intrinsic/min-content sizing creates critical horizontal overflow and identify the boundary where the problem originates.
- Toggle `ltr` and `rtl`. Inspect whether spacing and placement express logical start/end intent or accidental physical left/right assumptions.
- Enable **Visual reorder mutation**. Compare visual sequence with DOM/source sequence. Do not “repair” semantic source order by relying on visual reordering.

## Evidence to record

Copy `Responsive_Layout_Evidence_Matrix_v1_template.json` into your working evidence file and record:

- the region and source-order contract;
- the actual layout problem;
- your chosen model and its bounded rationale;
- the constraint that causes a responsive state change;
- logical-property decisions;
- observed overflow and visual order;
- observed DOM/source order and default focus sequence;
- one deliberate mutation and its observed result;
- the smallest repair you tested and the observed repair result;
- one residual limitation;
- one changed-context transfer result.

Keep **observation** separate from **inference/decision**.

## Acceptance boundary

A strong submission demonstrates all of the following without exposing a hidden answer key:

- no critical horizontal overflow in the required repaired states;
- direction changes do not require a duplicated left/right stylesheet;
- logical DOM/source order remains defensible;
- the chosen Grid/Flex/normal-flow mechanism is justified by the geometry of the region, not habit;
- at least one failure mutation is observed and repaired;
- the transfer fixture is handled independently;
- one residual limitation is stated.

## Local execution

Open `starter/index.html` in a standards-capable browser. No network access, package manager, build system, server, account, or credential is required.

`run_checks.py` performs only public structural/evidence checks: required files/probes, JSON validity, the full public row-field contract, and completion flags. It does not execute browser geometry, determine whether your CSS is semantically correct, or contain the hidden expected solution.


## Public checker command

From this `learner/` directory run `python run_checks.py --structure-only` before editing. After completing `evidence/learner_evidence.json`, run `python run_checks.py`. The checker remains structural/evidence-only; browser observations are still learner evidence.