docs: point conf schema and README stubs to smart_ide docs/repo
Replace embedded README bodies with links to central ia-dev-* docs. Update agent references from projects/README to docs/repo path.
This commit is contained in:
parent
047700fab0
commit
11da4329e4
@ -29,7 +29,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
|
||||
---
|
||||
|
||||
**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), **branche** et **répertoire de travail** du dépôt concerné (ia_dev ou dépôt du projet configuré).
|
||||
**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 `docs/repo/ia-dev-project-conf-schema.md`. Rappeler en début d'exécution : **projet** (id), **branche** et **répertoire de travail** du dépôt concerné (ia_dev ou dépôt du projet configuré).
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
|
||||
---
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu par **paramètre** (optionnel en premier argument : `./deploy/branch-align.sh [project_id] <env>`), **MAIL_TO** ou **AI_AGENT_TOKEN**. Voir `projects/README.md`. 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 par **paramètre** (optionnel en premier argument : `./deploy/branch-align.sh [project_id] <env>`), **MAIL_TO** ou **AI_AGENT_TOKEN**. Voir `docs/repo/ia-dev-project-conf-schema.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`**.
|
||||
|
||||
|
||||
@ -37,7 +37,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
|
||||
---
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu par **paramètre** (optionnel : `./deploy/change-to-all-branches.sh [project_id]`), **MAIL_TO** ou **AI_AGENT_TOKEN**. Voir `projects/README.md`. 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 par **paramètre** (optionnel : `./deploy/change-to-all-branches.sh [project_id]`), **MAIL_TO** ou **AI_AGENT_TOKEN**. Voir `docs/repo/ia-dev-project-conf-schema.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`**.
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
|
||||
---
|
||||
|
||||
**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.
|
||||
**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 `docs/repo/ia-dev-project-conf-schema.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`**.
|
||||
|
||||
|
||||
@ -27,7 +27,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
|
||||
---
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu par **paramètre** (optionnel en premier argument des scripts), **MAIL_TO** ou **AI_AGENT_TOKEN**. Voir `projects/README.md`. 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 par **paramètre** (optionnel en premier argument des scripts), **MAIL_TO** ou **AI_AGENT_TOKEN**. Voir `docs/repo/ia-dev-project-conf-schema.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`**.
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
|
||||
---
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu par **paramètre** (optionnel en premier argument des scripts), **MAIL_TO** ou **AI_AGENT_TOKEN**. Voir `projects/README.md`. 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 par **paramètre** (optionnel en premier argument des scripts), **MAIL_TO** ou **AI_AGENT_TOKEN**. Voir `docs/repo/ia-dev-project-conf-schema.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`**.
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
|
||||
---
|
||||
|
||||
**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.
|
||||
**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 `docs/repo/ia-dev-project-conf-schema.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`**.
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
|
||||
---
|
||||
|
||||
**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.
|
||||
**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 `docs/repo/ia-dev-project-conf-schema.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`**.
|
||||
|
||||
|
||||
@ -49,7 +49,7 @@ Chacune des actions ci-dessous est **obligatoire** et doit être réalisée **de
|
||||
|
||||
---
|
||||
|
||||
**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.
|
||||
**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 `docs/repo/ia-dev-project-conf-schema.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`**.
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
|
||||
---
|
||||
|
||||
**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.
|
||||
**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 `docs/repo/ia-dev-project-conf-schema.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`**.
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
|
||||
---
|
||||
|
||||
**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.
|
||||
**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 `docs/repo/ia-dev-project-conf-schema.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`**.
|
||||
|
||||
|
||||
@ -36,7 +36,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
- .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>/`. 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.
|
||||
**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 `docs/repo/ia-dev-project-conf-schema.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/<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.
|
||||
|
||||
@ -50,7 +50,7 @@ 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 (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`).
|
||||
- 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 `docs/repo/ia-dev-project-conf-schema.md`).
|
||||
- Dépendances : `jq`, `curl` (les scripts les utilisent).
|
||||
|
||||
**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).
|
||||
|
||||
@ -25,7 +25,7 @@ is_background: true
|
||||
|
||||
---
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'**id** est résolu **uniquement** par **MAIL_TO** ou **AI_AGENT_TOKEN** ; pas de fallback. Voir `projects/README.md`. Scripts : `./ai_working_help/notary-ai/` depuis la racine de ia_dev.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'**id** est résolu **uniquement** par **MAIL_TO** ou **AI_AGENT_TOKEN** ; pas de fallback. Voir `docs/repo/ia-dev-project-conf-schema.md`. Scripts : `./ai_working_help/notary-ai/` depuis la racine de ia_dev.
|
||||
|
||||
**Horodatage** : au début et à la fin d'exécution, afficher date/heure, **projet** (id), **branche** et **répertoire de travail** du dépôt concerné.
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
|
||||
---
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'**id** est résolu **uniquement** par **MAIL_TO** ou **AI_AGENT_TOKEN** ; pas de fallback. Voir `projects/README.md`. Scripts : `./ai_working_help/notary-ai/` depuis la racine de ia_dev.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'**id** est résolu **uniquement** par **MAIL_TO** ou **AI_AGENT_TOKEN** ; pas de fallback. Voir `docs/repo/ia-dev-project-conf-schema.md`. Scripts : `./ai_working_help/notary-ai/` depuis la racine de ia_dev.
|
||||
|
||||
**Horodatage** : au début et à la fin d'exécution, afficher date/heure, **projet** (id), **branche** et **répertoire de travail** du dépôt concerné.
|
||||
|
||||
@ -46,7 +46,7 @@ Tu es l'agent qui traite les **questions IA notaire** en attente dans le spooler
|
||||
|
||||
- Exécution depuis la **racine de ia_dev** (MAIL_TO ou AI_AGENT_TOKEN défini) : `Depuis la racine de ia_dev (MAIL_TO ou AI_AGENT_TOKEN défini) : ./ai_working_help/notary-ai/list-pending-notary-ai.sh`, etc.
|
||||
- **jq** installé (les scripts l'utilisent).
|
||||
- Id projet résolu **uniquement** par `MAIL_TO` ou `AI_AGENT_TOKEN` (voir `projects/README.md`).
|
||||
- Id projet résolu **uniquement** par `MAIL_TO` ou `AI_AGENT_TOKEN` (voir `docs/repo/ia-dev-project-conf-schema.md`).
|
||||
|
||||
## Workflow
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
|
||||
|
||||
---
|
||||
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu par **paramètre** (optionnel : premier argument ou `--project <id>`), **MAIL_TO** ou **AI_AGENT_TOKEN**. Voir `projects/README.md`. Rappeler en début d'exécution : projet (id), branche, répertoire de travail.
|
||||
**Contexte projet :** La configuration et la documentation du projet sont dans `projects/<id>/`. L'identifiant `<id>` est résolu par **paramètre** (optionnel : premier argument ou `--project <id>`), **MAIL_TO** ou **AI_AGENT_TOKEN**. Voir `docs/repo/ia-dev-project-conf-schema.md`. Rappeler en début d'exécution : projet (id), branche, répertoire de travail.
|
||||
|
||||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ is_background: false
|
||||
|
||||
## Règle d’exécution intégrale
|
||||
|
||||
1. **Horodatage et contexte** : début/fin — date/heure ISO, branche git du dépôt **ia_dev**, `pwd`, **project id** (`IA_PROJECT_ID`, premier argument, ou résolution MAIL_TO / AI_AGENT_TOKEN selon `projects/README.md`).
|
||||
1. **Horodatage et contexte** : début/fin — date/heure ISO, branche git du dépôt **ia_dev**, `pwd`, **project id** (`IA_PROJECT_ID`, premier argument, ou résolution MAIL_TO / AI_AGENT_TOKEN selon `docs/repo/ia-dev-project-conf-schema.md`).
|
||||
2. **Résolution** : lire `projects/<id>/conf.json` avec `jq` si disponible ; exiger `deploy.repository_root` (répertoire existant).
|
||||
3. **Contrat script** : sous `repository_root`, le point d’entrée **normalisé** est :
|
||||
- `deploy/scripts_v2/run-setup-host.sh`
|
||||
|
||||
54
README.md
54
README.md
@ -1,55 +1,9 @@
|
||||
# ia_dev
|
||||
|
||||
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).
|
||||
Documentation centralisée dans le monorepo **smart_ide** :
|
||||
|
||||
**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`.
|
||||
**[docs/repo/ia-dev-repository-overview.md](../docs/repo/ia-dev-repository-overview.md)**
|
||||
|
||||
## Usage (standalone)
|
||||
Schéma `conf.json` :
|
||||
|
||||
- **Racine d'exécution** : tous les scripts sont lancés depuis la **racine de ia_dev** (ce dépôt). L'id projet est résolu uniquement par **MAIL_TO** ou **AI_AGENT_TOKEN** (voir `projects/README.md`).
|
||||
- **Config** : dans `projects/<id>/conf.json`, les chemins vers les dépôts projet peuvent être **absolus** ou **relatifs à la racine du monorepo smart_ide** lorsque ia_dev y est intégré (voir `lib/conf_path_resolve.sh`, `projects/README.md` amont). 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** 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 |
|
||||
|---------|---------------------|
|
||||
| **Doc** | `docupdate` ; `projects/ia_dev/docs/` (GITEA_ISSUES_SCRIPTS_AGENTS, TICKETS_SPOOL_FORMAT, WORKFLOWS_AND_COMPONENTS) ; migration wiki (`gitea-issues/wiki-migrate-docs.sh`). |
|
||||
| **Code** | `fix`, `evol`, `code`, `fix-search` ; workflow correctifs/évolutions (fix-search → fix → push-by-script ; evol + code). |
|
||||
| **Ticketing** | `gitea-issues-process`, `agent-loop` ; spooler `projects/<id>/data/issues` ; scripts `gitea-issues/` (issues Gitea, mails, boucle récupération/traitement) ; hook `.cursor/hooks/remonter-mails.sh`. |
|
||||
| **IA notaire (ai_working_help)** | `notary-ai-loop`, `notary-ai-process` ; API `ai_working_help/server.js` (POST enqueue, GET response) ; spooler `projects/<id>/data/notary-ai/{pending,responded}` ; scripts `ai_working_help/notary-ai/` (list-pending, write-response). |
|
||||
| **DevOps** | `push-by-script`, `deploy-by-script`, `deploy-pprod-or-prod`, `branch-align-by-script-from-test`, `change-to-all-branches` ; scripts `deploy/` (pousse.sh, scripts_v2, alignement branches). |
|
||||
| **Sécurité / Qualité** | Règles `.cursor/rules/` ; pas de secrets en dur (`.secrets`, config par projet) ; `fix-lint` ; clôture obligatoire (`.cursor/rules/cloture-evolution.mdc`) pour tous les agents. |
|
||||
|
||||
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épertoire d'exécution (standalone)
|
||||
|
||||
Tous les scripts sont invoqués depuis la **racine de ia_dev** (ce dépôt).
|
||||
|
||||
- **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 (deploy/)
|
||||
|
||||
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. Chaque script accepte en option un **project_id** en premier argument (ou `--project <id>` pour pousse.sh) pour cibler le projet ; sinon le projet est résolu par MAIL_TO ou AI_AGENT_TOKEN. Les chemins absolus dans `projects/<id>/conf.json` indiquent où se trouve chaque projet et ses scripts de déploiement.
|
||||
|
||||
**Orchestration générique (méthodologie ia_dev → orchestrateur projet)** :
|
||||
|
||||
- **deploy/lib/deploy-methodology.sh** : environnements autorisés (`test` \| `pprod` \| `prod`), validations communes ; évolutions « même méthodologie / qualité / séquences » pour tous les projets s’ajoutent ici (ou libs sœurs), pas dans les dépôts applicatifs.
|
||||
- **deploy.sh** : `./deploy/deploy.sh <project_id> <env> [options…]` — méthodologie + `IA_PROJECT_ID`, puis **orchestrator.sh**.
|
||||
- **orchestrator.sh** : secrets depuis `conf.json`, puis **`exec`** du **script orchestrateur du dépôt cible** : `deploy.project_orchestrator_path` (relatif à `repository_root`). Un seul point d’entrée côté projet ; ce script enchaîne les sous-scripts métier. **Repli** : sans `project_orchestrator_path`, ancien modèle `hooks.phases` ou `deploy.deploy_script_path`.
|
||||
- **run-project-hooks.sh** : délègue à **orchestrator.sh** (compatibilité).
|
||||
|
||||
- **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 [project_id] <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. Invocation : `./deploy/deploy-by-script-to.sh [project_id] <pprod|prod>`.
|
||||
- **pousse.sh** : build check, commit, push. Invocation : `./deploy/pousse.sh [project_id|--project <id>] [--remote <remote>] [--bump-version]` avec le message de commit sur STDIN.
|
||||
- **branch-align.sh** : aligne origin/test, origin/pprod, origin/prod. Invocation : `./deploy/branch-align.sh [project_id] <env>`.
|
||||
- **change-to-all-branches.sh** : aligne les branches puis déploie test. Invocation : `./deploy/change-to-all-branches.sh [project_id]`.
|
||||
- **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.
|
||||
**[docs/repo/ia-dev-project-conf-schema.md](../docs/repo/ia-dev-project-conf-schema.md)**
|
||||
|
||||
@ -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 **uniquement** par **MAIL_TO** (adresse « to » des mails) ou **AI_AGENT_TOKEN** (lit `.secrets/<env>/ia_token`). Pas de fallback. Voir `projects/README.md`.
|
||||
- **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 `docs/repo/ia-dev-project-conf-schema.md` (racine monorepo **smart_ide**).
|
||||
- Données par projet : `projects/<id>/data/notary-ai/` (pending/, responded/).
|
||||
|
||||
## API (serveur Node)
|
||||
|
||||
@ -1,33 +1,3 @@
|
||||
# Shared deploy libraries (ia_dev)
|
||||
|
||||
## `ssh.sh`
|
||||
|
||||
Canonical SSH/SCP helpers (`ssh_run`, `scp_copy`, `require_ssh_key`, `ssh_common_opts`) used across projects.
|
||||
**LeCoffre** : `deploy/scripts_v2/_lib/ssh.sh` sources `ia_dev/deploy/lib/ssh.sh` when the path `ia_dev/deploy/lib/ssh.sh` exists from the repo root; otherwise it embeds the same implementation.
|
||||
|
||||
## `deploy-log.sh`
|
||||
|
||||
Optional `deploy_script_tee_log_if_requested <project_root> <log_subdir> [deploy_env]` — third arg `test` \| `pprod` \| `prod` sets the log filename `deploy_<env>_…` and a header line. Requires `info` from the project’s `colors.sh` (sourced before this file in `deploy.sh`). `DEPLOY_STARTED_AT` in the shell is echoed in the header when set.
|
||||
|
||||
## Policy
|
||||
|
||||
Project-specific logic (Prisma, systemd unit names, remote app layout, LeCoffre domains) stays under each repository’s `deploy/scripts_v2/`. Only transport/logging helpers live here.
|
||||
|
||||
## `deploy-methodology.sh`
|
||||
|
||||
Shared contract for all managed projects: allowed envs (`test` \| `pprod` \| `prod`), validation helpers. Sourced by **`deploy.sh`** and **`orchestrator.sh`**. Extend only with an explicit decision (new env = conf + doc migration).
|
||||
|
||||
**Boundary** : any step **strictly identical** for every project belongs here or in a sibling `deploy/lib/deploy-*.sh`. The project orchestrator under `repository_root` only sequences **project-specific** scripts (e.g. `_lib/deploy-phase-*.sh`).
|
||||
|
||||
Quality gates and longer sequences that are identical across projects should be added here or in peers — not in project repos.
|
||||
|
||||
## `deploy-conf-handling.sh`
|
||||
|
||||
Shared **conf.json** handling: `jq` requirement, `deploy.secrets_path` → `SECRETS_BASE` / `LECOFFRE_SECRETS_BASE`, exports **`IA_DEV_DEPLOY_REPO_ROOT`** and **`IA_DEV_DEPLOY_ENV`** (mandatory handoff: `ia_dev_deploy_assert_handoff_context` exits if unset or inconsistent — no fallback). Sourced by **`orchestrator.sh`**. Add new generic `deploy.*` reads here.
|
||||
|
||||
## Orchestration (`../orchestrator.sh`, `../deploy.sh`)
|
||||
|
||||
- **`deploy.sh`** : `./deploy/deploy.sh <project_id> <env> [args]` — applies methodology (env validation, banner), sets `IA_PROJECT_ID`, then **`exec orchestrator.sh`**.
|
||||
- **`orchestrator.sh`** : exports secrets from conf, then **`exec`** the **project orchestrator** `repository_root` + `deploy.project_orchestrator_path` (relative path) with the same `"$@"`. **Legacy** : if `project_orchestrator_path` is missing, uses `deploy.hooks.phases` or `deploy.deploy_script_path`. **`run-project-hooks.sh`** execs `orchestrator.sh` for backward compatibility.
|
||||
|
||||
Project orchestrator = single script in the target repo that sequences project-specific steps (`deploy.sh` LeCoffre today, or a dedicated `orchestrate-project.sh` later).
|
||||
**[docs/repo/ia-dev-deploy-lib.md](../../../docs/repo/ia-dev-deploy-lib.md)**
|
||||
|
||||
@ -1,15 +1,3 @@
|
||||
# ia_dev shared lib
|
||||
|
||||
## project_config.sh
|
||||
|
||||
Sourced by deploy scripts and gitea-issues to resolve the current project **id** and the path to its JSON config.
|
||||
|
||||
**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_ID` 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 (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_ID` and `PROJECT_ENV` (project and environment).
|
||||
|
||||
See `projects/README.md` for the config schema.
|
||||
**[docs/repo/ia-dev-shared-lib.md](../../docs/repo/ia-dev-shared-lib.md)**
|
||||
|
||||
@ -1,80 +1,5 @@
|
||||
# Project-specific configuration
|
||||
# Project-specific configuration (ia_dev)
|
||||
|
||||
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/`).
|
||||
Documentation canonique dans **smart_ide** :
|
||||
|
||||
**Paths in conf.json:**
|
||||
The scripts in `deploy/` deploy and build the **configured projects** (lecoffreio, enso, algo, etc.) in their own directories; they do not deploy ia_dev.
|
||||
|
||||
- **Project / deploy paths** (`project_path`, `deploy.repository_root`, `deploy.deploy_script_path`, `deploy.secrets_path`, `deploy.scripts_path`): **absolute** or **relative to the smart_ide monorepo root** (parent of `projects/` and `ia_dev/`). Resolution uses `lib/conf_path_resolve.sh` when the config file lives under `…/projects/<id>/conf.json` or `…/ia_dev/projects/<id>/conf.json`.
|
||||
- **`build_dirs`**: each entry is either **absolute**, **relative to the monorepo root** if it starts with `../`, or **relative to the project git root** (`repository_root`) otherwise (e.g. `enso/enso-front`).
|
||||
- **`version.package_json_paths`**: **relative to the project git root** unless absolute (e.g. `package.json`, `enso/enso-front/package.json`).
|
||||
- **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
|
||||
|
||||
The project **id** (directory name under `projects/`) is resolved by (first match wins):
|
||||
|
||||
**1. Explicit parameter**
|
||||
Scripts in `deploy/` accept an optional project id as first argument or via `--project <id>` (pousse.sh). When present and `projects/<id>/conf.json` exists, that id is used. Example: `./deploy/pousse.sh lecoffreio`, `./deploy/deploy-by-script-to.sh lecoffreio prod`.
|
||||
|
||||
**2. 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.
|
||||
|
||||
**3. 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`).
|
||||
|
||||
Scripts use **parameter** (or **`IA_PROJECT_ID`** env set by scripts), **`MAIL_TO`** (env) or **`AI_AGENT_TOKEN`** (env); they set `PROJECT_ID` and, for token, `PROJECT_ENV`. No other source (no `IA_PROJECT`, no `ai_project_id`, no `.ia_project`).
|
||||
|
||||
**Usage :** scripts lancés depuis la racine de ia_dev. Les chemins projet peuvent être absolus ou relatifs à la racine du monorepo **smart_ide** lorsque ia_dev y est intégré ; `mail.*` / `git.token_file` restent relatifs à la racine de ia_dev.
|
||||
|
||||
## Rule: conf.json is read-only for agents
|
||||
|
||||
**Les agents ne doivent pas modifier les fichiers `projects/<id>/conf.json`.** Si un changement de configuration est nécessaire, l’agent doit :
|
||||
|
||||
1. **Décrire** clairement la modification : fichier (`projects/<id>/conf.json`), section (ex. `tickets.authorized_emails.from`), ancienne et nouvelle valeur.
|
||||
2. **Demander** à l’utilisateur soit d’appliquer lui-même la modification, soit de valider pour que l’agent la fasse exceptionnellement.
|
||||
|
||||
Exemple : pour autoriser une nouvelle adresse d’expéditeur, proposer « Fichier : `projects/lecoffreio/conf.json`. Modification : ajouter `"nouvelle@adresse.com"` dans le tableau `tickets.authorized_emails.from`. Valides-tu cette modification ? »
|
||||
|
||||
## Schema
|
||||
|
||||
One JSON file per project: `projects/<id>/conf.json` (e.g. `projects/lecoffreio/conf.json`). The `<id>` is the directory name; the config file is always named `conf.json`.
|
||||
|
||||
| Field | Required | Description |
|
||||
|-------|----------|-------------|
|
||||
| `id` | no | Project identifier (directory name under `projects/`); default: directory name. |
|
||||
| `name` | no | Human-readable project name. |
|
||||
| `project_path` | no | Git clone root for cron / tooling: **absolute** or **relative to smart_ide monorepo root** (e.g. `../enso`, `.`). |
|
||||
| `build_dirs` | no | `npm run build` dirs: **absolute**; **monorepo-relative** if value starts with `../`; else **relative to repository root**. |
|
||||
| `deploy.scripts_path` | no | Deploy scripts dir: **absolute** or **monorepo-relative** (e.g. `../enso/deploy/scripts_v2`). |
|
||||
| `deploy.deploy_script_path` | no | **Absolute** or **monorepo-relative** path to `deploy.sh` (fallback / tooling). |
|
||||
| `deploy.project_orchestrator_path` | recommended | **Relative to `deploy.repository_root`** : single project orchestrator script (sequences project-specific deploy steps). Preferred over `deploy.hooks.phases`. |
|
||||
| `deploy.hooks.phases` | legacy | Optional list of scripts relative to `repository_root`; used only if `project_orchestrator_path` is unset. |
|
||||
| `deploy.secrets_path` | no | **Absolute** or **monorepo-relative** path to the project’s `.secrets` directory. |
|
||||
| `deploy.host_stays_on_test` | no | If **true**, `deploy-by-script-to.sh` keeps the app clone on branch **test** for **pprod**/**prod** deploys (no `checkout`/`reset --hard` on those branches); the project’s `deploy.sh` aligns remotes / worktree. **false** or omitted: legacy behaviour (checkout target branch, sync, deploy, checkout **test**). LeCoffre sets **true** permanently in `projects/lecoffreio/conf.json`. |
|
||||
| `version.package_json_paths` | no | Paths to `package.json` for version bump: **absolute** or **relative to repository root**. |
|
||||
| `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`, `from`). **to** resolves the project id when processing mails; format: string (single address) or list of strings or list of objects keyed by env (e.g. `[{ "test": "AI.X.TEST@…", "pprod": "…", "prod": "…" }]`). **from**: list of allowed sender addresses. 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.
|
||||
|
||||
## Example (minimal)
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "My App",
|
||||
"project_path": "/path/to/project/deploy",
|
||||
"build_dirs": ["/path/to/project/deploy/backend", "/path/to/project/deploy/frontend"]
|
||||
}
|
||||
```
|
||||
|
||||
## Example (full)
|
||||
|
||||
See `projects/lecoffreio/conf.json`.
|
||||
**[docs/repo/ia-dev-project-conf-schema.md](../../docs/repo/ia-dev-project-conf-schema.md)**
|
||||
|
||||
@ -32,7 +32,7 @@ Spooler tickets (nouveau) : mails dans **projects/<id>/data/issues/** (filtre pa
|
||||
## Contexte d'exécution
|
||||
|
||||
- **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`.
|
||||
- **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 `docs/repo/ia-dev-project-conf-schema.md` (racine monorepo **smart_ide**).
|
||||
- **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/`.
|
||||
|
||||
|
||||
@ -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 résolu par MAIL_TO ou AI_AGENT_TOKEN ; voir `projects/README.md`)
|
||||
- **Racine** : `ia_dev/projects/<id>/data/issues/` (id résolu par MAIL_TO ou AI_AGENT_TOKEN ; voir `docs/repo/ia-dev-project-conf-schema.md` à la racine du monorepo **smart_ide**)
|
||||
- **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`.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user