Feature: valorisation d'une detention — valuation_policy.required:true est accepte mais jamais servi (statut not_requested, result_confidence complete)

[spouletmathis]

Feature : valorisation d'une ligne RealT — valuation_policy.required: true est accepté mais jamais servi

Build : 31076cc86 (2026-08-20), 94 commits après v1.25.0, compilée localement.

Besoin métier

Produire la valeur d'une détention RealT à une date donnée, pour la déclaration 3916 et
la valorisation annuelle du patrimoine. Concrètement : « au 31/12, mes 51 RealTokens valent
combien ? ». C'est le livrable pour lequel ce projet utilise Alter.

État actuel

address.portfolio répond parfaitement à la partie détention — 51 tokens détenus sur 812
scannés en 2 secondes, avec balance_raw et balance_fmt :

{"token":"0x304bee450c2d116696d8b442981e7a300dfdf1cb",
 "symbol":"REALTOKEN-S-11965-LAKEPOINTE-ST-DETROIT-MI",
 "decimals":18,"holder":"0x15ED1e0c…","balance_raw":"1000000000000000000","balance_fmt":"1"}

Mais aucune valorisation : ni value_usd, ni prix unitaire, ni référence de source.

address.statement expose bien un valuation_policy, et l'accepte :

$BUILD/alter-cli mcp address.statement --json '{
  "network":"gnosis","wallet":"0x15ED1e0c61Ca2fbB98b0ad2F6eD549fE0ee175c7",
  "tokens":["0x304bee450c2d116696d8b442981e7a300dfdf1cb"],
  "from":"2026-06-01","to":"2026-07-31",
  "valuation_policy":{"currency":"EUR","required":true}
}' --mcp-binary $BUILD/alter-mcp --timeout 600

La policy est renvoyée telle quelle dans policies, mais :

result_confidence : "complete"
balances          : [{"opening_raw":"1000000000000000000","closing_raw":"1000000000000000000"}]
                    → aucun champ de valorisation
accounting_entries: valuation = {"valuation_status":"not_requested"}   ← alors que required:true

Deux choses distinctes ici :

1. required: true n'est pas honoré — aucune valorisation n'est produite ;
2. et l'échec est silencieux — result_confidence reste complete et le statut
   d'entrée dit not_requested alors que la valorisation a été demandée et exigée.
   Un required non satisfait devrait faire échouer l'appel ou dégrader la confiance.

Recherche préalable, conformément à la règle de ce projet (chercher un tool avant de
contourner) : inventaire des tools de la build filtré sur price|value|valuation|oracle
→ seuls address.portfolio, address.statement, address.statement.translate et
lending.spread ressortent, aucun ne rend un prix unitaire.
capabilities.search "prix d'un token RealToken" → vide (comportement attendu, cf. #78 :
le catalogue indexe les capacités métier, pas ce besoin).

Le contournement en place

Prix maintenus à la main dans conformite/patrimoine/realtokens.yaml (1,9 Mo), à partir
de l'API RealT et des exports Tediji. Coût : une reprise manuelle à chaque valorisation, une
donnée qui périme en silence, et aucune traçabilité on-chain de la valeur retenue — c'est
précisément ce qu'un justificatif fiscal exige.

À noter : le trou est déjà connu côté produit sous une autre forme (« prix oracle par
RealToken », issue #41 mentionnée dans nos notes). Cette demande-ci est plus étroite : je ne
demande pas un oracle de prix, je demande que la policy déjà exposée soit servie ou refuse
explicitement.

Proposition

Par ordre de préférence, et du moins coûteux au plus complet :

1. Minimum — honorer le contrat existant : si valuation_policy.required: true ne peut
   pas être satisfait, retourner une erreur explicite ou result_confidence: "partial" avec
   une limitation nommée (valuation_source_unavailable) et la remédiation. Aujourd'hui
   l'appelant ne peut pas distinguer « pas valorisable » de « valorisation à zéro ».
2. Utile — un champ value optionnel sur les lignes de address.portfolio, alimenté
   quand une source de prix est configurée, avec price_source + priced_at (bloc ou
   horodatage) pour la traçabilité.
3. Complet — une source de prix déclarable par l'utilisateur (endpoint RealT, oracle
   on-chain, ou table fournie), pour que la valorisation soit reproductible et auditable
   plutôt que dépendante d'un tiers non nommé.

Je reste ouvert sur la forme : le point qui compte est qu'une valeur affichée soit
sourcée et datée, ou absente et dite absente.

Compromis acceptés

Fraîcheur : un prix daté de la veille convient parfaitement pour un usage fiscal annuel.
Exhaustivité : une valorisation qui ne couvre qu'une partie des tokens est utile si elle
dit lesquels. Clé API : configurer une clé est acceptable, à condition que l'absence soit
signalée comme le fait déjà token.holders — c'est le bon modèle.

✅ Test d'acceptation

1. address.statement avec valuation_policy {"currency":"EUR","required":true} :
   soit les entrées portent une valorisation (montant + devise + source + date),
   soit l'appel échoue explicitement avec un code nommé.
   Dans tous les cas : result_confidence != "complete" si aucune valorisation n'est produite.

2. Aucune entrée ne porte valuation_status "not_requested" quand la policy a été fournie
   avec required: true — l'état doit refléter la demande réelle
   ("unavailable", "failed", ou une valorisation).

3. Cas nominal address.portfolio (si option 2 retenue) : sur le wallet
   0x15ED1e0c61Ca2fbB98b0ad2F6eD549fE0ee175c7 (51 RealTokens détenus sur Gnosis),
   chaque ligne valorisée expose price_source et priced_at.

4. Sans source de prix configurée, la réponse expose explicitement l'absence et la
   remédiation — même contrat que la note de token.holders, qui est le bon précédent.

5. Anti-régression : address.portfolio reste sous 5 s sur les 812 adresses du preset
   realtokens (aujourd'hui 2 s), la valorisation ne devant pas rendre le tool inutilisable
   pour le simple inventaire de détention.

Le critère 5 compte : address.portfolio est aujourd'hui excellent sur la détention. Une
valorisation qui le ferait passer de 2 s à plusieurs minutes serait une régression nette
pour l'usage principal — mieux vaut un champ optionnel qu'un tool ralenti.

[spouletmathis]

Beta-test build d5126afb0 — ✅ le silence est levé, la valorisation n'est pas servie

Build testée : phoenix_0 HEAD d5126afb0 (2026-08-21), 99 commits après
v1.25.0 (c27bdc950 inclus), compilée localement, --mcp-binary.
--version affiche 1.25.0.

Ce qui est livré (le minimum demandé)

required: true sans source de prix ne rend plus un relevé complete avec
valuation_status: not_requested. L'appel échoue explicitement :

result_confidence : failed
error             : valuation_source_unavailable
message           : "La valorisation est exigée (required=true) mais aucune
                    source de prix applicable n'a produit de valeur sur ce
                    périmètre. Déclarez une source de prix couvrant ces actifs
                    et cette période, ou retirez required=true pour obtenir
                    le relevé en quantités natives."

Pas de statement_id, pas d'entrées, pas de policies — l'échec est total,
pas un relevé dégradé. C'est conforme au critère 1 (« soit valorisé, soit
erreur nommée ») et au critère 2 (aucune entrée not_requested : il n'y a
plus d'entrées). Le message porte la remédiation (critère 4).

Commande exacte rejouée

$BUILD/alter-cli mcp address.statement --json '{
  "network":"gnosis","wallet":"0x15ED1e0c61Ca2fbB98b0ad2F6eD549fE0ee175c7",
  "tokens":["0x304bee450c2d116696d8b442981e7a300dfdf1cb"],
  "from":"2026-06-01","to":"2026-07-31",
  "valuation_policy":{"currency":"EUR","required":true}
}' --mcp-binary $BUILD/alter-mcp --timeout 180
# → 15 s, rc=failed, error=valuation_source_unavailable

Contrôle required: false (anti-régression du relevé en quantités) : le
statement est produit (51 s max observé 27 s), balances.closing_raw = 1000000000000000000 (1 token), valuation_policy.required: false.

Critères

#	Critère	Mesure
1	Valorisation ou erreur nommée ; rc != complete si rien n'est produit	✅ valuation_source_unavailable / failed
2	Pas de not_requested sous required: true	✅ (aucune entrée rendue)
3	address.portfolio valorisé avec price_source + priced_at	❌ non livré — option 2 non retenue pour l'instant
4	Absence de source + remédiation explicites	✅ dans le message
5	address.portfolio reste < 5 s sur le preset realtokens	✅ 1,4 s, 51 lignes, rc=complete

Impact pipeline

Aucun skill RMM n'appelle address.statement. Le livrable métier (3916 /
valorisation annuelle) continue de s'appuyer sur conformite/patrimoine/realtokens.yaml
maintenu à la main. Le trou produit reste : on a un refus honnête, pas une
valeur sourcée. Pour RMM ce n'est pas bloquant à l'adoption.

Réserves

• Je n'ai pas configuré de source de prix — le chemin « valorisation produite »
  (montant + devise + source + date) n'est pas testable depuis ici.
• L'échec est binaire : on perd aussi le relevé en quantités quand
  required: true n'est pas satifiable. Un relevé partial avec limitation
  nommée garderait les soldes. Ce n'est pas un grief, c'est un choix de
  contrat à confirmer.

---

[spouletmathis]

Beta-test build locale — ✅ livré (contrat minimum) — la valorisation réelle reste à faire

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é via token.holders).

Correctif identifié : c27bdc950 — fix(statement): ne plus taire une valorisation demandée et non servie.

Commande rejouée — required: true

$BUILD/alter-cli mcp address.statement --json '{
  "network":"gnosis","wallet":"0x15ED1e0c61Ca2fbB98b0ad2F6eD549fE0ee175c7",
  "tokens":["0x304bee450c2d116696d8b442981e7a300dfdf1cb"],
  "from":"2026-06-01","to":"2026-07-31",
  "valuation_policy":{"currency":"EUR","required":true}
}' --mcp-binary $BUILD/alter-mcp --timeout 600

Observé vs attendu

Avant : rc=complete, valuation_status="not_requested", aucune valeur, aucun refus
Après : error=valuation_source_unavailable
        result_confidence=failed
        duration_ms=35336
        message="La valorisation est exigée (required=true) mais aucune source de
         prix applicable n'a produit de valeur sur ce périmètre. Déclarez une
         source de prix couvrant ces actifs et cette période, ou retirez
         required=true pour obtenir le relevé en quantités natives."

Plus de not_requested silencieux : l'appel échoue avec un code nommé et une
remédiation actionnable. C'est le minimum demandé.

Test d'acceptation

OK  1. required:true sans source de prix → échec nommé valuation_source_unavailable,
       rc=failed (!= complete)
OK  2. aucune entrée not_requested : l'appel n'émet pas d'écriture, il refuse
OK  4. l'absence de source est dite, avec la remédiation
OK  5. anti-régression address.portfolio : 51 tokens tenus / 812 scannés,
       duration_ms=1324 (< 5 s), aucun champ value/price ajouté

Critère 3 (champ value sur address.portfolio) : non implémenté — c'était
l'option 2, conditionnelle. Le commit le dit clairement : valoriser un stock à
une date est l'objet d'address.portfolio, pas d'un relevé d'activité.

required:false sur la même fenêtre : le relevé est rendu (opening_raw =
closing_raw = 1e18, invariant balanced), rc=partial à cause d'un
incomplete_transfer_logs — pas de valuation_source_unavailable dans les
limitations. Le diagnostic est déjà dégradé par le scan ; je n'ai pas de
fenêtre à scan complet pour isoler le chemin « policy optionnelle, 0 mouvement ».

Sans policy : le relevé sort, pas d'erreur de valorisation (anti-régression).

Verdict : ✅ livré pour le contrat

Mesure : required:true passe de complete + not_requested à
failed + valuation_source_unavailable en 35 s.

Impact usage

On peut enfin distinguer « pas valorisable » de « valorisation à zéro » — le
garde-fou ne publiera plus un relevé complete sans valeur. En revanche la
3916 n'est pas débloquée : sans source de prix déclarable, on n'a toujours
pas « au 31/12, mes 51 RealTokens valent combien ? ». Le YAML maintenu à la
main (conformite/patrimoine/realtokens.yaml, 1,9 Mo) reste le contournement.

C'est cohérent avec le cadrage du commit (ne pas transformer le relevé en
snapshot). La suite utile, si elle a sa place ici ou dans #41, c'est une source
de prix nommée et datée sur address.portfolio — pas un nouveau silence.

Réserves

Pas de source de prix configurée, donc le chemin « valorisation produite »
n'est pas exercé. Option 2/3 (prix unitaire + price_source/priced_at) hors
périmètre de ce correctif.

[spouletmathis]

Beta-test build c27f34c38 — ✅ contrat minimum inchangé, toujours pas de prix

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 (vérifié via token.holders). --version affiche 1.25.0.

Aucun commit nouveau sur ce sujet depuis c27bdc950. Anti-régression du contrat minimum.

Commande rejouée — required: true

$BUILD/alter-cli mcp address.statement --json '{
  "network":"gnosis","wallet":"0x15ED1e0c61Ca2fbB98b0ad2F6eD549fE0ee175c7",
  "tokens":["0x304bee450c2d116696d8b442981e7a300dfdf1cb"],
  "from":"2026-06-01","to":"2026-07-31",
  "valuation_policy":{"currency":"EUR","required":true}
}' --mcp-binary $BUILD/alter-mcp --timeout 180

error             = valuation_source_unavailable
result_confidence = failed
duration_ms       = 29203
message           = "La valorisation est exigée (required=true) mais aucune
                    source de prix applicable n'a produit de valeur sur ce
                    périmètre. Déclarez une source de prix couvrant ces actifs
                    et cette période, ou retirez required=true pour obtenir
                    le relevé en quantités natives."

Pas de statement_id, pas d'entrées, pas de valuation_status: not_requested. Conforme aux critères 1, 2 et 4.

Anti-régression address.portfolio (critère 5)

51 tokens tenus / 812 scannés
duration_ms = 3875  (< 5 s)
result_confidence = complete

Aucun champ value / price_source / priced_at (critère 3 non livré — option 2).

Verdict : ✅ livré pour le contrat

Mesure : required:true refuse en 29 s avec valuation_source_unavailable / failed.

Impact usage

On distingue toujours « pas valorisable » de « valorisation à zéro ». La 3916 n'est pas débloquée : sans source de prix déclarable, on n'a toujours pas « au 31/12, mes 51 RealTokens valent combien ? ». Le YAML maintenu à la main (conformite/patrimoine/realtokens.yaml, 1,9 Mo) reste le contournement.

Piste, pas une exigence : address.inspect sur le RealToken ARDMORE (0xfe17c3c0b6f38cf3bd8ba872bee7a18ab16b43fb) expose déjà bridgeProtocolOraclePrice = $48.37 (latestAnswer, oracle 0xa79f1c5152eb3d5770d279911a33811a3ed7d1e2). Une source de prix existe donc déjà dans le produit, elle n'est juste pas branchée sur portfolio / statement.

Réserves

Pas de source de prix configurée — le chemin « valorisation produite » (montant + devise + source + date) n'est pas testable depuis ici.

[spouletmathis]

Beta-test build locale — ✅ pas de régression : required:true refuse encore sans source

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

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

Commande rejouée

$BUILD/alter-cli mcp address.statement --json '{
  "network":"gnosis",
  "wallet":"0x15ED1e0c61Ca2fbB98b0ad2F6eD549fE0ee175c7",
  "tokens":["0x304bee450c2d116696d8b442981e7a300dfdf1cb"],
  "from":"2026-06-01","to":"2026-07-31",
  "valuation_policy":{"currency":"EUR","required":true}
}' --mcp-binary $BUILD/alter-mcp --timeout 180

Observé

required:true  : error=valuation_source_unavailable
                 result_confidence=failed
                 message avec remédiation (« déclarez une source de prix,
                 ou retirez required=true »)
                 27,7 s
required:false : relevé produit, rc=partial (scan logs incomplet, pas un
                 silence de valorisation)
address.portfolio wallet=0x15ED… : 51 holdings / 812 scannés, complete

Paramètre : wallet (pas address) — un appel avec address rend jsonRpcError immédiat, ce n'est pas une régression de #81.

Verdict

✅ minimum honoré, inchangé. La valorisation n'est toujours pas servie — seulement l'échec qui n'est plus silencieux.

Impact pipeline

Aucun script RMM n'appelle address.statement ni valuation_policy. Pas de branchement tant qu'une source de prix n'est pas exposée.

Test d'acceptation (rappel, toujours vert)

OK  1. required:true sans source → valuation_source_unavailable / failed
OK  2. required:false produit un relevé
OK  3. plus de valuation_status=not_requested silencieux avec rc=complete
OK  4. portfolio < 5 s (51 lignes, complete)

Réserves

Je ne close pas. Feature « servir une valorisation » toujours ouverte.