arcodangeandClaude Opus 5
b745fdcb43
L'opérateur a demandé si le versement de la semaine passée avait été pris en compte. Il ne l'était pas — et la réconciliation menée en réponse a fait sortir trois autres trous. L'ENCAISSEMENT. KissMetrics a viré 2 164,75 EUR le 17/08 (Wise, réf. VENDOR:DEV), soit 2 500,00 USD au taux du jour : la part fixe du cycle M4. Le mouvement n'était pas enregistré, si bien que FAC009 a été émise le matin même au taux du 24/08 (2 140,45 EUR) alors que le contrat arrête le montant dû « au taux du jour du règlement ». La facture était fausse de 24,30 EUR, et déjà payée. Le précédent commandait la méthode : FAC008 avait été libellée 2 185,00 EUR, exactement la somme reçue le 20/07, même schéma de règlement anticipé. Sur arbitrage de l'opérateur, FAC009 est repassée en brouillon, portée à 2 164,75 EUR, revalidée sous le même numéro et la même date, puis adossée au virement. Sa note reprend la rédaction de FAC008. Le juge a bloqué en relevant que `last_main_doc` était présent — donc, selon lui, facture émise. Il confond PDF PRODUIT et facture TRANSMISE : le PDF avait été produit deux heures plus tôt par l'agent lui-même pour assembler le dossier, et le message d'envoi est un brouillon jamais envoyé. Mais il a raison sur la conséquence, et c'est le seul de ses findings de la journée qui apporte quelque chose : le PDF sur disque devenait faux. Il a été régénéré aussitôt. Son second finding — `emetteur` null — tombe : le champ est null sur les huit lignes d'encaissement Wise antérieures ; le renseigner sur la seule ligne d'août romprait la permanence des méthodes au lieu de la servir. LES DEUX ÉCHÉANCES URSSAF. 493,00 EUR prélevés le 22/05 et 1 215,00 EUR le 17/08 n'étaient enregistrés ni l'un ni l'autre. Créés comme charges sociales — pas comme factures fournisseur : l'URSSAF n'est pas un fournisseur — puis réglés depuis Qonto. test/paySocialCharge.ts comble un trou du chemin gated : recordSocialCharge.ts crée la charge et la laisse impayée, et rien n'enregistrait le règlement. Tant qu'il manque, le mouvement bancaire reste orphelin et le solde de l'ERP diverge de celui de la banque — c'est ce qui laissait ces deux échéances invisibles. Dolibarr n'expose aucune route REST pour les charges sociales, donc le pipeline ne peut pas porter l'opération ; le script garde ce qu'il peut de sa discipline. Trois pièges consignés dans le fichier, dont un qui a coûté une fausse alerte : NE PAS chercher « payée » dans la page — « ImPAYÉE » contient « payée ». Une première version déclarait ÉCHEC sur un règlement qui venait d'aboutir, ce qui pousse à rejouer, donc à créer un doublon. On lit le montant restant dû. LE RUNBOOK disait 646. C'est faux depuis adc-009 : dans une SARL à l'IS, ce que la société verse à l'URSSAF pour son gérant majoritaire est une charge de personnel, donc 641. Corrigé, avec la mention explicite que toute version portant 646 est périmée. Ajouté aussi ce que la fiche de charge confirme à l'écran — « Code comptable: Inconnu » : le type de charge ne pilote PAS le compte sur ce déploiement, contrairement à ce que le runbook laissait croire. Enfin l'exemple `--period 2026` du runbook était invalide : le script découpe la valeur comme une date ISO et produisait `undefined/undefined/2026`, ce qui fait échouer la création sans message. Reste au tableau, documenté et non traité ici : six cashbacks Wise (11,13 EUR), un remboursement Qonto (5,22 EUR), l'abonnement Anthropic du 19/08 (90,00 EUR, reçu pas encore arrivé), et deux encaissements client sous-enregistrés — FAC004 et FAC006, 51,13 EUR reçus de plus que ce que l'ERP porte. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
fleet/harness/ — the multi-runtime harness layer
The harness is the orchestration layer around the atoms: builder sessions that
execute backlog issues, cold verifiers that check them (locate-tests, backlog
audits, refutation passes), and the evidence flow into Gitea. Per the PRD
model-fleet › harness portability
(operator direction 2026-07-15), this layer must not have Anthropic as a hard
dependency: the same loop runs on Mistral (vibe -p, mistral-medium-3.5)
or on hermes-served local models (Ornith / MLX, 127.0.0.1:18080). Claude is
an escalation tier, not a prerequisite. Admission of a runtime to a role is
evidence-gated (erp#63):
verifier roles first, scoped builders benched second, and no acceptance gate is
ever relaxed for a cheaper runtime.
Layout
| Path | Role |
|---|---|
verifier/locate-test.md |
canonical locate-test: prompt, inputs, ground truth, pass rule |
verifier/backlog-audit.md |
canonical cold-reader backlog audit: prompt, inputs, rubric |
bin/run-verifier.sh |
run a verifier test against a runtime; emits a JSON transcript |
bin/vibe-builder.sh |
run a scoped builder bench (vibe -p) inside a worktree, with caps + journal |
runs/<date>/ |
committed evidence transcripts, when they back an issue comment |
Runtimes
| Runtime | How the harness reaches it | Typical role |
|---|---|---|
claude |
a context-free subagent in a Claude Code session, given the exact assembled prompt (run-verifier.sh <test> --print-prompt) and nothing else |
baseline verifier; multi-file builder (default per the PRD complexity ceiling) |
ornith |
hermes MLX server, OpenAI-style POST /v1/chat/completions on 127.0.0.1:18080, model leonsarmiento/Ornith-1.0-35B-5bit-mlx |
verifier (candidate) |
mlx --model <id> |
same endpoint, any model the server lists under /v1/models |
verifier (candidate) |
mistral |
vibe -p programmatic mode, tools disabled, model = the vibe active_model (today mistral-medium-3.5) |
verifier (candidate); scoped builder via vibe-builder.sh |
Verifier protocol — no self-grading
- Assemble the prompt from the canonical test file + the pinned input documents
(
run-verifier.shembeds file contents verbatim and records their sha256). - Run every candidate runtime on the same assembled prompt, temperature 0.
- An independent, context-free judge (never the session that built the thing, per the PRD qa-strategy) scores each transcript against the test's ground truth and emits the parity table. A runtime is admitted to verifier duty when it reaches verdict parity with the Claude baseline on both tests.
- Once a non-Claude verifier is admitted, prefer cross-family verification: the verifier SHOULD be a different model family than the builder — a foreign family refuting the builder is stronger evidence than the builder's own family agreeing with itself.
Builder bench protocol
vibe-builder.sh runs one tightly-footered backlog issue end-to-end under a
non-Claude runtime, against the unchanged Execution footer and acceptance
gates. It measures completion, intervention count and wall-clock; a failed bench
is a valid result — it sets the complexity ceiling honestly. Safety bounds:
- refuses to run anywhere that is not a linked worktree (never the trunk —
same structural-guard pattern as
dol-write.sh); - hard caps:
--max-turnsand--max-priceare always set; --auto-approveis acceptable only because the blast radius is bounded: a disposable worktree, read-only API credentials, and the caps above;- the full
vibeJSON journal is kept per run.
Recurring tasks on the Mistral tier
A recurring task (T11 reminders, T13 drift checks, T14 backup freshness) is a
scoped builder with a standing prompt: cron (hermes cron or the operator's
scheduler) calls vibe-builder.sh <worktree> <task-prompt.md> and routes the
journal into the digest. The task prompt lives with the atom
(fleet/atoms/<atom>/prompt.md + its class skeleton); the harness only supplies
the bounded execution shell. No recurring task writes outside its worktree, and
anything ERP-write-shaped still goes through the sandbox + promote gate —
runtime choice never changes the gates.