Task · SKT-0014.01

Validate the chart end to end: deploy it in k3d and check what it emits

Description

The other half of the chart work, and the more valuable half. A chart that renders is not a chart that emits correct telemetry.

The loop this closes: deploy the synthkit chart into the k3d lab, point it at the capture receiver that already decodes RW2, OTLP metrics, OTLP traces and Loki push, and compare what actually arrives against the committed inventory. That is the same comparison the fidelity gate makes, run against a REAL deployment rather than a dry-run projection — so it catches the class of defect that lives between “the renderer produced the right batch” and “the right bytes reached a destination”.

Why it matters more than it sounds: every defect this audit found was of the form “works against synthkit, fails against production”. A dry-run dump proves the renderer agrees with itself. Only running the real artifact through a real receiver proves the deployment does.

Specific things only this catches: credential wiring that silently disables a lane (RUM disables itself with a log line), queue and delivery behaviour under a real tick loop, the readiness contract actually reflecting deployment state, restart behaviour of cumulative counters, and any lane the chart forgets to wire at all.

Build on the existing seams rather than a parallel harness: e2e/receiver/ already decodes every lane and exposes an inventory endpoint, and the e2e suite already does expected.Subset(received) schema-only correlation. This is that comparison with the chart in the middle.

Acceptance Criteria

Definition of Done

Implementation Plan

Lane E order 3: deploy the chart inside the established k3d receiver harness, fail on unreachable declared lanes, reuse the inventory comparison, test counter restart behaviour, and wire the check into scheduled CI with evidence that the workflow invokes it.

2026-09-03 wave: After Lane C releases Docker, extend the existing receiver to retain counter samples, deploy the chart in k3d, reuse Schema.Subset for declared-versus-received evidence, prove restart behavior, and wire the exact check into scheduled CI with invocation evidence.

Implementation Notes

2026-09-02 resume boundary: the chart-in-k3d e2e was not implemented. The existing receiver inventory discards counter sample values, so it cannot prove restart behavior, and no scheduled workflow invokes a chart deployment check. Resume by preserving received counter samples across restart, reuse Schema.Subset for declared-versus-received comparison, fail any declared-but-unreachable lane, and wire the target into scheduled CI with run evidence. Repository just check and just dump passed, but no acceptance criterion is claimed; generation was not applicable.

2026-09-03 evidence: receiver counter observations now preserve exact RW2 values and timestamps; the chart test deploys into a disposable k3d cluster, compares received lanes with the existing inventory.Schema.Subset contract in both directions, fails declared-but-unreachable lanes, and proves a clean counter reset across a pod restart. The scheduled workflow invokes just chart-e2e with the agent fixture disabled. The single hosted workflow_dispatch at exact head 9bfe10c completed successfully (run 33610289703); TestChartE2E passed with a newer, lower node_cpu_seconds_total sample after restart and 481 exact counter samples on each side.

Final Summary

2026-09-02: Parked before implementation because the existing receiver cannot observe counter values across restart and no scheduled chart e2e invocation exists.

2026-09-03: Done. The real chart deployment, declared-lane reachability, existing inventory comparison, counter restart behavior, and scheduled hosted invocation are implemented and proved by a successful exact-head workflow run.

View the source file on GitHub