Como construir o seu fluxo de trabalho de trading: dos dados à revisão
Um fluxo de trabalho sólido leva dos dados e da análise à decisão, execução e revisão sem reconstruir o plano de memória. Cada etapa tem uma finalidade e um registo definido, permitindo comparar a intenção com o que aconteceu após uma operação. Este artigo mostra como ligar plataforma, calendário, alertas e diário num único processo, escolher as ferramentas necessárias e preparar um procedimento de emergência. Abrange tanto trading manual como regras executadas por código.
- Uma fonte de verdade para cada informação — um registo do plano preenchido antes de abrir a posição, um registo de execução completado após o fecho e um registo do processo com as regras em vigor: para cada informação, um deles prevalece em caso de discrepância; para provas que não cabem numa coluna, esse papel cabe ao arquivo de anexos. O gráfico, a lista de acompanhamento ativa e a nota no telefone são cópias de trabalho, não registos do processo; uma lista datada guardada no arquivo já não é uma cópia de trabalho
- Cada etapa responde a três perguntas — para que serve, o que falha sem ela e como reconhecerá que não funciona no seu caso. Uma etapa sem resposta à terceira pergunta é decoração do processo, não parte dele
- Um alerta inicia um procedimento, não uma ordem — cumprir a condição gera apenas um evento e uma notificação. O local da avaliação depende da ferramenta: nos servidores da plataforma ou na aplicação em execução. O passo seguinte depende de ter escrito o que fazer quando o alerta dispara (art. 11.2)
- Uma ferramenta não cria vantagem por si só — pode melhorar a repetibilidade, a ergonomia e a fiabilidade dos registos. A vantagem de uma estratégia nasce noutro lugar (art. 8.2); por isso o conjunto de ferramentas é decidido pelo teste de redundância, não por uma classificação
- As variantes manual e sistemática falham em pontos diferentes — na manual falha a pessoa que omite um passo; na sistemática, uma mudança silenciosa das condições: outra versão de um pacote, especificação do símbolo alterada ou nova ligação após uma sessão interrompida
- Altere o processo só após uma decisão documentada — data, observação, âmbito da alteração, critério de avaliação e período de validade. Sem esse registo, uma série de perdas escreve as suas novas regras e os resultados anteriores e posteriores misturam-se numa amostra incomparável
- O procedimento de emergência faz parte do fluxo — confirme o estado da conta por um segundo canal, pare a automação, verifique as posições no corretor, registe o incidente e retome apenas após confirmar o estado
1. Duas fontes de verdade: a falha típica do fluxo
Um fluxo de trabalho é uma ordem acordada de passos e — a parte mais frequentemente omitida — um local acordado para registar o resultado de cada passo. A ordem não basta. Se a entrada só existe como linha no gráfico, a dimensão só na calculadora e o motivo só na memória, uma semana depois terá o resultado da operação, mas não o processo que o produziu.
A falha começa quando a mesma informação vive em dois locais que podem divergir. Normalmente, um serviço de diário importa automaticamente o histórico da conta enquanto preenche uma folha todas as noites. A importação conhece a hora do servidor do corretor e os parâmetros reais de execução; a folha conhece a sua versão dos factos. Após um mês mostram números diferentes de operações e ninguém reconstrói a diferença, porque fechos parciais e ajustes divergem de maneiras distintas. Não é um defeito das aplicações, mas de um processo que nunca definiu qual fonte prevalece.
O que não é um fluxo de trabalho. Não é uma lista de aplicações nem o número de janelas abertas. Também não é «todas as manhãs verifico o mercado»: uma declaração não deixa um rasto utilizável depois. Um fluxo reconhece-se de forma mais simples: consegue apontar uma entrada, ficheiro ou registo produzido em cada etapa da última operação.
Convém retirar desde logo às ferramentas um peso que não conseguem suportar. Uma ferramenta não cria vantagem por si só. Plataforma, calendário e diário podem melhorar repetibilidade, ergonomia e credibilidade dos registos, o que já é muito. Não criam uma vantagem: esta vem das regras de entrada e saída, não do software (art. 8.2). Uma ferramenta pode influenciar o resultado líquido através dos custos realizados, erros de execução e completude dos registos: é todo o seu âmbito de ação. Separar as duas coisas tem uma consequência prática: «esta configuração dá vantagem» não faz sentido aqui porque não pode ser verificado; «reduz os desvios ao plano» faz sentido, porque a secção 12 explica como medir.
2. Mapa do processo: onze etapas e o que falha em cada uma
O modelo tem onze etapas; monitorização e revisão podem formar ciclos de feedback, enquanto o registo de decisões mantém a ordem:
calendário e dados → lista de acompanhamento → análise → plano → alerta → decisão → execução → monitorização → diário → revisão → alteração do processo
A sequência mostra as dependências do modelo. Cada estratégia pode organizar análise e alertas de outra forma, mas a decisão tem de usar um plano registado antes da execução. Omitir uma etapa não encurta o processo: transfere o trabalho para outra não preparada para isso. O plano omitido não desaparece; reconstitui-se ao enviar a ordem, sob pressão e sem nada escrito.
A tabela é o núcleo do artigo. Para cada etapa indica a finalidade, o que falha sem ela e como reconhecer que não funciona. A última coluna apresenta uma condição verificável nos seus dados: identifica o artefacto e a comparação a executar. Tem prioridade porque uma etapa sem tal condição não está realmente controlada: a falha pode, no máximo, ser sentida, não contada.
| Etapa | Para que serve | O que falha sem ela | Sinal de que não funciona no seu caso |
|---|---|---|---|
| Calendário e dados | Determina mudanças durante o seu horário: publicação, alteração do horário de negociação ou dia de financiamento triplo | Entra num período com custos e liquidez diferentes dos pressupostos do plano | O campo de eventos do plano desse dia está vazio: não distingue um dia sem publicações de um passo omitido. Preenchido, contém horas e fuso horário usado, alterações anunciadas do horário e dia de financiamento triplo, ou o valor explícito «sem eventos no horário de trabalho» |
| Lista de acompanhamento | Limita os instrumentos aos que consegue acompanhar no tempo realmente disponível | A análise estende-se a tudo o que se move | Faltam listas datadas da última semana no arquivo de anexos. Se existem, compare a composição entre dias consecutivos com a regra de rotação do registo do processo: uma mudança conforme não é um sinal de falha; uma mudança sem regra é |
| Análise | Produz uma tese e o nível que a invalida | Não há o que escrever no plano e a decisão nasce na janela de ordens | O campo do nível de invalidação está vazio: sem ele, a entrada é uma nota, não um plano |
| Plano | Transforma a tese em registo: instrumento, condição de entrada, nível de invalidação, nível protetor previsto, dimensão e fundamento, condição de cancelamento | A revisão perde o denominador: não distingue desvio de intenção | O registo do plano é posterior à abertura no histórico, ou não existe para essa posição |
| Alerta | Inicia o procedimento ao cumprir a condição e evita olhar para o gráfico sem motivo | Volta a olhar para o ecrã e as ocasiões de entrada aumentam à margem do plano | Existem alertas ativos cuja mensagem não aponta para uma entrada do registo do plano |
| Decisão | Separa «condição cumprida» de «vou entrar» e verifica se os pressupostos do plano continuam válidos | O alerta comporta-se como uma ordem | Duas condições simultâneas. Primeira: há uma ordem no histórico sem registo de decisão no plano — hora, identificador e decisão entrar ou cancelar. Segunda, para cancelamentos: num dia há menos registos de decisão do que notificações de alertas disparados recebidas no seu canal |
| Execução | Transforma o plano numa ordem num local acordado, após uma breve lista de verificação | Os parâmetros diferem do plano e a diferença não é registada | A dimensão ou o nível protetor no histórico difere do plano sem um desvio correspondente no diário. O nível de invalidação compara-se separadamente com o diário: se nunca foi enviado como ordem, não aparece no histórico |
| Monitorização | Define antecipadamente o que observa com a posição aberta e em que momentos | A posição aberta é renegociada continuamente | Conte os registos cujo campo próprio «momento da intervenção» seja «fora do plano». Preenche-o à mão ao completar o registo: nenhuma exportação sabe se algo correspondia ao seu horário |
| Diário | Conserva execução e classificação de forma quantificável | Só fica o extrato: resultado sem processo | A divisão por configuração ou hora devolve grupos vazios porque falta a classificação |
| Revisão | Compara plano e execução registados e identifica a diferença | As conclusões vêm da memória das últimas operações | Falta no registo do processo uma entrada com data e identificador da revisão. Sem marcar o evento não distingue uma revisão sem conclusões de outra que nunca ocorreu |
| Alteração do processo | Introduz uma correção com data, âmbito, critério de avaliação e validade | As regras mudam após cada série de perdas e a amostra deixa de ser comparável | Falta uma entrada com data e versão das regras em vigor nessa semana |
Os onze pontos são atividades. Existem dois tipos de locais de registo. Três registos — plano, execução ou diário e processo — contêm dados estruturados, ou seja, quantificáveis. Ao lado está o arquivo de anexos, repositório autorizado de provas que não cabem numa coluna: listas datadas, capturas e exportações do histórico. Cada ficheiro liga-se a um dia, plano ou incidente, pelo que a atividade deixa rasto num registo, no arquivo ou em ambos. Inclui a revisão: não é outro registo, mas escreve o resultado no local certo; um registo completado vai para execução e uma ficha de alteração para o processo. Por isso primeiro organizamos os registos, depois as atividades que os alimentam.
3. Uma fonte de verdade: plano, diário e versões do processo
O princípio cabe numa frase: para cada informação existe um local que prevalece em caso de discrepância. Tudo o que repita essa informação é uma cópia de trabalho. Pode perder-se e ser recriado a partir da fonte; o registo autorizado é restaurado de uma cópia de segurança controlada com histórico, não de uma cópia de trabalho qualquer.
Na prática existem três registos distintos pelo momento da criação:
- O registo do plano — é criado antes de enviar a ordem e não é editado depois. Pode ser uma folha separada ou uma secção do diário; a forma não importa, o momento sim. Uma entrada editada depois deixa de servir de denominador da revisão.
- O registo de execução — é alimentado por importação do histórico quando possível. Não por superioridade geral: a importação conhece a hora do servidor e os parâmetros reais, impossíveis de reconstruir de memória. Os campos manuais classificam configuração, motivo de saída, desvio e momento da intervenção. Estrutura, problemas de importação e métricas estão no art. 11.6.
- O registo do processo — contém as regras em vigor num período, com data e versão. Costuma ser omitido; sem ele não saberá depois com que regras negociou em março.
Ao lado dos três registos está o arquivo de anexos: capturas, listas datadas e exportações do histórico. Não é um quarto registo porque não contém dados quantificáveis, mas é o repositório autorizado de provas: não existe cópia superior dos seus ficheiros e cada um liga-se por identificador a um dia, plano ou incidente. São cópias de trabalho os layouts, lista ativa, conjuntos de alertas e notas do telefone. Todos são necessários; nenhum é fonte. O teste decisivo demora um minuto: Se hoje desaparecesse o seu perfil de gráficos, conseguiria reconstruir o plano das últimas cinco operações? Se não, os níveis eram a fonte em vez de uma cópia e todo o processo depende do ficheiro de configuração de uma única aplicação.
Versionar em vez de corrigir continuamente. Uma regra alterada a meio da semana não pode ser avaliada. A ficha de alteração tem cinco campos, cabe em poucas linhas e vai para o registo do processo: data de entrada em vigor, observação que motivou a mudança, âmbito exato, critério de avaliação e validade mínima antes de voltar ao assunto. Sem esses cinco campos é uma reação, não uma decisão.
Para avaliar regras, os resultados anteriores e posteriores não formam uma amostra homogénea. Pode somar resultados financeiros totais, mas avalie a eficácia por versão do processo. São dois conjuntos apesar de a conta ser a mesma. Nos testes históricos o mesmo princípio determina se faz sentido dividir os dados em treino e validação; consulte o art. 11.7.
4. Entrada no processo: calendário, lista de acompanhamento e alertas
Por vezes são tratados como três fontes de sinais. No processo fazem o contrário: filtram e reduzem as situações que exigem atenção. Cada um responde a uma pergunta diferente; nenhum a «devo entrar?».
O calendário só responde se as condições mudam durante o seu horário de trabalho. Não para onde irá o mercado. Como ler os campos, de onde vem o consenso e porque «impacto» é uma etiqueta do fornecedor, não do mercado, é explicado no art. 11.3. Interpretar a publicação e o mercado em torno dos dados pertence ao art. 6.4. No fluxo fica uma atividade: passar para o plano as horas de publicação com o respetivo fuso, porque a conversão mental tende a causar erros de uma hora.
A lista de acompanhamento depende do tempo disponível, não do número de instrumentos. Faz sentido dividi-los pelo papel: os que negoceia, os que observa para contexto e os que aguardam uma condição. Listas e layouts são tratados no art. 11.2. Importam duas coisas. Mudanças diárias sem regra escrita de rotação são difíceis de auditar e podem refletir só o que chamou a atenção; mudanças conformes a uma regra são legítimas. Para verificar, guarde a lista fechada do dia com data, como exportação, captura ou cópia do ficheiro no arquivo de anexos. A lista ativa só mostra hoje, não como era ontem.
Um alerta é uma condição que, ao cumprir-se, gera um evento e uma notificação, não uma ordem. Onde é avaliada depende da ferramenta e deve ser verificado para cada uma, sem transferir regras entre programas. A ajuda TradingView descreve alertas criados e disparados nos servidores da plataforma, que funcionam mesmo após fechar a página do gráfico[1]. A ajuda MetaTrader 4 atribui esse papel à aplicação em execução: após criar os alertas, o «terminal cliente» informa do evento[2], pelo que fechar o terminal significa não receber notificações. MetaTrader 5 diz o mesmo e acrescenta um detalhe decisivo: a condição horária é definida na hora local do computador[3]. É a dependência que a secção 11 pede para verificar nas proteções; resolve-se na documentação da ferramenta. Um alerta não envia ordens, não reserva preços nem confirma que, ao notificar, seja possível negociar no nível que o disparou. A cadeia completa de condição a ordem é analisada no art. 11.2; no fluxo aplicam-se três regras de organização:
- Um nível, um alerta, salvo redundância planeada. Cobrir o mesmo nível na plataforma e no terminal sem papéis definidos gera dois eventos com horas diferentes e mais estados a acompanhar. A redundância deliberada de canais independentes pode fazer parte da emergência, mas exige quatro decisões prévias: canal principal, reserva, reconhecimento do mesmo evento e verificação do funcionamento da reserva. Sem isso é ruído, não proteção; nunca pode provocar uma segunda execução.
- O texto reconstrói o contexto. Um nível isolado nada diz após três semanas. Escreva cenário, nível de invalidação e referência ao plano na mensagem.
- Um alerta tem validade. Um nível de há semanas pode ter perdido o contexto. Seis semanas são um prazo de trabalho proposto, não um limiar medido. Validade ou revisão periódica custam menos do que reagir a uma notificação cujo motivo já não recorda.
Convém decidir antes onde chega a notificação. Um alerta no telefone inicia outro procedimento que um no ecrã de trabalho. Essa decisão de desenho é descrita pelo lado do dispositivo no art. 11.4.
5. Plano da operação e lista de execução
O plano fornece o denominador da revisão. Começar com calma e ordenar as ideias são efeitos secundários, não o motivo. Se após uma semana não permite ler o que devia acontecer, não saberá se a execução correspondeu à intenção: avaliará a memória, não o processo.
O mínimo são sete campos, todos preenchidos antes de enviar a ordem:
- Instrumento e condição de entrada escrita para poder ser resolvida numa palavra. «Rutura de consolidação» não é uma condição; «fecho da vela horária acima do nível X» é.
- Nível de invalidação da tese — preço ou evento que invalida a tese independentemente do resultado atual. Pode ser uma publicação, fecho do outro lado do nível ou passagem do tempo; uma condição assim não pode ser enviada ao corretor como ordem.
- Nível protetor previsto — registado separadamente da invalidação. Após executar, acrescente o nível confirmado pelo servidor. Podem diferir; só a ordem confirmada tem equivalente no histórico. Confundi-los significa comparar o plano com um registo que nunca existiu.
- Dimensão da posição e fundamento. O número não basta: após um mês não reconstruirá a origem. O método para dimensão e limites está na secção 9; aqui só importa produzi-lo antes da ordem e registá-lo com os pressupostos.
- Condição de cancelamento — situação em que não entra apesar de cumprir a condição: custo fora da norma, publicação no horário ou falta de tempo para monitorizar.
- Hora do registo com fuso horário — permite ordenar depois plano, alerta e execução com horas diferentes.
- Identificador da entrada — formato livre, mas idêntico no nome da captura, mensagem do alerta e diário. Não chega automaticamente à ordem: é outra atividade, descrita abaixo.
O ponto sete parece burocracia e custa pouco. Liga registos e arquivo num rasto do diário ao plano anterior. Sem identificador comum, cada relação tem de ser reconstruída pela hora e instrumento, cada vez mais difícil com o aumento das operações.
O identificador do plano não é o da ordem. O histórico numera separadamente ordem, execução e posição e desconhece o identificador do plano. É tentador colocá-lo no comentário, mas este não é fiável sem reservas: pode ter limite de tamanho e o servidor pode truncá-lo, substituí-lo ou acrescentar marcas ao modificar ou fechar parcialmente. A solução duradoura é um mapa no plano: o identificador junto aos de ordem, execução e posição copiados do histórico ao completar o diário. Esse mapa, não o comentário, liga o plano ao artefacto da medição de completude da secção 12.
O registo de decisão acrescentado ao plano. Os sete campos são criados antes da ordem. Quando o alerta dispara acrescenta-se uma linha ao mesmo registo: hora com fuso, identificador do plano, entrar ou cancelar e, no cancelamento, a condição causadora. Uma linha basta para separar de forma verificável «condição cumprida» de «entrei». Sem ela, entrada e cancelamento deliberado deixam o mesmo rasto: nenhum; a revisão só vê operações realizadas.
A lista de execução não é o plano. O plano descreve a operação; a lista controla atividades. Deve ser binária, curta e executada na mesma janela de envio: se exige mudar de aplicação, será omitida precisamente quando devia ajudar. Costumam bastar quatro pontos: parâmetros conformes ao plano, dimensão calculada, publicação da lista no horário e posição já aberta com a mesma exposição. Os modelos para antes da sessão, antes da operação, fim do dia e fim da semana estão no conjunto de listas de verificação das ferramentas, pelo que não são repetidos aqui.
O sinal típico: marca depois de abrir ou deixa de o fazer quando «não há tempo». Ambos significam que a lista é um extra, não parte do procedimento de envio.
6. Monitorização, diário e arquivo de anexos
A posição aberta é especial: só aqui o resultado muda perante quem não o deveria comentar. A proteção é procedimental: escrever antes três coisas: o que observa, quando e o que pode alterar exatamente o estado da posição. A regra pode ser «rever no fecho horário e numa publicação da lista», ou outra; importa escrevê-la antes da sessão. Que regras de gestão fazem sentido é determinado num artigo específico sobre gestão de posições; o fluxo só assegura que estejam escritas antes e se possa verificar depois se foram cumpridas.
O diário só funciona quando separa resultado e qualidade de execução. Um registo só com lucros e perdas é um extrato com outro nome. A importação fornece parâmetros reais e hora do servidor; os campos manuais classificam configuração, motivo de saída, existência e direção dos desvios e momento da intervenção: se mudanças na posição, incluindo o fecho, ocorreram nas revisões previstas ou fora. Esse campo tem de ser criado por si; nenhuma exportação o substitui. Se existe motivo de operação exportado, indica a origem da ordem ou causa técnica da execução, não o cumprimento do horário. MQL5 descreve a propriedade DEAL_REASON com a frase «Uma execução pode resultar da ativação de uma ordem enviada por aplicação móvel ou programa MQL5, bem como de um evento StopOut, cálculo de margem de variação, etc.». Enumera «ativação de ordem de terminal de computador», «… de aplicação móvel», «… de plataforma web», «… de programa MQL5, ou seja, Expert Advisor ou script», depois ativação de Stop Loss, Take Profit, Stop Out, rollover, cálculo de margem de variação, split e evento societário[7]. São fontes e causas técnicas, não se o fecho ocorreu numa revisão prevista. Preencha por isso à mão «momento da intervenção»: «sem intervenção» para evolução conforme o plano, «no momento previsto» ou «fora do plano» se uma só intervenção ocorreu fora. Estrutura completa, problemas de importação — fuso, fechos parciais, ajustes, depósitos e levantamentos — e métricas estão no art. 11.6.
O arquivo de anexos não é um quarto registo: guarda anexos aos três registos, como capturas, listas datadas e exportações. Muitas vezes só se lembra tarde demais. Uma captura vale se permite reconstruir o contexto: instrumento visível, período, hora e escala. Um gráfico sem estes elementos é decoração. Bastam três regras para encontrar depois o material:
- O nome do ficheiro começa pelo identificador do plano. Uma pasta por datas é uma coleção de imagens; por identificadores, um índice.
- Duas capturas por operação — ao escrever o plano e após fechar. Tire uma terceira num desvio deliberado: os dados não reconstroem o que via no ecrã nesse momento.
- Exportação periódica do histórico. O alcance do histórico no terminal e painel depende do corretor e tipo de conta. Verifique a especificação e programe exportações com margem, antes de descobrir que já não acede a dados de há dois anos.
7. Revisão e alteração do processo após uma decisão documentada
A revisão tem três ciclos com períodos e, sobretudo, temas diferentes. Misturá-los explica porque «revejo todas as semanas» pode ser verdade e não produzir efeito.
| Ciclo | Quando | A que pergunta responde | O que deixa |
|---|---|---|---|
| Após a sessão | No mesmo dia | Se o registo está completo: entrada, capturas e classificação | Um registo completado no diário |
| Semanal | Hora fixa, independentemente do resultado semanal | Se a execução correspondeu aos planos registados e onde difere | Lista de desvios e respetiva direção no registo do processo |
| Trimestral | Fim do trimestre | Se o processo completo funciona e o que pode ser eliminado | Ficha de alteração ou registo «sem alterações», ambos no registo do processo |
Cada ciclo deixa uma entrada com data e identificador da própria revisão. A convenção é livre mas constante, por exemplo REV-2026-W34 para uma revisão semanal. Sem essa marca o resultado tem origem desconhecida e uma revisão sem conclusões parece outra que nunca ocorreu.
No ciclo semanal importa uma distinção fácil de ignorar: um desvio favorável continua a ser um desvio. Fechar antes do plano com lucro pertence à mesma classe de evento que mover a invalidação. Se só conta desvios com perdas, mede resultado, não conformidade.
O ciclo trimestral trata do processo, não dos resultados. Convém respeitar esse limite: resultados da estratégia, métricas e curva de capital pertencem ao art. 11.6. A revisão do processo pergunta que passos executa ou omite, quanto demoram e o que deixou de ser necessário.
Porque a alteração exige registo, não só decisão. Quanto mais variantes testa no mesmo histórico, maior a probabilidade de a melhor o parecer por acaso. A literatura descreve-o nos testes de estratégias[5]; a nota só cobre esse âmbito. Ainda assim, pode surgir seleção análoga nas regras do processo: a décima alteração avaliada nas mesmas trinta operações não é a décima conclusão, mas o décimo sorteio. A ficha conta a baixo custo quantas vezes alterou regras e com que fundamento.
8. Fluxos manual e sistemático: duas arquiteturas
O percurso da secção 2 muda conforme decide uma pessoa ou o código. Não pelo número de ferramentas, mas pela falha característica e como a reconhecer.
A variante manual baseia-se em cinco funções, não marcas. A ordem é enviada num terminal ligado ao servidor do corretor (art. 11.1). Análise e alertas ficam no ambiente gráfico (art. 11.2). Fonte do calendário e calculadora de dimensão são tratadas no art. 11.3, e as calculadoras prontas estão na secção de ferramentas. A quinta função regista plano e resultado: os registos da secção 3.
Preparar não é uma hora do dia, mas uma lista de artefactos. Antes de executar devem existir quatro registos: horas e fuso das publicações no plano; lista diária fechada, datada e guardada; alertas completos que apontem para o plano; e plano de sete campos da secção 5 para cada configuração prevista. É binário: ou estão registados ou não houve preparação, por muitas horas no gráfico. Durante a execução acrescenta-se uma decisão por alerta, sobretudo no cancelamento. Depois fica um artefacto: diário completo por cada posição fechada.
Os horários diários e semanais, separados para emprego a tempo inteiro e trabalho numa sessão, estão no recurso com listas de verificação e fluxo semanal. Copiá-los duplicaria material e perderia o sentido: o horário deve seguir o seu calendário, não o de outra pessoa.
A variante sistemática tem nove elementos e outros riscos: dados → repositório → ambiente de execução → teste histórico → teste forward ou demonstração → implementação → monitorização → registos → revisão. A decisão não passa para a mudança de código: esta é a etapa onze, alterar o processo. A decisão continua em tempo real, através de uma regra, e deixa a cadeia sinal → decisão do algoritmo → validador de limites → pedido ao corretor → resposta do servidor, com cada elo registado separadamente para localizar depois a falha. Versionar pertence à etapa onze e é condição para reconstruir as regras de uma semana, não só boa prática. O ambiente reproduzível está no art. 11.8, o procedimento de teste e período forward separado — por exemplo no tester MetaTrader 5 — no art. 11.7[6], e implementação, registos, identificação de posições próprias e continuidade no art. 11.5.
| Dimensão | Fluxo manual | Fluxo sistemático |
|---|---|---|
| Fonte de verdade do plano | Registo do plano preenchido antes da ordem | Versão do código com número e data de implementação |
| Fonte de verdade da execução | Importação do histórico e campos de classificação | Registo da aplicação reconciliado com o histórico |
| O que se versiona | Regras descritas por palavras | Manifesto de implementação: commit, configuração, ficheiro de bloqueio de dependências, versão dos dados e cópia da especificação do símbolo |
| Como se para | Não envia a ordem | Desativar permissões de negociação, paragem de emergência, parar o processo |
| Falha característica | Passo omitido sob pressão | Mudança silenciosa: versão do pacote, especificação do símbolo, nova ligação após sessão interrompida |
| Como se deteta | Existe operação mas falta o plano | A diferença entre registo e histórico deteta erros de execução, não mudanças silenciosas: estas exigem comparar o manifesto atual com o anterior |
9. Conjunto mínimo e teste de ferramentas redundantes
O conjunto descreve-se por funções, não marcas: ordens, análise e alertas, calendário, cálculo da dimensão e registo do plano e resultado. Uma aplicação pode cobrir duas e deixar quatro elementos em vez de cinco. Os ícones nada medem: importa que cada função tenha um local definido e único.
Quatro configurações de exemplo. Não são recomendações nem classificação. Cada conjunto nasce de um critério explícito: mostra como determina a composição e quanto custa. «A melhor ferramenta» sem critério é uma frase vazia, impossível de verificar.
| Critério de seleção | Composição | O que custa o critério |
|---|---|---|
| Sem custo fixo | Terminal do corretor também para gráficos; calendário do fornecedor; folha com fórmula como calculadora e registo de plano e execução | Análise e execução partilham janela: a separação é procedimental. Crie o plano na folha antes de abrir a ordem; complete a execução à mão |
| Análise separada da execução | Gráficos com alertas separados; terminal só para ordens; calendário; calculadora; diário com importação do histórico | Subscrição fixa e segundo ambiente a manter. Acesso do serviço só de leitura com palavra-passe de investidor |
| Trabalhar longe de um computador | Terminal no computador; aplicação móvel só para confirmar estado e fechar em emergência; alertas no telefone; calendário e calculadora no navegador de ambos; registos acessíveis nos dois | O móvel costuma ter menos funções: decida antes o que permite fazer nele (art. 11.4) |
| Regras em código | Repositório, ambiente de execução, tester, alojamento contínuo; calendário e dimensão no código com os mesmos parâmetros das regras; registos reconciliados com histórico | Aumentam os elementos que podem mudar sem o saber. Sem limites deterministas, paragem e monitorização não serve para uma conta real (art. 11.5) |
Teste de ferramentas redundantes. Desligue-a um mês, período convencional proposto para abranger vários ciclos semanais, e escreva que passo não consegue executar sem ela. Se nenhum, está ao lado do processo, não dentro. Face a «é útil?», a vantagem é um resultado demonstrável um trimestre depois: lista de passos, não declaração sem artefacto. Acrescentar funciona ao contrário: entra uma ferramenta quando identifica um passo hoje pior executado e como mudará. «Outros usam» não identifica um passo.
O que o teste não abrange. Não desligue monitorização de posições, canal de emergência da secção 11, cópias dos registos nem limites deterministas ou paragem. As proteções testam-se numa cópia ou demonstração, nunca desativando-as em real com posições abertas. O teste encontra ferramentas fora do processo, não quanto aguenta sem proteção.
10. Automatizar tarefas repetitivas de baixo risco
O critério exige quatro condições simultâneas: repetição, determinismo, erro detetável e consequências reversíveis. Se falta uma, não é candidata a automatizar, por muito que demore à mão.
No «sim» estão tarefas aborrecidas e por isso valiosas: notificações, importação do histórico, cópias dos registos, configurações e capturas, fórmulas repetíveis à mão e relatórios com métricas definidas. O erro deteta-se automaticamente se o controlo integra a automação: número importado face à fonte, soma de verificação da cópia ou alarme se faltar um ficheiro à hora prevista. Uma cópia danificada ou incompleta é a exceção ao erro imediatamente visível: parece correta até restaurar. Por isso permanece o teste periódico de restauro da secção 11, além dos controlos automáticos.
No «não» ficam por agora três coisas. Decidir entradas e saídas até a regra passar o procedimento do art. 11.7. Classificar os seus desvios, cujo valor está no julgamento, não em preencher uma coluna. E qualquer atividade que não saiba executar à mão: não porque automatizar seja mau, mas porque não reconhecerá quando começa a fazê-la mal.
A automação escala nos dois sentidos. Uma regra errada repete as consequências mais depressa e sem hesitar: limites deterministas, paragem e monitorização têm de existir antes da implementação, não após a primeira falha; consulte o art. 11.5, e para o código executor o art. 11.8.
11. Procedimento de emergência e cópia da configuração
Uma falha não é excecional, mas rara: quando ocorrer estará sem prática. Por isso o procedimento deve ser curto e escrito. Nas ferramentas tem cinco passos e a ordem faz parte dele:
- Confirme o estado por um canal diferente do que falhou. Aplicação móvel, painel do cliente ou chamada ao corretor: qualquer via sem o mesmo elemento. Configuração e limites da reserva estão no art. 11.4.
- Pare a automação antes de reparar o que quer que seja. Desativar permissões ou parar o processo é mais rápido do que diagnosticar e não exige entender a causa. Diagnosticar enquanto funciona muda as condições que está a observar.
- Verifique posições abertas e ordens pendentes no corretor, não na cópia local. Após perder a ligação, o terminal mostra o último estado conhecido, não necessariamente o atual.
- Registe o incidente enquanto ocorre, não depois. Hora e fuso, o que falhou, o que viu, o que fez, estado anterior e posterior. Uma hora depois fica uma impressão, não comparável com registos ou histórico.
- Retome só após confirmar que o estado do corretor coincide com o seu registo. Reiniciar antes de reconciliar o estado leva diretamente a duplicar posições.
O plano completo — encaminhamento de casos, contactos, formulário de incidente e registo dos testes trimestrais — está no plano de emergência das ferramentas. Aqui ficamos nas ferramentas, o único âmbito desta secção.
Verifique uma vez fora de uma emergência: que proteções residem no servidor e quais exigem uma aplicação ativa. Determina o que ocorre ao desligar ou perder a ligação. Depende de plataforma, modo e corretor; para configurações concretas consulte o art. 11.4 e o art. 11.5 correspondentes.
Cópia da configuração é a outra metade do procedimento: quanto demora reconstruir após perder o computador. A lista é curta: listas, modelos gráficos, alertas com mensagens, três registos da secção 3, anexos e credenciais num gestor de palavras-passe, nunca em texto. A localização depende do ambiente: pode existir um ficheiro copiável ou nenhum. A matriz reflete a documentação verificada em 22 de agosto de 2026; reconfirme para as suas ferramentas antes de considerar completa a cópia.
| Produto e variante | Onde reside | Como exportar | Como restaurar |
|---|---|---|---|
| Terminal MetaTrader 5 de computador: modelos e perfis | Em ficheiros na pasta de dados. Ajuda: «Os modelos são guardados como TPL em [\MQL5\Profiles\Templates]» e «Todos os perfis estão em [\MQL5\Profiles\Charts]»[8] | Copiar essas pastas. Também se documenta sincronização: «Para partilhar e sincronizar modelos e perfis entre plataformas use MQL5 Algo Forge, integrado no MetaEditor»[8] | Colocar ficheiros na pasta de dados da nova instalação ou descarregá-los da sincronização |
| Gráficos no navegador (TradingView): layout | Na conta, não num ficheiro local. Ajuda: «Um layout contém gráficos, definições, desenhos e indicadores e é identificado por um URL único»[9] | A documentação não descreve guardar o layout num ficheiro do utilizador | Entrar e abrir o layout guardado recupera definições, mas não é cópia independente nem protege contra eliminação |
| TradingView: listas de acompanhamento | Fora do layout. Ajuda: «Listas e alertas não são guardados nos layouts»[9] | Exportar para texto: «Download list as TXT». Ao importar: «O ficheiro deve ser .txt, com prefixo da bolsa e símbolos separados por vírgulas»[10] | Carregar TXT através da função indicada na ajuda |
| TradingView: alertas | Fora do layout[9] e do computador: são criados e disparados nos servidores da plataforma[1] | A documentação não descreve exportar alertas para ficheiros | Recriá-los à mão; mensagem e ligação ao plano ficam no registo, não só na ferramenta |
| Três registos e arquivo de anexos | Onde criados: ficheiro local, unidade de rede ou serviço | Depende do meio; a cópia tem de ser sua, não só do fornecedor | Restaurar e comparar número de registos e somas com o original |
A conclusão: «copiar ficheiros de configuração» não basta, pois alguns não existem. Para definições na conta, recuperar exige acesso protegido e registo independente do que não volta sozinho: sobretudo textos dos alertas e ligações ao plano.
12. Auditoria do fluxo: quatro medições em vez de uma impressão
A revisão trimestral só faz sentido se terminar em números. «Sinto-me melhor» não é comparável ao trimestre anterior. As quatro medições são um mínimo proposto, não uma lista fechada. Cada uma define grandeza, âmbito e fonte, e denominador e limiar convencional quando fizer sentido. Só duas têm os cinco elementos: o tempo não tem limiar absoluto e a redundância não tem denominador; a tabela explicita-o. Sem grandeza definida, âmbito e fonte não há comparação trimestral. As duas primeiras vêm dos registos existentes. As outras exigem um registo extra cada: tempos datados e resultado datado de redundância, ambos no registo do processo. Os limiares são pontos de partida convencionais para comparar consigo próprio, não padrões medidos.
| Medição | Numerador e denominador | Unidade e âmbito | Fonte de dados | Limiar convencional e resposta abaixo |
|---|---|---|---|---|
| Completude do registo | Numerador: operações com plano anterior à abertura. Denominador: todas as fechadas no período | % das operações, trimestre | Plano reconciliado com histórico pelo mapa de identificadores de plano, ordem, execução e posição da secção 5 | Limiar convencional 95 %. Abaixo, antecipe o registo ou reduza instrumentos, com ficha de alteração. Não encurte o plano: os sete campos da secção 5 já são mínimos |
| Conformidade da execução | Numerador: operações sem desvio segundo definição prévia. Denominador: operações com plano anterior à abertura | % das operações, trimestre | Campos do diário: desvio ao plano e momento da intervenção | Limiar convencional 90 %. Abaixo, procure concentração de desvios em certas condições e acrescente-as como cancelamento, com ficha da secção 3, não correção improvisada |
| Tempo do processo | Mediana da preparação e, separadamente, da revisão, um valor por dia de negociação da semana de controlo | Minutos, semana de controlo no trimestre | Registo datado do início e fim da preparação e revisão na semana de controlo, no processo, não de memória | Sem limiar absoluto; compare com o seu trimestre anterior. Se sobe, simplifique com ficha antes de abandonar: um procedimento abandonado não tem versão leve |
| Redundância de ferramentas | Numerador: ferramentas cuja desativação não bloqueou passos. Sem denominador: número absoluto do conjunto por funções da secção 9 | Elementos, trimestre | Resultado datado do teste da secção 9 no registo do processo | Limiar convencional zero. Acima, elimine ou atribua um passo concreto, com ficha nos dois casos; verifique no próximo trimestre |
As quatro medem deliberadamente o processo, incluindo redundância. Pode haver bom resultado com mau processo num trimestre de poucas operações; também processo diligente com perdas. Separar os juízos permite corrigir o que falhou após um período fraco, em vez de substituir as ferramentas à mão.
Antes de seguir, conte quantas das últimas cinco operações tinham plano antes de abrir. A percentagem usa a definição de completude, mas com cinco operações em vez de um trimestre: é o ponto inicial para comparar daqui a um trimestre. Verifique também captura e registo classificado, mas anote à parte: são medidas e unidades diferentes, não se somam.
O processo opera em condições definidas por outros: preços, histórico disponível, plataformas e destino da ordem enviada dependem do corretor. Aí começa a próxima secção do curso.
Perguntas frequentes — fluxo de trabalho de trading
Por onde começar se hoje não tenho processo?
Análise e execução têm de estar em duas aplicações?
Com que frequência posso alterar o fluxo?
Quantas ferramentas são demasiadas?
Um modelo de IA pode gerir parte do fluxo?
O que fazer se a plataforma não responde com uma posição aberta?
Preciso de outro fluxo numa semana de publicações importantes?
Fontes e referências
Os dados dos produtos foram verificados em 22 de agosto de 2026 na documentação dos fornecedores. Funções, limites, integrações e preçários mudam com versões e não ficam fixados aqui; os mecanismos duram mais. Antes de decidir consulte o estado atual nestas fontes primárias.
- TradingView Help Center, "Alerts are server-side" — tradingview.com/support/solutions/43000548327. Documentação: os alertas são criados e disparados nos servidores, independentemente do navegador. Verificado 2026-08-22.
- MetaQuotes Software Corp., "Alerts" — ajuda MetaTrader 4: metatrader4.com/en/trading-platform/help/overview/terminal/terminal_alerts. Documentação: «Os alertas sinalizam eventos do mercado» e «Após criá-los pode deixar o monitor: o terminal cliente informa automaticamente do evento do servidor». O terminal ativo vigia a condição. Verificado 2026-08-22.
- MetaQuotes Software Corp., "Executing Trades" — ajuda MetaTrader 5, secção Alertas: metatrader5.com/en/terminal/help/trading/performing_deals. Documentação: «Os alertas notificam eventos de mercado. Após criá-los pode deixar o monitor e a plataforma avisará automaticamente». A condição horária usa a hora local do computador e uma ação possível é iniciar um ficheiro executável. Verificado 2026-08-22.
- TradingView Help Center, "Strategy alerts" — tradingview.com/support/solutions/43000481368. Fonte da cópia de configuração no servidor criada ao configurar o alerta, não modificada por mudanças posteriores no gráfico. Verificado 2026-08-22.
- Bailey, D.H., Borwein, J.M., López de Prado, M., Zhu, Q.J. (2014). "Pseudo-Mathematics and Financial Charlatanism: The Effects of Backtest Overfitting on Out-of-Sample Performance". Notices of the American Mathematical Society, 61(5), 458–471. Estudo metodológico do efeito do número de variantes na interpretação do melhor resultado; aqui só justifica registar alterações, não afirmações sobre estratégias.
- MetaQuotes Software Corp., "Strategy Tester" — ajuda MetaTrader 5: metatrader5.com/en/terminal/help/algotrading/testing. Período forward separado e modos de geração de ticks como elementos documentados do teste da variante sistemática. Verificado 2026-08-22.
- MetaQuotes Software Corp., "Deal Properties" — referência MQL5: mql5.com/en/docs/constants/tradingconstants/dealproperties. Fonte dos valores ENUM_DEAL_REASON: DEAL_REASON_CLIENT, MOBILE, WEB, EXPERT, SL, TP, SO, ROLLOVER, VMARGIN, SPLIT, CORPORATE_ACTION. Demonstra que o motivo regista origem da ordem ou causa técnica da execução. Verificado 2026-08-22.
- MetaQuotes Software Corp., "Templates and Profiles" — ajuda MetaTrader 5: metatrader5.com/en/terminal/help/charts_advanced/templates_profiles. Documentação: «Os modelos são TPL em [\MQL5\Profiles\Templates]», «Todos os perfis estão em [\MQL5\Profiles\Charts]» e «Para partilhar e sincronizar modelos e perfis entre plataformas use MQL5 Algo Forge, integrado no MetaEditor». Verificado 2026-08-22.
- TradingView Help Center, "Layouts, charts, drawings, indicators, and their interaction" — tradingview.com/support/solutions/43000692404. Documentação: «Um layout contém gráficos, definições, desenhos e indicadores e tem URL único» e «Listas e alertas não são guardados nos layouts». Verificado 2026-08-22.
- TradingView Help Center, "How to import and export watchlists" — tradingview.com/support/solutions/43000487233. Documentação: exportar com «Download list as TXT»; importar «ficheiro .txt com prefixo da bolsa e símbolos separados por vírgulas». Verificado 2026-08-22.
