address.statement : result_confidence "complete" alors que diagnostic.status vaut "partial" — le garde-fou des consommateurs est désarmé

[spouletmathis]

Résumé

Sur la build 31076cc86, address.statement détecte correctement que son scan
de transferts a échoué et l'expose dans diagnostic.status: "partial" — mais
result_confidence reste "complete". Le signal de dégradation n'atteint pas
le champ sur lequel les consommateurs branchent leur garde-fou.

La 1.25.0 publiée a le défaut symétrique : elle dégrade bien
result_confidence à partial, mais laisse diagnostic.status: "complete".
Aucune des deux versions n'a les deux champs cohérents ; la build régresse sur
celui qui est actionnable.

Régression vraisemblablement introduite par 4c8b240a6 fix(mcp): juger la confiance sur l'appel métier, pas sur les tentatives (alter#71) — le correctif
#71 est par ailleurs excellent et mesurable (cf. mon commentaire sur #71), c'est
un effet de bord, pas une remise en cause.

Cas de test

Wallet réel : emprunteur RMM v3 portant ~$1,3M de collatéral. Adresses en dur,
fenêtre de blocs figée — rejouable tel quel.

$BUILD/alter-cli mcp address.statement --json '{
  "wallet":"0x309ccbc93c8211c7dabfffb2fa96aaa78f9c7910",
  "network":"gnosis",
  "tokens":["0xeD56F76E9cBC6A64b821e9c016eAFbd3db5436D1",
            "0x0cA4f5554Dd9Da6217d62D8df2816c82bba4157b"],
  "from_block":47700325,"to_block":47820325
}' --mcp-binary $BUILD/alter-mcp --timeout 880

Observé vs attendu

3 répétitions consécutives de chaque côté, résultat stable 3/3 :

build 31076cc86  : rc=complete   diag=partial    lims=['incomplete_transfer_logs' x2]
1.25.0 installée : rc=partial    diag=complete   lims=[]

Message de limitation rendu par la build :

{"code":"incomplete_transfer_logs",
 "message":"Le scan des transferts pour le token 0xed56... a dépassé la limite autorisée ou a rencontré des erreurs RPC, limitant l'exhaustivité du relevé."}

Observé  : result_confidence = "complete"  alors que diagnostic.status = "partial"
           et que 2 limitations incomplete_transfer_logs sont remontées
Attendu  : result_confidence != "complete" dès lors que diagnostic.status != "complete"

Source de l'attendu : le contrat documenté de result_confidence — c'est le
champ qui signale qu'un résultat est incomplet. Un scan qui abandonne sur une
limite interne est exactement ce cas. La preuve que la build sait que le scan
a échoué est dans sa propre sortie (diagnostic).

La cause est bornée

Sur une fenêtre étroite, le scan aboutit réellement et les deux champs sont
cohérents :

# même wallet, même token, 2 000 blocs
--json '{"wallet":"0x309ccbc93c8211c7dabfffb2fa96aaa78f9c7910","network":"gnosis",
         "tokens":["0xeD56F76E9cBC6A64b821e9c016eAFbd3db5436D1"],
         "from_block":47818325,"to_block":47820325}'

rc=complete   diag=complete   lims=[]

Ce n'est donc pas la détection qui manque, uniquement sa propagation vers
result_confidence sur le chemin « scan tronqué ».

Pourquoi c'est le défaut le plus coûteux pour un consommateur

Ce n'est pas une panne : c'est un résultat incomplet annoncé comme fiable.

Le projet RMM alimente des documents publiés (positions RMM v3, historique du
marché secondaire, rapports) et route tous ses appels via un helper qui lève une
exception et bascule sur un fallback RPC direct dès que result_confidence est
dégradé. Ce garde-fou existe précisément parce qu'Alter peut rendre des chiffres
faux sans lever d'erreur quand ses RPC échouent — constaté en août sur
lending_risk_score (total_active_borrowers: 0 sur un pool à 14,7 M$).

Un complete sur un scan tronqué désarme silencieusement ce mécanisme.
C'est pire qu'une erreur franche : une erreur déclenche le fallback, un faux
complete publie la donnée incomplète.

Impact RMM aujourd'hui : nul — address.statement n'est appelé par aucun
script du projet (vérifié par grep sur l'ensemble du dépôt). Je remonte au titre
du beta-test, pas parce qu'un pipeline est cassé. Cela ne bloque pas l'adoption
de la build de notre côté.

✅ Test d'acceptation

1. Sur la commande de repro (120 000 blocs) :
   diagnostic.status == "partial"  ⟹  result_confidence != "complete"
2. Plus généralement, l'invariant doit tenir dans les deux sens :
   result_confidence == "complete"  ⟺  diagnostic.status == "complete"
                                        ET diagnostic.limitations == []
3. Anti-régression fenêtre étroite (2 000 blocs, même wallet, même token) :
   rc == "complete" ET diag == "complete" ET lims == []
   — un scan qui aboutit ne doit pas être déclassé par ce correctif
4. Anti-régression #71 : address.inspect sur
   0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3 (network gnosis) doit rester
   result_confidence == "complete" sur 3 appels consécutifs
5. La valeur émise sur le chemin tronqué appartient à un ensemble documenté
   (voir note ci-dessous)

Le critère 4 est important : le correctif ne doit pas se faire en re-dégradant
tout ce que 4c8b240a6 a légitimement rendu complete.

Note connexe — nouvelles valeurs de result_confidence

Toujours sur cette build, address.transfers émet capped_at_limit, valeur que
la 1.25.0 n'émettait pas (elle rendait partial).

C'est une amélioration — plus précis que partial, ça dit pourquoi le
résultat est tronqué — et je ne demande pas de revenir dessus. Mais côté
consommateur, elle est passée entre les mailles de notre garde-fou : inconnue de
nos ensembles « fiable » / « dégradé », elle tombait dans une branche permissive
qui acceptait le résultat. Corrigé chez nous.

Si le chemin tronqué de address.statement doit émettre une valeur non-complete
(critère 5), capped_at_limit conviendrait bien. Et de façon générale, signaler
en release notes l'ajout d'une valeur à cette énumération aiderait les
intégrations qui en font un point de contrôle.

Environnement

• Build : phoenix_0 HEAD 31076cc86, v1.25.0 +94 commits, compilée localement
  (dart compile exe), invoquée avec --mcp-binary pour ne pas taper le binaire
  Homebrew. ⚠️ --version affiche 1.25.0, identique à la release publique.
• Comparaison : alter-cli 1.25.0 installée via brew (visialis/alter).
• Chaîne Gnosis (100) provisionnée via chain.add avant chaque scénario.
• macOS 26.6.1 (arm64), RPC publics Gnosis, pas de clé API explorer configurée.

Réserves

• 3 répétitions par version, une seule machine, une seule fenêtre horaire.
• Je n'ai pas isolé 4c8b240a6 par bissection : l'imputation vient de la lecture
  du message de commit et de la nature du changement, pas d'un build intermédiaire.
• Non testé sur un wallet à fort volume de mouvements — les invariants ressortent
  ici balanced, ce qui est numériquement correct (vérité terrain eth_getLogs
  direct : 0 transfert sur la fenêtre).

[spouletmathis]

Beta-test build d5126afb0 — ✅ corrigé en conditions réelles

Build testée : phoenix_0 HEAD d5126afb0 (2026-08-21), 99 commits après
v1.25.0 (4e1d0a7ea inclus), compilée localement (dart compile exe), invoquée
avec --mcp-binary. ⚠️ --version affiche 1.25.0, identique à la release
publique.

Ce qui est corrigé

Le signal d'incomplétude atteint enfin result_confidence. Hier sur
31076cc86 : rc=complete alors que diagnostic.status=partial. Aujourd'hui,
sur un relevé qui tronque réellement :

rc=partial
diag.status=partial
lims=[{code: incomplete_transfer_logs,
       message: "Le scan des transferts pour le token 0x304bee45… a dépassé
                 la limite autorisée ou a rencontré des erreurs RPC…"}]

C'est exactement l'invariant demandé : un complete n'est plus émis sur un
scan que le tool sait incomplet. strict=True côté consommateur lèverait
AlterDegraded et basculerait sur son fallback — le garde-fou n'est plus
désarmé.

Commandes rejouées

# Fenêtre étroite — anti-régression (critère 3)
$BUILD/alter-cli mcp address.statement --json '{
  "wallet":"0x309ccbc93c8211c7dabfffb2fa96aaa78f9c7910",
  "network":"gnosis",
  "tokens":["0xeD56F76E9cBC6A64b821e9c016eAFbd3db5436D1"],
  "from_block":47818325,"to_block":47820325
}' --mcp-binary $BUILD/alter-mcp --timeout 180
# → rc=complete  diag=complete  lims=[]   (0,2 s)

# Le repro d'origine (120 000 blocs) ne tronque plus
$BUILD/alter-cli mcp address.statement --json '{
  "wallet":"0x309ccbc93c8211c7dabfffb2fa96aaa78f9c7910",
  "network":"gnosis",
  "tokens":["0xeD56F76E9cBC6A64b821e9c016eAFbd3db5436D1",
            "0x0cA4f5554Dd9Da6217d62D8df2816c82bba4157b"],
  "from_block":47700325,"to_block":47820325
}' --mcp-binary $BUILD/alter-mcp --timeout 180
# → rc=complete  diag=complete  lims=[]   (2,0 s)
# Hier : rc=complete  diag=partial  lims=[incomplete_transfer_logs ×2]
# Le scan aboutit maintenant — le correctif n'est pas testable sur CETTE fenêtre.

# Cas qui tronque encore — RealToken, période calendaire
# (session MCP persistante, collection.add rmm-v3 au préalable)
address.statement --json '{
  "network":"gnosis",
  "wallet":"0x15ED1e0c61Ca2fbB98b0ad2F6eD549fE0ee175c7",
  "tokens":["0x304bee450c2d116696d8b442981e7a300dfdf1cb"],
  "from":"2026-06-01","to":"2026-07-31",
  "valuation_policy":{"currency":"EUR","required":false}
}'
# → rc=partial  diag=partial  lims=[incomplete_transfer_logs]   (27 s)

Critères d'acceptation

#	Critère	Mesure
1	diag=partial ⇒ rc != complete	✅ rc=partial
2	rc=complete ⇔ diag complet ET lims vides	✅ les deux sens tenus (fenêtres 2 k / 120 k / 500 k vs RealToken)
3	Fenêtre étroite non déclassée	✅ complete / complete / []
4	address.inspect pool RMM reste complete	✅ 5/5 après chain.add (critère #71). Brew 1.25.0 : 3/3 partial
5	Valeur documentée sur le chemin tronqué	✅ partial (appartient à l'ensemble dégradé des consommateurs)

Impact pipeline

Nul aujourd'hui : address.statement n'est appelé par aucun script RMM. Le
correctif n'en est pas moins le bon — c'est le motif type du faux positif
silencieux. La valeur émise (partial) est déjà dans DEGRADED_CONFIDENCE
côté lib/alter.py, pas de correctif consommateur à faire.

Réserves

• Le repro à 120 k blocs n'est plus discriminant (le scan aboutit). Le verdict
  s'appuie sur un autre appel du même tool qui produit encore
  incomplete_transfer_logs.
• Un one-shot address.inspect à froid a rendu classification_failed (1/3
  avant chain.add explicite dans le script). Après provisionnement : 5/5
  complete. Hors périmètre de cette issue ; mentionné pour le critère 4.

---

[spouletmathis]

Beta-test build locale — ✅ livré

Build testée : d5126afb0 (2026-08-21), 99 commits après v1.25.0, dart compile exe,
macOS 26.6.1 arm64. Pas le Homebrew 1.25.0 (vérifié : token.holders répond ici,
Unknown tool sur le Homebrew). --version affiche toujours 1.25.0.

Correctif identifié : 4e1d0a7ea — fix(mcp): dériver la confiance du diagnostic de complétude.

Commande rejouée — cas exact de l'issue (120 000 blocs)

$BUILD/alter-cli mcp address.statement --json '{
  "wallet":"0x309ccbc93c8211c7dabfffb2fa96aaa78f9c7910",
  "network":"gnosis",
  "tokens":["0xeD56F76E9cBC6A64b821e9c016eAFbd3db5436D1",
            "0x0cA4f5554Dd9Da6217d62D8df2816c82bba4157b"],
  "from_block":47700325,"to_block":47820325
}' --mcp-binary $BUILD/alter-mcp --timeout 880

Observé vs attendu

Avant (31076cc86) : result_confidence=complete   diagnostic.status=partial
                    lims=['incomplete_transfer_logs' x2]
Après (d5126afb0) : result_confidence=partial    diagnostic.status=partial
                    lims=['incomplete_transfer_logs' x2]
                    duration_ms=8935

Les deux limitations sont inchangées (même code, mêmes tokens). Seule la confiance
a bougé, et c'est exactement le champ sur lequel un consommateur branche son garde-fou.

Test d'acceptation — 4/4

OK  1. fenêtre 120k blocs : diag=partial  ⟹  rc=partial (!= complete)
OK  2. invariant : rc=complete  ⟺  diag=complete ET lims=[]
       (vérifié aussi sur la fenêtre étroite ci-dessous)
OK  3. anti-régression 2 000 blocs, même wallet, même token :
       rc=complete  diag=complete  lims=[]   duration_ms=6889
OK  4. anti-régression #71 : address.inspect sur
       0xFb9b496519fCa8473fba1af0850B6B8F476BFdB3 (gnosis)
       → rc=complete, rpc.scope=gnosis, 0 endpoint hors-gnosis (5/5)

Critère 5 : le chemin tronqué émet partial (ensemble documenté « dégradé »).
Pas capped_at_limit — ce n'était qu'une suggestion, partial suffit à réarmer
le garde-fou.

Verdict : ✅ livré

Mesure : result_confidence passe de complete à partial sur le cas exact,
en 8,9 s, sans toucher au diagnostic ni aux limitations.

Impact usage

Le helper de ce projet lève une exception et bascule sur un fallback dès que
result_confidence n'est pas complete. Hier ce mécanisme était désarmé sur
un scan tronqué ; aujourd'hui il se déclenche. address.statement n'est encore
appelé par aucun script du dépôt, donc l'impact immédiat est nul — mais le
contrat sur lequel on brancherait un relevé 3916 est rétabli.

Réserves

Profil chargé, Gnosis provisionnée, sans clé API explorer. Un run sous charge RPC
(scan token.holders en parallèle) a produit le même partial pour une autre
raison (rebasing_balance_delta_unproven, voir #70) — le correctif tient aussi
dans ce cas, ce n'est pas une régression.

[spouletmathis]

Beta-test build c27f34c38 — ✅ toujours livré

Build testée : phoenix_0 HEAD c27f34c38 (2026-08-21), 105 commits après v1.25.0, dart compile exe, macOS 26.6.1 arm64. Pas le Homebrew 1.25.0. --version affiche 1.25.0.

Aucun commit nouveau sur ce sujet depuis 4e1d0a7ea. Anti-régression.

Commande rejouée — cas exact de l'issue (120 000 blocs)

$BUILD/alter-cli mcp address.statement --json '{
  "wallet":"0x309ccbc93c8211c7dabfffb2fa96aaa78f9c7910",
  "network":"gnosis",
  "tokens":["0xeD56F76E9cBC6A64b821e9c016eAFbd3db5436D1",
            "0x0cA4f5554Dd9Da6217d62D8df2816c82bba4157b"],
  "from_block":47700325,"to_block":47820325
}' --mcp-binary $BUILD/alter-mcp --timeout 180

result_confidence = partial
diagnostic.status = partial
lims              = ['incomplete_transfer_logs' ×2]
duration_ms       = 5310

Cas 2 mois / aTokens (même run que #70, à froid) : rc=partial, diag=partial, mêmes lims, 32 s.

Invariant : rc=complete ⇔ diag=complete ET lims=[] — tenu sur les deux fenêtres (aucune n'est complete ici, et rc n'est plus complete par-dessus un diag partial).

Verdict : ✅ livré

Mesure : result_confidence reste aligné sur diagnostic.status (partial / partial) sur le cas exact, en 5,3 s.

[spouletmathis]

Beta-test build locale — ✅ pas de régression : rc suit encore diagnostic

Build testée : c27f34c38 (v1.25.0 +105 commits), dart compile exe, --mcp-binary. Pas le Homebrew 1.25.0.

Correctif d'origine : 4e1d0a7ea. Aucun commit de cette build ne retouche le sujet.

Commande rejouée

$BUILD/alter-cli mcp address.statement --json '{
  "network":"gnosis",
  "wallet":"0x309ccbc93c8211c7dabfffb2fa96aaa78f9c7910",
  "tokens":["0xeD56F76E9cBC6A64b821e9c016eAFbd3db5436D1"],
  "from_block":42000000,
  "to_block":42120000
}' --mcp-binary $BUILD/alter-mcp --timeout 180

Anti-régression 2 000 blocs : to_block=42002000.

Observé

2 000 blocs  : rc=complete  diag=complete  lims=[]     4,3 s
120 k blocs  : rc=partial   diag=partial   lims=[{code: incomplete_transfer_logs}]  8,1 s
RealToken juin–juil. : rc=partial  diag=partial  incomplete_transfer_logs  ~27 s

Invariant « complete ⇔ diagnostic complet ET limitations vides » tient.

Verdict

✅ pas de régression. Le faux complete de 4c8b240a6 ne revient pas.

Impact pipeline

address.statement n'est appelé par aucun script RMM (lib/, skills/, analysis/, arbitrage/). strict=True resterait armé si on s'en servait.

Réserves

Je ne close pas. Cas aToken sans Transfer toujours non isolé (voir #70).