Description
Agreed with Rob 2026-08-27. Deploy the synthkit chart into the EKS lab cluster via an ArgoCD application in the infrastructure repo, always-on, emitting to the dedicated synthkit emission-test stack.
What this actually buys, stated honestly — the shape-validation argument does NOT survive. An earlier version of this reasoning claimed the deployment would validate the chart against real collector behaviour. It would not, or at least not uniquely: the k8s-monitoring permutations are chart CONFIGURATION, and the k3d matrix models them credential-free, disposably, and already wired into the fidelity corpus. That is a better surface for shape questions than a live always-on deployment.
What does survive, and is worth doing on its own:
- Continuous regression detection. Nothing exercises synthkit between waves today, so a defect of the class this audit keeps finding — plausible-but-wrong rendering that works against synthkit and fails against production — surfaces only when someone goes looking. An always-on deployment turns that into drift.
- The Kubernetes deployment path becomes real rather than rendered: RBAC, secret projection, restarts, evictions, resource behaviour under a genuine tick loop.
- Upgrade and rollback come free from ArgoCD, which is what SKT-0005.14 wanted without building it.
- A permanent live reference for dashboards, docs screenshots and demos.
On corpus contamination: it was investigated and there is nothing to do. The concern was that synthkit own pod, scraped by the lab collector, would put values into the corpus that synthkit cannot itself emit, generating contradictions against itself. Checked against the corpus: pod, namespace, node, uid and created_by_name are ALL recorded values_elided: true with zero values, and the comparator runs no value comparison on an elided label. created_by_kind does carry values but a Deployment yields ReplicaSet, which synth already emits. So the mechanism cannot fire.
Excluding synthkit from the lab monitoring was considered and REJECTED: it would cost k8s-level visibility of an always-on deployment — restarts, OOMs, throttling — to prevent something that cannot happen. Renaming the emitted service was also considered and rejected for the same reason. Synthkit in its own namespace is a real application and legitimate corpus data. Do not re-open this without new evidence that a non-elided label carries synthkit-specific values.
One residual, and it argues for leaving it in: label KEYS are not elided. A key nothing else in the cluster carries would enter reality key set — but that surfaces as a coverage gap, not a contradiction, and is equally true of every other workload in that cluster. That is the corpus working, not being polluted.
Sequence after SKT-0014.01, so what the chart emits is known before it runs unattended.
Acceptance Criteria
- #1 An ArgoCD application deploys the chart to the lab cluster and syncs healthy
- #2 It emits to the emission-test stack, not the stack the reality corpus reads
- #3 Credentials reach it without any credential value entering the infrastructure repo
- #4 Upgrade and rollback are exercised at least once through ArgoCD
- #5 No exclusion is added to the lab monitoring config, per the recorded contamination finding
Definition of Done
- #1 make gate (build vet test race rw-proto-check spdx-check forbidden-words)
- #2 make blueprint-schema (only if a blueprint field or construct/workload config struct changed)
- #3 DRY_RUN=true go run ./cmd/synthkit -once -dump — inventory diffed against signals/
Implementation Plan
2026-09-06 read-only reconciliation: inspect the infrastructure declaration and live ArgoCD application, use the authorized image roll as upgrade evidence, and leave rollback unchecked because no rollback is performed solely for evidence.
Implementation Notes
2026-09-06 evidence: the declared application was live, synced, and healthy; its values target the dedicated emission role rather than the corpus-read role; credentials arrive through a referenced external secret with no literal value in the infrastructure repository; and the monitoring configuration contains no synthkit exclusion. The authorized image bump exercised an upgrade and the rollout became healthy. No rollback was performed, so AC4 remains unchecked.
2026-09-06 AC4 live proof: rollback commit d04f979, integrated with an unrelated remote dependency update by merge 4229a11; restore commit 0c08fad. Both directions read back Synced and Healthy with desired/ready/updated/available 1 and zero pod restarts. The older image showed no Beyla-native families after old samples aged out; the restored image showed all five again. Both infrastructure just check gates exited 0. Parent final DoD remains pending the current synthkit gate and explicit safe dump. No collector configuration was changed.
Final Summary
2026-09-06: Reconciled to 4/5. Deployment, target-role separation, secret delivery, and the no-exclusion decision are proven. The task remains In Progress until an ArgoCD rollback is exercised and recorded.
2026-09-06 reconciliation supersedes earlier pending rollback statements: both directions now have live deployment health and signal read-back. The separate final gate is tracked in the current run notes.
Current run: all five ACs are proven. Rollback and restoration each read back Synced/Healthy, ready=updated=available=1 and zero restarts; older-image native families aged out and all five returned after restoration. Current just check, explicit safe dump and agent-disabled e2e passed. Conditional schema generation is not applicable. No collector values or exclusions changed.