Une rafale bornée sans couper la lecture

Quatre familles de droits, vingt-deux opérations bornées

Le plafond est déclaré par famille de droits et le compteur reste par opération : un plafond écrit opération par opération serait une liste de nombres qui vieillirait à la suivante. Une opération neuve hérite du plafond de sa famille, et un contrôle échoue si l’une n’entre dans aucune.

1. 1. contribuer500 par opération, 1200 en tout

   Mesuré, pas deviné : les contrôles de ce dépôt sont aujourd’hui les seuls à écrire, et le plus intense atteint 223 fois la même opération et 437 contributions en tout pour un même compte en une heure. Ces plafonds sont donc au-dessus de l’heure de travail la plus dense que le dépôt produise, et deux ordres de grandeur sous une boucle machine.

   16 opérations : ajouter_contributeur, changer_etat, clore_tour, constater_evenement_reputation, declarer_objection, deposer_amendement, deposer_appel, deposer_argument, deposer_faille, deposer_proposition, deposer_rapport_minoritaire, ecrire_synthese, examiner_amendement, ouvrir_tour, resoudre_objection, signaler.

2. 2. suivre200 par opération, 300 en tout

   Suivre deux cents objets en une heure est déjà un import en masse, pas une lecture.

   2 opérations : arreter_suivi, suivre.

3. 3. moderer200 par opération, 300 en tout

   Un modérateur vide une file. Un plafond trop bas ferait du quota un obstacle à la modération, ce qui ne protégerait personne.

   2 opérations : prononcer_decision, trancher_appel.

4. 4. voter50 par opération, 60 en tout

   Le cap borne déjà la voix à une par tour. Ce plafond borne le remplacement d’un bulletin, pas la voix : cinquante remplacements en une heure sont de l’indécision.

   2 opérations : deposer_bulletin, remplacer_bulletin.

Un plafond posé par opération seulement laisse un client répartir sa rafale : 16 opérations de « contribuer » à 500 chacune feraient 8000 écritures dans l’heure. Le plafond par scope borne cette somme, et c’est lui qui mord le premier pour qui se répartit.

Mesurés, pas devinés. Les contrôles de ce dépôt sont aujourd’hui les seuls à écrire, et le plus intense atteint 223 fois la même opération et 437 contributions en tout pour un même compte en une heure. Les plafonds sont donc au-dessus de l’heure de travail la plus dense que le dépôt produise, et deux ordres de grandeur sous une boucle machine. Un nombre deviné aurait été faux dans un sens ou dans l’autre.

Le sujet est le compte, et un agent de plus n’est pas un quota de plus

Ce qui est impossible

Qu’un agent mandaté, un humain ou un agent système soit le sujet d’un quota. La table des consommations porte une clé étrangère composée vers « acteurs (id, nature) » et une contrainte qui borne la nature du sujet à « agent_autonome ». La nature d’un acteur est une colonne de sa ligne, à valeur unique : dix agents sous un compte comptent sur un seul compteur, et aucune écriture ne peut en faire autrement.

Ce qui est refusé

Qu’une lecture servie compte par la colonne de l’acteur ce qui relève d’un compte. La colonne existe — un agent autonome n’a pas de compte, la migration 008 le lui interdit — et un contrôle relit le SQL des 23 modules relus pour refuser qu’on s’en serve autrement.

Ce qui reste faisable, et à qui

Déclarer deux agents autonomes et obtenir deux compteurs. Ce n’est pas une faille du modèle : un agent autonome ne possède aucune voix humaine, et la limite porte par identité déclarée. Mais ce n’est pas rien, et c’est écrit plutôt que passé sous silence — aucun agent autonome ne peut écrire aujourd’hui, les écritures communautaires étant derrière un drapeau fermé.

Le cap, 99-101 : « quel que soit le nombre d’agents employés, ce compte ne possède qu’un vote courant par tour. » Un quota posé par agent serait contournable en déclarant deux agents.

La lecture publique n’est jamais coupée

Ce qui est impossible

Qu’un dépassement coupe une lecture. Aucune règle ne nomme « lire » ni « calculer », et la chaîne de lecture ne passe par aucune intention : il n’y a pas de plafond de lecture à appliquer, donc rien à désactiver, rien à contourner et rien à régler de travers. C’est une absence, pas un filtre.

Ce qui est refusé

Qu’un module de lecture appelle la fonction de quota. Un contrôle relit les modules servis et échoue si une route de lecture la nomme.

Ce qui reste faisable, et à qui

Ajouter une règle pour « lire », à qui tient le code. Elle serait refusée par le contrôle, qui lit la liste des scopes de lecture dans le module d’identité au lieu de la recopier.

Un compte au plafond d’écriture, et les lectures publiques interrogées une par une : toutes répondent 200.

Un dépassement rend 429, et le délai annoncé est tenable

Le délai se dérive : ceil(fenetre_secondes - (maintenant - plus_ancienne_consommation_dans_la_fenetre)). Jamais une constante.

Un « Retry-After » arrondi vers le bas mentirait d'une seconde en faveur du service et ferait boucler un client bien élevé, qui réessaierait à l'instant annoncé et essuierait un second 429.

Trois valeurs qu’il ne prend jamais : zéro, une constante, supérieur à la fenêtre.

Une fenêtre calendaire autorise deux fois le plafond en deux secondes, à cheval sur sa bordure. Le contrôle calcule les deux chiffres sur la même suite de consommations et les imprime côte à côte.

Un doublon n’est pas un dépassement, et les deux réponses diffèrent

Un rejeu ne consomme rien, et ce n’est pas un cas particulier du code : c’est l’ordre des gestes. La confirmation rend le reçu d’origine avant d’atteindre la consommation, donc un rejeu n’y parvient jamais.

• Même clé, même corps : le même reçu, « etat: rejouee », et aucune consommation — parce que confirmerIntention rend le reçu d'origine avant d'atteindre la consommation.
• Même clé, corps différent : refus « cle_idempotence_en_conflit », aucune consommation.
• Doublon de contenu sous une clé neuve : refus de la base par l'unicité de la table visée, et un 409 — jamais un 429 : deux causes différentes ne partagent pas un code.
• Sans clé d’idempotence : impossible dans ce dépôt : « operations.cle_idempotence » est NOT NULL avec CHECK (length BETWEEN 8 AND 128).

Aucun paiement n’élargit un quota citoyen

Ce qui est impossible

Qu’un paiement élargisse un quota citoyen. Le plafond citoyen n’a de colonne nulle part dans le schéma : l’élever n’est pas un UPDATE, il n’y a pas de ligne à élever. La table des plafonds professionnels, elle, ne peut pas nommer une opération citoyenne — sa contrainte ferme la liste aux quatre débits — et aucune ligne de consommation ne peut être de famille professionnelle.

Ce qui est refusé

Qu’une lecture servie consulte un plafond professionnel pour répondre à une question citoyenne.

Ce qui reste faisable, et à qui

Modifier la règle dans le code, la faire relire et déployer. C’est un geste qui laisse une trace relue, pas une ligne qu’on insère dans une table.

La liste de diffusion ne porte aucune clé étrangère sortante, et la seule entrante est celle des envois : il n’existe aucun chemin, à un saut comme à deux, entre un abonné et une table de quota. Ce relevé est interrogeable, pas affirmé.

Un quota professionnel existe au cap et il porte sur le gain de temps : debit_api, debit_mcp, exporter, webhook. Le cap, ligne 70 : « La facturation est préparée, mesurée et laissée désactivée. » Préparer veut dire les colonnes et les contrôles, pas un plafond en vigueur.

Ce que la base refuse, trois fois : qu'un plafond professionnel nomme une opération citoyenne — « CHECK (operation IN (...)) » sur les quatre seules ; qu'un plafond professionnel soit actif — « CHECK (actif = false) » ; qu'une consommation soit de famille professionnelle — « CHECK (famille = 'citoyen') » sur la table des consommations.

La priorité de revue est dérivée, et n’a aucune colonne

1. la gravité de l’article : contenu interdit, puis harcèlement, puis spam
2. le nombre de signalements portant sur la même cible
3. l’ancienneté du signalement
4. l’identifiant, pour que l’ordre soit total et donc stable d’un appel à l’autre

Aucune table, aucune colonne d’état : un second endroit où écrire « en attente » divergerait du premier au premier correctif. Un classement de file, lui, reste l’avis d’un médiateur sur une priorité — pas la priorité.

Ce qu’aucun quota ne fait

• aucun paiement n elargit un quota citoyen : Ni directement, ni par un attribut dérivé, ni par un rang. « abonnes » ne porte aucune clé étrangère sortante et la seule entrante est « envois.abonne_id » : il n'existe aucun chemin, à un saut comme à deux, entre la liste de diffusion et une table de quota.
• aucun quota ne derive d une reputation ni d une sanction : « consommations_de_quota » ne porte aucune clé vers « evenements_reputation », « fiabilite_agents », « decisions_moderation » ni « signalements_moderation ». Le relevé à deux sauts est interrogeable, pas affirmé.
• aucun rang n elargit un quota : Les rangs ouvrent des responsabilités, pas des débits. Le cap, 123 : « Les rangs débloquent des responsabilités, pas l'expression de base. »
• aucune consommation n est publique : Une ligne de consommation dirait quand un compte a agi et combien de fois. Le cap interdit d'inférer une opinion pour personnaliser le produit, et une courbe d'activité en est un matériau. Même règle qu'un signalement, pour la même raison.

Et trois familles de droits ne portent aucune règle : « lire » — Borner une lecture couperait la lecture publique. Le brief de phase le dit mot pour mot : « une rafale d’agent est bornée sans couper la lecture ». « calculer » — Même raison : un calcul est une lecture. « produire_brouillon » — Aucune opération du dépôt ne l’emploie aujourd’hui — mesuré en relevant les appels à « preparerIntention » des sept modules métier. Une règle sans opération serait une déclaration qui ne mesure rien.