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]>
test — Dolibarr UI automation (Deno + Playwright)
A small Deno + Playwright POC that drives the Dolibarr admin UI in the fr-FR
locale. Playwright fills the same forms a human admin would, so the automation
works even where the REST API can't (e.g. generating an API key, which is
encrypted with the instance's own DOLI_INSTANCE_UNIQUE_ID).
Layout
main.ts— original entrypoint (first install, company/display/module setup).provisionSandbox.ts— entrypoint that provisions theerp-sandboxinstance for the AI agent (enable REST API, create a write-scoped user, generate its API key).scripts/login.ts— admin login / logout / whoami helpers.scripts/forms.ts—fillForm,toggleOnOff, CKEditor/ACE helpers.scripts/admin/moduleSetup.ts—configureModule,enableApiModule.scripts/admin/userSetup.ts—createUser,assignRights,generateApiKey.
Configure
Copy .env.example to .env and fill it in. .env, *.key, and
.ai_agent_sandbox.key are gitignored — never commit secrets.
cp .env.example .env
Lock the installer (after a fresh install via main.ts)
Dolibarr keeps its web installer reachable until an install.lock file exists.
After a fresh install (the main.ts flow), create it in the target pod — for the
sandbox:
kubectl -n erp-sandbox exec \
"$(kubectl get pod -n erp-sandbox -l app.kubernetes.io/instance=erp-sandbox -o name)" -- \
/bin/sh -c 'touch /var/www/documents/install.lock && chown www-data:www-data /var/www/documents/install.lock'
The path is the Dolibarr data root (/var/www/documents, a PVC) — that's where
Dolibarr checks, and being on the PVC the lock persists across pod restarts. For
prod, swap to -n erp -l app.kubernetes.io/instance=erp. A sandbox seeded from
prod still needs this: the seed (see ../ops/sandbox/) copies the DB +
documents/mycompany, not install.lock.
Provision the sandbox
Provisions erp-sandbox.arcodange.lab: enables the REST API module, creates the
write-scoped ai_agent_sandbox user, grants it its write rights, and has
Dolibarr generate the user's API key. The key is written to
test/.ai_agent_sandbox.key (gitignored) — it is never printed.
cd test
deno run --allow-all provisionSandbox.ts
Populate .env from the erp-sandbox namespace secrets first. secretkv
carries the app env (including DOLI_ADMIN_PASSWORD); vso-db-credentials
carries the database password:
# Admin password (key DOLI_ADMIN_PASSWORD inside the secretkv secret)
kubectl get secret secretkv -n erp-sandbox \
-o jsonpath='{.data.DOLI_ADMIN_PASSWORD}' | base64 -d
# Database password (key `password` inside vso-db-credentials)
kubectl get secret vso-db-credentials -n erp-sandbox \
-o jsonpath='{.data.password}' | base64 -d
Set in .env:
DOLIBARR_ADDRESS=https://erp-sandbox.arcodange.lab
DOLI_ADMIN_LOGIN=admin
DOLI_ADMIN_PASSWORD="<from secretkv above>"
DOLI_DB_PASSWORD="<from vso-db-credentials above>"
# Optional — otherwise a random password is generated and only the API key emitted:
# AI_AGENT_SANDBOX_PASSWORD="<choose one>"
After it runs
The generated API key lands in test/.ai_agent_sandbox.key. Next step (not
automated by this POC): load it into the dolibarr skill's sandbox config /
Vault at kvv2/erp-sandbox/ai_agent.
Important
The sandbox Dolibarr is not installed/provisioned yet (empty DB, fresh install wizard). Until the install wizard has been completed against the sandbox,
provisionSandbox.tswill not have a UI to drive, and the selectors inmoduleSetup.ts/userSetup.tsare best-effort (Dolibarr 22 conventions, not verified live). Confirm them on the first real run.
Write rights granted
The ai_agent_sandbox user is created non-admin and granted (the authoritative
list is WRITE_IDS in provisionSandbox.ts):
| Module | rights ids |
|---|---|
| facture | lire=11, creer=12 |
| societe | lire=121, creer=122, client voir=262 |
| societe contact | lire=281, creer=282 |
| fournisseur | lire=1181, facture lire=1231, facture creer=1232 |
| produit | lire=31, creer=32 |
| banque | lire=111 |
| user | lire=251 — requis par le probe armé GET /users/info (checkpoint status/relink-env) |