v3 Website — Responsive Pass on All Pages — Design

Date: 2026-05-14 Project: Sub-project A of a two-part effort. (Sub-project B — a design-system audit + design guide — is deferred to its own spec→plan→build cycle later.) Worktree: /Users/maximilianbrandstaetter/Orcha/.claude/worktrees/website-v3-mobile-responsive, branch website-v3-mobile-responsive.

Goal

Make every real v3 website page render correctly on all screen sizes (320px phone → wide desktop), the way www/v3/de/index.html already was. The German homepage is done; this covers the remaining 29 pages.

Scope

In scope — 30 real pages (de homepage already complete → 29 remaining):

Out of scope:

Tiering

Two acceptance tiers, by page importance:

Approach

Extend product.css as the universal responsive layer. All 28 non-homepage pages already load v3.css + product.css; the homepage additionally loads responsive.css. product.css already collapses the shared template classes to one column at @media (max-width: 960px). We extend product.css in place rather than adding a new stylesheet — zero <link> churn, and it is already the shared stylesheet.

responsive.css stays homepage-specific. The one migration: the mobile-nav-drawer @media (max-width: 960px) activation block currently lives in responsive.css (homepage-only); it moves into product.css so the hamburger drawer — whose markup chrome.de.js already renders on every page — actually works site-wide. The drawer base styles are already in product.css (from the homepage project's final-review fix).

Breakpoints: 1024 / 768 / 480, plus 960 for the nav — identical to the homepage, for consistency.

Rejected alternatives: a new responsive-base.css linked on all 30 pages (cleaner separation, but 28 <link> edits for no functional gain); per-page passes with no shared foundation (re-fixes the shared template ~28 times).

Design

1. Shared responsive foundation — www/v3/css/product.css

2. Verification harness — www/v3/dev/screenshot.mjs

Extend the existing harness to accept a list of all 30 page URLs (not just the homepage). For each page × each width (320/375/768/1024/1280) it measures horizontal overflow and writes a screenshot to shots/; it exits non-zero if any page overflows at any width. Screenshot filenames encode page + width (e.g. produkt-kreditoren-de-375.png). This is the tool that makes 30-page verification tractable and is run after every stage.

3. EN homepage — www/v3/en/index.html

en/index.html (1716 lines) has diverged from the now-responsive de/index.html (1527 lines). Reconcile it to de's structure:

4. Section pages — polish tier ({de,en}/{agenten,implementierung,roi,steuerberater,trial}/index.html)

All 5 section pages are exact de/en structural mirrors (identical line counts), so each structural edit applies to both language files. Per page, on top of the foundation: rework the bespoke hero (e.g. roi uses hero-dots), move inline-styled layout into classes or in-body <style> blocks, and verify section-by-section at all widths. agenten is large (1066 lines) and will need the most attention; trial is small (89 lines).

5. Product pages — baseline tier ({de,en}/produkt/*.html)

All 9 product pages are exact de/en structural mirrors (e.g. kreditoren.html is 1528 lines in both). Per module, on top of the foundation: run the harness, fix whatever still overflows or is crushed — these pages carry heavy bespoke styling (kreditoren has ~132 inline style= + 3 in-body <style> blocks; abschluss has only 8). Triage, do not rework what already works. Apply the same structural edits to the de and en file of each module.

6. Sequencing

One spec (this document). writing-plans produces a staged plan; given the size it will likely be split into two sequential plans. Stages:

  1. Foundation — extend product.css; extend the harness to all 30 pages. (Unlocks baseline for all 28 product/section pages at once.)
  2. Product-page triage — 9 modules × de/en.
  3. Section-page polish — 5 sections × de/en.
  4. EN homepage reconcileen/index.html.

Each stage is independently shippable and verified by the harness before the next begins.

Acceptance criteria

Risks / known tricky areas