docs: ship /launch/v0-1-0 announcement page

astro.config.mjs

@@ -59,6 +59,11 @@ export default defineConfig({
             { label: "What is Plinth", slug: "index" },
             { label: "Manifesto", slug: "manifesto" },
             { label: "Try it in 60 minutes", slug: "start/try-it" },
+            {
+              label: "v0.1.0 launch",
+              slug: "launch/v0-1-0",
+              badge: { text: "new", variant: "tip" },
+            },
           ],
         },
         {

src/content/docs/index.md

@@ -18,6 +18,10 @@ hero:
       variant: minimal
 ---
 
+:::tip[v0.1.0 just shipped]
+A working SDK across Go and TypeScript, two starters, a CLI, a Backstage scaffolder, a Helm chart, and a worked example — all stable, all open. Read the [launch announcement](/launch/v0-1-0/).
+:::
+
 ## What Plinth gives a team
 
 A fleet of internal applications — project management, change requests, audit dashboards, HR tooling, internal admin — sharing one substrate, one SDK, one scaffolder. Modules import the platform; they don't re-implement it.

src/content/docs/launch/v0-1-0.md

@@ -0,0 +1,88 @@
+---
+title: Plinth v0.1.0 — bank-grade foundation for internal-tooling fleets
+description: A substrate, a 14-package SDK, two starters, a CLI, a Backstage scaffolder, and a worked example. Five months of solo work, all open-source, all stable.
+sidebar:
+  hidden: true
+---
+
+*2026-05-01*
+
+If you run a fleet of internal applications — change requests, audit dashboards, HR tooling, account-access workflows, the long tail — you've watched every module re-implement the same plumbing: identity, authorization, audit, observability, deployment. You've also watched every module inherit the same gaps: a session secret committed in `.env.example`, an authorization layer that fails open in dev mode, no real healthcheck, no error boundaries, no centralised logs.
+
+Plinth is the platform foundation those modules should have stood on from day one. Today is v0.1.0 — the first stable release. Everything below works, has tests, has docs, and is on a public registry you can install from right now.
+
+## Six commitments
+
+The [manifesto](/manifesto/) is the contract. Zero standing trust. GitOps everything. Immutable infrastructure. Durable workflows. Evidence by default. Open source first.
+
+If those don't match how you'd build internal tooling at a regulated org, save yourself the install. If they do — keep reading.
+
+## What v0.1.0 ships
+
+| Component | What it is | Install |
+| --- | --- | --- |
+| [`sdk-go`](https://github.com/plinth-dev/sdk-go) | 7 Go packages: fail-closed authz, non-blocking audit (CloudEvents 1.0), OTel init, RFC 7807 errors, paginate, vault, health | `go get github.com/plinth-dev/sdk-go/<pkg>@v0.1.0` |
+| [`sdk-ts`](https://github.com/plinth-dev/sdk-ts) | 7 TypeScript packages: `env`, `api-client`, `authz`, `authz-react`, `forms`, `otel-web`, `tables` | `pnpm add @plinth-dev/<pkg>` |
+| [`starter-api`](https://github.com/plinth-dev/starter-api) | Go 1.25 + chi + pgx, every SDK wired into one working service | `git clone` |
+| [`starter-web`](https://github.com/plinth-dev/starter-web) | Next.js 16 + React 19, every TS SDK wired into one working app | `git clone` |
+| [`cli`](https://github.com/plinth-dev/cli) | `plinth new <name>` to scaffold both starters with renamed identifiers | `go install github.com/plinth-dev/cli/cmd/plinth@v0.1.1` |
+| [`scaffolder`](https://github.com/plinth-dev/scaffolder) | Backstage software template + custom action emitting the same output | `pnpm add @plinth-dev/scaffolder-actions` |
+| [`platform`](https://github.com/plinth-dev/platform) | Helm umbrella chart — CloudNativePG + Cerbos + OTel Collector | `git clone && helm install` |
+| [`example-access-requests`](https://github.com/plinth-dev/example-access-requests) | Working internal tool: temp-prod-access requests with approver workflow | `git clone` |
+
+Total: nine repos, all MIT-licensed, all v0.1.0 stable, all CI-green, all docs-complete.
+
+API contracts are frozen for the 0.x line. Breaking changes batch into 0.2.0; v1.0 locks the API across major versions.
+
+## Try it in two minutes
+
+```bash
+# Scaffold a fully-wired Plinth module pair
+go install github.com/plinth-dev/cli/cmd/plinth@v0.1.1
+plinth new billing --module-path github.com/acme/billing-api
+
+# Or read a real working example end-to-end
+git clone https://github.com/plinth-dev/example-access-requests
+```
+
+The [60-minute walkthrough](/start/try-it/) takes you from `kind create cluster` to a deployed module. The [access-requests example](/examples/access-requests/) is a real internal tool you can clone and click through in 10 minutes.
+
+## What's deliberately not in v0.1.0
+
+The platform chart's a walking skeleton — Postgres + Cerbos + OTel only. The big substrate pieces are roadmapped, not shipped:
+
+- **Identity** — Vault HA Raft, Authentik, Ory Oathkeeper, cert-manager
+- **Data** — MinIO, NATS JetStream, Redis Sentinel, OpenSearch
+- **Observability** — SigNoz (ClickHouse-backed), kube-prometheus-stack
+- **Security** — Wazuh, Falco, Trivy Operator, Kyverno
+- **GitOps + DevX** — Argo CD, Argo Rollouts, Backstage
+- **Bootstrap** — Talos manifests, Argo app-of-apps, OCI publish to ghcr.io
+- **Examples** — feature-flag dashboard, invoice approval, on-call directory
+
+These land incrementally. The shape is fixed in [the architecture doc](/architecture/). What changes between now and v1.0 is *how much is wired up*, not *what the foundation looks like*.
+
+## Why v0.1.0 instead of v1.0
+
+The SDK contracts are stable — what's documented in the 14 ADRs at /sdk/ is the API for the 0.x line. Lib code rarely needs breaking changes; it needs depth. v0.2 / v0.3 etc. add features without breaking signatures.
+
+The substrate's another story. The `platform` chart will gain components, profiles will harden, the Talos bootstrap will appear. v1.0 is when the *whole architecture* in the manifesto runs end-to-end with one `helm install`. Mid-2027 if I'm honest with myself.
+
+## Why this exists at all
+
+I've spent fifteen years watching internal-tools teams at regulated orgs re-implement the same six commitments — badly, inconsistently, mostly at 2am the night before an audit. Every team. Every shop. The platform-engineering practice that emerged in the 2020s solved the deployment side of this; the *application-foundation* side stayed re-implemented per module.
+
+Plinth is the application-foundation side. It's the thing I'd want to inherit on my first day if a director told me "stand up an internal-tools team and ship 30 apps in 18 months."
+
+It's also a bet that internal-tools work is high-leverage, undervalued, and — uniquely in this AI-everywhere moment — gets *more* valuable as the apps themselves get cheaper to write. If everyone can vibe-code the next access-request workflow, what differentiates a serious org's internal tools is the substrate they sit on. The audit log nobody can disable. The authz that fails closed by default. The OTel pipeline that catches the regression three minutes after deploy.
+
+That substrate is what Plinth is. Open source, on purpose, MIT, no open-core, no proprietary extensions. The rest is the work.
+
+## What I'd love feedback on
+
+- Architecture critiques. Read the [overview](/architecture/) and the [ADRs](/adr/). Tell me what's wrong or what I'm missing.
+- Use it. Run `plinth new`. File issues for paper cuts.
+- The [example](/examples/access-requests/). Is it convincing as a "this is how you'd actually build it" demo? Where does it cheat?
+
+Bugs and feedback: GitHub issues on the relevant repo. Disclosures: `security@plinth.run`.
+
+— Husham