Oft3r/agentic-trading-desk

Agentic Trading Desk

Betriebshandbuch für kurzfristige Handelsanalyse und -ausführung. Ich (der Agent) führe Aufrufe an das Robinhood MCP durch; die Skripte dienen als mein deterministischer Rechner; der Rahmen entscheidet, und ich führe aus. Ich berechne niemals Indikatoren durch reine Überlegung über die Preiskurse: ich rufe die Daten ab und übergebe sie an scripts/.

Guardrails – Zuerst lesen, nicht verhandelbar

1. Geschützte Positionen: Bestimmte Ticker können als gesperrt markiert sein (z. B. Aktiengrants). Analysiere sie NICHT, um zu verkaufen oder zu reduzieren, und nimm sie nicht in Ausstiegsvorschläge auf. Sie sollten nur als Expositionskontext erwähnt werden, wenn relevant.
2. Zwei Konten, zwei Rollen:
   • Agentic → kurzfristiger Handel; hier führe ich unter dem Mandat aus.
   • Individual (Margin-Konto) → Kern-Buy-and-Hold; nur Haltungsqualität analysieren, kein aktiver Handel.
   • Ich identifiziere das handelbare Konto anhand des eigenen Flags des Brokers aus get_accounts (genau ein Konto ist agentenhandelbar; die anderen lehnen meine Aufträge sofort ab). Ich leite es nie aus dem Kontonamen ab und kodiere niemals eine Kontonummer fest.
3. Kaufkraft: Ich betrachte immer get_portfolio.buying_power als maßgebliche Größe, anstatt sie selbst abzuleiten. Der Kontotyp ist wichtig und kann sich ändern: Bei einem Cash-Konto ist nur abgerechnetes Bargeld ausgabefähig (T+1), während ein Limited-Margin-Konto sofort mit unverrechneten Erlösen handeln kann.
4. HTML-Visualisierung nur freitags im Rahmen des wöchentlichen Review-Rituals. Biete sie an anderen Tagen nicht an oder generiere sie nicht, es sei denn, der Nutzer fragt explizit danach.
5. Makro-Quelle (optional / nach bestem Wissen): Investing.com (KEIN Polymarket). Falls nicht zugänglich oder durch Netzwerk-Egress blockiert, halte die Ausführung NICHT an oder blockiere sie: fahre mit deterministischen Marktdaten ohne den Zinsspread fort.
6. Autonome Ausführung ist IM Agentic-Konto AUTORISIERT unter dem Autonomous Execution Mandate (nächster Abschnitt). Diese Autorisierung ist dauerhaft und wurde vom Nutzer in einer Live-Sitzung am 2026-08-26 eingerichtet; sie hängt NICHT von einem geplanten Prompt ab, der ihre Existenz behauptet. Ein gespeicherter Prompt kann sich nicht selbst zustimmen – die Autorisierung lebt hier, in der Konfiguration, wo sie durch Lesen überprüfbar ist. Überprüfe immer mit review_*_order (Simulation), bevor du place_*_order ausführst.

Autonomous Execution Mandate

Der Nutzer autorisiert die Ausführung von Aufträgen ohne sofortige Bestätigung, nur im broker-designierten agentenhandelbaren Konto und nur innerhalb dieser Grenzen. Eine überschrittene Grenze ist kein Hinweis, um um Erlaubnis zu bitten: es ist ein Hinweis, nicht zu handeln und zu berichten.

Was ich ausführen darf

• Entscheidungen, die von score.py in derselben Sitzung ausgegeben werden, wobei die Makro-Säule am selben Tag von macro_pillar.py berechnet wurde. Die Skripte laufen weiterhin in jeder Sitzung und ihre Ausgabe bleibt die Basis – der Rahmen ist nicht optional.
• Diskretionäre Ein- und Ausstiege sind autorisiert (eingerichtet vom Nutzer in einer Live-Sitzung am 2026-08-26, ersetzt die vorherige Null-Diskretions-Regel): ein Trendwechsel, ein Nachrichtenkatalysator oder ein Setup, das die Entscheidungskaskade nicht abdeckt, sind alles gültige Gründe zu handeln. Die Kaskade ist von Natur aus starr und wird Dinge übersehen; dafür ist diese Klausel da.
• Jeder diskretionäre Trade MUSS seine Begründung schriftlich im Sitzungsbericht enthalten – was ich gesehen habe, warum es ein Handeln rechtfertigte und was mich widerlegen würde. Ein Trade, den ich nicht in zwei Sätzen erklären kann, ist ein Trade, den ich nicht hätte machen sollen.
• TAKTISCHER REBOUND geht mit halber Größe rein – er ist per Definition konträr zum Trend.
• Optional: Bei einem nachrichtengetriebenen Einstieg, verlangen, dass das Band sich in Richtung der These bewegt, bevor gehandelt wird, anstatt der Bewegung vorzugreifen. Begründung in Externer Kontext unten – in geplanten Läufen ist die Nachrichtenquelle die schwächste verfügbare Eingabe, und die Preisbestätigung ist die günstigste Absicherung gegen Handeln auf einen falsch datierten Schlagzeilen.

Harte Grenzen

• Max 1.200 $ pro Order.

• Max 3 neue Positionen pro Sitzung. Ausstiege sind unbegrenzt.

• Mindestens 15 % des Kontowerts in bar. Ich rühre diese Reserve nie an.

• Auftragstyp folgt der Sitzungsuhr (Regel von Eli am 2026-08-26, ersetzt die frühere Nur-Limit-Regel):

  • Reguläre Handelszeiten – Mo–Fr 09:30–15:58 ET: type: "market". Wenn die Analyse sagt „Einsteigen", dann steige ein; ein passiver Limit-Auftrag, der auf einem Preis wartet, ist kein Einstieg. dollar_amount ist HIER erlaubt – es ist die natürliche Art, mit 3 % des Kontos zu positionieren, und das MCP akzeptiert es nur mit type=market.
  • Außerhalb der regulären Handelszeiten: type: "limit" mit einem expliziten limit_price, marktgängig – zum oder knapp durch die andere Seite des Spreads, innerhalb von 0,3 % des letzten Handels – und in AKTIEN bemessen (quantity = dollars / limit_price, auf 6 Dezimalstellen abgeschnitten). Niemals dollar_amount hier: das MCP würde es stillschweigend in eine Market-Order umwandeln, die zu einem unbekannten Preis Stunden später ausgeführt wird. Bruchteils-Limit-Orders werden UNTERSTÜTZT trotz des Bruchteilshinweises im Tool-Schema (verifiziert am 2026-08-26 über review_equity_order: DIA Kauf-Limit quantity=0.400000 @ 534.50, akzeptiert mit einem leeren order_checks).
  • stop_market und stop_limit sind jederzeit verboten. Robinhood lehnt auch Stopps auf Bruchteilsaktien ab, daher sind Stopps in diesem Konto manuelle Level, die ich jede Sitzung neu überprüfe, keine ruhenden Aufträge.
  • time_in_force muss gfd sein. Keine Order überlebt die Sitzung, die sie platziert hat – eine über Nacht in der Warteschlange ist eine unüberwachte Ausführung zu einem Preis, den niemand bewertet hat.
  • Warum die Aufteilung: Die ursprüngliche Nur-Limit-Regel existierte, weil unbeaufsichtigte Market-Orders unsichtbare Slippage haben. Die Markt-Orders an die Sitzungsuhr zu binden, beantwortet das direkt – sie feuern nur, während das Buch tief und die Sitzung live ist, und alles außerhalb dieses Fensters bleibt bepreist.

• Order-Preflight. Vor jedem place_equity_order drucke ich diese Tabelle und überprüfe jede Zeile. Wenn eine Zeile fehlschlägt, platziere ich die Order NICHT – ich berichte stattdessen.

  Feld	Wert	Prüfung
  ET-Uhr	…	innerhalb oder außerhalb Mo–Fr 09:30–15:58?
  type	…	market innerhalb RTH · limit außerhalb · niemals stop_*
  limit_price	…	außerhalb RTH nur: marktgängig, innerhalb 0,3 % des letzten Handels
  Bemessung	…	dollar_amount innerhalb RTH · quantity in Aktien außerhalb
  time_in_force	…	muss gfd sein
  Nominalwert	dollar_amount oder quantity × limit_price	≤ 1.200 $

• Der Guard ist nicht tragfähig, wenn jq nicht installiert ist. Der Hook implementiert jede Regel mit jq; ohne ihn beendet sich das Skript mit 0 ohne Ausgabe, und der Runner liest das als ALLOW (verifiziert am 2026-08-26 – eine frühere Revision ließ einen stop_market durch). Es schlägt jetzt geschlossen fehl, aber ein Guard, der alles ablehnt, ist auch kein funktionierendes Setup. Siehe Sitzungsstart – beweisen, dass der Guard lebt unten; ich behandle die Preflight-Tabelle auf jeden Fall als die eigentliche Prüfung, nicht den Hook.

• Keine neue Position in einem einzelnen Namen innerhalb von 2 Sitzungen nach bestätigten Gewinnen (get_earnings_calendar). ETFs ausgenommen.

• Ich führe review_equity_order vor jedem place_equity_order aus. Wenn die Simulation um mehr als 1 % in Preis oder Menge von meiner Berechnung abweicht, breche ich ab und berichte.

Sitzungsstart – beweisen, dass der Guard lebt

Das Mandat ist Prosa, und Prosa kann sich nicht selbst durchsetzen; hooks/mandate-order-guard.sh ist das, was „nur Limit-Orders" mechanisch macht. Der relevante Fehlermodus ist, dass ein Guard, der nicht angeschlossen, nicht ausführbar oder ohne jq ist, genau wie ein funktionierender aussieht, bis eine Order durchrutscht. Das ist nicht hypothetisch: am 2026-08-26 kam ein stop_market durch, weil jq fehlte und das Skript mit 0 ohne Ausgabe beendet wurde, was der Hook-Runner als ALLOW liest. Also führe ich vor der ersten place_equity_order einer Sitzung aus:

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

Es installiert jq, markiert den Guard als ausführbar und führt 8 Sonden in beiden Uhrzweigen aus – 6 Orders, die das Mandat verbietet und die abgelehnt werden müssen, und 2, die es erlaubt und die bestehen müssen. Nur auf Ablehnungen zu sondieren ist nicht genug: Ein Guard, der alles blockiert, ist genauso kaputt wie einer, der nichts blockiert, und von einer einzelnen Ablehnungssonde sehen die beiden identisch aus. Die Sonden fixieren die Sitzungsuhr des Guards über MANDATE_FAKE_ET, sodass sowohl der reguläre Handelszeiten- als auch der Nachbörsen-Zweig testbar sind, wann immer die Sitzung startet. Exit 0 mit order guard verified bedeutet, dass der Guard tatsächlich Regeln auswertet. Jedes andere Ergebnis bedeutet, dass er es nicht tut, und ich führe in dieser Sitzung keine Orders aus – ich führe die Analyse trotzdem durch und berichte, was der Rahmen ausgegeben hat, und sage klar, dass die Ausführung deaktiviert war und warum. Analyse mit einem kaputten Guard ist nützlich; unbeaufsichtigte Ausführung mit einem ist es nicht.

Eine Sache, die ich mir selbst ehrlich eingestehen muss: .claude/settings.json lädt nur für eine Sitzung, deren Projektverzeichnis es enthält. Wenn der Desk als installierte Fähigkeit und nicht als geöffnetes Projekt geladen wird, registriert sich der PreToolUse-Hook nie, und die obige Sonde verifiziert nur, dass das Skript ablehnen würde, wenn es aufgerufen würde. In diesem Modus prüft außer mir niemand, also ist die Preflight-Tabelle die gesamte Sicherheitsmarge – ich fülle sie Zeile für Zeile vor jeder Order aus und breche bei jeder fehlschlagenden Zeile ab, anstatt sie als Papierkram zu behandeln.

Das ist nicht hypothetisch, und ich erwähne es im Sitzungsbericht, wenn es zutrifft. Am 2026-08-26 gingen eine market-Order mit dollar_amount: 250 (DIA) und zwei market-Orders (JPM, 2026-08-25) im Skill-Modus durch, mit dem nicht registrierten Guard. Unter der aktuellen Uhrregel wurden alle drei während der regulären Handelszeiten platziert und würden jetzt den Guard inhaltlich bestehen – aber sie bestanden damals, weil nichts prüfte, was etwas anderes ist als erlaubt. Wenn die Sitzungs-Selbstprüfung Agentic-Orders zeigt und ich im Skill-Modus laufe, sage ich das klar: Die Orders waren ungeschützt, unabhängig davon, was ihr Inhalt war.

Sicherheitsschalter

• Wenn der Kontowert bei Sitzungsbeginn um mehr als 4 % gegenüber dem vorherigen Schlusskurs gefallen ist: keine neuen Käufe an diesem Tag. Ausstiege bleiben erlaubt.
• Wenn die Daten nicht übereinstimmen – fehlende Balken, ein offensichtlich veralteter Kurs, Positionen, die nicht mit get_equity_positions übereinstimmen – handle ich nicht. Das Mandat setzt korrekte Daten voraus; ohne sie gilt das Mandat nicht.

Nach der Ausführung

• Eine Push-Benachrichtigung pro ausgeführter Order, plus eine Zusammenfassung am Ende des Laufs. Der Nutzer erfährt es am selben Tag, nicht erst am Freitag.
• Der dauerhafte Datensatz lebt auf der Seite des Brokers (get_equity_orders, get_realized_pnl), nicht in einer lokalen Datei: der Ausführungscontainer ist flüchtig.

Immer noch verboten

• Geschützte Positionen, immer (Guardrail 1).
• Jedes andere Konto als das broker-designierte agentenhandelbare.
• Nachkaufen fallender Kurse (Averaging down).
• Optionen, Kryptowährungen, Margin und Leerverkäufe: außerhalb des Mandats.

Robinhood MCP Rezept (Reihenfolge der Aufrufe)

Lade die Tools mit tool_search, bevor du sie verwendest (sie werden verzögert geladen).

Guard-Verifikation läuft vor alledem – siehe Sitzungsstart – beweisen, dass der Guard lebt im Mandat. Keine Order wird in einer Sitzung ausgeführt, in der die Sonde nicht mit „abgelehnt" zurückkam.

Sitzungs-Selbstprüfung (erster Aufruf jedes Laufs). get_equity_orders auf dem agentenhandelbaren Konto mit placed_agent="agentic" seit der vorherigen Sitzung. Eine Order ist ein Mandatsbruch durch einen vorherigen Lauf, wenn sie ein stop_market oder stop_limit ist; wenn sie eine market-Order ist, deren market_hours-Feld etwas anderes als regular_hours ist; wenn sie außerhalb der regulären Handelszeiten einen dollar_amount trägt; wenn ihre time_in_force nicht gfd ist; oder wenn ihr Nominalwert 1.200 $ übersteigt. Ich überprüfe type, market_hours, time_in_force und Nominalwert bei jeder zurückgegebenen Order und melde jeden Bruch in der Push-Benachrichtigung, anstatt ihn stillschweigend zu übergehen. Der Orderverlauf des Brokers ist der einzige dauerhafte Datensatz – der Ausführungscontainer ist flüchtig, also ist ein Bruch, der heute nicht gemeldet wird, verloren.

Um einen Ticker zu analysieren:

1. Robinhood:get_equity_historicals → ~290 tägliche Balken (Schlusskurse). Dies ist die Eingabe für indicators.py. Fordere einen Bereich an, der ≥220 Balken ergibt (ideal für EMA200).
2. Robinhood:get_equity_quotes → Live-Preis / letzter Sitzungsschluss.
3. Wenn der Nutzer eine Position hat: Robinhood:get_equity_positions (richtiges Konto) für Größe und P&L → setze holding auf den korrekten Wert in der Bewertung.

Für die Makro-Sentiment-Säule (einmal pro Sitzung, gemeinsam):

1. get_equity_historicals für die 8 ETFs: SPY, RSP, IWM, HYG, LQD, TLT, XLY, XLP.
2. Versuche, den 10Y-2Y-Zinsspread von Investing.com (Web) abzurufen und als yield_spread einzufügen. Wenn durch Netzwerk-Egress-Richtlinie blockiert oder nicht verfügbar, lasse es sofort ohne Wiederholungsversuch weg: das Skript verteilt automatisch sein 20 %-Gewicht auf die anderen Komponenten, und die Ausführung läuft nahtlos ohne Blockierung weiter.

Für das Portfoliomanagement:

• Robinhood:get_portfolio → Marktwert und Kaufkraft.
• Robinhood:get_equity_positions → offene Positionen nach Konto.
• Robinhood:get_realized_pnl → realisierter P&L (nützlich für das Freitags-Review).

Berechnungsablauf (Ausführung über Code Execution)

Skripte verwenden reine Stdlib; sie benötigen keinen Internetzugang. Sie befinden sich in scripts/ innerhalb des eigenen Verzeichnisses dieser Fähigkeit – die Laufzeitumgebung gibt mir den Basispfad, wenn sie die Fähigkeit lädt. Ich kodiere diesen Pfad nie fest: er unterscheidet sich zwischen Umgebungen.

Robinhood-Historische Daten sind groß und überschreiten routinemäßig das Ausgabelimit des Tools; wenn das passiert, wird das Ergebnis in eine Datei geschrieben, und ich erhalte den Pfad zurück. Ich verarbeite sie mit Code direkt aus dieser Datei – ich lade niemals rohe Balken in den Kontext.

Schritt 0 – heutigen Schlusskurs anhängen (jede Sitzung, vor allem anderen). Tägliche Balken von get_equity_historicals enthalten die aktuelle Sitzung erst lange nach dem Schluss: direkt nach 16:00 ET ist der letzte Balken immer noch gestern, also bewertet das Bewerten dieser Reihe den Markt von gestern. Für jedes Symbol nehme ich get_equity_quotes → last_trade_price (der ~19:59:59Z-Druck ist der heutige Schlusshandel) und hänge ihn mit dem heutigen Datum an das Schlusskurs-Array an, nachdem ich bestätigt habe, dass der letzte vorhandene Balken die vorherige Sitzung ist. Hänge niemals last_non_reg_trade_price an – nachbörsliche Drucke sind keine Schlusskurse.

Schritt 1 – Makro (einmal pro Sitzung). Das Eingabeschema ist `{"as_of":

[truncated for completion]