docs(ops): add reference + env config + git workflow

docs/CONFIG-ENV.md

@@ -0,0 +1,68 @@
+# `docs/CONFIG-ENV.md`
+
+```md
+# 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).