L'erreur rattrapée par l'opérateur — ouvrir une fiche fournisseur au nom du gérant — n'était pas un défaut d'exécution mais un choix d'instrument. Rien dans le dépôt ne l'empêchait de se reproduire. RUNBOOK_quel_instrument.md pose la question qui tranche — à qui la société doit-elle cet argent ? — et sa table de décision : fournisseur réel → facture fournisseur ; organisme social ou fiscal → charge ; l'associé lui-même → paiement divers sur CCA1, sans aucun tiers. Il distingue les deux usages du compte courant, que l'on confond facilement : le gérant AVANCE une dépense (adc-005, le tiers est le fournisseur) contre la société DOIT au gérant (adc-010, aucun tiers). adc-010 enregistre la décision et sa base : le compte 455 porte les sommes dues à l'associé, le poste fournisseurs les dettes d'exploitation envers des tiers ayant fourni biens ou services. Le gérant qui met une pièce à disposition n'y entre pas — même raisonnement qu'adc-008 et le runbook charges sociales opposent déjà à l'URSSAF. AGENTS.md porte désormais la règle dans les operating rules, avec la leçon généralisable : une écriture dont le modèle contredit celles déjà au grand livre est presque toujours fausse, et la vérification coûte une requête. La règle dit aussi que le choix décide de la voie technique — ni les charges sociales ni les paiements divers n'ayant d'API REST, le promote gated ne peut pas les porter. Le calendrier porte la décision de l'opérateur du 13/08 : pas de rémunération de gérance en 2026, arbitrage reporté à 2027, avec ses conséquences — aucun trimestre de retraite validé, et une régularisation URSSAF probablement à la baisse puisque l'assiette réelle sera quasi nulle. 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.