One-prompt landing page

# Claude Fable 5 vs GPT-5.6 Sol — Landing Page Build Test

This document is the reproducible brief used for the DevShift head-to-head build test. Both agents receive the shared prompt verbatim. A small run-specific addendum assigns a different route and component namespace so the implementations cannot collide.

## Shared prompt

You are building a production-quality experimental landing page inside the existing DevShift Next.js website.

### Subject and job of the page

Create **DevShift Continuum**, an English landing page for founders and technical leaders who have an ambitious AI-product idea but need a team capable of turning the difficult brief into a reliable shipped system. The page has one job: make a serious product leader want to start a conversation with DevShift.

The core message is:

> From impossible brief to working product.

Use concrete, restrained copy about product strategy, AI engineering, orchestration, validation, and shipping. Do not fill the page with generic feature cards, vague AI superlatives, fake testimonials, invented customer logos, or unsupported metrics.

### Signature visual and interaction

The page must feel unusually beautiful, technically ambitious, and alive. Its signature is a persistent dimensional **product organism** that accompanies the visitor through the page:

- It begins in the hero as a precise but unresolved 3D machine made from layered glass, polished navy metal, luminous sky-blue paths, and fine technical markings.
- As the visitor scrolls, it follows the narrative and transforms through four real product stages: **Frame → Model → Build → Ship**.
- Each stage must visibly change the same object rather than swapping unrelated decorations: scattered constraints align into a wireframe, the wireframe gains system layers, the layers coordinate into an operating machine, and the machine resolves into a launch-ready architecture.
- Scroll position is the main input. Pointer movement may add subtle depth and parallax on desktop; touch input may add a restrained response on mobile.
- The motion should feel choreographed and physical—depth, occlusion, perspective, inertia, light, and purposeful state transitions—not like a looping particle wallpaper, a generic glowing orb, or a static poster with fade-in sections.
- Make one brave, memorable visual decision and keep the surrounding interface disciplined enough for it to land.

The user explicitly requested complex 3D scroll animation. For this isolated experiment route only, that requirement overrides the repository's normal prohibition on animation JavaScript and interactive client islands. Keep every exception route-local. Do not change global animation policy or shared production components.

### Narrative structure

Build a complete landing page, not only a hero:

1. **Hero** — DevShift Continuum, the main message, a short explanation, primary contact CTA, and a secondary “See the system move” action.
2. **Frame** — turn ambiguity into a buildable product definition.
3. **Model** — choose models, data boundaries, tools, and orchestration around the workflow rather than hype.
4. **Build** — implement the product as a coherent system with visible checkpoints and engineering evidence.
5. **Ship** — validate, harden, release, observe, and improve a real production system.
6. **Closing CTA** — invite the reader to bring DevShift one difficult product brief.

The persistent 3D organism should be the visual thread that makes these sections feel like one journey. Structural labels and stage indicators should encode actual scroll progress rather than acting as decoration.

### Visual direction

- Start from DevShift's existing navy, ice, white, and sky-blue identity, but interpret it as a premium technical instrument rather than copying the current homepage.
- Typography should be purposeful and editorial. Use the site's existing locally loaded font variables; do not fetch remote fonts.
- Avoid the common AI-landing-page formula of a centered gradient headline, floating glass cards, three feature columns, and decorative statistics.
- Avoid excessive pills, gratuitous gradients, and rounded containers around every piece of text.
- Use empty space, asymmetry, layering, strong typographic rhythm, and technical details that belong to this product-engineering story.
- The desktop composition should feel cinematic at 1440px. The mobile composition must be intentionally redesigned for 390px rather than merely scaled down.

### Engineering constraints

- Read `AGENTS.md` and the relevant Next.js 16 guides under `node_modules/next/dist/docs/` before coding.
- Use the existing Next.js App Router and TypeScript.
- Keep the route fully static/SSG. No backend, request-time APIs, cookies, or dynamic rendering.
- Do not add dependencies. Use the existing stack plus browser-native Canvas, SVG, CSS 3D, or WebGL APIs as appropriate.
- Do not load remote images, fonts, scripts, videos, models, or textures. Generate all visuals locally in code.
- Keep all implementation files inside the assigned route and component namespace. Do not edit shared navigation, layouts, global styles, content dictionaries, package files, lockfiles, existing articles, or other routes.
- A route-local Client Component is allowed for the visual experience. Keep static copy and metadata server-rendered.
- The page must work when JavaScript or advanced graphics are unavailable: preserve readable copy, CTA access, and a deliberate static visual fallback.
- Respect `prefers-reduced-motion`. The reduced-motion experience must remain composed and understandable, not blank.
- Pause expensive rendering when the page is hidden or the visual is offscreen. Cap device pixel ratio and avoid unbounded object allocation inside animation frames.
- Keep the hero heading immediately visible and stable. Do not animate its opacity and do not introduce avoidable layout shift.
- Maintain visible keyboard focus, semantic landmarks, one `h1`, usable contrast, and descriptive labels for interactive controls.
- Add route metadata with `robots: { index: false, follow: false }`; this is a temporary comparison surface.
- The contact CTA should link to `/en/#contact`. Include a small, accessible link back to the comparison article at `/en/insights/claude-fable-5-vs-gpt-5-6-sol`.
- Do not commit or push changes.

### Quality and validation

Treat this as a real design-engineering assignment. Plan the distinctive direction, build it, inspect the rendered page, and refine it at least once based on what you see.

Before finishing:

- run the most relevant lint/build checks available;
- confirm the route renders without console errors;
- verify the page at desktop and mobile widths if browser tooling is available;
- confirm reduced motion does not break content;
- report the files changed, checks run, and any known limitation.

## Claude Fable 5 run addendum

Implement only this output:

- Route: `/en/labs/fable-5-scroll-lab`
- Route file: `app/(en)/en/labs/fable-5-scroll-lab/page.tsx`
- Component namespace: `components/labs/fable-5-scroll-lab/`
- Route-local styles may live alongside that component namespace.

Use Claude Fable 5 at maximum effort. You are encouraged to use Claude Code's Ultracode/dynamic workflow when it materially improves planning, parallel implementation, visual review, or validation. You have permission to use that workflow. Do **not** invoke the Codex plugin or delegate any part of this implementation to Codex; this result must remain a Fable/Claude Code output.

## GPT-5.6 Sol run addendum

Implement only this output:

- Route: `/en/labs/gpt-5-6-sol-scroll-lab`
- Route file: `app/(en)/en/labs/gpt-5-6-sol-scroll-lab/page.tsx`
- Component namespace: `components/labs/gpt-5-6-sol-scroll-lab/`
- Route-local styles may live alongside that component namespace.

Use GPT-5.6 Sol at Ultra effort. Do **not** invoke Claude, a Claude Code bridge, a Claude-oriented plugin, or any other model. This result must remain a GPT-5.6 Sol/Codex output.