Everything-is-an-app: pilot cert-manager end-to-end (app-of-apps + settings + values)

Parent

linode/apl-core#3515

Design update (supersedes original §3/§8): enable flags live in AplCluster.spec.apps (env/settings/cluster.yaml), not a dedicated env/settings/apps.yaml. See linode/apl-core#3515 comment and ADR adr/2026-08-21-app-enable-flags-in-aplcluster.md.

What to build

The foundational tracer bullet for the "everything is an app" model: drive one always-installed pilot app (cert-manager) end-to-end through the new git-driven pipeline while every other core app stays on the legacy path.

End-to-end behavior:

• The pilot app's enabled flag is read from AplCluster.spec.apps.<name> in env/settings/cluster.yaml — reusing the existing AplCluster file-map entry, no new file/kind. derived.gotmpl overlays .Values.cluster.apps onto .Values.apps and then unsets .Values.cluster.apps, so existing installed: helmfile expressions for the pilot (.Values.apps.<name>.enabled) keep working byte-for-byte unchanged, and bin/compare.sh stays a zero-delta oracle.
• The pilot app's chart values live at env/values/<namespace>/<release>/values.custom.yaml (user-editable, vendor-shaped) and env/values/<namespace>/<release>/values.managed.yaml (operator-rendered cross-cutting/derived values). These are plain vendor YAML, outside the platform .Values merge.
• The operator writes both value files, then writes an ArgoCD Application CR as a file to env/manifests/namespaces/argocd/applications/<namespace>-<release>.yaml, committing files before the CR references them. The CR uses ArgoCD multi-source form: chart source + a ref source to the values repo with helm.valueFiles: [values.managed.yaml, values.custom.yaml] (custom wins on overlap).
• A single bootstrap root app-of-apps Application is server-side-applied during initial install and reconciles env/manifests/namespaces/argocd/applications/ recursively. After bootstrap, the pilot is fully git-driven.
• The Application name/filename keep today's <namespace>-<release> convention (getAppName) so the pilot upgrades in place rather than being replaced.

The CR-shape + write-then-create ordering must be produced by a dependency-injectable function (extending today's getArgocdCoreAppManifest / createArgocdAppManifest), following the existing deps = {...} pattern used by addGitOpsApps and the pure-function assertion style of getArgocdGitopsManifest.

Acceptance criteria

• The pilot's enabled flag lives at AplCluster.spec.apps.<name> in env/settings/cluster.yaml and is projected onto .Values.apps.<name>.enabled via derived.gotmpl (overlay-then-unset); legacy installed: expressions still resolve for the pilot.
• Enabling the pilot writes values.managed.yaml + a starter values.custom.yaml and commits them before the Application CR file is created (ordering asserted in a unit test via injected deps, no real git/K8s).
• The generated Application CR is multi-source with valueFiles listing managed then custom, named <namespace>-<release>.
• A bootstrap root app-of-apps is applied during install and syncs env/manifests/namespaces/argocd/applications/ recursively.
• The pilot app reconciles to Healthy in ArgoCD sourced entirely from the values repo; all other apps remain on the legacy path and are unaffected.
• Unit tests cover the reconcile function's CR shape, valueFiles order, ordering, and that it reads AplCluster.spec.apps.<name>.enabled (from env/settings/cluster.yaml) to decide whether to act.

Blocked by

None - can start immediately.

Start with env/settings/cluster.yaml, derived.gotmpl, and the existing getArgocdCoreAppManifest/createArgocdAppManifest flow. Read addGitOpsApps and getArgocdGitopsManifest for dependency injection and pure-function test patterns. Done means the pilot's CR shape, valueFiles order, write-before-create ordering, enable flag, and bootstrap app-of-apps behavior are covered by tests.