# CONFIG-ENV — variables, priorités, injection build

## 0) Ce que la prod doit garantir
Le bouton “Proposer” doit ouvrir :
- `PUBLIC_GITEA_BASE` (domaine Gitea)
- `PUBLIC_GITEA_OWNER=Archicratia`
- `PUBLIC_GITEA_REPO=archicratie-edition`

Si un seul de ces 3 paramètres est faux → on obtient :
- 404 / redirect login inattendu
- ou un repo/owner incorrect

## 1) Variables utilisées (publique, côté build Astro)

- `PUBLIC_GITEA_BASE`
- `PUBLIC_GITEA_OWNER`
- `PUBLIC_GITEA_REPO`

Elles sont consommées via `import.meta.env.PUBLIC_*` dans `EditionLayout.astro`.

## 2) Où elles vivent (en pratique)
Sur NAS, vous avez vu des divergences entre :
- `.env`
- `.env.local`
- `.env.production`

Règle :
- **prod build docker** doit être piloté par **`.env`** (ou `.env.production` si vous standardisez ainsi),
- mais on évite que `.env.local` “corrige en douce” un `.env` faux.

## 3) Vérification rapide (NAS)
en sh
for f in .env .env.local .env.production .env.production.local; do
  [ -f "$f" ] && echo "---- $f" && grep -nE '^PUBLIC_GITEA_(BASE|OWNER|REPO)=' "$f" || true
done

## 4) Injection Docker (ce qui doit être vrai)

Le build passe bien les build-args :

--build-arg PUBLIC_GITEA_BASE=...

--build-arg PUBLIC_GITEA_OWNER=...

--build-arg PUBLIC_GITEA_REPO=...

et le Dockerfile expose via ENV pour Astro build.

## 5) Contrôle “résultat dans le HTML”

Après build, vérifier que la page contient le bon chemin /issues/new vers le bon owner/repo :

curl -fsS http://127.0.0.1:8082/archicratie/archicrat-ia/chapitre-4/ > /tmp/page.html
grep -nE 'issues/new|archicratie-edition|Archicratia' /tmp/page.html | head -n 40

## 6) Secrets (à ne pas committer)

GITEA_TOKEN : jamais dans le repo.

Le token peut être utilisé ponctuellement pour push non-interactif, mais doit rester dans l’environnement local/CI.

## 7) Docker BuildKit / API (si besoin)

Si BuildKit/buildx est instable sur la machine, vous avez déjà un protocole “fonctionnel”.
Ne documenter ici que le “standard validé” (voir DEPLOY_PROD).