V 1.004 ToDoList et Journal découpé

journal/ASPIC-Journal. 20. Dépôt GitHub et Mirroir Gitea.md

@@ -0,0 +1,28 @@
+## 20. Dépôt Git — GitHub + mirroir Gitea, limite technique découverte sur l'écriture depuis Claude (27-28 août 2026)
+
+**Contexte et objectif.** Reprise d'un sujet posé plus tôt (section 2 : "installer Git, non urgent") dans le projet dédié à la gestion du serveur, avec Jean-Marc et Claude côté serveur. Mise en place actée : dépôt privé sur **GitHub** (`https://github.com/JMP-MS/ASPIC`), token d'accès dédié nommé "Claude-ASPIC" (lecture/écriture) généré pour permettre à Claude de travailler avec le code du projet sans dépendre d'envois de fichiers répétés. **Gitea installé sur le VPS en mirroir de ce dépôt GitHub**, synchronisation automatique toutes les heures — Gitea n'est qu'un miroir de lecture côté serveur, pas un canal de travail pour Claude ; son installation/paramétrage relève du projet de gestion du serveur, pas de celui-ci.
+
+**Objectif principal recherché par Jean-Marc :** que Claude n'ait plus besoin de lui redemander les fichiers actuels du projet en début de session pour pouvoir travailler dessus.
+
+**Test réalisé le 28 août 2026 (session ASPIC) :**
+
+- **Lecture (clone) : fonctionnelle.** Le dépôt a été cloné avec succès dans l'environnement de travail de Claude en utilisant le token fourni. Structure du dépôt (au moment du test) organisée par type de fichier : `html/` (`identification.html`, `liste_contacts.html`), `php/` (`aspic.php`, `contacts.php`, `db.php`, `index.php`, `preferences.php`, `professions.php`, `prospect_doc.php`, `prospect_web-form-001_ajoute.php`, `prospects_core.php`, `prospects_verifier.php`, `realisations.php`, `statuts.php`), `png/` (`logo.png`), `polices/` (`MetroDF.ttf`, `MetroDF.woff2`). Contenu vérifié à jour au 28 août (`liste_contacts.html` contient bien les fonctionnalités du 27 août — barre de position, navigation PgUp/PgDn). Un seul commit dans l'historique à ce stade ("Add files via upload"), cohérent avec un dépôt tout juste initialisé par import du dossier existant plutôt que par un historique construit au fil de l'eau.
+- **Écriture (push) : bloquée, pas un problème de token.** Toute tentative de `git push` échoue avec une erreur explicite d'un proxy git propre à l'environnement cloud où tourne Claude : *"access denied by the git proxy: JMP-MS/ASPIC is not in this session's authorized repository set, so the proxy will not inject a credential for it."* Ce proxy intercepte toutes les connexions sortantes de Claude vers GitHub ; il autorise la lecture avec un token fourni par l'utilisateur, mais bloque l'écriture tant que le dépôt visé n'a pas été explicitement ajouté à une liste de dépôts autorisés pour la session — mécanisme de sécurité côté Anthropic (protection probable contre le risque qu'une session manipulée pousse des commits non désirés), pas un souci de permissions GitHub ou de scope du token. Aucun outil disponible côté Claude, dans cette session, pour ajouter ce dépôt à la liste autorisée. **Ce blocage est indépendant du protocole (HTTPS vs SSH) — il intercepte toute connexion sortante de Claude vers github.com avant même l'authentification. Confirmé toujours d'actualité le 30 août 2026 (sections 23 et 24) : ce n'est pas ce blocage qu'on a levé, seulement contourné en poussant depuis le VPS de Jean-Marc plutôt que depuis l'environnement de Claude.**
+- **Contournements envisagés et écartés :** pas de connecteur GitHub officiel disponible dans le catalogue de connecteurs de l'organisation (vérifié) ; pas d'accès terminal (shell) sur le PC de Jean-Marc via le pont vers son ordinateur (seuls des outils de lecture/écriture de fichiers sont disponibles pour cet appareil, pas d'exécution de commandes) — impossible donc de pousser depuis chez lui en s'appuyant sur son propre réseau. La commande `/install-github-app`, trouvée par Jean-Marc en ligne, a été vérifiée non pertinente : c'est une commande de l'application **Claude Code CLI locale** (à installer sur un poste, avec un vrai terminal), qui sert à configurer GitHub Actions sur un dépôt — sans rapport avec le mécanisme d'autorisation du proxy git rencontré ici, et de toute façon inaccessible depuis une session Cowork comme celle-ci (pas de terminal local équivalent). Recherche complémentaire : ce blocage correspond à une limitation connue et actuellement sans solution de contournement côté Cowork, sans mécanisme self-service pour autoriser un dépôt.
+
+**Décision retenue (workflow hybride, 28 août 2026) :**
+
+- Claude lit désormais l'état du code directement sur GitHub en début de session (plus besoin que Jean-Marc renvoie les fichiers pour que Claude retrouve le contexte).
+- Claude continue de livrer les nouvelles versions de fichiers en téléchargement dans la conversation, comme avant la mise en place de Git.
+- C'est Jean-Marc qui pousse ces fichiers sur GitHub (source de vérité du code), qui se synchronise ensuite automatiquement vers Gitea (mirroir serveur, toutes les heures) — Git n'automatise donc pas encore la livraison des fichiers de Claude vers le dépôt, seulement la lecture par Claude de l'état existant.
+- Jean-Marc a noté que ce n'est pas aussi pratique qu'espéré (l'objectif initial incluait l'écriture directe par Claude), mais le gain principal (fin des demandes de renvoi de fichiers) reste acquis.
+- Si un accès en écriture direct devient nécessaire plus tard, cela nécessiterait de vérifier côté paramètres de compte/organisation Claude l'existence d'un mécanisme d'autorisation de dépôt — non trouvé à ce stade, peut évoluer. **Mise à jour du 30 août 2026 : toujours non trouvé, mais un contournement pratique équivalent a été mis en place — voir section 23.**
+
+**Structure finale retenue pour le dépôt (28 août 2026, même session) — retour sur l'organisation par type de fichier.** Après un premier échange où Claude avait confirmé que l'organisation par type (`html/`, `php/`, `png/`, `polices/`) lui convenait (elle n'a pas besoin de refléter la structure de déploiement, qui reste à plat dans le volume `./src` — section 3), Jean-Marc est revenu sur ce choix en tenant compte de la contrainte pratique posée par le nouveau workflow : c'est lui qui pousse manuellement chaque livraison de Claude vers GitHub, par un simple glisser/déposer. **Décision finale : tous les fichiers applicatifs (html/php/png/polices) reviennent à plat à la racine du dépôt**, à l'exception d'un nouveau dossier **`bdd/`**, dédié aux exports de structure des tables ASPIC (CREATE TABLE à jour, dans l'esprit des fichiers "Tables V01/V02.txt" transmis en tout début de projet — section 2) — pour garder une trace versionnée du schéma de données à côté du code, mais distincte des fichiers applicatifs eux-mêmes. Un dépôt à plat présente d'ailleurs un avantage supplémentaire par rapport à l'organisation par type : il colle exactement à la structure de déploiement réelle (fichiers copiés à plat dans `./src`). **Structure confirmée toujours à plat le 30 août 2026 lors du clone effectué depuis le VPS (section 23), pas de dossier `bdd/` visible à ce moment-là (à vérifier avec Jean-Marc, hors périmètre de la session du 30 août).**
+
+**Migration prise en charge par Jean-Marc lui-même** (recopie des fichiers déjà présents dans les sous-dossiers vers la racine, suppression des anciens dossiers `html/`/`php/`/`png/`/`polices/`, création du dossier `bdd/`), directement sur l'interface GitHub — pas d'action de Claude possible ici (écriture bloquée, voir ci-dessus). **Point à observer, curiosité de Jean-Marc :** effet de cette réorganisation sur le mirroir Gitea au prochain rafraîchissement horaire. Un mirroir Git réplique en principe l'historique du dépôt d'origine tel quel (suppressions, renommages et recréations de fichiers inclus, comme n'importe quel autre commit) — un comportement sans surprise est donc attendu, mais cela reste à confirmer en pratique et n'a pas été vérifié à ce stade ; le paramétrage précis de ce mirroir Gitea relève du projet de gestion du serveur, pas de celui-ci.
+
+**Deux points relevés par Claude en parcourant le dépôt lors du test du 28 août, à clarifier avec Jean-Marc (état constaté avant la réorganisation ci-dessus, à revérifier une fois la migration faite) :**
+
+- `prospects_form_web.html` (formulaire public de prospection, livré et déployé le 26 août 2026 — voir section 18) était **absent du dépôt GitHub**. À vérifier si c'est un oubli lors de l'import initial ou un choix volontaire (peut-être parce que ce fichier vit sur un autre hébergement, `mevelia-solutions.bzh/form`, distinct du serveur ASPIC lui-même) — réponse de Jean-Marc encore en attente à ce stade.
+- Un fichier `php/index.php` présent dans le dépôt (redirection de la racine du domaine vers l'écran d'identification — voir commentaire du fichier lui-même) n'était jusqu'ici pas documenté dans ce journal. Sa cible de redirection est écrite en dur comme `identification.html` (avec l'extension `.html`) ; à vérifier auprès de Jean-Marc si le fichier déployé en production a bien été conservé sous ce nom précis pour que cette redirection fonctionne, ou si ce point mérite une correction — réponse de Jean-Marc encore en attente à ce stade.