feat(erp): annoter un objet figé — la date URSSAF portée par une pièce jointe (#90)

Co-authored-by: Gabriel Radureau <[email protected]>

.claude/skills/dolibarr-sandbox-write/RUNBOOK_quel_instrument.md

@@ -32,6 +32,45 @@ réels payées personnellement par le gérant — le tiers y est le fournisseur,
 jamais le gérant. Un modèle qui contredit celui déjà en place est presque
 toujours le mauvais.
 
+## Une charge sociale est TOTALEMENT figée — écrire juste du premier coup
+
+> [!CAUTION]
+> Sur ce déploiement (Dolibarr 22.0.4 + PostgreSQL), **aucune écriture sur une
+> charge sociale n'aboutit** : ni la date, ni le montant, **ni même la note
+> publique**. Toutes échouent sur
+> `ERROR 42601: multiple assignments to same column "fk_user_modif"` —
+> `ChargeSociales::update()` affecte deux fois la même colonne, ce que MySQL
+> tolère et PostgreSQL rejette. Suivi : [erp#87](https://gitea.arcodange.lab/arcodange-org/erp/issues/87).
+
+**La règle générale — « si c'est déjà en production et sans incidence sur
+l'exercice, annoter l'objet suffit » — reste juste, mais son canal habituel est
+fermé ici.** Le champ note passe par le même `UPDATE`.
+
+Ce qui fonctionne, parce que c'est un autre chemin : **attacher un document**.
+Le téléversement n'est pas un `UPDATE` sur l'objet.
+
+```bash
+curl -s -X POST https://erp.arcodange.lab/api/index.php/documents/upload \
+  -H "DOLAPIKEY: $(cat test/.ai_agent_prod_prod_write.key)" \
+  -H 'Content-Type: application/json' -d @- <<JSON
+{"filename":"NOTE-<sujet>-<date>.md","modulepart":"tax","subdir":"<ID DE LA CHARGE>",
+ "filecontent":"<BASE64>","fileencoding":"base64","overwriteifexists":1}
+JSON
+```
+
+Vérifier sur `/compta/sociales/document.php?id=<ID>` que le compteur a bougé.
+Première application : la charge n°1 (URSSAF 1re échéance) porte le 22/05, date
+du *prélèvement*, quand l'échéance officielle est le 05/05 — l'écart, resté dans
+le même mois et le même exercice, est porté par une note attachée plutôt que
+forcé dans la donnée.
+
+`test/annotateObject.ts` écrit la note publique d'un objet **et refuse
+explicitement** quand le bug la bloque, au lieu de croire une page qui ré-affiche
+le formulaire. Ce faux positif a bien failli passer : la page de retour contient
+le texte soumis, donc un contrôle naïf « le texte est là » réussit sur un
+enregistrement qui n'a jamais eu lieu. **Relire l'objet, jamais la page de
+retour.** Le script reste utile sur les objets non affectés par erp#87.
+
 ## Le compte courant d'associé : deux usages à ne pas confondre
 
 Le compte bancaire **`CCA1` (id 3)** porte le numéro comptable **45511** et son