BDD-120 — Exécution complète du workflow (staging PostgreSQL)

Livraison regroupée : BDD-120 (Source dépôt) + BDD-121 (Mapper / Nettoyer / Destination) + BDD-122 (Croiser SQL).

User story

En tant qu'administrateur, lorsque je lance un workflow alimenté par un fichier du dépôt, je veux que toutes les lignes du fichier soient traitées et stockées dans des tables PostgreSQL de staging pour ce run, afin d'exécuter le pipeline sur des données réelles sans passer par le module Sources Heriade ni par un aperçu limité.

Critères d'acceptance

Critère	Statut
Le lancement manuel n'utilise plus getPreview (~20 lignes) pour le bloc Source	✅
L'entrée reste le fichier dépôt (input_document_id) ; création d'une Source Heriade non obligatoire	✅
Toutes les lignes du fichier sont chargées (S3 complet puis matérialisation en tables de staging par runUuid / nœud)	✅
Les tables de staging sont isolées entre exécutions et nettoyées selon la politique documentée	✅
Réutilisation du moteur de parse / import existant (FileParserService, SchemaTableService)	✅
Réutilisation optionnelle d'une table Heriade déjà existante pour le même document	❌ Hors périmètre — source = fichier dépôt (S3) uniquement
Limite WORKFLOW_RUN_MAX_ROWS : refus du run au-delà du seuil avec message explicite	✅
L'aperçu éditeur (panneau Source) reste sur échantillon, clairement distinct de l'exécution complète	✅

BDD-121 — Mapper, Nettoyer, Destination (données complètes)

Critère	Statut
Mapper / Nettoyer sur toutes les lignes amont	✅ (moteurs existants + staging)
Destination : export CSV/Excel sur toutes les lignes (S3 + URL signée)	✅
lastResult avec rowCount / columnCount réels + artifactRef	✅
Publication Heriade sur toutes les lignes	⏳ Avertissement (hors MVP — BDD-97)
Aperçu éditeur inchangé (échantillon)	✅

BDD-122 — Croiser SQL sur staging

Critère	Statut
Jointure INNER / LEFT en SQL sur tables staging complètes	✅
joinKeys[] (AND) + rétrocompat joinKey	✅
Colonnes droite non-clés suffixées __droite	✅
rows_in / rows_out via COUNT SQL (pas de chargement join en mémoire)	✅
Aperçu éditeur : simulation JS sur échantillon	✅ (inchangé)

Technique

Périmètre code

• Uniquement back/src/api/workflows/ (sous-dossier staging/) + workflows.module.ts + exceptions workflow + SQL tool_16.
• Aucune modification des modules sources, connections, documents.
• Pas de réutilisation d'une table Heriade existante : chaque run charge le fichier depuis le dépôt (S3), même si une source Heriade a déjà été créée pour ce document.

Staging PostgreSQL

• Schéma : staging_run_{runUuidSansTirets}
• Table par nœud matérialisé : node_{nodeUuidSansTirets}
• Nettoyage : DROP SCHEMA IF EXISTS ... CASCADE en finally après chaque POST /workflows/:uuid/run
• Script : sql/tool_16_workflow_run_staging.sql (convention, pas de table Prisma dédiée)

Variables d'environnement

Variable	Défaut (code)	Rôle
WORKFLOW_RUN_MAX_ROWS	100000 si non définie	Plafond lignes après parse S3 complet (optionnelle, pas dans .env.example)

Services

Service	Rôle
WorkflowDepotInputService	Résolution document dépôt (Prisma) + S3 + parse complet
WorkflowRunStagingService	DDL staging, lecture lignes, drop schema
WorkflowRunStagingExecutionService	Orchestration run (remplace l'implémentation enregistrée sous WorkflowRunService)

Doc API

• workflows.md