wunderforge / wunderforge/agenova
[E8-T6] Add Kubernetes artifact validation gates
- Dominant language
- Go
- Stars
- 4
- Forks
- 0
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 41
Description
## Outcome
repository-owned Kubernetes delivery artifacts fail deterministically before real-cluster execution when they are malformed or incompatible with the supported schemas.
## Delivery contract
- **Parent Epic:** #12 (E8)
- **Size:** S
- **Depends on:** #45 (E7-T2), #50 (E8-T3)
- **Wave:** Wave C - Credible delivery
- **Sequence:** 803.5
## Acceptance criteria
- the shared check harness validates YAML formatting/parsing; runs `helm lint` and deterministic `helm template` only when charts exist; validates rendered manifests and required CRDs against pinned schemas; the disposable-cluster lane adds server-side dry-run; one invalid fixture proves the offline PR gate fails; all entry points reuse the shared check profiles.
## Quality gate and evidence
- G1 with a failing invalid fixture and passing offline validation, plus G5 server-side dry-run output from the disposable cluster.
- Record exact commands/artifacts in the PR; prose-only confirmation is not evidence.
## Non-goal
- production Helm lifecycle, a live cluster on every PR, or validating vendored upstream artifacts Agenova does not own.
## Definition of Done
- Acceptance behavior and its named negative case are observable.
- Focused checks and the repository baseline pass, or an explicit blocker is recorded.
- A teammate can reproduce the evidence.
- The change remains inside the parent Epic and architecture boundary.
Contributor guide
Research direction
Start with the shared check harness and every entry point that reuses its check profiles; trace the offline PR gate and disposable-cluster lane described in the acceptance criteria. Confirm YAML, Helm, rendered-manifest, CRD-schema, and server-side dry-run checks, then reproduce the invalid-fixture failure, passing offline validation, and recorded G5 evidence.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- helm, kubernetes
- Domain
- ci-cd, infrastructure, testing-qa
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100