Design: offer cub gitops import as upgrade path in connected mode

[monadic]

Context

cub-scout's import command creates ConfigHub units by:

1. Discovering workloads (Deployments, StatefulSets, DaemonSets) via the K8s API
2. Grouping them into logical units
3. Calling cub unit create with raw kubectl get -o yaml manifests
4. Optionally wiring a worker + targets

This works universally — any cluster with kubectl access — but produces static snapshot units with no render pipeline.

Meanwhile, cub gitops import (shipped in cub CLI 2026-02-27) operates at the GitOps controller layer:

• Discovers ArgoCD Applications, Flux HelmReleases/Kustomizations
• Renders them via actual ArgoCD/Flux controllers (requires in-cluster renderer worker)
• Creates dry/wet unit pairs with MergeUnits links
• Extracts Helm labels (HelmChart, HelmRelease, HelmChartVersion)

Comparison

Dimension	cub-scout import	cub gitops import
Input	Live workloads	GitOps controller objects
Discovery	In-process K8s clientset	Server-side discover function via worker
Output	1 unit per workload group (raw manifest)	dry + wet unit pair per GitOps resource + link
Rendering	None (snapshot)	Full render via ArgoCD/Flux controllers
Requirements	kubectl access	K8s worker + renderer worker in-cluster + running controller
Use case	"What's running and who owns it?"	"Wire ConfigHub into the GitOps render pipeline"

These are complementary, not competing — different layers of the same problem.

Proposal

When cub-scout is in connected mode and detects that ArgoCD or Flux controllers are actually running on the cluster, offer cub gitops import as an upgrade path.

Detection

cub-scout already detects ArgoCD/Flux ownership via labels. Extend this to check for:

• ArgoCD: argocd-server deployment in argocd namespace
• Flux: source-controller + helm-controller/kustomize-controller in flux-system

UX Flow

1. cub-scout import runs as normal (discover → propose → create units)
2. If connected mode + GitOps controllers detected:

   ℹ ArgoCD detected with 3 Applications.
   
   cub gitops import can set up rendered dry/wet pipelines
   for these Applications, keeping ConfigHub in sync with
   what ArgoCD actually renders.
   
   Run: cub gitops import --space myapp-team \
        dev-kubernetes-yaml-kind-import-demo \
        dev-argocdrenderer-kubernetes-yaml-kind-import-demo
   

3. This is informational only — cub-scout doesn't call it, just suggests it

Why not delegate directly

• cub gitops import needs a renderer worker deployed inside the cluster (cub worker install)
• It needs auth tokens (ArgoCD) or running Flux controllers
• The setup is heavier than cub-scout's universal kubectl-only approach
• cub-scout should remain the lightweight entry point; cub gitops is the full pipeline

Benefits of the upgrade path

1. Rendered manifests instead of raw snapshots
2. Dry/wet pipeline — changes propagate automatically via links
3. Helm label extraction — chart metadata preserved
4. Stays current — not a one-time snapshot

Non-goals

• cub-scout should NOT require cub gitops import
• cub-scout should NOT install renderer workers
• The suggestion should be skipped in standalone (non-connected) mode

References

• Brian Grant's test scripts: test/scripts/test-argocd-import.sh, test/scripts/test-flux-import.sh (confighub repo)
• cub-scout demo: examples/import-from-live/demo.sh --live
• cub gitops help: cub gitops --help

[monadic]

Closing as implemented on main; details in previous comment.

[monadic]

Implemented in main.

What landed:

• Connected cub-scout import now attempts GitOps delegation for Argo/Flux workloads and falls back to snapshot import for leftovers.
• Delegation summary is printed so users can see exactly what was delegated vs snapshot-imported.
• --connect / --no-connect behavior is explicit and documented for post-import worker wiring.

Code references:

• Delegation entry point and fallback path: cmd/cub-scout/import.go (Step 5 apply path, delegation attempt)
• Delegation summary + filtering: cmd/cub-scout/import.go (printDelegationSummary, filterScoutWorkloadsAfterDelegation)
• cub gitops discover/import handoff per namespace: cmd/cub-scout/import.go (runGitOpsImportForNamespaces)

Docs/tests:

• CLI docs updated (CLI-GUIDE.md, import how-tos)
• Repeatable regression check added: make test-import-delegation / scripts/test-import-delegation.sh

Given this is now implemented and shipped, closing this design issue.