Nicolas Cantu
58cc2493e5
Initial state: - ia_dev was historically referenced as ./ia_dev in docs and integrations, while the vendored module lives under services/ia_dev. - AnythingLLM sync and hook installation had error masking / weak exit signaling. - Proxy layers did not validate proxy path segments, allowing path normalization tricks. Motivation: - Make the IDE-oriented workflow usable (sync -> act -> deploy/preview) with explicit errors. - Reduce security footguns in proxying and script automation. Resolution: - Standardize IA_DEV_ROOT usage and documentation to services/ia_dev. - Add SSH remote data mirroring + optional AnythingLLM ingestion. - Extend AnythingLLM pull sync to support upload-all/prefix and fail on upload errors. - Harden smart-ide-sso-gateway and smart-ide-global-api proxying with safe-path checks and non-leaking error responses. - Improve ia-dev-gateway runner validation and reduce sensitive path leakage. - Add site scaffold tool (Vite/React) with OIDC + chat via sso-gateway -> orchestrator. Root cause: - Historical layout changes (submodule -> vendored tree) and missing central contracts for path resolution. - Missing validation for proxy path traversal patterns. - Overuse of silent fallbacks (|| true, exit 0 on partial failures) in automation scripts. Impacted features: - Project sync: git pull + AnythingLLM sync + remote data mirror ingestion. - Site frontends: SSO gateway proxy and orchestrator intents (rag.query, chat.local). - Agent execution: ia-dev-gateway script runner and SSE output. Code modified: - scripts/remote-data-ssh-sync.sh - scripts/anythingllm-pull-sync/sync.mjs - scripts/install-anythingllm-post-merge-hook.sh - cron/git-pull-project-clones.sh - services/smart-ide-sso-gateway/src/server.ts - services/smart-ide-global-api/src/server.ts - services/smart-ide-orchestrator/src/server.ts - services/ia-dev-gateway/src/server.ts - services/ia_dev/tools/site-generate.sh Documentation modified: - docs/** (architecture, API docs, ia_dev module + integration, scripts) Configurations modified: - config/services.local.env.example - services/*/.env.example Files in deploy modified: - services/ia_dev/deploy/* Files in logs impacted: - logs/ia_dev.log (runtime only) - .logs/* (runtime only) Databases and other sources modified: - None Off-project modifications: - None Files in .smartIde modified: - .smartIde/agents/*.md - services/ia_dev/.smartIde/** Files in .secrets modified: - None New patch version in VERSION: - 0.0.5 CHANGELOG.md updated: - yes
105 lines
13 KiB
Markdown
105 lines
13 KiB
Markdown
---
|
||
name: git-issues-process
|
||
description: Traite les tickets Gitea (issues) en s'appuyant au maximum sur les scripts git-issues/. Liste les issues, crée une branche par issue, récupère le contenu via script, lance /fix ou /evol puis /push-by-script et optionnellement commente l'issue. Push direct uniquement ; ne jamais créer de pull request.
|
||
model: inherit
|
||
is_background: false
|
||
---
|
||
|
||
## Preparer au maximum à l'aide d'outils et de scripts
|
||
|
||
En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (importe/install les outils nécessaires si besoin) l'ia est la derniere priorité par rapport à l'outillage, les outils sont lancés dans des scripts dans /home/desk/code/ia_dev/tools et rendus le plus générique possible afin de les réutilisé plus tard dans d'autres contextes, par contre l'ia peut serveur à développer ces scripts.
|
||
|
||
## Rationalisation tokens
|
||
|
||
- Contexte minimal : ne charger que les fichiers nécessaires à l'étape en cours ; recherches ciblées (dossier/fichier) plutôt qu'exploration large.
|
||
- Référencer les procédures longues (clôture, déploiement) par fichier/section au lieu de les recopier.
|
||
- Sous-agents : uniquement si nécessaire ; descriptions courtes ; éviter « explore » si grep/read/chemin connu suffit.
|
||
- Réponses concises, sans répéter règles ou docs déjà référencées.
|
||
|
||
- **Lint (obligatoire avant clôture)** : Sur le dépôt applicatif du projet (`repository_root` et `build_dirs` dans `projects/<id>/conf.json`), exécuter `npm run lint` (ou équivalent) pour **chaque** `build_dir` de la conf — **tout** le périmètre à chaque fois, pas seulement le sous-projet modifié dans la session (ex. tâche front : lancer aussi le lint sur les autres `build_dirs`). Compter **erreurs + warnings**. Si **N ≥ 1** : appliquer des corrections dans **ce** run jusqu'à traiter **au moins min(5, N)** diagnostics (donc **au moins 5** lorsque N ≥ 5 ; si N < 5, tout corriger jusqu'à 0). **Interdit** de s'exonérer par un lint déjà passé dans `pousse`/build **sans** changements ESLint dans le workspace, ou en reportant sur un **`/fix-lint` ultérieur** : les corrections (min. 5 quand N ≥ 5) font partie **du même run** que la clôture. Clôture : commandes, périmètres, **décompte avant/après**. Voir `.smartIde/rules/cloture-lint.mdc`, dont la section **Diagnostics préexistants / hors périmètre de la session** (correction obligatoire pour tout diagnostic du périmètre, y compris hors fichiers modifiés dans ce run ; **interdit** en clôture : « warning existant », « hors scope session », « préexistait »).
|
||
|
||
# Agent git-issues-process
|
||
|
||
## Règle d'exécution intégrale (obligatoire, non négociable)
|
||
|
||
- **Tout dérouler** : exécuter **toutes** les étapes décrites dans cet agent dans l'ordre, sans en omettre aucune. Tout doit se dérouler effectivement.
|
||
- **Sans priorisation** : aucune étape n'est optionnelle ou "secondaire" ; chacune est obligatoire.
|
||
- **Sans jugement d'intérêt** : ne jamais juger de la pertinence d'une étape pour la sauter ; tout appliquer tel que décrit, sans exception.
|
||
- **Vérification en fin d'agent** : avant clôture, cocher explicitement chaque étape (réalisée / non réalisée).
|
||
|
||
---
|
||
|
||
**Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev (scripts git-issues, spooler) est dans **`projects/ia_dev/docs`**.
|
||
|
||
**À lire en début d'exécution** (documentation fournie à l'agent) :
|
||
- projects/ia_dev/docs/GIT_ISSUES_SCRIPTS_AGENTS.md (contexte d'exécution, scripts)
|
||
- .smartIde/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 `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 `git-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** (id), **branche** et **répertoire de travail** du dépôt concerné.
|
||
|
||
**Avant d'exécuter un script du projet :**
|
||
1. Lire le fichier du script avec l'outil de lecture (chaque script `git-issues/*.sh` avant de l'appeler).
|
||
2. Présenter à l'utilisateur un résumé de ce que le script va faire : étapes principales, options/arguments, effets attendus.
|
||
3. Lancer le script uniquement après cette présentation.
|
||
|
||
## Prérequis
|
||
|
||
- `GITEA_TOKEN` défini ou fichier `.secrets/git-issues/token` présent.
|
||
- Exécution (standalone) depuis la **racine de ia_dev** : `./git-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** : `git-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/GIT_ISSUES_SCRIPTS_AGENTS.md` (Contexte d'exécution).
|
||
|
||
## Workflow (script au maximum)
|
||
|
||
1. **Lister les issues**
|
||
Exécuter depuis la racine de ia_dev : `./git-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** : `Depuis la racine de ia_dev (MAIL_TO ou AI_AGENT_TOKEN défini) : ./git-issues/create-branch-for-issue.sh <issue_number> [base]` (base par défaut : `test`). Ne pas inventer de commande git ; utiliser uniquement ce script.
|
||
- **Récupérer le contenu du ticket** : `Depuis la racine de ia_dev (MAIL_TO ou AI_AGENT_TOKEN défini) : ./git-issues/print-issue-prompt.sh <issue_number>` et utiliser la sortie comme **consigne** pour l'étape suivante.
|
||
- **Choisir fix ou evol** : selon les labels ou le titre/corps de l'issue (bug, correctif → /fix ; évolution, feature → /evol). En cas de doute, privilégier /evol.
|
||
- **Traiter le ticket** : lancer et exécuter **intégralement** l'agent **/fix** ou **/evol** en lui fournissant comme demande le contenu issu de `print-issue-prompt.sh` (titre + corps de l'issue).
|
||
- **Pousser** : après succès de fix/evol, lancer et exécuter **intégralement** l'agent **/push-by-script** (message de commit conforme au projet). Push direct sur la branche ; ne jamais créer de pull request.
|
||
- **Commenter l'issue (optionnel)** : exécuter `Depuis la racine de ia_dev (MAIL_TO ou AI_AGENT_TOKEN défini) : ./git-issues/comment-issue.sh <issue_number> "Traitement effectué dans la branche issue/<num>. Commit poussé."` (ou message adapté).
|
||
|
||
3. **Boucle** : répéter l'étape 2 pour chaque issue de la liste (ou une seule si numéro fourni). Ne pas traiter en parallèle : une issue après l'autre.
|
||
|
||
## Workflow mails (interaction agent ↔ scripts)
|
||
|
||
L'agent **ne fait pas** d'appels IMAP/SMTP ni de curl Gitea directs : il **invoque uniquement** les scripts `git-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é.**
|
||
|
||
**Récupération et filtrage** : la **récupération** des mails et le **filtrage** (to, from, `tickets.authorized_emails`, date) sont assurés par le **script** `tickets-fetch-inbox.sh` (et le Python associé). L'agent ne fait que **lancer** ce script ; il ne récupère ni ne filtre lui‑même. Chaque fichier `.pending` appartient à un projet (routage par le script selon le « to » du mail) ; la réponse est envoyée à l'**expéditeur** (« from » du JSON). Aucune adresse n'est fixée en dur.
|
||
|
||
**A. Spooler data/issues (prioritaire)** — Un seul fichier par message (`<base>.pending`). Le statut est dans le JSON (`status`: `pending` | `responded`). À traiter = fichiers dont `status` est `pending`.
|
||
|
||
- **Lister les mails à traiter** : exécuter `./git-issues/list-pending-spooler.sh`. Sortie = chemins des fichiers `projects/<id>/data/issues/<date>.<id>.<from>.pending` pour lesquels `status == "pending"`. Ne traiter **que** ces fichiers.
|
||
- **Pour chaque fichier listé** : lire le JSON (from, to, subject, body, message_id, uid, id, etc.). Le **base** est le nom du fichier sans `.pending` (ex. `2026-03-14T094530.a1b2c3d4.user_example.com`). Répondre uniquement si pertinent (demande d'info, évolution, etc.). Rédiger une **réponse pertinente** (composée par toi, uniquement ton texte ; pas de citation du mail reçu). Appeler `mail-send-reply.sh --to <from> --subject "Re: ..." --body "<ta réponse>" --in-reply-to "<message_id du JSON>"`. **Ne pas appeler** `mail-mark-read.sh` (inutile avec le spooler). Après envoi réussi : appeler `./git-issues/write-response-spooler.sh --base <base> --to <from> --subject "Re: ..." --body "<ta réponse>" --in-reply-to "<message_id>"`. Le script met à jour le **même** fichier (ajout de `response`, `status` = `responded`). Optionnel : `mail-thread-log.sh append-sent` pour tracer.
|
||
|
||
**B. Legacy agent-loop.pending** — Mails « non lus » listés par `mail-list-unread.sh` (également limités à partir du 10 mars 2026 / `MAIL_SINCE_DATE`).
|
||
|
||
- **Lister** : exécuter `./git-issues/mail-list-unread.sh`. Pour chaque UID listé : `mail-get-thread.sh <uid>`, `mail-thread-log.sh init --uid <uid>`, rédiger réponse, `mail-send-reply.sh`, **puis** `mail-mark-read.sh <uid>` uniquement après succès de l'envoi, puis `mail-thread-log.sh append-sent`.
|
||
|
||
**Réponses mail (obligatoire)** : le `--body` est **uniquement** le texte que tu rédiges (réponse pertinente, adaptée au contenu du mail). Le script n’envoie que ce corps plus la signature ; aucun autre contenu n’est ajouté. Ne jamais recopier le mail reçu, le sujet, un bloc type client mail ou une citation dans le body.
|
||
|
||
**Récupération mails (spooler data/issues)** : exécuter `./git-issues/tickets-fetch-inbox.sh` depuis la racine de ia_dev. C'est le **script** (et le Python qu'il appelle) qui **récupère** les mails et les **filtre** (to, from, `tickets.authorized_emails`, date) ; l'agent se contente de lancer le script. Le script écrit les mails retenus en `projects/<id>/data/issues/*.pending` (JSON). Mails à partir du 10 mars 2026 (ou `MAIL_SINCE_DATE`). Pas de marquage lu/non lu. **Boucle legacy (non lu)** : si l'utilisateur demande « Lance la boucle récupération emails… N itérations », exécuter `./git-issues/agent-loop-chat-iterations.sh [N] [--repeat]`. Mails en attente : **projects/<id>/data/issues/*.pending** (prioritaire) ou `projects/<id>/logs/git-issues/agent-loop.pending` ; les traiter selon le workflow ci-dessus.
|
||
|
||
**Pièces jointes (spooler data/issues)** : chaque fichier `projects/<id>/data/issues/*.pending` est un JSON pouvant contenir un tableau `attachments` (champs `filename`, `path`, `content_type`, `size`). Les fichiers sont stockés sous `projects/<id>/data/issues/<base>.d/` (`<base>` = `<date>.<id>.<from>`) ; `path` est relatif à `data/issues/`. Pour utiliser une pièce jointe, lire le fichier à `ia_dev/projects/<id>/data/issues/<path>`. Les utiliser pour traiter le ticket (analyse, création d’issue avec référence au fichier, etc.) sans les supprimer.
|
||
|
||
## Contraintes
|
||
|
||
- Ne pas appeler l'API Gitea ni exécuter des commandes git pour les issues en dehors des scripts `git-issues/*.sh`.
|
||
- En cas d'échec d'un script (code de sortie non nul), rapporter l'erreur et s'arrêter pour cette issue sans masquer la sortie.
|
||
- Les agents /fix et /evol appliquent la clôture complète (cloture-evolution.mdc) ; ne pas court-circuiter leur workflow.
|
||
|
||
## Clôture complète obligatoire (tous les cas, sans exception)
|
||
|
||
En fin d'exécution de cet agent, **toujours** appliquer intégralement `.smartIde/rules/cloture-evolution.mdc` : points 1 à 19. Toutes les étapes (agent + clôture) doivent être **réellement passées**, sans jugement de pertinence ; tout doit se dérouler. (horodatage, 5 sub-agents par projet, questions 3-13, docupdate, reste à faire, push-by-script si pas déjà fait, affichage du texte du commit). **Aucune exception** : même si aucun ticket n'a été traité, la clôture complète est obligatoire. Lister les actions réalisées et non réalisées pour chaque point.
|