RPA Flow Architect

¿Qué hace RPA Flow Architect?

Trata un RPA como una máquina de estado recuperable alrededor de operaciones frágiles de interfaz de usuario, no como un script largo de clics. Reconstruye lo que se conoce, separa la evidencia de la inferencia, luego produce el diseño más pequeño seguro, diagnóstico, edición de nodo, decisión de aceptación o traspaso que el usuario necesita en el momento.

Comience Aquí

1. Lea las instrucciones del proyecto más cercano y el traspaso antes de inspeccionar o cambiar cualquier cosa.
2. Preserve las capacidades que el usuario dice que están completas o que la evidencia real ya verifica. No las reconstruya incidentalmente.
3. Clasifique la tarea:
   • Greenfield: requisitos y algunas pantallas clave.
   • Diagnóstico: un flujo existente se comporta incorrectamente.
   • Incidente: registros, estado y salidas son la evidencia principal.
   • Retrofit: agregar procesamiento por lotes, idempotencia, programación o reintento a un flujo funcional.
   • Aceptación: decidir si un flujo modificado cumple con su contrato.
   • Traspaso: preservar el progreso exacto y la próxima acción segura.
4. Asigne a la evidencia disponible un nivel E0-E3 usando evidence-and-control-flow.md.
5. Indique solo las suposiciones mínimas necesarias para proceder. Etiquete los hallazgos como confirmados, inferidos o pendientes de evidencia.
6. Redacte credenciales, identificadores de cuenta, tokens, números de teléfono y datos comerciales de ejemplos y registros.

Elija el Modo de Salida

Devuelva solo los modos útiles para la solicitud actual.

Arquitectura

Úselo cuando los requisitos sean suficientes pero un flujo existente esté ausente o sea irrelevante. Produzca:

• modelo de tarea comercial y claves de tarea;
• jerarquía de flujo de control;
• variables y límites de configuración;
• máquina de estado y códigos de error estables;
• política de reintento y limpieza en capas;
• contrato de archivo/almacenamiento;
• orden de implementación y matriz de aceptación.

Nunca invente la ubicación o los campos exactos de nodos no vistos. Se permite una arquitectura objetivo completa en E0; no se permite una afirmación sobre el editor actual.

Diagnóstico

Úselo cuando el usuario proporcione un flujo existente, capturas de pantalla o evidencia de fallo. Produzca:

• resultado de una oración;
• topología actual reconstruida;
• hechos confirmados e inferencias acotadas;
• problema, evidencia, impacto, confianza y causa raíz;
• límites ya completos que deben permanecer intactos;
• cola de modificación mínima;
• la próxima solicitud de evidencia más pequeña si la ubicación exacta aún se desconoce.

Reconstruya el anidamiento antes de recomendar un movimiento de nodo. Verifique el alcance real de Continuar, Salir del Bucle, Salir del Flujo, Cerrar Página, llamadas a subprocesos y manejadores de errores.

Guía de Un Nodo

Úselo para editores visuales frágiles o cuando el usuario solicite guía captura de pantalla por captura de pantalla. Proporcione exactamente una tarjeta de modificación de nodo actual:

Ubicación:
Operación: agregar | modificar | mover | deshabilitar
Tipo de nodo:
Padre y vecinos requeridos:
Valores de campo:
Manejo de errores:
Motivo:
Apariencia esperada en el editor:
Captura de pantalla a devolver:
Retroceso:

Después de que se devuelva la captura de pantalla, verifique la indentación, el ámbito padre/hijo, el orden, el modo de valor, el tipo de variable, los nombres de salida y el manejo de errores antes de dar la siguiente tarjeta. Siga screenshot-node-guidance.md.

Aceptación

Use registros, estado y artefactos juntos. Informe:

• recuentos esperados y reales por estado;
• línea de tiempo de EJECUTAR/SALTAR/REINTENTAR y recuento de pases;
• elementos running pendientes o desactualizados;
• discrepancias entre estado y artefacto;
• pasar, pasar condicional o fallar;
• la siguiente acción correctiva o de verificación más pequeña.

Las capturas de pantalla del editor por sí solas nunca prueban el éxito en tiempo de ejecución. Use logging-and-acceptance.md.

Traspaso

Registre la verdad actual en lugar de volver a contar toda la historia:

• objetivo y estado real actual;
• límites completados y protegidos;
• trabajo pendiente en orden;
• archivos clave y componentes solo del editor;
• pruebas y evidencia de ejecución real;
• próximo nodo o comando exacto;
• prohibiciones, reglas de privacidad y decisiones no resueltas.

Aplique los Invariantes de Fiabilidad

Audite cada diseño y diagnóstico contra estos invariantes:

1. Cada elemento iniciado alcanza un estado terminal o un fallo explícito reintentable. Nunca deje running indefinidamente.
2. success se escribe solo después de que el artefacto descargado sea validado y archivado en su ruta final.
3. Cada ruta de salida cierra o cede de forma segura su página, ventana, proceso, bloqueo y recurso temporal.
4. El salto se basa en la misma clave de tarea y un estado terminal declarado, no meramente en un archivo con nombre similar.
5. El reintento está acotado y separado en reintento de nodo, reintento de elemento y repetición de lote. Calcule el número de intentos del peor caso.
6. Error de credencial, tiempo de espera de inicio de sesión, CAPTCHA/control de riesgo, cambio de página, sin datos, fallo de descarga y fallo de archivo tienen estados distintos o códigos de error estables.
7. Los fallos de contraseña o credencial no se convierten silenciosamente en reintento infinito; confirme la política antes de cambiar su capacidad de reintento.
8. La generación del plan de tarea se sitúa fuera de los bucles de reintento y elemento de cada tarea. Cada fecha o tarea comercial posee una clave de tarea y ámbito de estado independientes.
9. La fecha de finalización comercial y la fecha de finalización de la consulta de UI permanecen separadas cuando el sistema objetivo utiliza un intervalo abierto por la derecha.
10. Los errores de configuración o planificación fundamentales fallan en cerrado; un fallo de elemento comercial se limpia y regresa a su bucle propietario.
11. Los registros identifican elementos con números de secuencia seguros o alias, nunca credenciales o datos operativos sensibles.
12. El manejo de CAPTCHA y control de acceso utiliza solo verificación oficial, intervención humana permitida, reintento acotado o fallar y continuar. Nunca diseñe una evasión.

La topología predeterminada es:

entrada
  -> generación del plan de tarea
  -> bucle de tarea
     -> bucle de paso de lote acotado
        -> bucle de elemento comercial
           -> decisión de debe-ejecutar / idempotencia
           -> marcar en ejecución
           -> subproceso de UI
           -> validar y archivar artefacto
           -> confirmar estado terminal o reintentable
           -> limpiar página/recursos
  -> reconciliación y resumen de aceptación

Lea state-retry-idempotency.md antes de cambiar estado, re-ejecución, paso de lote o lógica de fecha-tarea. Lea ui-auth-downloads.md antes de cambiar inicio de sesión, CAPTCHA, esperas, selectores, descargas o limpieza de página.

Use un Contrato de Estado Mínimo

Los proyectos pueden extender esta tabla, pero deben hacer explícitas las desviaciones.

Estado	Terminal	Reintentable predeterminado	Limpieza requerida
success	sí	no	cerrar página; el artefacto existe
no_data	sí	no	cerrar página
running	no	sí después de tiempo de espera	recuperar o reemplazar; nunca persistir para siempre
captcha_failed	no	sí, acotado	cerrar página
failed	política por código de error	política por código de error	cerrar página
credential_failed	decisión de política	no hasta que se confirme	cerrar página

Use códigos estables como credential_error, login_timeout, captcha_failed, element_not_found, download_timeout, archive_failed y state_write_failed. Mantenga los mensajes humanos separados de los códigos estables de máquina.

Use los Auditores Incluidos

Ejecute scripts contra copias o evidencia sanitizada. Son de solo lectura a menos que se proporcione una ruta de salida explícita.

• python scripts/parse_run_log.py <log> normaliza registros CSV, JSONL o texto plano y encuentra líneas de tiempo de elementos y eventos RUN abiertos.
• python scripts/audit_state.py <state.json> [--artifact-root DIR] encuentra estados ilegales, elementos running obsoletos y discrepancias estado/artefacto.
• python scripts/validate_rpa_spec.py <spec.json> audita estáticamente un diseño objetivo normalizado para reintento acotado, limpieza, cierre de estado, orden de archivado y violaciones de seguridad.

Trate la salida del script como evidencia, no como un sustituto para inspeccionar el flujo relevante o el contrato comercial.

Detalles de Ruta de Plataforma

Para ShadowBot/影刀, lea shadowbot-adapter.md antes de nombrar nodos o interpretar capturas de pantalla del editor. Las versiones de plataforma difieren: verifique la pestaña normal del nodo, la pestaña de manejo de errores, las variables de salida y el anidamiento visible en lugar de confiar en la memoria.

Para otra plataforma, traduzca semánticas en lugar de copiar etiquetas de ShadowBot. Las preguntas universales son: ¿qué posee el bucle?, ¿qué se muta?, ¿cómo sale el fallo?, ¿qué se limpia?, ¿qué evidencia confirma el éxito?

Finalice con un Próximo Paso Acotado por Evidencia

Termine con uno de los siguientes:

• una arquitectura completa más sus suposiciones;
• un diagnóstico verificado y la corrección segura más pequeña;
• una tarjeta de modificación de un nodo y la captura de pantalla necesaria a continuación;
• un veredicto de aceptación respaldado por registros, estado y artefactos;
• un traspaso que otra tarea pueda continuar sin reconstruir la historia.

No reclame finalización porque el diagrama se vea correcto. Reclame finalización solo cuando el diseño o cambio solicitado exista y su verificación proporcional haya pasado.