KN-86 Deckline Website — Design Document

Problem

The KN-86 Deckline needs a canonical product home at kn86-deckline.com. The marketing plan (weeks 5–16) assumes gwpdispatch.com as the editorial home, but there’s no product site — the place you send someone when they ask “what is this?” The domain is purchased. Nothing lives there yet.

Decision

Build a phased prelaunch site using the “Terminal Awakening” concept: a full-viewport Remotion boot sequence that shrinks into a persistent header, with content zones expanding as the 18-week build progresses.

Concept: Terminal Awakening

The site opens with the KN-86 booting up. BIOS POST, memory check, hardware check, CIPHER greeting, logo resolve. When the boot completes, the terminal shrinks to a thin sticky header bar with rotating CIPHER fragments. Below it, GWP’s archaeologist voice narrates the project in clean editorial sections on a dark ground with amber accents. Each major content section is introduced by a shorter Remotion animated transition (cartridge insert, mission board scroll, deck state transfer).

The two typographic modes — amber monospace for terminal, warm sans-serif for narration — are the site’s visual identity. They never mix.

Phased Rollout

The site grows as the build produces evidence. Four phases mapped to the marketing calendar:

Phase 1 — Week 5 (“The Discovery”): Boot sequence + 3 paragraphs of GWP intro + email capture styled as > REGISTER OPERATOR HANDLE_. Intentionally sparse. The mystery is the marketing. No product details, no emulator download, no screenshots.

Phase 2 — Weeks 8–12 (“Proof of Concept through Cartridge Design”): Add the Paradigm section — Lisp grammar, capability model, bare deck. Cartridge-insert Remotion interstitial. The site now explains what the device is, not just that it exists.

Phase 3 — Week 14 (“ICE Breaker Gameplay Preview”): Add the Emulator section with screenshots, build instructions, and platform support. The primary CTA flips from email capture to > DOWNLOAD EMULATOR_. Mission-board and deck-state-transfer Remotion transitions ship. The itch.io beta launches simultaneously.

Phase 4 — Week 16 (“Final Reveal”): Product photography, pricing, pre-order or waitlist mechanics. Future design work.

Tech Stack

Next.js (App Router) + Remotion (@remotion/player for client-side playback) + Tailwind CSS. Email capture via Next.js API route with a simple backend (Supabase, Buttondown, or ConvertKit — swappable).

Visual Language

AMBER #E6A020 on black #000000 (the device’s canonical default phosphor per ADR-0036; WHITE #F0F0F0 and GREEN #33F033 selectable on-device but the website ships in the default AMBER for visual identity). CRT scanline overlay at very low opacity. Phosphor bloom via text-shadow. Monospace for terminal, clean sans-serif (Inter or Space Grotesk) for editorial. No grain textures. Block cursor at 530ms blink. The lo-fi feeling comes from the monospace grid and the single-phosphor constraint, not from fake effects.

Boot Sequence (9 seconds)

0.0s black → 0.5s cursor blinks → 1.0s BIOS POST typing → 2.5s memory check → 3.5s hardware check → 4.5s cartridge slot empty → 5.5s screen clear → 6.0s CIPHER greeting → 7.5s logo resolve with glow pulse → 9.0s terminal shrinks to docked header bar.

Skippable via click or scroll. Respects prefers-reduced-motion. No audio without user interaction.

Voice

GWP (archaeologist) throughout. KEC’s voice appears only inside the boot sequence and the CIPHER bar — never in the editorial copy. The site reads like a field report from someone reconstructing a lost device, with the device itself occasionally speaking through terminal UI elements.

What Phase 1 Does NOT Include

No Paradigm section (Lisp grammar, capability model). No Emulator section (screenshots, download). No Remotion zone transitions beyond the boot sequence. No product photography. No pricing. These are Phases 2–4.

Build Prompt

The engineering brief lives at prompts/kn86-deckline-website-build.md. It contains the full technical spec for Phase 1: file structure, component breakdown, Remotion architecture, scroll behavior, accessibility requirements, OG tags, and copy direction.

Success Criteria

Phase 1 is successful if:

1. The boot sequence plays correctly and is skippable
2. The docked terminal bar persists with cycling CIPHER fragments
3. Email capture works end-to-end (form → API route → storage)
4. Lighthouse performance score ≥ 90
5. The site looks correct on mobile (boot sequence scales, form is usable)
6. prefers-reduced-motion is respected
7. OG tags render correctly when shared on Reddit, Bluesky, Mastodon