Files
erp/fleet
arcodangeandClaude Opus 5 d4c8d0d68d feat(erp): indemnité d'occupation janv→juil 2026 — change-set gated, au gate
La convention annexée aux statuts (annexe 3) et la décision n°1 de l'associé
unique du 09/01/2026 fixent une indemnité d'occupation de 220 EUR/mois pour un
bureau de 10 m² dans le domicile du gérant. Elle n'a JAMAIS été ni versée ni
comptabilisée : aucun tiers, aucune des 15 factures fournisseur, aucune ligne au
grand livre bancaire.

Change-set : un tiers « Radureau Gabriel » (FO0012) puis 7 factures fournisseur
validées et réglées par inscription au compte courant d'associé (compte 3), sans
mouvement de trésorerie — la voie adc-005. Janvier au PRORATA : la convention
prend effet à sa signature, 23 jours sur 31 → 163,23 EUR. Total 1 483,23 EUR et
non 1 540 : un mois plein aurait été légèrement généreux.

Chaque facture porte en note le fondement complet et le calcul qui justifie le
forfait — loyer 1 100 EUR, quote-part de surface 16,67 % → 183,33, charges
réelles 12,53 au prorata, soit 195,87 de prorata strict contre 220 retenus
(+12,3 %). La justification vit ainsi avec l'écriture, pas dans une note à part.

Répétition sandbox : 8 opérations, 14 suites, toutes ok. Dates vérifiées en
Europe/Paris — lues en UTC elles semblent reculées d'un jour, Dolibarr tronquant
à minuit heure serveur. Compte courant : -429,75 → -1 912,98.

Corrige un vrai défaut du pipeline découvert en route : quand une op échoue,
{id} était remplacé par le DICTIONNAIRE D'ERREUR, l'URL devenait un JSON
multiligne, urllib levait InvalidURL et l'étape mourait AVANT d'écrire son
artefact — on perdait la preuve de l'échec qu'on venait de produire. Corrigé
dans rehearse et dans apply, où --keep-going exposait la même faille en pleine
écriture de production.

Verdict pré-gate : BLOCK (mistral), au motif d'une numérotation non chronologique
contraire au CGI art. 289. FAUX POSITIF, démontré sur la production : les
factures FOURNISSEUR portent déjà 5 ruptures de chronologie, leur séquence
suivant l'ordre d'enregistrement et non la date du document ; les factures
ÉMISES, seules visées par l'art. 289, en comptent 0. Le juge a appliqué au
registre des factures reçues une règle qui ne gouverne que celles émises. Sa
recommandation de renumérotation casserait la piste d'audit fiable.

Le gate humain n'est pas franchi : rien n'est écrit en production.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-08-13 20:36:45 +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.