Claude
22a6c59488
Portage de tout ce qui, dans la Grille, ne dépend ni de la base FF ni de Qlik : - types.rs : ProductRow et types associés, JSON identique à JSON.stringify (camelCase, champs facultatifs omis, entiers sans décimale, NaN → null) et relecture sans perte des payloads grid_rows écrits par la version Node ; - store.rs : grid_rows (upsert par lots de 200 + purge, instantané, report des gammes, requêtes filtrées/triées/paginées via QueryBuilder et liste blanche de tri, fiche, fournisseurs, fraîcheur, nomenclatures) ; - rows_cache.rs : cache mémoire 10 min des lignes calculées (clé, LRU, patchGridRowsCache, invalidation, calculs en cours, compléments par magasin) ; - network_trend.rs, months.rs, store_patch.rs : logique pure testée ; - gammes_a_valider.rs, enregistrer.rs, snapshots.rs : actions getSnapshots, deleteSnapshot, saveSnapshot, saveDraftChanges, getGammesAValider, rejeterGammesAValider (validation zod reproduite, mêmes messages) ; - exports.rs : /api/export/excel et /api/export/modified-gammes (rust_xlsxwriter, mêmes feuilles, styles, largeurs et formats) ; - api_schemas.rs, zod.rs : schémas /api/v1, issues zod 4 à l'identique ; - api_v1.rs, openapi.rs : /api/v1/nomenclatures et /api/v1/openapi.json (document identique octet pour octet à celui de la version Node). Écart volontaire : listGridNomenclatures groupe par position (GROUP BY 1) ; la requête drizzle répétait left(code3, $n) avec un autre paramètre et échouait systématiquement sous PostgreSQL. Test d'intégration (grid_rows, snapshots, gammes à valider) activé par GRID_TEST_DATABASE_URL. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LG2LLJuswrrTTPKJmunEVf
CollectFlow
CollectFlow est une application de révision d'assortiment et d'analyse de performances des produits en point de vente, conçue pour consolider les données issues de plusieurs fournisseurs et magasins.
Prérequis
- Node.js 18+ (pour le développement local)
- Docker et Docker Compose (pour le déploiement conteneurisé)
- PostgreSQL 16+
Lancer avec Docker
Le projet est configuré pour tourner dans un conteneur Docker optimisé (mode standalone de Next.js). Note : Vous devez disposer d'une base de données PostgreSQL séparée (le conteneur ne lance que l'application web).
1. Démarrer l'application
À la racine du projet, lancez :
npm run docker:build
# ou directement
docker-compose up -d --build
L'application sera accessible sur http://localhost:5643.
L'application sera attachée au réseau Docker externe nginx_default afin d'être exposée derrière votre reverse proxy Nginx. Assurez-vous que ce réseau existe (docker network create nginx_default).
2. Arrêter l'application
npm run docker:down
# ou directement
docker-compose down
Développement Local (Sans Docker)
Si vous préférez développer en local, vous devrez configurer votre propre base de données PostgreSQL.
- Installer les dépendances :
npm install
-
Configurer la connexion DB : Allez sur la page des Paramètres (
/settings) dans l'application pour configurer l'accès à votre PostgreSQL local. -
Lancer le serveur de développement :
npm run dev
Structure du Projet (BMAD)
Ce projet respecte l'architecture BMAD (Business, Model, Application/API, Data) :
src/features/*: Logique métier (Business) isolée par feature (ex:grid,snapshots)src/types/*: Interfaces TypeScript (Model)src/app/*: Routeurs Next.js UI et endpoints d'API (Application/API)src/db/*: Schémas Drizzle ORM et connexions (Data)