Skills Celuga
verify-celuga-devis
Recette du module devis de `celuga-react` sur PostgreSQL et SMTP jetables.
Quand : Recette du module devis de celuga-react sur PostgreSQL et SMTP jetables.
Portée : machine (~/.agents/skills) · Fichiers : 1
Tout installer
Section intitulée « Tout installer »Copier le bloc et le coller dans un terminal. Il recrée tous les fichiers du skill.
dir="$HOME/.agents/skills/verify-celuga-devis"mkdir -p "$dir"cat > "$dir/SKILL.md" <<'CELUGA_SKILL_EOF'---name: verify-celuga-devisdescription: Vérifier le module devis Celuga sur PostgreSQL et SMTP jetables, avec parcours web, back-office, fichiers privés et preuves de persistance. Utiliser après un changement du module ou pour sa recette.---
# Vérifier Celuga devis
Exécuter depuis la racine du checkout à vérifier. Lire la carte `docs/module-devis/features/README.md` de ce checkout. Le pilote utilise les ports 15433, 11025, 18025, 3430 et 4432. Il ne peut pas fonctionner en parallèle avec un autre pilote utilisant ces ports. Le helper refuse la configuration de ce checkout si elle vise une autre base ou un autre SMTP. Lire les scripts du checkout avant de lancer une recette : le skill décrit leur contrat courant, les résultats historiques de `docs/module-devis/verification.md` ne valent pas résultat de cette exécution.
## Launch
```shbun install --frozen-lockfilenode scripts/verify-devis-pilot.mjs preparenode scripts/devis-pilot.mjs migratenode scripts/devis-pilot.mjs seed```
Le helper crée PostgreSQL 18.4 et Mailpit 1.29.0 avec des secrets locaux aléatoires si `.env` est absent. Mailpit exige STARTTLS et accepte l’authentification ; son certificat jetable est approuvé par les processus du lanceur via `NODE_EXTRA_CA_CERTS`. Le SMTP passe par les vrais `EMAIL_HOST`, `EMAIL_USER`, `EMAIL_PASS`, `EMAIL_PORT` du getter `getEmailConfig()` ; ne pas remplacer cela par un relais sans auth. Si `.env` existe, le helper valide ses cibles isolées et le conserve ; il ne crée alors ni conteneurs ni certificat et ne prouve pas seul que le transport fonctionne. Les collisions Docker ou de ports doivent être résolues en identifiant leur propriétaire, sans arrêter un autre environnement.
Démarrer dans deux sessions terminal contrôlables, garder leurs identifiants. La variable Astro empêche son détachement automatique sous un agent :
```shnode scripts/devis-pilot.mjs cmsASTRO_DEV_BACKGROUND=1 node scripts/devis-pilot.mjs web```
Le CMS est sur `http://localhost:3430`, le parcours sur `http://localhost:4432/devis`. La seed crée des documents explicitement identifiés comme fixtures et un administrateur synthétique dans `.devis-pilot-admin.json`, ignoré. Ne pas afficher ce fichier. Ne réserver aucun vrai créneau Calendly. Le lien par défaut du code courant est `https://calendly.com/ctachet/rencontre-celuga` ; une base existante peut conserver une ancienne URL de démonstration. Lire les réglages effectifs ; ni une ancienne preuve Oghma ni le lien par défaut ne prouvent la disponibilité du compte Celuga.
`apps/cms/src/env.ts` charge lui-même le `.env` racine et possède `getDevisPrivateDir()`. Avec le lanceur exécuté dans `apps/cms`, le chemin privé par défaut est `apps/cms/private/devis` ; un `DEVIS_PRIVATE_DIR` explicite le remplace. Le helper ne valide pas ce chemin : pour une configuration existante, vérifier qu’il appartient au pilote et ne pointe pas vers des fichiers partagés. Ce dossier n’est jamais servi comme média public. Les scripts conservent leurs propres lecteurs de configuration ; ne pas prétendre que toutes les variables sont centralisées.
## Doctor
```shnode scripts/verify-devis-pilot.mjs doctor```
Ce contrôle lit la configuration isolée, vérifie via `lsof` que les ports CMS/web appartiennent à ce checkout, puis lit les réglages publics, la page sans cache et Mailpit. Il écrit `.evidence/devis-skill/doctor.json`. Un échec interdit de conduire une instance inconnue. Ce helper requiert macOS ou un environnement avec `lsof`.
## Drive
Pour le web interactif, utiliser le navigateur collaboratif disponible dans l’hôte et son API documentée : identifier l’onglet puis lire son état avant d’agir. Une commande qui expire reste inconclusive. Le scénario Playwright du dépôt est un contrôle automatisé distinct ; ne pas ouvrir un autre navigateur interactif pour contourner une panne du navigateur natif.
```shnode scripts/devis-pilot.mjs reset-quotabunx playwright test --config=playwright.devis.config.ts --output=.evidence/devis-skill/e2enode scripts/devis-pilot.mjs reset-quotanode scripts/verify-devis-api.mjsnode scripts/devis-pilot.mjs persistencenode scripts/devis-pilot.mjs jobsnode scripts/verify-devis-migrations.mjs```
Le scénario migrations crée une base temporaire dans le conteneur pilote nommé `pstack-devis-postgres-20261007`, puis la supprime. Il rejoue uniquement baseline → module initial → hardening, down puis up ; il ne parcourt pas toutes les migrations récentes. Le succès de cette commande ne prouve donc pas la réversibilité du schéma courant. `migrate` applique, lui, la liste enregistrée dans le checkout au pilote.
Écart constaté dans le checkout de référence le 2026-10-17 : la seed `apps/cms/src/scripts/devisPilot.ts` fournit un seul lead DOCX, mais `scripts/verify-devis-api.mjs` exige encore `%PDF-` pour le document téléchargé. La fiche `features/documents.md` évoque aussi deux PDF de seed. Sur une seed fraîche, le scénario complet rencontre cette assertion obsolète ; vérifier l’état des scripts avant de conclure à une régression produit. Ne pas convertir le document métier en PDF pour satisfaire le test. Corriger le vérificateur dans une tâche applicative autorisée, puis rejouer ; les anciens résultats verts ne suffisent pas.
Les scripts HTTP et de persistance sont gardés pour ce pilote et utilisent des données synthétiques ; conserver également le contrôle du dossier privé décrit plus haut. Avant chaque nouvelle recette HTTP ou navigateur, reset-quota retire seulement les compteurs rate: de ce pilote strictement isolé. Les dossiers, refus anonymes et preuves sont conservés. Cela rend les reprises possibles sans contourner les quotas de l’application. Le scénario Calendly remplace la réponse du fournisseur à sa frontière HTTP pour prouver le chargement tardif et le préremplissage sans réservation. Il ne prouve pas le rendu réel du fournisseur. `bun run test:e2e` est un autre harnais : son `playwright.config.ts` exclut le devis, réutilise un serveur public sur 4321 et ne garantit pas encore une isolation PostgreSQL/SMTP. Ne pas le substituer à cette recette. Les sélecteurs et parcours sont dans les fichiers de la carte. Pour un changement ciblé, choisir le scénario correspondant et compléter les effets associés.
## Evidence
Conserver les commandes, codes de sortie, captures et traces sous `.evidence/`. Capturer l'action et son résultat, puis vérifier les effets dans une seconde lecture : dossier unique, historique, fichiers réels et destinataires/corps des emails. Un 404 sur un nom inventé ou un compteur de sujets ne prouve pas ces effets. Les tests UI simulés ne remplacent pas l'API et la base réelles.
`.evidence/` reste privé et ignoré : les traces réseau peuvent contenir des capacités ou des cookies. Publier uniquement des résumés sans secrets dans `docs/module-devis/verification.md`. Consigner les obligations dans `requirements.md` et les intégrations différées selon `readiness.md`. `baseline.md` contient des échecs datés ; les recontrôler avant de les qualifier de préexistants sur le checkout courant. Rapporter le commit et les modifications locales, les scénarios réellement exécutés, leurs résultats et les limites ; ne pas recopier un ancien verdict vert.
## Cleanup
Arrêter par Ctrl-C les deux sessions démarrées par ce passage. Si une session est perdue, retrouver son PID et son checkout avant de l'arrêter. Si Astro a été lancé sans la variable ci-dessus et signale un PID détaché, conserver ce PID, vérifier son checkout avec Doctor, puis utiliser `bun run --cwd apps/web astro dev stop` depuis ce checkout. Ne jamais tuer par nom de processus. Puis :
```shnode scripts/verify-devis-pilot.mjs cleanup```
Le helper retire seulement les conteneurs qu'il a créés, vérifiés par ID et label, et son `.env` si son contenu n'a pas changé. Un environnement existant réutilisé est conservé. Les preuves restent sous `.evidence/` ; vérifier leur présence après nettoyage. Ne pas exécuter ce nettoyage pendant qu'un autre agent utilise les ressources.
## Helpers
`node scripts/verify-devis-pilot.mjs prepare|doctor|cleanup` couvre préparation locale, contrôle en lecture et nettoyage ciblé. Le lanceur canonique du dépôt garde les commandes de migration, seed, CMS, web et persistance. Pour maintenir cette carte après évolution du module, utiliser `pstack:maintain-verification-skill`.
## Serveurs compilés
La variante suivante utilise les commandes compilées du lanceur ; ses anciens résultats sont documentés dans `verification.md` et doivent être rejoués pour prouver le checkout courant. Arrêter d'abord les sessions dev de cette recette ; ces serveurs utilisent les mêmes ports.
```shbunx cross-env PAYLOAD_ENABLE_PUSH=false DATABASE_URL=postgresql://invalid:invalid@127.0.0.1:1/invalid PAYLOAD_SECRET=local-build-only CACHE_SECRET=local-build-only bun run --cwd apps/cms buildbun run --cwd apps/web build```
Démarrer dans deux sessions contrôlables :
```shnode scripts/devis-pilot.mjs cms-builtnode scripts/devis-pilot.mjs web-built```
Puis vérifier l'instance et son upload maximal :
```shnode scripts/verify-devis-pilot.mjs doctornode scripts/devis-pilot.mjs reset-quotaDEVIS_VERIFY_MAX_UPLOAD=1 node scripts/verify-devis-api.mjs```
Cette variante produit un PDF 10 MiB avec xref valide, vérifie son stockage privé et ses octets relus, puis les mêmes contrôles HTTP et vrais emails SMTP. Elle ne prouve ni les images Docker ni les cookies dans un navigateur HTTPS. Les bornes 413 observées sont celles des routes ; la limite globale de l'adaptateur n'est pas isolée des lecteurs plus stricts. Arrêter les deux sessions puis appliquer Cleanup.
## Contrôles de source et schéma
Avant une PR, `AGENTS.md` demande `bun run check`. Cette commande comprend format, `check:generated`, lint, les quatre projets TypeScript (CMS, outillage racine, contrats et web), tests d’intégration, builds CMS/web et audit du bundle. Le build CMS utilise DB/secrets factices ; cela ne remplace aucun parcours runtime de cette recette.
`bun run check:generated` vérifie types et snapshot de migration dans une copie temporaire sans PostgreSQL et sans modifier le checkout. Il ne lit pas le schéma du pilote et ne valide pas la liste entière des migrations up/down. Suivre sa correction indiquée (`bun run generate:types` ou `bun run migrate:create <nom>`) en cas de dérive. À l’inverse, les générations explicites, `next typegen`, `astro sync` et les builds écrivent leurs sorties locales.CELUGA_SKILL_EOFmkdir -p "$HOME/.claude/skills" "$HOME/.codex/skills"[ -e "$HOME/.claude/skills/verify-celuga-devis" ] || ln -s "$dir" "$HOME/.claude/skills/verify-celuga-devis"[ -e "$HOME/.codex/skills/verify-celuga-devis" ] || ln -s "$dir" "$HOME/.codex/skills/verify-celuga-devis"SKILL.md
Section intitulée « SKILL.md »---name: verify-celuga-devisdescription: Vérifier le module devis Celuga sur PostgreSQL et SMTP jetables, avec parcours web, back-office, fichiers privés et preuves de persistance. Utiliser après un changement du module ou pour sa recette.---
# Vérifier Celuga devis
Exécuter depuis la racine du checkout à vérifier. Lire la carte `docs/module-devis/features/README.md` de ce checkout. Le pilote utilise les ports 15433, 11025, 18025, 3430 et 4432. Il ne peut pas fonctionner en parallèle avec un autre pilote utilisant ces ports. Le helper refuse la configuration de ce checkout si elle vise une autre base ou un autre SMTP. Lire les scripts du checkout avant de lancer une recette : le skill décrit leur contrat courant, les résultats historiques de `docs/module-devis/verification.md` ne valent pas résultat de cette exécution.
## Launch
```shbun install --frozen-lockfilenode scripts/verify-devis-pilot.mjs preparenode scripts/devis-pilot.mjs migratenode scripts/devis-pilot.mjs seed```
Le helper crée PostgreSQL 18.4 et Mailpit 1.29.0 avec des secrets locaux aléatoires si `.env` est absent. Mailpit exige STARTTLS et accepte l’authentification ; son certificat jetable est approuvé par les processus du lanceur via `NODE_EXTRA_CA_CERTS`. Le SMTP passe par les vrais `EMAIL_HOST`, `EMAIL_USER`, `EMAIL_PASS`, `EMAIL_PORT` du getter `getEmailConfig()` ; ne pas remplacer cela par un relais sans auth. Si `.env` existe, le helper valide ses cibles isolées et le conserve ; il ne crée alors ni conteneurs ni certificat et ne prouve pas seul que le transport fonctionne. Les collisions Docker ou de ports doivent être résolues en identifiant leur propriétaire, sans arrêter un autre environnement.
Démarrer dans deux sessions terminal contrôlables, garder leurs identifiants. La variable Astro empêche son détachement automatique sous un agent :
```shnode scripts/devis-pilot.mjs cmsASTRO_DEV_BACKGROUND=1 node scripts/devis-pilot.mjs web```
Le CMS est sur `http://localhost:3430`, le parcours sur `http://localhost:4432/devis`. La seed crée des documents explicitement identifiés comme fixtures et un administrateur synthétique dans `.devis-pilot-admin.json`, ignoré. Ne pas afficher ce fichier. Ne réserver aucun vrai créneau Calendly. Le lien par défaut du code courant est `https://calendly.com/ctachet/rencontre-celuga` ; une base existante peut conserver une ancienne URL de démonstration. Lire les réglages effectifs ; ni une ancienne preuve Oghma ni le lien par défaut ne prouvent la disponibilité du compte Celuga.
`apps/cms/src/env.ts` charge lui-même le `.env` racine et possède `getDevisPrivateDir()`. Avec le lanceur exécuté dans `apps/cms`, le chemin privé par défaut est `apps/cms/private/devis` ; un `DEVIS_PRIVATE_DIR` explicite le remplace. Le helper ne valide pas ce chemin : pour une configuration existante, vérifier qu’il appartient au pilote et ne pointe pas vers des fichiers partagés. Ce dossier n’est jamais servi comme média public. Les scripts conservent leurs propres lecteurs de configuration ; ne pas prétendre que toutes les variables sont centralisées.
## Doctor
```shnode scripts/verify-devis-pilot.mjs doctor```
Ce contrôle lit la configuration isolée, vérifie via `lsof` que les ports CMS/web appartiennent à ce checkout, puis lit les réglages publics, la page sans cache et Mailpit. Il écrit `.evidence/devis-skill/doctor.json`. Un échec interdit de conduire une instance inconnue. Ce helper requiert macOS ou un environnement avec `lsof`.
## Drive
Pour le web interactif, utiliser le navigateur collaboratif disponible dans l’hôte et son API documentée : identifier l’onglet puis lire son état avant d’agir. Une commande qui expire reste inconclusive. Le scénario Playwright du dépôt est un contrôle automatisé distinct ; ne pas ouvrir un autre navigateur interactif pour contourner une panne du navigateur natif.
```shnode scripts/devis-pilot.mjs reset-quotabunx playwright test --config=playwright.devis.config.ts --output=.evidence/devis-skill/e2enode scripts/devis-pilot.mjs reset-quotanode scripts/verify-devis-api.mjsnode scripts/devis-pilot.mjs persistencenode scripts/devis-pilot.mjs jobsnode scripts/verify-devis-migrations.mjs```
Le scénario migrations crée une base temporaire dans le conteneur pilote nommé `pstack-devis-postgres-20261007`, puis la supprime. Il rejoue uniquement baseline → module initial → hardening, down puis up ; il ne parcourt pas toutes les migrations récentes. Le succès de cette commande ne prouve donc pas la réversibilité du schéma courant. `migrate` applique, lui, la liste enregistrée dans le checkout au pilote.
Écart constaté dans le checkout de référence le 2026-10-17 : la seed `apps/cms/src/scripts/devisPilot.ts` fournit un seul lead DOCX, mais `scripts/verify-devis-api.mjs` exige encore `%PDF-` pour le document téléchargé. La fiche `features/documents.md` évoque aussi deux PDF de seed. Sur une seed fraîche, le scénario complet rencontre cette assertion obsolète ; vérifier l’état des scripts avant de conclure à une régression produit. Ne pas convertir le document métier en PDF pour satisfaire le test. Corriger le vérificateur dans une tâche applicative autorisée, puis rejouer ; les anciens résultats verts ne suffisent pas.
Les scripts HTTP et de persistance sont gardés pour ce pilote et utilisent des données synthétiques ; conserver également le contrôle du dossier privé décrit plus haut. Avant chaque nouvelle recette HTTP ou navigateur, reset-quota retire seulement les compteurs rate: de ce pilote strictement isolé. Les dossiers, refus anonymes et preuves sont conservés. Cela rend les reprises possibles sans contourner les quotas de l’application. Le scénario Calendly remplace la réponse du fournisseur à sa frontière HTTP pour prouver le chargement tardif et le préremplissage sans réservation. Il ne prouve pas le rendu réel du fournisseur. `bun run test:e2e` est un autre harnais : son `playwright.config.ts` exclut le devis, réutilise un serveur public sur 4321 et ne garantit pas encore une isolation PostgreSQL/SMTP. Ne pas le substituer à cette recette. Les sélecteurs et parcours sont dans les fichiers de la carte. Pour un changement ciblé, choisir le scénario correspondant et compléter les effets associés.
## Evidence
Conserver les commandes, codes de sortie, captures et traces sous `.evidence/`. Capturer l'action et son résultat, puis vérifier les effets dans une seconde lecture : dossier unique, historique, fichiers réels et destinataires/corps des emails. Un 404 sur un nom inventé ou un compteur de sujets ne prouve pas ces effets. Les tests UI simulés ne remplacent pas l'API et la base réelles.
`.evidence/` reste privé et ignoré : les traces réseau peuvent contenir des capacités ou des cookies. Publier uniquement des résumés sans secrets dans `docs/module-devis/verification.md`. Consigner les obligations dans `requirements.md` et les intégrations différées selon `readiness.md`. `baseline.md` contient des échecs datés ; les recontrôler avant de les qualifier de préexistants sur le checkout courant. Rapporter le commit et les modifications locales, les scénarios réellement exécutés, leurs résultats et les limites ; ne pas recopier un ancien verdict vert.
## Cleanup
Arrêter par Ctrl-C les deux sessions démarrées par ce passage. Si une session est perdue, retrouver son PID et son checkout avant de l'arrêter. Si Astro a été lancé sans la variable ci-dessus et signale un PID détaché, conserver ce PID, vérifier son checkout avec Doctor, puis utiliser `bun run --cwd apps/web astro dev stop` depuis ce checkout. Ne jamais tuer par nom de processus. Puis :
```shnode scripts/verify-devis-pilot.mjs cleanup```
Le helper retire seulement les conteneurs qu'il a créés, vérifiés par ID et label, et son `.env` si son contenu n'a pas changé. Un environnement existant réutilisé est conservé. Les preuves restent sous `.evidence/` ; vérifier leur présence après nettoyage. Ne pas exécuter ce nettoyage pendant qu'un autre agent utilise les ressources.
## Helpers
`node scripts/verify-devis-pilot.mjs prepare|doctor|cleanup` couvre préparation locale, contrôle en lecture et nettoyage ciblé. Le lanceur canonique du dépôt garde les commandes de migration, seed, CMS, web et persistance. Pour maintenir cette carte après évolution du module, utiliser `pstack:maintain-verification-skill`.
## Serveurs compilés
La variante suivante utilise les commandes compilées du lanceur ; ses anciens résultats sont documentés dans `verification.md` et doivent être rejoués pour prouver le checkout courant. Arrêter d'abord les sessions dev de cette recette ; ces serveurs utilisent les mêmes ports.
```shbunx cross-env PAYLOAD_ENABLE_PUSH=false DATABASE_URL=postgresql://invalid:invalid@127.0.0.1:1/invalid PAYLOAD_SECRET=local-build-only CACHE_SECRET=local-build-only bun run --cwd apps/cms buildbun run --cwd apps/web build```
Démarrer dans deux sessions contrôlables :
```shnode scripts/devis-pilot.mjs cms-builtnode scripts/devis-pilot.mjs web-built```
Puis vérifier l'instance et son upload maximal :
```shnode scripts/verify-devis-pilot.mjs doctornode scripts/devis-pilot.mjs reset-quotaDEVIS_VERIFY_MAX_UPLOAD=1 node scripts/verify-devis-api.mjs```
Cette variante produit un PDF 10 MiB avec xref valide, vérifie son stockage privé et ses octets relus, puis les mêmes contrôles HTTP et vrais emails SMTP. Elle ne prouve ni les images Docker ni les cookies dans un navigateur HTTPS. Les bornes 413 observées sont celles des routes ; la limite globale de l'adaptateur n'est pas isolée des lecteurs plus stricts. Arrêter les deux sessions puis appliquer Cleanup.
## Contrôles de source et schéma
Avant une PR, `AGENTS.md` demande `bun run check`. Cette commande comprend format, `check:generated`, lint, les quatre projets TypeScript (CMS, outillage racine, contrats et web), tests d’intégration, builds CMS/web et audit du bundle. Le build CMS utilise DB/secrets factices ; cela ne remplace aucun parcours runtime de cette recette.
`bun run check:generated` vérifie types et snapshot de migration dans une copie temporaire sans PostgreSQL et sans modifier le checkout. Il ne lit pas le schéma du pilote et ne valide pas la liste entière des migrations up/down. Suivre sa correction indiquée (`bun run generate:types` ou `bun run migrate:create <nom>`) en cas de dérive. À l’inverse, les générations explicites, `next typegen`, `astro sync` et les builds écrivent leurs sorties locales.