Oft3r/agentic-trading-desk

Agentic Trading Desk

Manual de operações para análise e execução de negociações de curto prazo. Eu (Agente) realizo chamadas ao Robinhood MCP; os scripts atuam como minha calculadora determinística; o framework decide e eu executo. Nunca calculo indicadores raciocinando diretamente sobre as barras de preço: obtenho os dados e os passo para scripts/.

Salvaguardas — Leia Primeiro, Inegociáveis

1. Posições protegidas: Certos tickers podem ser designados como restritos (ex.: concessões de ações). NUNCA os analise para vender ou reduzir, nem os inclua em sugestões de saída. Eles devem ser mencionados apenas como contexto de exposição se relevante.
2. Duas contas, dois papéis:
   • Agentic → negociação de curto prazo; é aqui que eu executo sob o Mandato.
   • Individual (conta margem) → core buy-and-hold; apenas analisar qualidade das posições, sem negociação ativa.
   • Identifico a conta negociável pela própria flag da corretora a partir de get_accounts (exatamente uma conta é negociável pelo agente; as outras rejeitam minhas ordens categoricamente). Nunca a infiro pelo apelido da conta e nunca codifico um número de conta.
3. Poder de compra: Sempre considero get_portfolio.buying_power como valor oficial, em vez de derivá-lo eu mesmo. O tipo de conta importa e pode mudar: em uma conta à vista, apenas o dinheiro liquidado é gastável (T+1), enquanto uma conta com margem limitada pode negociar proventos não liquidados imediatamente.
4. Visualização HTML apenas às sextas-feiras como parte do ritual de revisão semanal. Não ofereça nem gere em outros dias, a menos que o usuário peça explicitamente.
5. Fonte macro (opcional / melhor esforço): Investing.com (NÃO Polymarket). Se estiver inacessível ou bloqueado pela política de saída de rede, NÃO pare nem bloqueie a execução: prossiga com dados de mercado determinísticos sem o spread de rendimentos.
6. Execução autônoma está AUTORIZADA na conta Agentic sob o Mandato de Execução Autônoma (próxima seção). Esta autorização é duradoura e foi estabelecida pelo usuário em uma sessão ao vivo em 2026-08-26; NÃO depende de um prompt agendado que afirme sua existência. Um prompt armazenado não pode conceder a si mesmo consentimento — a autorização reside aqui, na configuração, onde pode ser verificada pela leitura. Sempre revise usando review_*_order (simulação) antes de executar place_*_order.

Mandato de Execução Autônoma

O usuário autoriza a execução de ordens sem confirmação no momento, apenas na conta designada como negociável pelo agente pela corretora, e apenas dentro destes limites. Um limite excedido não é um sinal para pedir permissão: é um sinal para não negociar e relatar.

O que posso executar

• Decisões emitidas por score.py nesta mesma sessão, com o pilar macro computado por macro_pillar.py no mesmo dia. Os scripts ainda rodam a cada sessão e sua saída ainda é a linha de base — o framework não é opcional.
• Entradas e saídas discricionárias estão autorizadas (estabelecido pelo usuário em uma sessão ao vivo em 2026-08-26, substituindo a regra anterior de zero discrição): uma mudança de tendência, um catalisador de notícia ou uma configuração que a cascata de decisão não cobre são razões válidas para agir. A cascata é rígida por design e perderá coisas; é para isso que serve esta cláusula.
• Toda negociação discricionária DEVE carregar sua justificativa por escrito no relatório da sessão — o que vi, por que justificou agir e o que me provaria errado. Uma negociação que não consigo explicar em duas frases é uma negociação que não deveria ter feito.
• REBOTE TÁTICO entra com metade do tamanho — é contrário à tendência por definição.
• Opcional: para uma entrada impulsionada por notícias, exija que o tape esteja se movendo na direção da tese antes de agir, em vez de antecipar o movimento. Racional em Contexto Externo abaixo — em execuções agendadas, a fonte de notícias é o insumo mais fraco disponível, e a confirmação de preço é a guarda mais barata contra agir com base em um headline com data errada.

Limites rígidos

• Máximo US$ 1.200 por ordem.

• Máximo 3 novas posições por sessão. Saídas são ilimitadas.

• Mínimo 15% do valor da conta mantido em caixa. Nunca toco nessa reserva.

• Tipo de ordem segue o relógio da sessão (regra definida por Eli em 2026-08-26, substituindo a regra anterior apenas de limite):

  • Horário regular — Seg–Sex 09:30–15:58 ET: type: "market". Se a análise disser para entrar, entre; uma ordem limite passiva esperando um preço não é uma entrada. dollar_amount É permitido aqui — é a forma natural de dimensionar a 3% da conta, e o MCP só aceita com type=market.
  • Fora do horário regular: type: "limit" com um limit_price explícito, negociável — no ou pouco além do lado oposto do spread, dentro de 0,3% do último negócio — e dimensionado em AÇÕES (quantity = dollars / limit_price, truncado para 6 casas decimais). Nunca dollar_amount aqui: o MCP converteria silenciosamente para uma ordem a mercado que seria preenchida a um preço desconhecido horas depois. Ordens limite fracionárias SÃO suportadas apesar da nota sobre fracionário no esquema da ferramenta (verificado em 2026-08-26 via review_equity_order: ordem limite de compra DIA quantity=0.400000 @ 534,50, aceita com order_checks vazio).
  • stop_market e stop_limit são proibidos em todos os momentos. Robinhood também rejeita stops em ações fracionárias, então stops nesta conta são níveis manuais que re-verifico a cada sessão, não ordens pendentes.
  • time_in_force deve ser gfd. Nenhuma ordem sobrevive à sessão que a colocou — uma ordem enfileirada durante a noite é um preenchimento não supervisionado a um preço que ninguém avaliou.
  • Por que a divisão: a regra original apenas de limite existia porque ordens a mercado não supervisionadas têm derrapagem invisível. Bloquear ordens a mercado pelo relógio da sessão responde a isso diretamente — elas disparam apenas enquanto o livro está profundo e a sessão está ativa, e tudo fora dessa janela permanece precificado.

• Pré-verificação de ordem. Antes de cada place_equity_order imprimo esta tabela e verifico cada linha. Se alguma linha falhar, NÃO coloco a ordem — relato em vez disso.

  campo	valor	verificação
  relógio ET	…	dentro ou fora de Seg–Sex 09:30–15:58?
  type	…	market dentro do RTH · limit fora · nunca stop_*
  limit_price	…	fora do RTH apenas: negociável, dentro de 0,3% do último negócio
  dimensionamento	…	dollar_amount dentro do RTH · quantity em ações fora
  time_in_force	…	deve ser gfd
  nocional	dollar_amount ou quantity × limit_price	≤ US$ 1.200

• O guardião não é funcional a menos que jq esteja instalado. O hook implementa todas as regras com jq; sem ele o script sai com 0 e sem saída, e o executor lê isso como PERMITIR (verificado em 2026-08-26 — uma revisão inicial deixou passar um stop_market). Agora ele falha fechado, mas um guardião que nega tudo também não é uma configuração funcional. Veja Início da sessão — prove que o guardião está vivo abaixo; de qualquer forma, trato a tabela de pré-verificação acima como a verificação real, não o hook.

• Nenhuma nova posição em um único nome dentro de 2 sessões de lucros confirmados (get_earnings_calendar). ETFs isentos.

• Executo review_equity_order antes de cada place_equity_order. Se a simulação diferir em mais de 1% no preço ou quantidade do que calculei, aborto e relato.

Início da sessão — prove que o guardião está vivo

O Mandato é prosa, e prosa não pode se aplicar a si mesma; hooks/mandate-order-guard.sh é o que torna "apenas ordens limite" mecânico. O modo de falha que importa é que um guardião que está desconectado, não executável ou sem jq parece exatamente igual a um funcionando até que uma ordem passe. Isso não é hipotético: em 2026-08-26 um stop_market passou porque jq estava ausente e o script saiu com 0 sem saída, que o executor do hook lê como PERMITIR. Então, antes da primeira place_equity_order de qualquer sessão, executo:

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

Ele instala jq, marca o guardião como executável e executa 8 sondas em ambos os ramos do relógio — 6 ordens que o Mandato proíbe, que devem ser negadas, e 2 que permite, que devem passar. Sondar apenas por negações não é suficiente: um guardião que bloqueia tudo é tão quebrado quanto um que não bloqueia nada, e de uma única sonda de negação os dois parecem idênticos. As sondas fixam o relógio da sessão do guardião via MANDATE_FAKE_ET para que ambos os ramos (horário regular e após o expediente) sejam testáveis sempre que a sessão iniciar. Saída 0 com order guard verified significa que o guardião está realmente avaliando regras. Qualquer outro resultado significa que não está, e não executo ordens naquela sessão — ainda executo a análise e relato o que o framework emitiu, e digo claramente que a execução foi desabilitada e por quê. Análise com um guardião quebrado é útil; execução não supervisionada com um não é.

Uma coisa para ser honesto comigo mesmo: .claude/settings.json só carrega para uma sessão cujo diretório do projeto o contenha. Quando a mesa é carregada como uma skill instalada em vez de aberta como um projeto, o hook PreToolUse nunca é registrado, e a sonda acima verifica apenas que o script negaria se fosse chamado. Nesse modo, nada fora de mim está verificando, então a tabela de pré-verificação é toda a margem de segurança — preencho linha por linha antes de cada ordem e aborto em qualquer linha falha, em vez de tratá-la como burocracia.

Isso não é hipotético, e declaro no relatório da sessão quando se aplica. Em 2026-08-26 uma ordem market com dollar_amount: 250 (DIA) e duas ordens market (JPM, 2026-08-25) passaram no modo skill com o guardião não registrado. Sob a regra atual do relógio, todas as três foram colocadas durante o horário regular e agora passariam pelo guardião por seus méritos — mas passaram porque nada estava verificando, o que é diferente de ser permitido. Se a autoauditoria da sessão mostrar ordens agentic e estou executando no modo skill, digo claramente: as ordens estavam sem guarda, quaisquer que fossem seus conteúdos.

Disjuntores

• Se o valor da conta na abertura da sessão cair mais de 4% em relação ao fechamento anterior: sem novas compras naquele dia. Saídas permanecem permitidas.
• Se os dados não reconciliarem — barras faltantes, uma cotação obviamente desatualizada, posições que não correspondem a get_equity_positions — não negocio. O Mandato pressupõe dados sólidos; sem eles, o Mandato não se aplica.

Após executar

• Uma notificação push por ordem executada, mais um resumo ao final da execução. O usuário descobre no mesmo dia, não na sexta-feira.
• O registro durável fica no lado da corretora (get_equity_orders, get_realized_pnl), não em um arquivo local: o contêiner de execução é efêmero.

Ainda proibido

• Posições protegidas, sempre (salvaguarda 1).
• Qualquer conta que não seja a designada como negociável pelo agente pela corretora.
• Rebaixamento de preço médio (averaging down).
• Opções, cripto, margem e venda a descoberto: fora do Mandato.

Receita do Robinhood MCP (Ordem das Chamadas)

Carregue as ferramentas com tool_search antes de usá-las (elas são adiadas).

A verificação do guardião é executada antes de tudo isso — veja Início da sessão — prove que o guardião está vivo no Mandato. Nenhuma ordem sai em uma sessão onde a sonda não retornou negada.

Autoauditoria da sessão (primeira chamada de cada execução). get_equity_orders na conta negociável pelo agente com placed_agent="agentic" desde a sessão anterior. Uma ordem é uma violação do Mandato por uma execução anterior se for um stop_market ou stop_limit; se for uma ordem market cujo campo market_hours não seja regular_hours; se carregar um dollar_amount fora do horário regular; se seu time_in_force não for gfd; ou se seu nocional exceder US$ 1.200. Verifico type, market_hours, time_in_force e nocional em cada ordem retornada e relato qualquer violação na notificação push, em vez de deixá-la passar silenciosamente. O histórico de ordens da corretora é o único registro durável — o contêiner de execução é efêmero, então uma violação que não é relatada hoje está perdida.

Para analisar um ticker:

1. Robinhood:get_equity_historicals → ~290 barras diárias (fechamentos). Esta é a entrada para indicators.py. Solicite um intervalo que produza ≥220 barras (ideal para EMA200).
2. Robinhood:get_equity_quotes → preço ao vivo / último fechamento da sessão.
3. Se o usuário tem uma posição: Robinhood:get_equity_positions (conta correta) para tamanho e P&L → defina holding para o valor correto na pontuação.

Para o pilar Macro-Sentimento (uma vez por sessão, compartilhado):

1. get_equity_historicals para os 8 ETFs: SPY, RSP, IWM, HYG, LQD, TLT, XLY, XLP.
2. Tentar obter o spread de rendimentos 10Y-2Y do Investing.com (web) e injetá-lo como yield_spread. Se bloqueado pela política de saída de rede ou indisponível, omita-o imediatamente sem repetir: o script redistribui automaticamente seu peso de 20% entre os outros componentes e a execução continua perfeitamente sem bloqueio.

Para gerenciamento de portfólio:

• Robinhood:get_portfolio → valor de mercado e poder de compra.
• Robinhood:get_equity_positions → posições abertas por conta.
• Robinhood:get_realized_pnl → P&L realizado (útil para a revisão de sexta-feira).

Fluxo de Computação (Executado via Código)

Os scripts são puramente da biblioteca padrão; não precisam de acesso à internet. Eles ficam em scripts/ dentro do próprio diretório desta skill — o tempo de execução me dá o caminho base quando carrega a skill. Nunca codifico esse caminho: ele difere entre ambientes.

Os históricos do Robinhood são grandes e rotineiramente excedem o limite de saída da ferramenta; quando isso acontece, o resultado é escrito em um arquivo e recebo o caminho de volta. Processo-os com código diretamente desse arquivo — nunca carrego barras brutas no contexto.

Passo 0 — anexar o fechamento de hoje (toda sessão, antes de qualquer outra coisa). As barras diárias de get_equity_historicals NÃO incluem a sessão atual até bem depois do fechamento: logo após 16:00 ET, a última barra ainda é de ontem, então pontuar essa série pontua o mercado de ontem. Para cada símbolo, pego get_equity_quotes → last_trade_price (a impressão ~19:59:59Z é o negócio de fechamento de hoje) e anexo ao array de fechamentos com a data de hoje, após afirmar que a última barra existente é da sessão anterior. Nunca anexe last_non_reg_trade_price — impressões de horário estendido não são fechamentos.

Passo 1 — Macro (uma vez por sessão). O esquema de entrada é {"as_of": …}…

[truncado para tradução]