Audit — pilier platform-ops

Douzieme et dernier tour de la rotation (docs/team/roster.md, @codebase-auditor). Les douze piliers ont desormais un audit au dossier.

Lecture seule sur le code. Ce tour differe des six precedents : les six piliers restants ont ete audites en une passe, a la demande. La profondeur par pilier est donc moindre, et chaque document dit ou il s'arrete. La sonde commune est la meme partout : les invariants que le roster declare pour le pilier.

Perimetre : src/services/cron|jobs|status|events|platform/**, src/lib/monitoring/**, .github/**, vercel.json, scripts/**.

Etat du depot : origin/main a 3e23edb7, 27 aout 2026.

Ce qui a ete verifie

---

Constat 1 — la garde de doc couvre un fichier et pas l'autre, et c'est l'autre qui a derive

Severite : faible. → backlog/platform-ops/0070

docs/team/roster.md:309, section @platform-ops-engineer :

« Plafond Vercel de 100 crons par projet, 50 declares : tout nouveau cron justifie son slot dans la PR. »

vercel.json en declare 57. L'ecart est de sept, et il ne s'agit pas d'un detail decoratif : c'est le chiffre sur lequel un agent decide s'il lui reste de la place avant le plafond de la plateforme.

Ce qui rend le constat interessant, c'est pourquoi l'un est juste et l'autre faux. scripts/check-doc-claims.mjs porte une claim cron.total qui derive le nombre de vercel.json et le compare a la valeur ecrite : mais chaque claim porte un champ file, et les neuf ciblent CLAUDE.md.

CLAUDE.md dit 57 parce qu'une garde l'y oblige. Le roster dit 50 parce que rien ne l'y oblige. Les deux documents ont ete ecrits par les memes mains, sur le meme sujet, a quelques jours d'intervalle ; celui qui est verifie est reste juste, celui qui ne l'est pas a derive de 14 %.

C'est la demonstration la plus courte de la doctrine que CLAUDE.md porte lui-meme : « les chiffres de cette page sont derives, pas tenus a la main ». Elle est vraie : pour cette page-la seulement.

Le correctif est petit : le mecanisme existe deja et sait cibler un fichier arbitraire.

---

Releve, sans item

• Le run-first des crons (item 0039) est en place et le roster le documente correctement, avec le raisonnement : une ligne CronExecution ouverte a l'entree, refermee a la sortie, jamais une seconde. C'est un des rares endroits ou la doc de pilier decrit un mecanisme livre plutot qu'un plan.

Ce que cet audit n'a pas couvert

C'est le pilier le moins couvert des douze, et il faut le dire net :

• src/services/cron et src/services/jobs — non ouverts au-dela du decompte. Aucune verification que les 57 crons sont effectivement gardes, ni qu'ils declarent un maxDuration coherent.
• src/services/status — non ouvert, alors qu'il alimente une page publique (/status) qui fait des affirmations de disponibilite.
• src/lib/monitoring — la regle « logger structure uniquement » n'a pas ete sondee. C'etait un invariant declare et je ne l'ai pas verifie ; le prochain tour devrait commencer par la.
• .github/** — les workflows CI n'ont pas ete lus. Ironiquement c'est la surface dont la panne (quota epuise) a rythme toute cette rotation.
• Le budget de crons : 57 sur 100. Personne ne verifie la marge, et le roster se trompait dessus.