Initial monorepo scaffold for Duoc Thu RAG medical chatbot

docs/adr/0001-vector-db-qdrant.md

@@ -0,0 +1,45 @@
+# ADR 0001: Use Qdrant as the vector database
+
+## Status
+
+Accepted
+
+## Context
+
+The RAG pipeline needs a vector store for drug-monograph chunks. The main
+alternative considered was **pgvector** (a Postgres extension), which would
+let us reuse the Postgres instance already needed for users/chat history —
+one fewer moving part to operate.
+
+The corpus is not free-flowing prose: it's a structured per-drug reference
+with rich per-chunk metadata (drug name, section type, page range). The
+common retrieval pattern this domain calls for is "vector similarity search,
+filtered by metadata" — e.g. "search only within chỉ định sections" or
+"filter to a specific drug the user named" combined with the semantic query.
+
+## Decision
+
+Use **Qdrant** as a dedicated vector database, separate from Postgres.
+
+## Rationale
+
+- Qdrant gives first-class combined payload-filtering + ANN search in a
+  single query, which is exactly the retrieval pattern this structured
+  corpus needs — pgvector supports filtering too, but it's a less natural
+  fit layered on top of a general-purpose relational engine.
+- Vector search becomes its own independent scaling axis, separate from the
+  transactional Postgres workload (users/chat) — re-indexing or re-ingesting
+  the formulary doesn't contend with transactional traffic.
+- Mature standalone Docker image for local dev, a well-supported Python
+  client, and a Helm chart for the production Kubernetes deployment target.
+- Corpus size (tens of thousands of chunks) is trivial for Qdrant's HNSW
+  indexing.
+
+## Consequences
+
+- One additional service to operate/deploy/monitor compared to pgvector
+  (which would ride on the existing Postgres).
+- Revisit if operational overhead becomes a real burden at our actual scale,
+  or if we want tighter transactional consistency between chat data and
+  retrieval — pgvector remains a viable fallback documented here for that
+  case.

docs/adr/0002-argocd-gitops.md

@@ -0,0 +1,48 @@
+# ADR 0002: Use the team's existing ArgoCD instance for deployment (GitOps)
+
+## Status
+
+Accepted
+
+## Context
+
+Phase 6 of the build roadmap needs a way to actually deploy the Helm chart to
+Kubernetes across dev/staging/prod. The original scaffold (`infra/ci/github-actions/deploy-cd.yml`)
+assumed a push-based CI deploy step (CI runs `helm upgrade`/`kubectl apply`
+directly against the cluster). The team already runs an ArgoCD instance used
+by other projects.
+
+## Decision
+
+Deploy via **GitOps through the team's existing ArgoCD instance** instead of
+building a custom push-based CD pipeline. ArgoCD Applications
+(`infra/argocd/applications/{dev,staging,prod}/app.yaml`) point at
+`infra/helm/medical-chatbot` in this repo; ArgoCD watches the repo and
+reconciles the cluster to match.
+
+## Rationale
+
+- Reuses infrastructure the team already operates and trusts, instead of
+  standing up a parallel deploy mechanism.
+- GitOps gives an auditable history of every deploy (it's just git commits
+  changing values files/image tags) and a built-in rollback path (revert the
+  commit).
+- Removes the need for CI to hold cluster credentials — CI's job shrinks to
+  "build, test, push image, bump tag," which is a smaller security surface
+  than "CI can directly mutate the production cluster."
+- Prod uses a non-automated `syncPolicy` (manual approval in ArgoCD) while
+  dev/staging auto-sync, matching normal caution around production changes.
+
+## Consequences
+
+- CI workflows (`infra/ci/github-actions/*.yml`) build/test/push images and
+  bump the relevant `values-<env>.yaml` image tag + push that commit; they do
+  **not** call `kubectl`/`helm` against any cluster directly.
+- Actual deploy execution and health/sync status live in the team's ArgoCD
+  UI/CLI, outside this repo — runbooks in `docs/runbooks/` should document how
+  to check sync status and roll back once the team's ArgoCD instance details
+  (cluster/server, project, repo URL) are confirmed (see TODOs in
+  `infra/argocd/README.md`).
+- If the team's ArgoCD instance becomes unavailable or this project needs to
+  fully own its own deploy tooling later, the push-based `deploy-cd.yml`
+  approach remains a documented fallback.