Ir al contenido

Reglas no negociables

Esta es la copia canónica de estas reglas — los CONTRIBUTING.md de cada repo enlazan aquí en vez de repetir el texto completo. Si vas a citarlas o actualizarlas, hazlo en esta página.

Estas reglas no son burocracia: son las que evitan que un cambio bien intencionado cause un problema real (legal, de confianza médica, o de validez del estudio). Léelas antes de tu primera línea de código, no después.

El registro y los médicos/entidades colaboradoras están en modo stealth. No hay NDA firmado, pero el trato es como si lo hubiera: ninguna superficie pública puede nombrar el registro, a los médicos colaboradores, ni a las entidades involucradas, ni insinuar su respaldo/participación. Esto incluye repos públicos, posts, demos a terceros, portafolio, LinkedIn.

Este sitio está gateado por acceso, no es público — pero el contenido es igual de sensible que los repos privados que enlaza. No lo reenvíes, no tomes screenshots para compartir fuera del grupo autorizado, no asumas que “gateado” significa “casual”. Si tienes duda sobre si algo cuenta como superficie pública, pregunta antes de publicar.

2. Los datos de pacientes reales nunca entran a un repo

Sección titulada «2. Los datos de pacientes reales nunca entran a un repo»

El corpus de 110 notas es información real de pacientes (los nombres de archivo son nombres de pacientes) y está fuera de git a propósito — ni siquiera en un repo privado, ni “solo para pruebas”. Trabaja con notas sintéticas, nunca con el corpus real.

Ya existen notas sintéticas de ejemplo: src/routes/persona-isolation.test.ts y persona-runtime-guard.test.ts en pokta-grader-bioagent (una nota a la vez), y los ejemplos hardcodeados en biobadamex-sweep-dry-run.ts del monorepo. Ninguno es a escala de 110 — si necesitas más variedad sintética, genera notas inventadas, nunca pidas las reales para desarrollo local.

3. Integridad del estudio — la más fácil de romper sin querer

Sección titulada «3. Integridad del estudio — la más fácil de romper sin querer»

Cualquier mejora cuyo número vaya a respaldar el estudio se mide en datos held-out, nunca en las mismas 110 notas contra las que el estudio reporta resultados.

Por qué importa: si ajustas un cambio mirando qué tan bien le va contra esas 110 notas, y luego reportas ese mismo número como resultado del estudio, estás entrenando contra el set de prueba. El número sube porque ajustaste específicamente para ese conjunto — no porque el sistema extraiga mejor en general — y eso invalida la comparación entre arms, que es todo el punto del ejercicio.

Esto es fácil de violar sin mala intención: “mejoré el score” se siente bien y es la métrica más a la mano. La regla existe justamente porque es la trampa más natural en la que caer.

Mejorar cualquiera de los tres sistemas como producto es el objetivo, y está perfecto. El matiz es dónde mides el número que vas a mostrar como resultado del estudio.

Los tres repos de código (pokta-grader-bioagent, rheuma-ai-bioagent, pokta-care-monorepo) prohíben trabajar directo en main o hacer push directo — ramas + PR + revisión humana, siempre. Este sitio de documentación sigue la misma regla. Los forks de terceros (como BioAgents) nunca se empujan de vuelta a remotos upstream/terceros.

  • Compensación / términos formales de colaboración para contribuidores externos.
  • Coordinación de handoffs pendientes con el Dr. Erick Zamora.
  • Si el cuarto arm opcional del estudio se llega a construir.

Si alguno de estos te bloquea, dilo directamente a quien te haya dado de alta — no improvises una solución para un punto que no es tuyo.