Files
erp/fleet
arcodangeandClaude Opus 5 3b6c93404e feat(erp): FAC011 — la part différée du cycle M3 n'avait jamais été facturée
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]>
2026-08-24 14:23:58 +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.