~0:30. First-ever platform intro for the dev team. Promise up front: this talk is everything you need to ship and run a service — and it fits in one YAML file you own.

~1:30. The "why" before the "how". Lead with Container Apps so it reads as evolution, not a rewrite. Security/SOC 2 = credibility + necessity. Clean slate = the legacy cluster's mistakes are fixed at the root, not patched. Reliability + cost are the day-to-day wins devs feel. Land it: same paved road for everyone, you move at Git speed, the platform handles the rest.

~1:30. Demystify "platform". Two honest pieces. One: it's a real AKS cluster, run from Git by ArgoCD and partitioned into two ArgoCD projects — `core` (CloudOps-owned platform addons) and `services` (developer workloads, your namespaces). Two: you only ever touch one file in your repo; a shared Helm chart is the translation layer that turns it into Kubernetes. The K8s complexity is real — it's the platform's problem, not yours.

~2:00. Reframe: the manifest is the one artefact that matters. Walk the chart left-to-right once, then the four jobs it does — these are the rest of the deck's section headers, so this slide is the map. Land the contract: if you ever want to click in Azure or run kubectl, stop — it goes in the file.

~1:00. The hero: you don't even write the YAML. Walk the terminal top to bottom — each ● is a step the skill performs (readiness check → the two files → a local gatecheck → a PR). The payoff line: it never writes app code, so app-side gaps come back as TODOs. Next slide: the rest of the skill family.

~1:00. The point: onboarding is one skill in a family that spans the whole lifecycle — readiness → onboard → add-database → modify → verify → inspect. All in the ynm-platform plugin. None write app code; mutating ones land a PR, inspecting ones are read-only. Reassures the control-conscious dev.

~2:00. Pay off the four verbs from "The manifest": here they are in one real file. Walk it top to bottom — each marked block is one job. Top-level postgres/mssql are repo-scoped (not per-service). Mention the companion gatecheck workflow that blocks bad manifests pre-merge, and point at platform.md + platform-demo to copy from. The deep-dive slides follow.

~3:00. Switch to the browser. Walk admin.dev.younium.cc: the service list, open one service → its rendered manifest, claims, health, and the links out (dashboards, logs, the live URL). Read-only — fastest answer to "what's deployed and is it healthy". Tie back: everything shown here came from the one manifest file.

~2:00. The hero is the baseline: six production features you never asked for — that's the "without asking" payoff. The hardened pod baseline is overridable if your image truly needs root/writable FS, but discourage it. The purple chips are the opt-in menu — gesture at them, don't read them; the main ones get their own slides later.

~1:30. The hero: one hostname line under *.dev.younium.cc → a real HTTPS URL. Wildcard cert, DNS, and the Gateway route are all automatic — no ACME wait. The knobs row: path shares a host (longest prefix wins), stripPrefix only when the app serves from /, tls: none for internal services, auth → SSO, up next.

~2:00. Dev message: one block, no auth code. The gateway (Envoy-native OIDC) does the sign-in; your app trusts the X-Auth-Request-* headers (next slide). instance = entra (employees) / frontegg (customers). gates require a role on a path; everything else is open to any signed-in user. Login redirect, cookie and /logout are automatic. (V2 removed mode: role and logout — use signedIn + gates; a logged-out hit on a gated path is a bare 401, log in at / first.)

~1:30. Deltas from V1 oauth2-proxy: primary identifier is X-Auth-Request-User (oid/sub GUID); Email may be absent on Entra (use Preferred-Username); Groups is base64-encoded JSON, not CSV — decode + parse. No Bearer/access-token header is forwarded. sso-demo-eg echoes the headers for debugging.

~1:30. mode: http is the default and the cost win (zero when idle). replicas for always-on. metrics for queue/event-driven workers (KEDA triggers). The cold-start warning prevents the #1 support thread. Health checks next.

~1:30. Rule of thumb: if it's a value, config. If it's sensitive, Key Vault + secrets block. There is no third place.

~2:30. Emphasize granularity: Service Bus access is per-topic and per-direction (send vs receive). storage = the pre-existing shared data accounts, allowlisted by name. Nobody writes Terraform for any of this.

~2:00. If anyone asks "which credential type": always DefaultAzureCredential, no arguments. It works locally too (az login / VS credential) — same code path from laptop to cluster.

~2:30. Pick fresh for greenfield schema work; copy (default) when you want realistic reference data on day one. sourceDatabase is rarely needed — the golden ynm-db-reference-golden is the usual stamp source. platform-demo has working Npgsql + SqlClient samples. MSSQL: drop InvariantGlobalization in csproj.

~1:30. assetCatalog is cluster-scoped (clusters/dev/eu01/values.yaml); gatecheck rejects unknown catalog names. Content updates need a pod restart. container volumes pair with azureAccess.blob; catalog volumes auto-emit AssetsAccess.

~1:30. Test environments = the environments ApplicationSet (wave 31): a file in ynm-environments deploys charts/platform-service into env-<name>. A PR labelled test-env writes that file for your branch → a full, isolated stack with its own URLs and its own DB copy; closing the PR tears it down. Same render as a real service — what you test is what ships. Pairs with the per-env DB copy (prev slide).

~2:00. Build once, promote the digest — the exact bits tested on dev ship to prod. Dev is fully automatic (Kargo direct-pushes the tag). Sandbox/prod is one Promote click → Kargo opens a kargo/promotion/* PR that auto-merges on the green check (branch protection stays enforced, no bypass) → ArgoCD deploys both regions. Rollback = re-promote an older Freight (no rebuild). Canary/blue-green = the rollout field (Argo Rollouts) with automated analysis + auto-abort.

~1:30. Grouped Projects: promotion.project: <name> lands the repo in the shared kargo-grp-<name> Project (Warehouse + Stage per member) instead of a per-repo one. The use case is a product spanning many repos/services (core = monolith-api + frontend + several services). One UI pane, promote together or individually. Group names are registered in servicesPromo.projects; the gatecheck rejects unregistered names. All real services are grouped.

~1:00. The near-term roadmap: (1) Slack integration for build/promotion notifications, (2) onboard CPQ — the first large service, (3) enable test environments for the Younium core services, (4) finalize the sandbox → prod promotion procedures. Demand-driven — invite asks.

~0:30. Close with the action: clone platform-demo, copy the .infrastructure folder, rename things, open your first PR. Offer to pair on the first onboarding.