feat: add kind-local overlay and kind-up-local target

[jeremyeder]

Summary

• Add kind-local kustomize overlay for local development without needing Quay registry access
• Add make kind-up-local target for a fully local dev workflow (build → load → deploy)
• Add vteam_public_api to load-images.sh and minikube _build-and-load (was missing)
• Fix OCI archive path bug in load-images.sh where colons in image tags created nested directory paths

Test plan

• make kind-up-local creates cluster, builds images, loads them, and deploys successfully
• All pods reach Running state with locally built images
• make kind-up (existing Quay workflow) still works unchanged
• make test-e2e passes against the local cluster

🤖 Generated with Claude Code

[github-actions]

Claude Code Review

Summary

PR #664 adds a kind-local kustomize overlay and make kind-up-local target enabling fully local kind-based development without Quay.io registry access. It also fixes a real bug in load-images.sh and adds the missing vteam_public_api component. This is a pure infrastructure/DX change — no backend Go code, no frontend TypeScript, no business logic — so security patterns around user-token auth and React Query don't apply directly. The work is generally clean and well-structured, with a few items worth addressing.

Issues by Severity

🚫 Blocker Issues

None.

🔴 Critical Issues

1. CONTENT_SERVICE_IMAGE set to vteam_backend — likely wrong value

components/manifests/overlays/kind-local/backend-env-patch.yaml, line 14:

- name: CONTENT_SERVICE_IMAGE
  value: "docker.io/library/vteam_backend:latest"

The backend is setting CONTENT_SERVICE_IMAGE to its own image (vteam_backend). Based on the platform architecture, this env var is likely used by the backend to specify an image for a side-car or workspace content service — it should almost certainly point to vteam_state_sync or vteam_claude_runner, not the backend API container. If this value is wrong, spawned sessions in the local cluster will use the incorrect image. Please verify what CONTENT_SERVICE_IMAGE is consumed by in the backend code and confirm the correct local value.

🟡 Major Issues

2. kubectl apply --validate=false — suppresses manifest validation

Makefile, kind-up-local Step 4:

@kubectl apply --validate=false -k components/manifests/overlays/kind-local/

The existing kind-up target does not use --validate=false. Disabling validation can silently accept misconfigured manifests (wrong field names, missing required fields, type errors in patches), making failures harder to diagnose. If a specific validation error is prompting this flag, that root cause should be fixed instead. If kustomize generates technically valid-but-not-schema-registered CRD fields, consider using --server-side apply with --force-conflicts rather than blanket disabling validation.

3. POD_FSGROUP: "0" — running with root fsGroup

components/manifests/overlays/kind-local/operator-env-patch.yaml, line 18:

- name: POD_FSGROUP
  value: "0"

Setting fsGroup to 0 means spawned runner pods will run with the root group, which is a security deviation from the project standard of dropping all capabilities (see CLAUDE.md Container Security section). This is likely a kind compatibility workaround, but it should be documented with a comment explaining why it's required and flagged as not acceptable for any non-local cluster.

4. patchesJson6902 is deprecated in Kustomize v5

components/manifests/overlays/kind-local/kustomization.yaml, line 22:

patchesJson6902:

patchesJson6902 was deprecated in kustomize v5.0 in favor of the unified patches field with options.merge: false. This will produce deprecation warnings and may break in future kustomize versions. The inline patch format under patches: is the current standard:

patches:
- target:
    group: apps
    version: v1
    kind: Deployment
    name: backend-api
  path: image-pull-policy-patch.yaml

🔵 Minor Issues

5. API server readiness timeout may be too short

Makefile, kind-up-local:

@for i in 1 2 3 4 5 6 7 8 9 10; do \

10 iterations × 3-second sleep = 30 seconds maximum wait. In resource-constrained CI environments or on slower machines, kind cluster API server startup can take longer. Consider increasing to 20 iterations (60s) or adopting kubectl wait --for=condition=Ready which has built-in timeout semantics and is more idiomatic:

kubectl wait --for=condition=Ready node/ambient-local-control-plane --timeout=120s

6. Test plan items are all unchecked

The PR description shows all four test plan checkboxes unchecked. While generated PRs may not always check these off, it would be good practice to confirm these were validated before merge, particularly:

• make kind-up (existing Quay workflow) still works unchanged
• make test-e2e passes against the local cluster

Positive Highlights

• Correct bug fix: The colon-to-slash substitution ${IMAGE//://} creating nested vteam_operator/latest.oci.tar paths is a real bug. The fix ${IMAGE//:/-} producing flat vteam_operator-latest.oci.tar filenames is exactly right.
• Variable extraction in load-images.sh: Assigning ARCHIVE="/tmp/${IMAGE//:/-}.oci.tar" and reusing it across save/import/cleanup eliminates the prior inconsistency risk where each use could drift.
• Missing vteam_public_api: Adding this to load-images.sh and _build-and-load is a proper fix — the public-api was a real gap in the local workflow.
• Step-by-step user output: The numbered step progress in kind-up-local with color coding is excellent developer UX, consistent with the existing kind-up style.
• Inline comments: The YAML patch files include clear comments explaining the IfNotPresent rationale, which will help future maintainers understand why the local overlay differs from the base.
• Clean layering: Building kind-local on top of ../kind via resources: is the right kustomize pattern — avoids duplication while keeping the Quay-based workflow untouched.

Recommendations

1. Before merge: Verify what CONTENT_SERVICE_IMAGE actually resolves to in the backend code and correct the value in backend-env-patch.yaml if it is indeed wrong (Critical Outcome: Reduce Refinement Time with agent System #1).
2. Before merge: Either remove --validate=false or add a comment explaining the specific validation error it's working around (Major Epic: RAT Architecture & Design #2).
3. Follow-up: Add a comment to POD_FSGROUP: "0" explaining the kind constraint and noting it must not be used in production overlays (Major Epic: Data Source Integration #3).
4. Follow-up: Migrate patchesJson6902 to the current patches syntax to avoid future kustomize upgrade friction (Major Epic: AI Agent Development #4).
5. Nice-to-have: Replace the manual retry loop with kubectl wait --timeout for more robust and idiomatic API server readiness checking (Minor Epic: Jira Integration & Workflow #5).

---

🔍 View AI decision process (logs available for 90 days)

📋 View memory system files loaded (click to expand)

What Amber Loaded for Code Review

Amber automatically loaded these repository standards from the memory system:

1. CLAUDE.md - Master project instructions, development standards
2. backend-development.md - Go backend, K8s integration patterns
3. frontend-development.md - NextJS, Shadcn UI, React Query patterns
4. security-standards.md - Auth, RBAC, token handling
5. k8s-client-usage.md - User token vs service account patterns
6. error-handling.md - Consistent error patterns
7. react-query-usage.md - Data fetching patterns

Impact: This review used your repository's specific code quality standards, security patterns, and best practices from the memory system (PRs #359, #360) - not just generic code review guidelines.