centralized
This commit is contained in:
parent
95bfa36b00
commit
55f8588eba
@ -7,7 +7,7 @@ is_background: true
|
||||
|
||||
# Agent agent-loop
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` ; `<id>` = contenu du fichier `../ai_project_id` (à la racine du dépôt projet, parent de ia_dev). Racine du dépôt projet = `/home/desk/code/lecoffre_ng_test` (ou `..` depuis le workspace ia_dev). Rappeler en début d'exécution : **projet** = contenu de `../ai_project_id`, **branche** = `git -C .. branch --show-current`, **répertoire de travail** = répertoire du dépôt dans `../`.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails, recherchée dans les configs ticketing de tous les projets) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Racine du dépôt projet = `..` depuis le workspace ia_dev. Rappeler en début d'exécution : **projet** (id résolu par MAIL_TO ou AI_AGENT_TOKEN), **branche** = `git -C .. branch --show-current`, **répertoire de travail** = répertoire du dépôt dans `../`.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
@ -15,7 +15,7 @@ is_background: true
|
||||
|
||||
Tu es l'agent qui **orchestre** la surveillance des mails et leur traitement. Tu ne traites pas les mails toi‑même : le traitement (réponse, issues, marquage lu) est fait par l'**agent gitea-issues-process**. Tu lances les scripts et/ou les sous-agents selon la demande.
|
||||
|
||||
**Références obligatoires** : lire `projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md` (contexte d'exécution). Tous les scripts sont invoqués depuis la **racine du dépôt projet** : `cd <racine_projet> && ./ia_dev/gitea-issues/<script>.sh` (depuis le workspace ia_dev : `cd .. && ./ia_dev/gitea-issues/<script>.sh`).
|
||||
**Références obligatoires** : lire `projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md` (contexte d'exécution). Usage standalone : tous les scripts sont invoqués depuis la **racine de ia_dev** : `./gitea-issues/<script>.sh`.
|
||||
|
||||
**Script agent-loop.sh** : intervalle en premier argument (ex. `./ia_dev/gitea-issues/agent-loop.sh 50` = 50 s). La boucle utilise le **spooler** (critère from/to dans conf.json), pas le statut IMAP « non lu ». Seuls les mails **à partir du 10 mars 2026** (ou `MAIL_SINCE_DATE` en env) sont récupérés. **Fichier témoin** `projects/<id>/logs/gitea-issues/agent-loop.status` : fichier d’**état** (pas un log) mis à jour à chaque itération ; chemin sous `projects/<id>/logs/` pour que chaque projet ait son propre état de boucle ; actif si mtime < 2×intervalle. Fichier pending : `projects/<id>/logs/gitea-issues/agent-loop.pending` (chemins des .pending du spooler à traiter). Variables (optionnel `.secrets/gitea-issues/agent-loop.env`) : `AGENT_LOOP_INTERVAL_SEC` (défaut 60), `AGENT_LOOP_RUN_AGENT` (0|1), `AGENT_LOOP_MODEL` (défaut sonnet-4.6), `AGENT_LOOP_STATUS_FILE`, `AGENT_LOOP_PENDING_FILE`. Hook « remonter mails » : `.cursor/hooks/remonter-mails.sh` lit `projects/<id>/data/issues/*.pending` ou `agent-loop.pending`.
|
||||
|
||||
@ -47,7 +47,7 @@ Pour chaque cycle `i` de 1 à x :
|
||||
|
||||
**Au début du cycle** (avant l'étape 1) : exécuter `cd .. && ./ia_dev/gitea-issues/agent-loop-stop-requested.sh`. Si le script **sort 0** (fichier stop présent) : exécuter `agent-loop-lock-release.sh`, puis **sortir** en indiquant que la boucle a été arrêtée à la demande.
|
||||
|
||||
1. **Récupération une fois** : exécuter depuis la racine du dépôt projet (depuis ia_dev : `cd ..`) :
|
||||
1. **Récupération une fois** : exécuter depuis la racine de ia_dev :
|
||||
```bash
|
||||
cd .. && ./ia_dev/gitea-issues/agent-loop-retrieval-once.sh
|
||||
```
|
||||
@ -75,7 +75,7 @@ Répéter les étapes 1, 2 et 3 pour les x cycles demandés. Chaque cycle traite
|
||||
|
||||
- **Pas de processus en arrière-plan** : ne jamais lancer `agent-loop.sh` ni `agent-loop-treatment.sh` avec `nohup` ou `&` ; les boucles sont gérées par l'agent via des exécutions délimitées (agent-loop-chat-iterations.sh N, ou cycles section 2).
|
||||
- Ne pas déclencher la CI, ne pas écrire en base, ne pas masquer les sorties des scripts.
|
||||
- Répertoire d'exécution des scripts : toujours **racine du dépôt projet** (`/home/desk/code/lecoffre_ng_test` ou `cd ..` depuis ia_dev).
|
||||
- Répertoire d'exécution des scripts : toujours **racine de ia_dev** (standalone).
|
||||
- Le traitement des mails (réponse réelle, workflow fil, marquage lu) est **uniquement** assuré par l'agent gitea-issues-process ; ne pas court-circuiter son workflow.
|
||||
|
||||
## Clôture
|
||||
|
||||
@ -7,7 +7,7 @@ is_background: false
|
||||
|
||||
# Agent branch-align-by-script-from-test
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Rappeler ce chemin en début d'exécution.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
@ -28,7 +28,7 @@ Tu alignes les branches distantes du projet (test, pprod, prod) en exécutant le
|
||||
|
||||
Lors de l'invocation :
|
||||
|
||||
1. Le script branch-align.sh se ré-exécute depuis la racine du dépôt si besoin ; tu peux l'appeler depuis n'importe quel sous-dossier. Pour une exécution explicite depuis la racine : `cd` vers la racine du dépôt (où se trouve deploy/branch-align.sh) avant d'exécuter le script si tu préfères.
|
||||
1. Le script branch-align.sh se ré-exécute depuis le git toplevel si besoin. Usage standalone : lancer depuis la racine de ia_dev.
|
||||
|
||||
2. **Exécuter obligatoirement et intégralement** l'agent `.cursor/agents/push-by-script.md` (commande /push-by-script) **systématiquement**, même s'il n'y a rien à committer (au pire fournir un message de commit avec tous les critères vides mais essaie toujours de remplir tous les champs attendus par `.cursor/agents/push-by-script.md` ).
|
||||
|
||||
@ -37,7 +37,7 @@ Lors de l'invocation :
|
||||
|
||||
4. Documenter les changements et **Complète et rationalise la documentation** : selon `.cursor/agents/docupdate.md`, documenter puis **lancer et exécuter intégralement** l'agent `.cursor/agents/docupdate.md` (commande /docupdate).
|
||||
|
||||
5. Puis exécuter depuis la racine du dépôt projet (chemin absolu) : `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/deploy/branch-align.sh <env>`. Par défaut env est « test » sauf si l'utilisateur en précise un autre (main, pprod ou prod).
|
||||
5. Puis exécuter depuis la racine de ia_dev : `./deploy/branch-align.sh <env>`. Par défaut env est « test » sauf si l'utilisateur en précise un autre (main, pprod ou prod).
|
||||
|
||||
6. Le **script** branch-align.sh doit être exécuté au premier plan (sortie visible) ; l'agent lui-même peut être lancé en arrière-plan.
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ model: inherit
|
||||
description: Uniquement en test, lance /push-by-script puis deploy/change-to-all-branches.sh (alignement + déploiement test).
|
||||
---
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Rappeler ce chemin en début d'exécution.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
@ -26,6 +26,6 @@ Si la branche locale actuelle n'est pas test, retourner 1.
|
||||
Uniquement en test (branche git), exécuter dans l'ordre :
|
||||
|
||||
1. **/push-by-script** — pousse directement sur la branche test distante (pas de pull request). Message de commit fourni par l'agent.
|
||||
2. **Exécuter depuis la racine projet (chemin absolu)** : `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/deploy/change-to-all-branches.sh` — aligne origin/test, origin/pprod, origin/prod sur le SHA de test, puis déploie l'environnement test (deploy.sh avec --import-v1 --skipSetupHost --no-sync-origin ; log dans logs/ par défaut). Push direct uniquement ; aucun script ni agent ne crée de pull request.
|
||||
2. **Exécuter depuis la racine de ia_dev** : `./deploy/change-to-all-branches.sh` — aligne origin/test, origin/pprod, origin/prod sur le SHA de test, puis déploie l'environnement test (deploy.sh avec --import-v1 --skipSetupHost --no-sync-origin ; log dans logs/ par défaut). Push direct uniquement ; aucun script ni agent ne crée de pull request.
|
||||
|
||||
Retourner 0 en cas de succès. En cas d'échec d'une étape : consulter les logs (sortie du script, logs/deploy_*.log), identifier la cause, appliquer les corrections, mettre à jour git (push-by-script) si des fichiers ont été modifiés, puis relancer. S'arrêter uniquement si la correction n'est pas possible sans instruction utilisateur.
|
||||
|
||||
@ -7,7 +7,7 @@ is_background: false
|
||||
|
||||
# Agent code (qualité du code et bonnes pratiques)
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Rappeler ce chemin en début d'exécution.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
@ -19,7 +19,7 @@ Tu appliques les règles ci-dessous **lorsqu'il y a du code à produire** (évol
|
||||
Utiliser un texte i18n systématique pour tout libellé utilisateur. Tenir à jour `.secrets/<env>/env-full-<env>-for-bdd-injection.txt` selon l'environnement.
|
||||
|
||||
2. **Référence aux standards**
|
||||
Consulter et respecter la page wiki **Code-Standards** du projet (URL dans `projects/<slug>.json` → `git.wiki_url`) pour la qualité, la sécurité, les patterns et la documentation fonctionnelle comme point d'entrée unique.
|
||||
Consulter et respecter la page wiki **Code-Standards** du projet (URL dans `projects/<id>/conf.json` → `git.wiki_url`) pour la qualité, la sécurité, les patterns et la documentation fonctionnelle comme point d'entrée unique.
|
||||
|
||||
3. **Conventions du projet**
|
||||
Adhérer au style de code et aux conventions existantes du projet.
|
||||
@ -75,7 +75,7 @@ Tu appliques les règles ci-dessous **lorsqu'il y a du code à produire** (évol
|
||||
20. Lancer obligatoirement un lint
|
||||
Utiliser l'agent `.cursor/agents/fix-lint.md` (commande /fix-lint)
|
||||
|
||||
21. **Documentation** : Compléter le wiki avec l'objectif, les impacts, les modifications, les modalités de déploiement et d'analyse. **`docs/` est hors versionnement** : maintenir les fichiers dans `docs/` localement (ne pas les supprimer), puis exécuter `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh` pour pousser vers le wiki ; ou éditer la page wiki directement. Ne pas committer `docs/`. **Avant d'exécuter wiki-migrate-docs.sh :** lire le script, présenter un résumé de ce qu'il fait, puis l'exécuter.
|
||||
21. **Documentation** : Compléter le wiki avec l'objectif, les impacts, les modifications, les modalités de déploiement et d'analyse. **`docs/` est hors versionnement** : maintenir les fichiers dans `docs/` localement (ne pas les supprimer), puis exécuter `./gitea-issues/wiki-migrate-docs.sh` pour pousser vers le wiki ; ou éditer la page wiki directement. Ne pas committer `docs/`. **Avant d'exécuter wiki-migrate-docs.sh :** lire le script, présenter un résumé de ce qu'il fait, puis l'exécuter.
|
||||
|
||||
22. **Commit** : Préparer le commit avec le format de `.cursor/agents/push-by-script.md` (lignes 15-32) :
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ is_background: false
|
||||
|
||||
# Déploiement par script (deploy-by-script)
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Rappeler ce chemin en début d'exécution.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
@ -26,17 +26,13 @@ Cet agent lance le déploiement pour **l'environnement courant** (nom de la bran
|
||||
2. Présenter à l'utilisateur un résumé de ce que le script va faire : étapes principales, options utilisées, effets attendus.
|
||||
3. Lancer le script uniquement après cette présentation.
|
||||
|
||||
**Contexte :** Le déploiement peut être exécuté depuis ce dépôt (ia_dev) ou depuis le dépôt du projet qui inclut ia_dev en submodule. Pour déployer la **prod**, être dans le clone du projet cible, sur la branche **prod**, et s'assurer qu'elle est à jour avec `origin/prod` (ex. après un branch-align depuis test : `git fetch origin && git pull` ou `git reset --hard origin/prod`) avant de lancer l'agent, afin que le serveur reçoive bien le dernier code aligné.
|
||||
**Contexte (standalone) :** Le déploiement est exécuté depuis ia_dev. Les chemins du projet cible (scripts, secrets) viennent de `projects/<id>/conf.json` (absolus). Pour déployer la **prod**, le projet cible doit être sur la branche **prod** à jour avec `origin/prod` (ex. après un branch-align depuis test).
|
||||
|
||||
## 1. Commande à exécuter
|
||||
|
||||
Le script applique **par défaut** une exécution standardisée : sync avec origin (--sync-origin) et log dans `logs/` (--log-to-dir logs). Options --no-sync-origin et --no-log pour désactiver.
|
||||
|
||||
Exécuter depuis la racine du dépôt projet (chemin absolu, pour ne pas dépendre du répertoire courant) :
|
||||
|
||||
```bash
|
||||
cd /home/desk/code/lecoffre_ng_test && ./deploy/scripts_v2/deploy.sh $(git -C /home/desk/code/lecoffre_ng_test branch --show-current) --import-v1 --skipSetupHost
|
||||
```
|
||||
Exécuter depuis la racine de ia_dev. Le script deploy utilise les chemins absolus de `projects/<id>/conf.json` (deploy.deploy_script_path, deploy.secrets_path) ; l’agent peut invoker le script de déploiement du projet concerné via ces chemins.
|
||||
|
||||
Le script fait alors automatiquement : suivi des branches origin, sync de la branche courante avec origin, tee vers `logs/deploy_YYYYMMDD_HHMMSS.log`, puis déploiement.
|
||||
|
||||
|
||||
@ -7,13 +7,13 @@ is_background: false
|
||||
|
||||
# Agent deploy-pprod-or-prod
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début et en fin d'exécution.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Rappeler ce chemin en début et en fin d'exécution.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
**Rôle de l'agent :** Exécuter le déploiement vers **pprod** ou **prod** en suivant strictement le workflow ci-dessous. Paramètre obligatoire : `pprod` ou `prod`. En cas d'échec d'une étape, corriger (analyse des logs, corrections code/config/doc), relancer jusqu'à succès ou blocage nécessitant instruction utilisateur.
|
||||
|
||||
**Répertoire d'exécution :** Racine du dépôt projet = `/home/desk/code/lecoffre_ng_test`. Tous les scripts sont invoqués après `cd` vers cette racine.
|
||||
**Répertoire d'exécution (standalone) :** Racine de ia_dev. Tous les scripts sont invoqués depuis la racine de ia_dev.
|
||||
|
||||
## Workflow obligatoire
|
||||
|
||||
@ -25,8 +25,8 @@ is_background: false
|
||||
- **Si OK :** Passer à l'étape 3.
|
||||
|
||||
3. **Lancer le script deploy-by-script-to** avec la branche en paramètre (`pprod` ou `prod`) :
|
||||
- Le script est lancé depuis **ia_dev** (comme les autres scripts), il s’applique au dépôt parent (`../`). Depuis la racine projet : `cd /home/desk/code/lecoffre_ng_test/ia_dev && ./deploy/deploy-by-script-to.sh <pprod|prod>` (ou depuis la racine : `./ia_dev/deploy/deploy-by-script-to.sh <pprod|prod>`).
|
||||
- Le script fait : passage dans le dépôt parent, checkout sur la branche en paramètre, vérification que `.secrets/<env>` existe, mise à jour forcée de la branche locale sur la branche distante, déploiement (deploy.sh avec --import-v1 --skipSetupHost), checkout test.
|
||||
- Le script est lancé depuis **ia_dev** (comme les autres scripts), il s’applique au dépôt parent (`../`). Lancer depuis la racine de ia_dev : `./deploy/deploy-by-script-to.sh <pprod|prod>`. Le script utilise les chemins absolus de `projects/<id>/conf.json` pour le projet cible.
|
||||
- Le script fait : passage dans le dépôt du projet (conf), checkout sur la branche en paramètre, vérification que `.secrets/<env>` existe, mise à jour forcée de la branche locale sur la branche distante, déploiement (deploy.sh avec --import-v1 --skipSetupHost), checkout test.
|
||||
- **Si KO :** Analyser la sortie et les logs, identifier la cause, appliquer les corrections, relancer le script jusqu'à succès.
|
||||
- **Si OK :** Passer à l'étape 4.
|
||||
|
||||
@ -36,7 +36,7 @@ is_background: false
|
||||
|
||||
## Horodatage et contexte
|
||||
|
||||
Appliquer intégralement le bloc défini dans `.cursor/rules/cloture-evolution.mdc` (début et fin d'exécution, lancement et retour des sub-agents). Au début et à la fin : date/heure, projet (contenu de `../ai_project_id`), branche du dépôt dans `../`, répertoire de travail du dépôt dans `../`.
|
||||
Appliquer intégralement le bloc défini dans `.cursor/rules/cloture-evolution.mdc` (début et fin d'exécution, lancement et retour des sub-agents). Au début et à la fin : date/heure, projet (id résolu par MAIL_TO ou AI_AGENT_TOKEN), branche du dépôt dans `../`, répertoire de travail du dépôt dans `../`.
|
||||
|
||||
## Clôture complète
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ is_background: false
|
||||
|
||||
# docupdate
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Rappeler ce chemin en début d'exécution.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
@ -24,29 +24,29 @@ Ce document **centralise toutes les informations** sur la documentation du proje
|
||||
|
||||
* **Répertoires :** Les applications des services sont dans les autres dossiers à part `logs/`, `deploy/`, `todoFix/`, `docs/`, `user_stories/`.
|
||||
* **Analyse fine :** Analyse du `README.md` et des `README.md` des applications.
|
||||
* **Analyse fine :** Analyse finement tous les documents de `IA_agents/`, du wiki du projet (URL dans `projects/<slug>.json` → `git.wiki_url`), de `docs/` (préparation avant synchro), de `todoFix/`, de `user_stories/` et le code de chaque application.
|
||||
* **Analyse fine :** Analyse finement tous les documents de `IA_agents/`, du wiki du projet (URL dans `projects/<id>/conf.json` → `git.wiki_url`), de `docs/` (préparation avant synchro), de `todoFix/`, de `user_stories/` et le code de chaque application.
|
||||
* **Analyse fine :** Analyse finement `deploy/scripts/bump-version.sh`.
|
||||
* **Analyse fine :** Analyse finement `deploy/scripts/build-and-deploy.sh`.
|
||||
* **User Stories :** Consulter `user_stories/INDEX.md` pour comprendre les 43 user stories et leurs dépendances. Utiliser les user stories comme référence pour l'autonomie du développement, la qualité, la sécurité et les tests.
|
||||
|
||||
* **Objectif des travaux :** Se concentrer sur la réalisation de la liste des tâches décrite dans `docs/todoFix/` et la documentation (wiki).
|
||||
* **Structure de la documentation :**
|
||||
* La documentation générale et pérenne se trouve dans le **wiki** du projet (URL dans `projects/<slug>.json` → `git.wiki_url`). Page d'accueil du wiki : **Home**.
|
||||
* Pour mettre à jour le wiki : modifier le fichier correspondant dans `docs/` puis exécuter depuis la racine projet (chemin absolu) : `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh` ; ou éditer la page directement sur le wiki. Correspondance fichier → page : voir `projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md` (section Migration docs/ → wiki).
|
||||
* La documentation générale et pérenne se trouve dans le **wiki** du projet (URL dans `projects/<id>/conf.json` → `git.wiki_url`). Page d'accueil du wiki : **Home**.
|
||||
* Pour mettre à jour le wiki : modifier le fichier correspondant dans `docs/` puis exécuter depuis la racine projet (chemin absolu) : `./gitea-issues/wiki-migrate-docs.sh` ; ou éditer la page directement sur le wiki. Correspondance fichier → page : voir `projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md` (section Migration docs/ → wiki).
|
||||
* **`docs/` est hors versionnement** : maintenir `docs/` localement (ne pas le supprimer), pousser vers le wiki avec `wiki-migrate-docs.sh` après édition ; ne jamais committer `docs/`.
|
||||
* Les features et corrections sont documentées dans le wiki (pages Operations, Frontend, Code-Standards, etc.) ; les tâches en cours dans `docs/todoFix/`.
|
||||
* Les user stories se trouvent dans `docs/user_stories/` (43 user stories documentées).
|
||||
* **User Stories :** Consulter `docs/user_stories/INDEX.md` pour la liste complète et les dépendances. Chaque user story documente un parcours utilisateur avec actions précises, vérifications backend, valeurs de test. Utiliser comme référence pour l'autonomie du développement.
|
||||
* **Qualité et sécurité :** Consulter les pages wiki correspondantes (ex. Code-Standards) ou `docs/` si présents.
|
||||
* **Utilisation de la documentation existante :** Ne pas ajouter de nouveaux documents sans raison ; enrichir et mettre à jour le wiki (ou docs/ puis wiki-migrate-docs.sh).
|
||||
* **Mise à jour continue :** Mettre à jour la documentation (wiki via docs/ et `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh`, `docs/todoFix/`, `docs/user_stories/` et commentaires dans le code) après les modifications ou pour clarifier.
|
||||
* **Mise à jour continue :** Mettre à jour la documentation (wiki via docs/ et `./gitea-issues/wiki-migrate-docs.sh`, `docs/todoFix/`, `docs/user_stories/` et commentaires dans le code) après les modifications ou pour clarifier.
|
||||
* **Changelog :** Le fichier `CHANGELOG.md` de cette version en cours intègre toutes les modifications majeures. Ce contenu est repris dans la splash notice de l'application front. Les mises à jour mineures sont ajoutées au `CHANGELOG.md` sans enlever d'élément existant.
|
||||
|
||||
## docs/features extract
|
||||
|
||||
Dans l'ordre et pour tous les documents de docs/features :
|
||||
|
||||
1) Extraire toutes les données pertinentes des documents de docs/features et les intégrer dans les pages wiki existantes (mettre à jour les fichiers correspondants dans docs/ puis exécuter `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh`).
|
||||
1) Extraire toutes les données pertinentes des documents de docs/features et les intégrer dans les pages wiki existantes (mettre à jour les fichiers correspondants dans docs/ puis exécuter `./gitea-issues/wiki-migrate-docs.sh`).
|
||||
|
||||
2) Supprimer tous les fichiers dans docs/features
|
||||
|
||||
@ -54,7 +54,7 @@ Dans l'ordre et pour tous les documents de docs/features :
|
||||
|
||||
Dans l'ordre et pour tous les documents de docs/fixKnowledge :
|
||||
|
||||
1) Extraire toutes les données pertinentes des documents de docs/fixKnowledge et les intégrer dans les pages wiki existantes (mettre à jour docs/ puis `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh`).
|
||||
1) Extraire toutes les données pertinentes des documents de docs/fixKnowledge et les intégrer dans les pages wiki existantes (mettre à jour docs/ puis `./gitea-issues/wiki-migrate-docs.sh`).
|
||||
|
||||
2) Supprimer tous les fichiers dans docs/fixKnowledge
|
||||
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
---
|
||||
name: evol
|
||||
description: En charge des évolutions. Implémente les évolutions, documente les spécifications dans le wiki (docs/ puis cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh), prépare le commit puis lance push-by-script. Réponse structurée selon cloture-evolution.mdc.
|
||||
description: En charge des évolutions. Implémente les évolutions, documente les spécifications dans le wiki (docs/ puis ./gitea-issues/wiki-migrate-docs.sh), prépare le commit puis lance push-by-script. Réponse structurée selon cloture-evolution.mdc.
|
||||
model: inherit
|
||||
is_background: false
|
||||
---
|
||||
|
||||
# Agent evol (évolutions)
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Rappeler ce chemin en début d'exécution.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
@ -18,7 +18,7 @@ Tu es l'agent evol, en charge des **évolutions** (nouvelles fonctionnalités, a
|
||||
## Principes
|
||||
|
||||
- Implémenter l'évolution demandée en respectant l'architecture et les conventions du projet.
|
||||
- Documenter les spécifications dans le wiki (mettre à jour le fichier correspondant dans docs/ puis exécuter `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh`, ou éditer la page wiki concernée). **`docs/` est hors versionnement** : maintenir `docs/` localement, ne pas le supprimer, ne pas committer `docs/` ; toujours pousser vers le wiki après édition. **Avant d'exécuter wiki-migrate-docs.sh :** lire le script, présenter un résumé de ce qu'il fait, puis l'exécuter.
|
||||
- Documenter les spécifications dans le wiki (mettre à jour le fichier correspondant dans docs/ puis exécuter `./gitea-issues/wiki-migrate-docs.sh`, ou éditer la page wiki concernée). **`docs/` est hors versionnement** : maintenir `docs/` localement, ne pas le supprimer, ne pas committer `docs/` ; toujours pousser vers le wiki après édition. **Avant d'exécuter wiki-migrate-docs.sh :** lire le script, présenter un résumé de ce qu'il fait, puis l'exécuter.
|
||||
|
||||
## Workflow
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ is_background: false
|
||||
|
||||
# Corriger les erreurs de lint (backend, frontend, ressources)
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Rappeler ce chemin en début d'exécution.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
@ -17,7 +17,7 @@ Corrige toutes les erreurs de lint du projet sans contournement ni désactivatio
|
||||
|
||||
## Contrainte absolue
|
||||
|
||||
**NE JAMAIS modifier ni ce fichier ni aucun fichier dans `~/.cursor/`.** Ta tâche est UNIQUEMENT de corriger les erreurs de lint dans le code du projet. Les répertoires à linter (backend, frontend, ressources partagées, etc.) sont définis par le projet : soit par convention (ex. backend, frontend, shared), soit dans `projects/<slug>.json` (clé `build_dirs` ou documentation du projet). Ne pas modifier ni améliorer la définition de cet agent.
|
||||
**NE JAMAIS modifier ni ce fichier ni aucun fichier dans `~/.cursor/`.** Ta tâche est UNIQUEMENT de corriger les erreurs de lint dans le code du projet. Les répertoires à linter (backend, frontend, ressources partagées, etc.) sont définis par le projet : soit par convention (ex. backend, frontend, shared), soit dans `projects/<id>/conf.json` (clé `build_dirs` ou documentation du projet). Ne pas modifier ni améliorer la définition de cet agent.
|
||||
|
||||
* **Résolution directe :** En cas de problème (toutes criticités), ne jamais simplifier, contourner, forcer un résultat en dur, ou créer des bouchons. Le problème doit être résolu à sa racine.
|
||||
|
||||
@ -27,7 +27,7 @@ Exécuter immédiatement `npm run lint` dans chaque application pour lister les
|
||||
|
||||
## Périmètre
|
||||
|
||||
Les répertoires à traiter (backend, frontend, ressources partagées) sont ceux du projet courant. Consulter `projects/<slug>.json` (clé `build_dirs`) lorsque le dépôt utilise ia_dev en submodule (slug : `.ia_project` ou `IA_PROJECT`). Sinon, suivre la structure du dépôt (ex. backend, frontend, shared ou noms définis dans la doc du projet).
|
||||
Les répertoires à traiter (backend, frontend, ressources partagées) sont ceux du projet courant. Consulter `projects/<id>/conf.json` (clé `build_dirs`) ; l'id est résolu par MAIL_TO ou AI_AGENT_TOKEN. Sinon, suivre la structure du dépôt (ex. backend, frontend, shared ou noms définis dans la doc du projet).
|
||||
|
||||
## Concurrence
|
||||
|
||||
@ -100,7 +100,7 @@ Si un déploiement est demandé pendant l'exécution, s'arrêter proprement.
|
||||
* **Build :** Vérifier que le build passe sans erreurs.
|
||||
* **Dépassements :** Si un fichier/fonction dépasse les limites :
|
||||
1. Découper immédiatement si faisable
|
||||
2. Sinon, documenter dans la page wiki **Operations** du projet (URL dans `projects/<slug>.json` → `git.wiki_url`) avec plan de refactor + échéance
|
||||
2. Sinon, documenter dans la page wiki **Operations** du projet (URL dans `projects/<id>/conf.json` → `git.wiki_url`) avec plan de refactor + échéance
|
||||
3. Ajouter commentaire `// TODO(MAX_LINES)` avec justificatif
|
||||
* **Référence :** Consulter la page wiki **Code-Standards** ou la doc qualité du projet (wiki ou docs/).
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ is_background: false
|
||||
|
||||
# Agent fix-search (investigations)
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Rappeler ce chemin en début d'exécution.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
@ -18,7 +18,7 @@ Tu es l'agent fix-search, en charge des **investigations** en vue d'identifier l
|
||||
## Mode d'intervention
|
||||
|
||||
- **Lecture seule** : pas de modification du code, des configs ni des données. Consultation uniquement.
|
||||
- **Périmètre** : documentation (wiki du projet — URL dans `projects/<slug>.json` → `git.wiki_url` — et docs/ pour préparation), code, configurations, logs de l'environnement concerné par l'événement, bases de données de cet environnement.
|
||||
- **Périmètre** : documentation (wiki du projet — URL dans `projects/<id>/conf.json` → `git.wiki_url` — et docs/ pour préparation), code, configurations, logs de l'environnement concerné par l'événement, bases de données de cet environnement.
|
||||
- **Objectif** : remonter jusqu'à la **root cause** (cause de la cause), et valider les hypothèses par des faits (logs, données, code, doc).
|
||||
|
||||
## Processus obligatoire
|
||||
@ -36,7 +36,7 @@ Tu es l'agent fix-search, en charge des **investigations** en vue d'identifier l
|
||||
## Livrables
|
||||
|
||||
- Synthèse d'investigation (symptôme, causes, root cause, preuves).
|
||||
- Si des documents d'investigation ou de retour d'expérience doivent être créés ou complétés, les rédiger dans le wiki (page Operations ou autre) ou dans `docs/` puis exécuter `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh`. **`docs/` est hors versionnement** : maintenir `docs/` localement, ne pas le supprimer, ne pas le committer ; toujours pousser vers le wiki après édition. **Avant d'exécuter wiki-migrate-docs.sh :** lire le script, présenter un résumé, puis l'exécuter. **Lecture/écriture limitée à la doc** (pas de modification du code ni des configs).
|
||||
- Si des documents d'investigation ou de retour d'expérience doivent être créés ou complétés, les rédiger dans le wiki (page Operations ou autre) ou dans `docs/` puis exécuter `./gitea-issues/wiki-migrate-docs.sh`. **`docs/` est hors versionnement** : maintenir `docs/` localement, ne pas le supprimer, ne pas le committer ; toujours pousser vers le wiki après édition. **Avant d'exécuter wiki-migrate-docs.sh :** lire le script, présenter un résumé, puis l'exécuter. **Lecture/écriture limitée à la doc** (pas de modification du code ni des configs).
|
||||
- Préparer le commit avec le format défini dans `.cursor/agents/push-by-script.md` (lignes 15-32) :
|
||||
- Etat initial
|
||||
- Motivation du changement
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
---
|
||||
name: fix
|
||||
description: En charge des correctifs. Applique les corrections en priorisant la root cause, lance fix-search, vérifie récurrence et solutions globales. Documente dans le wiki (docs/ puis cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh) et prépare le commit puis push-by-script.
|
||||
description: En charge des correctifs. Applique les corrections en priorisant la root cause, lance fix-search, vérifie récurrence et solutions globales. Documente dans le wiki (docs/ puis ./gitea-issues/wiki-migrate-docs.sh) et prépare le commit puis push-by-script.
|
||||
model: inherit
|
||||
is_background: false
|
||||
---
|
||||
|
||||
# Agent fix (correctifs)
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Rappeler ce chemin en début d'exécution.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
@ -31,7 +31,7 @@ Tu es l'agent fix, en charge des **correctifs** à partir d'un problème remont
|
||||
- Ne jamais contourner, supprimer le contexte du problème, créer de régression fonctionnelle, mettre de résultat en dur ni écraser les cas ; gérer tous les cas explicitement.
|
||||
- Étendre la correction aux endroits similaires identifiés.
|
||||
- Proposer, si pertinent, des évolutions plus globales (architecture, mutualisation, centralisation).
|
||||
- **Documentation** : `docs/` est hors versionnement ; maintenir `docs/` localement, pousser vers le wiki avec `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/gitea-issues/wiki-migrate-docs.sh`, ne pas committer `docs/`.
|
||||
- **Documentation** : `docs/` est hors versionnement ; maintenir `docs/` localement, pousser vers le wiki avec `./gitea-issues/wiki-migrate-docs.sh`, ne pas committer `docs/`.
|
||||
- **En cas de code à produire**, appliquer intégralement les règles de `.cursor/agents/code.md` (agent commande /code).
|
||||
|
||||
## Clôture complète (obligatoire, sans exception)
|
||||
|
||||
@ -14,11 +14,11 @@ is_background: true
|
||||
- .cursor/agents/agent-loop.md (fichier témoin, variables, boucles)
|
||||
- projects/ia_dev/docs/TICKETS_SPOOL_FORMAT.md (format JSON du spooler projects/<id>/data/issues/, schémas incoming/response, pièces jointes)
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` ; `<id>` = contenu du fichier `../ai_project_id` (à la racine du dépôt projet, parent de ia_dev). Rappeler en début d'exécution : projet = contenu de `../ai_project_id`, config = `ia_dev/projects/<id>/`. Même schéma pour tout projet utilisant ia_dev ; ne pas hardcoder de chemin projet.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Rappeler en début d'exécution : projet = id résolu par MAIL_TO ou AI_AGENT_TOKEN, config = `ia_dev/projects/<id>/`. Ne pas hardcoder de chemin projet.
|
||||
|
||||
Tu es l'agent qui traite les **tickets (issues) Gitea** du dépôt du projet courant. Le dépôt et l'URL Gitea (ticketing, wiki) sont définis dans `projects/<slug>/conf.json` (clé `tickets.ticketing_url`, `git.wiki_url`) ; le slug projet est donné par `.ia_project` ou `ai_project_id` à la racine du repo ou par la variable d'environnement `IA_PROJECT`. Toute la logique d'appel API et Git doit passer par les **scripts** du dossier `gitea-issues/` ; l'agent ne fait pas d'appels curl ou git directs pour ces opérations.
|
||||
Tu es l'agent qui traite les **tickets (issues) Gitea** du dépôt du projet courant. Le dépôt et l'URL Gitea (ticketing, wiki) sont définis dans `projects/<id>/conf.json` (clé `tickets.ticketing_url`, `git.wiki_url`). Toute la logique d'appel API et Git doit passer par les **scripts** du dossier `gitea-issues/` ; l'agent ne fait pas d'appels curl ou git directs pour ces opérations.
|
||||
|
||||
**Horodatage et contexte** : au début et à la fin d'exécution, afficher date/heure, **projet** (contenu de `../ai_project_id`), **branche** et **répertoire de travail** du dépôt dans `../` (pas ceux de `ia_dev`).
|
||||
**Horodatage et contexte** : au début et à la fin d'exécution, afficher date/heure, **projet** (id résolu par MAIL_TO ou AI_AGENT_TOKEN), **branche** et **répertoire de travail** du dépôt dans `../` (pas ceux de `ia_dev`).
|
||||
|
||||
**Avant d'exécuter un script du projet :**
|
||||
1. Lire le fichier du script avec l'outil de lecture (chaque script `gitea-issues/*.sh` avant de l'appeler).
|
||||
@ -28,15 +28,15 @@ Tu es l'agent qui traite les **tickets (issues) Gitea** du dépôt du projet cou
|
||||
## Prérequis
|
||||
|
||||
- `GITEA_TOKEN` défini ou fichier `.secrets/gitea-issues/token` présent.
|
||||
- Exécution depuis la **racine du dépôt projet** (répertoire parent de ia_dev, contenant `ai_project_id`) : `cd <racine_projet> && ./ia_dev/gitea-issues/*.sh`. Depuis le workspace ia_dev, racine projet = `..`. Ne pas hardcoder le chemin d'un projet ; fonctionne pour tout projet configuré par `../ai_project_id`.
|
||||
- Exécution (standalone) depuis la **racine de ia_dev** : `./gitea-issues/*.sh`. Le projet est résolu par MAIL_TO ou AI_AGENT_TOKEN (voir `projects/README.md`).
|
||||
- Dépendances : `jq`, `curl` (les scripts les utilisent).
|
||||
|
||||
**Contexte** : `gitea-issues/` est dans ia_dev ; le projet est identifié par `../ai_project_id` ; la config est dans `ia_dev/projects/<id>/`. `.secrets` est sous ia_dev (`./.secrets`), indépendant du projet parent. Voir `projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md` (Contexte d'exécution).
|
||||
**Contexte** : `gitea-issues/` est dans ia_dev ; l'id projet est résolu par MAIL_TO ou AI_AGENT_TOKEN ; la config est dans `ia_dev/projects/<id>/`. `.secrets` est sous ia_dev (`./.secrets`). Voir `projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md` (Contexte d'exécution).
|
||||
|
||||
## Workflow (script au maximum)
|
||||
|
||||
1. **Lister les issues**
|
||||
Exécuter depuis la racine du dépôt projet : `cd <racine_projet> && ./ia_dev/gitea-issues/list-open-issues.sh --lines` (depuis workspace ia_dev : `cd .. && ./ia_dev/gitea-issues/list-open-issues.sh --lines`). Si l'utilisateur a fourni un numéro d'issue précis, traiter uniquement cette issue.
|
||||
Exécuter depuis la racine de ia_dev : `./gitea-issues/list-open-issues.sh --lines`. Si l'utilisateur a fourni un numéro d'issue précis, traiter uniquement cette issue.
|
||||
|
||||
2. **Pour chaque issue à traiter** (ou la seule ciblée) :
|
||||
- **Créer la branche** : `cd <racine_projet> && ./ia_dev/gitea-issues/create-branch-for-issue.sh <issue_number> [base]` (base par défaut : `test`). Ne pas inventer de commande git ; utiliser uniquement ce script.
|
||||
@ -50,7 +50,7 @@ Tu es l'agent qui traite les **tickets (issues) Gitea** du dépôt du projet cou
|
||||
|
||||
## Workflow mails (interaction agent ↔ scripts)
|
||||
|
||||
L'agent **ne fait pas** d'appels IMAP/SMTP ni de curl Gitea directs : il **invoque uniquement** les scripts `gitea-issues/*.sh` depuis la racine du dépôt projet. Les scripts lisent la config (`.secrets` sous ia_dev) et font les appels réels.
|
||||
L'agent **ne fait pas** d'appels IMAP/SMTP ni de curl Gitea directs : il **invoque uniquement** les scripts `gitea-issues/*.sh` depuis la racine de ia_dev. Les scripts lisent la config (`.secrets` à la racine de ia_dev) et font les appels réels.
|
||||
|
||||
**Ordre pour traiter les mails en attente** : deux sources possibles. **Aucun enregistrement ne doit être supprimé.**
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ is_background: true
|
||||
|
||||
# Agent notary-ai-loop
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'**id** est résolu par **AI_AGENT_TOKEN**, **IA_PROJECT**, **ai_project_id** ou **.ia_project** (voir `projects/README.md`). Racine du dépôt = parent de ia_dev. Scripts : `ia_dev/ai_working_help/notary-ai/`.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'**id** est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Racine du dépôt = parent de ia_dev. Scripts : `ia_dev/ai_working_help/notary-ai/`.
|
||||
|
||||
**Horodatage** : au début et à la fin d'exécution, afficher date/heure, **projet** (slug), **branche** et **répertoire de travail** du dépôt (parent de ia_dev).
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ is_background: true
|
||||
|
||||
# Agent notary-ai-process
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'**id** est résolu par **AI_AGENT_TOKEN** (token des requêtes API), **IA_PROJECT**, **ai_project_id** ou **.ia_project** à la racine du dépôt parent. Racine du dépôt = parent de ia_dev. Les scripts notary-ai sont dans `ia_dev/ai_working_help/notary-ai/`.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'**id** est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes API) ; pas de fallback. Voir `projects/README.md`. Racine du dépôt = parent de ia_dev. Les scripts notary-ai sont dans `ia_dev/ai_working_help/notary-ai/`.
|
||||
|
||||
**Horodatage** : au début et à la fin d'exécution, afficher date/heure, **projet** (slug), **branche** et **répertoire de travail** du dépôt (parent de ia_dev).
|
||||
|
||||
@ -24,7 +24,7 @@ Tu es l'agent qui traite les **questions IA notaire** en attente dans le spooler
|
||||
|
||||
- Exécution depuis la **racine du dépôt** (parent de ia_dev) : `cd <racine_projet> && ./ia_dev/ai_working_help/notary-ai/list-pending-notary-ai.sh`, etc.
|
||||
- **jq** installé (les scripts l'utilisent).
|
||||
- Id projet résolu par `AI_AGENT_TOKEN`, `IA_PROJECT`, `ai_project_id` ou `.ia_project` (voir `projects/README.md`).
|
||||
- Id projet résolu **uniquement** par `MAIL_TO` ou `AI_AGENT_TOKEN` (voir `projects/README.md`).
|
||||
|
||||
## Workflow
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ is_background: false
|
||||
|
||||
# Agent push-by-script
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début d'exécution.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes) ; pas de fallback. Voir `projects/README.md`. Rappeler en début d'exécution.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
@ -54,11 +54,11 @@ Tu es l'agent push-by-script. **Rôle de l’agent :** construire le message de
|
||||
Pas de validation du commit à demander.
|
||||
Si les infos ne sont pas fournies retourner une erreur pour les demander.
|
||||
|
||||
4. Exécuter depuis la racine du dépôt projet (chemin absolu) : `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/deploy/pousse.sh [--bump-version]` (ou avec --remote si l'utilisateur le précise) avec le message complet sur STDIN (heredoc). Ne pas lancer `./deploy/pousse.sh` depuis un autre répertoire. Le script fait la build check, puis add/commit/push.
|
||||
4. Exécuter depuis la racine de ia_dev : `./deploy/pousse.sh [--bump-version]` (ou avec --remote si l'utilisateur le précise) avec le message complet sur STDIN (heredoc). Le script fait la build check (chemins absolus depuis conf), puis add/commit/push.
|
||||
|
||||
5. **Contrôle :** Ne pas masquer la sortie du script. Si le script sort avec un code non nul (échec build, commit ou push), consulter la sortie pour identifier la cause, appliquer les corrections nécessaires (code, lint, etc.), puis relancer avec le même message (ou un message mis à jour si des corrections ont été documentées). Si des fichiers ont été modifiés, le prochain run de pousse.sh les committera et poussera. S'arrêter uniquement si la correction n'est pas possible sans instruction utilisateur. Si le script sort avec 0, rapporter le succès.
|
||||
|
||||
**Contraintes :** Ne pas committer de chemins sensibles (.secrets/, .env, clés, etc.) ; le script les rejette. Git user.name doit être 4NK ou Nicolas Cantu. Ne pas utiliser --no-verify. Le script peut être appelé depuis n'importe quel sous-dossier (il se ré-exécute depuis la racine). **Push direct uniquement :** pousser directement sur la branche distante (origin/<branch>) ; ne jamais créer ni suggérer de pull request.
|
||||
**Contraintes :** Ne pas committer de chemins sensibles (.secrets/, .env, clés, etc.) ; le script les rejette. Git user.name doit être 4NK ou Nicolas Cantu. Ne pas utiliser --no-verify. Usage standalone : le script est invoqué depuis la racine de ia_dev (il peut se ré-exécuter depuis le toplevel git). **Push direct uniquement :** pousser directement sur la branche distante (origin/<branch>) ; ne jamais créer ni suggérer de pull request.
|
||||
|
||||
**Sortie :** Afficher la sortie complète du script. Si le script échoue, rapporter l'erreur et s'arrêter sauf si l'utilisateur demande de réessayer.
|
||||
|
||||
|
||||
@ -1,30 +1,18 @@
|
||||
#!/usr/bin/env bash
|
||||
# Hook script: read projects/<id>/data/issues/*.pending (spooler tickets) and output JSON with additional_context for sessionStart.
|
||||
# Run from project root (Cursor). Repo root = parent of ia_dev when script lives in ia_dev/.cursor/hooks.
|
||||
# No fallback: project id comes only from mail "to" or request token; in hook context there is none, so we aggregate pending from all projects.
|
||||
# Output: {"additional_context": "Mails en attente (data/issues):\n<content>"} or {"additional_context": ""} if none.
|
||||
set -euo pipefail
|
||||
# Consume stdin (hook input JSON)
|
||||
cat > /dev/null
|
||||
|
||||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
ROOT="$(cd "${SCRIPT_DIR}/../../.." && pwd)"
|
||||
IA_DEV="${ROOT}/ia_dev"
|
||||
PROJECT_SLUG=""
|
||||
[ -f "${ROOT}/ai_project_id" ] && PROJECT_SLUG="$(cat "${ROOT}/ai_project_id" | sed 's/[[:space:]]//g')"
|
||||
[ -z "$PROJECT_SLUG" ] && [ -f "${ROOT}/.ia_project" ] && PROJECT_SLUG="$(cat "${ROOT}/.ia_project" | sed 's/[[:space:]]//g')"
|
||||
if [ -n "$PROJECT_SLUG" ] && [ -d "${IA_DEV}/projects/${PROJECT_SLUG}" ]; then
|
||||
SPOOL="${IA_DEV}/projects/${PROJECT_SLUG}/data/issues"
|
||||
else
|
||||
SPOOL="${ROOT}/data/issues"
|
||||
fi
|
||||
|
||||
if [ ! -d "$SPOOL" ]; then
|
||||
printf '%s\n' "{\"additional_context\": \"\"}"
|
||||
exit 0
|
||||
fi
|
||||
IA_DEV="$(cd "${SCRIPT_DIR}/../.." && pwd)"
|
||||
|
||||
CONTENT=""
|
||||
for f in "${SPOOL}"/*.pending; do
|
||||
for spool in "${IA_DEV}/projects/"*/data/issues; do
|
||||
[ -d "$spool" ] || continue
|
||||
for f in "${spool}"/*.pending; do
|
||||
[ -f "$f" ] || continue
|
||||
if command -v jq >/dev/null 2>&1; then
|
||||
status="$(jq -r '.status // "pending"' "$f" 2>/dev/null)"
|
||||
@ -32,6 +20,7 @@ for f in "${SPOOL}"/*.pending; do
|
||||
fi
|
||||
CONTENT="${CONTENT}--- ${f##*/} ---"$'\n'"$(cat "$f")"$'\n'
|
||||
done
|
||||
done
|
||||
|
||||
if [ -n "$CONTENT" ]; then
|
||||
if command -v jq >/dev/null 2>&1; then
|
||||
|
||||
@ -10,9 +10,9 @@ model: inherit
|
||||
|
||||
- Clôturer toute réponse en **appliquant intégralement** ces règles /!\ TTRES IMPORTANT ET NON NEGOCIABLE, - **Périmètre** : la clôture est **toujours complète** pour **tous les agents** — sans exception. Aucune exception : même pour les agents qui ne modifient pas le code (ex. branch-align, push-by-script), les points 2 (5 sub-agents par projet), 14 (docupdate), 16 et 17 s’appliquent. C'est toujours applicable de 1 à 19. Lister toutes les actions réaliées et non réalisées dans tous les cas de tous les points.
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin au début de chaque agent.
|
||||
**Contexte projet :** Les agents sont définis et lancés depuis ia_dev (centralisé) mais sont **dédiés aux projets configurés** (lecoffreio, enso, algo, etc.), pas à ia_dev. La configuration et la documentation de chaque projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu par MAIL_TO ou AI_AGENT_TOKEN. Rappeler le projet et la branche au début de chaque agent.
|
||||
|
||||
**Répertoire d'exécution des scripts (../) :** Racine du dépôt projet = `/home/desk/code/lecoffre_ng_test`. Tous les scripts `deploy/` et `gitea-issues/` doivent être invoqués après `cd` vers cette racine (chemins absolus), ex. `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/deploy/pousse.sh`, pour ne pas dépendre du répertoire de travail courant.
|
||||
**Répertoire d'exécution des scripts (standalone) :** Racine de ia_dev. Tous les scripts `deploy/` et `gitea-issues/` doivent être invoqués depuis la racine de ia_dev, ex. `./deploy/pousse.sh`, `./gitea-issues/wiki-migrate-docs.sh`. Les chemins absolus dans `conf.json` pointent vers les dépôts des projets.
|
||||
|
||||
**Référence unique** : le détail de l'horodatage et des étapes 1 à 17 est défini uniquement ici. Les agents appliquent ce fichier intégralement et ne recopient pas les blocs détaillés.
|
||||
|
||||
|
||||
@ -6,9 +6,9 @@ model: inherit
|
||||
|
||||
# Règles pour tous aussi pour l'IA
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/` (chemin absolu : `/home/desk/code/lecoffre_ng_test/ia_dev/projects/<id>`). L'identifiant `<id>` vient du slug (contenu du fichier `../ai_project_id`). Rappeler ce chemin en début et en fin d'exécution de chaque agent.
|
||||
**Contexte projet :** Les agents sont **définis et lancés depuis ia_dev** (code et définitions centralisés dans ce dépôt) mais sont **dédiés aux projets configurés** (lecoffreio, enso, algo, etc.) : ils opèrent sur ces projets, pas sur ia_dev. La configuration et la documentation de chaque projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu par MAIL_TO ou AI_AGENT_TOKEN. Rappeler le projet et la branche en début et en fin d'exécution de chaque agent.
|
||||
|
||||
**Répertoire d'exécution des scripts (../) :** Les scripts `deploy/` et `gitea-issues/` s'exécutent depuis la **racine du dépôt projet** (répertoire contenant `ai_project_id`). Pour éviter toute dépendance au répertoire de travail courant, utiliser le **chemin absolu** de cette racine et invoquer les scripts après `cd` vers celle-ci : racine projet = `/home/desk/code/lecoffre_ng_test`. Exemple : `cd /home/desk/code/lecoffre_ng_test && ./ia_dev/deploy/pousse.sh`. Ne pas appeler `./deploy/...` ni `./gitea-issues/...` depuis un autre répertoire.
|
||||
**Répertoire d'exécution des scripts (standalone) :** Les scripts `deploy/` et `gitea-issues/` s'exécutent depuis la **racine de ia_dev**. Ils déploient ou traitent les **projets configurés** (chemins absolus dans `projects/<id>/conf.json`), pas ia_dev. Invoquer depuis la racine de ia_dev, ex. : `./deploy/pousse.sh`, `./gitea-issues/wiki-migrate-docs.sh`.
|
||||
|
||||
## Communication et langues
|
||||
|
||||
|
||||
34
README.md
34
README.md
@ -1,19 +1,21 @@
|
||||
# ia_dev
|
||||
|
||||
Dépôt de pilotage par l’IA pour les projets : **équipe d’agents IA** réutilisable par tout projet qui inclut ia_dev en submodule Git. Objectif : une équipe autonome couvrant la **documentation**, le **code** (correctifs, évolutions), le **ticketing** (issues Gitea, mails), le **devops** (push, déploiement, branches), la **sécurité** et la **qualité** (lint, règles).
|
||||
Dépôt de pilotage par l’IA pour les projets : **équipe d’agents IA** dont le code et les définitions sont dans ia_dev, lancés de façon centralisée pour tous les projets configurés (lecoffreio, enso, algo, etc.) ; ils agissent sur ces projets, pas sur ia_dev. Objectif : une équipe autonome couvrant la **documentation**, le **code** (correctifs, évolutions), le **ticketing** (issues Gitea, mails), le **devops** (push, déploiement, branches), la **sécurité** et la **qualité** (lint, règles).
|
||||
|
||||
**Principe** : le projet hôte n’a **aucune dépendance** vers ia_dev (aucun script du projet n’appelle ia_dev). Seul ia_dev, en fonction du paramétrage (`.ia_project`, `ai_project_id`, `projects/<id>/conf.json`), sollicite le projet (lecture de la config, appels aux scripts deploy, gitea-issues, etc.).
|
||||
**Principe** : ia_dev est un **dépôt autonome** (usage unique : standalone). La config par projet est dans `projects/<id>/conf.json` ; l’id projet est résolu par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (token des requêtes). Voir `projects/README.md`.
|
||||
|
||||
## Usage
|
||||
## Usage (standalone)
|
||||
|
||||
- **En submodule** : ce dépôt est inclus comme sous-module Git dans chaque projet. La config par projet est dans `projects/<id>/conf.json` ; le slug `<id>` est donné par le fichier `.ia_project` ou `ai_project_id` à la racine du dépôt hôte, ou par la variable d’environnement `IA_PROJECT`.
|
||||
- **Scripts** : à lancer depuis la **racine du dépôt du projet** (ex. `./ia_dev/deploy/pousse.sh`, `./ia_dev/gitea-issues/tickets-fetch-inbox.sh`).
|
||||
- **Racine d’exécution** : tous les scripts sont lancés depuis la **racine de ia_dev** (ce dépôt). Variable optionnelle : `IA_PROJECT` pour forcer l’id projet.
|
||||
- **Config** : dans `projects/<id>/conf.json`, les champs `project_path`, `build_dirs`, `deploy.scripts_path`, `deploy.deploy_script_path`, `deploy.secrets_path`, `version.package_json_paths` sont des **chemins absolus** (vers les dépôts des projets). Les champs `mail.imap_bridge_env` et `git.token_file` sont **relatifs à la racine de ia_dev**. Le répertoire `.secrets` à la racine de ia_dev contient `token` et `gitea-issues/agent-loop.env`, `gitea-issues/imap-bridge.env`.
|
||||
|
||||
Voir `projects/README.md` pour le schéma de configuration et les exemples.
|
||||
|
||||
## Agents et domaines
|
||||
|
||||
Les agents Cursor sont dans `.cursor/agents/`. Chaque agent indique où se trouve la doc : **projets gérés** → `projects/<id>/docs` ; **ia_dev** → `projects/ia_dev/docs`.
|
||||
Les **agents** ont leur **code et définitions** dans ia_dev (`.cursor/agents/`, `.cursor/rules/`) et sont **lancés de façon centralisée** depuis ce dépôt pour **tous les projets**. Ils sont **dédiés aux projets configurés** (lecoffreio, enso, algo, etc.) : ils agissent sur ces projets (doc, code, déploiement, ticketing), pas sur ia_dev. ia_dev est uniquement le projet qui porte leurs définitions et d’où on les invoque.
|
||||
|
||||
Chaque agent indique où se trouve la doc : **projets gérés** → `projects/<id>/docs` ; **ia_dev** → `projects/ia_dev/docs`.
|
||||
|
||||
| Domaine | Agents / composants |
|
||||
|---------|---------------------|
|
||||
@ -26,18 +28,18 @@ Les agents Cursor sont dans `.cursor/agents/`. Chaque agent indique où se trouv
|
||||
|
||||
Référence détaillée scripts et agents : `projects/ia_dev/docs/GITEA_ISSUES_SCRIPTS_AGENTS.md`. Index de la doc ia_dev : `projects/ia_dev/docs/README.md`.
|
||||
|
||||
## Répertoires d’exécution
|
||||
## Répertoire d’exécution (standalone)
|
||||
|
||||
Les scripts sont invoqués depuis la **racine du dépôt hôte**. Ils s’y placent (ou s’y ré-exécutent) avant de continuer.
|
||||
Tous les scripts sont invoqués depuis la **racine de ia_dev** (ce dépôt).
|
||||
|
||||
- **deploy/** : `PROJECT_ROOT` = git toplevel ; ré-exécution depuis la racine si besoin. Chemin du script résolu (`readlink -f` / `realpath`) pour que `IA_DEV_ROOT` soit correct même si `deploy` est un symlink vers `ia_dev/deploy`.
|
||||
- **gitea-issues/** : racine projet = parent de ia_dev ; `.secrets` sous ia_dev ; **logs** et **data** (spooler tickets) par projet sous `projects/<id>/logs/` et `projects/<id>/data/issues/` (id = slug, ex. contenu de `ai_project_id`).
|
||||
- **ai_working_help/** : API (server.js) et scripts `notary-ai/` ; spooler par projet sous `projects/<id>/data/notary-ai/{pending,responded}` ; scripts invoqués depuis la racine du dépôt (parent de ia_dev). Doc : `ai_working_help/docs/notary-ai-api.md`.
|
||||
- **deploy/** : scripts qui **déploient les projets configurés** (lecoffreio, enso, algo, etc.) dans leurs répertoires, pas ia_dev. Ils utilisent les chemins absolus de `projects/<id>/conf.json` pour agir sur chaque projet.
|
||||
- **gitea-issues/** : **logs** et **data** (spooler tickets) par projet sous `projects/<id>/logs/` et `projects/<id>/data/issues/` (id résolu par MAIL_TO ou AI_AGENT_TOKEN).
|
||||
- **ai_working_help/** : API (server.js) et scripts `notary-ai/` ; spooler par projet sous `projects/<id>/data/notary-ai/{pending,responded}`. Doc : `ai_working_help/docs/notary-ai-api.md`.
|
||||
|
||||
## Scripts centralisés (submodule)
|
||||
## Scripts centralisés (deploy/)
|
||||
|
||||
Les scripts suivants sont centralisés dans `ia_dev/deploy/`. Le projet n’a pas à fournir de wrapper ; on invoque depuis la racine : `./ia_dev/deploy/bump-version.sh`, `./ia_dev/deploy/pousse.sh`, etc.
|
||||
Les scripts dans `deploy/` **déploient et versionnent les projets configurés** (lecoffreio, enso, algo, etc.) dans leurs répertoires — ils ne déploient pas ia_dev. À lancer depuis la racine de ia_dev : `./deploy/bump-version.sh`, `./deploy/pousse.sh`, `./deploy/deploy-by-script-to.sh`, etc. Les chemins absolus dans `projects/<id>/conf.json` indiquent où se trouve chaque projet et ses scripts de déploiement.
|
||||
|
||||
- **bump-version.sh** : lecture de `projects/<id>/conf.json` (version.package_json_paths, version.splash_app_name). Invocation : `./ia_dev/deploy/bump-version.sh <version> [message]` depuis la racine du dépôt.
|
||||
- **deploy-by-script-to.sh** : enchaîne change-to-all-branches (ia_dev/deploy), puis checkout/pull/deploy via `deploy/scripts_v2/deploy.sh` du projet. Le projet peut avoir `deploy/deploy-by-script-to.sh` → `exec …/ia_dev/deploy/deploy-by-script-to.sh "$@"`.
|
||||
- **deploy/_lib/** : bibliothèque partagée pour les scripts de déploiement (`colors.sh`, `env-map.sh`, `ssh.sh`, `git-flow.sh`). Pour que `deploy/scripts_v2/` du projet utilise cette version : depuis la racine du projet, `rm -rf deploy/scripts_v2/_lib` puis `ln -s ../../ia_dev/deploy/_lib deploy/scripts_v2/_lib` (les scripts font `source "$SCRIPT_DIR/_lib/…"`).
|
||||
- **bump-version.sh** : lit `projects/<id>/conf.json` (version.package_json_paths, version.splash_app_name) et met à jour VERSION + package.json du **projet configuré**. Invocation : `./deploy/bump-version.sh <version> [message]` depuis la racine de ia_dev.
|
||||
- **deploy-by-script-to.sh** : checkout branche cible (pprod|prod), sync origin, exécute `deploy/scripts_v2/deploy.sh` du **projet configuré** (chemin dans conf), puis revient sur test.
|
||||
- **deploy/_lib/** : bibliothèque partagée pour les scripts de déploiement. Les `deploy/scripts_v2/` de chaque projet peuvent s’y lier (symlink) pour réutiliser cette lib.
|
||||
|
||||
@ -23,7 +23,7 @@
|
||||
## Id projet et résolution
|
||||
|
||||
- **Côté API** : le token est trouvé en parcourant tous les projets et tous les envs comme décrit précédemment : pour chaque `projects/<id>/.secrets/<env>/ia_token`, on compare le Bearer au contenu du fichier ou à (contenu + env). La première correspondance donne l'id projet et l'env (test, pprod, prod, etc.).
|
||||
- **Côté scripts** : id (et env) résolus par **MAIL_TO**, **AI_AGENT_TOKEN** (lit `.secrets/<env>/ia_token`), **IA_PROJECT**, ou **ai_project_id** / **.ia_project** à la racine du dépôt parent.
|
||||
- **Côté scripts** : id (et env) résolus **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (lit `.secrets/<env>/ia_token`). Pas de fallback. Voir `projects/README.md`.
|
||||
- Données par projet : `projects/<id>/data/notary-ai/` (pending/, responded/).
|
||||
|
||||
## API (serveur Node)
|
||||
@ -48,7 +48,7 @@ Lancement : depuis **ia_dev** : `cd ia_dev && node ai_working_help/server.js`. P
|
||||
|
||||
## Scripts (depuis la racine du dépôt, parent de ia_dev)
|
||||
|
||||
- **./ia_dev/ai_working_help/notary-ai/list-pending-notary-ai.sh** : liste les fichiers `projects/<id>/data/notary-ai/pending/*.json` (id résolu par AI_AGENT_TOKEN, IA_PROJECT, ai_project_id ou .ia_project).
|
||||
- **./ia_dev/ai_working_help/notary-ai/list-pending-notary-ai.sh** : liste les fichiers `projects/<id>/data/notary-ai/pending/*.json` (id résolu par MAIL_TO ou AI_AGENT_TOKEN).
|
||||
- **./ia_dev/ai_working_help/notary-ai/write-response-notary-ai.sh** : écrit la réponse dans responded/, supprime le pending.
|
||||
Options : `--pending-path <path> --response-json <json>` ou `--request-uid <uid> --answer "..." [--next-actions-table "..." ] [--members-info-sheet "..."] [--synthesis-recommendation "..."]`.
|
||||
|
||||
|
||||
@ -6,15 +6,14 @@ set -euo pipefail
|
||||
|
||||
NOTARY_AI_DIR="${NOTARY_AI_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
|
||||
IA_DEV_ROOT="$(cd "${NOTARY_AI_DIR}/../.." && pwd)"
|
||||
PROJECT_ROOT="$(cd "${IA_DEV_ROOT}/.." && pwd)"
|
||||
# Standalone: PROJECT_ROOT defaults to parent of ia_dev; set PROJECT_ROOT if the project repo is elsewhere
|
||||
PROJECT_ROOT="${PROJECT_ROOT:-$(cd "${IA_DEV_ROOT}/.." && pwd)}"
|
||||
export PROJECT_ROOT IA_DEV_ROOT
|
||||
if [[ -f "${IA_DEV_ROOT}/lib/project_config.sh" ]]; then
|
||||
# shellcheck source=../../lib/project_config.sh
|
||||
source "${IA_DEV_ROOT}/lib/project_config.sh"
|
||||
fi
|
||||
if [[ -z "${PROJECT_SLUG:-}" ]]; then
|
||||
PROJECT_SLUG="${AI_PROJECT_SLUG:-}"
|
||||
fi
|
||||
# No fallback: PROJECT_SLUG only from project_config.sh (MAIL_TO or AI_AGENT_TOKEN)
|
||||
if [[ -n "${PROJECT_SLUG:-}" && -n "${IA_DEV_ROOT:-}" ]]; then
|
||||
DATA_NOTARY_AI_DIR="${IA_DEV_ROOT}/projects/${PROJECT_SLUG}/data/notary-ai"
|
||||
DATA_NOTARY_AI_PENDING_DIR="${DATA_NOTARY_AI_DIR}/pending"
|
||||
|
||||
@ -10,7 +10,7 @@ cd "$ROOT"
|
||||
# shellcheck source=lib.sh
|
||||
source "${NOTARY_AI_DIR}/lib.sh"
|
||||
if [[ -z "${DATA_NOTARY_AI_PENDING_DIR:-}" || ! -d "${DATA_NOTARY_AI_PENDING_DIR}" ]]; then
|
||||
echo "[notary-ai] DATA_NOTARY_AI_PENDING_DIR not set or not a directory. Set IA_PROJECT or ai_project_id at repo root." >&2
|
||||
echo "[notary-ai] DATA_NOTARY_AI_PENDING_DIR not set or not a directory. Set MAIL_TO or AI_AGENT_TOKEN so project id is resolved (no fallback)." >&2
|
||||
exit 1
|
||||
fi
|
||||
for f in "${DATA_NOTARY_AI_PENDING_DIR}"/*.json; do
|
||||
|
||||
@ -3,7 +3,7 @@ set -euo pipefail
|
||||
|
||||
# Bump version and optional package.json files from project config (projects/<id>/conf.json).
|
||||
# Usage: ./bump-version.sh <version> [message_court]
|
||||
# Requires: run from repo root; project id from IA_PROJECT, .ia_project, or ai_project_id; jq if using version.package_json_paths.
|
||||
# Requires: run from repo root; project id from MAIL_TO or AI_AGENT_TOKEN only (no fallback); jq if using version.package_json_paths.
|
||||
|
||||
VERSION="${1:-}"
|
||||
SHORT_MSG="${2:-Nouvelles fonctionnalités et améliorations}"
|
||||
@ -51,8 +51,13 @@ if [[ -n "${PROJECT_CONFIG_PATH:-}" && -f "$PROJECT_CONFIG_PATH" ]] && command -
|
||||
fi
|
||||
|
||||
for p in "${package_paths[@]}"; do
|
||||
if [[ -f "$PROJECT_ROOT/$p" ]]; then
|
||||
sed -i "s/\"version\": \".*\"/\"version\": \"${VERSION}\"/" "$PROJECT_ROOT/$p"
|
||||
if [[ "$p" = /* ]]; then
|
||||
abs_p="$p"
|
||||
else
|
||||
abs_p="$PROJECT_ROOT/$p"
|
||||
fi
|
||||
if [[ -f "$abs_p" ]]; then
|
||||
sed -i "s/\"version\": \".*\"/\"version\": \"${VERSION}\"/" "$abs_p"
|
||||
echo "✅ $p → ${VERSION}"
|
||||
else
|
||||
echo "⚠️ $p not found, skipped"
|
||||
|
||||
@ -15,7 +15,7 @@ if [[ "$(pwd)" != "$PROJECT_ROOT" ]]; then
|
||||
cd "$PROJECT_ROOT" && exec "$SCRIPT_ABS" "$@"
|
||||
fi
|
||||
|
||||
# Resolve project id and config path: IA_PROJECT, .ia_project, or ai_project_id → projects/<id>/conf.json
|
||||
# Resolve project id and config path: MAIL_TO or AI_AGENT_TOKEN only (no fallback) → projects/<id>/conf.json
|
||||
# shellcheck source=../lib/project_config.sh
|
||||
source "${IA_DEV_ROOT}/lib/project_config.sh"
|
||||
|
||||
@ -105,12 +105,17 @@ fi
|
||||
if [[ ${#build_dirs[@]} -gt 0 ]]; then
|
||||
echo "[pousse] Build check (${#build_dirs[@]} dirs from project config)..."
|
||||
for dir in "${build_dirs[@]}"; do
|
||||
if [[ ! -d "${repo_root}/${dir}" ]]; then
|
||||
if [[ "$dir" = /* ]]; then
|
||||
abs_dir="$dir"
|
||||
else
|
||||
abs_dir="${repo_root}/${dir}"
|
||||
fi
|
||||
if [[ ! -d "$abs_dir" ]]; then
|
||||
echo "[pousse][WARN] Skipping build ${dir} (directory not found)" >&2
|
||||
continue
|
||||
fi
|
||||
echo "[pousse] Building ${dir}..."
|
||||
(cd "${repo_root}/${dir}" && npm run build) || {
|
||||
(cd "$abs_dir" && npm run build) || {
|
||||
echo "[pousse][ERROR] Build failed in ${dir}" >&2
|
||||
exit 1
|
||||
}
|
||||
|
||||
@ -20,6 +20,7 @@ export REPO_ROOT="${ROOT}"
|
||||
cd "$ROOT"
|
||||
# shellcheck source=lib.sh
|
||||
source "${GITEA_ISSUES_DIR}/lib.sh" 2>/dev/null || true
|
||||
# When no PROJECT_SLUG (no MAIL_TO/AI_AGENT_TOKEN), use generic ROOT/logs for status/pending file
|
||||
LOGS_GITEA="${PROJECT_LOGS_DIR:-$ROOT/logs}/gitea-issues"
|
||||
|
||||
STATUS_FILE="${AGENT_LOOP_STATUS_FILE:-$LOGS_GITEA/agent-loop.status}"
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
#!/usr/bin/env bash
|
||||
#
|
||||
# Shared config and helpers for Gitea issues scripts.
|
||||
# Source from gitea-issues/*.sh after cd to project root.
|
||||
# Source from gitea-issues/*.sh. Standalone: run from ia_dev root.
|
||||
#
|
||||
set -euo pipefail
|
||||
|
||||
@ -33,21 +33,25 @@ fi
|
||||
export PROJECT_LOGS_DIR
|
||||
export DATA_ISSUES_DIR
|
||||
|
||||
# Load token: GITEA_TOKEN env, then project config git.token_file, then default .secrets path
|
||||
# Load token: GITEA_TOKEN env, then project config git.token_file (path relative to ia_dev root), then default
|
||||
load_gitea_token() {
|
||||
if [[ -n "${GITEA_TOKEN:-}" ]]; then
|
||||
return 0
|
||||
fi
|
||||
local token_file=""
|
||||
local ia_dev_root="${GITEA_ISSUES_DIR}/.."
|
||||
if [[ -n "${PROJECT_CONFIG_PATH:-}" && -f "$PROJECT_CONFIG_PATH" ]] && command -v jq >/dev/null 2>&1; then
|
||||
local rel_path
|
||||
rel_path="$(jq -r '.git.token_file // empty' "$PROJECT_CONFIG_PATH" 2>/dev/null)"
|
||||
if [[ -n "$rel_path" && -n "${PROJECT_ROOT:-}" && -f "${PROJECT_ROOT}/${rel_path}" ]]; then
|
||||
token_file="${PROJECT_ROOT}/${rel_path}"
|
||||
if [[ -n "$rel_path" ]]; then
|
||||
# token_file in conf is relative to ia_dev root (this project)
|
||||
if [[ -f "${ia_dev_root}/${rel_path}" ]]; then
|
||||
token_file="${ia_dev_root}/${rel_path}"
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
if [[ -z "$token_file" ]]; then
|
||||
token_file="${GITEA_ISSUES_DIR}/../.secrets/gitea-issues/token"
|
||||
token_file="${ia_dev_root}/.secrets/gitea-issues/token"
|
||||
fi
|
||||
if [[ -f "$token_file" ]]; then
|
||||
GITEA_TOKEN="$(cat "$token_file")"
|
||||
|
||||
@ -1,6 +1,7 @@
|
||||
#!/usr/bin/env bash
|
||||
# List .pending files in projects/<id>/data/issues/ with status "pending" (one file per message; status updated in place).
|
||||
# Run from repo root. Output: one path per line.
|
||||
# Run from repo root. If PROJECT_SLUG is set (from MAIL_TO or AI_AGENT_TOKEN), list that project only; else list all projects.
|
||||
# Output: one path per line.
|
||||
# Usage: ./ia_dev/gitea-issues/list-pending-spooler.sh
|
||||
set -euo pipefail
|
||||
GITEA_ISSUES_DIR="${GITEA_ISSUES_DIR:-$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)}"
|
||||
@ -9,11 +10,17 @@ export GITEA_ISSUES_DIR
|
||||
cd "$ROOT"
|
||||
# shellcheck source=lib.sh
|
||||
source "${GITEA_ISSUES_DIR}/lib.sh" 2>/dev/null || true
|
||||
SPOOL="${DATA_ISSUES_DIR:-}"
|
||||
if [[ -z "${SPOOL:-}" || ! -d "$SPOOL" ]]; then
|
||||
echo "[gitea-issues] DATA_ISSUES_DIR not set or not a directory. Run from repo root with projects/<id> configured." >&2
|
||||
exit 1
|
||||
if [[ -n "${DATA_ISSUES_DIR:-}" && -d "${DATA_ISSUES_DIR}" ]]; then
|
||||
SPOOLS=("${DATA_ISSUES_DIR}")
|
||||
else
|
||||
# No project from MAIL_TO/AI_AGENT_TOKEN: list pending from all projects
|
||||
SPOOLS=()
|
||||
for spool in "${GITEA_ISSUES_DIR}/../projects/"*/data/issues; do
|
||||
[[ -d "$spool" ]] || continue
|
||||
SPOOLS+=("$spool")
|
||||
done
|
||||
fi
|
||||
for SPOOL in "${SPOOLS[@]}"; do
|
||||
for f in "${SPOOL}"/*.pending; do
|
||||
[[ -f "$f" ]] || continue
|
||||
status="$(jq -r '.status // "pending"' "$f" 2>/dev/null)"
|
||||
@ -21,3 +28,4 @@ for f in "${SPOOL}"/*.pending; do
|
||||
echo "$f"
|
||||
fi
|
||||
done
|
||||
done
|
||||
|
||||
@ -4,10 +4,12 @@
|
||||
|
||||
Sourced by deploy scripts and gitea-issues to resolve the current project **id** and the path to its JSON config.
|
||||
|
||||
**Before sourcing:** set `PROJECT_ROOT` (git repo root, where `ai_project_id` or `.ia_project` lives) and `IA_DEV_ROOT` (path to the `ia_dev` directory).
|
||||
**Standalone usage:** scripts are run from ia_dev root. Source after setting `IA_DEV_ROOT` (path to ia_dev); `PROJECT_ROOT` is derived by scripts when needed from config (e.g. project_path in conf.json).
|
||||
|
||||
**After sourcing:** `PROJECT_SLUG` and `PROJECT_CONFIG_PATH` are set (and exported). Config path is `projects/<id>/conf.json`.
|
||||
**After sourcing:** `PROJECT_SLUG` and `PROJECT_CONFIG_PATH` are set (and exported). Config path is `projects/<id>/conf.json`. For token-based resolution, `PROJECT_ENV` is also set.
|
||||
|
||||
**Project id resolution order:** `IA_PROJECT` env → `.ia_project` at PROJECT_ROOT → `ai_project_id` at PROJECT_ROOT.
|
||||
**Project id resolution (no fallback):**
|
||||
1. **MAIL_TO** (env): search all `projects/*/conf.json` for `tickets.authorized_emails.to` matching this address (string or list of env-keyed objects). The matching project directory name is the id.
|
||||
2. **AI_AGENT_TOKEN** (env): search all `projects/<id>/.secrets/<env>/ia_token` for matching token; sets `PROJECT_SLUG` and `PROJECT_ENV` (project and environment).
|
||||
|
||||
See `projects/README.md` for the config schema.
|
||||
|
||||
@ -1,14 +1,13 @@
|
||||
#
|
||||
# Project config resolution for ia_dev scripts.
|
||||
# Source this after setting PROJECT_ROOT and IA_DEV_ROOT.
|
||||
# Standalone: run from ia_dev root. Source after IA_DEV_ROOT is set (or it is derived from script location).
|
||||
# Resolves PROJECT_SLUG (id) and PROJECT_CONFIG_PATH (projects/<id>/conf.json).
|
||||
#
|
||||
# Project id resolution order:
|
||||
# 1. MAIL_TO (env): search all projects for tickets.authorized_emails.to == MAIL_TO
|
||||
# 2. AI_AGENT_TOKEN (env): search all projects/.secrets/<env>/ia_token for matching token; sets PROJECT_SLUG and PROJECT_ENV
|
||||
# 3. IA_PROJECT (env)
|
||||
# 4. .ia_project at PROJECT_ROOT (one line)
|
||||
# 5. ai_project_id at PROJECT_ROOT (one line)
|
||||
# Project id is resolved only by:
|
||||
# 1. MAIL_TO (env): search all projects for tickets.authorized_emails.to matching this address (config may have a string or a list of env-keyed objects).
|
||||
# 2. AI_AGENT_TOKEN (env): search all projects/.secrets/<env>/ia_token for matching token; sets PROJECT_SLUG and PROJECT_ENV (project and environment).
|
||||
#
|
||||
# No fallback: no IA_PROJECT, no ai_project_id, no .ia_project.
|
||||
#
|
||||
# Config file: projects/<id>/conf.json.
|
||||
#
|
||||
@ -19,11 +18,19 @@ if [[ -n "${MAIL_TO:-}" && -n "${IA_DEV_ROOT:-}" ]]; then
|
||||
_to="$(echo "${MAIL_TO}" | sed 's/[[:space:]]//g' | tr '[:upper:]' '[:lower:]')"
|
||||
for conf in "${IA_DEV_ROOT}/projects/"*/conf.json; do
|
||||
[[ -f "$conf" ]] || continue
|
||||
_to_conf="$(jq -r '.tickets.authorized_emails.to // ""' "$conf" 2>/dev/null | tr '[:upper:]' '[:lower:]' | sed 's/[[:space:]]//g')"
|
||||
# Extract all "to" addresses: string, or array of strings, or array of objects with env values
|
||||
while IFS= read -r _to_conf; do
|
||||
_to_conf="$(echo "$_to_conf" | tr '[:upper:]' '[:lower:]' | sed 's/[[:space:]]//g')"
|
||||
if [[ -n "$_to_conf" && "$_to_conf" = "$_to" ]]; then
|
||||
PROJECT_SLUG="$(basename "$(dirname "$conf")")"
|
||||
break
|
||||
break 2
|
||||
fi
|
||||
done < <(jq -r '
|
||||
.tickets.authorized_emails.to
|
||||
| if type == "string" then .
|
||||
elif type == "array" then (.[] | if type == "string" then . elif type == "object" then .[] else empty end)
|
||||
else empty end
|
||||
' "$conf" 2>/dev/null || true)
|
||||
done
|
||||
fi
|
||||
PROJECT_ENV=""
|
||||
@ -46,15 +53,6 @@ if [[ -z "$PROJECT_SLUG" && -n "${AI_AGENT_TOKEN:-}" && -n "${IA_DEV_ROOT:-}" ]]
|
||||
done
|
||||
fi
|
||||
export PROJECT_ENV
|
||||
if [[ -z "$PROJECT_SLUG" && -n "${IA_PROJECT:-}" ]]; then
|
||||
PROJECT_SLUG="$(echo "${IA_PROJECT}" | sed 's/[[:space:]]//g')"
|
||||
fi
|
||||
if [[ -z "$PROJECT_SLUG" && -n "${PROJECT_ROOT:-}" && -f "$PROJECT_ROOT/.ia_project" ]]; then
|
||||
PROJECT_SLUG="$(cat "$PROJECT_ROOT/.ia_project" | sed 's/[[:space:]]//g')"
|
||||
fi
|
||||
if [[ -z "$PROJECT_SLUG" && -n "${PROJECT_ROOT:-}" && -f "$PROJECT_ROOT/ai_project_id" ]]; then
|
||||
PROJECT_SLUG="$(cat "$PROJECT_ROOT/ai_project_id" | sed 's/[[:space:]]//g')"
|
||||
fi
|
||||
|
||||
PROJECT_CONFIG_PATH=""
|
||||
if [[ -n "$PROJECT_SLUG" && -n "${IA_DEV_ROOT:-}" ]]; then
|
||||
|
||||
@ -1,25 +1,26 @@
|
||||
# Project-specific configuration
|
||||
|
||||
This repo (`ia_dev`) is intended to be used as a **git submodule** inside each project. Project-specific parameters are stored in `projects/<id>/conf.json` (e.g. `projects/lecoffreio/conf.json`). The `<id>` is the project identifier and the name of the directory under `projects/`.
|
||||
This repo (`ia_dev`) is a **standalone** depot. Project-specific parameters are stored in `projects/<id>/conf.json` (e.g. `projects/lecoffreio/conf.json`). The `<id>` is the project identifier (directory name under `projects/`).
|
||||
|
||||
**Paths in conf.json:**
|
||||
The scripts in `ia_dev/deploy/` deploy and build the **configured projects** (lecoffreio, enso, algo, etc.) in their own directories; they do not deploy ia_dev.
|
||||
|
||||
- **Absolute** (required): `project_path`, `build_dirs`, `deploy.scripts_path`, `deploy.deploy_script_path`, `deploy.secrets_path`, `version.package_json_paths` — they point to each project repo.
|
||||
- **Relative to ia_dev root** (this project): `mail.imap_bridge_env`, `git.token_file`. They point to files under ia_dev’s own `.secrets/`.
|
||||
|
||||
## Current project selection
|
||||
|
||||
There is no longer a "slug" in the URL or path; the project **id** (directory name under `projects/`) is resolved by:
|
||||
There is no "slug" in the URL or path and no fallback file. The project **id** (directory name under `projects/`) is resolved only by:
|
||||
|
||||
**1. Mail ticketing**
|
||||
From the **To** address of an email: search all `projects/*/conf.json` for `tickets.authorized_emails.to` equal to that address (case-insensitive). The matching project directory name is the id.
|
||||
**1. Mail ticketing — "to" address**
|
||||
From the **To** address of an email: search all `projects/*/conf.json` for `tickets.authorized_emails.to` equal to that address (case-insensitive). The config may have a single string or a list of env-keyed objects (e.g. `[{ "test": "AI.X.TEST@…", "pprod": "…", "prod": "…" }]`). The matching project directory name is the id.
|
||||
|
||||
**2. API ai_working_help**
|
||||
The token is found by scanning as described above: traverse all projects and all envs, reading each `projects/<id>/.secrets/<env>/ia_token` and comparing its content (or content + env) to the Bearer token. The first match yields the project id and the env (e.g. `test`, `pprod`, `prod`).
|
||||
**2. Request token**
|
||||
The token in the request (e.g. Bearer) is matched by scanning all projects and all envs: each `projects/<id>/.secrets/<env>/ia_token` is read and compared (content or content + env). The first match yields the project id and the environment (`test`, `pprod`, `prod`).
|
||||
|
||||
**3. Scripts / fallback** (when no request context)
|
||||
- **`MAIL_TO`** (env): same as (1), resolve id by email "to".
|
||||
- **`AI_AGENT_TOKEN`** (env): same as (2), resolve id (and env) by token; sets `PROJECT_SLUG` and `PROJECT_ENV`.
|
||||
- **`IA_PROJECT`** (env)
|
||||
- **`.ia_project`** at repository root (one line)
|
||||
- **`ai_project_id`** at repository root (one line). When `ia_dev` is a submodule, this file lives at the host repo root (parent of `ia_dev`).
|
||||
Scripts use **`MAIL_TO`** (env) for (1) or **`AI_AGENT_TOKEN`** (env) for (2); they set `PROJECT_SLUG` and, for (2), `PROJECT_ENV`. No other source (no `IA_PROJECT`, no `ai_project_id`, no `.ia_project`).
|
||||
|
||||
When running from a repo that has `ia_dev` as a submodule, the root is the parent repo; the script resolves `ia_dev` either as `./ia_dev` or `./deploy` (symlink to `ia_dev/deploy`).
|
||||
**Usage unique : standalone.** Tous les scripts sont lancés depuis la racine de ia_dev. Les chemins dans conf sont absolus (sauf `imap_bridge_env` et `token_file`, relatifs à la racine de ia_dev).
|
||||
|
||||
## Schema
|
||||
|
||||
@ -28,14 +29,21 @@ One JSON file per project: `projects/<id>/conf.json` (e.g. `projects/lecoffreio/
|
||||
| Field | Required | Description |
|
||||
|-------|----------|-------------|
|
||||
| `name` | yes | Human-readable project name |
|
||||
| `project_path` | no | Relative path to project from ia_dev (e.g. `../lecoffre_ng_test`); used when running from ia_dev standalone |
|
||||
| `build_dirs` | no | List of directories (relative to repo root) where `npm run build` is run before push. If missing or empty, build check is skipped |
|
||||
| `version` | no | Version/bump configuration |
|
||||
| `version.package_json_paths` | no | List of paths (relative to repo root) to `package.json` files to update on bump |
|
||||
| `version.splash_app_name` | no | App name used in splash message template |
|
||||
| `mail` | no | Mail/imap bridge config |
|
||||
| `git` | no | Git hosting: `wiki_url`, `token_file` (path relative to repo root for token file). Ticketing URL is under `tickets`, not `git`. |
|
||||
| `tickets` | no | Ticketing: `ticketing_url` (Gitea issues URL), `authorized_emails` (`to`: alias or list of env-keyed objects, `from`: list of allowed sender addresses). **to** resolves the project id when processing mails. It may be a single string or a list of one object with env keys: `[{ "test": "AI.<project_id>.TEST@4nkweb.com", "pprod": "...", "prod": "..." }]`. Pattern: `AI.<project_id>.<env>@4nkweb.com` (`project_id` and `env` may be uppercase). See projects/ia_dev/docs/TICKETS_SPOOL_FORMAT.md. |
|
||||
| `project_path` | no | **Absolute** path to the project deploy root (e.g. `/home/desk/code/lecoffre_ng_test/deploy`). |
|
||||
| `build_dirs` | no | **Absolute** paths to directories where `npm run build` is run. |
|
||||
| `deploy.scripts_path` | no | **Absolute** path to deploy scripts (e.g. `…/deploy/scripts_v2`). |
|
||||
| `deploy.deploy_script_path` | no | **Absolute** path to deploy.sh. |
|
||||
| `deploy.secrets_path` | no | **Absolute** path to the project’s `.secrets` directory. |
|
||||
| `version.package_json_paths` | no | **Absolute** paths to package.json files to bump. |
|
||||
| `mail.imap_bridge_env` | no | **Relative to ia_dev root**: path to IMAP bridge env file (e.g. `.secrets/gitea-issues/imap-bridge.env`). |
|
||||
| `git.token_file` | no | **Relative to ia_dev root**: path to Gitea token file (e.g. `.secrets/gitea-issues/token`). |
|
||||
|
||||
| `version` | no | Version/bump configuration; `version.splash_app_name` for splash message template |
|
||||
| `mail` | no | Mail/imap bridge config; `mail.imap_bridge_env` relative to ia_dev root |
|
||||
| `git` | no | Git hosting: `wiki_url`, `git.token_file` (relative to ia_dev root). Ticketing URL is under `tickets`, not `git`. |
|
||||
| `tickets` | no | Ticketing: `ticketing_url` (Gitea issues URL), `authorized_emails` (`to`: alias or list of env-keyed objects, `from`: list of allowed sender addresses). **to** resolves the project id when processing mails. See projects/ia_dev/docs/TICKETS_SPOOL_FORMAT.md. |
|
||||
|
||||
**.secrets at ia_dev root** (this repo): contains `token` and `gitea-issues/agent-loop.env`, `gitea-issues/imap-bridge.env`. The paths `mail.imap_bridge_env` and `git.token_file` in conf are relative to ia_dev root and point to these files.
|
||||
|
||||
The API token for ai_working_help is **not** in conf.json. It is found by scanning all projects and all envs (as described above): each file `projects/<id>/.secrets/<env>/ia_token` is read and the Bearer is compared to the file content or to (file content + env). Token value is **base** + **env**; **env** is the environment name (test, pprod, prod), to be adapted per environment. The first match gives project id and env.
|
||||
|
||||
@ -44,7 +52,8 @@ The API token for ai_working_help is **not** in conf.json. It is found by scanni
|
||||
```json
|
||||
{
|
||||
"name": "My App",
|
||||
"build_dirs": ["backend", "frontend"]
|
||||
"project_path": "/path/to/project/deploy",
|
||||
"build_dirs": ["/path/to/project/deploy/backend", "/path/to/project/deploy/frontend"]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
{
|
||||
"id": "ia_dev",
|
||||
"name": "ia_dev",
|
||||
"project_path": "home/desk/code/ia_dev",
|
||||
"project_path": "/home/desk/code/ia_dev",
|
||||
"build_dirs": [],
|
||||
"deploy": {},
|
||||
"version": {
|
||||
|
||||
@ -31,17 +31,17 @@ Spooler tickets (nouveau) : mails dans **projects/<id>/data/issues/** (filtre pa
|
||||
|
||||
## Contexte d'exécution
|
||||
|
||||
- **Emplacement** : `gitea-issues/` est dans le sous-module **ia_dev** du dépôt projet. Chemin typique : `<racine_projet>/ia_dev/gitea-issues/`. Fonctionne pour tout projet utilisant ia_dev de la même manière.
|
||||
- **Projet cible** : le projet est identifié **dynamiquement** par le fichier `../ai_project_id` (à la racine du dépôt projet, parent de `ia_dev`). Son contenu (slug) sert à charger la config dans `ia_dev/projects/<id>/`. Changer de projet = changer le dépôt (ou le contenu de `ai_project_id`) ; aucun chemin à hardcoder.
|
||||
- **Lancement** : le chat Cursor et les scripts sont lancés depuis **ia_dev** (`<racine_projet>/ia_dev/`), mais les opérations (issues, mails, déploiement) concernent le dépôt **parent** (`../` = racine projet). Invoquer les scripts depuis la racine du dépôt projet : `cd <racine_projet> && ./ia_dev/gitea-issues/<script>.sh`. Depuis le workspace ia_dev, racine projet = `..`.
|
||||
- **Secrets et logs** : `.secrets` est sous **ia_dev** (`ia_dev/.secrets`, soit `./.secrets` depuis ia_dev), et **ne dépend pas du projet parent**. Les scripts résolvent la racine pour `.secrets` et `logs` via le répertoire contenant `gitea-issues` (ia_dev), afin que la config IMAP/SMTP et les logs soient les mêmes quel que soit le projet ; un même clone ia_dev peut servir plusieurs projets configurés par `../ai_project_id`.
|
||||
- **Emplacement (usage standalone)** : ia_dev est un dépôt autonome. `gitea-issues/` est à la racine de ia_dev. Un même clone ia_dev peut servir plusieurs projets (id résolu par MAIL_TO ou AI_AGENT_TOKEN).
|
||||
- **Projet cible** : le projet est identifié **dynamiquement** par **MAIL_TO** (adresse « to » des mails, recherchée dans les configs ticketing de tous les projets) ou **AI_AGENT_TOKEN** (token des requêtes). L'id sert à charger la config dans `projects/<id>/`. Pas de fallback. Voir `projects/README.md`.
|
||||
- **Lancement** : tous les scripts sont invoqués depuis la **racine de ia_dev** : `./gitea-issues/<script>.sh`. Les opérations (issues, mails, déploiement) utilisent les chemins absolus de `projects/<id>/conf.json` pour le projet cible.
|
||||
- **Secrets et logs** : `.secrets` est à la racine de ia_dev (`.secrets/gitea-issues/token`, `agent-loop.env`, `imap-bridge.env`). Les logs et data par projet sont sous `projects/<id>/logs/` et `projects/<id>/data/issues/`.
|
||||
|
||||
## Prérequis
|
||||
|
||||
- **jq** : `apt install jq` ou `brew install jq`
|
||||
- **Token Gitea** : variable d'environnement `GITEA_TOKEN` ou fichier `.secrets/gitea-issues/token` (contenu = le token, non versionné). Créer le token dans Gitea : Settings → Applications → Generate New Token (scopes `read:issue`, `write:issue` si commentaires).
|
||||
|
||||
## Scripts (depuis la racine du dépôt)
|
||||
## Scripts (depuis la racine de ia_dev)
|
||||
|
||||
| Script | Usage | Description |
|
||||
|--------|--------|-------------|
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Documentation générique (ia_dev)
|
||||
|
||||
Ce répertoire contient les documents **non spécifiques à un projet** (ex. LeCoffre.io), réutilisables pour tout projet piloté par ia_dev.
|
||||
Ce répertoire contient les documents **non spécifiques à un projet** (ex. LeCoffre.io), réutilisables pour tout projet piloté par ia_dev. Les **agents** ont leur code et définitions dans ia_dev et sont **lancés de façon centralisée** depuis ce dépôt pour **tous les projets configurés** ; ils sont dédiés à ces projets (doc, code, déploiement, ticketing), pas à ia_dev.
|
||||
|
||||
**Emplacements de la documentation :**
|
||||
- **Projets gérés** : `projects/<id>/docs` (ex. `projects/lecoffreio/docs`).
|
||||
|
||||
@ -6,7 +6,7 @@ Les mails et réponses sont stockés dans **projects/<id>/data/issues/** (sous i
|
||||
|
||||
**Un seul fichier de spooler par message reçu** : il n'y a pas un fichier par état. Un même message est représenté par un seul fichier ; quand le statut change (pending → response), on renomme ce fichier (changement d'extension) et on met à jour son contenu ; on ne crée pas de second fichier.
|
||||
|
||||
- **Racine** : `ia_dev/projects/<id>/data/issues/` (id = slug projet, ex. contenu de `ai_project_id` ou `.ia_project` à la racine du dépôt)
|
||||
- **Racine** : `ia_dev/projects/<id>/data/issues/` (id résolu par MAIL_TO ou AI_AGENT_TOKEN ; voir `projects/README.md`)
|
||||
- **Format des noms** : `<date>.<id>.<from>.<status>` (un seul fichier par message ; le statut change en renommant l’extension et en mettant à jour le contenu).
|
||||
- `date` : `YYYY-MM-DDTHHmmss` (ex. `2026-03-14T094530`)
|
||||
- `id` : identifiant unique généré à la réception (déterministe à partir du message, ex. 8 caractères hexadécimaux). Même message → même `id`.
|
||||
|
||||
62
tree.txt
Normal file
62
tree.txt
Normal file
@ -0,0 +1,62 @@
|
||||
projects
|
||||
├── algo
|
||||
│ └── conf.json
|
||||
├── enso
|
||||
│ ├── conf.json
|
||||
│ └── docs
|
||||
├── ia_dev
|
||||
│ ├── conf.json
|
||||
│ └── docs
|
||||
│ ├── agents-scripts-split.md
|
||||
│ ├── GITEA_ISSUES_SCRIPTS_AGENTS.md
|
||||
│ ├── README.md
|
||||
│ ├── TICKETS_SPOOL_FORMAT.md
|
||||
│ └── WORKFLOWS_AND_COMPONENTS.md
|
||||
├── lecoffreio
|
||||
│ ├── conf.json
|
||||
│ ├── data
|
||||
│ │ ├── issues
|
||||
│ │ │ ├── 2026-03-14T134128.af28dfa2.nicolas.cantu_pm.me.d
|
||||
│ │ │ │ └── 0_publickey_-_nicolas.cantu_pm.me_-___0xAFF1ECF4.asc
|
||||
│ │ │ └── 2026-03-14T134128.af28dfa2.nicolas.cantu_pm.me.pending
|
||||
│ │ └── notary-ai
|
||||
│ │ ├── pending
|
||||
│ │ └── responded
|
||||
│ ├── docs
|
||||
│ │ ├── agents-scripts-split.md
|
||||
│ │ ├── ANCRAGE_COMPLETE.md
|
||||
│ │ ├── API.md
|
||||
│ │ ├── ARCHITECTURE.md
|
||||
│ │ ├── CODE_STANDARDS.md
|
||||
│ │ ├── DATABASE_COMPLETE.md
|
||||
│ │ ├── DEPLOYMENT.md
|
||||
│ │ ├── FRONTEND.md
|
||||
│ │ ├── IMPORT_V1_DEPENDENCIES.md
|
||||
│ │ ├── import-v1-schema-and-scripts-analysis.md
|
||||
│ │ ├── MAILCHIMP_TEMPLATES.md
|
||||
│ │ ├── MIGRATION.md
|
||||
│ │ ├── OPERATIONS.md
|
||||
│ │ ├── README.md
|
||||
│ │ ├── SCRIPTS.md
|
||||
│ │ ├── sources
|
||||
│ │ │ ├── API Annuaire - Hi├®rarchies des entit├®s dans le notariat - API Annuaire.pdf
|
||||
│ │ │ ├── API Annuaire - Migration de l'APIv1 vers l'APIv2.pdf
|
||||
│ │ │ ├── API Annuaire - Pr├®sentation et guide d'int├®gration.pdf
|
||||
│ │ │ ├── API Annuaire - V2 - Documentation Utilisateur.pdf
|
||||
│ │ │ ├── Documentation API 1.21 (1).pdf
|
||||
│ │ │ ├── ID.NOT - Document d'int├®gration OpenIDConnect.pdf
|
||||
│ │ │ ├── ID.NOT - Pr├®sentation et guide d'int├®gration.pdf
|
||||
│ │ │ └── Portail des raccordements - Guide de d├®marrage.pdf
|
||||
│ │ ├── SYNC_V1_TO_V2_AT_LOGIN_PLAN.md
|
||||
│ │ ├── v1-schema.sql
|
||||
│ │ └── WORKFLOWS_AND_COMPONENTS.md
|
||||
│ └── logs
|
||||
│ └── gitea-issues
|
||||
│ ├── agent-loop-600-cycles.log
|
||||
│ ├── agent-loop-chat-iterations.log
|
||||
│ ├── agent-loop.lock
|
||||
│ ├── agent-loop.pending
|
||||
│ └── agent-loop.status
|
||||
└── README.md
|
||||
|
||||
17 directories, 43 files
|
||||
Loading…
x
Reference in New Issue
Block a user