Repository navigation
docs: plan de passage en réel, runbook d'exploitation et statut de la phase 0 - #92
Conversation
…/long terme) Analyse du run démo T212 n°2 (03/09 → 29/09) : verdict NO-GO réel en l'état, constat chiffré par modèle et par règle de sortie, plan en 5 phases (hygiène → backtest walk-forward → refonte moyen terme → démo de conformité → réel progressif). Aucun code modifié. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
| | Take-profit | +8 % (`TAKE_PROFIT_TARGET`) | Plafonne chaque gain à 8 %. Le TP attaché chez le broker est **rejeté (400) à chaque achat** (3/3) : c'est du code mort qui provoque un double POST. | | ||
| | Trailing stop logiciel | −3 % depuis le pic, dès +0,5 % de gain | CRUDP a une volatilité quotidienne de 1,9 à 3,5 % : **moins d'un écart-type d'une séance**, donc déclenchement quasi certain. SXRV (1,1 %) : environ 3 σ, déclenché en quelques semaines. | | ||
| | Time-stop | 15 jours calendaires (`MAX_HOLDING_DAYS`) | **Force la vente même si la position est en gain.** Incompatible avec un horizon de plusieurs mois. | | ||
| | Garde anti-perte | bloque tout SELL de modèle en dessous de −0,2 % | **18 ventes bloquées.** Les perdants sont conservés jusqu'au hard-stop −10 %. Asymétrie inverse du principe « couper les pertes, laisser courir les gains ». La tolérance de 0,2 % est aussi plus étroite que le spread réel (le 24/09 : valeur affichée 1 005,82 €, fill à 1 002,51 €, soit 0,33 %). | |
There was a problem hiding this comment.
WARNING: Analyse inexacte : la garde anti-perte ne garde pas « les perdants jusqu'au hard-stop −10 % »
_execute_sell_order contourne _check_sell_loss_guard quand force_stop_loss=True (src/t212_executor.py:1720-1726), et _evaluate_time_stop renvoie ("SELL", True) dès que la position dépasse MAX_HOLDING_DAYS tant que le drawdown n'excède pas TIME_STOP_SOFT_LOSS (src/t212_executor.py:1226-1230). Concrètement : une position à −3 % est donc vendue au 15e jour par le time-stop, garde ou pas. Le tableau de la section 1.3 surestime l'asymétrie « on garde les perdants » et sous-estime le poids réel du time-stop (que la ligne suivante décrit pourtant correctement). Corriger la cellule, sinon la phase 2.3 (« supprimer le time-stop »)appears comme le seul levier alors que la garde en est un second.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
| **2.3 Règles de sortie cohérentes avec le moyen terme** | ||
| - **Supprimer le take-profit fixe à +8 %.** | ||
| - **Supprimer le time-stop de 15 jours**, ou le remplacer par une sortie « tendance cassée ET aucun progrès depuis N semaines ». | ||
| - **Supprimer la garde anti-perte** sur les sorties de régime : une sortie est décidée par une règle, pas par le P&L latent. |
There was a problem hiding this comment.
WARNING: Supprimer toute la garde anti-perte supprime aussi une protection documentée contre les prix d'entrée corrompus
La garde n'est pas qu'un filtre de P&L latent : d'après son propre docstring et _validate_and_recalibrate_entry_price (src/t212_executor.py:170-215), elle protège contre une référence d'entrée fantôme/corrompue qui faisait passer une vente à perte pour une vente à profit (incident de juin 2026, drift à −17 %). La supprimer entièrement en phase 2, sans mécanisme de remplacement, rouvre cette classe de bug. Préférer : neutraliser la garde uniquement pour les sorties de régime (exemptions explicites par exit_reason), et conserver un contrôle de cohérence entrée/valeur avant tout POST de vente.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
|
|
||
| | Règle | Paramètre | Effet pour du moyen/long terme | | ||
| |---|---|---| | ||
| | Take-profit | +8 % (`TAKE_PROFIT_TARGET`) | Plafonne chaque gain à 8 %. Le TP attaché chez le broker est **rejeté (400) à chaque achat** (3/3) : c'est du code mort qui provoque un double POST. | |
There was a problem hiding this comment.
SUGGESTION: « code mort » est inexact et contredit AGENTS.md
L'attachement takeProfit n'est pas du code mort : il y a un repli délibéré sur un ordre nu au 400 (src/t212_executor.py:1371-1376), et AGENTS.md documente cet attachement + fallback comme une garantie GO-gate 2. Le constat « 400 systématique sur 3/3 achats en démo » est pertinent, mais l'action 0.7 devrait être formulée comme « l'API live n'accepte pas takeProfit sur un ordre au marché, à confirmer avant réel », sinon on supprime une protection broker-side encore active sur d'autres endpoints.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (2 files)
Resolved since previous reviewLes 3 constats précédents sont corrigés : le tag Previous Review Summaries (2 snapshots, latest commit fafcf79)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit fafcf79)Status: 3 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (2 files)
Resolved since previous reviewLes 3 constats précédents sont corrigés : la garde anti-perte est désormais décrite comme ne bloquant que les ventes de modèles (hard-stop et time-stop la contournent bien, Fix these issues in Kilo Cloud Previous review (commit 97e97c4)Status: 3 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (3 files)
Reviewed by free · Input: 0 · Output: 0 · Cached: 0 |
…se 0 - docs/RUNBOOK_EXPLOITATION.md : séparation PROD/DEV par tag, installation du watchdog, arrêt et reprise propres, vérifications rapides ; - plan : §6 avancement de la phase 0 (PR #93 à #98), diagnostic du modèle sentiment (quota Alpha Vantage + filtre de ticker, volontairement non réparé), vérification de la doc T212 en réel ; - memory-bank : entrées log.md et progress.md. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
laurentvv
changed the title
… décision - §1.3 : la garde anti-perte ne bloque que les ventes décidées par les modèles (le time-stop et le hard-stop la contournent) ; « code mort » du takeProfit reformulé ; - §2.3 : garde anti-perte neutralisée pour les sorties de régime seulement, conservée comme contrôle de cohérence du prix d'entrée (incident de juin 2026) ; - §7 (nouveau) : piliers du système de décision (hypothèse à valider en phase 1) et constat complémentaire sur la fenêtre sans stop lors d'une vente non exécutée. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
| |---|---|---|---|---| | ||
| | 1 | **Filtre de tendance et de régime** | Grebenkov, HMM (uniquement comme détecteur de régime de volatilité) + règles simples (MA200, momentum 3-12 mois, drawdown en cours) | Décide le **niveau d'exposition** (0 / 25 / 50 / 75 / 100 %), pas chaque achat ou vente | Seul composant qui avait raison sur la période (Grebenkov : achat 25 jours sur 27 sur un marché haussier). Déterministe, backtestable sur 5 ans, et référence naturelle que tout autre pilier doit battre. | | ||
| | 2 | **Couche de risque et d'exécution** | GO-gates 1 à 7 : idempotence des ordres, fill confirmé, stop GTC à cliquet chez le broker, volatilité quotidienne, garde de fraîcheur des données, verrou du scheduler, equity FIFO ; puis watchdog et régulateur d'appels | Protège le capital **même quand les modèles se trompent** | C'est le vrai acquis du projet. Il a déjà résisté à des incidents réels (vente bloquée par un stop réservé, FIFO antéchronologique, état broker inconnu). Sur 30 k€, la survie passe avant la performance. | | ||
| | 3 | **Prévision quantitative de moyen terme** (candidat) | TimesFM 3.0 (via ses quantiles) et le modèle classique (cible à 20-60 jours) | Confirmation et **dimensionnement** (probabilité de hausse, dispersion), pas un signe directionnel brut | Pas un pilier en l'état : TimesFM vend dans 84 à 93 % des cycles sur une autre série que celle tradée, le classique vise le lendemain. À garder seulement s'ils battent la règle simple hors échantillon. | |
There was a problem hiding this comment.
WARNING: Cible du modèle classique incohérente avec le code et avec le reste du document
La colonne « Composants existants » annonce « le modèle classique (cible à 20-60 jours) », mais la colonne « Pourquoi » de la même ligne dit « le classique vise le lendemain », et le §1.2 (ligne 47) ainsi que src/features.py:203 (df["Target"] = np.where(df["Returns"].shift(-1) > threshold, 1, 0)) confirment une cible à 1 jour. Le §1.2 conclut d'ailleurs que « l'horizon de 1 jour est du bruit ».
Comme ce tableau sert d'hypothèse de travail pour le banc de la phase 1, y déclarer un composant existant « cible à 20-60 jours » sans que ce soit implémenté conduirait à tester une cible que le code ne produit pas. Soit corriger en « cible à 1 jour », soit expliciter que la cible 20-60 jours est à créer en phase 2.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
|
|
||
| | # | Pilier | Composants existants | Rôle | Pourquoi | | ||
| |---|---|---|---|---| | ||
| | 1 | **Filtre de tendance et de régime** | Grebenkov, HMM (uniquement comme détecteur de régime de volatilité) + règles simples (MA200, momentum 3-12 mois, drawdown en cours) | Décide le **niveau d'exposition** (0 / 25 / 50 / 75 / 100 %), pas chaque achat ou vente | Seul composant qui avait raison sur la période (Grebenkov : achat 25 jours sur 27 sur un marché haussier). Déterministe, backtestable sur 5 ans, et référence naturelle que tout autre pilier doit battre. | |
There was a problem hiding this comment.
WARNING: Le HMM n'est pas un détecteur de régime de volatilité
src/hmm_model.py discrétise des rendements (−0,5 % / neutre / +0,5 %, _discretize_returns) et renvoie un signal directionnel BUY/SELL selon l'état haussier (Viterbi + _identify_bullish_state). Rien dans le code ne l'utilise comme détecteur de volatilité, et le §1.2 (ligne 47) le relève d'ailleurs comme « BUY 13, SELL 13 ».
Décrire le HMM comme « détecteur de régime de volatilité » dans les « composants existants » est donc inexact et risque d'orienter le banc de la phase 1 vers un usage (filtrage de volatilité) que le modèle ne sait pas faire aujourd'hui.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
|
|
||
| # 2. Cloner PROD à côté (sur un tag validé, jamais sur une branche de travail) | ||
| git tag prod-2026-09-30 # tag posé sur un main validé | ||
| git clone --branch prod-2026-09-30 https://github.com/laurentvv/Trading-AI.git C:\GIT\Trading-AI-prod |
There was a problem hiding this comment.
WARNING: Le git clone --branch prod-2026-09-30 échoue : le tag n'est jamais poussé
L'étape 2 crée le tag en local (git tag prod-2026-09-30, ligne 30) puis clone depuis l'URL GitHub. Sans git push origin prod-2026-09-30, le tag n'existe pas sur le remote et git clone --branch sort en erreur (« Remote branch prod-2026-09-30 not found »), ce qui bloque la mise en place du dossier PROD décrite en §2.
Il manque également un git checkout main explicite avant le git tag : sans argument, le tag est posé sur le HEAD courant, qui peut être une branche de travail — ce que le commentaire « tag posé sur un main validé » suppose sans l'assurer.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
…assique) + avancement phase 1 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Résumé
Analyse du run démo T212 n°2 (03/09 → 29/09/2026) et plan en 5 phases pour un passage en réel (30 k€, horizon moyen/long terme).
docs/PLAN_AMELIORATION_PASSAGE_REEL_2026-09-29.md: verdict NO-GO réel en l'état, constat chiffré par modèle de décision et par règle de sortie, phases 0 → 4, et §6 : avancement de la phase 0 (PR test: isoler chaque test dans un CWD temporaire (plus d'écriture dans la base du démo) #93 à feat(ops): watchdog d'exploitation (scheduler mort/bloqué, position sans stop, alertes, relance) #98, diagnostic du modèle sentiment, vérification de la doc T212 en réel).docs/RUNBOOK_EXPLOITATION.md: séparation PROD/DEV par tag, installation du watchdog, arrêt et reprise propres.memory-bank/log.mdetprogress.mdmis à jour.Aucun code modifié.
PR liées (phase 0)
#93 isolation des tests · #94 FinAcumen · #95
takeProfit· #96 limites d'appels T212 · #97 journal d'audit · #98 watchdogTest plan
🤖 Generated with Claude Code