Skip to content

variation-protocol: G-VAR-3 bloque par GENRE, le merge-gate promet le passage par TIER — et l'override n'a aucun organe #14344

Description

@myia-ai-01

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 « HOLD si 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 :

if c in GENRES:
    return c in LIGHT_GENRES
return tier not in ("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

  1. 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.
  2. 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.
  3. Si c'est le tier : genre_counts_light doit consulter le tier aussi pour les genres
    resolus — 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).
  4. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions