arcodangeandClaude Opus 5
11c8c65d45
provisionSandbox.ts granted `[12, 122, 262, 32, 111, 251]`: opaque numeric ids, one fixed scope, one agent per environment. Three failures in the 2026-07/08 sessions came straight from that: 1. Production `ai_agent` — documented as READ-ONLY in AGENTS.md, ADR-0003 and every SKILL.md — actually holds 46 rights against 9 declared, including create/modify on customer AND supplier invoices, thirdparties, contacts, thirdparty payment details, proposals, plus THREE delete rights (proposals, events, and submit/delete documents in the GED). 2. Writing a payment, then a product, to production each required granting a right by hand and revoking it after. A privilege granted ad hoc under time pressure is worse than one nobody holds. 3. A sandbox refresh wiped the agent's proposal rights, because they had been granted manually and lived nowhere in code. - scopes.ts declares three scopes with their purpose and allowed environments: `read` (both envs), `sandbox-write` (sandbox only), `prod-write` (production only, narrow: invoices + payments, what the gated promote apply actually does). resolveScope() refuses a scope on an environment it does not belong to. No scope grants DELETE — the ledger is append-only, deletion stays human. - provisionAiUser.ts creates or aligns one user per (environment × scope), emits its API key to a gitignored 600 file, and has an --audit mode that diffs what a user HOLDS against what its scope DECLARES. Production writes require the guard.ts opt-in. - The audit reads permission labels LIVE off /user/perms.php rather than trusting a catalogue in code: ids are stable per Dolibarr version, not across them, and an audit that cannot name what it found is not actionable. findUserId is implemented locally rather than imported: the trunk's userSetup.ts has one, but it is uncommitted WIP and a provisioning script must not depend on someone's working tree. Tooling only — no production rights were changed. The migration (create the scoped users, repoint the promote pipeline, then strip the over-grants from `ai_agent`) rotates credentials used by every read skill and is the operator's call. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01VRShc4QhLLU73FLHx9vskh
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.