lint(limagrain): corrections completes Phase 1+2

- Bloquants: mermaid 03-picking/_index reconstitue (archive 11-05), 13 liens vers pages squelette retires, 2 liens recibles (anoxie, application-dictionary)
- Conventions: 910 em dashes -> tirets simples, 145 checklists -> puces question, 13 questions resolues barrees
- Liens: 9 ancres reparees (slugs GitHub)
- Delta: 12 standard_ref remappes, blocs Standard EasyWMS + sections References ajoutes, front matter complete
- Glossaire: 15 termes standard deplaces en section rappel avec renvoi
- Rapport: limagrain/_lint_report.md (Phase 1 + Phase 2 + re-scan final)
- Inclut les pages des sessions precedentes non commitees + CLAUDE.md et consume.log en l'etat

wiki/limagrain/02-stockage/_index.md

@@ -1,11 +1,11 @@
 ---
-title: "Stockage — Vue d'ensemble"
+title: "Stockage - Vue d'ensemble"
 tags: [stockage, asrs, galileo, index]
 status: draft
 last_updated: 2026-05-05
 ---
 
-# Stockage — Vue d'ensemble
+# Stockage - Vue d'ensemble
 
 > **Périmètre** : miniload, transstockeurs, stations Galileo, stratégies de
 > putaway, zones de stockage, défragmentation.
@@ -22,6 +22,7 @@ last_updated: 2026-05-05
 - [Défragmentation](defragmentation.md)
 - [Processus d'anoxie](processus-anoxie.md)
 - [Gestion des palettes vides](palettes-vides.md)
+- [Flux de rejet PIE](rejet-pie.md)
 
 ## Vue synthétique du stockage Limagrain
 

wiki/limagrain/02-stockage/asrs-miniload.md

@@ -1,5 +1,5 @@
 ---
-title: "ASRS — Entrepôt automatique Limagrain"
+title: "ASRS - Entrepôt automatique Limagrain"
 tags: [stockage, ASRS, transstockeur, racks, emplacements]
 status: draft
 standard_ref: architecture/galileo-integration.md
@@ -10,7 +10,7 @@ last_updated: 2026-05-05
 author: Arthur
 ---
 
-# ASRS — Entrepôt automatique Limagrain
+# ASRS - Entrepôt automatique Limagrain
 
 > **Résumé** : description de l'installation automatique Limagrain : 4 allées
 > de transstockeurs, racks multi-profondeur, nomenclature des emplacements,
@@ -31,7 +31,7 @@ graines (sacs, big-bags) sur palettes US.
 | Code | Description |
 |------|-------------|
 | **LM** | Organisation LIMAGRAIN |
-| **MAG01** | Magasin automatique — 4 allées |
+| **MAG01** | Magasin automatique - 4 allées |
 
 ## Racks et capacités
 
@@ -48,8 +48,8 @@ Format : **AAAXXXYYYS(D)**
 | Code | Nb caractères | Description |
 |------|---------------|-------------|
 | AAA | 3 | Nom de l'allée (001–004) |
-| XXX | 3 | Coordonnée X — travée le long de l'allée |
-| YYY | 3 | Coordonnée Y — hauteur dans la travée |
+| XXX | 3 | Coordonnée X - travée le long de l'allée |
+| YYY | 3 | Coordonnée Y - hauteur dans la travée |
 | S | 1 | Côté de l'allée (1 = gauche, 2 = droite) |
 | D | 1 | Profondeur (1 = premier, 2 = second, ...) |
 
@@ -63,7 +63,7 @@ profondeur 1.
 
 | Type | Largeur (mm) | Longueur (mm) | Hauteur (mm) | Poids max (kg) |
 |------|--------------|---------------|--------------|----------------|
-| 1 — Palette US | 1000 | 1200 | 800 à 1900 | 1250 |
+| 1 - Palette US | 1000 | 1200 | 800 à 1900 | 1250 |
 
 ## Contrôles au PIE
 

wiki/limagrain/02-stockage/defragmentation.md

@@ -1,16 +1,16 @@
 ---
-title: "Défragmentation — Zone client et ordonnancement par tournée"
+title: "Défragmentation - Zone client et ordonnancement par tournée"
 tags: [stockage, défragmentation, expédition, zone-client, planning, tournée, STOP, custom]
 status: draft
 standard_ref: concepts/defragmentation.md
 jira_refs: [LIM-85, LIM-87]
 confluence_refs: []
 sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "LIM-85 LOT2.1 Configuration stratégies defragmentation du stock client par tournée.md", "LIM-87 LOT2.1 [TOURNÉES] Défragmentation client - quai non assigné ATTENTE_CLIENT CT-13.md"]
-last_updated: 2026-05-12
+last_updated: 2026-07-17
 author: Arthur
 ---
 
-# Défragmentation — Zone client et ordonnancement par tournée
+# Défragmentation - Zone client et ordonnancement par tournée
 
 > **Résumé** : processus de défragmentation pour préparer les palettes
 > d'expédition vers la zone de défragmentation client dans l'ASRS.
@@ -37,7 +37,7 @@ répond au besoin Limagrain** :
 |---------------|-------------|----------|
 | Shipping Only | Défrag uniquement les palettes complètes | Les palettes de picking ne sont pas repositionnées → ordonnancement STOP faux dans le canal |
 | Picking & Shipping | Défrag toutes les palettes (y compris celles à picker) | Les palettes sortent pour être défragmentées alors qu'elles doivent d'abord passer au PK → casse l'ordonnancement |
-| Picking Only | Non applicable au besoin | — |
+| Picking Only | Non applicable au besoin | - |
 
 **Contrainte métier** : le stock doit être rangé dans le canal
 d'expédition ASRS dans l'**ordre inverse des STOP** de la tournée, de
@@ -62,7 +62,7 @@ de l'expédition.
 
 - **Priorité** : basse (s'exécute en arrière-plan)
 - **Planification** : horaires configurables par Limagrain
-- **Zone cible** : zone défragmentation client (TK02, 03, 04 —
+- **Zone cible** : zone défragmentation client (TK02, 03, 04 -
   rangées 60-69, profondeurs 2-10)
 - **Déclencheur** : stratégie de défragmentation par rotation (standard)
   + custom défrag client par tournée (ci-dessous)
@@ -88,7 +88,29 @@ La défragmentation est l'étape 4 du flux d'expédition (voir
 3. Palettes picking → poste de travail d'abord, puis zone client
 4. Depuis zone client → sortie vers poumon le jour J
 
-## [CUSTOM] Défrag client par tournée — Quai non assigné (LIM-87)
+## [CONFIG] Stratégies de défragmentation client par tournée (LIM-85)
+
+> **Statut (LIM-85)** : **en cours de test client (pré-production)**.
+> Stratégies importées sur Git le 23/04/2026 (suite à l'atelier du 2 avril).
+> Ticket de suivi - peu de contenu technique, il sert à tracer la
+> configuration.
+
+Ce ticket couvre la **configuration des stratégies de défragmentation** du
+stock client par tournée : définition des stratégies (mode Shipping, type
+d'ordre Tournée) et de la zone cible ASRS (zone client TK02-04, rangées
+60-69). Ces stratégies sont le socle sur lequel s'appuie le custom
+d'éligibilité par tournée ci-dessous (LIM-87).
+
+La logique custom (filtre « toutes les palettes du RUT prêtes »,
+ordonnancement inverse des STOP, quai non assigné) relève de
+[LIM-87](https://easywmsfrance.atlassian.net/browse/LIM-87).
+
+## [CUSTOM] Défrag client par tournée - Quai non assigné (LIM-87)
+
+> **Statut (LIM-87)** : **en cours de test client (pré-production)**. Revue
+> de code validée le **28/04/2026** (après un NOK le 24/04 : bug de nommage
+> de paramètre `c` réutilisé entre le `Any` et le `Where` de la query,
+> corrigé le 27/04).
 
 ### Objectif
 
@@ -114,6 +136,14 @@ de la tournée** (RUT), pas de l'OS individuel.
   qui exclut de l'éligibilité toute tournée dont au moins une palette
   (d'au moins un OS) n'est pas encore prête dans l'ASRS
 
+La sélection des candidats passe par la query standard
+`OutboundDefragContainers_PendingByWarehouseExcludedIds`, **modifiée en
+custom** : elle ne retient un conteneur que si sa tournée (ou son OS) n'a
+**plus de picking en cours**. Elle exclut donc les conteneurs de picking
+restants **et** les conteneurs pas encore rangés dans l'ASRS (encore en
+mouvement, `LocationType != Aps`). S'il en existe au moins un, aucun
+conteneur de cet ordre n'est retenu pour la défrag.
+
 ### Règle d'éligibilité (pseudocode)
 
 ```
@@ -140,7 +170,8 @@ du **STOP 1** en dernier. Ainsi les palettes sortent dans le bon ordre
 lors du chargement camion (STOP 1 chargé en premier).
 
 Le rangement se fait dans un canal (ou plusieurs canaux) par tournée
-— pas un canal par STOP.
+
+- pas un canal par STOP.
 
 ### Paramètre MAX_DEFRAG_ATTEMPT
 
@@ -154,6 +185,10 @@ un emplacement de destination et n'en a pas trouvé. Si le filtre
 custom exclut la tournée avant même de chercher une destination,
 aucune tentative n'est décomptée.
 
+> **Résolu (LIM-87, 23/04/2026)** : `MAX_DEFRAG_ATTEMPT` ne concerne que la
+> défrag **par rotation**, **pas** la défrag d'expédition/client. Le custom
+> de défrag client par tournée n'est donc **pas** plafonné par ce compteur.
+
 ## Cas de tests (LIM-87)
 
 Légende : PC = palette complète, PP = palette de picking (mère),
@@ -175,7 +210,7 @@ PF = palette fille (sortie du picking, retour ASRS).
 |----|-------------|---------------|------------------|
 | 06 | PP partie, PF pas encore revenue | 2 SOR, SOR1 prêt, SOR2 avec PF pas revenue | **NON éligible** (un OS bloque tout le RUT) |
 | 07 | PF encore sur AGV (en mouvement) | Multi-OS, 1 PF en transit AGV | **NON éligible** tant que PF pas dans ASRS |
-| 08 | Quai déjà assigné à la tournée | Toutes palettes prêtes, quai assigné | **NON éligible** pour custom défrag — flux standard prend le relais |
+| 08 | Quai déjà assigné à la tournée | Toutes palettes prêtes, quai assigné | **NON éligible** pour custom défrag - flux standard prend le relais |
 | 09 | Picking partiel sur un OS | 1 SOR, 3 lignes picking, 2 PF revenues, 1 PP au PK | **NON éligible** (on attend la totalité) |
 
 ### Cas dégradés
@@ -184,7 +219,7 @@ PF = palette fille (sortie du picking, retour ASRS).
 |----|-------------|---------------|------------------|
 | 11 | AGV HS pendant retour PF | PF bloquée sur PK/buffer | **NON éligible** jusqu'à rangement ASRS |
 | 12 | Support sous révision | PP → buffer litige, stock réassigné sur PP' | Éligible quand toutes les palettes (réassignations incluses) dans ASRS |
-| 13 | Rupture de stock (ATTENTE CLIENT) | SOR1 prêt, SOR2 avec 1 ligne en rupture | **À trancher** : option A (RUT bloqué) ou option B (défrag partielle) |
+| 13 | Rupture de stock (ATTENTE CLIENT) | SOR1 prêt, SOR2 avec 1 ligne en rupture | Implémentation : commande incomplète → **pas de défrag** (proche option A). Arbitrage client à confirmer (option A vs B) |
 | 14 | Modification quantité (bouton Problème) | OnStockAdjust recalcule | Si stock suffisant → PF revient, RUT éligible. Si réassignation → attendre PP'/PF' |
 | 15 | RUT libéré, aucune PP partie (figé) | Pas de PK disponible | **NON éligible** (picking pas déclenché ≠ prêt). Pas de MAX_DEFRAG_ATTEMPT |
 | 16 | Ajout SOR à un RUT déjà éligible | Nouveau SOR avec lignes picking non traitées | **Redevient NON éligible** jusqu'à fin du nouveau SOR |
@@ -196,7 +231,7 @@ exemple si l'activité reprend la nuit).
 
 ## Points d'attention
 
-⚠️ Les tâches de défragmentation ont une priorité **basse** — elles ne
+⚠️ Les tâches de défragmentation ont une priorité **basse** - elles ne
 perturbent pas l'activité normale mais peuvent être longues.
 
 ⚠️ MECALUX conseille une présence sur site lors de la défragmentation
@@ -209,10 +244,13 @@ non prêt bloque toute la défrag du RUT.
 
 ## Questions ouvertes
 
-- [ ] Rupture de stock CT-13 : option A (RUT bloqué tant que rupture
+- ❓ Rupture de stock CT-13 : option A (RUT bloqué tant que rupture
   non résolue) ou option B (défrag sur les palettes dispo) ? (@Justine)
-- [ ] MAX_DEFRAG_ATTEMPT : scope défrag client seul ou aussi défrag par
-  rotation ? Impact sur la valeur à configurer (@Nicolas)
+  Implémentation actuelle : commande incomplète → pas de défrag (proche
+  option A), à confirmer client
+- [x] ~~MAX_DEFRAG_ATTEMPT : scope défrag client seul ou aussi défrag par
+  rotation ?~~ → Résolu (LIM-87) : uniquement la défrag par rotation, pas
+  la défrag d'expédition
 
 ## Historique des modifications
 
@@ -221,11 +259,13 @@ non prêt bloque toute la défrag du RUT.
 | 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
 | 2026-05-12 | Arthur | Refonte : ajout custom défrag client par tournée (LIM-87), mécanisme filtre éligibilité, ordonnancement STOP, 16 cas de tests |
 | 2026-05-13 | Arthur | Restauration contenu tronqué (caractéristiques, config, custom, cas de tests, points d'attention) |
+| 2026-07-17 | Arthur | Relecture LIM-85 (lecture directe, 1 commentaire) : ajout section « [CONFIG] Stratégies de défragmentation (LIM-85) » distinguant la config des stratégies (LIM-85, préprod, import Git 23/04) du custom d'éligibilité par tournée (LIM-87) ; statut + Références |
+| 2026-07-17 | Arthur | Relecture revue de code LIM-87 (préprod, validée 28/04) : ajout statut + query `OutboundDefragContainers_PendingByWarehouseExcludedIds` (filtre custom picking restant + conteneurs pas en Aps ; bug nommage paramètre corrigé 27/04) ; résolution MAX_DEFRAG_ATTEMPT (uniquement défrag rotation, pas expédition) ; CT-13 précisé (commande incomplète → pas de défrag, proche option A) |
 
 ## Références
 
 | Source | Type | Date |
 |--------|------|------|
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
-| [LIM-85](https://easywmsfrance.atlassian.net/browse/LIM-85) | Ticket Jira (stratégies défrag) | 2026 |
-| [LIM-87](https://easywmsfrance.atlassian.net/browse/LIM-87) | Ticket Jira (défrag client quai non assigné) | 2026 |
+| [LIM-85](https://easywmsfrance.atlassian.net/browse/LIM-85) | Ticket Jira (config stratégies défrag, préprod, import Git 23/04) | 2026 |
+| [LIM-87](https://easywmsfrance.atlassian.net/browse/LIM-87) | Ticket Jira (défrag client quai non assigné, 5 commentaires, préprod) | 2026-04 |

wiki/limagrain/02-stockage/galileo-config.md

@@ -1,16 +1,16 @@
 ---
-title: "Configuration Galileo — Limagrain"
-tags: [stockage, galileo, TMS, architecture, IT]
+title: "Configuration Galileo - Limagrain"
+tags: [stockage, galileo, TMS, architecture, IT, filmage, PIE]
 status: draft
 standard_ref: architecture/galileo-integration.md
-jira_refs: []
+jira_refs: [LIM-115]
 confluence_refs: []
-sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
-last_updated: 2026-05-05
+sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Jira LIM-115 (lecture directe 2026-07-20)"]
+last_updated: 2026-07-20
 author: Arthur
 ---
 
-# Configuration Galileo — Limagrain
+# Configuration Galileo - Limagrain
 
 > **Résumé** : architecture logicielle IT de l'installation Limagrain et
 > spécificités de la configuration Galileo (TMS).
@@ -61,7 +61,7 @@ graph TD
 - **ERP** : SAP EWM
 - **Direction** : bidirectionnelle (voir [Messages ERP](../06-erp-interface/messages-reference.md))
 
-## Stations PIE — Configuration spécifique
+## Stations PIE - Configuration spécifique
 
 3 stations PIE installées :
 
@@ -85,7 +85,7 @@ graph TD
 | Dimensions max | 1300 × 1100 × 1900 mm |
 | Poids max | 1250 kg |
 | État palette bois | Correct (visuel Galileo) |
-| Lecture RFID | Obligatoire — doit être connue (ASN) |
+| Lecture RFID | Obligatoire - doit être connue (ASN) |
 
 ## Flux physiques dans l'entrepôt
 
@@ -103,6 +103,58 @@ Deux entrées dans l'ASRS :
 > En cas de blocage long terme sur une entrée, un bouton permet de
 > rediriger les flux vers l'autre entrée.
 
+## Transmission du programme de filmage à la filmeuse (LIM-115)
+
+> **Statut (LIM-115)** : Ouvert. Cette tâche **transmet** le programme de
+> filmage à Galileo ; elle ne le **produit** pas (choix opérateur au poste,
+> stocké dans `CstAtt05`, voir LIM-67).
+
+**Objectif** : quand une palette quitte un poste d'identification (PIE) pour
+entrer dans l'ASRS, le WMS transmet automatiquement à Galileo le programme de
+filmage choisi par l'opérateur, sans action supplémentaire. Même principe que
+l'étiqueteuse automatique (custom data, pas de changement de route - voir
+[Flux expédition - Communication Galileo](../04-outbound/flux-expedition.md#communication-galileo-lim-111)).
+
+### Chaîne fonctionnelle
+
+L'opérateur choisit le programme au poste (action « Terminer » en réception,
+ou avant évacuation en picking) → valeur dans `CstAtt05` → tâche d'évacuation
+AGV vers la table d'entrée → passage **filmeuse** puis PIE → stockage ASRS. La
+règle « on ne filme que si le PIE valide la palette » est **structurellement**
+satisfaite : un mouvement de source PIE vers la table d'entrée (et non vers le
+poumon de rejet) n'existe que si le PIE a dit OK.
+
+### Mécanisme
+
+| Étape | Détail |
+|-------|--------|
+| Abonnement | Subscription custom sur l'event **`MovementCreated`** (modèle des `Galileo_*EventHandler_PR`), appelant un WF qui gère le CstData. Handler **léger** (event fréquent). |
+| Filtre source | Récupérer la station **source** du mouvement (StationType + StationNumber) ; la comparer au paramètre des PIE concernés. Si absente → sortie immédiate. |
+| Lecture programme | Depuis le mouvement → remonter au **support (Container)** → lire `CstAtt05`. Si vide ou = code « pas de filmage » (`0`) → forcer CstData à `0`. Si **destination = rejet** (type de tâche) → forcer CstData à `0`. |
+| Écriture CustomData | Écrire dans le **CustomData de la tâche** parente. **Idempotent** (une tâche peut générer plusieurs mouvements). Pas de collision avec l'étiqueteuse : c'est un **type de tâche différent** (une même tâche n'est jamais à la fois filmage et étiquetage). |
+| Transmission Galileo | Aucune commande spécifique : Galileo lit le CustomData à la transmission du mouvement (`GalileoMovTrackingCreateCommand`, transition Generated → In progress) et pilote la filmeuse. |
+
+Séquence : Easy crée le mouvement en `Generated` → Galileo fait une recherche
+d'ordre → Easy répond via `GalileoMovTrackingCreateCommand` (infos mouvement +
+tâche liée) → le mouvement passe en `Running`.
+
+### Périmètre
+
+- **Stations déclenchantes** : **PIE_02**, définies dans un **paramètre** (pas
+  de code en dur) pour absorber une évolution de topologie.
+- **Flux couverts** : **tous les flux entrant vers l'ASRS** via un poste
+  d'identification zone travail (réception extérieure/intersite, retour picking
+  vers ASRS, recertification, etc.). Mécanisme **générique** : teste uniquement
+  la station source + la présence d'un programme sur le support.
+- **Hors périmètre** : PIE_01 (entrée production, non filmée), PIE_03 (pas de
+  filmeuse après ce PIE), la pose de `CstAtt05` (LIM-67) et la mécanique
+  physique de la filmeuse (Galileo/TMS).
+
+> ⚠️ Réconciliation : le tableau des stations PIE ci-dessus indique
+> « PIE_03 = idem PIE_02 ». Pour le **filmage**, LIM-115 exclut PIE_03 (pas de
+> filmeuse en aval). L'identité PIE_02/PIE_03 vaut pour le **mode d'insertion**,
+> pas pour la filmeuse.
+
 ## Rétention des données
 
 | Entité | Durée standard | Souhait Limagrain |
@@ -123,21 +175,23 @@ Deux entrées dans l'ASRS :
 peuvent impacter les flux fonctionnels.
 
 ⚠️ La banderoleuse (filmeuse) est située avant le PIE côté postes de
-travail — un contrôle capacité filmeuse est fait en amont du PIE.
+travail - un contrôle capacité filmeuse est fait en amont du PIE.
 
 ## Questions ouvertes
 
-- [ ] Impact rétention 2 ans sur les performances Oracle (@Nicolas)
-- [ ] Fournisseur AGV définitif et protocole d'interface (@Théo)
+- ❓ Impact rétention 2 ans sur les performances Oracle (@Nicolas)
+- ❓ Fournisseur AGV définitif et protocole d'interface (@Théo)
 
 ## Historique des modifications
 
 | Date | Auteur | Modification |
 |------|--------|--------------|
 | 2026-05-05 | Arthur | Création initiale depuis AF V1.5 |
+| 2026-07-20 | Arthur | LIM-115 (lecture directe, Ouvert) : nouvelle section « Transmission du programme de filmage à la filmeuse » (subscription MovementCreated, filtre station source PIE_02 via paramètre, lecture CstAtt05, force CstData=0 si vide/pas de filmage/destination rejet, écriture idempotente CustomData tâche, lecture Galileo via GalileoMovTrackingCreateCommand ; périmètre tous flux entrant ASRS via PIE_02, hors PIE_01/PIE_03) + caveat réconciliation PIE_03 (pas de filmeuse) ; front matter jira_refs/sources/tags/last_updated |
 
 ## Références
 
 | Source | Type | Date |
 |--------|------|------|
 | FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5 | Analyse fonctionnelle | 28/11/2025 |
+| [LIM-115](https://easywmsfrance.atlassian.net/browse/LIM-115) | Ticket Jira (transmission du programme de filmage à Galileo/filmeuse) | 2026 |

wiki/limagrain/02-stockage/palettes-vides.md

@@ -2,7 +2,7 @@
 title: "Gestion des palettes vides"
 tags: [stockage, palettes-vides, réapprovisionnement, expédition]
 status: draft
-standard_ref: concepts/container-management.md
+standard_ref: concepts/container.md
 jira_refs: []
 confluence_refs: []
 sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx, "Réception - LIMAGRAIN - DEV - Confluence.md"]
@@ -12,7 +12,7 @@ author: Arthur
 
 # Gestion des palettes vides
 
-> **Résumé** : gestion des piles de palettes vides dans EasyWMS —
+> **Résumé** : gestion des piles de palettes vides dans EasyWMS -
 > réception, stockage, réapprovisionnement des postes et expédition.
 
 > **Standard EasyWMS** : → voir [Container Management](../../concepts/container.md)
@@ -21,7 +21,7 @@ author: Arthur
 ## Contexte projet
 
 Les palettes vides sont intégrées dans le périmètre EasyWMS. Leur gestion
-est faite **uniquement en pile** — aucune palette vide n'est traitée de
+est faite **uniquement en pile** - aucune palette vide n'est traitée de
 façon unitaire.
 
 ## Typologie
@@ -36,7 +36,7 @@ Les piles de palettes vides sont réceptionnées au niveau des quais.
 Type de réception : **Réception palettes vides**. L'article est nommé
 « PILE DE 10 PALETTES ».
 
-**Règles** : toujours reçu par paquet de 10 palettes (sinon refusé —
+**Règles** : toujours reçu par paquet de 10 palettes (sinon refusé -
 contrainte de hauteur). Aucun scan demandé. Pas de passage par poste
 de travail. Destination : stockage direct dans l'ASRS.
 
@@ -52,7 +52,7 @@ de travail. Destination : stockage direct dans l'ASRS.
 - Position : au plus proche de l'entrée/sortie pour réapprovisionner
   rapidement les postes
 - Stratégie de rangement : voir
-  [Stratégies de rangement](putaway-strategies.md) — type 5
+  [Stratégies de rangement](putaway-strategies.md) - type 5
 - Consultation : vue des stocks avec filtre sur l'article « palettes vides »
 
 ### Au niveau des postes de travail
@@ -100,7 +100,7 @@ Les piles de palettes vides peuvent être expédiées :
 
 ## Points d'attention
 
-⚠️ Gestion uniquement en pile (jamais unitaire) — simplifie le suivi
+⚠️ Gestion uniquement en pile (jamais unitaire) - simplifie le suivi
 mais impose des manipulations par lot de 10.
 
 ⚠️ Le nombre de piles en stock est visible en filtrant la vue des stocks

wiki/limagrain/02-stockage/processus-anoxie.md

@@ -1,8 +1,8 @@
 ---
-title: "Processus d'anoxie — TK01"
+title: "Processus d'anoxie - TK01"
 tags: [stockage, anoxie, TK01, flag, custom, processus]
 status: draft
-standard_ref: concepts/warehouse-processes.md
+standard_ref: concepts/quality-control.md
 jira_refs: []
 confluence_refs: []
 sources: [FR-SW-04-07_LIMAGRAIN_Functional_Analysis_V1.5.docx]
@@ -10,7 +10,7 @@ last_updated: 2026-05-05
 author: Arthur
 ---
 
-# Processus d'anoxie — TK01
+# Processus d'anoxie - TK01
 
 > **Résumé** : processus [CUSTOM] de traitement par anoxie dans l'allée 1,
 > incluant le flag « A anoxier », la relocalisation et le blocage d'allée.
@@ -63,7 +63,7 @@ spécifiques depuis la vue des stocks.
 ## Cas particuliers
 
 - Des stocks d'une même référence (article-lot) peuvent posséder des dates
-  de dernière anoxie différentes — ces stocks ne sont pas physiquement
+  de dernière anoxie différentes - ces stocks ne sont pas physiquement
   différenciables
 - Si une palette contient du stock « mixte » dont certaines lignes ont le
   flag et d'autres pas → toutes les lignes sont considérées « A anoxier »
@@ -77,20 +77,20 @@ flowchart TD
     RELOC1 --> SEL2[2. Sélection palettes à anoxier]
     SEL2 --> RELOC2[Relocalisation vers TK01]
     RELOC2 --> BLOCK[3. Blocage manuel allée 01]
-    BLOCK --> WAIT[Anoxie en cours — 3 à 4 semaines]
+    BLOCK --> WAIT[Anoxie en cours - 3 à 4 semaines]
     WAIT --> FIN[4. Bouton « Fin d'anoxie »]
     FIN --> UPDATE[MAJ date dernière anoxie + suppression flag]
     UPDATE --> DEBLOCK[Déblocage manuel allée 01]
 ```
 
-### Étape 1 — Évacuation des palettes non concernées
+### Étape 1 - Évacuation des palettes non concernées
 
 - Sélection manuelle depuis la vue des conteneurs (filtre sur flag
   « A anoxier »)
 - Relocalisation vers une autre allée (en masse, voir déplacement
   de conteneurs)
 
-### Étape 2 — Relocalisation des palettes à anoxier
+### Étape 2 - Relocalisation des palettes à anoxier
 
 - Sélection manuelle des palettes avec flag « A anoxier »
 - Relocalisation vers TK01 dans la mesure des emplacements disponibles
@@ -98,12 +98,12 @@ flowchart TD
 [CUSTOM] Les étapes 1 et 2 peuvent être **automatisées** afin de créer
 automatiquement les tâches de relocalisation.
 
-### Étape 3 — Blocage
+### Étape 3 - Blocage
 
 - Blocage **manuel** de l'allée 01 sur EasyWMS
 - Le stock et l'allée deviennent indisponibles
 
-### Étape 4 — Fin d'anoxie
+### Étape 4 - Fin d'anoxie
 
 - [CUSTOM] Bouton « Fin d'anoxie » qui :
   - Met à jour la date de dernière anoxie
@@ -122,7 +122,7 @@ automatiquement les tâches de relocalisation.
 
 Les palettes avec flag « A anoxier » ont une stratégie de rangement
 dédiée qui priorise TK01 (voir
-[Stratégies de rangement](putaway-strategies.md) — type 1).
+[Stratégies de rangement](putaway-strategies.md) - type 1).
 
 ## Points d'attention
 
@@ -138,8 +138,8 @@ en cas de reprise d'activité.
 
 ## Questions ouvertes
 
-- [ ] Automatisation étapes 1 et 2 — développement custom validé ? (@Nicolas)
-- [ ] Interface du bouton « Fin d'anoxie » — écran dédié ou menu existant ? (@Fabien)
+- ❓ Automatisation étapes 1 et 2 - développement custom validé ? (@Nicolas)
+- ❓ Interface du bouton « Fin d'anoxie » - écran dédié ou menu existant ? (@Fabien)
 
 ## Historique des modifications
 

wiki/limagrain/02-stockage/putaway-strategies.md

@@ -21,36 +21,36 @@ author: Arthur
 ## Contexte projet
 
 Le premier filtre appliqué aux palettes détermine la stratégie de rangement.
-Limagrain n'utilise pas de classes de rotation ABC — la répartition se fait
+Limagrain n'utilise pas de classes de rotation ABC - la répartition se fait
 sur la nature fonctionnelle de la palette.
 
-## Stratégie 1 — Palettes avec flag « A Anoxier » (mono ou multi lot)
+## Stratégie 1 - Palettes avec flag « A Anoxier » (mono ou multi lot)
 
 Objectif : stocker en priorité dans TK_01 (zone anoxie).
 
 | Priorité | Règle |
 |----------|-------|
-| 1 | TK01 — canal incomplet, même lot SAP + mêmes attributs logistiques (article, propriétaire, statut) |
-| 2 | TK01 — canal vide |
-| 3 | TK01 — canal incomplet avec autre référence |
+| 1 | TK01 - canal incomplet, même lot SAP + mêmes attributs logistiques (article, propriétaire, statut) |
+| 2 | TK01 - canal vide |
+| 3 | TK01 - canal incomplet avec autre référence |
 | 4 | Appliquer la stratégie sans flag « A Anoxier » (stratégie 2 ou 3) |
 | 5 | REJET |
 
-## Stratégie 2 — Palettes mono lot sans flag « A Anoxier »
+## Stratégie 2 - Palettes mono lot sans flag « A Anoxier »
 
 Objectif : optimiser le taux de remplissage et répartir le stock entre allées.
 
 | Priorité | Règle |
 |----------|-------|
 | 1 | Canal incomplet même lot SAP + mêmes attributs logistiques |
-| 2 | Canal le plus adapté dans un TK qui n'a **pas** de stock équivalent (répartition inter-allées) — taille optimale vs nb palettes ASN restantes |
+| 2 | Canal le plus adapté dans un TK qui n'a **pas** de stock équivalent (répartition inter-allées) - taille optimale vs nb palettes ASN restantes |
 | 3 | Canal le plus adapté aux nb palettes ASN restantes (toute allée) |
 | 4 | REJET |
 
 **Sélection du canal** : canal le plus grand possible qui sera rempli
 complètement, ou canal qui laissera le moins de positions vides.
 
-## Stratégie 3 — Palettes multi lot sans flag « A Anoxier »
+## Stratégie 3 - Palettes multi lot sans flag « A Anoxier »
 
 | Priorité | Règle |
 |----------|-------|
@@ -59,17 +59,17 @@ complètement, ou canal qui laissera le moins de positions vides.
 | 3 | Canal incomplet (tout) |
 | 4 | REJET |
 
-## Stratégie 4 — Palettes d'expédition (mono ou multi lot)
+## Stratégie 4 - Palettes d'expédition (mono ou multi lot)
 
 Objectif : stocker dans la zone défragmentation client, regroupées par route.
 
 | Priorité | Règle |
 |----------|-------|
-| 1 | Canal incomplet avec palettes de la même route — zone défragmentation client |
-| 2 | Canal vide — zone défragmentation client |
+| 1 | Canal incomplet avec palettes de la même route - zone défragmentation client |
+| 2 | Canal vide - zone défragmentation client |
 | 3 | PAS DE MOUVEMENT (palette reste en place) |
 
-## Stratégie 5 — Piles de palettes vides
+## Stratégie 5 - Piles de palettes vides
 
 Article type « Palette » (NIMP15).
 
@@ -98,7 +98,7 @@ rejet configuré (sauf stratégie 4 où la palette reste sur place).
 qu'après assignation de stock (post-libération de l'OS).
 
 ⚠️ La stratégie 1 (anoxie) utilise un fallback vers les stratégies 2/3
-si TK_01 est plein — important en période hors-anoxie.
+si TK_01 est plein - important en période hors-anoxie.
 
 ## Historique des modifications
 

wiki/limagrain/02-stockage/rejet-pie.md

@@ -0,0 +1,255 @@
+---
+title: "Flux de rejet PIE - Renvoi au poste d'origine"
+tags: [stockage, rejet, PIE, poste, big-bag, production, custom, agv]
+status: draft
+standard_ref: concepts/reception.md
+jira_refs: [LIM-114]
+confluence_refs: []
+related:
+
+  - limagrain/01-inbound/controle-qualite-reception.md
+  - limagrain/07-admin/ad-customs.md
+  - limagrain/07-admin/parametres-projet.md
+sources: ["Jira LIM-114 (lecture directe 2026-07-20)"]
+last_updated: 2026-07-20
+author: Arthur
+---
+
+# Flux de rejet PIE - Renvoi au poste d'origine
+
+> **Résumé** : logique [CUSTOM] qui, lorsqu'une palette est rejetée au PIE
+> avant stockage ASRS, calcule et renvoie au WMS la destination de la palette
+> (renvoi au **poste de travail d'origine**), y pose un verrou porteur de la
+> cause, et gère la correction puis la ré-injection.
+
+> **Standard EasyWMS** : → voir [Reception](../../concepts/reception.md) et le
+> [Contrôle qualité à réception (PIE)](../01-inbound/controle-qualite-reception.md)
+> (contrôles PIE, LIM-66). Ce qui suit documente la **spécificité Limagrain**
+> du rejet.
+
+> **Statut (LIM-114)** : Ouvert, non assignée, **rédaction en cours** côté
+> ticket. Contenu susceptible d'évoluer.
+
+## Contexte projet
+
+Le passage au **PIE** (voir
+[Contrôle qualité à réception](../01-inbound/controle-qualite-reception.md),
+LIM-66) contrôle chaque support avant stockage dans l'ASRS. Si un contrôle
+échoue, la palette est **rejetée** et ne rentre pas dans l'ASRS.
+
+Causes de rejet fonctionnelles attendues : **dimension**, **poids**,
+**étiquette (RFID non lue)**, **palette bois**.
+
+### Revirement client
+
+Cette tâche **remplace** l'approche « poumon au sol + notification SmartUI »
+(esquissée dans LIM-66, Confluence « Réception » §3.2). Le client confirme
+vouloir le **renvoi de la palette rejetée vers le poste de travail où elle a
+été précédemment traitée**, malgré la charge AGV supplémentaire.
+
+Risque assumé (justification initiale de l'abandon) : renvoyer au poste
+d'origine mobilise l'AGV et le poste, avec un risque de blocage table/poste et
+une perte de temps. **Accepté par le client.** La mise à jour Confluence sera
+faite en fin de projet ; pas de modification de LIM-66 (uniquement un lien).
+
+## Principe - le WMS répond la destination
+
+Les routes de rejet **EasyS** amènent la palette rejetée jusqu'à un poste de
+sortie (PS). Une fois au PS, la **recherche d'ordre** déclenche l'interrogation
+du WMS par Galileo : **c'est le WMS qui répond la destination**. Il n'y a donc
+pas de conflit avec les routes EasyS existantes et **pas de reprise de routes**
+à demander à Mecalux.
+
+Cette tâche porte uniquement sur la **logique WMS** (calcul de destination),
+le report du poste d'origine (`CstAtt06`) sur le support réel, et un nouveau
+paramètre `PK_REJET_PROD`.
+
+## Topologie EST / OUEST
+
+- Les palettes de **production** entrent obligatoirement par l'**entrée EST**
+  (image de quai → PIE, sans poste de travail). Exception standard : si le
+  `PE01` (EST) est fermé, tout le flux (y compris production) bascule côté
+  **OUEST** via les routes EasyS existantes.
+- Les palettes de **réception** (fournisseur / intersite / retour) et les
+  palettes **sources de picking** passent par un poste de travail (PK) côté
+  OUEST, qui devient leur **poste d'origine**.
+
+Le WMS est **agnostique du côté** : EasyS achemine le rejet vers le PS local
+(EST ou OUEST), et le WMS répond la destination à partir des attributs du
+support.
+
+## Détermination de la destination de rejet
+
+Au moment de la recherche d'ordre sur le support rejeté arrivé au PS, le WMS
+calcule la destination :
+
+```
+1. Lire CstAtt06 (Code du PK assigné = poste d'origine) du support.
+
+2. SI CstAtt06 renseigné (poste d'origine connu) :        // réception, picking
+     candidat = poste CstAtt06
+     SI big-bag (CstAtt02 = true) ET candidat ∉ PK_BIGBAG : candidat = INVALIDE
+     SI candidat non disponible (fermé / mode incompatible / saturé) : candidat = INVALIDE
+     SI candidat VALIDE : destination = candidat
+     SINON : destination = fallback (étape 4)
+
+3. SINON (CstAtt06 vide) :                                 // production (CstAtt04 = ASN) ou origine inconnue
+     destination = PK_REJET_PROD
+     SI PK_REJET_PROD non disponible : destination = fallback (étape 4)
+
+4. FALLBACK : premier poste ouvert et disponible (first-available),
+     compatible big-bag si CstAtt02 = true.
+     SI big-bag ET aucun poste PK_BIGBAG disponible :
+         LOG erreur + la palette attend sur le PS (pas de destination)
+
+5. Poser un verrou "REJET PIE" sur le support, portant la cause du rejet.
+
+6. Répondre la destination à Galileo.
+```
+
+Notes :
+
+- Le routage vers la destination est **automatique** (convoyeurs PE/PS/PIE
+  sans opérateur), notamment pour les palettes de production qui partent
+  directement vers `PK_REJET_PROD`.
+- La sélection d'un poste « disponible » réutilise la logique de disponibilité
+  de l'assignation des postes (mode actif, saturation), voir
+  [Mini jobs d'assignation au PK](../03-picking/job-assignation-pk.md)
+  (LIM-70 / LIM-74).
+- « Origine inconnue » (`CstAtt06` vide sur un support non production) est
+  traitée comme production → `PK_REJET_PROD` (filet de sécurité).
+
+## Affichage de la cause au poste
+
+Le support arrive au poste avec le verrou « REJET PIE ». À l'arrivée / au scan
+du support, le WMS **affiche la cause du rejet** (dimension, poids, étiquette,
+palette bois) portée par le verrou. **Pas de notification SmartUI** (aligné
+avec l'abandon des notifications de LIM-66) : l'information est portée par le
+verrou et visible au scan.
+
+> ⚠️ **Dépendance Mecalux à confirmer** : pour afficher la cause, EasyS/Galileo
+> doit transmettre au WMS le **type d'erreur PIE** au moment du rejet. À
+> défaut, le WMS n'affichera que « REJET PIE » sans le détail de la cause.
+
+## Correction et ré-injection
+
+L'opérateur traite la palette au poste selon la cause :
+
+| Cause | Action opérateur |
+|-------|------------------|
+| Étiquette | Réétiquetage (impression au poste) |
+| Dimension / poids | Correction physique (reconditionnement, retrait/ajout) |
+| Palette bois réparable | Repalettisation |
+| Palette bois **non réparable** | Déclaration « non réparable » → mouvement vers **REJ01** |
+
+**REJ01** = sortie de rejet dur côté OUEST. Elle évite d'abîmer la navette
+avec des palettes portant des flags non conformes ; la palette ne repart pas
+vers l'ASRS.
+
+Après correction, l'opérateur utilise l'option **standard « Stocker support »**
+(aucun dév custom) : le support repart vers l'ASRS via le PIE (`PIE_ENTRY_PK`)
+et **repasse le contrôle PIE nominal**.
+
+- Contrôle PIE **OK** → rangement ASRS, le verrou « REJET PIE » est **levé**.
+- Contrôle PIE **échoue à nouveau** → nouveau rejet, retour au poste d'origine.
+  **Pas de garde-fou anti-boucle** : tant qu'il y a un rejet, on renvoie au
+  poste d'origine (comportement stable et identique à chaque cycle).
+
+## Prérequis - report du poste d'origine (CstAtt06)
+
+Le `CstAtt06` « Code du PK assigné » (Support, String, créé en LIM-70)
+matérialise le poste d'origine. Il est posé sur le support **fictif** de
+l'image de quai par LIM-70/LIM-74, mais le support **réel** qui passe au PIE
+ne l'hérite pas automatiquement. Il faut donc le **reporter** :
+
+- **Réception (LIM-67)** : à la création du support réel au poste, renseigner
+  `CstAtt06` = code du PK courant.
+- **Picking (LIM-91)** : sur la palette source traitée au poste de picking,
+  renseigner `CstAtt06` = code du PK picking (pour qu'un rejet au ré-stockage
+  revienne au bon poste).
+- **Production** : pas de poste d'origine. `CstAtt06` reste **vide** ; le
+  support est identifié production via `CstAtt04` = ASN. Destination =
+  `PK_REJET_PROD`.
+
+## Paramètres et attributs
+
+Nouveau paramètre (à déclarer dans LIM-14) :
+
+| Paramètre | Description | Défaut |
+|-----------|-------------|--------|
+| `PK_REJET_PROD` | Poste de rejet des palettes sans poste d'origine (production). À câbler physiquement côté EST (ex. `PS01`). | (à définir) |
+
+Paramètres existants réutilisés : `PK_BIGBAG` (postes compatibles big-bag),
+`PIE_ENTRY_PK` (PIE de ré-insertion après poste), `MODES_PKxx` (modes actifs).
+Voir [Paramètres projet](../07-admin/parametres-projet.md).
+
+Attributs utilisés (Support - voir [AD Customs](../07-admin/ad-customs.md#cstatt-support-container--palette)) :
+
+| Attribut | Rôle dans le rejet |
+|----------|--------------------|
+| `CstAtt06` | Poste d'origine. Lu pour déterminer la destination. |
+| `CstAtt02` | Big-bag. Contraint la destination aux postes de `PK_BIGBAG`. |
+| `CstAtt04` | ASN (production). Identifie les palettes sans poste d'origine. |
+
+## Cas de test
+
+27 cas de test définis dans le ticket, regroupés par famille :
+
+- **Destination réception / picking** (CT 1-4) : renvoi au poste `CstAtt06` ;
+  chaque cause (dimension, poids, étiquette, palette bois) route au poste
+  d'origine avec sa cause dans le verrou.
+- **Destination production** (CT 5-7) : `CstAtt04` = ASN + `CstAtt06` vide →
+  `PK_REJET_PROD` (routage auto sans opérateur) ; fallback si indisponible ;
+  origine inconnue traitée comme production.
+- **Big-bag** (CT 8-11) : poste d'origine compatible `PK_BIGBAG` ; origine
+  incompatible → fallback big-bag ; aucun poste compatible → log + attente PS ;
+  non big-bag sans contrainte.
+- **Poste d'origine indisponible** (CT 12-14) : poste fermé/saturé → fallback
+  first-available ; aucun poste dispo → attente PS (à confirmer).
+- **Affichage cause** (CT 15-17) : cause visible au scan ; pas de SmartUI ;
+  « REJET PIE » générique si cause non transmise par EasyS.
+- **Correction / ré-injection** (CT 18-21) : « Stocker support » standard →
+  re-contrôle PIE ; re-rejet → retour poste sans garde-fou ; boucle stable ;
+  aucun écran custom.
+- **Palette bois non réparable** (CT 22-23) : déclaration → REJ01 ; réparable
+  → ré-injection normale.
+- **Prérequis CstAtt06** (CT 24-27) : report réception (LIM-67), pose picking
+  (LIM-91), production sans `CstAtt06`, support réel sans report → traité
+  comme origine inconnue (`PK_REJET_PROD`).
+
+## Points d'attention
+
+⚠️ **Pas de garde-fou anti-boucle** : une palette qui échoue plusieurs fois
+au PIE revient à chaque fois au poste d'origine. Aucune sortie litige
+automatique.
+
+⚠️ Le renvoi au poste d'origine mobilise l'AGV et le poste (risque de blocage
+table/poste). Choix assumé par le client.
+
+⚠️ Tâches liées à modifier : **LIM-67** (report `CstAtt06` sur support réel),
+**LIM-91** (pose `CstAtt06` sur palette source picking), **LIM-14**
+(déclaration `PK_REJET_PROD`), **LIM-66** (ajout d'un lien, sans modification).
+
+## Questions ouvertes
+
+- Transmission de la cause de rejet (type d'erreur PIE) d'EasyS/Galileo vers
+  le WMS - conditionne l'affichage de la cause (@Mecalux)
+- Poste physique `PK_REJET_PROD` côté EST (ex. `PS01`) et sa joignabilité si
+  `PE01` fermé (bascule OUEST) - à valider layout
+- Comportement si aucun poste disponible (attente sur PS vs autre) - à confirmer
+- Disponibilité de l'imprimante d'étiquette au poste d'origine (cause
+  étiquette) - à valider
+
+## Historique des modifications
+
+| Date | Auteur | Modification |
+|------|--------|--------------|
+| 2026-07-20 | Arthur | Création depuis LIM-114 (lecture directe, Ouvert, rédaction en cours) : flux de rejet PIE avec renvoi au poste d'origine, algorithme de destination, topologie EST/OUEST, affichage de la cause, correction/ré-injection + REJ01, report CstAtt06, paramètre PK_REJET_PROD, 27 cas de test résumés |
+
+## Références
+
+| Source | Type | Date |
+|--------|------|------|
+| [LIM-114](https://easywmsfrance.atlassian.net/browse/LIM-114) | Ticket Jira (flux de rejet PIE, rédaction en cours) | 2026 |
+| [LIM-66](https://easywmsfrance.atlassian.net/browse/LIM-66) | Ticket Jira (contrôles PIE, approche poumon abandonnée) | 2026 |
+| [LIM-70](https://easywmsfrance.atlassian.net/browse/LIM-70) / [LIM-74](https://easywmsfrance.atlassian.net/browse/LIM-74) | Tickets Jira (CstAtt06, disponibilité poste, PK_BIGBAG) | 2026 |

wiki/limagrain/02-stockage/zones-stockage.md

@@ -47,7 +47,7 @@ zones de stockage ont été définies pour répondre à deux besoins métier :
 - Réservée **en priorité** aux palettes avec le flag « A anoxier »
 - Hors période d'anoxie, utilisée comme stockage normal (priorité anoxie)
 - Durant l'anoxie (3-4 semaines, 2x/an) : allée + stock bloqués
-- Voir [Processus d'anoxie](../08-transverse/decisions-architecture.md)
+- Voir [Processus d'anoxie](processus-anoxie.md)
 
 ### Zone Principale (TK_02, 03 & 04)