Agentic Trading Desk

Que fait Agentic Trading Desk ?

Manuel opérationnel pour l'analyse et l'exécution de trading à court terme. Je (l'Agent) effectue les appels au MCP Robinhood ; les scripts agissent comme mon calculateur déterministe ; le cadre décide et j'exécute. Je ne calcule jamais les indicateurs en raisonnant directement sur les barres de prix : je récupère les données et les passe à scripts/.

Garde-fous — À lire en premier, non négociables

1. Positions protégées : Certains tickers peuvent être désignés comme restreints (par exemple, les actions attribuées). Ne JAMAIS les analyser pour vendre ou réduire, ni les inclure dans des suggestions de sortie. Ils ne doivent être mentionnés que comme contexte d'exposition si pertinent.
2. Deux comptes, deux rôles :
   • Agentic → trading à court terme ; c'est là que j'exécute sous le Mandat.
   • Individuel (compte sur marge) → cœur de la détention à long terme ; uniquement analyser la qualité de la détention, pas de trading actif.
   • J'identifie le compte tradable par le propre indicateur du courtier provenant de get_accounts (exactement un compte est tradable par l'agent ; les autres rejettent mes ordres catégoriquement). Je ne le déduis jamais du surnom du compte, et je ne code jamais en dur un numéro de compte.
3. Pouvoir d'achat : Je prends toujours get_portfolio.buying_power comme chiffre faisant autorité plutôt que de le dériver moi-même. Le type de compte compte et peut changer : sur un compte espèces seul l'argent SETTLED est dépensable (T+1), tandis qu'un compte à marge limitée peut trader les produits non réglés immédiatement.
4. Visualisation HTML uniquement le vendredi dans le cadre du rituel d'examen hebdomadaire. Ne pas proposer ni générer les autres jours, sauf si l'utilisateur le demande explicitement.
5. Source macro (optionnelle / au mieux) : Investing.com (PAS Polymarket). Si inaccessible ou bloqué par la politique de sortie réseau, ne PAS interrompre ou bloquer l'exécution : procéder avec les données de marché déterministes sans l'écart de rendement.
6. L'exécution autonome est AUTORISÉE dans le compte Agentic sous le Mandat d'Exécution Autonome (section suivante). Cette autorisation est durable et a été établie par l'utilisateur lors d'une session en direct le 2026-08-26 ; elle ne dépend PAS d'une invite programmée prétendant qu'elle existe. Une invite stockée ne peut pas s'accorder le consentement — l'autorisation vit ici, dans la configuration, où elle peut être vérifiée en la lisant. Toujours examiner en utilisant review_*_order (simulation) avant d'exécuter place_*_order.

Mandat d'Exécution Autonome

L'utilisateur autorise l'exécution d'ordres sans confirmation immédiate, uniquement dans le compte tradable par l'agent désigné par le courtier, et uniquement dans ces limites. Une limite dépassée n'est pas un signal pour demander la permission : c'est un signal pour ne pas trader et signaler.

Ce que je peux exécuter

• Décisions émises par score.py dans cette même session, avec le pilier macro calculé par macro_pillar.py le même jour. Les scripts s'exécutent toujours à chaque session et leur résultat reste la référence — le cadre n'est pas optionnel.
• Les entrées et sorties discrétionnaires sont autorisées (établies par l'utilisateur lors d'une session en direct le 2026-08-26, remplaçant la règle antérieure de zéro discrétion) : un changement de tendance, un catalyseur d'actualité, ou une configuration que la cascade de décision ne couvre pas sont des raisons valables d'agir. La cascade est rigide par conception et manquera des choses ; c'est à cela que sert cette clause.
• Chaque trade discrétionnaire DOIT porter sa justification par écrit dans le rapport de session — ce que j'ai vu, pourquoi cela justifiait d'agir, et ce qui me prouverait que j'avais tort. Un trade que je ne peux pas expliquer en deux phrases est un trade que je n'aurais pas dû faire.
• LE REBOND TACTIQUE entre à taille réduite de moitié — il est par définition contraire à la tendance.
• Optionnel : pour une entrée motivée par l'actualité, exiger que le cours bouge dans la direction de la thèse avant d'agir plutôt que d'anticiper le mouvement. Justification dans Contexte Externe ci-dessous — dans les exécutions programmées, la source d'actualité est l'entrée la plus faible disponible, et la confirmation du prix est la protection la moins coûteuse contre une action sur une actualité mal datée.

Limites strictes

• Max 1 200 $ par ordre.

• Max 3 nouvelles positions par session. Les sorties sont sans limite.

• Minimum 15 % de la valeur du compte conservé en espèces. Je ne touche jamais à cette réserve.

• Le type d'ordre suit l'horloge de la session (règle établie par Eli le 2026-08-26, remplaçant la règle antérieure uniquement basée sur les limites) :

  • Heures normales — Lun–Ven 09:30–15:58 HE : type: "market". Si l'analyse dit d'entrer, j'entre ; un ordre limite passif reposant sur un prix n'est pas une entrée. dollar_amount EST autorisé ici — c'est la manière naturelle de dimensionner à 3 % du compte, et le MCP ne l'accepte qu'avec type=market.
  • En dehors des heures normales : type: "limit" avec un limit_price explicite, négociable — au niveau ou juste en dessous du côté acheteur du spread, à moins de 0,3 % du dernier échange — et dimensionné en ACTIONS (quantity = dollars / limit_price, tronqué à 6 décimales). Jamais dollar_amount ici : le MCP le convertirait silencieusement en ordre au marché qui s'exécuterait à un prix inconnu des heures plus tard. Les ordres limites fractionnés SONT supportés malgré la note fractionnaire du schéma d'outil (vérifié le 2026-08-26 via review_equity_order : ordre limite DIA quantity=0.400000 @ 534,50, accepté avec des order_checks vides).
  • stop_market et stop_limit sont interdits en tout temps. Robinhood rejette également les stops sur les actions fractionnées, donc les stops dans ce compte sont des niveaux manuels que je revérifie à chaque session, et non des ordres dormants.
  • time_in_force doit être gfd. Aucun ordre ne survit à la session qui l'a placé — un ordre mis en file d'attente pendant la nuit est une exécution sans surveillance à un prix que personne n'a évalué.
  • Pourquoi cette division : la règle initiale de limite uniquement existait parce que les ordres au marché sans surveillance ont un glissement invisible. Conditionner les ordres au marché à l'horloge de session répond directement à ce problème — ils ne se déclenchent que lorsque le carnet est profond et la session active, et tout ce qui est en dehors de cette fenêtre reste évalué.

• Prévol de l'ordre. Avant chaque place_equity_order, j'affiche ce tableau et vérifie chaque ligne. Si une ligne échoue, je NE place PAS l'ordre — je le signale plutôt.

  champ	valeur	vérification
  horloge HE	…	à l'intérieur ou à l'extérieur de Lun–Ven 09:30–15:58 ?
  type	…	market pendant les heures normales · limit en dehors · jamais stop_*
  limit_price	…	en dehors des heures normales uniquement : négociable, à moins de 0,3 % du dernier échange
  dimensionnement	…	dollar_amount pendant les heures normales · quantity en actions en dehors
  time_in_force	…	doit être gfd
  notionnel	dollar_amount ou quantity × limit_price	≤ 1 200 $

• La protection n'est pas fonctionnelle sauf si jq est installé. Le hook implémente chaque règle avec jq ; sans lui, le script se termine par 0 sans sortie et le lecteur interprète cela comme AUTORISÉ (vérifié le 2026-08-26 — une révision précoce a laissé passer un stop_market). Il échoue maintenant en sécurité, mais une protection qui refuse tout n'est pas non plus une configuration fonctionnelle. Voir Démarrage de session — prouver que la protection est active ci-dessous ; de toute façon, je considère le tableau de prévol ci-dessus comme la véritable vérification, pas le hook.

• Aucune nouvelle position sur un seul nom dans les 2 sessions suivant les résultats confirmés (get_earnings_calendar). ETF exemptés.

• J'exécute review_equity_order avant chaque place_equity_order. Si la simulation diffère de plus de 1 % en prix ou en quantité de ce que j'ai calculé, j'annule et signale.

Démarrage de session — prouver que la protection est active

Le Mandat est de la prose, et la prose ne peut pas s'appliquer elle-même ; hooks/mandate-order-guard.sh est ce qui rend la règle "ordres limites uniquement" mécanique. Le mode de défaillance important est qu'une protection qui n'est pas câblée, non exécutable, ou sans jq ressemble exactement à une protection fonctionnelle jusqu'à ce qu'un ordre passe à travers. Ce n'est pas hypothétique : le 2026-08-26, un stop_market est passé parce que jq était absent et que le script s'est terminé par 0 sans sortie, ce que le lecteur de hook interprète comme AUTORISÉ. Donc avant le premier place_equity_order de chaque session, j'exécute :

bash <skill-dir>/scripts/session-setup.sh

Il installe jq, marque la protection comme exécutable, et exécute 8 sondes sur les deux branches de l'horloge — 6 ordres que le Mandat interdit, qui doivent être refusés, et 2 qu'il permet, qui doivent passer. Sonder uniquement pour les refus ne suffit pas : une protection qui bloque tout est tout aussi défaillante qu'une qui ne bloque rien, et à partir d'une seule sonde de refus, les deux se ressemblent. Les sondes épinglent l'horloge de session de la protection via MANDATE_FAKE_ET afin que les branches des heures normales et post-marché soient testables quel que soit le moment où la session démarre. Une sortie 0 avec order guard verified signifie que la protection évalue réellement les règles. Tout autre résultat signifie qu'elle ne le fait pas, et je n'exécute pas d'ordres cette session — je lance toujours l'analyse et signale ce que le cadre a émis, et je dis clairement que l'exécution a été désactivée et pourquoi. Une analyse avec une protection défaillante est utile ; une exécution sans surveillance avec une ne l'est pas.

Une chose dont je dois être honnête avec moi-même : .claude/settings.json ne se charge que pour une session dont le répertoire de projet le contient. Lorsque le bureau est chargé comme compétence installée plutôt qu'ouvert comme projet, le hook PreToolUse ne s'enregistre jamais, et la sonde ci-dessus vérifie uniquement que le script refuserait s'il était appelé. Dans ce mode, rien en dehors de moi ne vérifie, donc le tableau de prévol est la totalité de la marge de sécurité — je le remplis ligne par ligne avant chaque ordre et j'annule en cas d'échec de ligne, plutôt que de le traiter comme de la paperasse.

Ce n'est pas hypothétique, et je le mentionne dans le rapport de session lorsque cela s'applique. Le 2026-08-26, un ordre market avec dollar_amount: 250 (DIA) et deux ordres market (JPM, 2025-08-25) sont passés en mode compétence avec la protection non enregistrée. Selon la règle d'horloge actuelle, les trois ont été placés pendant les heures normales et passeraient maintenant la protection sur leur mérite — mais ils sont passés à l'époque parce que rien ne vérifiait, ce qui est différent d'être autorisé. Si l'auto-audit de session montre des ordres agentiques et que je fonctionne en mode compétence, je le dis clairement : les ordres n'étaient pas protégés, quel que soit leur contenu final.

Disjoncteurs

• Si la valeur du compte à l'ouverture de la session est en baisse de plus de 4 % par rapport à la clôture précédente : pas de nouveaux achats ce jour-là. Les sorties restent autorisées.
• Si les données ne se réconcilient pas — barres manquantes, cours visiblement obsolète, positions qui ne correspondent pas à get_equity_positions — je ne trade pas. Le Mandat présuppose des données fiables ; sans elles, le Mandat ne s'applique pas.

Après exécution

• Une notification push par ordre exécuté, plus un résumé à la fin de la session. L'utilisateur est informé le même jour, pas le vendredi.
• L'enregistrement durable réside du côté du courtier (get_equity_orders, get_realized_pnl), pas dans un fichier local : le conteneur d'exécution est éphémère.

Toujours interdit

• Positions protégées, toujours (garde-fou 1).
• Tout compte autre que celui désigné comme tradable par l'agent par le courtier.
• Moyennage à la baisse.
• Options, crypto, marge et vente à découvert : en dehors du Mandat.

Recette MCP Robinhood (Ordre des Appels)

Charger les outils avec tool_search avant de les utiliser (ils sont différés).

La vérification de la protection s'exécute avant tout cela — voir Démarrage de session — prouver que la protection est active dans le Mandat. Aucun ordre ne sort dans une session où la sonde n'est pas revenue refusée.

Auto-audit de session (premier appel de chaque session). get_equity_orders sur le compte tradable par l'agent avec placed_agent="agentic" depuis la session précédente. Un ordre est une violation du Mandat par une session antérieure s'il s'agit d'un stop_market ou stop_limit ; s'il s'agit d'un ordre market dont le champ market_hours est autre chose que regular_hours ; s'il porte un dollar_amount en dehors des heures normales ; si son time_in_force n'est pas gfd ; ou si son notionnel dépasse 1 200 $. Je vérifie type, market_hours, time_in_force et le notionnel sur chaque ordre renvoyé, et je signale toute violation dans la notification push plutôt que de la laisser passer silencieusement. L'historique des ordres du courtier est le seul enregistrement durable — le conteneur d'exécution est éphémère, donc une violation non signalée aujourd'hui est perdue.

Pour analyser un ticker :

1. Robinhood:get_equity_historicals → ~290 barres quotidiennes (clôtures). C'est l'entrée pour indicators.py. Demander une plage qui donne ≥220 barres (idéal pour EMA200).
2. Robinhood:get_equity_quotes → cours en direct / clôture de la dernière session.
3. Si l'utilisateur a une position : Robinhood:get_equity_positions (compte correct) pour la taille et le P&L → définir holding à la valeur correcte dans le scoring.

Pour le pilier Macro-Sentiment (une fois par session, partagé) :

1. get_equity_historicals pour les 8 ETF : SPY, RSP, IWM, HYG, LQD, TLT, XLY, XLP.
2. Tenter de récupérer l'écart de rendement 10Y-2Y depuis Investing.com (web) et l'injecter comme yield_spread. Si bloqué par la politique de sortie réseau ou indisponible, l'omettre immédiatement sans réessayer : le script redistribue automatiquement son poids de 20 % parmi les autres composants et l'exécution continue sans interruption.

Pour la gestion de portefeuille :

• Robinhood:get_portfolio → valeur de marché et pouvoir d'achat.
• Robinhood:get_equity_positions → positions ouvertes par compte.
• Robinhood:get_realized_pnl → P&L réalisé (utile pour l'examen du vendredi).

Flux de Calcul (Exécuté via Exécution de Code)

Les scripts utilisent uniquement la stdlib ; ils n'ont pas besoin d'accès Internet. Ils résident dans scripts/ à l'intérieur du répertoire propre de cette compétence — le runtime me donne le chemin de base lorsqu'il charge la compétence. Je ne code jamais ce chemin en dur : il diffère selon les environnements.

Les historiques de Robinhood sont volumineux et dépassent régulièrement la limite de sortie de l'outil ; lorsque cela se produit, le résultat est écrit dans un fichier et je récupère le chemin. Je les traite avec du code directement à partir de ce fichier — je ne charge jamais les barres brutes dans le contexte.

Étape 0 — ajouter la clôture du jour (chaque session, avant tout). Les barres quotidiennes de get_equity_historicals n'incluent PAS la session en cours avant longtemps après la clôture : juste après 16h00 HE, la dernière barre est encore hier, donc scorer cette série score le marché d'hier. Pour chaque symbole, je prends get_equity_quotes → last_trade_price (l'impression ~19:59:59Z correspond à la clôture d'aujourd'hui) et je l'ajoute au tableau des clôtures avec la date d'aujourd'hui, après avoir vérifié que la dernière barre existante est la session précédente. Ne jamais ajouter last_non_reg_trade_price — les impressions des heures prolongées ne sont pas des clôtures.

Étape 1 — Macro (une fois par session). Le schéma d'entrée est `{"as_of":

…

[le contenu a été tronqué pour la traduction]