3 000 USD manquants, découverts en assemblant le dossier client complet. La cartographie des cycles ne laisse pas de doute : M1, M2 et M4 ont chacun leur part fixe ET leur part différée ; M3 n'avait que sa part fixe (FAC008, réglée le 20/07). La facture pro forma PR2607-0001, remise au client en juillet, annonçait pourtant l'émission de cette part différée pour le 24/08/2026 — soit le jour même. C'est la date retenue : la numérotation reste chronologique au sens de l'article 289 du CGI, et l'échéance reste au 23/10/2026, trois mois après la fin du cycle M3. Le retard est écrit dans la note de la facture plutôt que masqué par une date d'émission rétroactive, qui elle romprait la chronologie. LE JUGE A POSÉ LA BONNE QUESTION. Il demandait si le différé de trois mois court depuis l'émission ou depuis la fin du cycle — les deux lectures ne divergent que pour M3, dont la facture est tardive : 23/10 contre 24/11. La pro forma tranche en toutes lettres et dans ses deux versions : « émise le 24/08/2026, à échéance du 23/10/2026 », et « paiement différé à 3 mois DE LA PRESTATION ». Retenir une autre date reviendrait à s'écarter d'une annonce déjà faite au client. Preuve en 02b-preuve-echeance.txt. CE QUI A ÉTÉ RETIRÉ DU CHANGE-SET EN COURS DE ROUTE. Une première version ajoutait la clause de pénalités L.441-10 à FAC001, FAC002 et FAC003, qui en sont dépourvues. L'opérateur a précisé le circuit réel : pendant la phase d'audit (janvier-février 2026), c'est WISE qui a émis les factures, en reprenant les identifiants internes de Dolibarr. Ces trois-là ONT donc été transmises au client. Modifier leur note aujourd'hui ferait diverger le registre interne du document que le client détient — l'inverse du but recherché. Le défaut de mention est réel mais historique, sur des factures réglées : consigné, pas réécrit. Depuis avril 2026 en revanche, KissMetrics vire le montant sur le compte Wise sans recevoir aucune facture. C'est ce qui a permis de reprendre FAC004, FAC006 et FAC009 plus tôt dans la journée, et c'est le dossier du 24/08 qui porte ces factures au client pour la première fois. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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 (A0–A3 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.mdstale 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.mdoperating rules +dolibarr-sandbox-writeSKILL.md.