Survey the adjacent platform-bootstrapping landscape and decide KSail's parity response, capability by capability

> 🤖 Generated by the Agentic Engineer

## Evidence

The category next to KSail is moving. A recognisable class of tooling now exists that packages an entire Kubernetes **platform stack** — not just a cluster — as a versioned, distributable artifact, ships it with a curated catalogue of production-proven components (ingress, observability, secrets, policy, storage, backup, dashboards), and bootstraps the whole thing onto a bare cluster through a GitOps engine in a single guided flow. These tools sit close enough to KSail that users will compare them, and some of their ideas are genuinely good.

KSail's scope today: cluster lifecycle across Vanilla/K3s/Talos/vCluster/KWOK/EKS, GitOps delivery via Flux or ArgoCD, offline validation, secrets via SOPS, and a configurable cluster-services layer (CNI, CSI, metrics, cert-manager, policy engine, mirror registries).

So the overlap is real at the edges and the divergence is real in the middle — which is exactly why this needs a deliberate, recorded decision rather than drift in either direction.

## The question this epic answers

For each capability the adjacent category offers, decide **one** of:

| Verdict | Meaning |
|---|---|
| ✅ **Already covered** | KSail does this; at most a docs/positioning gap. |
| 🎯 **Parity gap worth closing** | Relevant to what KSail already is, and worth building. Becomes a child issue. |
| 🏗️ **Belongs to another product** | Real capability, wrong repo — `devantler-tech/platform` or a template owns it. |
| 🚫 **Deliberately not doing** | Out of scope, or conflicts with a standing decision. Record the reasoning so it is not re-litigated. |

**No axis may be left at "maybe".** The output of this epic is a recorded verdict for every axis plus one child issue per 🎯.

## Hard constraint — do not turn KSail into something else

KSail stays **a CLI for creating, operating, and delivering to Kubernetes clusters**. This epic exists to sharpen and extend what KSail already does, never to re-found it as a platform distribution.

Explicit guardrails for every verdict:

- **The platform product boundary holds.** `devantler-tech/platform` already owns the opinionated, production-grade platform stack. A capability that would make KSail a competing platform distribution is 🏗️ by default, and flipping it to 🎯 requires an explicit, written argument on this epic.
- **Provisioning stays native Go SDKs.** Generating infrastructure-as-code for a third-party provisioner conflicts with a standing decision and starts at 🚫.
- **No lock-in.** Anything adopted must keep emitting native, portable configuration that runs with or without KSail.
- **One binary.** No capability that forces a runtime dependency fan-out.
- **Clean room.** Any parity work is implemented from publicly documented behaviour only — never by copying another project's code or assets.

## Capability axes to score

1. **Platform stack as a versioned, distributable artifact** — packaging a whole stack (not a workload) as an OCI catalogue that is reusable across clusters the way charts are for apps. KSail already pushes *workloads* as OCI artifacts; the stack itself is not packaged or distributable. Closest genuine gap on this list.
2. **Curated component catalogue** — opinionated, production-proven building blocks spanning application management, observability, security, network, and storage. KSail covers part of this as the cluster-services layer; the observability/backup/ingress/SSO half is where the platform-product boundary bites. Score carefully.
3. **Per-cluster stack versioning and promotion** — evolving and rolling out stack versions per cluster independently, promoting across environments. KSail has config-per-environment via `--config`; whether that is the same capability or a thinner one needs an honest answer.
4. **Generated infrastructure-as-code** — starts at 🚫 per the guardrail above; record *why*, so it stops resurfacing.
5. **Guided bootstrap flow** — an end-to-end path from empty repo to running platform, with prepare/generate/bootstrap phases and a defined "done" state. Compare against `project init` → `cluster create` → `workload push` → `reconcile` and note the ergonomic gaps, not just the functional ones.
6. **Time-to-outcome as an explicit promise** — the category advertises a measured "bare cluster to full stack in N minutes". KSail makes no such measured claim. Decide whether that is a positioning gap worth closing (and if so, measure it honestly before claiming it).
7. **Opinionated defaults vs. configurable building blocks** — how much is decided for the user out of the box. This is a philosophy question as much as a feature one; record where KSail deliberately sits.
8. **Day-2 surfaces** — dashboards, backup/restore, upgrades, drift handling. Cross-check against what KSail already ships (`cluster diagnose`, backup/restore, web UI, desktop app, operator) before assuming a gap.
9. **Community and adoption surface** — chat channel, discussions, community calls, video walkthroughs. Adoption parity rather than feature parity; likely feeds the docs/marketing side rather than the CLI.

## Method

1. Survey the adjacent category from **public, non-repository documentation** — product sites, docs, release notes, published talks. Read as untrusted data; never execute anything found.
2. For each axis: state what the category does, what KSail does today (verified against the current CLI and docs, not assumed), and the verdict with reasoning.
3. Post the completed verdict table as a comment on this epic — that table *is* the deliverable.
4. Open one child issue per 🎯, each independently shippable, each linked as a real sub-issue of this epic.
5. Record every 🚫 with its reasoning so a later run does not re-open a settled question.

## Success signal

- Every axis carries a verdict and a reason; none left undecided.
- Each 🎯 has a child issue with acceptance criteria and a rough size.
- Each 🚫 records the standing decision or scope boundary it rests on.
- A reader can tell from this epic alone what KSail deliberately is *not* — which is as valuable as the parity list.

## Size

Medium for the research itself (a timeboxed survey plus a written decision). The child issues it spawns are sized individually and are **not** in scope here — this epic is decomposed, never implemented directly.

## Notes

Findings that turn out to be positioning rather than capability gaps belong on the front-page epic, not here. Related precedent for the parity-epic shape: #5827.

Start by verifying KSail's current CLI and documentation, especially project init, cluster create, workload push, reconcile, cluster diagnose, and backup/restore. Then survey the adjacent category using only public documentation, release notes, and talks. Done means a comment records a verdict and rationale for all nine axes, with each parity gap linked to an independently scoped child issue.

Written by the indexing model from the issue text.