Jorge
9a5308c3c9
Hasta ahora el proyecto carecía de convenciones documentadas. Esta configuración inicial consolida code style, git conventions, política de tests, comandos /audit y /check, y las skills locales del repo (sf-backend-architecture y clean-ddd-hexagonal) en una estructura reutilizable: defaults estrictos al copiar a otros repos, con excepciones específicas de sf-sim documentadas por su carácter legacy. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
27 lines
2.7 KiB
JSON
27 lines
2.7 KiB
JSON
{
|
|
"skill_name": "sf-backend-architecture",
|
|
"evals": [
|
|
{
|
|
"id": 0,
|
|
"name": "planning-nuevo-operador",
|
|
"mode": "planning",
|
|
"prompt": "Tenemos que añadir un nuevo operador al sistema, Movistar, igual que ya tenemos NOS y Objenious. Va a hacer falta poder hacer activaciones, cancelaciones y pausa de las SIMs igual que con los otros, y la prueba que nos pasan dice que el iccid empieza por 3401 (Movistar España). Quiero que me ayudes a planificar el servicio nuevo: por dónde empiezo, qué pongo en sim-shared y qué local del servicio, qué eventos van a llegarle y cómo encajan en sim.exchange. Estoy en una sesión de planning con el equipo y quiero salir con un esqueleto claro y la lista de decisiones que aún no tenemos resueltas.",
|
|
"expected_output": "Un esqueleto de servicio nuevo (carpetas, ports, usecases, eventos), preguntas concretas sobre las decisiones pendientes (idempotencia, retry, autenticación con Movistar, outbox, etc.), y la actualización del Map COMPANYICCID en domain/companies.ts con 3401->movistar."
|
|
},
|
|
{
|
|
"id": 1,
|
|
"name": "brainstorming-outbox",
|
|
"mode": "brainstorming",
|
|
"prompt": "Tenemos un problema en sim-entrada-eventos: cuando hacemos una activación, primero publicamos el evento al RabbitMQ y luego guardamos la order en Postgres. Si el guardado falla nos quedamos con un evento que el worker procesa pero del que no tenemos seguimiento. Y al revés también: si invierto el orden y el publish falla, hay order pero el worker no se entera. ¿Cómo lo resolvemos? Quiero discutirlo bien antes de implementar nada, no me valen respuestas de manual. Tengo dudas si esto es realmente un outbox o si hay algo más simple.",
|
|
"expected_output": "Análisis de las opciones (transactional outbox, mensajería de 2-fase, aceptar la ventana y reconciliar a posteriori), tradeoffs de cada una, recomendación basada en el contexto del repo (sim-eventos), y preguntas sobre criticidad del evento (¿perderlo es pérdida de dinero?) para decidir si outbox es bloqueante."
|
|
},
|
|
{
|
|
"id": 2,
|
|
"name": "audit-sim-consumidor-nos",
|
|
"mode": "audit",
|
|
"prompt": "Audita el servicio packages/sim-consumidor-nos contra la arquitectura de la casa. Quiero un informe completo con todas las secciones fijas: capas, DDD, hexagonal, EDA, CQRS, persistencia, errores, tests, estilo. Cita archivo:línea para cada hallazgo. Ordena los riesgos por severidad y dame acciones concretas al final.",
|
|
"expected_output": "Informe en formato fijo (12 secciones desde 'Resumen ejecutivo' hasta 'Acciones recomendadas') con hallazgos citando archivo:línea, veredicto OK/Observaciones/Bloqueante justificado, y acciones priorizadas."
|
|
}
|
|
]
|
|
}
|