Skip to content

feat(demo): datos de calidad — histórico de 90 días, calibración ganada y actas verdes - #103

Open
gonzaloMorenoc wants to merge 5 commits into
mainfrom
feat/demo-datos-calidad
Open

feat(demo): datos de calidad — histórico de 90 días, calibración ganada y actas verdes#103
gonzaloMorenoc wants to merge 5 commits into
mainfrom
feat/demo-datos-calidad

Conversation

@gonzaloMorenoc

Copy link
Copy Markdown
Owner

Qué

La demo de «Demo MTP» tenía 40 runs, pero no podía enseñar el producto funcionando: ni una sola acta decía «apto», 16 de 26 familias de defectos estaban sin clasificar, el panel de acciones correctivas estaba vacío y el grafo vivía de 4 tests indexados.

Esta rama reescribe la siembra para que la demo cuente una historia real.

Antes Ahora
Runs / ventana temporal 40 en 21 días 50 en 90 días
Actas «apto» 0 14 (confianza media)
Familias sin clasificar 16 0
Correcciones / precisión 11 / — 34 / 88%
Acciones correctivas 0 5
Tests indexados (grafo) 4 35
Propuestas pendientes 1 5

Que no hubiera actas verdes era estructural, no un descuido

compute_confidence exige ≥30 correcciones humanas para salir de confianza baja, y la demo tenía 11. Con esa cifra, un run limpio nunca puede firmarse verde: ninguna cantidad de runs adicionales lo habría arreglado. Hacía falta sembrar también el trabajo humano.

La historia: el motor aprendiendo

El histórico ya no es plano. Las actas de hace tres meses son apto-con-reservas con confianza baja —el motor aún no conocía a este cliente, y el acta lo dice— y las recientes son apto con confianza media.

Esa evolución no está simulada: la calibración se lee en el instante de emitir cada acta, así que basta sembrar en orden cronológico (runs antiguos → el equipo etiqueta → runs recientes) para que salga del propio producto. Es la prueba visible de la tesis: la memoria mejora con el uso.

El orden de las fases es el diseño. Si las etiquetas fueran al final, todas las actas quedarían en confianza baja. Era exactamente el comportamiento anterior, documentado en el código como decisión consciente.

Lo que costó dos siembras descubrir

El motor de triaje no clasifica por el texto del error. Las reglas exigen historia:

  • maintenance exige que el test pasara antes y que el DOM haya cambiado.
  • infra exige fallo masivo: tres errores de red en el mismo run.
  • real sí sale de una aserción sola.
  • Lo demás cae en unknown.

Un catálogo de fallos sueltos —impecable leyéndolo— dejaba 14 de 33 familias sin clasificar, la precisión en 58% y ni un acta verde. Por eso el calendario incluye ahora el pasado verde de cada localizador y un run que es «el día que se cayó el proveedor de pagos». Tres tests unitarios protegen esas propiedades en milisegundos, en vez de descubrirlas en una siembra de tres minutos.

Se corrigieron además dos fallos propios: el seed comparaba con defect_families.label (que vale unknown hasta que alguien etiqueta) en lugar de la categoría del motor, y el reparto de correcciones no producía ni una hasta la familia 85, cuando una demo real ronda las 35.

Estructura

  • src/demo/demo_catalog.py (nuevo) — 31 firmas de fallo coherentes con su proyecto y el calendario de 90 días. Es el fichero que se toca para cambiar la demo.
  • src/demo/labeling.py (nuevo) — decide si el humano confirma o corrige al motor, para fijar la precisión objetivo de forma determinista.
  • src/demo/demo_test_assets.py (nuevo) — los tests indexados, uno por cada fichero donde ocurre un fallo: grafo y Defect DNA hablan del mismo código.
  • src/demo/seed.py — orquesta las fases; sin literales de datos dentro.
  • src/demo/knowledge_data.py / seed_knowledge.py — 5 propuestas pendientes en la bandeja.

Plan de pruebas

  • 1.069 tests unitarios en verde (los del catálogo y el etiquetado entran en CI).
  • 12 tests de integración en verde contra la BD real, con claves de firma efímeras. Incluidos los que ya existían: el escenario fresh_push del guion y la idempotencia siguen funcionando.
  • Siembra real medida: los números de la tabla de arriba salen de ejecutarla, no de estimarla.
  • Re-seed de producción (scripts/reseed_demo.py) — pendiente, lo ejecuta Gonzalo.
  • Repasar la app con la cuenta de demo tras el re-seed.
  • Refrescar los UUID de docs/demo/prod.local.md.

Notas

  • El re-seed pasa de segundos a varios minutos: 50 runs cruzando la ingesta con embeddings.
  • Las conexiones de GitHub y Jira no se siembran: exigen credenciales reales, y esta demo no finge capacidades que no existan.
  • La suite de integración conviene ejecutarla por lotes: los 12 tests de una vez agotan conexiones del pooler.

https://claude.ai/code/session_01Fzbva9TvFGkVRaJ9DRSJY7

30 firmas de fallo coherentes con su proyecto (banca falla en transferencias,
api-pagos en la pasarela) y 45 runs repartidos sobre 90 días con densidad
creciente. El tramo antiguo concentra los fallos: son las familias que el
equipo etiqueta y con las que el motor se calibra.
La precisión de la demo se fija en ~85% repartiendo confirmaciones y
correcciones de forma determinista, en vez de etiquetar siempre igual que el
motor (100% no se lo cree nadie y significaría que el humano no aportó nada).
Un fallo solo se clasifica si sus datos cuentan la historia que la regla
necesita: maintenance exige que el test pasara antes con otro DOM, e infra
exige tres errores de red en el mismo run. Sin eso el motor los deja en
'unknown' y ensucian el Defect DNA.

- green_keys: el pasado verde de cada localizador que luego se rompe.
- Un run de caída del proveedor con los tres errores de red juntos.
- Los errores de red sueltos pasan a ser fallos de negocio, que es como se
  ven de verdad cuando van solos.
- Tres tests nuevos protegen las tres propiedades.
…ndose

El orden ES el diseño: runs antiguos (motor sin calibrar, actas con reservas)
-> etiquetado humano de todas las familias -> runs recientes (motor calibrado,
actas 'apto'). La calibración se lee al emitir cada acta, así que la evolución
sale del propio producto en vez de simularse.

Medido en una siembra real: 34 correcciones, 88% de precisión, 0 familias sin
etiquetar, 14 actas verdes y 5 acciones correctivas propuestas.

El reparto de correcciones se arregla además para tamaños reales: con el umbral
anterior no había ni una corrección hasta la familia 85, y una demo ronda las 35.
… contenido

El grafo vivía de 4 tests indexados y la bandeja de propuestas estaba vacía.
Ahora hay 35 tests indexados, uno por cada fichero donde ocurre un fallo del
catálogo (grafo y Defect DNA hablan del mismo código), y 5 propuestas
pendientes de revisar, cada una nacida de un defecto real.
@vercel

vercel Bot commented Jul 25, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
mnemo Ready Ready Preview, Comment Jul 25, 2026 5:57pm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant