Appliqué en production : la charge n°1 (URSSAF 1re échéance, 493 €) porte désormais 2 pièces — l'appel de cotisations officiel et une note de correction. Vérifié sur /compta/sociales/document.php?id=1.
La doctrine
Posée par l'opérateur : si une donnée fautive est déjà en production et sans incidence insurmontable sur l'exercice, on ne force pas la correction — on annote l'objet. Le registre reste append-only, la vérité est portée par la pièce, et l'écriture n'est pas maquillée.
La règle est juste. Son canal habituel est fermé ici.
Ce que la vérification a révélé
Sur ce déploiement, aucune écriture sur une charge sociale n'aboutit — ni la date, ni le montant, ni même la note publique. Toutes passent par le même UPDATE et échouent sur multiple assignments to same column "fk_user_modif" (#87).
Ce qui fonctionne est un autre chemin : attacher un document — le téléversement n'est pas un UPDATE sur l'objet.
Chemin
Résultat
Édition de la date
❌ 42601
Édition du montant seul
❌ 42601
Note publique
❌42601
Pièce jointe
✅
Le faux positif qui a failli passer
J'ai d'abord conclu que le chemin des notes échappait au bug. Il ne lui échappe pas.
La page de retour de Dolibarr ré-affiche le texte soumis : un contrôle naïf « le texte est là » réussit sur un enregistrement qui n'a jamais eu lieu. La note de test n'avait pas persisté — constaté en relisant l'objet dans une navigation séparée.
test/annotateObject.ts en tire sa forme : il relit l'objet, jamais la page de retour, et refuse explicitement en nommant le bug quand celui-ci bloque. Il reste utile sur les objets non affectés par #87. C'est la même leçon que le versement GED — vérifier par la chose, pas par ce que l'écran renvoie.
Contenu de la note attachée
Que le 22/05 est la date du prélèvement, que l'échéance officielle est le 05/05 (appel URSSAF du 09/07, n° TI 117 1583346778 4, joint à la même charge), que le règlement a donc eu 17 jours de retard, pourquoi la date n'a pas été corrigée, et que l'écart reste dans le même mois et le même exercice — sans incidence sur 2026. Avec le rappel que les 3 041 € sont provisoires et régularisables.
Copie versionnée sous fleet/profile/notes/.
Vérifications
deno check test/annotateObject.ts → OK
Répétition sandbox : le script détecte le bug et refuse (exit 1), au lieu de rapporter un succès
Relecture de la sandbox après le test initial : la note n'avait pas persisté — d'où la correction
Production : document.php?id=1 → 2 fichiers liés, 65 Ko
L'issue reste ouverte : le défaut amont n'est pas corrigé, seulement contourné. Les trois autres voies (correction en base, patch de l'image, remontée upstream) restent sur la table, mais la charge n'est plus muette.
**Appliqué en production** : la charge n°1 (URSSAF 1re échéance, 493 €) porte désormais **2 pièces** — l'appel de cotisations officiel et une note de correction. Vérifié sur `/compta/sociales/document.php?id=1`.
## La doctrine
Posée par l'opérateur : *si une donnée fautive est déjà en production et sans incidence insurmontable sur l'exercice, on ne force pas la correction — on annote l'objet.* Le registre reste append-only, la vérité est portée par la pièce, et l'écriture n'est pas maquillée.
La règle est juste. **Son canal habituel est fermé ici.**
## Ce que la vérification a révélé
Sur ce déploiement, **aucune écriture sur une charge sociale n'aboutit** — ni la date, ni le montant, **ni même la note publique**. Toutes passent par le même `UPDATE` et échouent sur `multiple assignments to same column "fk_user_modif"` ([#87](https://gitea.arcodange.lab/arcodange-org/erp/issues/87)).
Ce qui fonctionne est un **autre chemin** : attacher un document — le téléversement n'est pas un `UPDATE` sur l'objet.
| Chemin | Résultat |
| --- | --- |
| Édition de la date | ❌ 42601 |
| Édition du montant seul | ❌ 42601 |
| **Note publique** | ❌ **42601** |
| **Pièce jointe** | ✅ |
## Le faux positif qui a failli passer
J'ai d'abord conclu que le chemin des notes échappait au bug. **Il ne lui échappe pas.**
La page de retour de Dolibarr **ré-affiche le texte soumis** : un contrôle naïf « le texte est là » réussit sur un enregistrement qui n'a jamais eu lieu. La note de test n'avait pas persisté — constaté en relisant l'objet dans une navigation séparée.
`test/annotateObject.ts` en tire sa forme : il relit **l'objet**, jamais la page de retour, et **refuse explicitement** en nommant le bug quand celui-ci bloque. Il reste utile sur les objets non affectés par #87. C'est la même leçon que le versement GED — *vérifier par la chose, pas par ce que l'écran renvoie*.
## Contenu de la note attachée
Que le 22/05 est la date du **prélèvement**, que l'échéance officielle est le **05/05** (appel URSSAF du 09/07, n° TI 117 1583346778 4, joint à la même charge), que le règlement a donc eu **17 jours de retard**, pourquoi la date n'a pas été corrigée, et que l'écart reste dans le même mois et le même exercice — sans incidence sur 2026. Avec le rappel que les 3 041 € sont **provisoires** et régularisables.
Copie versionnée sous `fleet/profile/notes/`.
## Vérifications
- `deno check test/annotateObject.ts` → OK
- Répétition sandbox : le script détecte le bug et refuse (exit 1), au lieu de rapporter un succès
- Relecture de la sandbox après le test initial : la note **n'avait pas persisté** — d'où la correction
- Production : `document.php?id=1` → 2 fichiers liés, 65 Ko
## Suite pour #87
L'issue reste ouverte : le défaut amont n'est pas corrigé, seulement contourné. Les trois autres voies (correction en base, patch de l'image, remontée upstream) restent sur la table, mais la charge n'est plus muette.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Doctrine posée par l'opérateur le 13/08 : si une donnée fautive est déjà en
production et sans incidence insurmontable sur l'exercice, on ne force pas la
correction — on annote l'objet. Le registre reste append-only et l'écriture
n'est pas maquillée.
La règle est juste, son canal habituel est fermé ici : sur ce déploiement,
AUCUNE écriture sur une charge sociale n'aboutit — ni la date, ni le montant,
NI MÊME LA NOTE PUBLIQUE. Toutes passent par le même UPDATE et échouent sur
« multiple assignments to same column fk_user_modif » (erp#87).
Ce qui fonctionne est un autre chemin : attacher un document, le téléversement
n'étant pas un UPDATE sur l'objet. La charge n°1 (URSSAF 1re échéance, 493 EUR)
porte désormais deux pièces : l'appel de cotisations officiel, et une note de
correction expliquant que le 22/05 est la date du PRÉLÈVEMENT quand l'échéance
officielle est le 05/05 — 17 jours de retard, écart resté dans le même mois et
le même exercice.
annotateObject.ts écrit la note publique d'un objet et REFUSE explicitement
quand le bug la bloque. Ce garde-fou vient d'un faux positif qui a bien failli
passer : la page de retour de Dolibarr ré-affiche le texte soumis, si bien qu'un
contrôle « le texte est là » réussit sur un enregistrement qui n'a jamais eu
lieu. J'ai d'abord conclu que le chemin des notes échappait au bug — il ne lui
échappe pas. Relire l'objet, jamais la page de retour. Le script reste utile sur
les objets non affectés par erp#87.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Appliqué en production : la charge n°1 (URSSAF 1re échéance, 493 €) porte désormais 2 pièces — l'appel de cotisations officiel et une note de correction. Vérifié sur
/compta/sociales/document.php?id=1.La doctrine
Posée par l'opérateur : si une donnée fautive est déjà en production et sans incidence insurmontable sur l'exercice, on ne force pas la correction — on annote l'objet. Le registre reste append-only, la vérité est portée par la pièce, et l'écriture n'est pas maquillée.
La règle est juste. Son canal habituel est fermé ici.
Ce que la vérification a révélé
Sur ce déploiement, aucune écriture sur une charge sociale n'aboutit — ni la date, ni le montant, ni même la note publique. Toutes passent par le même
UPDATEet échouent surmultiple assignments to same column "fk_user_modif"(#87).Ce qui fonctionne est un autre chemin : attacher un document — le téléversement n'est pas un
UPDATEsur l'objet.Le faux positif qui a failli passer
J'ai d'abord conclu que le chemin des notes échappait au bug. Il ne lui échappe pas.
La page de retour de Dolibarr ré-affiche le texte soumis : un contrôle naïf « le texte est là » réussit sur un enregistrement qui n'a jamais eu lieu. La note de test n'avait pas persisté — constaté en relisant l'objet dans une navigation séparée.
test/annotateObject.tsen tire sa forme : il relit l'objet, jamais la page de retour, et refuse explicitement en nommant le bug quand celui-ci bloque. Il reste utile sur les objets non affectés par #87. C'est la même leçon que le versement GED — vérifier par la chose, pas par ce que l'écran renvoie.Contenu de la note attachée
Que le 22/05 est la date du prélèvement, que l'échéance officielle est le 05/05 (appel URSSAF du 09/07, n° TI 117 1583346778 4, joint à la même charge), que le règlement a donc eu 17 jours de retard, pourquoi la date n'a pas été corrigée, et que l'écart reste dans le même mois et le même exercice — sans incidence sur 2026. Avec le rappel que les 3 041 € sont provisoires et régularisables.
Copie versionnée sous
fleet/profile/notes/.Vérifications
deno check test/annotateObject.ts→ OKdocument.php?id=1→ 2 fichiers liés, 65 KoSuite pour #87
L'issue reste ouverte : le défaut amont n'est pas corrigé, seulement contourné. Les trois autres voies (correction en base, patch de l'image, remontée upstream) restent sur la table, mais la charge n'est plus muette.
🤖 Generated with Claude Code