render: shorten the component rendered in the output

It's too long for documentation.  Shorten it for clarity.

Result:

```
❯ holos render platform ./platform
rendered bank-accounts-db for cluster workload in 160.7245ms
rendered bank-ledger-db for cluster workload in 162.465625ms
rendered bank-userservice for cluster workload in 166.150417ms
rendered bank-ledger-writer for cluster workload in 168.075459ms
rendered bank-balance-reader for cluster workload in 172.492292ms
rendered bank-backend-config for cluster workload in 198.117916ms
rendered bank-secrets for cluster workload in 223.200042ms
rendered gateway for cluster workload in 124.841917ms
rendered httproutes for cluster workload in 131.86625ms
rendered bank-contacts for cluster workload in 154.463792ms
rendered bank-transaction-history for cluster workload in 159.968208ms
rendered bank-frontend for cluster workload in 325.24425ms
rendered app-projects for cluster workload in 110.577916ms
rendered ztunnel for cluster workload in 137.502792ms
rendered cni for cluster workload in 209.993375ms
rendered cert-manager for cluster workload in 172.933834ms
rendered external-secrets for cluster workload in 135.759792ms
rendered local-ca for cluster workload in 98.026708ms
rendered istiod for cluster workload in 403.050833ms
rendered argocd for cluster workload in 294.663167ms
rendered gateway-api for cluster workload in 228.47875ms
rendered namespaces for cluster workload in 113.586916ms
rendered base for cluster workload in 533.76675ms
rendered external-secrets-crds for cluster workload in 529.053375ms
rendered crds for cluster workload in 931.180458ms
rendered platform in 1.248310167s
```

Previously:

```
❯ holos render platform ./platform
rendered projects/bank-of-holos/backend/components/bank-ledger-db for cluster workload in 158.534875ms
rendered projects/bank-of-holos/backend/components/bank-accounts-db for cluster workload in 159.836166ms
rendered projects/bank-of-holos/backend/components/bank-userservice for cluster workload in 160.360667ms
rendered projects/bank-of-holos/backend/components/bank-balance-reader for cluster workload in 169.478584ms
rendered projects/bank-of-holos/backend/components/bank-ledger-writer for cluster workload in 169.437833ms
rendered projects/bank-of-holos/backend/components/bank-backend-config for cluster workload in 182.089333ms
rendered projects/bank-of-holos/security/components/bank-secrets for cluster workload in 196.502792ms
rendered projects/platform/components/istio/gateway for cluster workload in 122.273083ms
rendered projects/bank-of-holos/frontend/components/bank-frontend for cluster workload in 307.573584ms
rendered projects/platform/components/httproutes for cluster workload in 149.631583ms
rendered projects/bank-of-holos/backend/components/bank-contacts for cluster workload in 153.529708ms
rendered projects/bank-of-holos/backend/components/bank-transaction-history for cluster workload in 165.375667ms
rendered projects/platform/components/app-projects for cluster workload in 107.253958ms
rendered projects/platform/components/istio/ztunnel for cluster workload in 137.22275ms
rendered projects/platform/components/istio/cni for cluster workload in 233.980958ms
rendered projects/platform/components/cert-manager for cluster workload in 171.966958ms
rendered projects/platform/components/external-secrets for cluster workload in 134.207792ms
rendered projects/platform/components/istio/istiod for cluster workload in 403.19ms
rendered projects/platform/components/local-ca for cluster workload in 97.544708ms
rendered projects/platform/components/argocd/argocd for cluster workload in 289.577208ms
rendered projects/platform/components/gateway-api for cluster workload in 218.290458ms
rendered projects/platform/components/namespaces for cluster workload in 109.534125ms
rendered projects/platform/components/istio/base for cluster workload in 526.32525ms
rendered projects/platform/components/external-secrets-crds for cluster workload in 523.7495ms
rendered projects/platform/components/argocd/crds for cluster workload in 1.002546375s
rendered platform in 1.312824333s
```

.cspell.json

@@ -5,48 +5,89 @@
     "mdx"
   ],
   "words": [
+    "admissionregistration",
+    "apiextensions",
     "applicationset",
     "argoproj",
     "authcode",
+    "authorizationpolicies",
     "authpolicy",
     "authproxy",
     "authroutes",
     "buildplan",
     "cainjector",
+    "CAROOT",
+    "certificaterequests",
+    "certificatesigningrequests",
+    "clsx",
     "clusterissuer",
+    "clusterissuers",
+    "clusterrole",
+    "clusterrolebinding",
+    "configmap",
     "cookiesecret",
     "coredns",
+    "corev",
+    "CRD's",
     "crds",
+    "creds",
     "crossplane",
     "cuecontext",
     "cuelang",
+    "customresourcedefinition",
+    "daemonset",
+    "destinationrules",
     "devicecode",
     "dnsmasq",
     "dscacheutil",
     "entgo",
+    "envoyfilters",
     "errgroup",
+    "fctr",
     "fieldmaskpb",
     "flushcache",
+    "gatewayclasses",
+    "gendoc",
+    "ggnpl",
+    "ghaction",
     "gitops",
+    "godoc",
+    "golangci",
+    "goreleaser",
     "grpcreflect",
+    "grpcroutes",
     "grpcurl",
     "holos",
     "holoslogger",
+    "horizontalpodautoscaler",
     "httpbin",
+    "httproute",
+    "httproutes",
     "Infima",
     "isatty",
     "istiod",
+    "jbrx",
     "jetstack",
+    "Jsonnet",
     "killall",
     "kubeadm",
     "kubeconfig",
     "kubelogin",
     "Kustomization",
+    "Kustomizations",
     "kustomize",
     "ldflags",
+    "leaderelection",
     "libnss",
     "loadbalancer",
     "mattn",
+    "mccutchen",
+    "mindmap",
+    "mktemp",
+    "msqbn",
+    "mtls",
+    "Multicluster",
+    "mutatingwebhookconfiguration",
     "mxcl",
     "myhostname",
     "nameserver",
@@ -54,35 +95,67 @@
     "orgid",
     "otelconnect",
     "Parentspanid",
+    "pcjc",
+    "peerauthentications",
     "pflag",
+    "pipefail",
     "PKCE",
     "platformconnect",
+    "poddisruptionbudget",
+    "podinfo",
+    "portmapping",
     "promhttp",
+    "protobuf",
     "protojson",
+    "proxyconfigs",
+    "Pulumi",
     "putenv",
+    "qjbp",
     "quickstart",
+    "referencegrant",
+    "referencegrants",
+    "requestauthentications",
     "retryable",
+    "rolebinding",
     "ropc",
+    "seccomp",
+    "SECRETKEY",
+    "secretstores",
+    "serverlb",
+    "serverside",
+    "serviceaccount",
+    "serviceentries",
     "spanid",
     "spiffe",
     "startupapicheck",
+    "stefanprodan",
     "structpb",
+    "subjectaccessreviews",
+    "svclb",
     "systemconnect",
     "tablewriter",
     "Tiltfile",
     "timestamppb",
+    "Timoni",
     "tlsclientconfig",
     "tokencache",
     "Tokener",
     "Traceid",
     "traefik",
     "uibutton",
+    "untar",
     "Upsert",
     "urandom",
     "usecases",
     "userconnect",
     "userdata",
+    "validatingwebhookconfiguration",
+    "virtualservices",
+    "wasmplugins",
+    "workloadentries",
+    "workloadgroups",
     "zerolog",
-    "zitadel"
+    "zitadel",
+    "ztunnel"
   ]
 }

.github/workflows/dev-deploy.yaml

@@ -0,0 +1,57 @@
+name: Dev Deploy
+
+on:
+  push:
+    branches: ['main', 'dev-deploy']
+
+jobs:
+  deploy:
+    name: Deploy
+    runs-on: ubuntu-latest
+    steps:
+      ## Not needed on ubuntu-latest
+      # - name: Provide GPG and Git
+      #   run: sudo apt update && sudo apt -qq -y install gnupg git curl zip unzip tar bzip2 make jq
+
+      ## Not needed on ubuntu-latest
+      # - name: Provide Holos Dependencies
+      #   run: |
+      #     sudo mkdir -p -m 755 /etc/apt/keyrings
+      #     curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
+      #     sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg
+      #     echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
+      #     sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list
+      #     sudo apt update
+      #     sudo apt install -qq -y kubectl
+      #     curl -fsSL -o-  https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
+
+      # Must come after git executable is provided
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: '1.22.x'
+
+      - uses: ko-build/setup-ko@v0.7
+        env:
+          KO_DOCKER_REPO: quay.io/holos-run/holos
+
+      - name: Setup SSH
+        run: |
+          mkdir -p ~/.ssh
+          echo "${{ secrets.DEPLOY_SSH_PRIVATE_KEY }}" > ~/.ssh/id_ed25519
+          chmod 600 ~/.ssh/id_ed25519
+          ssh-keyscan github.com >> ~/.ssh/known_hosts
+          git config --global user.name "github-actions[bot]"
+          git config --global user.email "github-actions[bot]@users.noreply.github.com"
+
+      - name: make dev-deploy
+        env:
+          auth_user: holos-run+pusher
+          auth_token: ${{ secrets.QUAY_TOKEN }}
+        run: |
+          echo "${auth_token}" | ko login quay.io --username "${auth_user}" --password-stdin
+          make dev-deploy

.github/workflows/golangci-lint.yaml

@@ -0,0 +1,30 @@
+name: golangci-lint
+on:
+  push:
+    branches:
+      - main
+      - test
+  pull_request:
+    types: [opened, synchronize]
+
+permissions:
+  # Required: allow read access to the content for analysis.
+  contents: read
+  # Optional: allow read access to pull request. Use with `only-new-issues` option.
+  pull-requests: read
+  # Optional: allow write access to checks to allow the action to annotate code in the PR.
+  checks: write
+
+jobs:
+  golangci:
+    name: lint
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-go@v5
+        with:
+          go-version: stable
+      - name: golangci-lint
+        uses: golangci/golangci-lint-action@v6
+        with:
+          version: v1.60

.github/workflows/lint.yaml

@@ -13,9 +13,9 @@ permissions:
   contents: read
 
 jobs:
-  golangci:
+  lint:
     name: lint
-    runs-on: gha-rs
+    runs-on: ubuntu-latest
     steps:
       - name: Checkout code
         uses: actions/checkout@v4
@@ -30,16 +30,13 @@ jobs:
         with:
           go-version: stable
 
-      - name: Install Packages
-        run: sudo apt update && sudo apt -qq -y install git curl zip unzip tar bzip2 make
+      ## Not needed on ubuntu-latest
+      # - name: Install Packages
+      #   run: sudo apt update && sudo apt -qq -y install git curl zip unzip tar bzip2 make
 
       - name: Install Tools
-        run: |
-          set -x
-          make tools
+        run: make tools
 
-      - name: golangci-lint
-        uses: golangci/golangci-lint-action@v4
-        with:
-          version: latest
-          skip-pkg-cache: true
+      - name: Lint
+        # golangci-lint runs in a separate workflow.
+        run: make lint -o golangci-lint

.github/workflows/publish.yaml

@@ -1,36 +0,0 @@
-name: Publish
-
-on:
-  push:
-    branches: ['main', 'publish']
-
-jobs:
-  publish:
-    name: Publish
-    runs-on: gha-rs
-    steps:
-      - name: Provide GPG and Git
-        run: sudo apt update && sudo apt -qq -y install gnupg git curl zip unzip tar bzip2 make
-
-      # Must come after git executable is provided
-      - name: Checkout
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - uses: actions/setup-go@v5
-        with:
-          go-version: '1.22.x'
-
-      - uses: ko-build/setup-ko@v0.7
-        env:
-          KO_DOCKER_REPO: quay.io/holos-run/holos
-
-      - name: Publish
-        env:
-          KO_DOCKER_REPO: quay.io/holos-run/holos
-          auth_token: ${{ secrets.QUAY_TOKEN }}
-          auth_user: ${{ secrets.QUAY_USER }}
-        run: |
-          echo "${auth_token}" | ko login "https://${KO_DOCKER_REPO}" --username "${auth_user}" --password-stdin
-          ko build

.github/workflows/release.yaml

@@ -12,11 +12,12 @@ permissions:
 
 jobs:
   goreleaser:
-    runs-on: gha-rs
+    runs-on: ubuntu-latest
     steps:
+      ## Not needed on ubuntu-latest
       # Must come before Checkout, otherwise goreleaser fails
-      - name: Provide GPG and Git
-        run: sudo apt update && sudo apt -qq -y install gnupg git curl zip unzip tar bzip2 make
+      # - name: Provide GPG and Git
+      #   run: sudo apt update && sudo apt -qq -y install gnupg git curl zip unzip tar bzip2 make
 
       # Must come after git executable is provided
       - name: Checkout

.gitignore

@@ -1,5 +1,4 @@
 /bin/
-vendor/
 .idea/
 coverage.out
 /dist/

Makefile

@@ -58,7 +58,6 @@ tidy: ## Tidy go module.
 
 .PHONY: fmt
 fmt: ## Format code.
-	cd docs/examples && cue fmt ./...
 	cd internal/generate/platforms && cue fmt ./...
 	go fmt ./...
 
@@ -93,11 +92,14 @@ clean: ## Clean executables.
 test: ## Run tests.
 	scripts/test
 
+.PHONY: golangci-lint
+golangci-lint:
+	golangci-lint run
+
 .PHONY: lint
-lint: ## Run linters.
+lint: golangci-lint ## Run linters.
 	buf lint
 	cd internal/frontend/holos && ng lint
-	golangci-lint run
 	./hack/cspell
 
 .PHONY: coverage
@@ -133,13 +135,17 @@ website-deps: ## Install Docusaurus deps for go generate
 	cd doc/website && npm install
 
 .PHONY: image # refer to .ko.yaml as well
-image:  ## Container image build
-	KO_DOCKER_REPO=$(DOCKER_REPO) GIT_DETAIL=$(GIT_DETAIL) GIT_SUFFIX=$(GIT_SUFFIX) ko build --platform=all --bare ./cmd/holos --tags $(GIT_DETAIL)$(GIT_SUFFIX)
+image:  ## Container image build for workflows/publish.yaml
+	KO_DOCKER_REPO=$(DOCKER_REPO) GIT_DETAIL=$(GIT_DETAIL) GIT_SUFFIX=$(GIT_SUFFIX) ko build --platform=all --bare ./cmd/holos --tags $(GIT_DETAIL)$(GIT_SUFFIX) --tags latest
 
-.PHONY: deploy
-deploy: image  ## DEPLOY TO PROD
+.PHONY: prod-deploy
+prod-deploy: install image  ## deploy to PROD
 	GIT_DETAIL=$(GIT_DETAIL) GIT_SUFFIX=$(GIT_SUFFIX) bash ./hack/deploy
 
+.PHONY: dev-deploy
+dev-deploy: install image  ## deploy to dev
+	GIT_DETAIL=$(GIT_DETAIL) GIT_SUFFIX=$(GIT_SUFFIX) bash ./hack/deploy-dev
+
 .PHONY: website
 website: ## Build website
 	./hack/build-website

README.md

@@ -1,3 +1,35 @@
-# k3d Platform
+## Holos - A Holistic Development Platform
 
-Refer to https://holos.run/docs/tutorial/local/k3d
+<img width="50%"
+align="right"
+style="display: block; margin: 40px auto;"
+src="https://openinfrastructure.co/blog/2016/02/27/logo/logorectangle.png">
+
+Building and maintaining a software development platform is a complex and time
+consuming endeavour.  Organizations often dedicate a team of 3-4 who need 6-12
+months to build the platform.
+
+Holos is a tool and a reference platform to reduce the complexity and speed up
+the process of building a modern, cloud native software development platform.
+
+- **Accelerate new projects** - Reduce time to market and operational complexity by starting your new project on top of the Holos reference platform.
+- **Modernize existing projects** - Incrementally incorporate your existing platform services into Holos for simpler integration.
+- **Unified configuration model** - Increase safety and reduce the risk of config changes with CUE.
+- **First class Helm and Kustomize support** - Leverage and reuse your existing investment in existing configuration tools such as Helm and Kustomize.
+- **Modern Authentication and Authorization** - Holos seamlessly integrates platform identity and access management with zero-trust beyond corp style authorization policy.
+
+## Quick Installation
+
+```console
+go install github.com/holos-run/holos/cmd/holos@latest
+```
+
+## Docs and Support
+
+The documentation for developing and using Holos is available at: https://holos.run
+
+For discussion and support, [open a discussion](https://github.com/orgs/holos-run/discussions/new/choose).
+
+## License
+
+Holos is licensed under Apache 2.0 as found in the [LICENSE file](LICENSE).

api/core/v1alpha3/apiobjects.go

@@ -0,0 +1,47 @@
+package v1alpha3
+
+import "google.golang.org/protobuf/types/known/structpb"
+
+// InternalLabel is an arbitrary unique identifier internal to holos itself.
+// The holos cli is expected to never write a InternalLabel value to rendered
+// output files, therefore use a [InternalLabel] when the identifier must be
+// unique and internal.  Defined as a type for clarity and type checking.
+//
+// A InternalLabel is useful to convert a CUE struct to a list, for example
+// producing a list of [APIObject] resources from an [APIObjectMap].  A CUE
+// struct using InternalLabel keys is guaranteed to not lose data when rendering
+// output because a InternalLabel is expected to never be written to the final
+// output.
+type InternalLabel string
+
+// Kind is a kubernetes api object kind. Defined as a type for clarity and type
+// checking.
+type Kind string
+
+// APIObject represents the most basic generic form of a single kubernetes api
+// object.  Represented as a JSON object internally for compatibility between
+// tools, for example loading from CUE.
+type APIObject structpb.Struct
+
+// APIObjectMap represents the marshalled yaml representation of kubernetes api
+// objects.  Do not produce an APIObjectMap directly, instead use [APIObjects]
+// to produce the marshalled yaml representation from CUE data, then provide the
+// result to [Component].
+type APIObjectMap map[Kind]map[InternalLabel]string
+
+// APIObjects represents Kubernetes API objects defined directly from CUE code.
+// Useful to mix in resources to any kind of [Component], for example
+// adding an ExternalSecret resource to a [HelmChart].
+//
+// [Kind] must be the resource kind, e.g. Deployment or Service.
+//
+// [InternalLabel] is an arbitrary internal identifier to uniquely identify the resource
+// within the context of a `holos` command.  Holos will never write the
+// intermediate label to rendered output.
+//
+// Refer to [Component] which accepts an [APIObjectMap] field provided by
+// [APIObjects].
+type APIObjects struct {
+	APIObjects   map[Kind]map[InternalLabel]APIObject `json:"apiObjects"`
+	APIObjectMap APIObjectMap                         `json:"apiObjectMap"`
+}

api/core/v1alpha3/buildplan.go

@@ -0,0 +1,52 @@
+package v1alpha3
+
+// FilePath represents a file path.
+type FilePath string
+
+// FileContent represents file contents.
+type FileContent string
+
+// FileContentMap represents a mapping of file paths to file contents.
+type FileContentMap map[FilePath]FileContent
+
+// BuildPlan represents a build plan for the holos cli to execute.  The purpose
+// of a BuildPlan is to define one or more [Component] kinds.  For example a
+// [HelmChart], [KustomizeBuild], or [KubernetesObjects].
+//
+// A BuildPlan usually has an additional empty [KubernetesObjects] for the
+// purpose of using the [Component] DeployFiles field to deploy an ArgoCD
+// or Flux gitops resource for the holos component.
+type BuildPlan struct {
+	Kind       string        `json:"kind" cue:"\"BuildPlan\""`
+	APIVersion string        `json:"apiVersion" cue:"string | *\"v1alpha3\""`
+	Spec       BuildPlanSpec `json:"spec"`
+}
+
+// BuildPlanSpec represents the specification of the build plan.
+type BuildPlanSpec struct {
+	// Disabled causes the holos cli to take no action over the [BuildPlan].
+	Disabled bool `json:"disabled,omitempty"`
+	// Components represents multiple [HolosComponent] kinds to manage.
+	Components BuildPlanComponents `json:"components,omitempty"`
+}
+
+type BuildPlanComponents struct {
+	Resources             map[InternalLabel]KubernetesObjects `json:"resources,omitempty"`
+	KubernetesObjectsList []KubernetesObjects                 `json:"kubernetesObjectsList,omitempty"`
+	HelmChartList         []HelmChart                         `json:"helmChartList,omitempty"`
+	KustomizeBuildList    []KustomizeBuild                    `json:"kustomizeBuildList,omitempty"`
+}
+
+// Kustomize represents resources necessary to execute a kustomize build.
+// Intended for at least two use cases:
+//
+//  1. Process a [KustomizeBuild] [Component] which represents raw yaml
+//     file resources in a holos component directory.
+//  2. Post process a [HelmChart] [Component] to inject istio, patch jobs,
+//     add custom labels, etc...
+type Kustomize struct {
+	// KustomizeFiles holds file contents for kustomize, e.g. patch files.
+	KustomizeFiles FileContentMap `json:"kustomizeFiles,omitempty"`
+	// ResourcesFile is the file name used for api objects in kustomization.yaml
+	ResourcesFile string `json:"resourcesFile,omitempty"`
+}

api/core/v1alpha3/component.go

@@ -0,0 +1,43 @@
+package v1alpha3
+
+// Component defines the fields common to all holos component kinds.  Every
+// holos component kind should embed Component.
+type Component struct {
+	// Kind is a string value representing the resource this object represents.
+	Kind string `json:"kind"`
+	// APIVersion represents the versioned schema of this representation of an object.
+	APIVersion string `json:"apiVersion" cue:"\"v1alpha3\""`
+	// Metadata represents data about the holos component such as the Name.
+	Metadata Metadata `json:"metadata"`
+
+	// APIObjectMap holds the marshalled representation of api objects.  Useful to
+	// mix in resources to each Component type, for example adding an
+	// ExternalSecret to a [HelmChart] Component.  Refer to [APIObjects].
+	APIObjectMap APIObjectMap `json:"apiObjectMap,omitempty"`
+
+	// DeployFiles represents file paths relative to the cluster deploy directory
+	// with the value representing the file content.  Intended for defining the
+	// ArgoCD Application resource or Flux Kustomization resource from within CUE,
+	// but may be used to render any file related to the build plan from CUE.
+	DeployFiles FileContentMap `json:"deployFiles,omitempty"`
+
+	// Kustomize represents a kubectl kustomize build post-processing step.
+	Kustomize `json:"kustomize,omitempty"`
+
+	// Skip causes holos to take no action regarding this component.
+	Skip bool `json:"skip" cue:"bool | *false"`
+}
+
+// Metadata represents data about the object such as the Name.
+type Metadata struct {
+	// Name represents the name of the holos component.
+	Name string `json:"name"`
+	// Namespace is the primary namespace of the holos component.  A holos
+	// component may manage resources in multiple namespaces, in this case
+	// consider setting the component namespace to default.
+	//
+	// This field is optional because not all resources require a namespace,
+	// particularly CRDs and DeployFiles functionality.
+	// +optional
+	Namespace string `json:"namespace,omitempty"`
+}

api/core/v1alpha3/constants.go

@@ -0,0 +1,11 @@
+package v1alpha3
+
+const (
+	APIVersion    = "v1alpha3"
+	BuildPlanKind = "BuildPlan"
+	HelmChartKind = "HelmChart"
+	// ChartDir is the directory name created in the holos component directory to cache a chart.
+	ChartDir = "vendor"
+	// ResourcesFile is the file name used to store component output when post-processing with kustomize.
+	ResourcesFile = "resources.yaml"
+)

api/core/v1alpha3/doc.go

@@ -0,0 +1,26 @@
+// Package v1alpha3 contains the core API contract between the holos cli and CUE
+// configuration code.  Platform designers, operators, and software developers
+// use this API to write configuration in CUE which `holos` loads.  The overall
+// shape of the API defines imperative actions `holos` should carry out to
+// render the complete yaml that represents a Platform.
+//
+// [Platform] defines the complete configuration of a platform.  With the holos
+// reference platform this takes the shape of one management cluster and at
+// least two workload cluster.  Each cluster has multiple [Component]
+// resources applied to it.
+//
+// Each holos component path, e.g. `components/namespaces` produces exactly one
+// [BuildPlan] which in turn contains a set of [Component] kinds.
+//
+// The primary kinds of [Component] are:
+//
+//  1. [HelmChart] to render config from a helm chart.
+//  2. [KustomizeBuild] to render config from [Kustomize]
+//  3. [KubernetesObjects] to render [APIObjects] defined directly in CUE
+//     configuration.
+//
+// Note that Holos operates as a data pipeline, so the output of a [HelmChart]
+// may be provided to [Kustomize] for post-processing.
+package v1alpha3
+
+//go:generate ../../../hack/gendoc

api/core/v1alpha3/helm.go

@@ -0,0 +1,38 @@
+package v1alpha3
+
+// HelmChart represents a holos component which wraps around an upstream helm
+// chart.  Holos orchestrates helm by providing values obtained from CUE,
+// renders the output using `helm template`, then post-processes the helm output
+// yaml using the general functionality provided by [Component], for
+// example [Kustomize] post-rendering and mixing in additional kubernetes api
+// objects.
+type HelmChart struct {
+	Component `json:",inline"`
+	Kind      string `json:"kind" cue:"\"HelmChart\""`
+
+	// Chart represents a helm chart to manage.
+	Chart Chart `json:"chart"`
+	// ValuesContent represents the values.yaml file holos passes to the `helm
+	// template` command.
+	ValuesContent string `json:"valuesContent"`
+	// EnableHooks enables helm hooks when executing the `helm template` command.
+	EnableHooks bool `json:"enableHooks" cue:"bool | *false"`
+}
+
+// Chart represents a helm chart.
+type Chart struct {
+	// Name represents the chart name.
+	Name string `json:"name"`
+	// Version represents the chart version.
+	Version string `json:"version"`
+	// Release represents the chart release when executing helm template.
+	Release string `json:"release"`
+	// Repository represents the repository to fetch the chart from.
+	Repository Repository `json:"repository,omitempty"`
+}
+
+// Repository represents a helm chart repository.
+type Repository struct {
+	Name string `json:"name"`
+	URL  string `json:"url"`
+}

api/core/v1alpha3/kubernetesobjects.go

@@ -0,0 +1,10 @@
+package v1alpha3
+
+const KubernetesObjectsKind = "KubernetesObjects"
+
+// KubernetesObjects represents a [Component] composed of Kubernetes API
+// objects provided directly from CUE using [APIObjects].
+type KubernetesObjects struct {
+	Component `json:",inline"`
+	Kind      string `json:"kind" cue:"\"KubernetesObjects\""`
+}

api/core/v1alpha3/kustomizebuild.go

@@ -0,0 +1,8 @@
+package v1alpha3
+
+// KustomizeBuild represents a [Component] that renders plain yaml files in
+// the holos component directory using `kubectl kustomize build`.
+type KustomizeBuild struct {
+	Component `json:",inline"`
+	Kind      string `json:"kind" cue:"\"KustomizeBuild\""`
+}

api/core/v1alpha3/platform.go

@@ -0,0 +1,44 @@
+package v1alpha3
+
+import "google.golang.org/protobuf/types/known/structpb"
+
+// Platform represents a platform to manage.  A Platform resource informs holos
+// which components to build.  The platform resource also acts as a container
+// for the platform model form values provided by the PlatformService.  The
+// primary use case is to collect the cluster names, cluster types, platform
+// model, and holos components to build into one resource.
+type Platform struct {
+	// Kind is a string value representing the resource this object represents.
+	Kind string `json:"kind" cue:"\"Platform\""`
+	// APIVersion represents the versioned schema of this representation of an object.
+	APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha3\""`
+	// Metadata represents data about the object such as the Name.
+	Metadata PlatformMetadata `json:"metadata"`
+
+	// Spec represents the specification.
+	Spec PlatformSpec `json:"spec"`
+}
+
+type PlatformMetadata struct {
+	// Name represents the Platform name.
+	Name string `json:"name"`
+}
+
+// PlatformSpec represents the specification of a Platform.  Think of a platform
+// specification as a list of platform components to apply to a list of
+// kubernetes clusters combined with the user-specified Platform Model.
+type PlatformSpec struct {
+	// Model represents the platform model holos gets from from the
+	// PlatformService.GetPlatform rpc method and provides to CUE using a tag.
+	Model structpb.Struct `json:"model" cue:"{...}"`
+	// Components represents a list of holos components to manage.
+	Components []PlatformSpecComponent `json:"components"`
+}
+
+// PlatformSpecComponent represents a holos component to build or render.
+type PlatformSpecComponent struct {
+	// Path is the path of the component relative to the platform root.
+	Path string `json:"path"`
+	// Cluster is the cluster name to provide when rendering the component.
+	Cluster string `json:"cluster"`
+}

api/schema/v1alpha3/definitions.go

@@ -0,0 +1,163 @@
+// Package v1alpha3 contains CUE definitions intended as convenience wrappers
+// around the core data types defined in package core.  The purpose of these
+// wrappers is to make life easier for platform engineers by reducing boiler
+// plate code and generating component build plans in a consistent manner.
+package v1alpha3
+
+import (
+	core "github.com/holos-run/holos/api/core/v1alpha3"
+	"google.golang.org/protobuf/types/known/structpb"
+)
+
+//go:generate ../../../hack/gendoc
+
+// Component represents the fields common the different kinds of component.  All
+// components have a name, support mixing in resources, and produce a BuildPlan.
+type ComponentFields struct {
+	// Name represents the Component name.
+	Name string
+	// Resources are kubernetes api objects to mix into the output.
+	Resources map[string]any
+	// ArgoConfig represents the ArgoCD GitOps configuration for this Component.
+	ArgoConfig ArgoConfig
+	// BuildPlan represents the derived BuildPlan for the Holos cli to render.
+	BuildPlan core.BuildPlan
+}
+
+// Helm provides a BuildPlan via the Output field which contains one HelmChart
+// from package core.  Useful as a convenience wrapper to render a HelmChart
+// with optional mix-in resources and Kustomization post-processing.
+type Helm struct {
+	ComponentFields `json:",inline"`
+
+	// Version represents the chart version.
+	Version string
+	// Namespace represents the helm namespace option when rendering the chart.
+	Namespace string
+
+	// Repo represents the chart repository
+	Repo struct {
+		Name string `json:"name"`
+		URL  string `json:"url"`
+	}
+
+	// Values represents data to marshal into a values.yaml for helm.
+	Values interface{} `cue:"{...}"`
+
+	// Chart represents the derived HelmChart for inclusion in the BuildPlan
+	// Output field value.  The default HelmChart field values are derived from
+	// other Helm field values and should be sufficient for most use cases.
+	Chart core.HelmChart
+
+	// EnableKustomizePostProcessor processes helm output with kustomize if true.
+	EnableKustomizePostProcessor bool `cue:"true | *false"`
+
+	// KustomizeFiles represents additional files to include in a Kustomization
+	// resources list.  Useful to patch helm output.  The implementation is a
+	// struct with filename keys and structs as values.  Holos encodes the struct
+	// value to yaml then writes the result to the filename key.  Component
+	// authors may then reference the filename in the kustomization.yaml resources
+	// or patches lists.
+	// Requires EnableKustomizePostProcessor: true.
+	KustomizeFiles map[string]any `cue:"{[string]: {...}}"`
+
+	// KustomizePatches represents patches to apply to the helm output.  Requires
+	// EnableKustomizePostProcessor: true.
+	KustomizePatches map[core.InternalLabel]any `cue:"{[string]: {...}}"`
+
+	// KustomizeResources represents additional resources files to include in the
+	// kustomize resources list.
+	KustomizeResources map[string]any `cue:"{[string]: {...}}"`
+}
+
+// Kustomize provides a BuildPlan via the Output field which contains one
+// KustomizeBuild from package core.
+type Kustomize struct {
+	ComponentFields `json:",inline"`
+	// Kustomization represents the kustomize build plan for holos to render.
+	Kustomization core.KustomizeBuild
+}
+
+// Kubernetes provides a BuildPlan via the Output field which contains inline
+// API Objects provided directly from CUE.
+type Kubernetes struct {
+	ComponentFields `json:",inline"`
+	// Objects represents the kubernetes api objects for the Component.
+	Objects core.KubernetesObjects
+}
+
+// ArgoConfig represents the ArgoCD GitOps configuration for a Component.
+// Useful to define once at the root of the Platform configuration and reuse
+// across all Components.
+type ArgoConfig struct {
+	// Enabled causes holos to render an ArgoCD Application resource for GitOps if true.
+	Enabled bool `cue:"true | *false"`
+	// ClusterName represents the cluster within the platform the Application
+	// resource is intended for.
+	ClusterName string
+	// DeployRoot represents the path from the git repository root to the `deploy`
+	// rendering output directory.  Used as a prefix for the
+	// Application.spec.source.path field.
+	DeployRoot string `cue:"string | *\".\""`
+	// RepoURL represents the value passed to the Application.spec.source.repoURL
+	// field.
+	RepoURL string
+	// TargetRevision represents the value passed to the
+	// Application.spec.source.targetRevision field.  Defaults to the branch named
+	// main.
+	TargetRevision string `cue:"string | *\"main\""`
+	// AppProject represents the ArgoCD Project to associate the Application with.
+	AppProject string `cue:"string | *\"default\""`
+}
+
+// Cluster represents a cluster managed by the Platform.
+type Cluster struct {
+	// Name represents the cluster name, for example "east1", "west1", or
+	// "management".
+	Name string `json:"name"`
+	// Primary represents if the cluster is marked as the primary among a set of
+	// candidate clusters.  Useful for promotion of database leaders.
+	Primary bool `json:"primary" cue:"true | *false"`
+}
+
+// Fleet represents a named collection of similarly configured Clusters.  Useful
+// to segregate workload clusters from their management cluster.
+type Fleet struct {
+	Name string `json:"name"`
+	// Clusters represents a mapping of Clusters by their name.
+	Clusters map[string]Cluster `json:"clusters" cue:"{[Name=_]: name: Name}"`
+}
+
+// StandardFleets represents the standard set of Clusters in a Platform
+// segmented into Fleets by their purpose.  The management Fleet contains a
+// single Cluster, for example a GKE autopilot cluster with no workloads
+// deployed for reliability and cost efficiency.  The workload Fleet contains
+// all other Clusters which contain workloads and sync Secrets from the
+// management cluster.
+type StandardFleets struct {
+	// Workload represents a Fleet of zero or more workload Clusters.
+	Workload Fleet `json:"workload" cue:"{name: \"workload\"}"`
+	// Management represents a Fleet with one Cluster named management.
+	Management Fleet `json:"management" cue:"{name: \"management\"}"`
+}
+
+// Platform is a convenience structure to produce a core Platform specification
+// value in the Output field.  Useful to collect components at the root of the
+// Platform configuration tree as a struct, which are automatically converted
+// into a list for the core Platform spec output.
+type Platform struct {
+	// Name represents the Platform name.
+	Name string `cue:"string | *\"holos\""`
+	// Components is a structured map of components to manage by their name.
+	Components map[string]core.PlatformSpecComponent
+	// Model represents the Platform model holos gets from from the
+	// PlatformService.GetPlatform rpc method and provides to CUE using a tag.
+	Model structpb.Struct `cue:"{...}"`
+	// Output represents the core Platform spec for the holos cli to iterate over
+	// and render each listed Component, injecting the Model.
+	Output core.Platform
+	// Domain represents the primary domain the Platform operates in.  This field
+	// is intended as a sensible default for component authors to reference and
+	// platform operators to define.
+	Domain string `cue:"string | *\"holos.localhost\""`
+}

api/v1alpha1/buildplan.go

@@ -1,6 +1,7 @@
 package v1alpha1
 
 import (
+	"errors"
 	"fmt"
 	"strings"
 )
@@ -38,7 +39,7 @@ func (bp *BuildPlan) Validate() error {
 		errs = append(errs, fmt.Sprintf("apiVersion invalid: want: %s have: %s", APIVersion, bp.APIVersion))
 	}
 	if len(errs) > 0 {
-		return fmt.Errorf("invalid BuildPlan: " + strings.Join(errs, ", "))
+		return errors.New("invalid BuildPlan: " + strings.Join(errs, ", "))
 	}
 	return nil
 }

doc/md/api.md

@@ -0,0 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
+# API Reference
+
+<DocCardList />

doc/md/api/core.md

@@ -0,0 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
+# Core API
+
+<DocCardList />

doc/md/api/core/v1alpha3.md

@@ -0,0 +1,403 @@
+<!-- Code generated by gomarkdoc. DO NOT EDIT -->
+
+# v1alpha3
+
+```go
+import "github.com/holos-run/holos/api/core/v1alpha3"
+```
+
+Package v1alpha3 contains the core API contract between the holos cli and CUE configuration code. Platform designers, operators, and software developers use this API to write configuration in CUE which \`holos\` loads. The overall shape of the API defines imperative actions \`holos\` should carry out to render the complete yaml that represents a Platform.
+
+[Platform](<#Platform>) defines the complete configuration of a platform. With the holos reference platform this takes the shape of one management cluster and at least two workload cluster. Each cluster has multiple [Component](<#Component>) resources applied to it.
+
+Each holos component path, e.g. \`components/namespaces\` produces exactly one [BuildPlan](<#BuildPlan>) which in turn contains a set of [Component](<#Component>) kinds.
+
+The primary kinds of [Component](<#Component>) are:
+
+1. [HelmChart](<#HelmChart>) to render config from a helm chart.
+2. [KustomizeBuild](<#KustomizeBuild>) to render config from [Kustomize](<#Kustomize>)
+3. [KubernetesObjects](<#KubernetesObjects>) to render [APIObjects](<#APIObjects>) defined directly in CUE configuration.
+
+Note that Holos operates as a data pipeline, so the output of a [HelmChart](<#HelmChart>) may be provided to [Kustomize](<#Kustomize>) for post\-processing.
+
+## Index
+
+- [Constants](<#constants>)
+- [type APIObject](<#APIObject>)
+- [type APIObjectMap](<#APIObjectMap>)
+- [type APIObjects](<#APIObjects>)
+- [type BuildPlan](<#BuildPlan>)
+- [type BuildPlanComponents](<#BuildPlanComponents>)
+- [type BuildPlanSpec](<#BuildPlanSpec>)
+- [type Chart](<#Chart>)
+- [type Component](<#Component>)
+- [type FileContent](<#FileContent>)
+- [type FileContentMap](<#FileContentMap>)
+- [type FilePath](<#FilePath>)
+- [type HelmChart](<#HelmChart>)
+- [type InternalLabel](<#InternalLabel>)
+- [type Kind](<#Kind>)
+- [type KubernetesObjects](<#KubernetesObjects>)
+- [type Kustomize](<#Kustomize>)
+- [type KustomizeBuild](<#KustomizeBuild>)
+- [type Metadata](<#Metadata>)
+- [type Platform](<#Platform>)
+- [type PlatformMetadata](<#PlatformMetadata>)
+- [type PlatformSpec](<#PlatformSpec>)
+- [type PlatformSpecComponent](<#PlatformSpecComponent>)
+- [type Repository](<#Repository>)
+
+
+## Constants
+
+<a name="APIVersion"></a>
+
+```go
+const (
+    APIVersion    = "v1alpha3"
+    BuildPlanKind = "BuildPlan"
+    HelmChartKind = "HelmChart"
+    // ChartDir is the directory name created in the holos component directory to cache a chart.
+    ChartDir = "vendor"
+    // ResourcesFile is the file name used to store component output when post-processing with kustomize.
+    ResourcesFile = "resources.yaml"
+)
+```
+
+<a name="KubernetesObjectsKind"></a>
+
+```go
+const KubernetesObjectsKind = "KubernetesObjects"
+```
+
+<a name="APIObject"></a>
+## type APIObject {#APIObject}
+
+APIObject represents the most basic generic form of a single kubernetes api object. Represented as a JSON object internally for compatibility between tools, for example loading from CUE.
+
+```go
+type APIObject structpb.Struct
+```
+
+<a name="APIObjectMap"></a>
+## type APIObjectMap {#APIObjectMap}
+
+APIObjectMap represents the marshalled yaml representation of kubernetes api objects. Do not produce an APIObjectMap directly, instead use [APIObjects](<#APIObjects>) to produce the marshalled yaml representation from CUE data, then provide the result to [Component](<#Component>).
+
+```go
+type APIObjectMap map[Kind]map[InternalLabel]string
+```
+
+<a name="APIObjects"></a>
+## type APIObjects {#APIObjects}
+
+APIObjects represents Kubernetes API objects defined directly from CUE code. Useful to mix in resources to any kind of [Component](<#Component>), for example adding an ExternalSecret resource to a [HelmChart](<#HelmChart>).
+
+[Kind](<#Kind>) must be the resource kind, e.g. Deployment or Service.
+
+[InternalLabel](<#InternalLabel>) is an arbitrary internal identifier to uniquely identify the resource within the context of a \`holos\` command. Holos will never write the intermediate label to rendered output.
+
+Refer to [Component](<#Component>) which accepts an [APIObjectMap](<#APIObjectMap>) field provided by [APIObjects](<#APIObjects>).
+
+```go
+type APIObjects struct {
+    APIObjects   map[Kind]map[InternalLabel]APIObject `json:"apiObjects"`
+    APIObjectMap APIObjectMap                         `json:"apiObjectMap"`
+}
+```
+
+<a name="BuildPlan"></a>
+## type BuildPlan {#BuildPlan}
+
+BuildPlan represents a build plan for the holos cli to execute. The purpose of a BuildPlan is to define one or more [Component](<#Component>) kinds. For example a [HelmChart](<#HelmChart>), [KustomizeBuild](<#KustomizeBuild>), or [KubernetesObjects](<#KubernetesObjects>).
+
+A BuildPlan usually has an additional empty [KubernetesObjects](<#KubernetesObjects>) for the purpose of using the [Component](<#Component>) DeployFiles field to deploy an ArgoCD or Flux gitops resource for the holos component.
+
+```go
+type BuildPlan struct {
+    Kind       string        `json:"kind" cue:"\"BuildPlan\""`
+    APIVersion string        `json:"apiVersion" cue:"string | *\"v1alpha3\""`
+    Spec       BuildPlanSpec `json:"spec"`
+}
+```
+
+<a name="BuildPlanComponents"></a>
+## type BuildPlanComponents {#BuildPlanComponents}
+
+
+
+```go
+type BuildPlanComponents struct {
+    Resources             map[InternalLabel]KubernetesObjects `json:"resources,omitempty"`
+    KubernetesObjectsList []KubernetesObjects                 `json:"kubernetesObjectsList,omitempty"`
+    HelmChartList         []HelmChart                         `json:"helmChartList,omitempty"`
+    KustomizeBuildList    []KustomizeBuild                    `json:"kustomizeBuildList,omitempty"`
+}
+```
+
+<a name="BuildPlanSpec"></a>
+## type BuildPlanSpec {#BuildPlanSpec}
+
+BuildPlanSpec represents the specification of the build plan.
+
+```go
+type BuildPlanSpec struct {
+    // Disabled causes the holos cli to take no action over the [BuildPlan].
+    Disabled bool `json:"disabled,omitempty"`
+    // Components represents multiple [HolosComponent] kinds to manage.
+    Components BuildPlanComponents `json:"components,omitempty"`
+}
+```
+
+<a name="Chart"></a>
+## type Chart {#Chart}
+
+Chart represents a helm chart.
+
+```go
+type Chart struct {
+    // Name represents the chart name.
+    Name string `json:"name"`
+    // Version represents the chart version.
+    Version string `json:"version"`
+    // Release represents the chart release when executing helm template.
+    Release string `json:"release"`
+    // Repository represents the repository to fetch the chart from.
+    Repository Repository `json:"repository,omitempty"`
+}
+```
+
+<a name="Component"></a>
+## type Component {#Component}
+
+Component defines the fields common to all holos component kinds. Every holos component kind should embed Component.
+
+```go
+type Component struct {
+    // Kind is a string value representing the resource this object represents.
+    Kind string `json:"kind"`
+    // APIVersion represents the versioned schema of this representation of an object.
+    APIVersion string `json:"apiVersion" cue:"\"v1alpha3\""`
+    // Metadata represents data about the holos component such as the Name.
+    Metadata Metadata `json:"metadata"`
+
+    // APIObjectMap holds the marshalled representation of api objects.  Useful to
+    // mix in resources to each Component type, for example adding an
+    // ExternalSecret to a [HelmChart] Component.  Refer to [APIObjects].
+    APIObjectMap APIObjectMap `json:"apiObjectMap,omitempty"`
+
+    // DeployFiles represents file paths relative to the cluster deploy directory
+    // with the value representing the file content.  Intended for defining the
+    // ArgoCD Application resource or Flux Kustomization resource from within CUE,
+    // but may be used to render any file related to the build plan from CUE.
+    DeployFiles FileContentMap `json:"deployFiles,omitempty"`
+
+    // Kustomize represents a kubectl kustomize build post-processing step.
+    Kustomize `json:"kustomize,omitempty"`
+
+    // Skip causes holos to take no action regarding this component.
+    Skip bool `json:"skip" cue:"bool | *false"`
+}
+```
+
+<a name="FileContent"></a>
+## type FileContent {#FileContent}
+
+FileContent represents file contents.
+
+```go
+type FileContent string
+```
+
+<a name="FileContentMap"></a>
+## type FileContentMap {#FileContentMap}
+
+FileContentMap represents a mapping of file paths to file contents.
+
+```go
+type FileContentMap map[FilePath]FileContent
+```
+
+<a name="FilePath"></a>
+## type FilePath {#FilePath}
+
+FilePath represents a file path.
+
+```go
+type FilePath string
+```
+
+<a name="HelmChart"></a>
+## type HelmChart {#HelmChart}
+
+HelmChart represents a holos component which wraps around an upstream helm chart. Holos orchestrates helm by providing values obtained from CUE, renders the output using \`helm template\`, then post\-processes the helm output yaml using the general functionality provided by [Component](<#Component>), for example [Kustomize](<#Kustomize>) post\-rendering and mixing in additional kubernetes api objects.
+
+```go
+type HelmChart struct {
+    Component `json:",inline"`
+    Kind      string `json:"kind" cue:"\"HelmChart\""`
+
+    // Chart represents a helm chart to manage.
+    Chart Chart `json:"chart"`
+    // ValuesContent represents the values.yaml file holos passes to the `helm
+    // template` command.
+    ValuesContent string `json:"valuesContent"`
+    // EnableHooks enables helm hooks when executing the `helm template` command.
+    EnableHooks bool `json:"enableHooks" cue:"bool | *false"`
+}
+```
+
+<a name="InternalLabel"></a>
+## type InternalLabel {#InternalLabel}
+
+InternalLabel is an arbitrary unique identifier internal to holos itself. The holos cli is expected to never write a InternalLabel value to rendered output files, therefore use a [InternalLabel](<#InternalLabel>) when the identifier must be unique and internal. Defined as a type for clarity and type checking.
+
+A InternalLabel is useful to convert a CUE struct to a list, for example producing a list of [APIObject](<#APIObject>) resources from an [APIObjectMap](<#APIObjectMap>). A CUE struct using InternalLabel keys is guaranteed to not lose data when rendering output because a InternalLabel is expected to never be written to the final output.
+
+```go
+type InternalLabel string
+```
+
+<a name="Kind"></a>
+## type Kind {#Kind}
+
+Kind is a kubernetes api object kind. Defined as a type for clarity and type checking.
+
+```go
+type Kind string
+```
+
+<a name="KubernetesObjects"></a>
+## type KubernetesObjects {#KubernetesObjects}
+
+KubernetesObjects represents a [Component](<#Component>) composed of Kubernetes API objects provided directly from CUE using [APIObjects](<#APIObjects>).
+
+```go
+type KubernetesObjects struct {
+    Component `json:",inline"`
+    Kind      string `json:"kind" cue:"\"KubernetesObjects\""`
+}
+```
+
+<a name="Kustomize"></a>
+## type Kustomize {#Kustomize}
+
+Kustomize represents resources necessary to execute a kustomize build. Intended for at least two use cases:
+
+1. Process a [KustomizeBuild](<#KustomizeBuild>) [Component](<#Component>) which represents raw yaml file resources in a holos component directory.
+2. Post process a [HelmChart](<#HelmChart>) [Component](<#Component>) to inject istio, patch jobs, add custom labels, etc...
+
+```go
+type Kustomize struct {
+    // KustomizeFiles holds file contents for kustomize, e.g. patch files.
+    KustomizeFiles FileContentMap `json:"kustomizeFiles,omitempty"`
+    // ResourcesFile is the file name used for api objects in kustomization.yaml
+    ResourcesFile string `json:"resourcesFile,omitempty"`
+}
+```
+
+<a name="KustomizeBuild"></a>
+## type KustomizeBuild {#KustomizeBuild}
+
+KustomizeBuild represents a [Component](<#Component>) that renders plain yaml files in the holos component directory using \`kubectl kustomize build\`.
+
+```go
+type KustomizeBuild struct {
+    Component `json:",inline"`
+    Kind      string `json:"kind" cue:"\"KustomizeBuild\""`
+}
+```
+
+<a name="Metadata"></a>
+## type Metadata {#Metadata}
+
+Metadata represents data about the object such as the Name.
+
+```go
+type Metadata struct {
+    // Name represents the name of the holos component.
+    Name string `json:"name"`
+    // Namespace is the primary namespace of the holos component.  A holos
+    // component may manage resources in multiple namespaces, in this case
+    // consider setting the component namespace to default.
+    //
+    // This field is optional because not all resources require a namespace,
+    // particularly CRDs and DeployFiles functionality.
+    // +optional
+    Namespace string `json:"namespace,omitempty"`
+}
+```
+
+<a name="Platform"></a>
+## type Platform {#Platform}
+
+Platform represents a platform to manage. A Platform resource informs holos which components to build. The platform resource also acts as a container for the platform model form values provided by the PlatformService. The primary use case is to collect the cluster names, cluster types, platform model, and holos components to build into one resource.
+
+```go
+type Platform struct {
+    // Kind is a string value representing the resource this object represents.
+    Kind string `json:"kind" cue:"\"Platform\""`
+    // APIVersion represents the versioned schema of this representation of an object.
+    APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha3\""`
+    // Metadata represents data about the object such as the Name.
+    Metadata PlatformMetadata `json:"metadata"`
+
+    // Spec represents the specification.
+    Spec PlatformSpec `json:"spec"`
+}
+```
+
+<a name="PlatformMetadata"></a>
+## type PlatformMetadata {#PlatformMetadata}
+
+
+
+```go
+type PlatformMetadata struct {
+    // Name represents the Platform name.
+    Name string `json:"name"`
+}
+```
+
+<a name="PlatformSpec"></a>
+## type PlatformSpec {#PlatformSpec}
+
+PlatformSpec represents the specification of a Platform. Think of a platform specification as a list of platform components to apply to a list of kubernetes clusters combined with the user\-specified Platform Model.
+
+```go
+type PlatformSpec struct {
+    // Model represents the platform model holos gets from from the
+    // PlatformService.GetPlatform rpc method and provides to CUE using a tag.
+    Model structpb.Struct `json:"model" cue:"{...}"`
+    // Components represents a list of holos components to manage.
+    Components []PlatformSpecComponent `json:"components"`
+}
+```
+
+<a name="PlatformSpecComponent"></a>
+## type PlatformSpecComponent {#PlatformSpecComponent}
+
+PlatformSpecComponent represents a holos component to build or render.
+
+```go
+type PlatformSpecComponent struct {
+    // Path is the path of the component relative to the platform root.
+    Path string `json:"path"`
+    // Cluster is the cluster name to provide when rendering the component.
+    Cluster string `json:"cluster"`
+}
+```
+
+<a name="Repository"></a>
+## type Repository {#Repository}
+
+Repository represents a helm chart repository.
+
+```go
+type Repository struct {
+    Name string `json:"name"`
+    URL  string `json:"url"`
+}
+```
+
+Generated by [gomarkdoc](<https://github.com/princjef/gomarkdoc>)

doc/md/api/schema.md

@@ -0,0 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
+# Schema API
+
+<DocCardList />

doc/md/api/schema/v1alpha3.md

@@ -0,0 +1,213 @@
+<!-- Code generated by gomarkdoc. DO NOT EDIT -->
+
+# v1alpha3
+
+```go
+import "github.com/holos-run/holos/api/schema/v1alpha3"
+```
+
+Package v1alpha3 contains CUE definitions intended as convenience wrappers around the core data types defined in package core. The purpose of these wrappers is to make life easier for platform engineers by reducing boiler plate code and generating component build plans in a consistent manner.
+
+## Index
+
+- [type ArgoConfig](<#ArgoConfig>)
+- [type Cluster](<#Cluster>)
+- [type ComponentFields](<#ComponentFields>)
+- [type Fleet](<#Fleet>)
+- [type Helm](<#Helm>)
+- [type Kubernetes](<#Kubernetes>)
+- [type Kustomize](<#Kustomize>)
+- [type Platform](<#Platform>)
+- [type StandardFleets](<#StandardFleets>)
+
+
+<a name="ArgoConfig"></a>
+## type ArgoConfig {#ArgoConfig}
+
+ArgoConfig represents the ArgoCD GitOps configuration for a Component. Useful to define once at the root of the Platform configuration and reuse across all Components.
+
+```go
+type ArgoConfig struct {
+    // Enabled causes holos to render an ArgoCD Application resource for GitOps if true.
+    Enabled bool `cue:"true | *false"`
+    // ClusterName represents the cluster within the platform the Application
+    // resource is intended for.
+    ClusterName string
+    // DeployRoot represents the path from the git repository root to the `deploy`
+    // rendering output directory.  Used as a prefix for the
+    // Application.spec.source.path field.
+    DeployRoot string `cue:"string | *\".\""`
+    // RepoURL represents the value passed to the Application.spec.source.repoURL
+    // field.
+    RepoURL string
+    // TargetRevision represents the value passed to the
+    // Application.spec.source.targetRevision field.  Defaults to the branch named
+    // main.
+    TargetRevision string `cue:"string | *\"main\""`
+    // AppProject represents the ArgoCD Project to associate the Application with.
+    AppProject string `cue:"string | *\"default\""`
+}
+```
+
+<a name="Cluster"></a>
+## type Cluster {#Cluster}
+
+Cluster represents a cluster managed by the Platform.
+
+```go
+type Cluster struct {
+    // Name represents the cluster name, for example "east1", "west1", or
+    // "management".
+    Name string `json:"name"`
+    // Primary represents if the cluster is marked as the primary among a set of
+    // candidate clusters.  Useful for promotion of database leaders.
+    Primary bool `json:"primary" cue:"true | *false"`
+}
+```
+
+<a name="ComponentFields"></a>
+## type ComponentFields {#ComponentFields}
+
+Component represents the fields common the different kinds of component. All components have a name, support mixing in resources, and produce a BuildPlan.
+
+```go
+type ComponentFields struct {
+    // Name represents the Component name.
+    Name string
+    // Resources are kubernetes api objects to mix into the output.
+    Resources map[string]any
+    // ArgoConfig represents the ArgoCD GitOps configuration for this Component.
+    ArgoConfig ArgoConfig
+    // BuildPlan represents the derived BuildPlan for the Holos cli to render.
+    BuildPlan core.BuildPlan
+}
+```
+
+<a name="Fleet"></a>
+## type Fleet {#Fleet}
+
+Fleet represents a named collection of similarly configured Clusters. Useful to segregate workload clusters from their management cluster.
+
+```go
+type Fleet struct {
+    Name string `json:"name"`
+    // Clusters represents a mapping of Clusters by their name.
+    Clusters map[string]Cluster `json:"clusters" cue:"{[Name=_]: name: Name}"`
+}
+```
+
+<a name="Helm"></a>
+## type Helm {#Helm}
+
+Helm provides a BuildPlan via the Output field which contains one HelmChart from package core. Useful as a convenience wrapper to render a HelmChart with optional mix\-in resources and Kustomization post\-processing.
+
+```go
+type Helm struct {
+    ComponentFields `json:",inline"`
+
+    // Version represents the chart version.
+    Version string
+    // Namespace represents the helm namespace option when rendering the chart.
+    Namespace string
+
+    // Repo represents the chart repository
+    Repo struct {
+        Name string `json:"name"`
+        URL  string `json:"url"`
+    }
+
+    // Values represents data to marshal into a values.yaml for helm.
+    Values interface{} `cue:"{...}"`
+
+    // Chart represents the derived HelmChart for inclusion in the BuildPlan
+    // Output field value.  The default HelmChart field values are derived from
+    // other Helm field values and should be sufficient for most use cases.
+    Chart core.HelmChart
+
+    // EnableKustomizePostProcessor processes helm output with kustomize if true.
+    EnableKustomizePostProcessor bool `cue:"true | *false"`
+
+    // KustomizeFiles represents additional files to include in a Kustomization
+    // resources list.  Useful to patch helm output.  The implementation is a
+    // struct with filename keys and structs as values.  Holos encodes the struct
+    // value to yaml then writes the result to the filename key.  Component
+    // authors may then reference the filename in the kustomization.yaml resources
+    // or patches lists.
+    // Requires EnableKustomizePostProcessor: true.
+    KustomizeFiles map[string]any `cue:"{[string]: {...}}"`
+
+    // KustomizePatches represents patches to apply to the helm output.  Requires
+    // EnableKustomizePostProcessor: true.
+    KustomizePatches map[core.InternalLabel]any `cue:"{[string]: {...}}"`
+
+    // KustomizeResources represents additional resources files to include in the
+    // kustomize resources list.
+    KustomizeResources map[string]any `cue:"{[string]: {...}}"`
+}
+```
+
+<a name="Kubernetes"></a>
+## type Kubernetes {#Kubernetes}
+
+Kubernetes provides a BuildPlan via the Output field which contains inline API Objects provided directly from CUE.
+
+```go
+type Kubernetes struct {
+    ComponentFields `json:",inline"`
+    // Objects represents the kubernetes api objects for the Component.
+    Objects core.KubernetesObjects
+}
+```
+
+<a name="Kustomize"></a>
+## type Kustomize {#Kustomize}
+
+Kustomize provides a BuildPlan via the Output field which contains one KustomizeBuild from package core.
+
+```go
+type Kustomize struct {
+    ComponentFields `json:",inline"`
+    // Kustomization represents the kustomize build plan for holos to render.
+    Kustomization core.KustomizeBuild
+}
+```
+
+<a name="Platform"></a>
+## type Platform {#Platform}
+
+Platform is a convenience structure to produce a core Platform specification value in the Output field. Useful to collect components at the root of the Platform configuration tree as a struct, which are automatically converted into a list for the core Platform spec output.
+
+```go
+type Platform struct {
+    // Name represents the Platform name.
+    Name string `cue:"string | *\"holos\""`
+    // Components is a structured map of components to manage by their name.
+    Components map[string]core.PlatformSpecComponent
+    // Model represents the Platform model holos gets from from the
+    // PlatformService.GetPlatform rpc method and provides to CUE using a tag.
+    Model structpb.Struct `cue:"{...}"`
+    // Output represents the core Platform spec for the holos cli to iterate over
+    // and render each listed Component, injecting the Model.
+    Output core.Platform
+    // Domain represents the primary domain the Platform operates in.  This field
+    // is intended as a sensible default for component authors to reference and
+    // platform operators to define.
+    Domain string `cue:"string | *\"holos.localhost\""`
+}
+```
+
+<a name="StandardFleets"></a>
+## type StandardFleets {#StandardFleets}
+
+StandardFleets represents the standard set of Clusters in a Platform segmented into Fleets by their purpose. The management Fleet contains a single Cluster, for example a GKE autopilot cluster with no workloads deployed for reliability and cost efficiency. The workload Fleet contains all other Clusters which contain workloads and sync Secrets from the management cluster.
+
+```go
+type StandardFleets struct {
+    // Workload represents a Fleet of zero or more workload Clusters.
+    Workload Fleet `json:"workload" cue:"{name: \"workload\"}"`
+    // Management represents a Fleet with one Cluster named management.
+    Management Fleet `json:"management" cue:"{name: \"management\"}"`
+}
+```
+
+Generated by [gomarkdoc](<https://github.com/princjef/gomarkdoc>)

doc/md/archive/guides/try-holos/index.mdx

@@ -1,5 +1,6 @@
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
 
 # Try Holos Locally
 
@@ -29,7 +30,7 @@ definitions described in the [Glossary](/docs/glossary).
 
 You'll need the following tools installed to complete this guide.
 
-1. [holos](/docs/guides/install) - to build the platform.
+1. [holos](/docs/install) - to build the platform.
 2. [helm](https://helm.sh/docs/intro/install/) - to render Holos components that wrap upstream Helm charts.
 3. [k3d](https://k3d.io/#installation) - to provide a k8s api server.
 4. [OrbStack](https://docs.orbstack.dev/install) or [Docker](https://docs.docker.com/get-docker/) - to use k3d.
@@ -255,10 +256,9 @@ git add deploy
 git commit -m "holos render platform ./platform"
 ```
 
-:::important
+:::info[Don't blink, this is where Holos builds the platform]
 
-⚡ Don't blink, this is where Holos actually builds the platform.  It usually
-takes no more than a few seconds.
+It usually takes no more than a few seconds.
 
 Rendering the holos reference platform currently results in about 500K lines of
 yaml.  In contrast, roughly 80K lines are produced by this slimmed down k3d
@@ -271,6 +271,50 @@ all configuration into one single model.
 
 :::
 
+## Configure DNS {#DNS}
+
+Configure your machine to resolve `*.holos.localhost` to your loopback
+interface.  This is necessary for requests to reach the workload cluster.
+
+<Tabs>
+  <TabItem value="macos" label="macOS" default>
+  Cache sudo credentials.
+
+  Admin access is necessary to setup a local dnsmasq instance and configure
+  macOS's DNS resolver.
+
+  ```bash
+  sudo -v
+  ```
+
+  Resolve *.holos.localhost DNS queries to 127.0.0.1.
+
+  ```bash
+  bash ./scripts/local-dns
+  ```
+
+  </TabItem>
+  <TabItem value="linux" label="Linux">
+    [NSS-myhostname](http://man7.org/linux/man-pages/man8/nss-myhostname.8.html)
+    ships with many Linux distributions and should resolve *.localhost
+    automatically to 127.0.0.1.
+
+    Otherwise it is installable with:
+
+    ```bash
+    sudo apt install libnss-myhostname
+    ```
+  </TabItem>
+  <TabItem value="windows" label="Windows">
+    Ensure the loopback interface has at least the following names in `C:\windows\system32\drivers\etc\hosts`
+
+    ```
+    127.0.0.1 httpbin.holos.localhost app.holos.localhost
+    ```
+  </TabItem>
+</Tabs>
+
+
 ## Create the Cluster {#Create-Cluster}
 
 The Workload Cluster is where your applications and services will be deployed.
@@ -313,72 +357,39 @@ on GKE, EKS, Talos, k3s, and Kubeadm clusters.
 
 Traefik is disabled because Istio provides the same functionality.
 
-### Local CA {#Local-CA}
-
-Holos platforms use cert manager to issue tls certificates.  The browser and
-tools we're using need to trust these certificates to work together.  In this
-section we'll create a local trusted certificate authority.
-
-Admin access is necessary for `mkcert` to install the certificate into your
-trust stores.
-
-```bash
-sudo -v
-```
-
-```bash
-bash ./scripts/local-ca
-```
-
-### DNS Setup {#DNS}
-
-Configure your machine to resolve `*.holos.localhost` to your loopback
-interface.  This is necessary for requests to reach the workload cluster.
-
-<Tabs>
-  <TabItem value="macos" label="macOS" default>
-  Cache sudo credentials.
-
-  Admin access is necessary to setup a local dnsmasq instance and configure
-  macOS's DNS resolver.
-
-  ```bash
-  sudo -v
-  ```
-
-  Resolve *.holos.localhost DNS queries to 127.0.0.1.
-
-  ```bash
-  bash ./scripts/local-dns
-  ```
-
-  </TabItem>
-  <TabItem value="linux" label="Linux">
-    [NSS-myhostname](http://man7.org/linux/man-pages/man8/nss-myhostname.8.html)
-    ships with many Linux distributions and should resolve *.localhost
-    automatically to 127.0.0.1.
-
-    Otherwise it is installable with:
-
-    ```bash
-    sudo apt install libnss-myhostname
-    ```
-  </TabItem>
-  <TabItem value="windows" label="Windows">
-    Ensure the loopback interface has at least the following names in `C:\windows\system32\drivers\etc\hosts`
-
-    ```
-    127.0.0.1 httpbin.holos.localhost app.holos.localhost
-    ```
-  </TabItem>
-</Tabs>
-
 ## Apply the Platform Components {#Apply-Platform-Components}
 
 Use `kubectl` to apply each platform component.  In production, it's common to
 fully automate this process with ArgoCD, but we use `kubectl` to the same
 effect.
 
+### Local CA {#Local-CA}
+
+Holos platforms use cert manager to issue tls certificates.  The browser and
+tools we're using need to trust these certificates to work together.
+
+Admin access is necessary for `mkcert` to manage the certificate into your trust
+stores.
+
+```bash
+sudo -v
+```
+
+Manage the local CA and copy the CA key to the workload cluster so that cert
+manager can manage trusted certificates.
+
+```bash
+bash ./scripts/local-ca
+```
+
+:::warning
+
+Take care to run the local-ca script each time you create the workload cluster
+so that Certificates are issued correctly.
+
+:::
+
+
 ### Service Mesh
 
 The platform service mesh provides an ingress gateway and connectivity useful
@@ -415,8 +426,16 @@ certificate authority.
 kubectl -n cert-manager wait pod -l app.kubernetes.io/component=webhook --for=condition=Ready
 kubectl apply --server-side=true -f deploy/clusters/workload/components/local-ca
 kubectl apply --server-side=true -f deploy/clusters/workload/components/certificates
+kubectl -n istio-gateways wait certificate httpbin.holos.localhost --for=condition=Ready
 ```
 
+:::warning
+
+The certificate will time out before becoming ready if the [local-ca](#Local-CA)
+script was not run after the cluster was created.
+
+:::
+
 #### Istio {#Istio}
 
 Istio implements the Service Mesh.
@@ -443,7 +462,7 @@ kubectl apply --server-side=true -f deploy/clusters/workload/components/httpbin-
 kubectl -n holos-system wait pod -l app.kubernetes.io/instance=httpbin --for=condition=Ready
 ```
 
-:::important
+:::info
 
 Browse to [https://httpbin.holos.localhost/](https://httpbin.holos.localhost/)
 to verify end to end connectivity.  You should see the httpbin index page.
@@ -482,9 +501,17 @@ kubectl apply --server-side=true -f deploy/clusters/workload/components/authrout
 
 <Tabs groupId="registration">
   <TabItem value="registered" label="Signed In">
-    Verify authentication is working by visiting
+    <Admonition type="info">
+    Verify authentication is working by browsing to
     [https://httpbin.holos.localhost/holos/authproxy](https://httpbin.holos.localhost/holos/authproxy).
-    The auth proxy should respond with a simple `Authenticated` response.
+
+    We want a simple `Authenticated` response.
+
+      <Admonition type="tip">
+      You may need to refresh the page a few times while the platform configures
+      itself.
+      </Admonition>
+    </Admonition>
 
     Istio will respond with `no healthy upstream` until the pod becomes ready.
     Wait for the pod to become ready with:
@@ -495,7 +522,12 @@ kubectl apply --server-side=true -f deploy/clusters/workload/components/authrout
 
     Once authenticated, visit
     [https://httpbin.holos.localhost/holos/authproxy/userinfo](https://httpbin.holos.localhost/holos/authproxy/userinfo)
-    which returns a subset of claims from your id token:
+    which returns a subset of claims from your id token.
+
+    <Admonition type="warning">
+      If you get `Unauthorized` instead of a json response body, make sure you
+      [authenticated](https://httpbin.holos.localhost/holos/authproxy) first.
+    </Admonition>
 
     ```json
     {
@@ -504,7 +536,6 @@ kubectl apply --server-side=true -f deploy/clusters/workload/components/authrout
       "preferredUsername": "demo"
     }
     ```
-
   </TabItem>
   <TabItem value="unregistered" label="Signed Out">
     The auth proxy will always try to sign you in when you are signed out, so
@@ -640,10 +671,10 @@ foundation of a software development platform that:
 
 Dive deeper with the following resources that build on the foundation you have now.
 
- 1. Explore the [Rendering Process](/docs/design/rendering) in Holos.
+ 1. Explore the [Rendering Process](/docs/concepts#rendering) in Holos.
  2. Dive deeper into the [Platform Manifests](./platform-manifests) rendered in this guide.
- 3. Deploy [ArgoCD](/docs/guides/argocd) onto the foundation you built.
- 4. Deploy [Backstage](/docs/guides/backstage) as a portal to the integrated platform components.
+ 3. Deploy [ArgoCD](../argocd) onto the foundation you built.
+ 4. Deploy [Backstage](../backstage) as a portal to the integrated platform components.
 
 ## Clean-Up
 

doc/md/archive/guides/try-holos/platform-manifests.md

@@ -2,7 +2,7 @@
 
 This document provides an example of how Holos uses CUE and Helm to unify and
 render the platform configuration.  It refers to the manifests rendered in the
-[Try Holos Locally](/docs/guides/try-holos/) guide.
+Try Holos Locally guide.
 
 Take a moment to review the manifests `holos` rendered to build the platform.
 

doc/md/archive/local-development.md

@@ -2,7 +2,7 @@
 
 This document captures notes on locally developing Holos.
 
-Follow the steps in [Try Holos Locally](/docs/guides/try-holos), but take care
+Follow the steps in [Try Holos Locally](../guides/try-holos), but take care
 to select `Develop` tabs when creating the k3d cluster so you have a local
 registry to push to.
 

doc/md/backstory.md

@@ -0,0 +1,3 @@
+# Backstory
+
+Holos is a tool intended to lighten the burden of managing Kubernetes resources.  In 2020 we set out to develop a holistic platform composed from open source cloud native components.  We quickly became frustrated with how each of the major components packaged and distributed their software in a different way.  Many projects choose to distribute their software with Helm charts, while others provide plain yaml files and Kustomize bases.  The popular Kube Prometheus Stack project provides Jsonnet to render and update Kubernetes yaml manifests.

doc/md/design/rendering.md

@@ -1,47 +0,0 @@
-# Rendering
-
-:::tip
-
-This document provides a brief overview of the rendering process, a core design
-element in Holos.
-
-:::
-
-Holos uses the Kubernetes resource model to manage configuration.  The `holos`
-command line interface is the primary method you'll use to manage your platform.
-Holos uses CUE to provide a unified configuration model of the platform.  This
-unified configuration is built up from components packaged with Helm, Kustomize,
-CUE, or any other tool that can produce Kubernetes resource manifests as output.
-
-This process can be thought of as a data **rendering pipeline**.  The key
-concept is that `holos` will always produce fully rendered output, but delegates
-the _application_ of the configuration to other tools like `kubectl apply`,
-ArgoCD, or Flux.
-
-```mermaid
----
-title: Figure 2 - Render Pipeline
----
-graph LR
-    PS[<a href="/docs/api/core/v1alpha2#PlatformSpec">PlatformSpec</a>]
-    BP[<a href="/docs/api/core/v1alpha2#BuildPlan">BuildPlan</a>]
-    HC[<a href="/docs/api/core/v1alpha2#HolosComponent">HolosComponent</a>]
-
-    H[<a href="/docs/api/core/v1alpha2#HelmChart">HelmChart</a>]
-    K[<a href="/docs/api/core/v1alpha2#KustomizeBuild">KustomizeBuild</a>]
-    O[<a href="/docs/api/core/v1alpha2#KubernetesObjects">KubernetesObjects</a>]
-
-    P[<a href="/docs/api/core/v1alpha2#Kustomize">Kustomize</a>]
-    Y[Kubernetes <br>Resources]
-    G[GitOps <br>Resource]
-
-    C[Kube API Server]
-
-    PS --> BP --> HC
-    HC --> H --> P
-    HC --> K --> P
-    HC --> O --> P
-
-    P --> Y --> C
-    P --> G --> C
-```

doc/md/guides.md

@@ -0,0 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
+# Guides
+
+<DocCardList />

doc/md/guides/local-cluster.mdx

@@ -0,0 +1,277 @@
+---
+description: Build a local Cluster to use with these guides.
+slug: /guides/local-cluster
+sidebar_position: 300
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
+
+# Local Cluster
+
+In this guide we'll set up a local k3d cluster to apply and explore the
+configuration described in our other guides.  After completing this guide you'll
+have a standard Kubernetes API server with proper DNS and TLS certificates.
+You'll be able to easily reset the cluster to a known good state to iterate on
+your own Platform.
+
+The [Concepts](/docs/concepts) page defines capitalized terms such as Platform
+and Component.
+
+## Reset the Cluster
+
+If you've already followed this guide, reset the cluster by running the
+following commands.  Skip this section if you're creating a cluster for the
+first time.
+
+First, delete the cluster.
+
+<Tabs groupId="k3d-cluster-delete">
+  <TabItem value="command" label="Command">
+```bash
+k3d cluster delete workload
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt showLineNumbers
+INFO[0000] Deleting cluster 'workload'
+INFO[0000] Deleting cluster network 'k3d-workload'
+INFO[0000] Deleting 1 attached volumes...
+INFO[0000] Removing cluster details from default kubeconfig...
+INFO[0000] Removing standalone kubeconfig file (if there is one)...
+INFO[0000] Successfully deleted cluster workload!
+```
+  </TabItem>
+</Tabs>
+
+Then create the cluster again.
+
+<Tabs groupId="k3d-cluster-create">
+  <TabItem value="command" label="Command">
+```bash
+k3d cluster create workload \
+  --registry-use k3d-registry.holos.localhost:5100 \
+  --port "443:443@loadbalancer" \
+  --k3s-arg "--disable=traefik@server:0"
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt showLineNumbers
+INFO[0000] portmapping '443:443' targets the loadbalancer: defaulting to [servers:*:proxy agents:*:proxy]
+INFO[0000] Prep: Network
+INFO[0000] Created network 'k3d-workload'
+INFO[0000] Created image volume k3d-workload-images
+INFO[0000] Starting new tools node...
+INFO[0000] Starting node 'k3d-workload-tools'
+INFO[0001] Creating node 'k3d-workload-server-0'
+INFO[0001] Creating LoadBalancer 'k3d-workload-serverlb'
+INFO[0001] Using the k3d-tools node to gather environment information
+INFO[0001] HostIP: using network gateway 172.17.0.1 address
+INFO[0001] Starting cluster 'workload'
+INFO[0001] Starting servers...
+INFO[0001] Starting node 'k3d-workload-server-0'
+INFO[0003] All agents already running.
+INFO[0003] Starting helpers...
+INFO[0003] Starting node 'k3d-workload-serverlb'
+INFO[0009] Injecting records for hostAliases (incl. host.k3d.internal) and for 3 network members into CoreDNS configmap...
+INFO[0012] Cluster 'workload' created successfully!
+INFO[0012] You can now use it like this:
+kubectl cluster-info
+```
+  </TabItem>
+</Tabs>
+
+Finally, add your trusted certificate authority.
+
+<Tabs groupId="apply-local-ca">
+  <TabItem value="command" label="Command">
+```bash
+kubectl apply --server-side=true -f "$(mkcert -CAROOT)/namespace.yaml"
+kubectl apply --server-side=true -n cert-manager -f "$(mkcert -CAROOT)/local-ca.yaml"
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt showLineNumbers
+namespace/cert-manager serverside-applied
+secret/local-ca serverside-applied
+```
+  </TabItem>
+</Tabs>
+
+You're back to the same state as the first time you completed this guide.
+
+## What you'll need {#requirements}
+
+You'll need the following tools installed to complete this guide.
+
+1. [holos](/docs/install) - to build the platform.
+2. [helm](https://helm.sh/docs/intro/install/) - to render Holos components that wrap upstream Helm charts.
+3. [k3d](https://k3d.io/#installation) - to provide a k8s api server.
+4. [OrbStack](https://docs.orbstack.dev/install) or [Docker](https://docs.docker.com/get-docker/) - to use k3d.
+5. [kubectl](https://kubernetes.io/docs/tasks/tools/) - to interact with the k8s api server.
+6. [mkcert](https://github.com/FiloSottile/mkcert?tab=readme-ov-file#installation) - to make trusted TLS certificates.
+7. [jq](https://jqlang.github.io/jq/download/) - to fiddle with JSON output.
+
+## Configure DNS {#configure-dns}
+
+Configure your machine to resolve `*.holos.localhost` to your loopback
+interface.  This is necessary for requests to reach the workload cluster.  Save
+this script to a file and execute it.
+
+```bash showLineNumbers
+#! /bin/bash
+#
+
+set -euo pipefail
+
+tmpdir="$(mktemp -d)"
+finish() {
+  [[ -d "$tmpdir" ]] && rm -rf "$tmpdir"
+}
+trap finish EXIT
+cd "$tmpdir"
+
+brew install dnsmasq
+
+cat <<EOF >"$(brew --prefix)/etc/dnsmasq.d/holos.localhost.conf"
+# Refer to https://holos.run/docs/tutorial/local/k3d/
+address=/holos.localhost/127.0.0.1
+EOF
+
+if [[ -r /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist ]]; then
+  echo "dnsmasq already configured"
+else
+  sudo cp "$(brew list dnsmasq | grep 'dnsmasq.plist$')" \
+    /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
+  sudo launchctl unload /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
+  sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
+  dscacheutil -flushcache
+  echo "dnsmasq configured"
+fi
+
+sudo mkdir -p /etc/resolver
+sudo tee /etc/resolver/holos.localhost <<EOF
+domain holos.localhost
+nameserver 127.0.0.1
+EOF
+sudo killall -HUP mDNSResponder
+
+echo "all done."
+```
+
+## Create the Cluster {#create-the-cluster}
+
+The Workload Cluster is where your applications and services will be deployed.
+In production this is usually an EKS, GKE, or AKS cluster.
+
+:::tip
+
+Holos supports all compliant Kubernetes clusters. Holos was developed and tested
+on GKE, EKS, Talos, k3s, and Kubeadm clusters.
+
+:::
+
+Create a local registry to speed up image builds and pulls.
+
+```bash
+k3d registry create registry.holos.localhost --port 5100
+```
+
+Create the workload cluster configured to use the local registry.
+
+```bash
+k3d cluster create workload \
+  --registry-use k3d-registry.holos.localhost:5100 \
+  --port "443:443@loadbalancer" \
+  --k3s-arg "--disable=traefik@server:0"
+```
+
+Traefik is disabled because Istio provides the same functionality.
+
+## Setup Root CA {#setup-root-ca}
+
+Platforms most often use cert-manager to issue tls certificates.  The browser
+and tools we're using need to trust these certificates to work together.
+Generate a local, trusted root certificate authority with the following script.
+
+Admin access is necessary for `mkcert` to manage the certificate into your trust
+stores.
+
+```bash
+sudo -v
+```
+
+Manage the local CA and copy the CA key to the workload cluster so that cert
+manager can manage trusted certificates.
+
+Save this script to a file and execute it to configure a trusted certificate
+authority.
+
+```bash showLineNumbers
+#! /bin/bash
+#
+
+set -euo pipefail
+
+mkcert --install
+
+tmpdir="$(mktemp -d)"
+finish() {
+  [[ -d "$tmpdir" ]] && rm -rf "$tmpdir"
+}
+trap finish EXIT
+cd "$tmpdir"
+
+# Create the local CA Secret with ca.crt, tls.crt, tls.key
+
+mkdir local-ca
+cd local-ca
+CAROOT="$(mkcert -CAROOT)"
+cp -p "${CAROOT}/rootCA.pem" ca.crt
+cp -p "${CAROOT}/rootCA.pem" tls.crt
+cp -p "${CAROOT}/rootCA-key.pem" tls.key
+kubectl create secret generic --from-file=.  --dry-run=client -o yaml local-ca > ../local-ca.yaml
+echo 'type: kubernetes.io/tls' >> ../local-ca.yaml
+
+cd ..
+
+cat <<EOF > namespace.yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  labels:
+    kubernetes.io/metadata.name: cert-manager
+  name: cert-manager
+spec:
+  finalizers:
+  - kubernetes
+EOF
+kubectl apply --server-side=true -f namespace.yaml
+kubectl apply -n cert-manager --server-side=true -f local-ca.yaml
+
+# Save the Secret to easily reset the cluster later.
+install -m 0644 namespace.yaml "${CAROOT}/namespace.yaml"
+install -m 0600 local-ca.yaml "${CAROOT}/local-ca.yaml"
+```
+
+:::warning
+
+Take care to run the local-ca script each time you create the workload cluster
+so that Certificates are issued correctly.
+
+:::
+
+## Clean Up {#clean-up}
+
+If you'd like to clean up the resources you created in this guide, remove them
+with:
+
+```bash
+k3d cluster delete workload
+```
+
+## Next Steps
+
+Now that you have a real cluster, apply and explore the manifests Holos renders
+in the [Quickstart](/docs/quickstart) guide.

doc/md/guides/manage-a-project.mdx

@@ -0,0 +1,106 @@
+---
+description: Self service platform resource management for project teams.
+slug: /guides/manage-a-project
+sidebar_position: 200
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
+
+# Manage a Project
+
+In this guide we'll explore how Holos easily, safely, and consistently manages
+platform resources for teams to develop the projects they're working on.
+
+Intended Audience: Platform Engineers and Software Engineers.
+
+Goal is to demonstrate how the platform team can consistently, easily, and
+safely provide platform resources to software engineers.
+
+Assumption is software engineers have a container they want to deploy onto the
+platform and make accessible.  We'll use httpbin as a stand-in for the dev
+team's container.
+
+Project is roughly equivalent to Dev Team for the purpose of this guide, but in
+practice multiple teams work on a given project over the lifetime of the
+project, so we structure the files into projects instead of teams.
+
+## What you'll need {#requirements}
+
+You'll need the following tools installed to complete this guide.
+
+1. [holos](/docs/install) - to build the Platform.
+2. [helm](https://helm.sh/docs/intro/install/) - to render Helm Components.
+3. [kubectl](https://kubernetes.io/docs/tasks/tools/) - to render Kustomize Components.
+
+If you'd like to apply the manifests we render in this guide complete the
+following optional, but recommended, steps.
+
+a. Complete the [Local Cluster] guide to set up a local cluster to work with.
+b. You'll need a GitHub account to fork the repository associated with this
+guide.
+
+## Fork the Guide Repository
+
+<Tabs groupId="fork">
+  <TabItem value="command" label="Command">
+```bash
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt showLineNumbers
+```
+  </TabItem>
+</Tabs>
+
+This guide assumes you will run commands from the root directory of this
+repository unless stated otherwise.
+
+[Quickstart]: /docs/quickstart
+[Local Cluster]: /docs/guides/local-cluster
+
+## Render the Platform
+
+So we can build the basic platform.  Don't dwell on the platform bits.
+
+## Apply the Manifests
+
+Deploy ArgoCD, but not any of the Application resources.
+
+## Browse to ArgoCD
+
+Note there is nothing here yet.
+
+## Switch to your Fork
+
+Note all of the Applications change consistently.
+
+## Apply the Applications
+
+Note how ArgoCD takes over management, no longer need to k apply.
+
+## Create a Project
+
+Project is a conceptual, not technical, thing in Holos.  Mainly about how components are laid out in the filesystem tree.
+
+We use a schematic built into holos as an example, the platform team could use the same or provide a similar template and instructions for development teams to self-serve.
+
+## Render the Platform
+
+Notice:
+
+1. Project is registered with the platform at the root.
+2. HTTPRoute and Namespace resources are added close to the root in `projects`
+3. Deployment and Service resources are added at the leaf in `projects/httpbin/backend`
+
+## Update the image tag
+
+Add a basic schematic to demonstrate this.  May need to add two new flags for image url and image tag to the generate subcommand, but should just be two new fields on the struct.
+
+## Dive Deeper
+
+Set the stage for constraints.  Ideas: Limit what resources can be added,
+namespaces can be operated in, enforce labels, etc...
+
+Simple, consistent, easy constraints.

doc/md/guides/quickstart.mdx

@@ -0,0 +1,724 @@
+---
+description: Try Holos with this quick start guide.
+slug: /quickstart
+sidebar_position: 100
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
+
+# Quickstart
+
+In this guide, you'll experience how Holos makes the process of operating a
+Platform safer, easier, and more consistent. We'll use Holos to manage a
+vendor-provided Helm chart as a Component. Next, we'll mix in our own custom
+resources to manage the Component with GitOps. Finally, you'll see how Holos
+makes it safer and easier to maintain software over time by surfacing the exact
+changes that will be applied when upgrading the vendor's chart to a new version,
+before they are actually made.
+
+The [Concepts](/docs/concepts) page defines capitalized terms such as Platform
+and Component.
+
+## What you'll need {#requirements}
+
+You'll need the following tools installed to complete this guide.
+
+1. [holos](/docs/install) - to build the Platform.
+2. [helm](https://helm.sh/docs/intro/install/) - to render Holos Components that
+wrap upstream Helm charts.
+
+Optionally, if you'd like to apply the rendered manifests to a real Cluster,
+first complete the [Local Cluster Guide](/docs/guides/local-cluster).
+
+## Install Holos
+
+Install Holos with the following command or other methods listed on the
+[Installation](/docs/install/) page.
+
+```bash
+go install github.com/holos-run/holos/cmd/holos@latest
+```
+
+## Create a Git Repository
+
+Start by initializing an empty Git repository. Holos operates on local files
+stored in a Git repository.
+
+<Tabs groupId="init">
+  <TabItem value="command" label="Command">
+    ```bash
+    mkdir holos-quickstart
+    cd holos-quickstart
+    git init
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    Initialized empty Git repository in /holos-quickstart/.git/
+    ```
+  </TabItem>
+</Tabs>
+
+This guide assumes you will run commands from the root directory of the Git
+repository unless stated otherwise.
+
+## Generate the Platform {#Generate-Platform}
+
+Generate the Platform code in the repository root. A Platform refers to the
+entire set of software holistically integrated to provide a software development
+platform for your organization. In this guide, the Platform will include a
+single Component to demonstrate how the concepts fit together.
+
+```bash
+holos generate platform quickstart
+```
+
+Commit the generated platform config to the repository.
+
+<Tabs groupId="commit-platform">
+  <TabItem value="command" label="Command">
+    ```bash
+    git add .
+    git commit -m "holos generate platform quickstart - $(holos --version)"
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    [main (root-commit) 0b17b7f] holos generate platform quickstart
+     213 files changed, 72349 insertions(+)
+     ...
+    ```
+  </TabItem>
+</Tabs>
+
+## Generate a Component {#generate-component}
+
+The platform you generated is currently empty. Run the following command to
+generate the CUE code that defines a Helm Component.
+
+<Tabs groupId="gen-podinfo">
+  <TabItem value="command" label="Command">
+    ```bash
+    holos generate component podinfo --component-version 6.6.1
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    generated component
+    ```
+  </TabItem>
+</Tabs>
+
+The --component-version 6.6.1 flag intentionally installs an older release.
+You'll see how Holos assists with software upgrades later in this guide.
+
+The generate component command creates two files: a leaf file,
+`components/podinfo/podinfo.gen.cue`, and a root file, `podinfo.gen.cue`. Holos
+leverages the fact that [order is
+irrelevant](https://cuelang.org/docs/tour/basics/order-irrelevance/) in CUE to
+register the component with the Platform by adding a file to the root of the Git
+repository. The second file defines the component in the leaf component
+directory.
+
+<Tabs groupId="podinfo-files">
+  <TabItem value="components/podinfo/podinfo.gen.cue" label="Leaf">
+    `components/podinfo/podinfo.gen.cue`
+    ```cue showLineNumbers
+    package holos
+
+    // Produce a helm chart build plan.
+    (#Helm & Chart).Output
+
+    let Chart = {
+      Name:      "podinfo"
+      Version:   "6.6.1"
+      Namespace: "default"
+
+      Repo: name: "podinfo"
+      Repo: url:  "https://stefanprodan.github.io/podinfo"
+
+      Values: {}
+    }
+    ```
+  </TabItem>
+  <TabItem value="podinfo.gen.cue" label="Root">
+    `podinfo.gen.cue`
+    ```cue showLineNumbers
+    package holos
+
+    // Manage podinfo on workload clusters only
+    for Cluster in #Fleets.workload.clusters {
+      #Platform: Components: "\(Cluster.name)/podinfo": {
+        path:    "components/podinfo"
+        cluster: Cluster.name
+      }
+    }
+    ```
+  </TabItem>
+</Tabs>
+
+In this example, we provide the minimal information needed to manage the Helm
+chart: the name, version, Kubernetes namespace for deployment, and the chart
+repository location.
+
+This chart deploys cleanly without any values provided, but we include an empty
+Values struct to show how Holos improves consistency and safety in Helm by
+leveraging the strong type-checking in CUE. You can safely pass shared values,
+such as the organization’s domain name, to all Components across all clusters in
+the Platform by defining them at the root of the configuration.
+
+Commit the generated component config to the repository.
+
+<Tabs groupId="commit-component">
+  <TabItem value="command" label="Command">
+    ```bash
+    git add .
+    git commit -m "holos generate component podinfo - $(holos --version)"
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    [main cc0e90c] holos generate component podinfo
+     2 files changed, 24 insertions(+)
+     create mode 100644 components/podinfo/podinfo.gen.cue
+     create mode 100644 podinfo.gen.cue
+    ```
+  </TabItem>
+</Tabs>
+
+## Render the Component
+
+You can render individual components without adding them to a Platform, which is
+helpful when developing a new component.
+
+<Tabs groupId="render-podinfo">
+  <TabItem value="command" label="Command">
+    ```bash
+    holos render component ./components/podinfo --cluster-name=default
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    cached
+    rendered podinfo
+    ```
+  </TabItem>
+</Tabs>
+
+First, the command caches the Helm chart locally to speed up subsequent
+renderings. Then, the command runs Helm to produce the output and writes it into
+the deploy directory.
+
+<Tabs groupId="tree-podinfo">
+  <TabItem value="command" label="Command">
+    ```bash
+    tree deploy
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    deploy
+    └── clusters
+        └── default
+            └── components
+                └── podinfo
+                    └── podinfo.gen.yaml
+
+    5 directories, 1 file
+    ```
+  </TabItem>
+</Tabs>
+
+The component deploys to one cluster named `default`. In practice, the same
+component is often deployed to multiple clusters, such as `east` and `west` to
+provide redundancy and increase availability.
+
+:::tip
+This example is equivalent to running `helm template` on the chart and saving
+the output to a file. Holos simplifies this task, making it safer and more
+consistent when managing many charts.
+:::
+
+## Mix in an ArgoCD Application
+
+We've seen how Holos works with Helm, but we haven't yet explored how Holos
+makes it easier to consistently and safely manage all of the software in a
+Platform.
+
+Holos allows you to easily mix in resources that differentiate your Platform.
+We'll use this feature to mix in an ArgoCD [Application][application] to manage
+the podinfo Component with GitOps. We'll define this configuration in a way that
+can be automatically and consistently reused across all future Components added
+to the Platform.
+
+Create a new file named `argocd.cue` in the root of your Git repository with the
+following contents:
+
+<Tabs groupId="argocd-config">
+  <TabItem value="command" label="argocd.cue">
+    ```cue showLineNumbers
+    package holos
+
+    #ArgoConfig: {
+      Enabled: true
+      RepoURL: "https://github.com/holos-run/holos-quickstart-guide"
+    }
+    ```
+  </TabItem>
+</Tabs>
+
+:::tip
+If you plan to apply the rendered output to a real cluster, change the
+`example.com` RepoURL to the URL of the Git repository you created in this
+guide. You don't need to change the example if you're just exploring Holos by
+inspecting the rendered output without applying it to a live cluster.
+:::
+
+With this file in place, render the component again.
+
+<Tabs groupId="render-podinfo-argocd">
+  <TabItem value="command" label="Command">
+    ```bash
+    holos render component ./components/podinfo --cluster-name=default
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    wrote deploy file
+    rendered gitops/podinfo
+    rendered podinfo
+    ```
+  </TabItem>
+</Tabs>
+
+Holos uses the locally cached chart to improve performance and reliability. It
+then renders the Helm template output along with an ArgoCD Application resource
+for GitOps.
+
+:::tip
+By defining the ArgoCD configuration at the root, we again take advantage of the
+fact that [order is
+irrelevant](https://cuelang.org/docs/tour/basics/order-irrelevance/) in CUE.
+:::
+
+Defining the configuration at the root ensures all future leaf Components take
+the ArgoCD configuration and render an Application manifest for GitOps
+management.
+
+<Tabs groupId="tree-podinfo-argocd">
+  <TabItem value="command" label="Command">
+    ```bash
+    tree deploy
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    deploy
+    └── clusters
+        └── default
+            ├── components
+            │   └── podinfo
+            │       └── podinfo.gen.yaml
+            └── gitops
+                └── podinfo.application.gen.yaml
+
+    6 directories, 2 files
+    ```
+  </TabItem>
+</Tabs>
+
+Notice the new `podinfo.application.gen.yaml` file created by enabling ArgoCD in
+the Helm component. The Application resource in the file looks like this:
+
+<Tabs groupId="podinfo-application">
+  <TabItem value="file" label="podinfo.application.gen.yaml">
+    ```yaml showLineNumbers
+    apiVersion: argoproj.io/v1alpha1
+    kind: Application
+    metadata:
+      name: podinfo
+      namespace: argocd
+    spec:
+      destination:
+        server: https://kubernetes.default.svc
+      project: default
+      source:
+        path: ./deploy/clusters/default/components/podinfo
+        repoURL: https://example.com/holos-quickstart.git
+        targetRevision: main
+    ```
+  </TabItem>
+</Tabs>
+
+:::tip
+Holos generates a similar Application resource for every additional Component
+added to your Platform.
+:::
+
+Finally, add and commit the results to your Platform's Git repository.
+
+<Tabs groupId="commit-argo">
+  <TabItem value="command" label="Command">
+    ```bash
+    git add .
+    git commit -m "holos render component ./components/podinfo --cluster-name=default"
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    [main f95cef1] holos render component ./components/podinfo --cluster-name=default
+     3 files changed, 134 insertions(+)
+     create mode 100644 argocd.cue
+     create mode 100644 deploy/clusters/default/components/podinfo/podinfo.gen.yaml
+     create mode 100644 deploy/clusters/default/gitops/podinfo.application.gen.yaml
+    ```
+  </TabItem>
+</Tabs>
+
+In this section, we learned how Holos simplifies mixing resources into
+Components, like an ArgoCD Application. Holos ensures consistency by managing an
+Application resource for every Component added to the Platform through the
+configuration you define in `argocd.cue` at the root of the repository.
+
+## Define Workload Clusters {#workload-clusters}
+
+We've generated a Component to manage podinfo and integrated it with our
+Platform, but rendering the Platform doesn't render podinfo. Podinfo isn't
+rendered because we haven't assigned any Clusters to the workload Fleet.
+
+Define two new clusters, `east` and `west`, and assign them to the workload
+Fleet. Create a new file named `clusters.cue` in the root of your Git repository
+with the following contents:
+
+<Tabs groupId="clusters">
+  <TabItem value="clusters.cue" label="clusters.cue">
+    ```cue showLineNumbers
+    package holos
+
+    // Define two workload clusters for disaster recovery.
+    #Fleets: workload: clusters: {
+      // In CUE _ indicates values are defined elsewhere.
+      east: _
+      west: _
+    }
+    ```
+  </TabItem>
+</Tabs>
+
+This example shows how Holos simplifies configuring multiple clusters with
+similar configuration by grouping them into a Fleet.
+
+:::tip
+Fleets help segment a group of Clusters into one leader and multiple followers
+by designating one cluster as the primary. Holos makes it safer, easier, and
+more consistent to reconfigure which cluster is the primary. The primary can be
+set to automatically restore persistent data from backups, while non-primary
+clusters can be configured to automatically replicate from the primary.
+
+Automatic database backup, restore, and streaming replication is an advanced
+topic enabled by Cloud Native PG and CUE. Check back for a guide on this and
+other Day 2 operations topics.
+:::
+
+## Render the Platform {#render-platform}
+
+Render the Platform to render the podinfo Component for each of the workload
+clusters.
+
+<Tabs groupId="render-platform">
+  <TabItem value="command" label="Command">
+    ```bash
+    holos render platform ./platform
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    rendered components/podinfo for cluster west in 99.480792ms
+    rendered components/podinfo for cluster east in 99.882667ms
+    ```
+  </TabItem>
+</Tabs>
+
+The render platform command iterates over every Cluster in the Fleet and renders
+each Component assigned to the Fleet. Notice the two additional subdirectories
+created under the deploy directory, one for each cluster: `east` and `west`.
+
+<Tabs groupId="tree-platform">
+  <TabItem value="command" label="Command">
+    ```bash
+    tree deploy
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    deploy
+    └── clusters
+        ├── default
+        │   ├── components
+        │   │   └── podinfo
+        │   │       └── podinfo.gen.yaml
+        │   └── gitops
+        │       └── podinfo.application.gen.yaml
+        # highlight-next-line
+        ├── east
+        │   ├── components
+        │   │   └── podinfo
+        │   │       └── podinfo.gen.yaml
+        │   └── gitops
+        │       └── podinfo.application.gen.yaml
+        # highlight-next-line
+        └── west
+            ├── components
+            │   └── podinfo
+            │       └── podinfo.gen.yaml
+            └── gitops
+                └── podinfo.application.gen.yaml
+
+    14 directories, 6 files
+    ```
+  </TabItem>
+</Tabs>
+
+Holos ensures consistency and safety by defining the ArgoCD Application once,
+with strong type checking, at the configuration root.
+
+New Application resources are automatically generated for the `east` and `west`
+workload Clusters.
+
+<Tabs groupId="applications">
+  <TabItem value="east" label="east">
+  `deploy/clusters/east/gitops/podinfo.application.gen.yaml`
+```yaml showLineNumbers
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: podinfo
+  namespace: argocd
+spec:
+  destination:
+    server: https://kubernetes.default.svc
+  project: default
+  source:
+    # highlight-next-line
+    path: ./deploy/clusters/east/components/podinfo
+    repoURL: https://example.com/holos-quickstart.git
+    targetRevision: main
+```
+  </TabItem>
+  <TabItem value="west" label="west">
+  `deploy/clusters/west/gitops/podinfo.application.gen.yaml`
+```yaml showLineNumbers
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: podinfo
+  namespace: argocd
+spec:
+  destination:
+    server: https://kubernetes.default.svc
+  project: default
+  source:
+    # highlight-next-line
+    path: ./deploy/clusters/west/components/podinfo
+    repoURL: https://example.com/holos-quickstart.git
+    targetRevision: main
+```
+  </TabItem>
+  <TabItem value="default" label="default">
+  `deploy/clusters/default/gitops/podinfo.application.gen.yaml`
+```yaml showLineNumbers
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: podinfo
+  namespace: argocd
+spec:
+  destination:
+    server: https://kubernetes.default.svc
+  project: default
+  source:
+    # highlight-next-line
+    path: ./deploy/clusters/default/components/podinfo
+    repoURL: https://example.com/holos-quickstart.git
+    targetRevision: main
+```
+  </TabItem>
+</Tabs>
+
+Add and commit the rendered Platform and workload Clusters.
+
+<Tabs groupId="commit-render-platform">
+  <TabItem value="command" label="Command">
+    ```bash
+    git add .
+    git commit -m "holos render platform ./platform - $(holos --version)"
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    [main 5aebcf5] holos render platform ./platform - 0.93.2
+     5 files changed, 263 insertions(+)
+     create mode 100644 clusters.cue
+     create mode 100644 deploy/clusters/east/components/podinfo/podinfo.gen.yaml
+     create mode 100644 deploy/clusters/east/gitops/podinfo.application.gen.yaml
+     create mode 100644 deploy/clusters/west/components/podinfo/podinfo.gen.yaml
+     create mode 100644 deploy/clusters/west/gitops/podinfo.application.gen.yaml
+    ```
+  </TabItem>
+</Tabs>
+
+## Upgrade a Helm Chart
+
+Holos is designed to ease the burden of Day 2 operations. With Holos, upgrading
+software, integrating new software, and making safe platform-wide configuration
+changes become easier.
+
+Let's upgrade the podinfo Component to see how this works in practice. First,
+update the Component version field to the latest upstream Helm chart version.
+
+<Tabs groupId="gen-podinfo">
+  <TabItem value="command" label="Command">
+    ```bash
+    holos generate component podinfo --component-version 6.6.2
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    generated component
+    ```
+  </TabItem>
+</Tabs>
+
+Remove the cached chart version.
+
+<Tabs groupId="gen-podinfo">
+  <TabItem value="command" label="Command">
+    ```bash
+    rm -rf components/podinfo/vendor
+    ```
+  </TabItem>
+</Tabs>
+
+Now re-render the Platform.
+
+<Tabs groupId="render-platform2">
+  <TabItem value="command" label="Command">
+    ```bash
+    holos render platform ./platform
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    rendered components/podinfo for cluster east in 327.10475ms
+    rendered components/podinfo for cluster west in 327.796541ms
+    ```
+  </TabItem>
+</Tabs>
+
+Notice we're still using the upstream chart without modifying it. The Holos
+component wraps around the chart to mix in additional resources and integrate
+the component with the broader Platform.
+
+## Visualize the Changes
+
+Holos makes it easier to see exactly what changes are made and which resources
+will be applied to the API server. By design, Holos operates on local files,
+leaving the task of applying them to ecosystem tools like `kubectl` and ArgoCD.
+This allows platform operators to inspect changes during code review, or before
+committing the change at all.
+
+For example, using `git diff`, we see that the only functional change when
+upgrading this Helm chart is the deployment of a new container image tag to each
+cluster.  Additionally, we can roll out this change gradually by applying it to
+the east cluster first, then to the west cluster, limiting the potential blast
+radius of a problematic change.
+
+<Tabs groupId="git-diff">
+  <TabItem value="command" label="Command">
+    ```bash
+    git diff deploy/clusters/east
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```diff showLineNumbers
+diff --git a/deploy/clusters/east/components/podinfo/podinfo.gen.yaml b/deploy/clusters/east/components/podinfo/podinfo.gen.yaml
+index 7cc3332..8c1647d 100644
+--- a/deploy/clusters/east/components/podinfo/podinfo.gen.yaml
++++ b/deploy/clusters/east/components/podinfo/podinfo.gen.yaml
+@@ -5,9 +5,9 @@ kind: Service
+ metadata:
+   name: podinfo
+   labels:
+-    helm.sh/chart: podinfo-6.6.1
++    helm.sh/chart: podinfo-6.6.2
+     app.kubernetes.io/name: podinfo
+-    app.kubernetes.io/version: "6.6.1"
++    app.kubernetes.io/version: "6.6.2"
+     app.kubernetes.io/managed-by: Helm
+ spec:
+   type: ClusterIP
+@@ -29,9 +29,9 @@ kind: Deployment
+ metadata:
+   name: podinfo
+   labels:
+-    helm.sh/chart: podinfo-6.6.1
++    helm.sh/chart: podinfo-6.6.2
+     app.kubernetes.io/name: podinfo
+-    app.kubernetes.io/version: "6.6.1"
++    app.kubernetes.io/version: "6.6.2"
+     app.kubernetes.io/managed-by: Helm
+ spec:
+   replicas: 1
+@@ -53,7 +53,7 @@ spec:
+       terminationGracePeriodSeconds: 30
+       containers:
+         - name: podinfo
+         # highlight-next-line
+-          image: "ghcr.io/stefanprodan/podinfo:6.6.1"
+         # highlight-next-line
++          image: "ghcr.io/stefanprodan/podinfo:6.6.2"
+           imagePullPolicy: IfNotPresent
+           command:
+             - ./podinfo
+```
+  </TabItem>
+</Tabs>
+
+:::tip
+Holos is designed to surface the _fully rendered_ manifests intended for the
+Kubernetes API server, making it easier to see and reason about platform-wide
+configuration changes.
+:::
+
+## Recap {#recap}
+
+In this quickstart guide, we learned how Holos makes it easier, safer, and more
+consistent to manage a Platform composed of multiple Clusters and upstream Helm
+charts.
+
+We covered how to:
+
+1. Generate a Git repository for the Platform config.
+2. Wrap the unmodified upstream podinfo Helm chart into a Component.
+3. Render an individual Component.
+4. Mix-in your Platform's unique resources to all Components.  For example, ArgoCD Application resources.
+5. Define multiple similar, but not identical, workload clusters.
+6. Render the manifests for the entire Platform with the `holos render platform` command.
+7. Upgrade a Helm chart to the latest version as an important Day 2 task.
+8. Visualize and surface the details of planned changes Platform wide.
+
+## Dive Deeper
+
+If you'd like to dive deeper, check out the [Schema API][schema] and [Core
+API][core] reference docs. The main difference between the schema and core
+packages is that the schema is used by users to write refined CUE, while the
+core package is what the schema produces for `holos` to execute. Users rarely
+need to interact with the Core API when on the happy path, but can use the core
+package as an escape hatch when the happy path doesn't go where you want.
+
+
+[application]: https://argo-cd.readthedocs.io/en/stable/user-guide/application-specification/
+[schema]: /docs/api/schema/v1alpha3/
+[core]: /docs/api/core/v1alpha3/

doc/md/introduction.md

@@ -0,0 +1,10 @@
+---
+description: Holos Documentation
+slug: /
+---
+
+# Introduction
+
+:::warning TODO
+See [introduction](https://github.com/facebook/docusaurus/blob/main/website/docs/introduction.mdx?plain=1)
+:::

doc/md/runbooks/deploy.md

@@ -0,0 +1,31 @@
+# Deployment
+
+This document describes how deployment from `main` is configured.
+
+1. Refer to the publish workflow.
+2. Uses a SSH deploy key to:
+3. Clone the holos-infra repo.
+4. Write the image tag to saas/userdata/components/dev-holos-app/images.json
+5. Run holos render platform ./platform
+6. Commit and push the results.
+7. ArgoCD takes over the rollout.
+
+## Credentials
+
+TODO: Lock this down more, the deploy key has too much access to the infra
+repository.
+
+```bash
+mkdir -p tmp
+cd tmp
+ssh-keygen -t ed25519 -f holos-infra.key -m pem -C holos-run/holos -N ''
+gh secret set DEPLOY_SSH_PRIVATE_KEY < holos-infra.key
+gh api --method POST \
+  -H "Accept: application/vnd.github+json" \
+  /repos/holos-run/holos-infra/keys \
+  -f title='holos-run/holos deploy key' \
+  -f key="$(cat holos-infra.key.pub)" \
+  -F read_only=false
+cd ..
+rm -rf tmp
+```

doc/md/start.md

@@ -0,0 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
+# Get Started
+
+<DocCardList />

doc/md/start/comparison.md

@@ -0,0 +1,70 @@
+---
+description: Compare Holos with other tools in the ecosystem.
+slug: /comparison
+sidebar_position: 300
+---
+
+# Comparison
+
+:::tip
+Holos is designed to complement and improve, not replace, existing tools in the
+cloud native ecosystem.
+:::
+
+## Helm
+
+### Chart Users
+
+Describe how things are different when using an upstream helm chart.
+
+### Chart Authors
+
+Describe how things are different when writing a new helm chart.
+
+## Kustomize
+
+TODO
+
+## ArgoCD
+
+TODO
+
+## Flux
+
+TODO
+
+## Timoni
+
+| Aspect     | Timoni               | Holos                | Comment                                                                                  |
+| ---------- | -------------------- | -------------------- | ---------------------------------------------------------------------------------------- |
+| Language   | CUE                  | CUE                  | Like Holos, Timoni is also built on CUE.                                                 |
+| Artifact   | OCI Image            | Plain YAML Files     | The Holos Authors find plain files easier to work with and reason about than OCI images. |
+| Outputs to | OCI Image Repository | Local Git repository | Holos is designed for use with existing GitOps tools.                                    |
+| Concept    | Module               | Component            | A Timoni Module is analogous to a Holos Component.                                       |
+| Concept    | Bundle               | Platform             | A Timoni Bundle is somewhat similar, but smaller in scope to a Holos Platform.           |
+
+:::important
+
+The Holos Authors are deeply grateful to Stefan and Timoni for the capability of
+importing Kubernetes custom resource definitions into CUE.  Without this
+functionality, much of the Kubernetes ecosystem would be more difficult to
+manage in CUE and therefore in Holos.
+
+:::
+
+
+## KubeVela
+
+1. Also built on CUE.
+2. Intended to create an Application abstraction.
+3. Holos prioritizes composition over abstraction.
+4. An abstraction of an Application acts as a filter that removes all but the lowest common denominator functionality.  The Holos Authors have found this filtering effect to create excessive friction for software developers.
+5. Holos focuses instead on composition to empower developers and platform engineers to leverage the unique features and functionality of their software and platform.
+
+## Pulumi
+
+TODO
+
+## Jsonnet
+
+TODO

doc/md/start/concepts.md

@@ -0,0 +1,370 @@
+---
+description: Learn the concepts and domain language Holos uses.
+slug: /concepts
+sidebar_position: 200
+---
+
+# Concepts
+
+## Introduction
+
+This page is intended as a high level conceptual overview of the key concepts in
+Holos.  Refer to the [Core API](/docs/api/core/) for low level reference
+documentation.
+
+Holos is a tool built for platform engineers.  The Holos authors share three
+core values which guide our design decisions for the tool.
+
+1. Safety
+2. Ease of use
+3. Consistency
+
+Each of the following concepts are intended to support and strengthen one or
+more of these core values.  In this way we hope to lighten the burden carried by
+platform engineers.
+
+## Concepts
+
+- [Component](<#component>) - The primary building block in Holos, wraps a Helm chart, Kustomize base, or plain resources defined in CUE.
+- [Platform](<#platform>) - A collection of Components integrated into a software development platform.
+- [Model](<#model>) - Structured data included in the Platform specification, available to all Components.  For example, your organization's domain name.
+- [Rendering](<#rendering>) - Holos is a tool that makes the process of rendering Kubernetes manifests safer, easier, and consistent.
+- [Cluster](<#cluster>) - A Kubernetes cluster.  Components are rendered for and applied to a Cluster.
+- [Fleet](<#fleet>) - A collection of Clusters with a similar purpose.  A Platform is typically composed of two Fleets, one for management the second for workloads.
+
+```mermaid
+graph TB
+    Platform[<a href="#platform">Platform</a>]
+    Cluster[<a href="#cluster">Cluster</a>]
+    Fleet[<a href="#fleet">Fleet</a>]
+    Component[<a href="#component">Component</a>]
+    Helm[<a href="#component">Helm</a>]
+    Kustomize[<a href="#component">Kustomize</a>]
+    CUE[<a href="#component">CUE</a>]
+
+    Cluster --> Platform
+    Fleet --> Cluster
+    Component --> Fleet
+    Helm --> Component
+    Kustomize --> Component
+    CUE --> Component
+```
+
+:::tip
+This graph is organized as a tree.  We often say configuration at the root
+defines the broad Platform.  Configuration at a leaf defines a Component of the
+Platform.  The concept of a tree also reflects the filesystem organization of
+the configuration.
+:::
+
+<!--
+
+```mermaid
+---
+title: Figure 1 - Holos Concepts
+---
+mindmap
+  root((Holos))
+    Platform
+      Components
+        HelmChart
+        KustomizeBuild
+        KubernetesObjects
+      Model
+        name: Example Org
+        domain: example.com
+    Renders
+      YAML Files
+        Kubernetes Manifests
+        ArgoCD Application
+        FluxCD Kustomization
+```
+
+-->
+
+
+## Component
+
+A Component is the primary building block when managing software with Holos.  A
+software project you wish to integrate into your platform, for example ArgoCD,
+is managed using one or more components.
+
+The primary Component kinds are:
+
+1. **HelmChart** to render config provided by Helm.
+2. **KustomizeBuild** to render config provided by Kustomize.
+3. **KubernetesObjects** to render config provided by CUE.
+
+Components are intended to integrate unmodified upstream software releases into
+your Platform.  In this way, the focus of a Component is more about the unique
+differentiating aspects of your platform than the upstream software contained in
+the Component.
+
+#### Example HelmChart Component
+
+The ArgoCD Component is a good example of a HelmChart component because it takes
+advantage of most of the key features that empower you to focus on the key
+differentiators of your unique platform.
+
+Take note of the following key points in this example ArgoCD Component:
+
+1. The Component wraps the ArgoCD Helm Chart in a way that's easy to upgrade and maintain over time.
+2. Newer Gateway API resources are mixed-in replacing the older Ingress resource included in the chart.
+3. Helm output is passed through Kustomize to configure secure mutual TLS encryption.
+4. Helm values are easier and safer to manipulate with CUE instead of text markup.
+5. Kustomize is easier and safer to manipulate with CUE instead of text markup.
+6. Platform data Model values are easily accessible, for example the OIDC issuer and the organizations's domain name.
+
+The Component wraps around the unmodified upstream ArgoCD helm chart
+providing easier upgrades as new versions are released.
+
+Note how the Component facilitates composition by allowing us to mix-in new
+functionality from the ecosystem without modifying the upstream chart.  The
+Platform this Component integrates with uses the new Gateway API, but the
+upstream helm chart does not yet support Gateway API.  See how the Resources
+field is used to mix-in a ReferenceGrant from the Gateway API without modifying
+the upstream helm chart.
+
+The Platform uses Istio to implement service to service encryption with mutual
+TLS.  The Component passes the Helm output to Kustomize to integrate with Istio.
+Kustomize is used to patch the argocd-server Deployment resource to inject the
+Istio sidecar for mutual TLS.
+
+Helm values are safer and easier to work with in CUE.  Note how you can modify
+helm values using well defined data instead of manipulating text yaml files.
+Similarly, the yaml files used for Kustomize are produced by CUE, which is again
+safer and easier because the Kustomize spec has been imported into CUE and is
+validated.
+
+Finally, the domain name used by this Platform is easily accessible from the
+PlatformSpec which is defined at the root level and made available to all
+components integrated into the platform.  Similarly, data values shared by all
+of the Components that make up ArgoCD is defined in a structure accessible by
+each of these components.
+
+```cue
+package holos
+
+import (
+	"encoding/yaml"
+	"strings"
+)
+
+// Produce a helm chart build plan.
+(#Helm & Chart).Output
+
+let Chart = {
+	Name:      "argo-cd"
+	Namespace: "argocd"
+	Version:   "7.1.1"
+
+	Chart: chart: release: "argocd"
+
+	// The upstream chart uses a Job to create the argocd-redis Secret.  Enable
+	// hooks to enable the Job.
+	Chart: enableHooks: true
+
+	Repo: name: "argocd"
+	Repo: url:  "https://argoproj.github.io/argo-helm"
+
+	// Ensure all of our mix-in resources go into the same namespace as the Chart.
+	Resources: [_]: [_]: metadata: namespace: Namespace
+
+	// Grant the Gateway namespace the ability to refer to the backend service
+	// from HTTPRoute resources.
+	Resources: ReferenceGrant: (#IstioGatewaysNamespace): #ReferenceGrant
+
+	// Pass the helm output through kustomize.
+	EnableKustomizePostProcessor: true
+
+	// Force all resources into the component namespace, some resources in the
+	// helm chart do not specify the namespace so they will get mis-applied
+	// when the kubectl (client-go) context is another namespace.
+	KustomizeFiles: "kustomization.yaml": namespace: Namespace
+
+	// Patch the backend with the service mesh sidecar.
+	KustomizePatches: {
+		mesh: {
+			target: {
+				group:   "apps"
+				version: "v1"
+				kind:    "Deployment"
+				name:    "argocd-server"
+			}
+			patch: yaml.Marshal(IstioInject)
+		}
+	}
+
+	Values: #Values & {
+		kubeVersionOverride: "1.29.0"
+		// handled in the argo-crds component
+		crds: install:  false
+		global: domain: "argocd.\(_Platform.Model.org.domain)"
+		dex: enabled:   false
+		// the service mesh handles secure mTLS
+		configs: params: "server.insecure": true
+		configs: cm: {
+			"admin.enabled":           false
+			"oidc.config":             yaml.Marshal(OIDCConfig)
+			"users.anonymous.enabled": "false"
+		}
+
+		// Refer to https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/
+		let Policy = [
+			"g, argocd-view, role:readonly",
+			"g, prod-cluster-view, role:readonly",
+			"g, prod-cluster-edit, role:readonly",
+			"g, prod-cluster-admin, role:admin",
+		]
+
+		configs: rbac: "policy.csv": strings.Join(Policy, "\n")
+	}
+}
+
+let IstioInject = [{
+	op:    "add",
+	path:  "/spec/template/metadata/labels/sidecar.istio.io~1inject",
+	value: "true",
+}]
+
+let OIDCConfig = {
+	name:            "Holos Platform"
+	issuer:          _ArgoCD.issuerURL
+	clientID:        _ArgoCD.clientID
+	requestedScopes: _ArgoCD.scopesList
+	// Set redirect uri to https://argocd.example.com/pkce/verify
+	enablePKCEAuthentication: true
+	// groups is essential for rbac
+	requestedIDTokenClaims: groups: essential: true
+}
+```
+
+## Platform
+
+A Platform refers to all of the software and services integrated together to
+provide your organization's software development platform.  Holos is designed to
+manage all of the resources that compose your Platform using the [Kubernetes
+Resource Model][krm] (KRM).  Nearly all platforms are larger than Kubernetes
+itself.  For example, your developers likely need a GCS or S3 bucket to store
+data.  Holos takes advantage of Crossplane to manage resources in a consistent
+way.
+
+Holos defines a [Platform][Platform] object which collects multiple Components
+together along with organizational data defined by your Model.  Consider the
+following example, which is a Platform that manages a single Component which
+manages namespaces for each cluster in the Platform.
+
+```cue
+package holos
+
+import v1 "github.com/holos-run/holos/api/v1alpha2"
+
+v1.#Platform & {
+	metadata: name: "example"
+
+	spec: components: [{
+		path:    "components/namespaces"
+		cluster: "cluster1"
+	}]
+}
+```
+
+This platform is rendered by the command:
+
+```bash
+holos render platform ./platform
+```
+
+When Holos renders the platform, it iterates over each component, generates and
+executes a [BuildPlan][BuildPlan], then writes the fully rendered output of the
+component to the filesystem.  In this simple example, two files are produced:
+
+1. `deploy/clusters/cluster1/components/namespaces/namespaces.gen.yaml`
+2. `deploy/clusters/cluster1/gitops/namespaces.application.gen.yaml`
+
+The first file is a plain kubernetes manifest containing Namespace resources.
+The second file is an ArgoCD Application resource to deploy and manage the
+resources defined in the first file.
+
+## Model
+
+The Platform Model is where you store top-level data values used throughout
+multiple components in your Platform.  Your organization's domain name is a
+prime example of the kind of data stored in the Model.  Many components derive
+host names from your organization's domain name.  CUE makes this process safe,
+easy, and consistent.  For example:
+
+```cue
+hostname: "argocd.\(_Platform.Model.org.domain)"
+```
+
+When Holos renders a Platform, the model is loaded from a JSON file in the local
+filesystem.  The platform model file is intended to be committed to version
+control along with the rest of the Holos Platform and Component code.
+
+Holos additionally provides a web ui and form to make it easy to enter and
+validate top level configuration data.  You have complete control over the web
+form, it's rendered from JSON data defined by CUE.  Customizing the web form is
+an advanced topic, the key concept to take away is the Model is for top level,
+platform-wide data.  You control the shape and structure of the Model, and you
+have the ability to collect Model values using a simple web form.
+
+## Rendering
+
+Holos uses the Kubernetes resource model to manage configuration.  The Holos
+command line interface is the primary method you'll use to manage your platform.
+Holos uses CUE to provide a unified configuration model of the platform.  This
+unified configuration is built up from components packaged with Helm, Kustomize,
+CUE, or any other tool that can produce Kubernetes resource manifests as output.
+
+This process can be thought of as a data **rendering pipeline**.  The key
+concept is that Holos will always produce fully rendered output, but delegates
+the _application_ of the configuration to other tools like kubectl apply,
+ArgoCD, or Flux.
+
+```mermaid
+---
+title: Figure 2 - Render Pipeline
+---
+graph LR
+    PS[<a href="/docs/api/core/v1alpha2#PlatformSpec">PlatformSpec</a>]
+    BP[<a href="/docs/api/core/v1alpha2#BuildPlan">BuildPlan</a>]
+    HC[<a href="/docs/api/core/v1alpha2#HolosComponent">Components</a>]
+
+    H[<a href="/docs/api/core/v1alpha2#HelmChart">HelmChart</a>]
+    K[<a href="/docs/api/core/v1alpha2#KustomizeBuild">KustomizeBuild</a>]
+    O[<a href="/docs/api/core/v1alpha2#KubernetesObjects">KubernetesObjects</a>]
+
+    P[<a href="/docs/api/core/v1alpha2#Kustomize">Kustomize</a>]
+    Y[Kubernetes <br/>Resources]
+    G[GitOps <br/>Resource]
+    FS[Local Files]
+
+    C[Kube API Server]
+
+    PS --> BP --> HC
+    HC --> H --> P
+    HC --> K --> P
+    HC --> O --> P
+
+    P --> Y --> FS
+    P --> G --> FS
+
+    FS --> ArgoCD --> C
+    FS --> Flux --> C
+    FS --> kubectl --> C
+```
+
+## Cluster
+
+A Cluster represents a Kubernetes cluster.  One component may be reused across
+multiple different Clusters.
+
+## Fleet
+
+A Fleet represents a group of Clusters that share a similar purpose.  A Platform
+typically has two Fleets, one for management and one for workloads.
+
+[krm]: https://docs.google.com/document/d/1RmHXdLhNbyOWPW_AtnnowaRfGejw-qlKQIuLKQWlwzs/view#heading=h.sa6p0aye4ide
+[Platform]: /docs/api/core/v1alpha2/#Platform
+[BuildPlan]: /docs/api/core/v1alpha2/#BuildPlan

doc/md/start/install.md

@@ -1,4 +1,10 @@
-# Install Holos
+---
+description: Install the Holos executable.
+slug: /install
+sidebar_position: 100
+---
+
+# Installation
 
 Holos is distributed as a single file executable.
 
@@ -18,4 +24,3 @@ go install github.com/holos-run/holos/cmd/holos@latest
 
 - [helm](https://github.com/helm/helm/releases) to fetch and render Helm chart components.
 - [kubectl](https://kubernetes.io/docs/tasks/tools/) to [kustomize](https://kustomize.io/) components.
-

doc/website/docusaurus.config.ts

@@ -4,7 +4,7 @@ import type * as Preset from '@docusaurus/preset-classic';
 
 const config: Config = {
   title: 'Holos',
-  tagline: 'The Platform Operating System',
+  tagline: 'The Holistic Package Manager for Cloud Native Applications',
   favicon: 'img/favicon.ico',
 
   // Set the production url of your site here
@@ -35,16 +35,13 @@ const config: Config = {
     mermaid: true
   },
 
+  // TODO: These redirects don't seem to be working, at least with the `npm run
+  // start` dev server.
   plugins: [
     [
       '@docusaurus/plugin-client-redirects',
       {
-        redirects: [
-          {
-            to: "/docs/guides/try-holos/",
-            from: "/docs/tutorial/local/k3d/"
-          }
-        ],
+        redirects: [],
       },
     ],
   ],
@@ -96,19 +93,14 @@ const config: Config = {
       items: [
         {
           type: 'doc',
-          docId: 'guides/try-holos/index',
+          docId: 'guides/quickstart',
           position: 'left',
           label: 'Try Holos',
         },
+        { to: '/docs', label: 'Docs', position: 'left' },
         {
           type: 'doc',
-          docId: 'intro',
-          position: 'left',
-          label: 'Docs',
-        },
-        {
-          type: 'docSidebar',
-          sidebarId: 'api',
+          docId: 'api',
           position: 'left',
           label: 'API',
         },
@@ -133,16 +125,20 @@ const config: Config = {
           title: 'Docs',
           items: [
             {
-              label: 'Try Holos Locally',
-              to: '/docs/guides/try-holos',
+              label: 'Quickstart',
+              to: '/docs/quickstart',
+            },
+            {
+              label: 'Concepts',
+              to: '/docs/concepts',
             },
             {
               label: 'Documentation',
-              to: '/docs/intro',
+              to: '/docs',
             },
             {
               label: 'API Reference',
-              to: '/docs/api/core/v1alpha2',
+              to: '/docs/api',
             },
           ],
         },
@@ -151,7 +147,7 @@ const config: Config = {
           items: [
             {
               label: 'Discuss',
-              href: 'https://github.com/orgs/holos-run/discussions',
+              href: 'https://github.com/holos-run/holos/discussions',
             },
           ],
         },

doc/website/package.json

@@ -15,10 +15,10 @@
     "typecheck": "tsc"
   },
   "dependencies": {
-    "@docusaurus/core": "3.4.0",
-    "@docusaurus/plugin-client-redirects": "^3.4.0",
-    "@docusaurus/preset-classic": "3.4.0",
-    "@docusaurus/theme-mermaid": "^3.4.0",
+    "@docusaurus/core": "^3.5.2",
+    "@docusaurus/plugin-client-redirects": "^3.5.2",
+    "@docusaurus/preset-classic": "^3.5.2",
+    "@docusaurus/theme-mermaid": "^3.5.2",
     "@mdx-js/react": "^3.0.0",
     "clsx": "^2.0.0",
     "prism-react-renderer": "^2.3.0",
@@ -26,9 +26,9 @@
     "react-dom": "^18.0.0"
   },
   "devDependencies": {
-    "@docusaurus/module-type-aliases": "^3.4.0",
-    "@docusaurus/tsconfig": "^3.4.0",
-    "@docusaurus/types": "^3.4.0",
+    "@docusaurus/module-type-aliases": "^3.5.2",
+    "@docusaurus/tsconfig": "^3.5.2",
+    "@docusaurus/types": "^3.5.2",
     "@wcj/html-to-markdown-cli": "^2.1.1",
     "cspell": "^8.10.4",
     "html-to-markdown": "^1.0.0",

doc/website/sidebars.ts

@@ -12,41 +12,63 @@ import type { SidebarsConfig } from '@docusaurus/plugin-content-docs';
  */
 const sidebars: SidebarsConfig = {
   doc: [
-    'intro',
+    'introduction',
     {
+      label: 'Getting Started',
       type: 'category',
+      collapsed: true,
+      link: { type: 'doc', id: 'start' },
+      items: [
+        {
+          type: 'autogenerated',
+          dirName: 'start',
+        },
+      ],
+    },
+    {
       label: 'Guides',
+      type: 'category',
       collapsed: false,
+      link: { type: 'doc', id: 'guides' },
       items: [
-        'guides/install',
-        'guides/try-holos/index',
-        'guides/try-holos/platform-manifests',
-        'guides/argocd/index',
-        'guides/backstage/index',
-        'guides/observability/index',
+        {
+          type: 'autogenerated',
+          dirName: 'guides',
+        },
       ],
     },
     {
+      label: 'API Reference',
       type: 'category',
-      label: 'Design',
-      collapsed: false,
+      collapsed: true,
+      link: { type: 'doc', id: 'api' },
       items: [
-        'design/rendering',
-      ],
+        {
+          label: 'Schema API',
+          type: 'category',
+          link: { type: 'doc', id: 'api/schema' },
+          collapsed: true,
+          items: [
+            {
+              type: 'autogenerated',
+              dirName: 'api/schema',
+            },
+          ]
+        },
+        {
+          label: 'Core API',
+          type: 'category',
+          link: { type: 'doc', id: 'api/core' },
+          collapsed: true,
+          items: [
+            {
+              type: 'autogenerated',
+              dirName: 'api/core',
+            },
+          ]
+        },
+      ]
     },
-    {
-      type: 'category',
-      label: 'Reference Platform',
-      collapsed: false,
-      items: [
-        'reference-platform/architecture',
-      ],
-    },
-    'glossary',
-  ],
-  api: [
-    'api/core/v1alpha2',
-    'cli',
   ],
 };
 

doc/website/src/components/HomepageFeatures/index.tsx

@@ -8,36 +8,50 @@ type FeatureItem = {
   description: JSX.Element;
 };
 
+// TODO: Consider focusing on the three pillars of Safe, Easy, Consistent.
 const FeatureList: FeatureItem[] = [
   {
-    title: 'Zero Trust Security',
-    Svg: require('@site/static/img/base00/undraw_security_on_re_e491.svg').default,
+    title: 'Kustomize Helm',
+    Svg: require('@site/static/img/base00/undraw_together_re_a8x4.svg').default,
     description: (
       <>
-        Spend more time on your business features and less time rebuilding
-        authentication and authorization.  Holos provides zero trust security
-        with no code needed to protect your services.
+        Super charge your existing Helm charts by providing well defined,
+        validated input values, post-processing the output with Kustomize,
+        and mixing in your own custom resources.  All without modifying upstream
+        charts to alleviate the pain of upgrades.
       </>
     ),
   },
   {
-    title: 'Multi-Cloud',
-    Svg: require('@site/static/img/base00/undraw_cloud_hosting_7xb1.svg').default,
+    title: 'Unified Data Model',
+    Svg: require('@site/static/img/base00/undraw_fitting_pieces_re_nss7.svg').default,
     description: (
       <>
-        Avoid vendor lock in, downtime, and price hikes.  Holos is designed to
-        easily deploy workloads into multiple clouds and multiple regions.
+        Unify all of your platform components into one well-defined, strongly
+        typed data model with CUE.  Holos makes it easier and safer to integrate
+        seamlessly with software distributed with current and future tools that
+        produce Kubernetes resource manifests.
       </>
     ),
   },
   {
-    title: 'Developer Portal',
-    Svg: require('@site/static/img/base00/undraw_data_trends_re_2cdy.svg').default,
+    title: 'Deep Insights',
+    Svg: require('@site/static/img/base00/undraw_code_review_re_woeb.svg').default,
     description: (
       <>
-        Ship high quality code quickly, provide a great developer experience,
-        and maintain control over your infrastructure with the integrated
-        Backstage developer portal.
+        Reduce risk and increase confidence in your configuration changes.
+        Holos offers clear visibility into complete resource configuration
+        <i>before</i> being applied.
+      </>
+    ),
+  },
+  {
+    title: 'Interoperable',
+    Svg: require('@site/static/img/base00/undraw_version_control_re_mg66.svg').default,
+    description: (
+      <>
+        Holos is designed for compatibility with your preferred tools and
+        processes, for example git diff and code reviews.
       </>
     ),
   },

doc/website/src/css/custom.css

@@ -4,6 +4,12 @@
  * work well for content-centric websites.
  */
 
+/* Enable wrapping by default for mobile */
+/* pre code {
+  white-space: pre-wrap;
+  overflow-wrap: anywhere;
+} */
+
 /* You can override the default Infima variables here. */
 :root {
   --ifm-link-color: #268bd2;

doc/website/src/pages/index.module.css

@@ -21,3 +21,7 @@
   align-items: center;
   justify-content: center;
 }
+
+.divider {
+  margin: 0 5px;
+}

doc/website/src/pages/index.tsx

@@ -17,19 +17,26 @@ function HomepageHeader() {
         </Heading>
         <p className="hero__subtitle">{siteConfig.tagline}</p>
         <p className="projectDesc">
-          Holos is a holistic software development platform built from the most
-          popular open source projects.<br /> Build your developer platform in
-          no time.
+          Holos adds CUE's type safety, unified structure, and strong validation
+          features to your current software packages, including Helm and
+          Kustomize.  These features make the experience of integrating software
+          packages into a holistic platform a pleasant journey.
         </p>
         <div className={styles.buttons}>
           <Link
             className="button button--secondary button--lg"
-            to="/docs/intro">
+            to="docs/quickstart">
             Get Started
           </Link>
+          <span className={styles.divider}></span>
+          <Link
+            className="button button--primary button--lg"
+            to="docs/concepts">
+            Learn More
+          </Link>
         </div>
       </div>
-    </header>
+    </header >
   );
 }
 
@@ -37,8 +44,8 @@ export default function Home(): JSX.Element {
   const { siteConfig } = useDocusaurusContext();
   return (
     <Layout
-      title={`Hello from ${siteConfig.title}`}
-      description="Holos provides a software development platform that holistically integrates the most popular cloud native projects.">
+      title={`${siteConfig.title} Package Manager`}
+      description="Holos adds CUE's type safety, unified structure, and strong validation features to your current software packages, including Helm and Kustomize.">
       <HomepageHeader />
       <main>
         <HomepageFeatures />

doc/website/static/img/base00/undraw_lighthouse_re_7r60.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="581.17725" height="668" viewBox="0 0 581.17725 668" xmlns:xlink="http://www.w3.org/1999/xlink"><path d="M248.22582,95.78906h89.68896v73.14404h-89.68896V95.78906Zm87.68896,2h-85.68896v69.14404h85.68896V97.78906Z" fill="#3f3d56"/><rect x="286.81782" y="130.98987" width="70.42636" height="1.99974" transform="translate(181.51001 450.39061) rotate(-88.47361)" fill="#3f3d56"/><rect x="260.34565" y="130.98987" width="70.42636" height="1.99974" transform="translate(155.74299 423.92783) rotate(-88.47361)" fill="#3f3d56"/><rect x="233.87348" y="130.98987" width="70.42636" height="1.99974" transform="translate(129.97597 397.46506) rotate(-88.47361)" fill="#3f3d56"/><path d="M348.72143,167.19043h2v-25.20508l-.72803-.20605c-.60986-.17334-61.65332-17.0542-116.78076,.00732l-.70459,.21777v22.75928h2v-21.28271c51.125-15.53857,107.2041-1.80664,114.21338,.02783v23.68164Z" fill="#3f3d56"/><path d="M233.76635,153.69775c64.82178-17.31445,115.12402-.19727,115.625-.02246l.66016-1.8877c-.50586-.17676-51.35449-17.50244-116.80127-.02246l.51611,1.93262Z" fill="#3f3d56"/><path d="M233.76635,161.05615c64.82178-17.31543,115.12402-.19678,115.625-.02246l.66016-1.8877c-.50586-.17676-51.35449-17.50244-116.80127-.02246l.51611,1.93262Z" fill="#3f3d56"/><path d="M246.74401,244.86805h89.34375v-66.20661l12.40885-10.72828c-38.14672-11.12717-76.76201-11.43174-115.81597-1.65451l14.06337,12.69546v65.89394Z" fill="#657b83"/><path d="M369.00512,238.97021h2v-33.73975l-.72803-.20605c-.82227-.23193-83.0752-22.97705-157.34863,.00732l-.70459,.21777v30.44629h2v-28.97021c69.79443-21.31152,146.50439-2.16113,154.78125,.02686v32.21777Z" fill="#3f3d56"/><path d="M213.48217,220.43018c87.56445-23.39014,155.5166-.25879,156.19287-.02246l.66016-1.8877c-.68164-.23877-69.17871-23.57813-157.36914-.02246l.51611,1.93262Z" fill="#3f3d56"/><path d="M213.48217,230.35742c87.56689-23.39014,155.51611-.25879,156.19287-.02246l.66016-1.8877c-.68164-.23828-69.17871-23.57764-157.36963-.02246l.5166,1.93262Z" fill="#3f3d56"/><path d="M240.95321,96.78906c0,15.53397,27.00976,.40367,48.94007,.40367s50.33076,15.13029,50.33076-.40367-26.05059-39.70833-47.9809-39.70833c-21.93031,0-51.28993,24.17436-51.28993,39.70833Z" fill="#657b83"/><rect x="270.73446" y="43.84462" width="43.01736" height="23.16319" transform="translate(584.48627 110.85243) rotate(-180)" fill="#657b83"/><rect x="288.10685" y="0" width="6.61806" height="47.9809" transform="translate(582.83176 47.9809) rotate(-180)" fill="#657b83"/><path d="M199.59036,667.59633h173.72395l-26.47222-380.53818,34.74479-46.32639c-59.18845-9.46943-119.14115-12.02188-180.34201-3.30903l24.81771,43.01736-26.47222,387.15623Z" fill="#e6e6e6"/><g><rect x="226.06258" y="594.79772" width="31.43576" height="72.79861" transform="translate(483.56093 1262.39405) rotate(-180)" fill="#fff"/><polyline points="280.66154 667.59633 282.31605 584.87064 263.40639 561.70744 242.60772 561.70744 257.49835 586.29047 258.97862 666.78245" fill="#ccc"/></g><g><rect x="301.06258" y="594.79772" width="31.43576" height="72.79861" transform="translate(633.56093 1262.39405) rotate(-180)" fill="#fff"/><polyline points="355.66154 667.59633 357.31605 584.87064 338.40639 561.70744 317.60772 561.70744 332.49835 586.29047 333.97862 666.78245" fill="#ccc"/></g><path d="M434.0852,668h2v-56.8208l-.72803-.20605c-.37207-.10498-37.84863-10.58545-91.42773-15.78418-49.46045-4.7998-123.16992-5.95557-193.44287,15.7915l-.70459,.21777v54.61084h2v-53.13525c69.74414-21.42383,142.84131-20.26025,191.95459-15.49414,49.30518,4.78418,84.88721,14.04346,90.34863,15.51855v55.30176Z" fill="#3f3d56"/><path d="M151.03979,637.34082c83.10986-22.19971,155.81982-21.02441,202.18115-16.12939,50.24316,5.30469,81.22705,15.99951,81.53418,16.10693l.66016-1.8877c-.30859-.10791-31.46045-10.8667-81.91406-16.20068-46.54443-4.92041-119.54102-6.10791-202.97754,16.17822l.51611,1.93262Z" fill="#3f3d56"/><path d="M151.03979,655.34229c83.10986-22.19922,155.81982-21.02441,202.18115-16.12939,50.24316,5.30469,81.22705,15.99951,81.53418,16.10693l.66016-1.8877c-.30859-.10791-31.46045-10.8667-81.91406-16.20068-46.54346-4.9209-119.54102-6.10791-202.97754,16.17822l.51611,1.93262Z" fill="#3f3d56"/><rect x="0" y="665.78223" width="581.17725" height="2" fill="#2f2e41"/></svg>

doc/website/static/img/base00/undraw_male_avatar_g98d.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="532" height="532" viewBox="0 0 532 532" xmlns:xlink="http://www.w3.org/1999/xlink"><circle cx="270.75986" cy="260.93427" r="86.34897" fill="#ffb6b6"/><polygon points="221.18982 360.05209 217.28876 320.6185 295.18982 306.05209 341.18982 418.05209 261.18982 510.05209 204.18982 398.05209 221.18982 360.05209" fill="#ffb6b6"/><path d="m216.0374,340.35736l17.03111,3.84802s-13.38821-42.45453-8.84396-46.50766c4.54427-4.05316,15.68007,2.33328,15.68007,2.33328l11.70201,13.1199,14.25394-14.51239s15.47495-19.2421,21.53397-24.6463-3.67319-25.46364-3.67319-25.46364c0,0,89.89185-24.23923,56.44299-67.83968,0,0-19.61093-34.18452-25.99734-23.04871-6.38641,11.1358-14.00162-6.55013-14.00162-6.55013l-23.25381,4.42198s-45.89429-27.06042-89.45331,30.82959c-43.55902,57.89003,28.57916,154.01572,28.57916,154.01572h-.00002Z" fill="#2f2e41"/><path d="m433.16003,472.95001c-47.19,38.26001-105.57001,59.04999-167.16003,59.04999-56.23999,0-109.81-17.33997-154.62-49.47998.08002-.84003.16003-1.66998.23004-2.5,1.19-13,2.25-25.64001,2.94995-36.12,2.71002-40.69,97.64001-67.81,97.64001-67.81,0,0,.42999.42999,1.29004,1.17999,5.23999,4.59998,26.50995,21.27997,63.81,25.94,33.25995,4.15997,44.20996-15.57001,47.51996-25.02002,1-2.88,1.30005-4.81,1.30005-4.81l97.63995,46.10999c6.37,9.10004,8.86005,28.70001,9.35004,50.73004.01996.90997.03998,1.81.04999,2.72998Z" fill="#657b83"/><path d="m454.09003,77.91003C403.85004,27.66998,337.05005,0,266,0S128.15002,27.66998,77.91003,77.91003C27.67004,128.15002,0,194.95001,0,266c0,64.85004,23.05005,126.16003,65.29004,174.57001,4.02997,4.63,8.23999,9.14001,12.62,13.52002,1.02997,1.02997,2.07001,2.06,3.12,3.06,2.79999,2.70996,5.65002,5.35999,8.54999,7.92999,1.76001,1.57001,3.54004,3.10999,5.34003,4.62,1.40997,1.19,2.82001,2.35999,4.25,3.51001.02997.02997.04999.04999.07996.07001,3.97003,3.19995,8.01001,6.27997,12.13,9.23999,44.81,32.14001,98.37999,49.47998,154.61998,49.47998,61.59003,0,119.97003-20.78998,167.16003-59.04999,3.84998-3.12,7.62-6.35999,11.32001-9.71002,3.26996-2.95996,6.46997-6.01001,9.60999-9.14996.98999-.98999,1.97998-1.98999,2.95001-3,2.70001-2.78003,5.32001-5.61005,7.88-8.48004,43.37-48.71997,67.07996-110.83997,67.07996-176.60999,0-71.04999-27.66998-137.84998-77.90997-188.08997Zm10.17999,362.20997c-2.5,2.84003-5.06,5.64001-7.67999,8.37-4.08002,4.25-8.28998,8.37-12.64001,12.34003-1.64996,1.52002-3.32001,3-5.01001,4.46997-1.91998,1.67004-3.85999,3.31-5.82996,4.92004-15.53003,12.75-32.54004,23.75-50.73004,32.70996-7.19,3.54999-14.56,6.78003-22.09998,9.67004-29.28998,11.23999-61.08002,17.39996-94.28003,17.39996-32.03998,0-62.75995-5.73999-91.19-16.23999-11.66998-4.29999-22.94995-9.40997-33.77997-15.26001-1.59003-.85999-3.16998-1.72998-4.73999-2.62-8.26001-4.67999-16.25-9.78998-23.91998-15.31-.25-.17999-.51001-.37-.76001-.54999-5.46002-3.94-10.77002-8.09003-15.90002-12.45001-1.88-1.59003-3.73999-3.20001-5.57001-4.84998-2.97998-2.65002-5.89996-5.38-8.75-8.18005-5.39996-5.28998-10.56-10.79999-15.48999-16.52997C26.09003,391.77002,2,331.65002,2,266,2,120.42999,120.43005,2,266,2s264,118.42999,264,264c0,66.66003-24.82996,127.62-65.72998,174.12Z" fill="#3f3d56"/></svg>

doc/website/static/img/base00/undraw_pic_profile_re_7g2h.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="532" height="532" viewBox="0 0 532 532" xmlns:xlink="http://www.w3.org/1999/xlink"><g><g><circle cx="270.759" cy="260.92941" r="86.34897" fill="#a0616a"/><polygon points="199.2879 366.61365 217.2879 320.61365 310.2879 306.61365 320.28003 408.44043 226.28003 410.44043 199.2879 366.61365" fill="#a0616a"/></g><path d="M357.94449,276.8613c-1.12067,4.48965-3.38602,15.17972-6.9238,15.23233-2.89023,.04208-5.65668-46.33466-2.76953-54.00568,3.31638-8.81271-5.39886-19.96062-11.96411-25.6832-11.80423-10.2894-38.00696,11.80466-64.65118,1.79587-.70633-.26482-.56558-.23502-8.97934-3.59174-25.88966-10.32974-27.2506-10.62788-28.73386-10.77521-12.55046-1.24167-27.86705,9.02844-34.12146,21.55038-6.50168,13.01653-1.06937,24.18106-7.18346,55.67184-.71246,3.67065-1.83138,8.90216-3.59174,8.97934-3.21819,.14029-6.3605-17.04846-7.18346-21.55038-3.44792-18.86186-6.7722-37.04675,0-57.46771,.73878-2.22729,5.29158-10.49458,14.36693-26.93799,13.0744-23.68825,19.65018-35.57709,21.55038-37.7132,13.62859-15.32624,38.43575-29.30734,59.26357-23.34626,10.52704,3.01299,8.63953,7.85691,21.55038,12.57105,23.00821,8.40057,43.00476-1.87303,46.69254,5.3876,1.9537,3.84602-3.51236,7.01686-3.59174,14.36693-.13593,12.6114,15.81424,16.25575,25.14212,28.73386,5.01447,6.70819,13.59753,6.78012-8.87228,96.78212l.00003,.00003Z" fill="#2f2e41"/></g><path d="M464.92017,442.61035c-3.48022,3.91016-7.09009,7.74023-10.83008,11.48047-50.23999,50.23926-117.04004,77.90918-188.09009,77.90918-61.40991,0-119.63989-20.66992-166.75-58.71973-.03003-.01953-.05005-.04004-.07983-.07031-6.25-5.03906-12.30005-10.39941-18.14014-16.05957,.10986-.87988,.22998-1.75,.35986-2.61035,.82007-5.7998,1.73022-11.33008,2.75-16.41992,8.3501-41.71973,118.22021-85.51953,121.08008-86.66016,.04004-.00977,.06006-.01953,.06006-.01953,0,0,14.14014,52.12012,74.72998,51.4502,41.27002-.4502,33.27002-51.4502,33.27002-51.4502,0,0,.5,.09961,1.43994,.2998,11.91992,2.53027,94.68018,20.70996,127.33008,45.52051,9.94995,7.55957,17.08984,23.66016,22.21997,42.85938,.21997,.82031,.42993,1.66016,.65015,2.49023Z" fill="#657b83"/><path d="M454.09009,77.91016C403.8501,27.6709,337.05005,0,266,0S128.15015,27.6709,77.90991,77.91016C27.67017,128.15039,0,194.9502,0,266c0,64.85059,23.05005,126.16016,65.29004,174.57031,4.03003,4.62988,8.23999,9.13965,12.61987,13.52051,1.03003,1.0293,2.07007,2.05957,3.12012,3.05957,5.84009,5.66016,11.89014,11.02051,18.14014,16.05957,.02979,.03027,.0498,.05078,.07983,.07031,47.11012,38.0498,105.3401,58.71973,166.75001,58.71973,71.05005,0,137.8501-27.66992,188.09009-77.90918,3.73999-3.74023,7.34985-7.57031,10.83008-11.48047,43.36987-48.71973,67.07983-110.83984,67.07983-176.61035,0-71.0498-27.66992-137.84961-77.90991-188.08984Zm10.17993,362.20996c-7.86987,8.9502-16.33008,17.37012-25.33008,25.18066-17.06982,14.84961-36.06982,27.5293-56.55981,37.62988-7.19019,3.5498-14.56006,6.7793-22.1001,9.66992-29.29004,11.24023-61.08008,17.39941-94.28003,17.39941-32.04004,0-62.76001-5.73926-91.18994-16.23926-11.67017-4.30078-22.94995-9.41016-33.78003-15.26074-1.59009-.85938-3.16992-1.72949-4.73999-2.61914-8.26001-4.68066-16.25-9.79004-23.91992-15.31055-10.98999-7.87988-21.3501-16.58984-30.98022-26.03027-5.3999-5.29004-10.55981-10.7998-15.48975-16.5293C26.09009,391.77051,2,331.65039,2,266,2,120.43066,120.42993,2,266,2s264,118.43066,264,264c0,66.66016-24.82983,127.62012-65.72998,174.12012Z" fill="#3f3d56"/></svg>