Files
erp/fleet
arcodangeandClaude Opus 5 8fe740896b fix(profile): cotisations TNS en 641, pas 646 — et charge sociale immuable
L'appel de cotisations URSSAF 2026 (PDF officiel du 09/07) a permis de qualifier
l'imputation, restée explicitement ouverte dans le runbook. La réponse contredit
ce qui y était écrit.

Le compte 646 est réservé à l'entreprise individuelle et aux sociétés à l'IR : il
ne s'applique pas à une SARL à l'IS. La prise en charge par la société des
cotisations de son gérant majoritaire est un complément de rémunération —
compte 641, sous-compte dédié, déductible. 645 et 631/633 restent vides :
aucun salarié, l'opérateur n'est pas employeur.

Piège corrigé au passage : la mention « CSG déductible fiscalement » de l'appel
vise l'IR personnel du gérant (art. 62 CGI), pas l'IS de la société. Pour la
SARL la CSG/CRDS est intégralement déductible — la réintégration annoncée dans
un premier temps était un raisonnement d'entreprise individuelle mal transposé.

Le runbook affirmait aussi que le type de charge Dolibarr pilotait le compte.
Faux : la colonne « Code comptable » du dictionnaire est vide pour tous les
types, TAXSSI compris (vérifié cellule par cellule), et le module comptabilité
n'est pas déployé. La carte affiche « Code comptable: Inconnu ». L'ERP porte les
faits, pas les écritures.

Deux corrections de fond sur les dates et les montants :
- les dates de l'échéancier sont des dates d'ÉCHÉANCE (le 5 du mois), pas de
  débit bancaire — 05/05 et non 22/05, ce qui rend visible le retard de 17 jours ;
- les 3 041 EUR sont PROVISOIRES, assis sur un forfait début d'activité, et
  seront régularisés. L'assiette est la rémunération du gérant, jamais le CA.

Enfin, découvert en tentant la correction de date : aucune charge sociale n'est
modifiable sur ce déploiement. Toute édition, même du seul montant, échoue sur
« multiple assignments to same column fk_user_modif » — ChargeSociales::update()
génère un UPDATE que PostgreSQL rejette (42601) là où MySQL passe. Le défaut est
propre à cet objet ; la mise à jour d'un tiers via REST fonctionne. La date doit
donc être juste à la création. updateSocialCharge.ts conserve le cas de
reproduction et diagnostique l'erreur au lieu de la subir.

Le justificatif officiel est attaché aux trois charges de production.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-13 18:49:18 +02:00
..

fleet/ — the atom registry

The fleet is Arcodange's AI back-office: narrow agents ("atoms") that operate the Dolibarr ERP's daily admin & accounting under the AI back-office PRD. This directory is the registry — the versioned source of truth for what the fleet may do. An atom absent from the registry does not run. Contract semantics come from the PRD atom contract; file syntax from the PRD document surface.

What an atom is

One narrow capability (classify, extract, validate, record, reconcile, report, remind) with a strict I/O contract and deterministic validators around it. The LLM proposes, code disposes: formats, arithmetic, checksums, dedupe and referential integrity are enforced by validators, and a model output that fails validation is quarantined, never auto-corrected. Workflows are compositions of atoms with explicit gates — never one prompt that "does the accounting".

Each atom lives in fleet/atoms/<atom>/:

File Role
atom.yaml the registry entry — the contract (schema below)
prompt.md thin runtime prompt, ≤ ~40 lines, extends exactly one class skeleton; no business rules (rules live in fleet/profile/ and in validators)
scripts/ the deterministic implementation: runners, validators, scoring hooks

Folder name = atom name = registry name — the house <app> join-key discipline applied to atoms.

Layout

fleet/
├── README.md                  # this file: registry doc + atom.yaml schema
├── classes/                   # the 7 prompt skeletons (PRD agent catalog)
│   ├── sentinel.md
│   ├── extractor.md
│   ├── erp-scribe.md
│   ├── deterministic-controller.md   # no-LLM by design
│   ├── analyst-writer.md
│   ├── researcher.md
│   └── knowledge-archivist.md
├── atoms/
│   └── invoice-extract/       # T02 — the worked example (contract only; implementation = erp#40)
│       ├── atom.yaml
│       ├── prompt.md
│       └── scripts/
├── golden/                    # per-atom golden sets — land with erp#39
├── profile/                   # fiscal.yaml + calendar.yaml + ADC register + validator (profile/README.md)
└── harness/                   # multi-runtime harness layer: verifier tests + builder bench (harness/README.md)

atom.yaml — the contract, field by field

Per the PRD atom contract:

Field Meaning
name, version Identity. Folder name = name. version bumps on any behavioral change (prompt, model, validator) — a bump re-triggers the atom's golden-set evals.
input_schema / output_schema JSON Schema for the atom's I/O; enforced at runtime (constrained decoding where the model tier supports it).
invariants Deterministic post-conditions checked by code after every run (e.g. HT + TVA == TTC ± 0.01). A failed invariant quarantines the output — refuse, never repair.
side_effect_class read · draft · write-sandbox · write-prod · outbound — drives which gates and credentials apply, per the PRD environment posture table.
idempotency_key How a replay is recognized (e.g. supplier + ref_supplier + TTC) — a second run with the same key must be a no-op.
autonomy The earned level (A0A3 on the autonomy ladder) + a pointer to the eval evidence that justifies it.
model_policy Preferred tier, fallbacks, escalation rule, per the PRD model fleet; closed per-atom by routing-bench evidence (erp#45 for the first atoms).
eval_ref Where the golden set + scoring script live (fleet/golden/<atom>/).

Two registry conveniences beyond the PRD contract fields bind the entry to the rest of the surface: class (which fleet/classes/<class>.md skeleton the prompt extends) and task (the PRD task-inventory id the atom serves).

The worked example is atoms/invoice-extract/atom.yaml (T02) — contract only; its implementation is erp#40.

How an atom graduates

Autonomy is earned per atom, never assumed. The levels (A0 manual → A1 prepare → A2 rehearse + gate → A3 autonomous + audit) are defined on the PRD autonomy ladder; promotion and demotion are mechanical, per the PRD autonomy promotion gates (golden-set evals, unedited-approval streaks, incident demotion — the bars live there, not here). The earned level and its evidence are recorded in the atom's autonomy field: a promotion is a PR that changes that field with the evidence linked, verified per the QA strategy's independent-verification rule.

Conventions

  • English for all agent-facing files (house language policy).
  • Same-change freshness: a change to an atom that leaves its atom.yaml / prompt.md stale is an incomplete change.
  • One capability per file; YAML/frontmatter over prose for anything a machine parses.
  • Environment rules (trunk hygiene, read-only prod, sandbox-first writes, promote gate) are the repo-wide ones: AGENTS.md operating rules + dolibarr-sandbox-write SKILL.md.