La machine qui trade à midi

Le marché et sa langue

1.1 · Qu'est-ce qu'un marché ?

1.2 · La bougie OHLC

1.3 · Long vs Short

1.4 · Le compte : NAV, equity, P&L

1.5 · Bid / Ask / Spread

1.6 · Le ticker et ses dialectes

_IB_EXCHANGE_TO_YAHOO = {
    "SBF":  ".PA",   # Euronext Paris
    "IBIS": ".DE",   # Frankfurt / Xetra
    "AEB":  ".AS",   # Euronext Amsterdam
    "LSE":  ".L",    # London Stock Exchange
    ...
}                    # bourse US → pas de suffixe

Ce qu'il faut retenir

Ordres & exécution IB

2.1 Le chemin d'un ordre

2.2 Types d'ordres : mange le carnet toi-même

2.3 La machine à états IB — PendingSubmit ne prouve RIEN

2.4 Le bracket atomique (A3) — vis l'incident

2.5 Trailing stops — le filet qui survit au crash

2.6 Preflight & valeurs piégées

Rappel actif — verrouille le module

Risque, sizing & frais

Au module 02 tu as vu les mains de la machine — les ordres, les brackets, les statuts IB. Ici, son bouclier. Deux chiffres pour comprendre pourquoi ce module existe : 374 % de levier atteint un jour de mai par accident, et -13 % de capital jamais déployé pendant des mois — en silence, sans un seul log. La leçon centrale de l'industrie comme de Precision Ledger : ce n'est presque jamais le mauvais signal qui tue un compte, c'est la mauvaise taille. Et un bug de risque ne crashe pas — il sous-performe en silence.

3.1 — Le sizing tue avant les mauvais signaux

Avant toute formule, un duel. Prédis le gagnant — c'est la règle ici : on parie d'abord, on regarde ensuite.

Le win rate seul ne dit rien : ce qui compte est le produit fréquence × taille relative des gains. C'est exactement pourquoi le ranker de Precision Ledger note l'asymétrie RR comme premier des 5 axes du scoring pointwise (module 05) — un dossier n'est bon que si ce qu'on peut gagner dépasse nettement ce qu'on risque. Le gate A1 du système refuse d'ailleurs tout trade avec un ratio RR < 2.

3.2 — Monte-Carlo : voir la ruine avant de la vivre

Question piège : un système gagnant peut-il te ruiner ? Oui — si la taille de position est trop grosse. Une seule courbe d'equity est une anecdote ; pour voir le risque, il faut rejouer le même système des centaines de fois. C'est le principe du Monte-Carlo : 500 vies parallèles du même trader.

3.3 — Le sizing vol-target (A2) : la volatilité comme budget

Question d'ouverture : le book contient NVDA (volatilité ~45 %/an) et KO (~12 %/an). Si on met le même montant sur chacun, NVDA portera presque 4 fois plus de risque. Comment les dimensionner pour qu'ils portent le même poids de risque ? Réponse du système : penser le risque comme un budget de courses. NVDA coûte cher au kilo de risque — on en met moins dans le panier. C'est le sizing vol-target (agents/risk_engine/sizing.py, pur NumPy, testable sans I/O).

Les vrais paramètres de size_book_long_short : budgets de vol séparés long 18 % / short 8 % annualisés (asymétrie volontaire : la perte d'un short n'est pas bornée et il paie un loyer d'emprunt), σ floor 10 % (aucun titre n'est traité comme « sans risque » — ici KO à 9 % est remonté à 10 %), cap par titre ×1.6 l'equal-weight (≈ 22.8 % pour N=7 : un gagnant style NVDA ne peut pas absorber le book), floor ×0.5, et surtout scale ≤ 1.0. Pondération par conviction : score_i/100 issu du pointwise. Un drift relatif ≥ 15 % d'un poids déclenche un rebalance (flag ROTATION_REBALANCE_ENABLED, en shadow).

3.4 — Le circuit de drawdown (A5) : le disjoncteur

Qui a le droit d'arrêter la machine ? Pas un humain qui regarde un écran — un disjoncteur, comme dans une maison : il ne demande pas pourquoi le courant grimpe, il coupe. Le drawdown (la baisse depuis le plus haut) est mesuré en continu par drawdown_circuit.py (cron toutes les 10 min, calculé en EUR sur portfolio_snapshots) et traduit en régime qui multiplie la taille de tout nouveau trade.

Note d'histoire : la pause était à -5 % jusqu'au 2026-06-04. Sur un book corrélé à l'indice (β ≈ 1), un -5 % est une correction de marché ordinaire, pas un signal que les agents se trompent — à ce seuil, le circuit affamait la rotation à ~30 % investi. Desserré à -7 %, le kill reste à -8 %. Le seuil 200 % vient directement de l'incident du 2026-05-06 : 374 % de levier en paper (module 02).

3.5 — Le gate A1 et le bug de devise

Dernier rempart avant l'ordre : le gate A1, core.evaluate_trade(req, ctx) → RiskDecision, appelé en tout premier dans worker.py avant tout le reste. Il compose le régime A5, les gates shorts A6, le sizing A2, et vérifie RR ≥ 2, la liquidité, la corrélation, le plafond de borrow. Chaque évaluation — acceptée ou rejetée — écrit une ligne d'audit dans la table risk_audit (payload JSONB, 6 indexes).

Maintenant, le bug le plus instructif du projet. Le compte IB DUQ133771 est en euros ; les titres cotent en dollars. Pendant des mois, le sizing a divisé un NAV en EUR par des prix en USD. Prédis l'impact sur le déploiement du capital :

3.6 — Les frais : l'ennemi silencieux

Une rotation quotidienne, ce sont des ordres tous les jours — et chaque ordre paie un péage : commission broker, taxes réglementaires (SEC, FINRA) sur les ventes, et pour les shorts un loyer d'emprunt quotidien. Individuellement dérisoires ; cumulés, c'est de la limaille dans le moteur. Combien sur un an ? Manipule :

Dans le système, tout cela vit dans fees_ledger (Task 018) : un journal append-only de tous les frais — commission ib_real, taxes reg_sec/reg_finra, borrow estimated (accrual quotidien, cron 02:30 UTC, sur watchlist ∪ shorts ouverts). Point crucial : c'est du tracking pur. Le ledger ne modifie NI le NAV NI le realized_pnl — IB déduit déjà la commission du P&L ; la re-soustraire serait du double comptage.

3.7 — Les gates shorts (A6) : le permis spécial

Pourquoi shorter exige-t-il un contrôle technique à part ? Parce que la perte d'un short n'est pas bornée (module 01) et qu'un short squeeze — quand tous les vendeurs à découvert doivent racheter en même temps — peut tripler un titre en quelques jours (GameStop 2021). short_gates.py filtre en deux étages : Tier 1, binaire (un seul critère suffit à bloquer) : liste Reg SHO ≥ 5 jours consécutifs, earnings dans ≤ 10 jours, achats nets d'initiés ≥ 5 M$ sur 30 j (on ne shorte pas contre ceux qui savent), flag hard-to-borrow d'IB. Tier 2, composite squeeze (il faut ≥ 2 signaux sur 4 pour bloquer) : short interest ≥ 7 % du flottant, days-to-cover ≥ 3 (volume 10 j), borrow ≥ max(1 %, 2× la médiane de l'univers), utilization ≥ 90 %. La leçon des post-mortems GameStop est dans le code : le signal tueur était la convergence des quatre, pas un seul — un OR plat aurait produit des milliers de faux positifs.

Détail qui en dit long : l'ancien gate « flottant < 20 M d'actions » a été supprimé au pivot large-cap (2026-05-26) — sur un univers ≥ 5 G$ il ne se déclenchait jamais. Un gate qui ne peut jamais tirer n'est pas un garde-fou, c'est du code mort qui rassure à tort.

Ce qu'il faut retenir

Le fil rouge : l'edge décide quoi trader, le risque décide combien — et c'est le combien qui fait survivre. Quiz de validation (≥ 80 % pour déverrouiller le module 04) :

Le cerveau multi-agents

4.1 · Pourquoi pas un humain ? Les biais comme bug

4.2 · Le graphe d'agents : une salle d'audience par titre

4.3 · Quel modèle pour quel rôle

4.4 · La mémoire : RAG sur Qdrant

Ce qu'il faut retenir

La rotation top-N

Chaque jour ouvré à 12:00 UTC, 512 titres se présentent à la porte. Le soir, il en reste 9 dans le portefeuille. Ce module démonte la machine qui fait ce tri — le cœur de l'ADR 0006 V2 : un entonnoir quantitatif, un jury de 5, un tournoi de 810 duels, et des garde-fous nés chacun d'une perte réelle. C'est ici que vit l'edge du fonds : non pas « trouver l'info avant les autres », mais front-loader le raisonnement LLM sur des dossiers riches, puis classer ces dossiers avec une rigueur statistique qu'un humain n'a pas.

5.1 · L'entonnoir : 512 → 50 → 25/15 → 7+2

Avant de voir le schéma, prédis : sur les 512 titres de l'univers, combien finissent réellement dans le book chaque jour ?

5.2 · Stage 1 — le jury de 5 (pointwise)

Question d'ouverture : si tu demandes à un même LLM de noter un dossier sur 100, deux fois de suite, obtiens-tu la même note ? Non — et le système ne nie pas ce bruit, il le traite statistiquement. Le scoring pointwise (ranker/pointwise_scorer.py) pose k=5 fois la même question (self-consistency) et garde la médiane des 5 notes, sur 5 axes : asymétrie RR, force du catalyst, forecast Chronos, technique, sentiment. L'ordre de présentation des éléments est permuté à chaque sample pour neutraliser le biais de position (un LLM favorise ce qu'il lit en premier). Les notes sont ensuite normalisées en rank-z par book.

5.3 · Stage 2 — le tournoi de duels + Bradley-Terry

Noter 25 dossiers de 0 à 100, c'est dur et bruité. Dire lequel de DEUX dossiers est meilleur, c'est facile. Le Stage 2 (ranker/pairwise_duels.py) ne demande au LLM que des duels : un round-robin complet double passe (A vs B, puis B vs A — encore l'anti-biais de position). Reste à transformer des centaines de réponses « A bat B » en un classement : c'est le modèle Bradley-Terry (ranker/bradley_terry.py, MLE NumPy maison, algorithme MM de Zermelo-Ford). Avant la formule, joue le tournoi toi-même — tu ES le juge LLM.

Le compte exact : 25 longs × 24 adversaires = 600 duels, 15 shorts × 14 = 210, soit 810 duels/run en mode full. Chaque duel = 1 appel LLM (Sonnet 4.6, abonnement — coût marginal nul). Le mode seeded (ranker/pairwise_schedule.py, flag PAIRWISE_SCHEDULE_MODE) tombe à ~144 duels (÷5.6) : une épine dorsale connexe + une clique concentrée à la frontière rang-K/(K+1) — là où se joue la sélection — avec des ancres déterministes sha256(run_id:book_side).

5.4 · La sélection et ses garde-fous

Le classement est fait. Pourquoi ne pas simplement prendre le top-7 chaque jour ? Parce qu'un titre qui oscille entre rang 7 et rang 8 ferait un aller-retour par jour — et chaque aller-retour coûte (commissions, spread, slippage — module 03). portfolio_builder.py assemble le book (F4 tri bt_score, F5 cap secteur 2/secteur, F6 sizing vol-target, F7 cash mode : < 4 longs valides → cash partiel, jamais un 7/7 forcé), puis rotation_orchestrator.py applique quatre amortisseurs :

Détail qui a coûté cher : l'hystérésis travaille en rangs absolus, jamais en pourcentage d'un score — un buffer multiplicatif est mathématiquement mal défini quand le score est signé ou proche de zéro (L34). Seul un forced exit (stop touché, choc news) passe outre min-hold et hystérésis — et déclenche alors le cooldown.

5.5 · L'exécution : du classement aux ordres

À toi de jouer l'orchestrateur. rotation_executor.py ne reçoit pas « un classement » mais un diff : book cible vs book courant → ENTER / EXIT / HOLD. Chaque ordre passe le gate A1 (module 03) puis part au bridge en direct — il n'écrit pas trade_proposals (L37). Trois kill-switches étagés : ROTATION_ENABLED (maître), ROTATION_EXEC_ENABLED (ordres réels), ROTATION_DRY_RUN (shadow audit-only). Et un garde-fou de bon sens : un book cible vide signifie « LIQUIDE tout » — le chemin exit-only construit donc son RotationPlan à la main, sans repasser par la décision (L39).

Depuis la fusion Task 016, des étages optionnels s'intercalent (flags, validés en shadow avant flip) : ESCALIER_PRECUT_ENABLED (pré-coupe recall@N≈0.9 avant les duels — moins d'appels, même top), DEEP_EXIT_REVIEW_ENABLED (re-check Opus avant d'éjecter une position gagnante), ROTATION_REBALANCE_ENABLED (top-up/trim si le poids dérive de ≥ 15 %).

5.6 · Reconcile : rattraper la réalité

Piège temporel : les ordres partent à 12:00 UTC… mais l'open US est à 13:30. Les fills arrivent APRÈS la fenêtre de poll du run. La réponse : des crons de réconciliation idempotents qui relisent IB — rotation_fill_reconcile (rattrape les fills lents et écrit aussi la ligne rotation_log d'entrée — sinon la date d'entrée serait « maintenant » à chaque run et le min-hold deviendrait éternel), rotation_exit_reconcile (sorties décidées côté IB, ex. stop serveur), ledger_coherence (toute divergence DB↔IB = alerte). Règle d'écriture : persist-after-fill — rotation_log n'enregistre que des fills réels, et aucun ordre market ne part hors RTH (13:30-20:00 UTC).

5.7 · La surveillance intraday

Entre deux runs, le book n'est pas aveugle : intraday_exit_monitor.py tourne toutes les 15 minutes en RTH. Si une news liée à une position sort avec un sentiment FinBERT ≤ −0.7 (module 06), c'est un forced exit : il override tout — min-hold compris — et arme le cooldown 7 jours. C'est le seul chemin qui court-circuite les amortisseurs de 5.4, et c'est voulu : les règles anti-whipsaw protègent contre le bruit, pas contre un incendie.

5.8 · Le carnet auto-apprenant

Prédis avant de lire : pour savoir si le ranker bat le hasard, faut-il journaliser les 9 trades pris… ou les ~40 candidats scorés ?

Le carnet repose sur trois pièces. 1) Un fil traversant : le decision_id = UUIDv5 déterministe uuid5(NS, run_id|TICKER|side) (ranker/decision_id.py) — recalculable à l'identique au scoring ET à l'exécution, il relie ranker_run, trades et rotation_log sans jamais se passer d'identifiant. 2) Le contrefactuel : candidate_forward_returns stocke 1 ligne par candidat scoré (pas seulement tradé) avec ses retours forward 1/3/5/7 jours — l'antidote au biais du survivant. 3) Le label honnête : à J+7, forward_labeler.py applique la triple-barrier et ré-écrit l'outcome dans le point Qdrant du trade (la mémoire RAG du module 04 apprend de ses résultats).

Glisse k : trop serré (k ≤ 1.4 ici), le bruit normal du titre touche la barrière basse → LOSS alors que la thèse était bonne. Médian, la barrière haute est atteinte → WIN. Trop large, plus rien n'est touché → TIMEOUT. Le label dépend du chemin, pas seulement du point d'arrivée — un titre qui finit à +3 % après avoir traversé −6 % aurait stoppé n'importe quel trader réel. C'est ce que le label naïf « prix plus haut à J+7 ? » efface.

Dernière pièce : à D+0 un debrief Haiku résume chaque décision ; à J+7 le point Qdrant est mis à jour par set_payload (merge). Subtilité réelle : set_payload sur un point inexistant répond 404 silencieux — le point doit donc être créé À L'ENTRÉE (au fill), keyé sur le decision_id traversant. La boucle est fermée : ce que le système trade aujourd'hui, il s'en souviendra demain — avec l'outcome.

Ce qu'il faut retenir

La rotation n'est pas un « stock picker » : c'est un tournoi quotidien où l'entonnoir économise le raisonnement, où la médiane et les duels neutralisent le bruit du juge, où chaque garde-fou est la cicatrice d'une perte réelle, et où le carnet transforme chaque journée en donnée d'apprentissage — y compris pour les titres NON tradés.

Valide le module

Data, news & sentiment

À 15:00 UTC, une dépêche tombe sur un titre du book. Quinze minutes plus tard au plus, la position est liquidée — sans qu'aucun humain n'ait cliqué. Entre la dépêche et l'ordre de vente, il y a tout ce module : une ferme de workflows qui aspire le web, un modèle de sentiment local, un extracteur d'entités, et un seuil gravé dans le code : -0.7. M4 vous a montré le cerveau, M5 le tournoi. Voici les sens du système — et pourquoi un système qui lit mal une news peut vendre Eli Lilly à cause du mot « rally ».

6.1 · Les sens du système — la ferme n8n

Question d'abord : quand l'analyste news (M4) appelle son outil get_n8n_news(ticker), d'où viennent les articles qu'il lit ? Personne ne les colle à la main. Une instance n8n (outil d'automatisation no-code, LXC 192.168.15.7, v2.14.2) fait tourner 10 workflows qui aspirent presse RSS, Finnhub, Reddit, discours Fed/ECB, dépôts SEC et taux d'emprunt IBKR, puis versent tout dans Supabase. Le module agents/tradingagents/utils/n8n_news.py requête ensuite news_items + news_sentiment + news_tickers. Clique chaque workflow sur la carte : cadence, ruse anti-bot, table de destination, consommateurs.

La ruse la plus instructive : WF03 Reddit. L'API .json de Reddit bloquait les requêtes automatisées (anti-bot). Plutôt que de se battre, le workflow est passé au flux RSS Atom public avec un User-Agent Firefox réaliste et un parser Atom maison. Leçon de plomberie data : la voie officielle n'est pas toujours la voie ouverte.

6.2 · FinBERT — le thermomètre à -0.7

Chaque article ingéré passe par FinBERT (LXC 124 :8082) : un modèle BERT spécialisé finance, local et gratuit, qui classe un texte en 3 classes — positive / negative / neutral — agrégées en un score signé de -1 à +1. Plus de 2255 articles sont déjà scorés. Son rôle le plus critique : le détonateur d'exit forcé. Si une news liée à un titre du book sort à ≤ -0.7, le moniteur intraday (intraday_exit_monitor.py, toutes les 15 min en séance 13:30-20:00 UTC) liquide la position et arme un cooldown de 7 jours — car face à une vraie mauvaise nouvelle, le prix gap : un stop technique arrive après la bataille.

À toi de jouer le modèle. Avant de voir les scores, place chacune des 6 headlines ci-dessous sur l'axe -1 → +1. Deux d'entre elles sont des pièges connus des modèles de sentiment : l'ironie et la négation.

6.3 · « rally » n'est pas LLY — le problème name→instrument

Prédis avant de lire : une dépêche parle de « la firme de Cupertino ». Comment la machine sait-elle qu'il s'agit du même instrument que « Apple » et « AAPL » ? C'est le problème name→instrument : relier du texte libre à une ligne de la table instruments (M7). La solution naïve — chercher le ticker comme sous-chaîne dans le texte (« substring ») — est une bombe : le mot « rally » contient « LLY », le ticker d'Eli Lilly. Un exit forcé branché là-dessus pourrait liquider une position sur un mot de vocabulaire. D'où deux parades réelles : linked_only=True obligatoire dans get_n8n_news pour le chemin forced-exit (on ne lit que les news déjà liées à l'instrument), et GLiNER, un modèle de NER dédié.

GLiNER (gliner_multi-v2.1, LXC 124 :8084, endpoint POST /extract, code dans precision-ledger-backend/gliner-service/) extrait les noms de sociétés avec 87% de F1 en multilingue, contre 62% pour un LLM généraliste en zero-shot — et en 130 ms sur CPU, local, gratuit. Il est le Layer 3 de la pipeline name→instrument des workflows news, et doit remplacer l'extraction de tickers actuellement confiée à Ollama (qwen3:14b, LXC 124 :11434).

6.4 · Catalysts SEC & coût d'emprunt — la data qui bloque

Toutes les données n'alimentent pas des opinions : certaines bloquent des trades. Trois workflows scrutent les dépôts SEC : Form 4 (transactions d'initiés → table insider_transactions — un dirigeant qui vend $5M, c'est un signal), Reg SHO (liste seuil des titres en échec de livraison → regsho_threshold_list) et 8-K (événements corporate matériels → corporate_events_8k). Le quatrième, WF07, récupère par FTP chez IBKR les taux d'emprunt de titres → borrow_rates / borrow_rate_history. Ces tables nourrissent les gates shorts A6 (M3) et la porte A du détecteur (M5). À toi de relier chaque table à son effet aval — glisse (ou clique) chaque table vers l'effet qu'elle déclenche.

6.5 · Géopolitique & boule de cristal — geo_ingest et Chronos-2

Dernier sens : le monde au-delà des tickers. La pipeline agents/geo_ingest/ ingère GDELT (base mondiale d'événements géopolitiques), Polymarket (marchés de prédiction), FinLight, PortWatch (trafic portuaire) et l'EIA (énergie), fabrique un geo_context injecté à l'analyste géopolitique (geopolitical_analyst), et propage les chocs par secteur via un graphe de connaissances inspiré des matrices entrées-sorties de Leontief — une guerre du fret frappe d'abord les transporteurs, puis leurs clients. Avant de lire la suite, prédis ceci :

graph LR
  G[GDELT] --> I[agents/geo_ingest/]
  P[Polymarket] --> I
  F[FinLight] --> I
  W[PortWatch] --> I
  E[EIA] --> I
  I --> T[geo_context]
  T --> A[geopolitical_analyst]

Et la boule de cristal : Chronos-2 (amazon/chronos-bolt-base, LXC 124 :8083, POST /forecast) est un modèle de forecasting de séries temporelles qui projette l'OHLCV en avant. Il dessine les overlays de prévision sur les charts du cockpit (via api/routers/markets.py) et fournit l'un des 5 axes de la note pointwise du ranker (M5). Pas une promesse de voyance : un axe parmi cinq, pondéré comme les autres.

Ce qu'il faut retenir

Le système ne « lit pas les news » : il industrialise leur ingestion (10 workflows n8n), les thermomètre localement (FinBERT, exit forcé ≤ -0.7 vérifié toutes les 15 min), résout les noms en instruments sans coïncidences orthographiques (GLiNER 87% F1, linked_only=True), et transforme les dépôts SEC et les taux d'emprunt en vetos mécaniques. La règle culturelle commune à tout le module : une donnée externe est coupable jusqu'à preuve du contraire — on valide en exécutant, cas vides et colonnes surnuméraires inclus.

Quiz de fin de module

Identité des titres & infra

Ton dollar vient d'être alloué à NVDA par le ranker — mais sous quel nom cette action est-elle connue chez IB, chez Yahoo, à l'ISIN ? Si la machine confond deux de ces noms, elle achète le mauvais instrument.

Le même titre s'appelle VK chez Interactive Brokers, VK.PA chez Yahoo, FR00… à l'ISIN, conId 12345 dans le registre interne d'IB et BBG000… au FIGI. Si la machine confond deux de ces noms — ou pire, croit voir deux titres là où il n'y en a qu'un — elle achète le mauvais instrument, double une position, ou laisse un short sans surveillance. Ce module raconte l'état civil des titres et le squelette qui porte tout le reste : Supabase, Qdrant, Redis, l'API, et le geste de deploy qui met tout ça en prod.

7.1 — La table instruments : l'état civil des titres

Question d'ouverture : combien d'identités différentes porte une seule action dans ce système ? Compte sur le schéma — chaque branche est un dialecte qu'une source de données parle (IB, Yahoo, OpenFIGI, les dépêches…) :

Depuis le 2026-05-19 (ADR 0007), la table instruments est la source de vérité de l'identité d'un titre : PK synthétique + colonnes de mapping figi_composite, isin, ib_con_id, yahoo_symbol, peuplée par agents/backfill_instruments.py et le resolver d'entrée tradingagents/utils/ingress_resolver.py. Règle de schéma : toute table qui porte un ticker ajoute instrument_id INTEGER REFERENCES instruments en dual-write — ~25 tables aujourd'hui, avec un trigger SQL en filet pour remplir la colonne si un écrivain l'oublie. Pour retirer un ticker bogus : UPDATE instruments SET active=false, jamais de liste codée en dur.

Détail savoureux : l'ISIN est une donnée payante chez la plupart des fournisseurs… mais IB le donne gratuitement via reqContractDetailsAsync() (champ secIdList de ContractDetails). À l'inverse, OpenFIGI /v3/mapping ne renvoie pas l'ISIN, et son /v3/search est inexploitable pour passer d'un nom à un ticker — c'est la recherche Yahoo qui fait ce travail.

7.2 — L'univers tradeable et son gate

Le système ne peut acheter que ce qui appartient à son univers : la vue matérialisée tradeable_universe_current (~512 lignes : S&P 500 = 499, complément NASDAQ-100 = 13). Le gate « Layer 0 » universe_gate.py bloque tout BUY/SHORT hors de cette liste, avec un cache Redis SET (universe:tradable, TTL 5 min, test d'appartenance SISMEMBER en O(1)). Maintenant, le cas qui fâche :

7.3 — Supabase : le grand livre

Supabase (Postgres self-hosted, LXC 108, 192.168.1.126:8000) tient le journal de toute la machine : ~59 tables en prod. On lui parle par deux portes qu'il ne faut JAMAIS confondre :

Sur ces 59 tables, 7 forment le cœur rotation + carnet. Explore-les — pour chacune : qui écrit, qui lit, et où tu l'as déjà croisée dans ce guide.

7.4 — Qdrant, Redis, FastAPI : le reste du squelette

7.5 — La journée du système en crons

Personne ne clique, mais quelque chose tourne presque à chaque heure. Voici les 24 heures UTC d'un jour ouvré — clique un marqueur pour voir ce qui s'exécute et ce qui s'écrit, ou rejoue la journée entière :

7.6 — Le cycle de deploy : 2 repos, 3 gestes

Le code vit dans 2 repos git séparés — precision-ledger-backend/ et precision-ledger-frontend/. Le dossier racine du projet n'est PAS un repo : jamais de git init à la racine (L1, gravée après l'avoir frôlé). Le chemin vers la prod est toujours le même :

graph LR
  A[commit dans backend/] --> B[push GitHub via gh CLI]
  B --> C[ssh 192.168.15.8 : git pull]
  C --> D{quel dossier a change ?}
  D -->|api/| E[docker compose up -d --build api]
  D -->|agents/| F[systemctl restart trading-worker]
  D -->|ib-bridge/| G[rebuild du container ib-bridge]

Pourquoi deux gestes différents côté serveur ? Parce que api/ et agents/ sont deux mondes Python distincts : 2 pyproject.toml séparés (L2 — vérifier le bon avant d'ajouter une dépendance), gérés par uv (jamais pip), Python 3.12+. L'API tourne dans un container Docker ; le worker des agents tourne en service systemd. Et le push lui-même a son piège : depuis le sandbox, export PATH="/c/Program Files/GitHub CLI:$PATH" d'abord, sinon le credential helper gh est introuvable et le push meurt en 403.

À toi de router — trois fichiers modifiés, trois gestes à choisir :

Ce qu'il faut retenir

L'infra de Precision Ledger tient en quatre réflexes : une identité = une PK synthétique (jamais le ticker en clé), un garde-fou en panne = un garde-fou fermé, la DB est un journal (deux portes, chacune ses pièges — la vérité reste chez IB), et un fichier modifié = un geste de deploy précis. Vérifie que ça tient :

Leçons de guerre & culture ops

Ton dollar est parti en ordre à 12:45 UTC. À 13:30 il est rempli. À J+7, le carnet notera si la thèse était bonne. Mais entre les deux, il a failli ne jamais partir — ou partir à $3.22M de levier non voulu. Ce module raconte comment chaque cicatrice est devenue une règle.

8.1 — Le notebook des règles

8.2 — La salle des incidents

8.3 — Les 5 piliers de la culture ops

8.4 — Où regarder quand ça casse

Ce que tu emportes

Un jour dans la vie d'un run

9.1 — Le film du run, scène par scène

Fais défiler : l'horloge à gauche suit la scène active. Réponds dans ta tête à chaque question AVANT de révéler — score d'échauffement : 0/11.

worker: idle — next timer 12:00:00 UTC 

9.2 — L'examen final

9.3 — Et maintenant ?

Glossaire

Tous les termes glossés du guide, alimentés par les modules via PLA.gloss.add.