Rebuild the docs front page around problem, audience fit, and what's in the box

> 🤖 Generated by the Agentic Engineer

## Evidence

`docs/src/content/docs/index.mdx` renders, top to bottom: hero (tagline + two CTAs) → **Why KSail?** (two prose paragraphs) → demo video → **Key Features** (17 cards) → **Quick Start** → **How It Works** (mermaid architecture diagram) → **Where to next** (six cards).

Seven gaps, all observable on the page as it stands today:

| # | Gap | What the page does now |
|---|---|---|
| 1 | The problem is not a section | The pain — "juggling kind or k3d, helm, kubectl, a GitOps engine, SOPS, and a pile of glue scripts" — is one clause inside a prose paragraph. A reader who skims never lands on it, and never sees their own frustration named back to them. |
| 2 | No "who this is for" | Nothing on the page lets a platform engineer, an app team without platform capacity, or an architect with a hand-built setup recognise themselves. Fit is left entirely to inference. |
| 3 | No "what's in the box" | KSail embeds Kind, K3d, Talos, vCluster, KWOK, Flux, ArgoCD, Helm, Kustomize, SOPS, K9s, cert-manager, and pluggable CNI/CSI/policy engines. The strongest available proof of the "one binary, no tool sprawl" claim exists only as prose and as labels inside a mermaid node — never as a scannable, categorised inventory. |
| 4 | Flat feature list | 17 equally-weighted cards. Everything is emphasised, so nothing is. There is no hierarchy between the handful of capabilities that actually decide adoption and the long tail that matters only after adoption. |
| 5 | No community or support surface | The page ends at "Where to next". There is no Discussions link, no issue tracker, no "where do I ask a question" — a visitor who is nearly convinced has nowhere to go but away. |
| 6 | No in-page navigation | The splash template gives the reader no way to jump between sections; the header carries search, GitHub, and the theme toggle only. The page is a scroll, not a structure. |
| 7 | "How It Works" is structural, not a journey | The mermaid diagram shows how the components relate to each other. It does not walk the reader from install to a working outcome, so "what does my first hour look like" is still unanswered. |

## Audience and problem

First-time visitors evaluating KSail: platform engineers choosing a cluster tool, application teams with no platform capacity, and architects whose hand-rolled setup has hit its limits. They arrive from search, GitHub, or a Slack link and decide in well under a minute whether this is for them.

The page currently asks them to read prose and infer their own fit. Every question that decides adoption — *is this my problem, is this for someone like me, what do I actually get, what will my first hour look like, and where do I ask if I get stuck* — is either buried or absent.

## Hypothesis

Restructuring the front page around **problem → fit → proof → journey → support**, rather than capability enumeration, will let a visitor answer those five questions without reading a paragraph — and convert more of them into a first `ksail project init`.

## Success signal

Umami is already wired into the site (`analytics.platform.devantler.tech`), so this is measurable rather than guessed.

- **Baseline first.** Capture at least two weeks of current front-page numbers before any redesign lands: sessions, bounce, and click-through to `/start/quickstart/` and the outbound GitHub link.
- **Target:** a meaningful lift in front-page → `/start/quickstart/` click-through against that baseline, with no drop in outbound GitHub clicks.
- **Guardrails:** no regression in Lighthouse performance or accessibility scores; no meaningful increase in page weight; no loss of the existing content — the long-tail features move, they do not disappear.
- **Honest proxy:** front-page CTA click-through is a proxy for adoption, not adoption itself. Installs and stars are too noisy and too lagged to attribute to a page change, so they are context, never the success criterion.

## Smallest useful change

Do **not** rebuild the page in one PR. The first independently shippable child is instrumentation + baseline (per-CTA and per-section Umami events), because without it the redesign cannot be judged. Each subsequent child is one section, shippable and reviewable on its own.

Proposed children, in order:

1. **Instrument and baseline** — per-CTA and per-section events, then record two weeks of numbers on this epic.
2. **Problem section** — promote the pain out of "Why KSail?" prose into its own scannable block, three named pains as cards.
3. **"Who it's for" section** — three self-identification cards for the three audiences above.
4. **"What's in the box" inventory** — every embedded tool as a card with a one-line "what this does for you", grouped by category (cluster provisioning · GitOps · secrets · workloads · cluster services). This is the single highest-value addition: it is the proof behind the headline claim.
5. **Feature hierarchy** — curate a headline set from the current 17; move the remainder behind a "see all capabilities" surface rather than deleting them.
6. **Journey rework** — turn "How It Works" into a numbered walkthrough from install to a working cluster with real commands and an explicit "you're done" end state. Keep the architecture diagram, but as supporting detail rather than the answer.
7. **Community and support block** — Discussions, issues, and docs, closing the page on a way forward instead of a dead end.
8. **In-page section navigation** — anchor links so the restructured page is navigable.

## Acceptance criteria

- A visitor can answer *is this my problem*, *is this for me*, *what do I get*, *what is my first hour*, and *where do I ask* without reading a prose paragraph.
- Every tool KSail embeds is visible on the front page as a categorised, scannable inventory.
- The front page has a curated feature hierarchy, not a flat list; nothing currently documented is lost.
- The page carries a community/support surface and in-page navigation.
- Instrumentation is live and a pre-redesign baseline is recorded on this epic before the final child merges.
- Voice follows the `jargon-free-voice` register: concise, outcome-framed, written for humans. Stack nouns stay — a reader looking for Talos or Flux support must still see those names.
- Lighthouse performance and accessibility do not regress.

## Size

Large — an epic, decomposed into the eight children above. Each child is small and independently shippable; children 2–8 depend only on child 1 existing, not on each other.

## Notes

This is a **restructure, not a rewrite of what KSail is.** The positioning, the claims, and the technical content are sound; the page's information architecture is what fails the first-time reader. Nothing here changes the product's scope or its docs' technical accuracy.

Read docs/src/content/docs/index.mdx and the splash template first, then begin with the independently shippable instrumentation and baseline child rather than the full redesign. Use the existing Umami setup and record the specified front-page metrics before changing sections. Done means the baseline is captured and each later section can be reviewed and shipped independently without losing existing content.

Written by the indexing model from the issue text.