judicial-recon

name

judicial-recon

description

Reconocimiento de portales judiciales con browser automatizado. Explora cualquier sistema judicial, descubre APIs ocultas, mapea datos disponibles, y genera un reporte de viabilidad técnica. Usar cuando el usuario pida: analizar o mapear un portal judicial, descubrir APIs en un sistema de justicia, evaluar viabilidad de automatización, o reverse-engineer un sitio de tribunales. Triggers: "explorá este portal", "qué APIs tiene", "reconocimiento judicial", "mapear portal", "es posible automatizar", o nombres de portales como "SISFE", "JusCABA", "EJE", "MEV", "Lex100". Requiere browser (Playwright MCP recomendado).

judicial-recon — Reconocimiento de Portales Judiciales

Guiá al usuario a explorar un portal judicial desconocido. Vos hacés el trabajo técnico (navegar, interceptar requests, clasificar). El usuario solo da la URL, credenciales si necesita, y un caso de prueba.

Output: Reporte de viabilidad markdown usando la plantilla en references/reporte-template.md.

Prerequisito: Browser automation. Si no hay herramienta de browser disponible, indicar al usuario que instale Playwright MCP y parar.

Idioma: Español. El usuario es abogado argentino/LATAM. Explicar términos técnicos cuando aparezcan.

Regla de seguridad: NUNCA escribir credenciales del usuario. Si requiere login, navegar al formulario y esperar que el usuario ingrese sus datos manualmente.

---

Fase 1 — Setup

Preguntar al usuario: URL del portal, jurisdicción, ¿requiere login?

Navegar a la URL. Tomar snapshot. Verificar que carga un portal judicial.

• Si pide plugin legacy (Java, Silverlight) → informar incompatibilidad, parar.

Fase 2 — Login

Si el portal es público (sin formulario de login visible) → saltar a Fase 3.

Si requiere login:

1. Navegar al formulario de login
2. Indicar al usuario que ingrese credenciales en el browser abierto
3. Esperar confirmación, tomar snapshot para verificar acceso
4. Registrar si hay CAPTCHA (tipo y comportamiento)

Fase 3 — Exploración

Mapear la estructura completa del portal. Seguir el checklist en references/exploration-checklist.md.

Resumen del proceso:

1. Dashboard: snapshot, identificar menú principal y buscador
2. Búsqueda de prueba: pedir al usuario un nombre o número de causa conocido, ejecutar búsqueda
3. Expediente concreto: navegar a un resultado, recorrer todas las secciones/tabs
4. Para cada sección: registrar URL, datos visibles, paginación, adjuntos descargables
5. PDF de prueba: intentar descargar un adjunto, registrar resultado

Fase 4 — API Discovery

La fase más importante. Revisar los network requests capturados durante la exploración.

1. Capturar requests: obtener log de network requests (excluir estáticos)
2. Buscar API: filtrar por responses JSON, URLs con /api/, /rest/, /services/, requests POST
3. Probar sin sesión: para cada endpoint encontrado, hacer curl sin cookies para ver si es público
4. Clasificar:
   • API pública (sin auth) → Complejidad BAJA
   • API con auth (requiere sesión) → Complejidad MEDIA
   • Sin API (solo HTML) → Complejidad ALTA — documentar selectores CSS clave

Detalle de filtrado y clasificación en references/api-discovery.md.

Fase 5 — Reporte

Generar reporte markdown completando la plantilla en references/reporte-template.md.

Ofrecer guardar como archivo reporte-viabilidad-[nombre-portal].md.

Informar al usuario que con este reporte, un desarrollador (o él mismo con otro agente) puede construir la integración siguiendo los próximos pasos recomendados en el reporte.