ADR-0014: Gitea as the in-boundary git host

Status: Accepted — 001-walking-skeleton (2026-06) Principles served: I, VI Source: specs/001-walking-skeleton/research.md D-4

Context

Every app lives in its own git repo, promotion is a platform-raised pull request (ADR-0004), and the boundary requires git to live inside the configured tier — prompts, generated code, and history may not leave the customer boundary. The git host therefore has to run in-cluster and expose a PR API the Tend operator can drive programmatically.

Decision

In-cluster Gitea is the reference git host for per-app repos and promotion PRs. It is lightweight, self-hostable, and has a PR API the operator can drive (the Gitea PR reviewer group maps to the platform-approver group in Keycloak). The choice is explicitly pluggable: a customer's existing in-boundary git — for example GitLab or GitHub Enterprise on-premises — can replace Gitea, honoring the no-lock-in posture.

Alternatives considered

• GitHub.com — rejected: off-boundary.
• A bare git server — rejected: no PR/review primitive, which the promotion-as-PR flow requires.

Consequences

The full promotion audit trail — PR, review, merge — stays inside the boundary, and the operator has a concrete API to raise promotion PRs against. Gitea is also an evidence source: the evidence index reads commit history (with builder-recorded prompt hashes) and promotion PR metadata from its API (ADR-0016). One honest gap follows from Gitea also hosting the platform repo, which makes the app-of-apps loop circular on a fresh cluster. hack/seed-gitea.sh breaks that circle once — install Gitea directly, push the platform repo into it, register the Argo CD credential — after which Argo adopts those same manifests and the platform is self-hosting. The bootstrap gap recorded when this ADR was written is closed; the local development path survives it on its own merits.