@piecemaker-legal/piecemaker 1.0.0

package/server/piecemaker/vendor/piecemaker-plugin/skills/recherche-juridique/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: recherche-juridique
+description: "Rechercher un texte de loi ou une jurisprudence via le serveur MCP Légifrance et produire des citations vérifiables (bloc <CITATIONS>) pour une réponse ou un acte PieceMaker. À utiliser dès qu'un texte de loi, un article ou une décision doit être cité — jamais de mémoire. Le hook Stop `verify-citations.mjs` bloque le tour si une citation ne se retrouve pas mot pour mot dans une source réellement lue."
+---
+
+# Recherche juridique et citations vérifiables
+
+## Ce que ce skill garantit
+
+**Une citation n'est acceptée que si elle a été lue dans ce tour, mot pour
+mot.** Le hook Stop `verify-citations.mjs` relit chaque citation du bloc
+`<CITATIONS>` produit en fin de réponse, la localise mécaniquement dans le
+texte source réel, et bloque le tour si l'une d'elles est introuvable — même
+approximativement. Ce n'est jamais un jugement du modèle : c'est une
+recherche de sous-chaîne, tolérante aux espaces/casse/ponctuation mais pas au
+sens. Une citation reformulée, résumée ou inventée est rejetée.
+
+Ce skill décrit le déroulé de recherche avec les outils Légifrance
+effectivement disponibles, puis le format exact que le vérificateur accepte.
+
+## Outils du serveur MCP Légifrance
+
+| Outil | Rôle |
+| --- | --- |
+| `Search_Cour_Cassation` | Recherche ciblée dans la jurisprudence de la Cour de cassation (mots-clés, opérateurs ET/OU, expression exacte, référence d'article), filtrable par matière et publication au bulletin. |
+| `Search_Conseil_Etat` | Même recherche ciblée dans la jurisprudence du Conseil d'État, filtrable par publication au recueil Lebon. |
+| `Search_Cour_Appel` | Même recherche dans les cours d'appel, filtrable par ville — bien cibler (ville + dates), le volume est important. |
+| `Search_CAA` | Même recherche dans les cours administratives d'appel, filtrable par ville. |
+| `Search_Premiere_Instance` | Recherche dans les juridictions de première instance — volume très limité (~50 décisions), opérateur OU par défaut. |
+| `Search_Code` | Recherche dans les codes juridiques français (Code civil, Code du travail…) — référence d'article exacte (`L. 1235-3`), mots-clés ou expression exacte. Renvoie les identifiants `LEGIARTI…` des articles trouvés. |
+| `consulter_article` | Texte intégral et vigueur d'une version précise d'article, à partir de son identifiant `LEGIARTI…` rendu par `Search_Code`. |
+| `consulter_decision` | Rapatrie le texte intégral d'une décision à partir de son identifiant (`JURITEXT…`, `CETATEXT…`). **Rapatrie le texte intégral et le met en cache** (voir plus bas) — c'est le moyen normal de lire une décision avant de la citer. |
+| `Download_Query_Results` | Télécharge en masse tous les résultats d'une requête dans un dossier local, pour trier sans paginer. **Ne rapatrie pas le texte intégral** (voir l'avertissement ci-dessous) — sert au tri, jamais directement à la citation. |
+| `Build_Research_Corpus` | Construit un corpus exhaustif et reproductible sur une question de droit : plusieurs requêtes, déduplication, téléchargement et scan du texte intégral de chaque décision. **Rapatrie le texte intégral.** À utiliser pour une recherche large et systématique plutôt qu'un enchaînement manuel de `Search_*`. |
+| `Validate_Research_Cards` | Valide mécaniquement (sans LLM) le résultat de `Build_Research_Corpus` : une fiche par décision, citations confirmées dans le texte intégral, rapport de couverture. |
+| `Tracking_BODACC` | Situation d'une entreprise (procédures collectives) via son SIREN — hors jurisprudence, utile pour qualifier une partie. |
+
+### Le fait décisif : seuls deux chemins rendent une citation vérifiable
+
+Le vérificateur ne peut confirmer une citation que si le texte intégral de sa
+source est quelque part sur disque. Sur les trois façons dont le MCP restitue
+une décision, **une seule ne rapatrie pas ce texte** :
+
+- **`Build_Research_Corpus`** écrit `decisions.jsonl` (une décision par ligne,
+  champ `texte` = texte intégral réel) — vérifiable.
+- **`consulter_decision`** renvoie le texte intégral dans sa réponse d'outil ;
+  le hook `decision-cache.mjs` le capte au passage et l'écrit dans
+  `~/.piecemaker/decisions/<id>.json` — vérifiable.
+- **`Download_Query_Results`** écrit `results.json`, mais chaque entrée ne
+  contient que `id`, `titre`, `lien`, `date`, `analyse` (un sommaire) et,
+  optionnellement, `solution.dispositif` (le dispositif seul — jamais les
+  motifs). **Pas de texte intégral.** Citer une décision connue uniquement par
+  ce canal produira une citation non vérifiée et bloquera le tour.
+
+**Conséquence pratique** : `Download_Query_Results` sert à trier une liste de
+résultats (lire les titres/sommaires, écarter le hors-sujet). Dès qu'une
+décision de cette liste doit être citée, il faut d'abord la lire avec
+`consulter_decision` (ou l'avoir dans un corpus `Build_Research_Corpus`) —
+jamais citer directement depuis `results.json`.
+
+## Déroulé de recherche
+
+1. **Recherche large** avec l'outil `Search_*` adapté à la juridiction visée
+   (ou `Build_Research_Corpus` pour une question de droit qui mérite un
+   balayage systématique plutôt qu'une requête isolée). Pour un texte de loi,
+   `Search_Code`.
+2. **Tri** des résultats sur les seuls éléments déjà renvoyés (titre, sommaire,
+   date, `analyse`) — sans lire chaque décision en entier. `Download_Query_Results`
+   aide à trier un grand volume hors ligne.
+3. **Lecture** des seules décisions/articles retenus comme potentiellement
+   cite-worthy : `consulter_decision` (jurisprudence) ou `consulter_article`
+   (texte de loi), ou relecture du `decisions.jsonl` d'un corpus déjà construit.
+   Ne lire que ce qui sera effectivement cité ou a de bonnes chances de l'être
+   — pas systématiquement tout ce qui est remonté par la recherche large.
+4. **Citation** : une fois la décision ou l'article lu dans ce tour, en extraire
+   les passages utiles mot pour mot et construire le bloc `<CITATIONS>`
+   (format ci-dessous).
+
+## Discipline de citation
+
+- **Ne jamais citer une source qu'on n'a pas lue dans ce tour.** Une décision
+  connue seulement par son titre, son sommaire, un résumé mémorisé ou un
+  résultat de recherche n'est pas une source de citation valable — elle doit
+  d'abord être lue avec `consulter_decision` ou `consulter_article`.
+- **Une citation est une reproduction littérale**, jamais une reformulation
+  ni un résumé. Copier le texte exact de la source, ponctuation comprise si
+  possible (le vérificateur tolère un léger écart d'espace/casse/ponctuation,
+  pas un écart de sens).
+- **Au plus 3 extraits par citation**, chacun **25 mots maximum**, bien ciblés
+  sur l'affirmation qu'ils appuient.
+- **Références contiguës** : les marqueurs `[N]` dans le texte de la réponse
+  vont de `[1]` à `[N]` sans saut, dans l'ordre de première apparition. Chaque
+  `[N]` a exactement une entrée correspondante `"ref": N` dans le bloc
+  `<CITATIONS>`. Réutiliser un `ref` existant pour citer à nouveau la même
+  source/le même passage plutôt que d'en créer un nouveau.
+- Si une source utile n'a pas encore été lue, la lire avant de la citer — ou,
+  à défaut, dire qu'elle n'a pas pu être lue et ne pas s'appuyer dessus.
+
+## Format du bloc `<CITATIONS>`
+
+Le bloc est ajouté **à la toute fin** de la réponse, tel que parsé par
+`piecemaker-plugin/scripts/lib/citations.cjs` :
+
+```
+<CITATIONS>
+[ ... tableau JSON d'objets citation ... ]
+</CITATIONS>
+```
+
+Le contenu entre les balises doit être un tableau JSON valide (`JSON.parse`
+strict — pas de virgule finale, pas de commentaire). Chaque entrée du tableau
+prend l'une des deux formes suivantes.
+
+### Forme « jurisprudence » (`kind: "case"`)
+
+Identifie la décision par `decision_id` — l'identifiant Légifrance
+(`JURITEXT…`, `CETATEXT…`) tel que rendu par `Search_*`/`Download_Query_Results`/
+`Build_Research_Corpus`, et lu avec `consulter_decision` (ou présent dans un
+`decisions.jsonl`).
+
+```json
+{
+  "ref": 1,
+  "kind": "case",
+  "decision_id": "JURITEXT000012345678",
+  "quotes": [
+    { "quote": "le juge doit rechercher si l'inexécution est suffisamment grave" }
+  ]
+}
+```
+
+Plusieurs extraits de la même décision (jusqu'à 3) :
+
+```json
+{
+  "ref": 2,
+  "kind": "case",
+  "decision_id": "JURITEXT000012345678",
+  "quotes": [
+    { "quote": "premier extrait littéral, vingt-cinq mots au maximum" },
+    { "quote": "second extrait littéral, distinct du premier" }
+  ]
+}
+```
+
+`type` et `author` sont acceptés dans chaque objet `quotes` (facultatifs,
+informatifs, jamais vérifiés). `doc_id`, `page`, `sheet`, `cell` ou un `quote`
+au premier niveau n'ont pas de sens pour une citation de jurisprudence — ne
+pas les utiliser sur une entrée `case`.
+
+### Forme « document » (`kind: "document"`, ou `doc_id` sans `decision_id`)
+
+Identifie une pièce du dossier par `doc_id` (le chemin, absolu ou relatif à la
+racine du dossier, de sa contrepartie Markdown convertie — jamais l'original).
+Chaque extrait porte un localisateur `page` (numéro, ou `"N-M"` pour une plage)
+ou, pour un tableur, `sheet` + `cell` (adresse ou plage A1, ex. `"B7"` ou
+`"B7:C9"`).
+
+```json
+{
+  "ref": 3,
+  "doc_id": "pieces/contrat-bail.md",
+  "quotes": [
+    { "page": 3, "quote": "le preneur s'engage à occuper les lieux en bon père de famille" }
+  ]
+}
+```
+
+Extrait à cheval sur deux pages : `page` prend la forme `"N-M"` et la
+sentinelle `[[PAGE_BREAK]]` sépare, dans le même `quote`, le texte de fin de
+page N du texte de début de page M — chaque segment est vérifié
+indépendamment contre sa propre page.
+
+```json
+{
+  "ref": 4,
+  "doc_id": "pieces/attestation.md",
+  "quotes": [
+    { "page": "41-42", "quote": "texte de fin de page 41 [[PAGE_BREAK]] texte de début de page 42" }
+  ]
+}
+```
+
+Citation dans un tableur (pièce convertie contenant des tableaux `## Sheet:
+<nom>`) : `sheet` + `cell` remplacent `page`.
+
+```json
+{
+  "ref": 5,
+  "doc_id": "pieces/tableau-honoraires.md",
+  "quotes": [
+    { "sheet": "Honoraires", "cell": "B7", "quote": "3 500 €" }
+  ]
+}
+```
+
+Une citation à un seul extrait peut aussi s'écrire sous la forme abrégée
+(niveau supérieur au lieu de `quotes`) — `citations.cjs` l'accepte, elle
+retombe sur un tableau `quotes` d'un seul élément :
+
+```json
+{ "ref": 6, "doc_id": "pieces/mise-en-demeure.md", "page": 1, "quote": "je vous mets en demeure de régulariser sous huitaine" }
+```
+
+## Ce que fait le vérificateur, et quoi faire quand il bloque
+
+À l'arrêt du tour, `verify-citations.mjs` :
+
+1. Parse le bloc `<CITATIONS>` du dernier message.
+2. Pour chaque citation, résout sa source réelle — texte intégral de la
+   décision (corpus `Build_Research_Corpus`, cache `consulter_decision`, ou en
+   dernier recours le sommaire de `Download_Query_Results`) ou pièce
+   Markdown du dossier.
+3. Localise mécaniquement chaque extrait dans ce texte. Un extrait qui a
+   légèrement dérivé (espace, casse, ponctuation) est **corrigé
+   automatiquement** avec l'extrait source exact — ce n'est pas une faute.
+4. Un extrait introuvable, même tolérant, **bloque le tour** : la réponse
+   liste chaque citation fautive avec son identifiant et le motif (source
+   inconnue, source illisible, ou introuvable dans la source).
+
+Quand ça arrive : soit relire la source exacte et reprendre le texte réel de
+l'extrait fautif (jamais le reformuler pour le faire passer), soit retirer la
+citation si elle ne peut pas être justifiée par une source effectivement lue.
+
+## Ce qu'il ne faut pas faire
+
+- Ne jamais citer une décision connue uniquement par un résultat
+  `Download_Query_Results` sans l'avoir d'abord lue avec `consulter_decision`.
+- Ne jamais paraphraser un extrait pour qu'il « sonne » comme la source — le
+  vérificateur tolère l'espace/la casse/la ponctuation, pas le sens.
+- Ne jamais laisser un `ref` sauter un numéro ou repartir en désordre.
+- Ne jamais dépasser 3 extraits par citation ni 25 mots par extrait.
+- Ne jamais inventer un `decision_id` ou un `doc_id` pour combler un manque de
+  source.

package/server/piecemaker/vendor/piecemaker-plugin/skills/redaction-juridique/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: redaction-juridique
+description: "Rédiger, réviser ou commenter un acte juridique français (assignation, conclusions en défense, conclusions d'appel, décision d'associé unique SCI, courrier, mémo) pour PieceMaker, à partir des templates du cabinet, en s'appuyant sur la skill `recherche-juridique` pour les citations. À utiliser dès qu'il faut rédiger ou relire un acte de procédure ou un document juridique."
+---
+
+# Rédaction juridique française — à partir des templates du cabinet
+
+## Bibliothèque de templates
+
+Quatre templates Word sont disponibles dans `/Users/tsardet/Desktop/` :
+
+| Fichier | Usage | Placeholders (`{{...}}`) |
+| --- | --- | --- |
+| `01 - Template Assignation.docx` | Assignation devant une juridiction (acte d'huissier). | `JURIDICTION_COMPETENTE`, `TYPE_DOCUMENT`, `PARTIE_CLIENTE`, `ROLE_CLIENT`, `PARTIE_ADVERSE`, `ROLE_ADVERSE`, `ADRESSE_TRIBUNAL`, `MENTIONS_OBLIGATOIRES`, `PLAISE`, `FAITS`, `DISCUSSION_ASSIGNATION`, `DISPOSITIF`, `BORDEREAU_PIECES`. |
+| `02 - Template Conclusions en défense.docx` | Conclusions en défense (première instance, communiquées par RPVA). | `JURIDICTION_COMPETENTE`, `DATE_GENERATION`, `TYPE_DOCUMENT`, `PARTIE_CLIENTE`, `ROLE_CLIENT`, `PARTIE_ADVERSE`, `ROLE_ADVERSE`, `PLAISE`, `FAITS`, `DISCUSSION`, `DISPOSITIF`, `BORDEREAU_PIECES`. |
+| `03 - Template Conclusions Appel.docx` | Conclusions d'appel (communiquées par RPVA). | Comme les conclusions en défense, plus `CHEFS_JUGEMENT_CRITIQUES`, `DISCUSSION_APPEL`, `DISPOSITIF_APPEL`. |
+| `04 - Template Décisions Associé Unique SCI.docx` | *Prévu pour* une décision d'associé unique de SCI. | **À vérifier avant usage** — voir l'avertissement ci-dessous. |
+
+Chaque template suit la même architecture générale : en-tête (juridiction, parties, avocats), un bloc `{{PLAISE}}`, un rappel des faits, une discussion, un dispositif ("PAR CES MOTIFS"), puis le bordereau de pièces communiquées (`{{BORDEREAU_PIECES}}`).
+
+Le fichier template source reste entièrement générique : il contient des
+placeholders `{{...}}`, jamais une entité réelle ni un code d'anonymisation. Les
+codes éventuels n'apparaissent que dans le document de travail au moment de la
+rédaction.
+
+**Avertissement sur le template n°4** : à la vérification, le fichier `04 - Template Décisions Associé Unique SCI.docx` contient actuellement le même contenu que `01 - Template Assignation.docx` (mêmes placeholders, même texte d'acte d'huissier "J'AI, huissier soussigné, DONNÉ ASSIGNATION A…") — ce n'est pas la structure attendue pour une décision d'associé unique de SCI. Avant de s'en servir pour un acte réel, signalez cette anomalie à l'utilisateur et demandez confirmation ou un template corrigé plutôt que de rédiger une décision de SCI sur un canevas d'assignation.
+
+Ces templates peuvent être déplacés vers `~/.piecemaker/templates/` pour un emplacement stable, indépendant du Bureau ; voir la skill `ajout-de-fonctionnalites` pour la gestion des templates personnels.
+
+## Workflow de rédaction
+
+1. **Choisir le bon template** selon la nature de l'acte (voir tableau ci-dessus).
+2. **Préparer un document de travail `.docx`** dans le dossier du client en
+   **copiant** le template choisi vers ce nouveau chemin (`cp`) — ne jamais
+   éditer le template original en place, et ne jamais copier par-dessus un
+   fichier de travail contenant déjà de la rédaction à conserver. Aucun
+   document n'a besoin d'être ouvert dans une application Word : toute la
+   suite passe par le skill `docx-cli` (Bash + le binaire `docx`) — il n'y a
+   ni volet, ni `paneId`.
+3. **Lire le contenu du document de travail** avec `docx read fichier.docx`
+   (Markdown) et localiser les placeholders restants avec
+   `docx find fichier.docx "{{"` — la sortie donne les localisateurs stables
+   (`p3:5-20`) qui servent aux éditions :
+
+   ```bash
+   docx read fichier.docx                       # contenu en Markdown
+   docx find fichier.docx --regex "\{\{[A-Z_]+\}\}"   # placeholders + localisateurs
+   docx replace fichier.docx "{{PARTIE_CLIENTE}}" "…"    # un placeholder
+   docx replace fichier.docx --batch fills.jsonl         # tous, en une passe
+   docx validate fichier.docx                   # contrôle du document produit
+   ```
+
+   `docx replace` remplace le texte en conservant la mise en forme du run :
+   plus besoin de fusionner les runs fragmentés à la main comme avec le
+   dépaquetage OOXML, le placeholder est retrouvé même s'il est éclaté sur
+   plusieurs `<w:r>`.
+4. **Remplir les placeholders** repérés à l'étape précédente, un par un, en
+   s'appuyant sur les pièces du dossier (voir l'agent `analyste-piece` pour
+   synthétiser une pièce avant de rédiger les faits) et sans jamais inventer
+   une information absente du dossier. Le document de travail est l'unique
+   source des placeholders : ne charger ni fichier JSON compagnon, ni ordre ou
+   consigne de placeholder stocké hors du document.
+5. **Citer via `recherche-juridique`** : toute référence à un texte de loi ou à une décision insérée dans `{{DISCUSSION}}` / `{{DISCUSSION_APPEL}}` / `{{DISCUSSION_ASSIGNATION}}` / `{{DISPOSITIF*}}` doit d'abord être vérifiée avec cette skill — jamais citée de mémoire.
+6. **Anonymiser avant toute sortie externe** du document rédigé — anonymisation depuis l'administration (« Anonymiser & mapper »), puis vérification par l'agent `verificateur-anonymisation` avant envoi.
+
+## Règles qui s'appliquent toujours
+
+- **Citations vérifiables uniquement** : voir la skill `recherche-juridique` pour le détail des outils et de la procédure de vérification. Ne jamais produire un identifiant de texte ou de décision non confirmé.
+- **Ne jamais réutiliser un nom réel** présent dans une pièce anonymisée du dossier pour rédiger un extrait destiné à sortir du dossier de travail — rester sur les codes du mapping (`PERSONNE_PHYSIQUE_1`, `PERSONNE_MORALE_1`, `SOCIETE_SCI_1`, `ADRESSE_1`, etc.) tant que le document n'est pas définitivement destiné à un usage interne au dossier.
+- **Respecter les règles de validation du template** (ex. : une section "FAITS" doit s'appuyer sur des notes de bas de page référençant les pièces communiquées) plutôt que de les contourner pour faire passer un placeholder vide ou incomplet.
+- L'édition du document de travail passe par le skill `docx-cli` : le binaire
+  `docx` mute l'OOXML en place, sans dépaquetage ni application Word, et sans
+  `paneId`. Après le remplissage initial des placeholders, toute édition
+  ultérieure doit rester en suivi des modifications : activer le suivi une
+  fois avec `docx track-changes fichier.docx on` — chaque `replace`, `edit`,
+  `insert` ou `delete` émet alors ses `<w:ins>`/`<w:del>` — puis contrôler
+  avec `docx track-changes list fichier.docx` que toutes les modifications
+  portent bien une marque de suivi.
+- **Corriger une mise en forme se fait au niveau du style**, jamais en
+  recopiant le template par-dessus le document déjà rédigé : redéfinir un
+  style déjà déclaré (police, taille, alignement, espacements) se propage à
+  tous les paragraphes qui le portent et laisse le contenu intact. Inspecter
+  les styles avec `docx styles fichier.docx` ; `docx` mutant le XML en place,
+  les styles maison et les couleurs de thème du template survivent aux
+  éditions. Si un réglage n'a pas de verbe dédié, passer par l'échappatoire
+  `docx raw` plutôt que par un dépaquetage manuel, et revalider avec
+  `docx validate`.
+
+## Ce qu'il ne faut pas faire
+
+- Ne jamais fabriquer un numéro d'article, de décision ou de dossier pour combler un manque d'information.
+- Ne jamais présenter une jurisprudence non vérifiée comme un fait établi.
+- Ne jamais modifier un template original sur le Bureau ou dans `~/.piecemaker/templates/` : toujours travailler sur une copie.
+- Ne jamais copier un template par-dessus un document de travail contenant déjà du travail à conserver : la copie initiale ne se fait qu'une fois, sur un fichier de travail vide ou tout juste créé.
+- Ne jamais simplifier une règle de validation de template juridique sans validation d'un expert du domaine.
+- Ne jamais utiliser le template n°4 pour une vraie décision de SCI tant que son contenu n'a pas été corrigé (voir l'avertissement ci-dessus).

package/server/piecemaker/vendor/piecemaker-plugin/skills/tamponnage/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: tamponnage
+description: Configurer ou générer le tampon du cabinet et tamponner les pièces d'un dossier PieceMaker pour un bordereau — sélection des originaux, conversion en PDF, apposition du tampon numéroté et écriture dans « Pièces tamponnées/Pièce n°1.pdf ». À utiliser dès qu'il est question de tamponner, classer ou numéroter des pièces, de préparer un bordereau, ou de créer, importer, enregistrer ou supprimer un tampon.
+---
+
+# Tamponnage des pièces (bordereau)
+
+## Où vit le code
+
+| Rôle | Emplacement |
+| --- | --- |
+| Enregistrer / lire / supprimer le tampon | `websocket-server/server.cjs` — `POST /api/tampon/save`, `GET /api/tampon/load`, `DELETE /api/tampon/delete` |
+| Tamponner une liste de pièces | `websocket-server/server.cjs` — `POST /api/stamping`, avec `pdf-lib` |
+| Format d'image et dossier de sortie | `websocket-server/lib/stamping.cjs` |
+| Convertir l'original en PDF | `websocket-server/lib/office-to-pdf.cjs` — LibreOffice headless (bureautique) ou `pdf-lib` (images, texte) |
+| Installer LibreOffice | `installer/steps/10-libreoffice.mjs` (`piecemaker --step 10-libreoffice`) |
+| Mémoriser le dossier de travail | `websocket-server/server.cjs` — `rememberDossierFolder` / `getDossierFolder`, registre `<racine PieceMaker>/.piecemaker/dossier_folders.json` |
+| Interface d'administration (`/admin/` → onglet « Tampon et pièces ») | `admin/index.html`, `admin/app.js`, générateur `admin/stamp-builder.mjs`, dossiers via `GET /api/admin/dossiers` |
+
+> **Pont Word retiré.** L'outil MCP `Stamping` et la modal « 🕹️ Configurer le
+> tampon » du volet Word appelaient `POST /api/word/stamping` puis
+> `localTools.stamping` dans `taskpane/taskpane.js` — ce code a été retiré de
+> ce dépôt et vit désormais dans un dépôt séparé et indépendant
+> (`PieceMaker-Word-MCP`), actuellement **suspendu**. Il n'existe **aucun
+> équivalent via le skill `docx-cli`** : `docx` sait lire/éditer un `.docx`, pas
+> superposer une image sur un PDF ni piloter une modal dans un volet Office
+> ouvert. Tant que ce dépôt séparé n'est pas réactivé, configurer et appliquer
+> le tampon passe uniquement par `/admin/` (onglet « Tampon et pièces »).
+
+Le tampon est **un seul fichier** : `<racine PieceMaker>/.piecemaker/tampon.png`
+(image PNG ou JPEG postée en base64 sur `/api/tampon/save`, cf.
+`getSystemDataPath`). Un seul tampon pour tout le cabinet — pas de tampon par
+dossier ni par utilisateur.
+
+## Chaîne de traitement réelle
+
+1. **Le tampon doit exister.** Sans `.piecemaker/tampon.png`, `/api/stamping`
+   répond 400 (« Aucun tampon configuré »). On l'enregistre depuis l'onglet
+   « Tampon et pièces » de `/admin/` (import PNG/JPEG *ou* générateur
+   haute définition : forme, contour, police, couleur et épaisseur, puis
+   « Enregistrer le tampon »).
+2. **La liste des pièces vient des dossiers juridiques enregistrés** :
+   `GET /api/admin/dossiers` → `listDossiers` bâtit la liste sur le registre
+   `caseFolders` (quelle que soit sa place dans l'arborescence), et chaque
+   pièce est un **fichier original** du dossier (tout fichier qui n'est ni
+   `.md` ni `.json`, via `listOriginals`), **identifié par son chemin relatif
+   au dossier** — aucun `compilation_dossier_*.json` n'est requis. L'ancien
+   parcours « volet Word / MCP », qui lisait
+   `<dossier juridique>/compilation_dossier_<documentId>.json` (champ
+   `documents[]` : `id`, `filename`, `type_document`, `date_document`,
+   `texte_integral`) écrit au chargement du dossier depuis Word, n'est plus
+   alimenté : rien dans ce dépôt n'écrit plus ce fichier depuis le retrait du
+   pont Word. Un `compilation_dossier_*.json` déjà présent sur disque reste
+   lisible par les routes `/api/anonymize/compilation/:documentId` existantes,
+   mais aucun nouveau dossier ne peut plus être chargé par ce chemin sans le
+   dépôt `PieceMaker-Word-MCP`.
+3. **Appel** : `POST /api/stamping` avec
+   `{ "pieces": [...], "documentId": "<id>", "folder": "<dossier de travail>" }`.
+   `pieces` porte soit des **chemins relatifs au dossier** (chemin normal
+   aujourd'hui), soit des **`id` de compilation** (`"0001"`, uniquement si un
+   `compilation_dossier_*.json` hérité existe encore sur disque pour ce
+   `documentId`).
+   **L'ordre du tableau fait la numérotation** : premier élément → Pièce n°1.
+   `folder` est facultatif si le dossier de travail a déjà été mémorisé pour ce
+   `documentId` ; sinon la requête est refusée en 400 plutôt que d'écrire
+   ailleurs — le passer explicitement (ou le renseigner dans le champ
+   « Dossier de travail » de l'administration). Le dossier transmis est ramené
+   à son **dossier juridique** — le sous-dossier immédiat de la racine
+   PieceMaker qui le contient (`resolveLegalCaseFolder`) — et tout chemin hors
+   de cette racine est refusé.
+4. **Pour chaque pièce**, le serveur ouvre le **fichier original** — l'entrée de
+   compilation résolue par son `filename` si elle existe, sinon le chemin relatif
+   résolu dans le dossier (`resolveCaseRelativeFile`, chemin absolu ou remontant
+   refusé) —, **jamais le `.md`** produit par la conversion Markdown, le charge
+   dans `pdf-lib`, appose le tampon sur la **première page**, en haut à droite
+   (carré de 100 pt, marge de 20 pt), avec le numéro de pièce imprimé au centre.
+5. **Sortie** : `<dossier juridique>/Pièces tamponnées/Pièce n°N.pdf`.
+   Le dossier juridique est celui résolu à l'étape 3 (`folder`, ou dossier
+   mémorisé pour le `documentId`), jamais la racine PieceMaker : les pièces
+   tamponnées restent avec le dossier du client. Réponse
+   `{ folder, tamponnedDir, results[], summary: { total, success, failure } }`,
+   chaque `result` portant `pieceNumber`, `id`, `filename`, `outputFileName`
+   ou `error`.
+
+**Règle de nommage — non négociable** : un fichier par pièce, nommé
+exactement `Pièce n°<N>.pdf` (`Pièce n°1.pdf`, `Pièce n°2.pdf`, …), numéroté
+selon l'ordre du bordereau. Pas de préfixe de dossier, pas de nom d'origine
+conservé, pas de zéro de remplissage.
+
+## Conversion en PDF de l'original
+
+`/api/stamping` convertit chaque pièce avant de la tamponner
+(`websocket-server/lib/office-to-pdf.cjs`) :
+
+| Original | Moteur | Dépendance |
+| --- | --- | --- |
+| `.pdf` | aucun, le fichier est tamponné tel quel | — |
+| `.xlsx` `.xlsm` `.xls` `.ods` `.csv` | LibreOffice headless | **LibreOffice requis** |
+| `.docx` `.doc` `.odt` `.rtf` `.pptx` `.ppt` `.odp` `.html` | LibreOffice headless | **LibreOffice requis** |
+| `.png` `.jpg` `.jpeg` | `pdf-lib`, image centrée sur une page A4 | aucune |
+| `.txt` `.md` `.log` | `pdf-lib`, texte paginé A4 | aucune |
+| autre (`.zip`, `.tif`, …) | refusé pièce par pièce | — |
+
+LibreOffice est appelé avec un profil utilisateur isolé
+(`-env:UserInstallation=…`), ce qui permet de convertir même quand une
+instance de LibreOffice est déjà ouverte sur le poste — même précaution que le
+script `office/soffice.py` des skills documentaires officielles d'Anthropic.
+
+Si le binaire est absent, la pièce échoue avec un message d'installation et
+les autres pièces sont traitées quand même. Résolution :
+`piecemaker --step 10-libreoffice`, ou `SOFFICE_PATH` dans `.env` si
+LibreOffice est installé à un emplacement non standard. `GET /api/admin/status`
+expose `libreOffice: false` dans ce cas, et l'onglet « Tampon et pièces » de
+l'administration affiche l'avertissement.
+
+Deux règles constantes : `smart_converter.py` (skill `conversion-md`) produit
+du **Markdown**, pas du PDF — il n'intervient pas ici ; et on ne tamponne
+jamais le `.md` d'une pièce, le bordereau doit renvoyer au document d'origine.
+
+## Diagnostic des erreurs fréquentes
+
+| Message | Cause |
+| --- | --- |
+| `Aucun tampon configuré` | `.piecemaker/tampon.png` absent — enregistrer un tampon d'abord |
+| `Dossier de travail inconnu` | aucun dossier mémorisé pour ce `documentId` — passer `folder`, ou renseigner « Dossier de travail » dans l'administration |
+| `Le document doit être enregistré dans un dossier juridique sous la racine PieceMaker` | le dossier transmis est hors de la racine configurée — le déplacer, ou corriger la racine dans l'administration |
+| `Dossier de travail introuvable : …` | le chemin transmis n'existe pas (dossier déplacé, lecteur réseau non monté) |
+| `Fichier compilation_dossier non trouvé` | un `id` de compilation a été envoyé mais aucun `compilation_dossier_*.json` n'existe pour ce `documentId` (ce fichier n'est plus produit — voir plus haut) |
+| `Document avec ID … introuvable dans la compilation` | l'`id` envoyé n'existe pas dans `documents[]` (ids au format `0001`) |
+| `Fichier introuvable : …` | `document.filename` ne pointe pas vers un chemin existant — le fichier original a été déplacé ou n'a jamais été enregistré avec son chemin complet |
+| `Un classeur Excel exige LibreOffice…` | LibreOffice absent — `piecemaker --step 10-libreoffice` ou `SOFFICE_PATH` |
+| `Conversion LibreOffice échouée (…)` | fichier protégé par mot de passe, corrompu, ou format non reconnu par LibreOffice |
+| `Type de fichier non pris en charge pour le tamponnage` | extension hors du tableau ci-dessus (archive, TIFF…) |
+
+## Règles
+
+- Le nombre de pièces tamponnées et leur ordre doivent correspondre exactement
+  au bordereau du dossier (rédigé via le skill `docx-cli` dans le document de
+  procédure) : renumérotez le bordereau si la sélection change, la
+  numérotation n'est pas persistée côté serveur.
+- Compilations et pièces tamponnées contiennent des données de client : ne
+  recopiez pas leur contenu dans des logs ou des messages hors du poste local.
+- Relancer `/api/stamping` écrase les `Pièce n°N.pdf` existants du sous-dossier
+  `Pièces tamponnées` — c'est le comportement attendu lors d'une renumérotation, mais
+  prévenez avant de le faire sur un bordereau déjà déposé.
+- N'écrivez jamais de pièce tamponnée à la racine du dossier juridique ni à
+  celle de la racine PieceMaker : le sous-dossier `Pièces tamponnées` est le seul
+  emplacement.