You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
variation-protocol: G-VAR-3 bloque par GENRE, le merge-gate promet le passage par TIER — et l'override n'a aucun organe #14344
variation-protocol.md §2 (G-VAR-3) et §3 (merge-gate) n'emploient pas le meme referent, et
l'ecart se paie en cycles worker :
Endroit
Formulation
Referent
§2 G-VAR-3
« Ban absolu sur les genres LIGHT (guard · ledger · docs · readme · test) »
appartenance de genre
§3 merge-gate
« HOLDsi genre LIGHT ou DEEP/MED non-distinct. Un 2ᵉ DEEP/MED genuinement distinct passe »
tier declare
Un grain MED/guard tombe dans les deux a la fois : bloque par §2 (le genre est LIGHT), passant
par §3 (le tier est MED et la substance est distincte).
L'organe tranche pour §2 — genre_counts_light ne consulte le tier que dans la branche
fail-CLOSED (return tier not in ("MED","DEEP")), jamais pour un genre resolu :
ifcinGENRES:
returncinLIGHT_GENRESreturntiernotin ("MED", "DEEP") # tier-awareness #13585, fail-CLOSED seulement
C'est defendable — le ban par genre est ce qui empeche de contourner G-VAR-3 par choix de mot —
mais alors §3 promet quelque chose que l'organe ne rend pas, et un worker qui lit §3 se croit
couvert.
Incident
PR #14330 (po-2026), MED/guard apres #13869 LIGHT/guard. Le travail : +176/-3 sur l'organe de
merge-gate, 293/293 tests, differentiel old-vs-new sur 264 corps rendant exactement les 3 FP
vises, et il fait passer #13951 de BLOCKED a OK. Non generable-en-serie par le litmus de la regle
elle-meme — et pourtant bloque. La lane a refuse le retag (« le travail EST un grain guard,
le requalifier serait du blanchiment »), ce qui etait le bon reflexe. Override accorde a la main : #14330 (comment).
Ce qu'il faut trancher
Le ban G-VAR-3 porte-t-il sur le genre ou sur le tier ? Les deux se defendent ; ce qui ne
se defend pas est que §2 et §3 repondent differemment.
Si c'est le genre : §3 doit cesser de promettre le passage d'un 2ᵉ MED/DEEP distinct quand
le genre est dans LIGHT_GENRES.
Une troisieme voie : garder le ban par genre, et inscrire l'override comme mecanisme normal
(marqueur lu par l'organe), au lieu d'un arbitrage manuel par cycle. Il n'existe aujourd'hui aucun predicat G-VAR-3 OVERRIDE dans variation_light_cap.py ni dans variation-light-genre.yml — l'override est purement humain, donc invisible au garde.
Aucun agent ne s'auto-autorise a modifier .claude/rules/ : sign-off user requis (CLAUDE.md §A).
Cette issue porte la question, elle ne tranche pas.
Exposition connexe : #14322 (MED/guard, meme lane) touchera la meme adjacence a son
re-check post-merge.
variation-protocol.md§2 (G-VAR-3) et §3 (merge-gate) n'emploient pas le meme referent, etl'ecart se paie en cycles worker :
guard·ledger·docs·readme·test) »Un grain MED/guard tombe dans les deux a la fois : bloque par §2 (le genre est LIGHT), passant
par §3 (le tier est MED et la substance est distincte).
L'organe tranche pour §2 —
genre_counts_lightne consulte le tier que dans la branchefail-CLOSED (
return tier not in ("MED","DEEP")), jamais pour un genre resolu :C'est defendable — le ban par genre est ce qui empeche de contourner G-VAR-3 par choix de mot —
mais alors §3 promet quelque chose que l'organe ne rend pas, et un worker qui lit §3 se croit
couvert.
Incident
PR #14330 (po-2026),
MED/guardapres#13869 LIGHT/guard. Le travail : +176/-3 sur l'organe demerge-gate, 293/293 tests, differentiel old-vs-new sur 264 corps rendant exactement les 3 FP
vises, et il fait passer #13951 de BLOCKED a OK. Non generable-en-serie par le litmus de la regle
elle-meme — et pourtant bloque. La lane a refuse le retag (« le travail EST un grain guard,
le requalifier serait du blanchiment »), ce qui etait le bon reflexe. Override accorde a la main :
#14330 (comment).
Ce qu'il faut trancher
se defend pas est que §2 et §3 repondent differemment.
le genre est dans
LIGHT_GENRES.genre_counts_lightdoit consulter le tier aussi pour les genresresolus — au risque de rouvrir le contournement par choix de mot que la fermeture de
l'enumeration avait ferme (G-VAR : le vocabulaire du tag
Grain:n'est valide sur aucun de ses 3 axes (genre, tier, prev) et echoue fail-OPEN #13475).(marqueur lu par l'organe), au lieu d'un arbitrage manuel par cycle. Il n'existe aujourd'hui
aucun predicat
G-VAR-3 OVERRIDEdansvariation_light_cap.pyni dansvariation-light-genre.yml— l'override est purement humain, donc invisible au garde.Aucun agent ne s'auto-autorise a modifier
.claude/rules/: sign-off user requis (CLAUDE.md §A).Cette issue porte la question, elle ne tranche pas.
Exposition connexe : #14322 (
MED/guard, meme lane) touchera la meme adjacence a sonre-check post-merge.