ArgoCD (GitOps deployment)

Deployment uses the team's existing ArgoCD instance (not self-hosted by this project) rather than a custom push-based CD pipeline. See docs/adr/0002-argocd-gitops.md for the rationale.

Flow

CI (infra/ci/github-actions/*-ci.yml) builds and pushes a container image per app on merge to master, then bumps that app's image tag in infra/helm/medical-chatbot/values-<env>.yaml (or a per-app values file) and pushes that commit back to the repo. CI never runs kubectl apply or helm upgrade directly.
ArgoCD (team-managed, pointed at this repo) watches infra/argocd/applications/<env>/ and infra/helm/medical-chatbot/, detects the values-file change, and syncs the cluster to match — this is the actual deploy step, owned by ArgoCD, not by our CI.
Promotion between environments (dev -> staging -> prod) is a Git operation (merge/PR that changes the target values file or image tag for that env), not a manual kubectl/helm command.

Files

applications/dev/app.yaml, applications/staging/app.yaml, applications/prod/app.yaml — one ArgoCD Application CR per environment, each pointing at this repo + the infra/helm/medical-chatbot chart with that environment's values file.

TODO once the team's ArgoCD instance details are known

Fill in spec.destination.server (target cluster API server / context name) in each app.yaml — currently a placeholder.
Confirm which ArgoCD project (RBAC scoping) these Applications should belong to, instead of the placeholder default.
Confirm the repo URL placeholder in each app.yaml once the GitHub repo exists (filled in as part of the initial scaffold commit/push).