Recompose the lower /courses journey around project-based learning

Problem

The lower half of /courses reads as if its chapters are out of order even though the underlying information sequence is sound. In the supplied desktop screenshot, the four-step process, the illustrated project-learning story, and the FAQ run together: the project story is a narrow island in a large unstructured field, its illustration is not reliably prominent, and the FAQ begins without a strong enough chapter transition. This makes the final three chapters feel accidental and gives a secondary explanatory block too much competition with the course catalogue.

The intended information architecture remains:

1. hero;
2. optional Wrapped entry point;
3. course facts;
4. course catalogue;
5. How our zoomcamp works;
6. Learn by building;
7. Frequent questions.

The redesign must make that sequence visually unmistakable rather than changing the product story or moving sections around.

Normative references

• _docs/design/design-system.md — shared 76rem shell, band and typography hierarchy, tokens, responsive breakpoints, focus, contrast, reduced-motion and structural rules.
• _docs/design/adversarial-redesign-process.md — independent rendered-evidence design gate and REVISE/ACCEPT verdicts.
• _docs/specs/04-courses-and-cohorts.md — database-owned course discovery and preserved learner behavior.
• _docs/architecture/database-only-content.md — public content remains database-owned; no checked-in fallback content.
• Current surface: courses/templates/courses/course_list.html and its course-list tests, especially courses/tests/test_course_list_projects_section.py and courses/tests/test_content_page_shell.py.

Scope

• Redesign only the public /courses composition, with the lower three chapters as the primary problem area.
• Preserve the existing semantic section order listed above and make every chapter visually distinct through a repeatable section rhythm: aligned shell/gutters, deliberate vertical padding, legible heading hierarchy, and clear boundaries.
• Keep the catalogue the dominant task on the page. The process, project-learning story, and FAQ are explanatory chapters after discovery, not competing hero/catalogue surfaces.
• Keep the four-step process as one coherent, ordered sequence. On wide screens all four stages align as a stable row; narrower layouts reflow in reading order without drifting headings, isolated columns, or horizontal scrolling.
• Turn Learn by building into a complete chapter rather than a narrow orphan in blank space. Its illustration must visibly render, retain meaningful scale, and balance the copy/gallery action on desktop; its narrow-screen stack must feel intentional.
• Give the FAQ a distinct chapter start and predictable responsive grid while preserving its existing questions and community-Slack destination.
• Reuse the shared design system's tokens, typography, shell and interaction primitives. Page-local CSS is acceptable only for the page-specific composition.
• Update focused structural/rendering tests whose current assertions encode the old composition.
• Capture and inspect full-page rendered evidence below .tmp/adversarial-design-review/issue-417/ at 1440×900 or 1440×1000, 768×900, 390×844 and 320×800; include light mode at every size and dark mode at 1440px and 390px.

Non-goals

• No change to course/cohort models, catalogue selection or ordering, registration state, registration counts, project-gallery data, or database content.
• No new hardcoded public-content projection or file-backed fallback.
• No rewrite of the hero, course cards, catalogue information architecture, global masthead/footer, course-family pages, project gallery, or FAQ copy.
• No new navigation destination, filtering behavior, animation, illustration asset, or JavaScript interaction.
• No broad design-system refactor unless a shared defect is independently demonstrated and separately scoped.

Dependencies and boundaries

• No blocking issue or new package is required.
• Preserve all current URLs, counts and gates: course cards continue to target their course-family routes; the hero keeps the current registration URL when one exists and the #courses fallback otherwise; the hero and FAQ Slack actions keep their current destinations; the project-gallery chapter renders only when all_projects_url resolves; optional Wrapped continues to render before the facts when enabled; public registration/family counts remain computed from their current sources.
• Preserve database-backed normal, content-rich, and empty catalogue behavior. Hidden courses remain absent.
• Work must preserve concurrent changes in the repository. No production data, credentials, or personal data may enter screenshots or logs.

Acceptance criteria

• The rendered and DOM reading order is hero → optional Wrapped → facts → catalogue → four-step process → Learn by building → FAQ. The redesign does not reorder those chapters.
• The course catalogue remains the page's dominant task through heading scale, placement, density and whitespace; no lower explanatory chapter reads as a second hero or competes with the catalogue CTA/cards.
• The facts, catalogue, process, project and FAQ content align to the shared --shell (76rem maximum) with at least the standard 1rem narrow gutter. Repeated section spacing/boundaries make each chapter's start and end unmistakable.
• At 1440px, the four process stages form one aligned four-column sequence. Dividers, indices, headings and body-copy starts are visually stable despite different title/copy lengths.
• At 768px, 390px and 320px, all four stages retain the order 01→02→03→04, reflow deliberately, and do not create clipped text, collisions, stranded fragments, or document-level horizontal overflow.
• Representative catalogues with 0, 1, 3, 4, 6 and more than 6 family cards remain visually coherent: incomplete final grid rows do not stretch or masquerade as featured content, card density remains scannable, and the lower chapters retain their intended prominence. Both 3-tile and 4-tile fact strips compose cleanly.
• Learn by building reads as a full-width chapter within the shared shell, with deliberate top/bottom spacing and a clear boundary from both the steps and FAQ. It is not a narrow content island surrounded by unexplained blank space.
• The project illustration visibly renders in both light and dark modes, is not clipped/collapsed/hidden, and has enough scale and contrast to function as the visual anchor. Desktop composition balances artwork with heading/copy/action; mobile composition stacks in a deliberate reading order.
• The project-gallery action remains a clear text link to the existing all_projects_url, has a visible keyboard focus state, and provides a minimum 44×44 CSS-pixel interactive target without overlapping other content.
• When all_projects_url is unavailable, the entire project chapter is absent, no empty wrapper or abnormal gap remains, and the process transitions cleanly to the FAQ.
• The FAQ has an unmistakable chapter start, keeps the existing questions/answers and Slack destination, renders as a balanced two-column grid where space permits, and becomes a single readable column at narrow widths.
• Light and dark themes use approved tokens. Body and muted text meet 4.5:1 contrast on their actual grounds; focus indication is at least the shared visible 3px treatment; no information depends on color alone.
• Keyboard reading/focus order follows DOM order and every actionable destination is operable. Whole-card course targets preserve visible focus plus Enter and Space activation; project and other CTAs have visible focus and at least 44×44 CSS-pixel targets. Reduced-motion mode removes nonessential movement without hiding state or content.
• The page retains one H1, correctly associated H2 section headings, valid labelled sections, the shared content-page shell, canonical/metadata behavior, and all current database-backed course content/routes.
• Empty catalogue and optional-Wrapped states preserve the same chapter hierarchy without broken spacing or absent required headings.
• Focused Django tests cover section order, the gallery-present and gallery-absent paths, preserved destinations, and empty/optional composition. The applicable repository-selected Django and Playwright checks pass.
• An implementer captures and inspects full-page /courses renders at 1440×900 or 1440×1000, 768×900, 390×844 and 320×800 in light mode, plus 1440px and 390px in dark mode, under .tmp/adversarial-design-review/issue-417/. Evidence covers gallery present/absent, both 3/4 fact tiles and representative 0/1/3/4/6/>6-card catalogue densities; a computed scrollWidth <= clientWidth check passes at every viewport.
• The illustration include selects the established light/dark companion assets correctly, and any shared primitive changed for this page is regression-checked in its other consumers.
• An independent adversarial design reviewer evaluates the rendered artifacts against every criterion and returns ACCEPT, explicitly confirming that no blocking or material hierarchy, alignment, spacing, density, typography, palette, component, responsive, accessibility, destination or content-fidelity issue remains. Any REVISE verdict returns to the same implementer for another full affected-state render/review round.

Browser scenarios

Content-rich desktop

1. Render /courses full-page at 1440×900 or 1440×1000 with several real-shaped synthetic course families and a resolvable project gallery.
2. Verify the catalogue is encountered as the primary task before the explanatory chapters.
3. Verify the four stages align, the illustration is visible, the project chapter occupies a deliberate shell-wide composition, and the FAQ starts as a separate chapter.
4. Follow a course-family card, the project-gallery link, and the FAQ Slack link; verify each existing destination is unchanged.

Tablet and narrow reflow

1. Render the same content full-page at 768×900, 390×844 and 320×800.
2. Verify visual and keyboard order, the 01→04 process sequence, project artwork/copy/action stacking, FAQ single-column behavior where needed, standard gutters, and scrollWidth <= clientWidth.
3. Tab through all actionable elements and verify visible non-overlapping focus indicators and target sizes.

Theme and motion preferences

1. Repeat representative 1440px and 390px renders in dark mode.
2. Verify artwork visibility and text/control contrast on each actual section ground.
3. Enable reduced motion and verify the page remains understandable and interactive with nonessential transitions suppressed.

Optional and empty states

1. Render with all_projects_url unavailable; verify no project wrapper/gap remains and steps transition cleanly into the FAQ.
2. Render with no visible course families; verify the catalogue empty state and all required explanatory chapters remain coherent.
3. Render with Wrapped enabled and disabled; verify it stays between hero and facts without disturbing the rest of the hierarchy.

Evidence and review contract

The independent reviewer must inspect rendered output, not source-only claims. Each review round ends with exactly one verdict:

• REVISE: a finite prioritized list naming the route, viewport/state, artifact, impact and observable correction for every material failure.
• ACCEPT: confirmation that the complete contract was checked and no material issue remains.

Implementation is not complete on “looks better,” partial approval, or approval with unresolved material findings.

Start with courses/templates/courses/course_list.html, the design-system and adversarial-review documents, and the focused tests in courses/tests/test_course_list_projects_section.py and courses/tests/test_content_page_shell.py. Run the repository-selected Django and Playwright checks, then inspect the required rendered states and viewports. Done means the preserved chapter order, responsive composition, accessibility behavior, destinations, and database-backed states pass with an independent ACCEPT verdict.