arcodangeandClaude Opus 5
23b0d87aff
L'opérateur tient ses documents hors ERP, dans 1_DOCUMENTS versionné en git. Ce dépôt reste l'exemplaire de référence ; la GED en reçoit le sous-ensemble dont un lecteur des comptes a besoin — ce qui justifie une charge, ce qui prouve que la société existe, ce qui fixe les termes entre la société et son gérant. Le manifeste est déclaratif (gedManifest.ts) : ajouter un document, c'est ajouter une ligne. Les exclusions sont délibérées et commentées — pièces d'identité (données personnelles, aucun lecteur comptable n'en a besoin, l'ERP est exposé), correspondance administrative, et le bail sous-jacent (8,6 Mo contre un plafond de 2 Mo ; le recompresser altérerait le rendu d'une pièce juridique avec un outil non vérifié). Les factures de logement sont versées comme JUSTIFICATIFS du forfait de 220 EUR de la convention d'occupation, jamais comme charges : la convention les inclut forfaitairement et exclut toute régularisation. Les enregistrer séparément serait un double emploi. Le répertoire le dit dans sa description. Cinq pièges ont coûté cher et sont consignés dans RUNBOOK_ged.md : - l'API REST MENT sur modulepart=ecm. Elle répond le nom du fichier — donc succès — sans rien déposer que la GED sache retrouver : arbre vide et 404 sur le chemin qu'on vient d'écrire. Elle accepte de surcroît n'importe quel subdir. La GED manuelle ne s'alimente que par l'UI, qui écrit ET indexe ; - un répertoire ne se crée que par l'UI ; « existe déjà » vaut succès ; - l'arbre est replié et monté en JS, ses ancres portent href="#", le chemin vit dans rel et l'id dans le onclick, et les enfants n'arrivent qu'au dépliage ; - au-delà de 2 Mo le formulaire accepte, n'écrit rien et n'affiche aucune erreur ; - la case « écraser » ne s'applique pas : chaque passe dupliquait. D'où le principe de vérification : par les NOMS, jamais par un compteur — un compteur juste peut recouvrir deux exemplaires d'une pièce et l'absence d'une autre. C'est ce contrôle qui a révélé l'échec silencieux de l'API. Répété en sandbox, puis appliqué en production : 5 répertoires, 10 pièces, chacune relue par son nom dans la GED. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
ERP
CLI — bin/arcodange
Read-only operational CLI for the Arcodange Dolibarr at erp.arcodange.lab. One entry point, subcommands per domain:
bin/arcodange ping # Dolibarr version + liveness
bin/arcodange whoami # confirm auth as ai_agent
bin/arcodange invoice list # KissMetrics invoices with payment state
bin/arcodange invoice audit 12 # JSON facts + PDF mandatory-mention audit
bin/arcodange payments state # per-invoice TTC vs payments reconciliation
bin/arcodange payments timeline --year 2026 # cash receipts with cumulative balance
bin/arcodange tva summary # CA3-ready collectée − déductible per month
bin/arcodange thirdparty audit-all # completeness audit, country-aware
bin/arcodange templates inspect 1 # recurring template health (frequency, next fire, …)
bin/arcodange snapshot --out /tmp/erp.json # full state dump with content_hash
bin/arcodange help # full command tree
Read-only by design. The underlying API key (ai_agent) has no write permissions; corrections go through the Dolibarr UI.
Credentials. Reads .claude/skills/dolibarr/.env (mode 600, gitignored). Setup instructions: .claude/skills/dolibarr/README.md.
Source of behaviour. Each subcommand delegates to a script under .claude/skills/<skill>/scripts/. The skills' SKILL.md files document the business logic and are also discoverable by Claude Code via skill triggers.
Dolibarr
Premiers démarrages
Si l'application log au démarrage l'erreur suivante:
Importing custom SQL from update_table_ownership.sql ...
sed: couldn't open temporary file /var/www/scripts/before-starting.d/sedwHcRlQ: Read-only file system
Il faudra prendre la main du shell du pod et executer:
kubectl exec -n erp `kubectl get pod -n erp -l app.kubernetes.io/name=erp -o=name` -c erp -- sh -c 'PGPASSWORD=${DOLI_DB_PASSWORD} psql -U ${DOLI_DB_USER} -h ${DOLI_DB_HOST} -p ${DOLI_DB_HOST_PORT} ${DOLI_DB_NAME} \
-f /var/www/scripts/before-starting.d/update_table_ownership.sql'
Sous peine de ne plus avoir les droits de consulter la base de données une fois les crédentials mis à jour par vault. Dans ce cas executer la commande mais avec les credentials d'admin postgres.