Make a page work on narrow screens

# Apply the “Make a page work on narrow screens” guide in your agent

## Objective
A responsive page rearranges its content when space changes. Start with a usable single column, then add columns where the content benefits. Keep the same task achievable at narrow widths; shrinking a desktop screenshot is not a responsive layout.

## Prerequisites
- Inspect the repository, documentation, and existing conventions.
- Confirm the need matches the guide scope: Adapt a page to phones and browser zoom while keeping its content and actions available.
- Preserve the correct decisions already in place.

## Guide steps
- 1. 1. Start from the task, then choose the layout — For a course page, write the reading order first: course title, explanation, price, enrollment action, then supporting details. Sketch that order as one column before arranging the price alongside the explanation on a wider screen. This is an original planning exercise, not a prescribed layout for every product.
- 2. 2. Let real content reveal the breakpoint — Use a viewport setting that follows the device width and allows zoom. Prefer flexible dimensions over a fixed desktop canvas. Choose a breakpoint when the actual content becomes cramped, rather than because a named phone model has a particular width.
- 3. 3. Check the whole enrollment journey — Open a course with a long title, expand its prerequisites, follow the enrollment action, then return. Repeat with the price panel stacked. Confirm that the action keeps its label and destination, prerequisites remain reachable, and focus follows a meaningful sequence. Keep expected and observed results separately.
- 4. 4. Distinguish reflow from magnification — WCAG 2.2 Reflow, level AA, concerns presentation at 320 CSS pixels wide for vertically scrolling content without lost information or functionality or a need to scroll in both directions. A 1280 CSS pixel viewport at 400% browser zoom reaches that width. Pinch magnification alone does not establish this.
- 5. 5. Keep layout evidence separate from accessibility claims — Test the course page at the measured narrow viewport and through an intermediate width, then complete enrollment navigation with the keyboard. Recheck any fixed header or bottom action that can cover content. Capture the build, viewport, zoom, browser and failing step when something becomes unreachable.

## Acceptance criteria — Verify the result
- The long EN and FR versions keep the course explanation, price and action available.
- The layout works around each breakpoint, not only at two screenshot sizes.
- The measured 320 CSS pixel check records any justified exception.
- Keyboard navigation reaches the same intended enrollment destination.
- Observed results name the tested build, browser and viewport.
- Fixed headers and bottom actions leave the focused control visible during the journey.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Requires · The real project context: repository, documentation, and existing constraints

# Anchor the guide in the project

## Objective
Turn the applied steps into durable repository conventions.

## Checks
- Link each decision made to the guide step that justifies it.
- Add the checklist to the relevant reviews.
- Record out-of-scope cases for the neighboring guides.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:7c743cde722a275f362074973375583bd6156a4edc6157878342fadb572861b2

# Diagnose a failed application of the “Make a page work on narrow screens” guide

## Observed symptom
[DESCRIBE THE SYMPTOM HERE]

## Observable checks
- Replay the steps in order and note the first one that diverges:
- 1. 1. Start from the task, then choose the layout — For a course page, write the reading order first: course title, explanation, price, enrollment action, then supporting details. Sketch that order as one column before arranging the price alongside the explanation on a wider screen. This is an original planning exercise, not a prescribed layout for every product.
- 2. 2. Let real content reveal the breakpoint — Use a viewport setting that follows the device width and allows zoom. Prefer flexible dimensions over a fixed desktop canvas. Choose a breakpoint when the actual content becomes cramped, rather than because a named phone model has a particular width.
- 3. 3. Check the whole enrollment journey — Open a course with a long title, expand its prerequisites, follow the enrollment action, then return. Repeat with the price panel stacked. Confirm that the action keeps its label and destination, prerequisites remain reachable, and focus follows a meaningful sequence. Keep expected and observed results separately.
- 4. 4. Distinguish reflow from magnification — WCAG 2.2 Reflow, level AA, concerns presentation at 320 CSS pixels wide for vertically scrolling content without lost information or functionality or a need to scroll in both directions. A 1280 CSS pixel viewport at 400% browser zoom reaches that width. Pinch magnification alone does not establish this.
- 5. 5. Keep layout evidence separate from accessibility claims — Test the course page at the measured narrow viewport and through an intermediate width, then complete enrollment navigation with the keyboard. Recheck any fixed header or bottom action that can cover content. Capture the build, viewport, zoom, browser and failing step when something becomes unreachable.

## Possible causes
- A step was skipped or executed out of order.
- The actual need falls outside the guide scope.
- A checklist criterion was never verified.

## Bounded fixes
- Redo only the diverging step and what depends on it.
- Document the gap if the guide scope does not cover the need.

## Final verification — Verify the result
- The long EN and FR versions keep the course explanation, price and action available.
- The layout works around each breakpoint, not only at two screenshot sizes.
- The measured 320 CSS pixel check records any justified exception.
- Keyboard navigation reaches the same intended enrollment destination.
- Observed results name the tested build, browser and viewport.
- Fixed headers and bottom actions leave the focused control visible during the journey.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Requires · The real project context: repository, documentation, and existing constraints

# Prevent the next drift

## Objective
Turn the first diverging step into an explicit project check.

## Checks
- Add a focused check on the step that diverged.
- Verify the checklist on a second real case.
- Document the scope limit you hit.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:6c69f9557b6f91a699414dbd06c5a6dcc5f6ffb9e1397f6937138c45acb1de33