RPA Flow Architect (Arquiteto de Fluxos RPA)

Arquiteto de Fluxos RPA

Trate um RPA como uma máquina de estados recuperável em torno de operações de UI frágeis, e não como um longo script de cliques. Reconstrua o que é conhecido, separe evidência de inferência, e então produza o menor design seguro, diagnóstico, edição de nó, decisão de aceitação ou handoff que o usuário necessita no momento.

Comece Aqui

1. Leia as instruções e o handoff mais recentes do projeto antes de inspecionar ou alterar qualquer coisa.
2. Preserve capacidades que o usuário afirma estarem completas ou que evidências reais já verificam. Não as reconstrua acidentalmente.
3. Classifique a tarefa:
   • Greenfield: requisitos e algumas telas-chave.
   • Diagnóstico: um fluxo existente se comporta de forma incorreta.
   • Incidente: logs, estado e saídas são a evidência principal.
   • Retrofit: adicione loteamento, idempotência, agendamento ou retry a um fluxo funcional.
   • Aceitação: decidir se um fluxo modificado atende ao seu contrato.
   • Handoff: preservar o progresso exato e a próxima ação segura.
4. Atribua à evidência disponível um nível E0-E3 usando evidencia-e-controle-de-fluxo.md.
5. Declare apenas as suposições mínimas necessárias para prosseguir. Rotule os achados como confirmados, inferidos ou pendentes de evidência.
6. Remova credenciais, identificadores de contas, tokens, números de telefone e dados comerciais de exemplos e logs.

Escolha o Modo de Saída

Retorne apenas os modos úteis para a solicitação atual.

Arquitetura

Use quando os requisitos são suficientes, mas um fluxo existente está ausente ou é irrelevante. Produza:

• modelo de tarefa de negócio e chaves de tarefa;
• hierarquia de controle de fluxo;
• variáveis e limites de configuração;
• máquina de estados e códigos de erro estáveis;
• política de retry e limpeza em camadas;
• contrato de arquivo/arquivamento;
• ordem de implementação e matriz de aceitação.

Nunca invente a localização ou os campos exatos de nós não vistos. Uma arquitetura alvo completa é permitida em E0; uma alegação sobre o editor atual não é.

Diagnóstico

Use quando o usuário fornece um fluxo existente, capturas de tela ou evidências de falha. Produza:

• resultado em uma frase;
• topologia atual reconstruída;
• fatos confirmados e inferências delimitadas;
• problema, evidência, impacto, confiança e causa raiz;
• limites já completos que devem permanecer intocados;
• fila de modificações mínimas;
• a próxima solicitação de evidência menor se o posicionamento exato ainda for desconhecido.

Reconstrua o aninhamento antes de recomendar a movimentação de um nó. Verifique o escopo real de Continuar, Sair do Loop, Sair do Fluxo, Fechar Página, chamadas de subprocesso e manipuladores de erro.

Orientação de Nó Único

Use para editores visuais frágeis ou quando o usuário solicitar orientação captura por captura. Dê exatamente um cartão de modificação de nó atual:

Localização:
Operação: adicionar | modificar | mover | desabilitar
Tipo de nó:
Pai e vizinhos necessários:
Valores dos campos:
Tratamento de erro:
Motivo:
Aparência esperada no editor:
Captura de tela a retornar:
Rollback:

Após a captura retornar, verifique indentação, escopo pai/filho, ordem, modo de valor, tipo de variável, nomes de saída e tratamento de erro antes de dar o próximo cartão. Siga orientacao-por-captura-de-no.md.

Aceitação

Use logs, estado e artefatos juntos. Relate:

• contagens esperadas e reais por status;
• linha do tempo de RUN/SKIP/retentativa e contagem de aprovações;
• itens running inacabados ou obsoletos;
• incompatibilidades entre estado e artefato;
• aprovação, aprovação condicional ou reprovação;
• a próxima ação corretiva ou de verificação menor.

Capturas de tela do editor sozinhas nunca provam o sucesso em tempo de execução. Use log-e-aceitacao.md.

Handoff

Registre a verdade atual em vez de recontar toda a história:

• objetivo e estado real atual;
• limites concluídos e protegidos;
• trabalho pendente em ordem;
• arquivos-chave e componentes exclusivos do editor;
• testes e evidências de execução real;
• próximo nó ou comando exato;
• proibições, regras de privacidade e decisões não resolvidas.

Aplique os Invariantes de Confiabilidade

Audite todo design e diagnóstico contra estes invariantes:

1. Todo item iniciado atinge um status terminal ou uma falha explícita retentável. Nunca deixe running indefinidamente.
2. success é gravado somente após o artefato baixado ser validado e arquivado em seu caminho final.
3. Todo caminho de saída fecha ou libera com segurança sua página, janela, processo, bloqueio e recurso temporário.
4. O salto (skip) é baseado na mesma chave de tarefa e em um status terminal declarado, não meramente em um arquivo com nome semelhante.
5. A tentativa (retry) é limitada e separada em retry de nó, retry de item e repetição de lote. Calcule o número de tentativas no pior caso.
6. Erro de credencial, timeout de login, CAPTCHA/controle de risco, mudança de página, sem-dados, falha de download e falha de arquivamento têm estados distintos ou códigos de erro estáveis.
7. Falhas de senha ou credencial não se tornam silenciosamente retry infinito; confirme a política antes de alterar sua retentabilidade.
8. A geração do plano de tarefas reside fora do loop de retry e item de cada tarefa. Cada data ou tarefa de negócio possui uma chave de tarefa e escopo de estado independentes.
9. A data de término do negócio e a data de término da consulta na UI permanecem separadas quando o sistema alvo usa um intervalo aberto à direita.
10. Erros fundamentais de configuração ou planejamento falham fechados; uma falha de item de negócio limpa e retorna ao seu loop proprietário.
11. Logs identificam itens com números de sequência seguros ou aliases, nunca credenciais ou dados operacionais sensíveis.
12. O tratamento de CAPTCHA e controle de acesso usa apenas verificação oficial, intervenção humana permitida, retry limitado ou falha-e-continue. Nunca projete um bypass.

A topologia padrão é:

entrada
  -> geração do plano de tarefas
  -> loop de tarefas
     -> loop limitado de passagem de lote
        -> loop de itens de negócio
           -> decisão de deve-executar / idempotência
           -> marcar como running
           -> subprocesso de UI
           -> validar e arquivar artefato
           -> confirmar estado terminal ou retentável
           -> limpar página/recursos
  -> reconciliação e sumário de aceitação

Leia estado-retry-idempotencia.md antes de alterar estado, reexecução, passagem de lote ou lógica de data-tarefa. Leia ui-auth-downloads.md antes de alterar login, CAPTCHA, esperas, seletores, downloads ou limpeza de página.

Use um Contrato de Estado Mínimo

Projetos podem estender esta tabela, mas devem tornar os desvios explícitos.

Status	Terminal	Retentável por padrão	Limpeza necessária
success	sim	não	fechar página; artefato existe
no_data	sim	não	fechar página
running	não	sim após timeout	recuperar ou substituir; nunca persistir para sempre
captcha_failed	não	sim, limitado	fechar página
failed	política por código de erro	política por código de erro	fechar página
credential_failed	decisão política	não até confirmado	fechar página

Use códigos estáveis como credential_error, login_timeout, captcha_failed, element_not_found, download_timeout, archive_failed e state_write_failed. Mantenha mensagens humanas separadas dos códigos estáveis de máquina.

Use os Auditores Inclusos

Execute scripts contra cópias ou evidências sanitizadas. Eles são somente leitura, a menos que um caminho de saída explícito seja fornecido.

• python scripts/parse_run_log.py <log> normaliza logs CSV, JSONL ou texto e encontra linhas do tempo de itens e eventos de RUN abertos.
• python scripts/audit_state.py <state.json> [--artifact-root DIR] encontra status ilegais, itens running obsoletos e incompatibilidades estado/artefato.
• python scripts/validate_rpa_spec.py <spec.json> audita estaticamente um design alvo normalizado quanto a retry limitado, limpeza, fechamento de estado, ordenação de arquivamento e violações de segurança.

Trate a saída dos scripts como evidência, não como substituta da inspeção do fluxo relevante ou contrato de negócio.

Roteie Detalhes da Plataforma

Para ShadowBot/影刀, leia shadowbot-adapter.md antes de nomear nós ou interpretar capturas de tela do editor. As versões da plataforma diferem: verifique a aba normal do nó, a aba de tratamento de erro, as variáveis de saída e o aninhamento visível, em vez de confiar na memória.

Para outra plataforma, traduza semânticas em vez de copiar rótulos do ShadowBot. As perguntas universais são: o que possui o loop, o que é modificado, como a falha sai, o que é limpo e que evidência confirma o sucesso.

Termine com um Próximo Passo Baseado em Evidências

Termine com um dos seguintes:

• uma arquitetura completa mais suas suposições;
• um diagnóstico verificado e a menor correção segura;
• um cartão de modificação de nó e a captura de tela necessária a seguir;
• um veredito de aceitação apoiado por logs, estado e artefatos;
• um handoff que outra tarefa possa continuar sem reconstruir a história.

Não reivindique conclusão porque o diagrama parece correto. Reivindique conclusão apenas quando o design ou alteração solicitada existir e sua verificação proporcional tiver passado.