roadmap: platform-template direction & themes (2026 H1)

[devantler]

🤖 Generated by the Daily AI Assistant

Roadmap: platform-template — direction & themes (2026 H1)

This is the product's first roadmap anchor: where platform-template is and where it
should go. It is a strategy synthesis, not new scope — it groups the already-filed,
well-specified issues into coherent themes so the product has a single tracked direction.

Where the product is

platform-template is the genericized, fully-automated-bootstrap derivative of
devantler-tech/platform: a batteries-included
Hetzner/Talos/Flux platform that stands up unattended from "Use this template". As of its
recent go-live it is feature-complete relative to platform — networking, certs, secrets
(OpenBao+ESO), SSO (Dex), policy/runtime security (Kyverno/Kubescape/Tetragon), storage
(Longhorn/CNPG), autoscaling, observability, backup/DR are all wired and CI-validated.

So the strategic emphasis is not new features — it is consolidation, portability, and
shedding scaffolding as the ecosystem matures. Three themes capture all current open work.

Theme 1 — Externalize reusable Kyverno policies to the shared policies library

Problem. Five Kyverno policies vendored in this template are generic Flux/Helm hygiene,
not template-specific, so every devantler-tech platform/tenant re-vendors them and they drift.
Direction. Upstream each to the shared Kyverno-policies repo and consume from there — the
holistic shared-library principle (a pattern proven in 2+ places belongs in a shared lib).
Children: #3 (auto-vpa), #4 (enforce-flux-best-practices), #5 (helm-release-enable-tests),
#6 (helm-release-install-crds), #7 (helm-release-remediation-retries). Size: M (per-policy
upstream PR + repin; additive, backward-compatible).

Theme 2 — Shed upstream-driven workarounds as dependencies mature

Problem. Two components exist only to paper over current upstream limitations and add
surface area: the auth-proxy component (until Cilium ships native forward-auth) and a
SPIRE-start workaround (until the Cilium bug lands).
Direction. Keep these tracked against their upstream issues and remove the moment upstream
ships — don't let temporary scaffolding ossify into permanent architecture.
Children: #8 (auth-proxy → Cilium native forward-auth, cilium/cilium#23797), #13 (SPIRE
start workaround, cilium/cilium#40533). Size: S each, externally gated (blocked on
upstream — watch, don't push).

Theme 3 — Prefer first-class Helm releases over vendored manifests

Problem. Some core infra is delivered as raw/vendored manifests rather than a HelmRelease,
which costs upgradability and config consistency vs. the rest of the platform.
Direction. Componentize raw-manifest infra into HelmReleases where a maintained upstream
chart exists, so it gets the same Flux-managed upgrade/remediation path as everything else.
Children: #14 (CoreDNS → HelmRelease). Size: M. (Future candidates: audit the remaining
k8s/bases/infrastructure for other raw-manifest components worth the same treatment.)

Acceptance / definition of "this roadmap is on track"

• Theme 1: the 5 policies live in the shared library and this template consumes them (no
  divergent local copies), platform aligned to the same source.
• Theme 2: each workaround has a live upstream link and is removed within a release of upstream
  shipping; no orphaned scaffolding.
• Theme 3: CoreDNS is a HelmRelease; a short audit notes any other raw-manifest infra.

Not in scope (deliberately)

New platform capabilities — the template tracks platform; net-new infra should prove out in
platform first and flow down via template-sync, not originate here.

---

Filed as a strategy review (the product had no roadmap anchor). Children keep their normal
labels; this epic is the umbrella. Verify each child's live state before picking it up.

[devantler]

🤖 Generated by the Daily AI Assistant

Triage pass — Theme 1 children labelled + a surfaced precondition

Triage: #3–#7 were unlabelled (the epic says children keep their normal labels). Labelled all
five enhancement so they show up in the normal backlog and tie back to this theme.

Precondition worth surfacing before Theme 1 starts: Theme 1's direction is "upstream each
policy to the shared Kyverno-policies repo and consume from there" — but no such repo exists
yet (devantler-tech has no Kyverno/policy-named repo; verified via gh repo list). So all five
children share a single critical-path prerequisite that isn't itself tracked: the shared
Kyverno-policy library has to exist before any of #3–#7 can be done (their acceptance criterion —
"the 5 policies live in the shared library and this template consumes them" — can't be met
otherwise).

That makes the real sequencing:

1. Maintainer decision (gating): create/identify the shared home — e.g. a new
   devantler-tech/kyverno-policies repo (OCIRepository-published, the way the other shared libs
   are consumed), or fold these into an existing shared lib. Net-new repo is a maintainer-owned
   call, so I'm flagging rather than filing it.
2. Then mechanical (per policy): move policy → shared repo, repin this template's
   cluster-policies/ to consume from there, drop the local copy — additive/backward-compatible,
   one PR per policy. platform aligns to the same source (closes the drift the theme calls out).

No code change this run — the children are correctly enhancement-labelled and blocked only on
the step-1 decision (an internal decision, so not the blocked label, which this repo reserves
for external/upstream gating like #8/#13). Once you pick the shared home, the five upstream PRs
are ready to decompose and ship.