Supprimer docs/SESSION_BILAN_CI_RUNNER_DNS_2026-01.md

Reviewed-on: #70

.env

@@ -1,3 +0,0 @@
-PUBLIC_GITEA_BASE=https://gitea.archicratie.trans-hands.synology.me
-PUBLIC_GITEA_OWNER=Archicratia
-PUBLIC_GITEA_REPO=archicratie-edition

.env.development

@@ -1,4 +0,0 @@
-PUBLIC_GITEA_BASE=https://gitea.archicratie.trans-hands.synology.me
-PUBLIC_GITEA_OWNER=Archicratia
-PUBLIC_GITEA_REPO=archicratie-edition
-PUBLIC_SITE=https://archicratie.trans-hands.synology.me

.env.local

@@ -1,5 +0,0 @@
-FORGE_API=http://192.168.1.20:3000
-FORGE_BASE=https://gitea.archicratie.trans-hands.synology.me
-FORGE_TOKEN=aW73wpfJ4MiN2!3UU69qL*vWF9$9V7f@2
-PUBLIC_GITEA_OWNER=Archicratia
-PUBLIC_GITEA_REPO=archicratie-edition

.env.production

@@ -1,6 +0,0 @@
-PUBLIC_SITE=https://archicratie.trans-hands.synology.me
-PUBLIC_RELEASE=0.1.0
-
-PUBLIC_GITEA_BASE=https://gitea.archicratie.trans-hands.synology.me
-PUBLIC_GITEA_OWNER=Archicratia
-PUBLIC_GITEA_REPO=archicratie-edition

docs/CONFIG-ENV.md

@@ -10,6 +10,15 @@ Si un seul de ces 3 paramètres est faux → on obtient :
 - 404 / redirect login inattendu
 - ou un repo/owner incorrect
 
+
+# Diagnostic — “Proposer” (résumé)
+
+**Symptôme :** clic “Proposer” → 404 / login / mauvais repo  
+**Cause la plus fréquente :** `PUBLIC_GITEA_OWNER` (casse sensible) ou `PUBLIC_GITEA_REPO` faux.
+
+➡️ Procédure complète (pas-à-pas + commandes) : voir `docs/TROUBLESHOOTING.md#proposer-404`.
+
+
 ## 1) Variables utilisées (publique, côté build Astro)
 
 - `PUBLIC_GITEA_BASE`

docs/DEPLOY_PROD_SYNOLOGY_DS220.md

@@ -1,5 +1,15 @@
 # Déploiement production (Synology DS220+ / DSM 7.3) — Astro → Nginx statique
 
+> ✅ **CANONIQUE** — Procédure de référence “prod DS220+ / DSM 7.3”.
+
+> Toute modif de déploiement doit être faite **ici**, via PR sur Gitea/main (pas d’édition à la main en prod).
+
+> Périmètre : build Docker (Node→Nginx), blue/green 8081/8082, Reverse Proxy DSM, smoke, rollback.
+
+> Dépendances critiques : variables PUBLIC_GITEA_* (sinon “Proposer” part en 404/login loop).
+
+> Voir aussi : OPS-REFERENCE.md (index), OPS_COCKPIT.md (checklist), TROUBLESHOOTING.md (incidents).
+
 Dernière mise à jour : 2026-02-01
 
 Ce document décrit une mise en place stable sur NAS :
@@ -73,6 +83,17 @@ 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
 
+En cas d’échec :
+- 404 / login loop / mauvais repo → `docs/TROUBLESHOOTING.md#proposer-404`
+- double onglet → `docs/TROUBLESHOOTING.md#proposer-double-onglet`
+
+## Diagnostic — “Proposer” (résumé)
+
+**Symptôme :** clic “Proposer” → 404 / login / mauvais repo  
+**Cause la plus fréquente :** `PUBLIC_GITEA_OWNER` (casse sensible) ou `PUBLIC_GITEA_REPO` faux.
+
+➡️ Procédure complète (pas-à-pas + commandes) : voir `docs/TROUBLESHOOTING.md#proposer-404`.
+
 ## 5) Reverse Proxy DSM (le point clé)
 
 ### DSM 7.3 :

docs/FEATURE-PROPOSER.md

@@ -43,61 +43,15 @@ Le flow ne doit jamais ouvrir deux onglets.
 - un seul `a.target="_blank"` (ou équivalent) déclenché
 - sur click : handler doit neutraliser les propagations parasites
 
-### Vérification (NAS)
+## Diagnostic (canonique)
-en sh :
-curl -fsS http://127.0.0.1:8082/archicratie/archicrat-ia/chapitre-4/ > /tmp/page.html
-grep -n "window.open" /tmp/page.html | head
 
-Doit retourner 0 ligne.
+Le diagnostic détaillé est centralisé dans `docs/TROUBLESHOOTING.md` pour éviter les doublons.
 
-## 3) Diagnostic “trace ouverture onglet” (navigateur)
+- 404 / non autorisé / redirect login :
+  - voir : `TROUBLESHOOTING.md#proposer-404`
+  - cause la plus fréquente : `PUBLIC_GITEA_OWNER/REPO` faux (souvent casse)
 
-Dans la console, tu peux surcharger temporairement les mécanismes d’ouverture pour tracer :
+- Double onglet :
+  - voir : `TROUBLESHOOTING.md#proposer-double-onglet`
+  - cause la plus fréquente : double handler (bubbling) ou `window.open` + `a.click()`
 
-si un window.open survient,
-
-ou si un a.click target _blank est appelé.
-
-But : prouver qu’il n’y a qu’un seul événement d’ouverture.
-
-## 4) URL attendue (forme)
-
-L’onglet doit ressembler à :
-
-{PUBLIC_GITEA_BASE}/{OWNER}/{REPO}/issues/new?title=...&body=...
-
-Important : owner et repo doivent être exactement ceux du repo canonique.
-
-## 5) Pré-requis d’accès
-
-L’utilisateur doit être loggé sur Gitea pour accéder à /issues/new
-
-Si non loggé : redirect vers /user/login (comportement normal)
-
-## 6) Tests fonctionnels (checklist)
-
-Ouvrir une page chapitre (ex chapitre 4)
-
-Clic Proposer (sur un paragraphe)
-
-Choix 1 puis choix 2
-
-Vérifier :
-
-1 seul onglet
-
-URL du repo correct
-
-formulaire new issue visible
-
-title/body pré-remplis (chemin + ancre + texte actuel)
-
-Créer l’issue → vérifier le traitement CI/runner
-
-## 7) Pannes typiques + causes
-
-404 sur issue/new : PUBLIC_GITEA_OWNER/REPO faux (souvent casse)
-
-2 onglets : double handler (bubbling + ouverture multiple)
-
-pas de favicon : cache ou absence dans public/ → rebuild

docs/OPS-DEPLOYMENT.md

@@ -1,6 +1,46 @@
-OPS — Déploiement Archicratie Web Edition (Mac Studio → DS220+)
+# OPS — Déploiement Archicratie Web Edition (Mac Studio → DS220+)
 Objectif : déployer une nouvelle version du site sur le NAS (DS220+) sans jamais casser la prod, en utilisant un schéma blue/green piloté par DSM Reverse Proxy, avec une procédure robuste même quand docker compose build est instable sur le NAS.
 
+> 🟧 **LEGACY / HISTORIQUE** — Ce document n’est plus la source de vérité.
+
+> Référence actuelle : docs/DEPLOY_PROD_SYNOLOGY_DS220.md (canonique).
+
+> Statut : gelé (on n’édite plus que pour ajouter un lien vers le canonique, si nécessaire).
+
+> Raison : doublon → risque de divergence → risque d’erreur en prod.
+
+> Si tu lis ceci pour déployer : stop → ouvre le canonique.
+
+> ⚠️ LEGACY — Ne pas suivre pour déployer.
+> Doc conservé pour historique.
+> Canon : `DEPLOY_PROD_SYNOLOGY_DS220.md` + `OPS-SYNC-TRIPLE-SOURCE.md`.
+
+## Pourquoi ce doc existe encore
+
+- Historique : il capture des repères (domaines, ports, logique blue/green) tels qu’ils ont été consolidés pendant la phase d’implémentation.
+- Sécurité : éviter la divergence documentaire (un seul pas-à-pas officiel).
+- Maintenance : si tu dois déployer, tu suis le canonique ; ici tu ne viens que pour comprendre “d’où ça vient”.
+
+## Ce qu’il faut faire aujourd’hui (canonique)
+
+➡️ Déploiement = `docs/DEPLOY_PROD_SYNOLOGY_DS220.md` (procédure détaillée, à jour).
+
+## Schéma (résumé, sans commandes)
+
+- Ne jamais toucher au slot live.
+- Construire/tester sur l’autre slot.
+- Smoke test.
+- Bascule DSM Reverse Proxy (8081 ↔ 8082).
+- Rollback DSM si besoin.
+
+<details>
+
+> 🚫 NE PAS UTILISER POUR PROD — ARCHIVE UNIQUEMENT
+
+<summary>Archive — ancien pas-à-pas (NE PAS SUIVRE)</summary>
+
+> ⚠️ Archive. Ce contenu est conservé pour mémoire.
+
 ## 0) Repères essentiels
 Noms & domaines
     • Site public (prod) : https://archicratie.trans-hands.synology.me
@@ -383,3 +423,5 @@ Fix standard (dans le vrai dossier site/) :
 rm -rf node_modules .astro dist
 npm ci
 npm run dev
+
+</details>

docs/OPS-REFERENCE.md

@@ -4,7 +4,7 @@ Document “pivot” : liens, invariants, conventions, commandes réflexes.
 
 ## 0) Invariants (à ne pas casser)
 
-- **Source de vérité Git** : `origin/main` sur :contentReference[oaicite:0]{index=0}.
+- **Source de vérité Git** : origin/main (repo Archicratia/archicratie-edition sur Gitea).
 - **Prod** : conteneur `archicratie-web-*` (nginx) derrière reverse proxy DSM.
 - **Config “Proposer”** : dépend de `PUBLIC_GITEA_BASE`, `PUBLIC_GITEA_OWNER`, `PUBLIC_GITEA_REPO` injectés au build.
 - **Branches** : `main` = travail ; `master` = legacy/compat (alignée mais protégée).

docs/OPS-RUNBOOK-ARCHICRATIE-WEB.md

@@ -1,5 +1,15 @@
 # OPS Runbook — Archicratie Web (NAS Synology DS220 + Gitea)
 
+> 🟦 **ALIAS (résumé)** — Runbook 1-page pour opérer vite sans se tromper.
+
+> La procédure détaillée **canonique** est : docs/DEPLOY_PROD_SYNOLOGY_DS220.md.
+
+> Source Git : Gitea/main ; déploiement = rebuild depuis main ; pas de hotfix non versionné.
+
+> Déploiement : build sur slot inactif → smoke → bascule DSM → rollback si besoin.
+
+> Incidents connus : voir docs/TROUBLESHOOTING.md.
+
 ## 0. Objectif
 Ce document décrit la procédure **exacte** pour :
 - maintenir un état cohérent entre **Local (Mac Studio)**, **Gitea**, **NAS (prod)** ;

docs/TROUBLESHOOTING.md

@@ -15,6 +15,7 @@ Toujours isoler : **Local**, **Gitea**, **NAS**, **Navigateur**.
 
 ---
 
+<a id="proposer-404"></a>
 ## 1) “Proposer” ouvre Gitea mais retourne 404 / non autorisé
 
 ### Symptôme
@@ -38,6 +39,7 @@ Puis rebuild + restart du container + smoke.
 
 ---
 
+<a id="proposer-double-onglet"></a>
 ## 2) Double onglet à la validation du flow “Proposer”
 
 ### Symptôme
@@ -64,7 +66,9 @@ garder un seul mécanisme d’ouverture
 
 sur click : preventDefault() + stopImmediatePropagation()
 
+<a id="Favicon-504-erreurs"></a>
 ## 3) Favicon 504 / erreurs console sur favicon
+
 # Symptôme
 
 Console navigateur : GET /favicon.ico 504

docs/anchors.md

@@ -63,7 +63,7 @@ Si l’ID exact n’existe plus :
 But : éviter les “liens morts” historiques quand une régénération d’IDs a eu lieu.
 
 Limite : c’est un fallback de dernier recours (moins déterministe qu’un alias explicite).
-Le mécanisme recommandé reste : `docs/anchor-aliases.json` + injection au build.
+Le mécanisme recommandé reste : `src/anchors/anchor-aliases.json` + injection au build.
 
 _______________________________________
 
@@ -87,7 +87,7 @@ Les IDs d’ancres générés (ou dérivés) peuvent changer :
 
 ## 2) Le mapping d’alias
 
-- Fichier versionné (ex) : `docs/anchor-aliases.json`
+- Fichier versionné (ex) : `src/anchors/anchor-aliases.json`
 - Format : `oldId -> newId` par page
 
 Ex en json :