chore(projects): rename ia_dev project lecoffreio to kogus

- Move projects/lecoffreio to projects/kogus; update conf id and secrets_path
- Refresh agents, deploy script examples, project README, kogus docs paths
- Keep product hostname/systemd naming (lecoffreio) unchanged

.smartIde/agents/change-to-all-branches.md

@@ -43,7 +43,7 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
 
 **Rôle de l’agent :** vérifier que la branche locale est test (sinon retour 1), fournir le message de commit (via /push-by-script), lancer le script, contrôler la sortie et le code de retour. **Rôle du script :** exécution déterministe (vérif branche test, `branch-align.sh test`, orchestrateur ou `deploy.sh test --no-sync-origin` ; flags métier uniquement via `$SECRETS_BASE/test/deploy.conf` ; journalisation toujours `./logs/deploy_*.log`). Préparation OS cible : agent **`/setup-host`** + `deploy/scripts_v2/run-setup-host.sh`, pas `deploy.sh`.
 
-**Projet lecoffreio :** si le script enchaîne **`deploy/scripts_v2`**, appliquer le contrat multisite (**`SITE_CODE`** / **`deploy-site.sh`** / **`deploy-lecoffre-all-sites.sh`**, secrets **`.secrets/<site>/<env>/`**) décrit dans **`repository_root/docs/features/multi-site-architecture.md`** et **`repository_root/.cursor/agents/agent-paths-registry.md`** §3 bis (les agents Cursor du dépôt applicatif sont sous **`.cursor/agents/`**, pas **`.smartIde`**).
+**Projet kogus (monorepo LeCoffre) :** si le script enchaîne **`deploy/scripts_v2`**, appliquer le contrat multisite (**`SITE_CODE`** / **`deploy-site.sh`** / **`deploy-lecoffre-all-sites.sh`**, secrets **`.secrets/<site>/<env>/`**) décrit dans **`repository_root/docs/features/multi-site-architecture.md`** et **`repository_root/.cursor/agents/agent-paths-registry.md`** §3 bis (les agents Cursor du dépôt applicatif sont sous **`.cursor/agents/`**, pas **`.smartIde`**).
 
 **Branche applicative test-first (obligatoire) :** Toute correction de code, configuration ou documentation dans le **dépôt applicatif** (`repository_root` dans `projects/<id>/conf.json`) pendant l’exécution de cet agent doit être réalisée sur la branche locale **test**. Avant toute modification : si le dépôt applicatif n’est pas sur **test**, exécuter **`git checkout test`** (ou équivalent validé projet). **Interdit** : committer un correctif **uniquement** sur **pprod** ou **prod** depuis cet agent. Si l’échec ou le contexte provient d’une phase **pprod**/**prod** (correctifs identifiés après déploiement ou analyse sur ces branches), appliquer la procédure **Corrections découvertes sur pprod ou prod** dans `.smartIde/agents/deploy-pprod-or-prod.md` : correctifs sur **test**, puis **rejouer** le workflow complet depuis l’étape 2 de cet agent dans ce flux (**`/change-to-all-branches`** inclus dans **`/deploy-pprod-or-prod`**), sans court-circuiter l’alignement **test → pprod → prod**.
 
@@ -73,7 +73,7 @@ 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 de ia_dev** : `./deploy/change-to-all-branches.sh [project_id]` — aligne origin/test, origin/pprod, origin/prod sur le SHA de test, puis déploie l'environnement test (`orchestrator.sh` ou `deploy.sh test --no-sync-origin` ; métier via `deploy.conf` ; logs `./logs/`). project_id optionnel pour cibler le projet. Push direct uniquement ; aucun script ni agent ne crée de pull request.
-   - **Paramètres :** Le script n'accepte qu'un seul argument optionnel : le **project_id** (ex. lecoffreio). La branche est toujours **test** (imposée par le script, pas un paramètre). Si l'utilisateur fournit deux tokens (ex. « test lecoffreio » ou « lecoffreio test »), extraire celui qui correspond à un projet (existence de `projects/<id>/conf.json`) et appeler le script avec uniquement ce project_id : `./deploy/change-to-all-branches.sh lecoffreio`.
+   - **Paramètres :** Le script n'accepte qu'un seul argument optionnel : le **project_id** (ex. kogus). La branche est toujours **test** (imposée par le script, pas un paramètre). Si l'utilisateur fournit deux tokens (ex. « test kogus » ou « kogus test »), extraire celui qui correspond à un projet (existence de `projects/<id>/conf.json`) et appeler le script avec uniquement ce project_id : `./deploy/change-to-all-branches.sh kogus`.
    - **Pas de timeout :** Ne pas lancer la commande avec un timeout court (ex. 5 min). Le déploiement (build, migrations, import-v1, redémarrage services, vérifications) peut durer 10 à 30 min ; utiliser un timeout long ou aucun timeout pour laisser le script aller au bout.
 
 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. **Si la cause est typecheck / lint / build** : lancer **intégralement** l'agent **/fix-lint** pour le projet, puis /push-by-script, puis **relancer immédiatement** change-to-all-branches.sh (sans demander à l'utilisateur). Répéter jusqu'à succès ou **5 tentatives** ; au-delà, documenter et s'arrêter. Pour les autres causes (erreur serveur, secret manquant, infra) : s'arrêter si la correction n'est pas possible sans instruction utilisateur.

.smartIde/agents/deploy-by-script.md

@@ -31,9 +31,9 @@ En tant qu'agent, avant de solliciter l'ia, regarde ce que tu peux scripter (imp
 
 **Documentation** : La doc des projets gérés est dans **`projects/<id>/docs`** ; la doc ia_dev est dans **`projects/ia_dev/docs`**.
 
-**`deploy.host_stays_on_test: true` dans `projects/<id>/conf.json` (ex. lecoffreio / LeCoffre) :** le clone applicatif (`repository_root`) reste sur la branche Git locale **`test`** pour les déploiements **pprod**/**prod** via **`deploy-by-script-to.sh`**. L’environnement cible est l’**argument** du script. Le `deploy.sh` du dépôt aligne les remotes / **worktree** (ex. **`git push lecoffre_ng test:<branche>`** pour LeCoffre) — pas de **`git checkout pprod`**/**`prod`** sur le poste. Vérifier **`test`** aligné avec le remote attendu. Doc applicative : **`deploy/README.md`** ; agents Cursor du dépôt LeCoffre : **`repository_root/.cursor/agents/deploy-by-script.md`** (pas **`.smartIde`** sur le dépôt applicatif).
+**`deploy.host_stays_on_test: true` dans `projects/<id>/conf.json` (ex. **kogus** / monorepo LeCoffre) :** le clone applicatif (`repository_root`) reste sur la branche Git locale **`test`** pour les déploiements **pprod**/**prod** via **`deploy-by-script-to.sh`**. L’environnement cible est l’**argument** du script. Le `deploy.sh` du dépôt aligne les remotes / **worktree** (ex. **`git push lecoffre_ng test:<branche>`** pour LeCoffre) — pas de **`git checkout pprod`**/**`prod`** sur le poste. Vérifier **`test`** aligné avec le remote attendu. Doc applicative : **`deploy/README.md`** ; agents Cursor du dépôt LeCoffre : **`repository_root/.cursor/agents/deploy-by-script.md`** (pas **`.smartIde`** sur le dépôt applicatif).
 
-## Multisite — projet **lecoffreio**
+## Multisite — projet **kogus** (site produit `lecoffreio` = ligne notary, inchangé côté BDD)
 
 Lorsque le playbook appelle **`repository_root/deploy/scripts_v2/`**, respecter la boucle **`SITE_CODE`** (**`notary`**, **`enso`**, **`genealogie`**) ou **`deploy-site.sh`** / **`deploy-lecoffre-all-sites.sh`** ; **`deploy-by-script-to`** ne positionne pas **`SITE_CODE`**. Secrets : **`.secrets/<site>/<env>/`**. Source normative : **`repository_root/docs/features/multi-site-architecture.md`** ; **`repository_root/.cursor/agents/agent-paths-registry.md`** §3 bis ; § **Multisite** dans **`repository_root/.cursor/agents/deploy-pprod-or-prod.md`**.
 
@@ -54,7 +54,7 @@ Cet agent lance le déploiement vers l’**environnement passé au script** (ex.
 **Horodatage et contexte** : appliquer intégralement le bloc défini dans `.smartIde/rules/cloture-evolution.mdc` (début et fin d'exécution, lancement et retour des sub-agents).
 
 **Avant d'exécuter un script du projet :**
-1. Lire le fichier du script avec l'outil de lecture (ex. `deploy/scripts_v2/deploy.sh` ; pour **lecoffreio**, lire aussi **`deploy-site.sh`** / **`deploy-lecoffre-all-sites.sh`** si le flux les utilise).
+1. Lire le fichier du script avec l'outil de lecture (ex. `deploy/scripts_v2/deploy.sh` ; pour **kogus**, lire aussi **`deploy-site.sh`** / **`deploy-lecoffre-all-sites.sh`** si le flux les utilise).
 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.
 
@@ -64,7 +64,7 @@ Cet agent lance le déploiement vers l’**environnement passé au script** (ex.
 
 Le script applique **par défaut** une exécution standardisée : sync avec origin (`--sync-origin`, désactivable avec `--no-sync-origin`). La sortie est **toujours** enregistrée sous `logs/deploy_*.log`. Préparation paquets sur la cible : **`/setup-host`** + `deploy/scripts_v2/run-setup-host.sh`, pas `deploy.sh`.
 
-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). Pour cibler un projet explicitement : passer l’id en premier argument, ex. `./deploy/deploy-by-script-to.sh lecoffreio prod` (ou utiliser MAIL_TO / AI_AGENT_TOKEN). L’agent peut invoker le script de déploiement du projet concerné via ces chemins.
+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). Pour cibler un projet explicitement : passer l’id en premier argument, ex. `./deploy/deploy-by-script-to.sh kogus prod` (ou utiliser MAIL_TO / AI_AGENT_TOKEN). 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.
 

.smartIde/agents/deploy-pprod-or-prod.md

@@ -70,7 +70,7 @@ Si l’utilisateur ou un autre processus **a** déjà aligné / poussé : **le s
 
 Cocher explicitement : **« Ordre anti-duplication : respecté (pas de `/push-by-script` ni `/change-to-all-branches` standalone avant l’étape 2 hors ce workflow) »** — ou documenter l’exception si évolution du fichier sans étape 2. Cocher : **« Corrections pprod/prod : si applicable, faites sur test puis workflow rejoué depuis étape 2 (aucun correctif applicatif « seulement pprod/prod ») »**. Cocher aussi : **« Lint min. 5 : exécuté sur repository_root + décompte avant/après (ou 0 diagnostic) ; pas de report seul sur /fix-lint »**.
 
-## Multisite — projet **lecoffreio**
+## Multisite — projet **kogus** (monorepo LeCoffre ; code produit site `lecoffreio` inchangé)
 
 Quand **`repository_root`** est le monorepo LeCoffre et **`deploy-by-script-to`** enchaîne **`deploy/scripts_v2/`**, l’orchestration doit couvrir **`notary`**, **`enso`**, **`genealogie`** (**`SITE_CODE`** ou **`deploy-site.sh`** / **`deploy-lecoffre-all-sites.sh`**) ; **`deploy-by-script-to`** ne définit pas **`SITE_CODE`**. Secrets : **`.secrets/<site>/<env>/`**. Doc : **`repository_root/docs/features/multi-site-architecture.md`** ; **`repository_root/.cursor/agents/agent-paths-registry.md`** §3 bis ; **`repository_root/.cursor/agents/deploy-pprod-or-prod.md`** § Multisite.
 
@@ -85,8 +85,8 @@ Quand **`repository_root`** est le monorepo LeCoffre et **`deploy-by-script-to`*
 
 3. **Lancer le script deploy-by-script-to** avec l’environnement en paramètre (`pprod` ou `prod`) :
    - Le script est lancé depuis la racine de ia_dev. Avec project_id (optionnel), MAIL_TO ou AI_AGENT_TOKEN le dépôt cible est celui de la conf (deploy.secrets_path). Lancer : `./deploy/deploy-by-script-to.sh [project_id] <pprod|prod>`.
-   - **`deploy.host_stays_on_test: true`** dans `projects/<id>/conf.json` (LeCoffre : **true** dans `projects/lecoffreio/conf.json`) : le clone applicatif reste sur **`test`** ; `deploy-by-script-to.sh` ne fait **pas** de `checkout` **pprod**/**prod** ni `reset --hard` sur ces branches ; le `deploy.sh` du dépôt aligne les remotes / **worktree** (voir **`deploy/README.md`** du dépôt applicatif).
+   - **`deploy.host_stays_on_test: true`** dans `projects/<id>/conf.json` (LeCoffre : **true** dans `projects/kogus/conf.json`) : le clone applicatif reste sur **`test`** ; `deploy-by-script-to.sh` ne fait **pas** de `checkout` **pprod**/**prod** ni `reset --hard` sur ces branches ; le `deploy.sh` du dépôt aligne les remotes / **worktree** (voir **`deploy/README.md`** du dépôt applicatif).
-   - **Sinon :** le script fait en général : passage dans le dépôt du projet, `checkout` sur la branche paramètre, vérification que la base secrets attendue par le projet existe (**lecoffreio** : imbriquée **`.secrets/<site>/<env>/`**, voir **`repository_root/docs/features/multi-site-architecture.md`** — le seul plat **`.secrets/<env>/`** n’est pas le contrat nominal multisite), `reset --hard` sur **`origin/<branche>`**, déploiement (orchestrateur ou `deploy.sh`), puis **`checkout test`**.
+   - **Sinon :** le script fait en général : passage dans le dépôt du projet, `checkout` sur la branche paramètre, vérification que la base secrets attendue par le projet existe (**kogus** / monorepo LeCoffre : imbriquée **`.secrets/<site>/<env>/`**, voir **`repository_root/docs/features/multi-site-architecture.md`** — le seul plat **`.secrets/<env>/`** n’est pas le contrat nominal multisite), `reset --hard` sur **`origin/<branche>`**, déploiement (orchestrateur ou `deploy.sh`), puis **`checkout test`**.
    - **Si KO :** Analyser la sortie et les logs, identifier la cause. **Ne pas** se limiter à corriger sur la branche **pprod**/**prod** : retour **test**, corrections, puis **rejouer depuis l’étape 2** (**`/change-to-all-branches`** puis **`deploy-by-script-to`**) jusqu'à succès (section **Corrections découvertes sur pprod ou prod**).
    - **Si OK :** Passer à l'étape 4.
 

.smartIde/agents/setup-host.md

@@ -23,7 +23,7 @@ is_background: false
 4. **Invocation** : depuis la racine du dépôt projet (`cd "$(jq -r '.deploy.repository_root' conf.json)"` ou équivalent) :
    - `bash deploy/scripts_v2/run-setup-host.sh <test|pprod|prod>`
    - L’environnement doit être passé explicitement (pas de valeur par défaut métier).
-5. **Secrets** : **`run-setup-host.sh`** résout le répertoire d’env via **`lecoffre_secrets_env_dir_for_read`** (layout **`.secrets/<site>/<env>/`** pour LeCoffre, comme **`deploy.sh`** / **`connect-db-paths.sh`**) ; s’assurer que **`SITE_CODE`** ou les trois branches **`notary`**, **`enso`**, **`genealogie`** sont peuplées selon le projet — voir **`repository_root/docs/features/multi-site-architecture.md`** pour **lecoffreio**.
+5. **Secrets** : **`run-setup-host.sh`** résout le répertoire d’env via **`lecoffre_secrets_env_dir_for_read`** (layout **`.secrets/<site>/<env>/`** pour LeCoffre, comme **`deploy.sh`** / **`connect-db-paths.sh`**) ; s’assurer que **`SITE_CODE`** ou les trois branches **`notary`**, **`enso`**, **`genealogie`** sont peuplées selon le projet — voir **`repository_root/docs/features/multi-site-architecture.md`** pour le projet **kogus** (monorepo LeCoffre).
 6. **Sortie** : ne pas masquer stdout/stderr ; en échec, relire les messages sudo / SSH.
 7. **Clôture** : appliquer `.smartIde/rules/cloture-evolution.mdc` en fin d’exécution agent (horodatage, questions 3–11 selon périmètre touché).
 

.smartIde/rules/cloture-evolution.mdc

@@ -10,7 +10,7 @@ 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 :** 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.
+**Contexte projet :** Les agents sont définis et lancés depuis ia_dev (centralisé) mais sont **dédiés aux projets configurés** (kogus — monorepo LeCoffre multisite ; 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 (standalone) :** Racine de ia_dev. Tous les scripts `deploy/` et `git-issues/` doivent être invoqués depuis la racine de ia_dev, ex. `./deploy/pousse.sh`, `./git-issues/wiki-migrate-docs.sh`. Les chemins absolus dans `conf.json` pointent vers les dépôts des projets.
 

.smartIde/rules/rules.mdc

@@ -6,7 +6,7 @@ model: inherit
 
 # Règles pour tous aussi pour l'IA
 
-**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.
+**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** (kogus — monorepo LeCoffre multisite ; 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 (standalone) :** Les scripts `deploy/` et `git-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`, `./git-issues/wiki-migrate-docs.sh`.
 

ai_working_help/notary-ai/notary-ai-wait-agent-then-loop-10h.sh

@@ -28,8 +28,8 @@ IA_DEV_ROOT="$(cd "${NOTARY_AI_DIR}/../.." && pwd)"
 cd "$IA_DEV_ROOT"
 
 if [[ -z "${MAIL_TO:-}" && -z "${AI_AGENT_TOKEN:-}" ]]; then
-	if [[ -f "${IA_DEV_ROOT}/projects/lecoffreio/.secrets/test/ia_token" ]]; then
+	if [[ -f "${IA_DEV_ROOT}/projects/kogus/.secrets/test/ia_token" ]]; then
-		AI_AGENT_TOKEN="$(tr -d ' \n\r\t' < "${IA_DEV_ROOT}/projects/lecoffreio/.secrets/test/ia_token")"
+		AI_AGENT_TOKEN="$(tr -d ' \n\r\t' < "${IA_DEV_ROOT}/projects/kogus/.secrets/test/ia_token")"
 		export AI_AGENT_TOKEN
 	fi
 fi

deploy/bump-version.sh

@@ -24,7 +24,7 @@ SHORT_MSG="${2:-Nouvelles fonctionnalités et améliorations}"
 
 if [[ -z "$VERSION" ]]; then
   echo "❌ Usage: ./bump-version.sh [project_id] <version> [message_court]"
-  echo "   Exemple: ./bump-version.sh lecoffreio 2.1.0 'Nouveaux filtres'"
+  echo "   Exemple: ./bump-version.sh kogus 2.1.0 'Nouveaux filtres'"
   exit 1
 fi
 

deploy/deploy.sh

@@ -1,7 +1,7 @@
 #!/usr/bin/env bash
 # Generic deploy entry from ia_dev: shared methodology (envs, contract), then ia_dev orchestrator → project orchestrator.
 # Usage (from ia_dev root): ./deploy/deploy.sh <project_id> <env> [options…]
-# Example: ./deploy/deploy.sh lecoffreio test --no-sync-origin
+# Example: ./deploy/deploy.sh kogus test --no-sync-origin
 set -euo pipefail
 
 SCRIPT_REAL="$(readlink -f "${BASH_SOURCE[0]:-$0}" 2>/dev/null || realpath "${BASH_SOURCE[0]:-$0}" 2>/dev/null || echo "${BASH_SOURCE[0]:-$0}")"
@@ -18,7 +18,7 @@ source "${DEPLOY_DIR}/lib/deploy-methodology.sh"
 if [[ $# -lt 2 ]]; then
 	echo "[deploy][ERROR] Missing arguments" >&2
 	echo "Usage: $0 <project_id> <env> [options passed to project orchestrator]" >&2
-	echo "Example: $0 lecoffreio test --no-sync-origin" >&2
+	echo "Example: $0 kogus test --no-sync-origin" >&2
 	exit 1
 fi
 

deploy/pousse.sh

@@ -42,7 +42,7 @@ usage() {
 Usage:
   ./deploy/pousse.sh [project_id|--project <project_id>] [--remote <remote>] [--bump-version]
 
-  project_id     Optional. Id from projects/<id>/conf.json (e.g. lecoffreio). Else from MAIL_TO or AI_AGENT_TOKEN.
+  project_id     Optional. Id from projects/<id>/conf.json (e.g. kogus). Else from MAIL_TO or AI_AGENT_TOKEN.
   --project <id> Same as positional project_id.
   --bump-version Increment patch (third component) in VERSION before staging.
 

lib/project_config.sh

@@ -4,7 +4,7 @@
 # Resolves PROJECT_ID and PROJECT_CONFIG_PATH (projects/<id>/conf.json).
 #
 # Project id is resolved by (first match wins):
-#   1. IA_PROJECT_ID (env): explicit project id; set by scripts when passed as parameter (e.g. ./pousse.sh lecoffreio).
+#   1. IA_PROJECT_ID (env): explicit project id; set by scripts when passed as parameter (e.g. ./pousse.sh kogus).
 #   2. 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).
 #   3. AI_AGENT_TOKEN (env): search all projects/.secrets/<env>/ia_token for matching token; sets PROJECT_ID and PROJECT_ENV (project and environment).
 #

projects/README.md

@@ -6,7 +6,7 @@ Documentation canonique dans **smart_ide** :
 
 ## Projects (examples)
 
-- **lecoffreio** — directory `projects/lecoffreio/` (see `conf.json` + optional `.secrets/`).
+- **kogus** — directory `projects/kogus/` : monorepo LeCoffre multisite (`notary` / `enso` / `genealogie` comme **`SITE_CODE`** dans le dépôt applicatif). Identifiant **ia_dev** distinct du **code produit** `lecoffreio` (ligne notaire en base / API). Voir `conf.json` + optional `.secrets/`.
-- **enso** — `projects/enso/conf.json` registers the Enso monorepo (`deploy.repository_root`) and `deploy.secrets_path` → `$IA_DEV_ROOT/.secrets/enso` (per-env `enso-deploy.env` under `test` / `pprod` / `prod`).
+- **enso** — `projects/enso/conf.json` : autre dépôt applicatif (projet **ia_dev** séparé nommé « enso »), **pas** le même objet que la ligne de déploiement **`SITE_CODE=enso`** du monorepo **kogus**. Enregistre `deploy.repository_root` et `deploy.secrets_path` → `$IA_DEV_ROOT/.secrets/enso` (per-env `enso-deploy.env` sous `test` / `pprod` / `prod`).
 
 **Note (enso):** the previous broken symlink `projects/enso` → `../../projects/enso` was removed. Use this versioned directory only; do not recreate that relative symlink.

projects/ia_dev/docs/GIT_ISSUES_SCRIPTS_AGENTS.md

@@ -147,7 +147,7 @@ Le répertoire `docs/` n'est pas versionné. Pour disposer d'une copie locale (
 
 ### Usage « wiki uniquement » pour les agents
 
-La connaissance du projet peut reposer **uniquement sur le wiki** (sans lire `docs/`) : les agents peuvent exécuter `./git-issues/wiki-get-page.sh <PageName>` pour récupérer le contenu markdown d'une page et l'utiliser comme référence. Exemples : `./git-issues/wiki-get-page.sh Home`, `./git-issues/wiki-get-page.sh Operations`, `./git-issues/wiki-get-page.sh Code-Standards`. Prérequis : token Gitea (comme pour les autres scripts wiki). Les agents peuvent ainsi consulter la doc projet à la demande depuis le wiki, sans dépendre des fichiers locaux `docs/`. La documentation des projets gérés est dans **`projects/<id>/docs`** (ex. `projects/lecoffreio/docs`) ; la documentation propre à ia_dev est dans **`projects/ia_dev/docs`**.
+La connaissance du projet peut reposer **uniquement sur le wiki** (sans lire `docs/`) : les agents peuvent exécuter `./git-issues/wiki-get-page.sh <PageName>` pour récupérer le contenu markdown d'une page et l'utiliser comme référence. Exemples : `./git-issues/wiki-get-page.sh Home`, `./git-issues/wiki-get-page.sh Operations`, `./git-issues/wiki-get-page.sh Code-Standards`. Prérequis : token Gitea (comme pour les autres scripts wiki). Les agents peuvent ainsi consulter la doc projet à la demande depuis le wiki, sans dépendre des fichiers locaux `docs/`. La documentation des projets gérés est dans **`projects/<id>/docs`** (ex. `projects/kogus/docs`) ; la documentation propre à ia_dev est dans **`projects/ia_dev/docs`**.
 
 ## Agents (commandes)
 

projects/ia_dev/docs/README.md

@@ -3,7 +3,7 @@
 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`).
+- **Projets gérés** : `projects/<id>/docs` (ex. `projects/kogus/docs`).
 - **ia_dev (ce dépôt)** : `projects/ia_dev/docs` (ce répertoire).
 
 - **agents-scripts-split.md** : Répartition des rôles entre agents Cursor et scripts (branch-align, change-to-all-branches, deploy, push), exécution depuis la racine, options standardisées.

projects/kogus/conf.json

@@ -1,5 +1,5 @@
 {
-	"id": "lecoffreio",
+	"id": "kogus",
 	"name": "Lecoffre.io",
 	"project_path": "/home/desk/code/lecoffre_ng_test/deploy",
 	"build_dirs": [
@@ -12,7 +12,7 @@
 		"scripts_path": "/home/desk/code/lecoffre_ng_test/deploy/scripts_v2",
 		"deploy_script_path": "/home/desk/code/lecoffre_ng_test/deploy/scripts_v2/deploy.sh",
 		"project_orchestrator_path": "deploy/scripts_v2/deploy.sh",
-		"secrets_path": "/home/desk/code/ia_dev/projects/lecoffreio/.secrets",
+		"secrets_path": "/home/desk/code/ia_dev/projects/kogus/.secrets",
 		"host_stays_on_test": true
 	},
 	"version": {

projects/kogus/data/issues/2026-03-16T150856.55fb50b8.nicolas.cantu_pm.me.pending

@@ -30,7 +30,7 @@
     "in_reply_to_message_id": "<G1Cb1a_-Vb-E4o4zC1uNbA1u8sSD23ledYvzJozkp4GIkFVS1UJqwloYIKVIVZ5yCmh0mFj7dDcJMOEuWrg3GUu-eTVhY5Nfar5jiM5a-fQ=@pm.me>",
     "to": "nicolas.cantu@pm.me",
     "subject": "Re: Présent le projet",
-    "body": "Le projet Lecoffre.io (LeCoffre) est une application de gestion de coffre-fort numérique et de documents, déployée sur les environnements test, préproduction et production. Le dépôt de code est hébergé sur Gitea (git.4nkweb.com). Les tickets et le support sont gérés via les issues Gitea et la boîte de support IA. La configuration et la documentation du projet sont dans ia_dev/projects/lecoffreio/.",
+    "body": "Le projet Lecoffre.io (LeCoffre) est une application de gestion de coffre-fort numérique et de documents, déployée sur les environnements test, préproduction et production. Le dépôt de code est hébergé sur Gitea (git.4nkweb.com). Les tickets et le support sont gérés via les issues Gitea et la boîte de support IA. La configuration et la documentation du projet sont dans ia_dev/projects/kogus/.",
     "sent_at": "2026-03-16T16:17:12Z"
   }
 }

projects/kogus/data/issues/2026-03-16T154650.19e0f3e9.nicolas.4nk_pm.me.pending

@@ -30,7 +30,7 @@
     "in_reply_to_message_id": "<YZ6wMSX0dOKQc6NSlJIjvN75cLSk0pEwFbmibuA9LrVro-aS_yfrra93ykYgJgAk2XjcuD-cNe2zf_HOtAL1Yl7LKmCaXezG4nBMfjwkrs4=@pm.me>",
     "to": "nicolas.4nk@pm.me",
     "subject": "Re: Présente le projet",
-    "body": "Le projet Lecoffre.io (LeCoffre) est une application de gestion de coffre-fort numérique et de documents, déployée sur les environnements test, préproduction et production. Le dépôt de code est hébergé sur Gitea (git.4nkweb.com). Les tickets et le support sont gérés via les issues Gitea et la boîte de support IA. La configuration et la documentation du projet sont dans ia_dev/projects/lecoffreio/.",
+    "body": "Le projet Lecoffre.io (LeCoffre) est une application de gestion de coffre-fort numérique et de documents, déployée sur les environnements test, préproduction et production. Le dépôt de code est hébergé sur Gitea (git.4nkweb.com). Les tickets et le support sont gérés via les issues Gitea et la boîte de support IA. La configuration et la documentation du projet sont dans ia_dev/projects/kogus/.",
     "sent_at": "2026-03-16T16:17:25Z"
   }
 }

projects/kogus/docs/API.md

@@ -2,7 +2,7 @@
 
 **Auteur** : Équipe 4NK
 
-Ce document consolide la documentation des APIs externes utilisées par LeCoffre.io. Référence détaillée (Ancrage Bitcoin Signet, Annuaire, configuration, déploiement) : `projects/lecoffreio/docs/API.md` dans le dépôt ia_dev. Référence unique des checks de déploiement : voir `Deployment.md` (cartographie des checks).
+Ce document consolide la documentation des APIs externes utilisées par LeCoffre.io. Référence détaillée (Ancrage Bitcoin Signet, Annuaire, configuration, déploiement) : `projects/kogus/docs/API.md` dans le dépôt ia_dev. Référence unique des checks de déploiement : voir `Deployment.md` (cartographie des checks).
 
 ## API agent IA notaire (ai_working_help)
 
@@ -56,7 +56,7 @@ L’agent ne doit jamais renvoyer RIB, coordonnées bancaires ou de paiement. Co
 
 ## Autres APIs (référence détaillée)
 
-- **API d’ancrage Bitcoin Signet** : vue d’ensemble, endpoints `/api/anchor/document`, `/api/anchor/verify`, flux synchrone, configuration et déploiement — voir `projects/lecoffreio/docs/API.md`.
+- **API d’ancrage Bitcoin Signet** : vue d’ensemble, endpoints `/api/anchor/document`, `/api/anchor/verify`, flux synchrone, configuration et déploiement — voir `projects/kogus/docs/API.md`.
 - **Intégration Genapi / iNot** : `POST /api/v1/notary/documents/:uid/push-inot`, OAuth, création eDocument, code métier `GENAPI_API_UNAVAILABLE`.
 - **Erreurs d’intégrations externes** : mappings `*_API_UNAVAILABLE` (GENAPI, ANNUAIRE, ANCHORAGE, IDNOT, OPENID, IPFS, MAILCHIMP, STRIPE) ; conventions `integration.operation` pour la traçabilité.
 

projects/kogus/docs/Code-Standards.md

@@ -67,7 +67,7 @@ Ces vérifications alimentent les tests manuels et les scripts d’analyse (voir
 ## Configuration qualité et inventaire des bypass
 
 **Date**: 2026-03-19  
-**Contexte**: Agent fix-lint projet lecoffreio — priorité amont (règles de qualité + bypass).
+**Contexte**: Agent fix-lint projet **kogus** (monorepo LeCoffre) — priorité amont (règles de qualité + bypass).
 
 ### Règles et exigences de qualité — état par sous-projet
 

projects/kogus/docs/Deployment.md

@@ -71,11 +71,11 @@ Liste des fichiers contenant les textes affichés à l’utilisateur (libellés,
 
 ## Déploiement applicatif
 
-- **Multi-site (`SITE_CODE`, secrets imbriqués)** : les scripts applicatifs (`deploy/scripts_v2`, `connect-db-paths.sh`) attendent **`.secrets/<site>/<env>/`** avec **`site ∈ { notary, enso, genealogie }`**. **`SITE_CODE`** (ou **`LECOFFRE_SITE_CODE`** / **`DEPLOY_SITE_CODE`**) doit être **exporté explicitement** avant ces scripts ; l’orchestrateur **ia_dev** ne le déduit pas depuis le `conf.json`. Sous **`projects/lecoffreio/conf.json`**, **`deploy.secrets_path`** pointe souvent vers un arbre **plat** **`<secrets_path>/<env>/`** uniquement : **`orchestrator.sh`** et **`deploy/deploy-by-script-to.sh`** peuvent alors créer pour chaque site **notary**, **enso**, **genealogie** un lien **`<secrets_path>/<site>/<env>` → `../<env>`** si l’emplacement imbriqué n’existe pas encore et que **`<secrets_path>/<env>/`** est un répertoire. Un répertoire **réel** (non lien) existant n’est pas écrasé ; pour des secrets **distincts** par site, remplacer le lien par un vrai répertoire.
+- **Multi-site (`SITE_CODE`, secrets imbriqués)** : les scripts applicatifs (`deploy/scripts_v2`, `connect-db-paths.sh`) attendent **`.secrets/<site>/<env>/`** avec **`site ∈ { notary, enso, genealogie }`**. **`SITE_CODE`** (ou **`LECOFFRE_SITE_CODE`** / **`DEPLOY_SITE_CODE`**) doit être **exporté explicitement** avant ces scripts ; l’orchestrateur **ia_dev** ne le déduit pas depuis le `conf.json`. Sous **`projects/kogus/conf.json`**, **`deploy.secrets_path`** pointe souvent vers un arbre **plat** **`<secrets_path>/<env>/`** uniquement : **`orchestrator.sh`** et **`deploy/deploy-by-script-to.sh`** peuvent alors créer pour chaque site **notary**, **enso**, **genealogie** un lien **`<secrets_path>/<site>/<env>` → `../<env>`** si l’emplacement imbriqué n’existe pas encore et que **`<secrets_path>/<env>/`** est un répertoire. Un répertoire **réel** (non lien) existant n’est pas écrasé ; pour des secrets **distincts** par site, remplacer le lien par un vrai répertoire.
 - **Orchestration ia_dev** : depuis la racine du dépôt ia_dev, `./deploy/deploy.sh <project_id> <env> [options]` exporte `IA_PROJECT_ID` puis exécute `orchestrator.sh`. Celui-ci enchaîne les scripts listés dans `deploy.hooks.phases` du `conf.json` du projet (chemins relatifs à `repository_root`), ou exécute `deploy.deploy_script_path` si `phases` est vide. `run-project-hooks.sh` délègue à `orchestrator.sh` (compatibilité). Cadrage : `deploy/DEPLOY_ORCHESTRATION_IA_DEV.md`.
-- **Scripts** : `deploy/scripts_v2/` ; chemin projet dans ia_dev `projects/lecoffreio/conf.json` (project_path, build_dirs, deploy.deploy_script_path, deploy.secrets_path).
+- **Scripts** : `deploy/scripts_v2/` ; chemin projet dans ia_dev `projects/kogus/conf.json` (project_path, build_dirs, deploy.deploy_script_path, deploy.secrets_path).
 - **Clé SSH déploiement (`DEPLOY_SSH_KEY`)** : définie dans `.secrets/<env>/.env.<env>`. Utiliser un chemin **portable** : par ex. `DEPLOY_SSH_KEY='$HOME/.ssh/id_ed25519_4nk'` (l’expansion de `$HOME`, `${HOME}` et un préfixe `~/` est appliquée par `lecoffre_deploy_resolve_deploy_ssh_key` après `load_dotenv_file_strict`, qui ne fait pas d’`eval`). Ne pas figer un autre compte système (`/home/desk/...`). Ordre de repli si la clé indiquée est absente : `$HOME/.ssh/id_ed25519_4nk`, puis `$HOME/.ssh/id_ed25519`. Avant toute connexion SSH, la clé retenue est validée avec `ssh-keygen -y`. Vérification réseau : `bash deploy/scripts_v2/run-verify-ssh.sh <env>` ou les trois d’un coup : `bash deploy/scripts_v2/run-verify-ssh-all-envs.sh`.
 - **Modifications locales** : en **test**, le script `deploy.sh` met en stash les changements non commités avant pull/require_clean et les remet en place (stash pop) en fin de déploiement réussi. En **pprod** et **prod**, les changements locaux sont mis en stash sans remise en place (pas de développement local à conserver).
 - **Versions** : version.package_json_paths (backend, frontend) ; splash_app_name pour la notice.
 - **Secrets** : `.secrets/<env>/env-full-<env>-for-bdd-injection.txt` pour l’injection en BDD ; NOTARY_AI_AGENT_URL, NOTARY_AI_AGENT_TOKEN pour l’agent IA notaire (voir API.md).
-- **Cartographie des checks de déploiement** : référence unique dans la doc projet (ex. projects/lecoffreio/docs ou doc dédiée) ; ne pas dupliquer ici.
+- **Cartographie des checks de déploiement** : référence unique dans la doc projet (ex. projects/kogus/docs ou doc dédiée) ; ne pas dupliquer ici.

projects/kogus/docs/README.md

@@ -1,6 +1,6 @@
 # Documentation LeCoffre.io (index)
 
-**Projet** : lecoffreio  
+**Projet ia_dev** : **kogus** (identifiant outillage ; le site produit « LeCoffre » reste `product_code` / `sites.code` **lecoffreio** côté applicatif).  
 **Wiki** : https://git.4nkweb.com/4nk/lecoffre_ng/wiki  
 **Correspondance fichier → page wiki** : nom du fichier sans `.md`, `_` → `-`, title-case par segment (ex. `README.md` → Readme, `Operations.md` → Operations).
 
@@ -22,3 +22,7 @@ Contenu des anciens dossiers `docs/features/` et `docs/fixKnowledge/` : ventilé
 ## Mise à jour du wiki
 
 Depuis la racine du dépôt qui contient `docs/` : exécuter le script de migration (si disponible depuis ia_dev) pour pousser `docs/*.md` vers le wiki. Correspondance détaillée : `projects/ia_dev/docs/GIT_ISSUES_SCRIPTS_AGENTS.md` (section Migration docs/ → wiki). Ne pas committer `docs/` (hors versionnement).
+
+## Dépôt applicatif `lecoffre_ng_test` (référence versionnée)
+
+Le monorepo applicatif (`deploy.repository_root` dans `projects/kogus/conf.json`) versionne **`docs/`** à sa racine : index **`docs/README.md`**, fiches **`docs/features/`**. Ce répertoire **`projects/kogus/docs/`** sous ia_dev reste un miroir / notes d’intégration agents ; en cas d’écart, le dépôt Git du code fait foi. Alignement **`VERSION`** / **`front-common/src/front/version.json`** / **`CHANGELOG.md`** : voir la même section *Numéro de version publié* dans le **`docs/README.md`** du monorepo.