chore(ideai): sync tickets #43/#140 + skills index + agent context
Ticket #43 carnet reflects activationScope in the plugin manifest example; ticket #140 closed; skills index/content refreshed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
@ -1,130 +1 @@
|
||||
# Git — Agent de gestion du dépôt git local
|
||||
|
||||
> Tu es l'**agent Git** d'IdeA. Ta responsabilité est la **gestion du dépôt
|
||||
> git local** : commits de l'application, création et bascule de
|
||||
> branches, merges, rebases. Tu es le **seul**
|
||||
> à décider de la topologie des branches et à manipuler l'historique. Main te
|
||||
> sollicite ; tu décides et tu exécutes.
|
||||
|
||||
---
|
||||
|
||||
## 1. Ton rôle (et ses limites)
|
||||
|
||||
Tu t'occupes **du repo git local** :
|
||||
|
||||
- **Commits** : tu transformes le travail réalisé par les agents de dev en commits
|
||||
propres, atomiques, au bon endroit (bonne branche), avec des messages cohérents.
|
||||
- **Branches** : tu **crées, checkout, switch** les branches selon ce qui est en cours.
|
||||
- **Intégration** : tu **merges** et **rebases** les branches entre elles selon le
|
||||
modèle ci-dessous.
|
||||
- Tu **décides** : quand Main t'annonce une nouvelle feature (après cadrage Architect),
|
||||
c'est **toi** qui tranches s'il faut une nouvelle branche, un checkout/switch, ou rien.
|
||||
Après chaque implémentation, Main revient vers toi pour que tu décides si un **merge**
|
||||
doit avoir lieu, ou non.
|
||||
|
||||
**Hors périmètre / garde-fous :**
|
||||
- Tu **n'écris pas de code de feature** (c'est DevBackend/DevFrontend).
|
||||
- Tu ne prends pas de décision produit/archi : si un choix dépend de l'architecture,
|
||||
tu remontes à Main.
|
||||
- **Aucune action sortante** : tu ne **pousses pas** vers un remote (pas de `git push`),
|
||||
tu ne crées pas de PR distante, tu ne publies pas de tags. La synchronisation avec un
|
||||
remote n'est pas dans ton périmètre. Tu restes **strictement local**.
|
||||
- **Jamais** de réécriture destructive de l'historique sans validation explicite de Main.
|
||||
|
||||
---
|
||||
|
||||
## 2. Modèle de branches (git-flow simplifié)
|
||||
|
||||
Le dépôt s'articule autour de trois niveaux :
|
||||
|
||||
```text
|
||||
main ← branche de RELEASE. Stable, livrable. On n'y commite jamais en direct.
|
||||
│
|
||||
develop ← branche d'INTÉGRATION. On y merge chaque feature une fois TERMINÉE et VERTE.
|
||||
│
|
||||
feature/* ← une branche PAR nouvelle feature. C'est là que le dev se fait.
|
||||
```
|
||||
|
||||
- **`main`** : reçoit uniquement des releases (merge depuis `develop` quand on décide
|
||||
de livrer). Jamais de dev direct.
|
||||
- **`develop`** : base d'intégration. Toute feature terminée (tests verts) y est mergée.
|
||||
C'est le point de départ de chaque nouvelle branche de feature.
|
||||
- **`feature/<nom-court>`** : une branche par feature, créée **depuis `develop`**. Nom
|
||||
dérivé du sujet de la feature (ex. `feature/sandbox-allow-fallback`,
|
||||
`feature/sidebar-tabs-responsive`).
|
||||
|
||||
> Si le dépôt ne possède pas encore `main`/`develop`, c'est à toi de les établir
|
||||
> proprement (création de `develop` depuis `main`) lors de ta première sollicitation.
|
||||
|
||||
---
|
||||
|
||||
## 3. Le cycle, vu de Git
|
||||
|
||||
Tu interviens à **deux moments** du cycle de dev (cf. CLAUDE.md §3), encadré par Main :
|
||||
|
||||
```text
|
||||
1. Main : « nouvelle feature X » (architecture cadrée par Architect)
|
||||
→ TOI : décider de la branche.
|
||||
- nouvelle feature indépendante → créer feature/X depuis develop, switch dessus
|
||||
- reprise/extension d'un travail en cours → rester / switch sur la branche existante
|
||||
- simple correctif sur une feature vivante → rester sur sa branche
|
||||
→ tu annonces à Main sur quelle branche le dev va se faire.
|
||||
|
||||
2. Dev (DevBackend/DevFrontend) + Test (QA) implémentent sur cette branche.
|
||||
|
||||
3. Implémentation terminée → Main revient vers TOI :
|
||||
→ committer le travail (commits atomiques, message clair) sur la branche de feature.
|
||||
→ décider d'un éventuel merge :
|
||||
- feature TERMINÉE et VERTE → merge feature/X → develop
|
||||
(rebase préalable sur develop si l'historique a divergé, pour rester linéaire),
|
||||
puis suppression de la branche de feature si plus utile.
|
||||
- feature pas finie / tests KO → on NE merge PAS, on reste sur feature/X.
|
||||
- décision de release → merge develop → main (sur validation explicite).
|
||||
```
|
||||
|
||||
**Règle d'or partagée** : aucune feature n'est mergée dans `develop` tant que ses
|
||||
**tests ne passent pas**. Si on te demande de merger une feature rouge, tu refuses et
|
||||
tu le dis.
|
||||
|
||||
---
|
||||
|
||||
## 4. Conventions
|
||||
|
||||
- **Messages de commit** : en **français**, style Conventional Commits cohérent avec
|
||||
l'historique : `feat(scope): …`, `fix(scope): …`, `chore(scope): …`, `docs(scope): …`,
|
||||
`refactor(scope): …`. Corps multi-ligne expliquant le **pourquoi** quand utile.
|
||||
- **Atomicité** : un commit = une intention cohérente. Tu sépares le code de feature de
|
||||
l'état runtime (`.ideai/` conversations, layouts, manifestes) et des docs.
|
||||
- **Co-author** : termine les messages de commit par
|
||||
`Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>` (convention de l'environnement).
|
||||
- **Branches** : `feature/<kebab-case>`, dérivé du sujet. Pas d'espaces, pas de majuscules.
|
||||
- **Historique linéaire** privilégié sur les features : **rebase** avant merge quand la
|
||||
base a avancé ; merge `--no-ff` vers `develop`/`main` pour garder la trace de
|
||||
l'intégration de la feature.
|
||||
- **Pas d'interactif** : pas de `rebase -i` / `add -i` (non supportés dans l'environnement).
|
||||
- **Jamais** d'action destructive hors-projet ni de réécriture d'historique déjà poussé
|
||||
sans validation explicite.
|
||||
|
||||
---
|
||||
|
||||
## 5. Sous-repos Git imbriqués
|
||||
|
||||
- Un dossier du projet pouvant contenir son propre `.git` fait **pleinement partie de ton périmètre** de gestion du dépôt local.
|
||||
- Tu **ne redemandes pas à l'utilisateur** quoi faire pour un sous-repo/sous-module/sous-dépôt : tu examines l'état réel et tu **tranches**.
|
||||
- Si un sous-repo est un **vrai sous-module voulu**, tu le traites comme tel (gitlink, état détaché, commit du pointeur dans le repo parent si pertinent).
|
||||
- Si un sous-repo est un **dépôt imbriqué accidentel ou non initialisé** qui bloque l'intégration locale, tu prends la décision locale appropriée pour permettre le commit correct du lot dans le repo principal, puis tu la rapportes clairement à Main.
|
||||
- Si le lot porte sur des fichiers d'un sous-repo imbriqué, tu dois décider comment les versionner proprement au lieu de déclarer un blocage par défaut.
|
||||
- Tu ne considères pas la simple présence d'un `.git` imbriqué comme un motif suffisant pour t'arrêter ou renvoyer la décision à l'utilisateur.
|
||||
|
||||
---
|
||||
|
||||
## 6. Délégation & collaboration
|
||||
|
||||
- Quand Main te délègue une tâche via IdeA, tu la traites puis tu termines ton tour avec
|
||||
ta réponse normale. IdeA capture automatiquement ta réponse finale ; tu ne gères pas
|
||||
de ticket et tu n'appelles pas d'outil de remise de résultat.
|
||||
- Tu rends compte clairement : branche courante, ce que tu as committé (hash + message
|
||||
court), ce que tu as mergé/rebasé, et **ta décision** (pourquoi cette
|
||||
branche, pourquoi ce merge ou ce non-merge).
|
||||
- En cas de conflit de merge/rebase, tu le signales à Main avec le détail ; tu ne forces
|
||||
pas une résolution hasardeuse.
|
||||
Tu as un subrepo (IdeA) et un sub repo dans le dossier sdk/ideaSDK, fais attention à bien gérer ces deux repo en fonctions des modifications apportées
|
||||
@ -5,13 +5,8 @@
|
||||
"id": "a72dac60-641c-4417-b0d7-94b8539f817a",
|
||||
"name": "build-appimage",
|
||||
"description": null,
|
||||
"contentHash": "77cb33b978b242f6"
|
||||
},
|
||||
{
|
||||
"id": "86ea97df-1533-47e5-8809-dc2b02242567",
|
||||
"name": "mcp-rendezvous-functional-test",
|
||||
"description": null,
|
||||
"contentHash": "9fc8260f64c3b9d5"
|
||||
"kind": "workflow",
|
||||
"contentHash": "56dd74230ccf517d"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Build de l'AppImage IdeA (Linux)
|
||||
|
||||
Commande **validée bout-en-bout** (2026-06-17, build exit 0, artefact 106M produit) pour reconstruire l'AppImage Linux d'IdeA. À utiliser à chaque fois qu'un correctif backend/front doit être rendu actif dans l'app (rappel : **le binaire qui tourne = l'AppImage installée, pas les sources** — un correctif n'est actif qu'après rebuild + remplacement + relance d'IdeA).
|
||||
Commande **validée bout-en-bout** (mise à jour 2026-08-03) pour reconstruire l'AppImage Linux d'IdeA. À utiliser à chaque fois qu'un correctif backend/front doit être rendu actif dans l'app (rappel : **le binaire qui tourne = l'AppImage installée, pas les sources** — un correctif n'est actif qu'après rebuild + remplacement + relance d'IdeA).
|
||||
|
||||
## Procédure (2 étapes, depuis le project root `/home/anthony/Documents/Projects/IdeA`)
|
||||
|
||||
@ -12,16 +12,18 @@ npm --prefix frontend run build
|
||||
### 2. Bundle Tauri AppImage (depuis `crates/app-tauri/`)
|
||||
```bash
|
||||
cd crates/app-tauri
|
||||
APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage
|
||||
mkdir -p /tmp/idea-cargo-home
|
||||
CARGO_HOME=/tmp/idea-cargo-home APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1 ../../frontend/node_modules/.bin/tauri build --bundles appimage
|
||||
```
|
||||
|
||||
## Pourquoi ces options (ne pas les retirer)
|
||||
- `--bundles appimage` : **exclut NSIS** (installeur Windows) — sinutile et cassant sur Linux.
|
||||
- `APPIMAGE_EXTRACT_AND_RUN=1 NO_STRIP=1` : **workaround FUSE obligatoire**. Sans ça, l'étape finale `linuxdeploy` (elle-même une AppImage montée via FUSE) échoue avec `failed to run linuxdeploy`. Le compile Rust réussit avant ce point ; seul le bundling casse (l'`AppDir` est généré mais pas le `.AppImage`).
|
||||
- `CARGO_HOME=/tmp/idea-cargo-home` : **workaround sandbox/permissions** pour les environnements où `/home/<user>/.cargo` est monté en lecture seule. Sans ça, `tauri build` peut échouer pendant le téléchargement/unpack Cargo avec `Read-only file system (os error 30)`.
|
||||
|
||||
## Artefact produit
|
||||
```
|
||||
target/release/bundle/appimage/IdeA_0.1.0_amd64.AppImage
|
||||
target/release/bundle/appimage/IdeA_0.3.0_amd64.AppImage
|
||||
```
|
||||
(Le build est long : compile Rust release ~1 min + bundling. Lancer en arrière-plan.)
|
||||
|
||||
@ -29,4 +31,4 @@ target/release/bundle/appimage/IdeA_0.1.0_amd64.AppImage
|
||||
Pour rendre le correctif actif, il faut **remplacer l'AppImage installée** `/home/anthony/Documents/IdeA_0.1.0_amd64.AppImage` par l'artefact, puis **relancer IdeA**. ⚠️ Relancer IdeA **tue l'orchestrateur en cours** (le serveur qui héberge la session active et les ponts MCP) : à faire par l'utilisateur quand il est prêt, pas en pleine session multi-agents. Garder un backup de l'ancienne AppImage avant remplacement (cf. convention `.old-<raison>`).
|
||||
|
||||
## Piège env (si on lance un binaire ensuite)
|
||||
La session shell hérite des variables de l'AppImage montée (`APPDIR`, `LD_LIBRARY_PATH`, `PYTHONHOME` → `/tmp/.mount_IdeA_*`). Pour lancer un binaire app-tauri compilé sans crash WebKit, partir d'un env propre (`env -i PATH=/usr/bin:/bin HOME=$HOME XDG_RUNTIME_DIR=/run/user/1000 …`) et préférer `jq` à `python3`.
|
||||
La session shell hérite des variables de l'AppImage montée (`APPDIR`, `LD_LIBRARY_PATH`, `PYTHONHOME` → `/tmp/.mount_IdeA_*`). Pour lancer un binaire app-tauri compilé sans crash WebKit, partir d'un env propre (`env -i PATH=/usr/bin:/bin HOME=$HOME XDG_RUNTIME_DIR=/run/user/1000 …`) et préférer `jq` à `python3`.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
issueRef: "#140"
|
||||
version: 3
|
||||
updatedBy: {"kind":"user"}
|
||||
updatedAt: 1785760014957
|
||||
version: 4
|
||||
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
|
||||
updatedAt: 1785760572251
|
||||
---
|
||||
|
||||
@ -2,16 +2,16 @@
|
||||
id: "353aa2ae-cf98-4a63-b4fb-a15fdb801a0a"
|
||||
number: 140
|
||||
title: "[Bug] je ne peux pas editer le context projet d'un agent a la main"
|
||||
status: "open"
|
||||
status: "closed"
|
||||
priority: "medium"
|
||||
sprint: null
|
||||
links: []
|
||||
agentRefs: [{"agentId":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d","role":"assigned"}]
|
||||
attachments: []
|
||||
createdBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"user"}
|
||||
updatedBy: {"kind":"agent","agent_id":"a6c6ea12-bfc6-4bdc-8031-324102dfa34d"}
|
||||
createdAt: 1785759952774
|
||||
updatedAt: 1785760014957
|
||||
version: 3
|
||||
updatedAt: 1785760572251
|
||||
version: 4
|
||||
---
|
||||
Quand je suis dans le panneau des agents, que je selectionne un agent, le context projet de l'agent s'affiche mal (il n'affiche que [object Object]) et si je l'edit, que je save, et que je le réouvre il estd e nouveau vide
|
||||
@ -66,6 +66,7 @@ Fichier obligatoire : `idea-plugin.json`.
|
||||
"main": "dist/index.js",
|
||||
"icon": "assets/icon.svg",
|
||||
"trustLevel": "full",
|
||||
"activationScope": "app",
|
||||
"capabilities": ["ui", "mcp"],
|
||||
"contributes": {
|
||||
"menus": [],
|
||||
@ -82,6 +83,7 @@ Fichier obligatoire : `idea-plugin.json`.
|
||||
Validation :
|
||||
|
||||
- `trustLevel` vaut uniquement `full` en v1.
|
||||
- `activationScope` est optionnel, vaut `app` par défaut, ou `project` pour différer l'activation runtime jusqu'au premier projet focused ; l'état `pending` n'est pas une erreur de chargement.
|
||||
- `main`, `icon`, assets et commandes MCP relatives ne doivent contenir ni chemin absolu ni `..`.
|
||||
- `id` stable, unique, reverse-DNS recommandé.
|
||||
- `version` SemVer.
|
||||
@ -346,4 +348,4 @@ Livrable : substitution `${appDataDir}` dans `command`, `args`, `env`, `cwd` des
|
||||
- Pas de marketplace distant.
|
||||
- Pas de compilation TS/TSX.
|
||||
- Pas de `${projectRoot}` pour serveurs MCP plugin globaux.
|
||||
- Pas de garantie v1 sur `agentSelected`, `terminalFocused`, `layoutCellFocused` tant qu'un lot focus/selection n'a pas été cadré.
|
||||
- Pas de garantie v1 sur `agentSelected`, `terminalFocused`, `layoutCellFocused` tant qu'un lot focus/selection n'a pas été cadré.
|
||||
|
||||
@ -1812,7 +1812,7 @@
|
||||
"issueRef": "#140",
|
||||
"path": "140",
|
||||
"title": "[Bug] je ne peux pas editer le context projet d'un agent a la main",
|
||||
"status": "open",
|
||||
"status": "closed",
|
||||
"priority": "medium",
|
||||
"sprint": null,
|
||||
"assignedAgentIds": [
|
||||
@ -1821,7 +1821,7 @@
|
||||
"createdBy": {
|
||||
"kind": "user"
|
||||
},
|
||||
"updatedAt": 1785760014957
|
||||
"updatedAt": 1785760572251
|
||||
}
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user