feat(landing): add image generation showcase

[open-design-crew]

Why

Open Design now supports image generation through an active membership, but the public site did not have a dedicated solution page that explains the capability or demonstrates the range of results. This adds a production landing page aligned with the existing solution-page information architecture so visitors can understand the supported models, inspect complete prompts, and download the desktop client.

What users will see

• A new /solutions/image-generation/ page, including /zh/solutions/image-generation/
• Hero and membership messaging for Seedream 5.0 Pro, GPT Image 2, and Nano Banana 2
• 19 generated-image examples with complete prompts in a centered modal
• Workflow, membership, FAQ, and final CTA sections
• Desktop download and GitHub actions aligned with existing solution pages

Surface area

• UI — landing-page solution route, responsive layout, image gallery, prompt modal, and CTA hierarchy
• Daemon / API
• Installer / packaging
• Build / CI
• Docs only

Screenshots

Validated locally at http://127.0.0.1:17674/zh/solutions/image-generation/. The per-PR landing-page preview will be generated by CI for visual review.

Bug fix verification

Not a bug fix.

Validation

• pnpm guard
• pnpm --filter @open-design/landing-page test — 137 passed
• pnpm --filter @open-design/landing-page build — 6631 pages built
• Verified English and Chinese static outputs contain all 19 image assets

[github-actions]

🚀 Landing page preview

This PR is deployed to a Cloudflare Pages preview — not staging or production:

• Stable alias: https://pr-6904.open-design-landing-staging.pages.dev
• This build: https://e85bbe22.open-design-landing-staging.pages.dev
  Updated for commit a2b0580.

[mrcfps]

Thanks @app/open-design-crew — this is a lovely showcase. The 19-image gallery, prompt modal, membership/model story, and locale wrapper all land cleanly, and the hero/footer download CTAs match the existing solution-page contract.

A few non-blocking maintainability notes below. The page itself works; these are about keeping the copy, mosaic, and discoverability from drifting the next time this route is edited.

_{🔁 Powered by Looper · runner=reviewer · agent=grok-build · An autonomous AI dev team for your GitHub repos.}

[mrcfps]

Visible copy is split across two sources, and they have already drifted.

pageCopy hardcodes the section titles and bodies that the template actually renders (galleryTitle, galleryBody, workflowTitle, accessTitle, accessBody, faqTitle, finalTitle, finalBody, dialogTitle, close). IMAGE_GENERATION_COPY already defines the same slots (galleryHeading, galleryLead, howHeading, accessHeading, accessBody, faqTitle, finalHeading, finalBody, promptTitle, close) plus a large unused set (copyPrompt, copied, viewPrompt, generatedLive, liveLabel, modelsEyebrow, modelsHeading, …).

Those two sources already disagree. For example:

• pageCopy.galleryBody says visitors should “inspect its complete prompt”
• IMAGE_GENERATION_COPY.en.galleryLead says “Open any prompt, copy it, and make it your own”
• pageCopy.accessBody / copy.accessBody and pageCopy.finalBody / copy.finalBody also differ

The template only reads copy.title, copy.description, copy.eyebrow, copy.headingA / headingB, copy.lead, copy.secondaryCta, copy.steps, copy.accessItems, and copy.faq. Everything else in the data file is dead.

This matters because the next copy edit will almost certainly go into IMAGE_GENERATION_COPY and silently miss the page. The leftover “copy it” / copyPrompt strings also describe a copy button that was never wired.

Suggested change: delete pageCopy. Keep one locale map in IMAGE_GENERATION_COPY and render from it. Reconcile the drifted strings first, then drop the unused keys so the data file only contains fields the template reads.

_{🔁 Powered by Looper · runner=reviewer · agent=grok-build · An autonomous AI dev team for your GitHub repos.}

[mrcfps]

Desktop mosaic is load-bearing on example order, not on the layout field the data already has.

Each example already carries layout: 'wide' | 'portrait' | 'square', and index.astro applies ig-gallery-card-${example.layout}. On desktop those classes do not control placement. This block assigns grid-column / grid-row with hardcoded :nth-child(1), :nth-child(14), :nth-child(2,3,6,7,8,15,16), and :nth-child(4,5,12,13). The layout-class rules only appear later, inside the max-width: 720px breakpoint.

That means IMAGE_GENERATION_EXAMPLES order is part of the visual contract, but nothing enforces it. Adding a 20th image, swapping two portraits, or reordering the celestial-world set will silently break the 12-column mosaic. The layout field looks like the source of truth and is not.

Suggested change: drive desktop spans from the layout class (or a data-span derived from example.layout) the same way mobile already does. If this exact 19-card mosaic is intentional, keep the nth-child rules but add a short comment that the example order is load-bearing, and a test that the array length / layout sequence still matches these selectors.

_{🔁 Powered by Looper · runner=reviewer · agent=grok-build · An autonomous AI dev team for your GitHub repos.}

[mrcfps]

This new route is not reachable from the existing Image solution surfaces.

The page ships at /solutions/image-generation/ (and locale prefixes), but this PR does not register it in:

• apps/landing-page/app/pages/solutions/index.astro USE_CASES — still only { key: 'image', slug: 'image' }
• apps/landing-page/app/_components/site-footer.astro USE_CASE_HREFS — still /solutions/image/
• the header Solution → Image item, which continues to open /solutions/image/
• apps/landing-page/app/pages/solutions/image/index.astro, whose browse/gallery link still points at /plugins/templates/

So a visitor who follows the current Image use-case never sees this showcase. The two URLs will also compete for the same intent.

I would not expand the fixed 6-item useCaseItems nav tuple just for this. A lighter close is: point /solutions/image/’s browse/gallery CTA (exampleHref) at /solutions/image-generation/, and/or add a hub card on /solutions/ that links here. That keeps the existing Image nav entry and makes the showcase discoverable.

_{🔁 Powered by Looper · runner=reviewer · agent=grok-build · An autonomous AI dev team for your GitHub repos.}

[mrcfps]

@app/open-design-crew thank you for the follow-up polish on this showcase — the simplified hero CTAs and refined prompt-dialog close control look clean and match the existing solution-page contract.

I re-checked this head (a2b0580) end to end: locale wrapper, 19-example gallery + prompt modal wiring, membership/model FAQ copy, download/GitHub CTA hierarchy, asset/id alignment, and the solution-page count test bump. No new correctness, safety, or test issues on the changed ranges.

The three earlier non-blocking threads (single copy source, mosaic order vs layout, and discoverability from /solutions/image/) are still open as follow-ups and do not block merge. Nice work shipping this page 🙌

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

[AmyShang-alt]

@app/open-design-crew

Thanks for the contribution. I completed QA validation for this PR.

QA Acceptance Record

Scope:

• Image-generation solution routes, localized rendering, 19-image gallery, prompt dialog, responsive mobile layouts, static assets, SEO metadata, and download/GitHub CTA behavior.

Scope-to-evidence:

• Automated coverage -> pnpm --filter @open-design/landing-page test passed 137/137; pnpm guard passed.
• Build and routing -> landing-page build completed with 6,631 static pages and 11 locale variants for this route.
• Static assets -> all 19 WebP assets returned HTTP 200 with image/webp and loaded successfully during full-page scrolling.
• Runtime layout -> verified at 1280x720, 390x844, and 320x568 with no page-level horizontal overflow.
• Prompt dialog -> verified hero and gallery data mapping, close button, backdrop close, focus restoration, and narrow-screen bounds.

Verified:

• EN/ZH content, 19 gallery cards, workflow, FAQ, CTA hierarchy, canonical/hreflang metadata, responsive single-column mobile layout, and installer-link rewriting.

Not verified:

• No blocking items. Escape behavior in the in-app browser remains a non-blocking compatibility note; close button and backdrop paths work.

Risks / notes:

• Existing review follow-ups on copy-source consolidation, order-dependent desktop mosaic rules, and route discoverability remain non-blocking maintainability items.

Conclusion:

• Accepted.