@piecemaker-legal/piecemaker 1.0.6

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.