refactor: reorganize GitOps control plane

docs/adr/0001-canonical-repository.md

@@ -0,0 +1,12 @@
+# ADR 0001: Internal Gitea is canonical
+
+Status: accepted
+
+The internal repository
+`https://git.learn.hyeonworks.com/donghyeon.kang/project-gitops` is the only
+writable deployment source.
+
+Argo CD and Gitea Actions use this URL. A GitHub copy may exist only as a
+read-only mirror with monitored replication; it must never be an independent
+deployment branch. GHCR remains an image registry and does not require GitHub
+to host the GitOps source.

docs/adr/0002-terraform-ownership.md

@@ -0,0 +1,24 @@
+# ADR 0002: Terraform state ownership
+
+Status: accepted
+
+Terraform은 VM/네트워크뿐 아니라 provider가 제공되는 Vault API 객체도
+관리할 수 있다. 현재 저장소의 Terraform 범위는 Vault API이고 실제
+machine provisioning은 provider가 확정될 때 별도 root로 추가한다.
+
+`dev-k3s`는 두 state만 사용한다.
+
+- `vault-core`: mounts, auth backends, policies, Kubernetes/JWT roles,
+  application Transit key
+- `vault-database`: PostgreSQL connection과 dynamic roles
+
+resource/API path 하나는 한 state에만 속한다. state는 암호화, versioning,
+access control, locking이 가능한 remote backend에 저장한다.
+
+`vault-core`는 privilege-escalation 가능한 객체를 포함하므로 제한된
+관리자 실행만 허용한다. `vault-database`는 core가 생성한
+`vault-database-automation-dev` 정책의 short-lived identity로 실행한다.
+
+Secret payload는 Terraform resource/data source로 관리하지 않는다.
+필수 credential은 ephemeral variable과 provider write-only argument를
+통해서만 apply에 전달한다.

docs/adr/0003-vault-topology.md

@@ -0,0 +1,25 @@
+# ADR 0003: Vault topology
+
+Status: accepted for dev, production decision pending
+
+동일한 단일 노드 K3s 안의 두 Vault는 failure domain을 분리하지 못하면서
+초기화, Transit credential, rotation과 staged apply 절차를 추가했다.
+따라서 `dev-k3s`는 단일 self-hosted Vault로 단순화한다.
+
+Dev profile:
+
+- single-node integrated Raft
+- Shamir 1-of-1 init/unseal
+- TLS 미적용
+- 명시적 backup/recovery runbook
+
+이 구성은 production에 사용할 수 없다. production은 다음 중 하나를
+선택해야 한다.
+
+- managed Vault
+- workload cluster 밖의 독립 HA Vault
+- 최소 3-node integrated-Raft + TLS + KMS/HSM auto-unseal + PDB,
+  anti-affinity와 정기 restore exercise
+
+production Vault가 결정되기 전에는 production manifest와 Terraform root를
+만들지 않는다.

docs/adr/0004-argo-bootstrap-stages.md

@@ -0,0 +1,18 @@
+# ADR 0004: Single Argo CD root
+
+Status: accepted
+
+Argo CD 설치 후 `bootstrap/argocd/root-application.yaml` 하나만 seed한다.
+root는 `clusters/dev-k3s`의 AppProject와 모든 child Application을 소유한다.
+
+반복 `kubectl apply`와 foundation/platform/application별 root wrapper는
+제거한다. routine deployment는 Git merge만으로 시작한다.
+
+Child Application의 sync wave는 객체 생성 순서를 가독성 있게 표현하지만
+서로 다른 Application의 readiness dependency로 간주하지 않는다.
+Workload와 hook은 Vault/DB가 늦게 준비되는 상황을 retry할 수 있어야 한다.
+
+Root가 child Application을 prune하거나 삭제하려면 확인이 필요하다.
+shared resource 소유권 충돌은 sync를 실패시킨다. 현재 규모에서는 명시적
+Application을 사용하고 두 번째 클러스터가 생길 때 ApplicationSet을
+검토한다.

docs/adr/0005-repository-layout.md

@@ -0,0 +1,17 @@
+# ADR 0005: Cluster-first repository layout
+
+Status: accepted
+
+현재는 하나의 platform 팀, 하나의 dev cluster와 소수 workload를 가지므로
+GitOps configuration monorepo를 유지한다. application source repository와
+deployment configuration repository는 분리한다.
+
+- `platform/`, `workloads/`: 환경 중립 base
+- `clusters/<cluster>/manifests`: cluster-specific final composition
+- `clusters/<cluster>/applications`: Argo reconciliation inventory
+- `iac/terraform`: Kubernetes manifest와 분리된 external API IaC
+- `bootstrap`: controller가 존재하기 전의 최소 seed
+
+production 접근권한, 소유 팀, Terraform backend 또는 release cadence가
+실제로 갈라질 때 platform GitOps, workload GitOps, IaC repo 분리를
+재검토한다. 존재하지 않는 환경의 skeleton은 유지하지 않는다.

docs/adr/0006-gateway-and-istio.md

@@ -0,0 +1,33 @@
+# ADR 0006: Gateway API first, Istio deferred
+
+Status: accepted
+
+현재 단일 노드 K3s와 auth/api 중심 workload에는 service mesh 운영 비용을
+정당화할 mTLS identity, L7 authorization, canary traffic policy 또는
+multi-team 요구가 없다. 이번 개편에는 Istio를 설치하지 않는다.
+
+선행 작업:
+
+1. Traefik Gateway API provider와 GatewayClass 검증
+2. Ingress를 Gateway/HTTPRoute로 이관
+3. north-south TLS
+4. 내부 호출의 ingress hairpin 제거
+5. Vault/PostgreSQL native TLS
+6. NetworkPolicy regression test와 observability/SLO
+
+Istio 요구가 실제화되면 sidecar가 아니라 ambient mode로 제한 pilot한다.
+초기 범위는 api-server와 auth-server이며 Vault, Vault injector,
+PostgreSQL은 제외한다. ztunnel L4부터 시작하고 L7 정책이 필요할 때만
+waypoint를 추가한다.
+
+다음 기능 요구 중 두 개 이상과 운영 선행조건이 모두 충족될 때 ADR을
+재검토한다.
+
+- ServiceAccount identity 기반 east-west mTLS
+- path/JWT 기반 L7 authorization
+- canary traffic split/retry/timeout/outlier detection
+- 지속적인 서비스·namespace·팀 증가
+- application instrumentation만으로 해결하기 어려운 장애 분석
+
+현재 Ingress를 즉시 제거하지 않는다. TLS, DNS, GatewayClass 계약이
+확정되기 전 가상의 Gateway 설정을 배포하지 않기 위함이다.