Los tres role files y commons se contradicen sobre borrado_en/creado_en: el checklist de audit exige la regla RETIRADA

Analisis de los .md vivos, 2026-10-01, pedido por Elazar. SSOT es commons seccion 12, que dice tres cosas: (1) la fila vigente es el evento de NEGOCIO mas reciente, nunca la escrita mas recientemente; (2) NUNCA ordenar por creado_en, es columna de auditoria; (3) la vigencia NUNCA es borrado_en - borrado_en solo excluye filas soft-deleteadas administrativamente. Los tres role files vivos dicen LO CONTRARIO, textual: - agents/movilba-db-role.md:112 'Current record = borrado_en IS NULL. Views compute current with row_number() OVER (PARTITION BY ... ORDER BY creado_en DESC) = 1' - agents/movilba-coder-role.md:93 'Current record = borrado_en IS NULL, not the most recent' + row_number() - agents/movilba-audit-role.md:41 checklist: 'Views compute current via row_number(). Queries filter with borrado_en IS NULL' El de audit es el peor de los tres porque es un GATE: el checklist hace que el unico control que corre antes de un push rechace codigo que cumple commons y apruebe el defecto que commons prohibe. Las dos poblaciones medidas que motivaron la regla estan en MEMORY-db (2441 creado_en backdateados, 2315 borrado_en de los cuales 2314 forzados por un indice) y el conflicto regla-vs-indice ya es MOVILBA-42; MOVILBA-121 decide el alcance retroactivo. Segundo hallazgo, en commons mismo: la seccion 12 linea 208 dice que la fila anterior 'never closed, never soft-deleted, never gets a bookkeeping end-date' y nombra linea_entidad_asignaciones explicitamente - pero la estructura instalada de esa tabla tiene borrado_en mas uq_linea_entidad_activa (unique parcial WHERE borrado_en IS NULL) y src/actions/lineas.ts cierra la fila vieja escribiendo borrado_en. O la regla no alcanza a esa tabla o la tabla viola la regla; hoy el .md afirma algo que la base contradice, y es justo la tabla de MOVILBA-621. Tercer hallazgo: commons:213 cita 'the hard rule (section audit columns)' y esa seccion NO EXISTE en ningun .md vivo (grep sobre shared/md, .claude/rules, agents/movilba-*.md, CLAUDE.md). La regla esta enunciada inline en el mismo renglon, asi que no se perdio nada, pero el puntero esta muerto. Cuarto: .claude/rules/catalogos.md:13 dice 'Always filter borrado_en IS NULL' en absoluto y su propia seccion 18 (lineas 22-23) lo desmiente - filtrar al LEER para un usuario, NO filtrar al RESOLVER un valor ya existente (import, backfill, etiqueta de un FK guardado), porque regimen_servicio_modalidad esta 0 de 7 viva con 2395 fichas apuntando adentro. La linea 13 es la que se lee sola. commons:322 tiene el mismo defecto: enuncia 'Filter borrado_en IS NULL' sin la asimetria. Arreglo propuesto: los tres role files no re-enuncian la regla, apuntan a commons seccion 12 (duplicacion hacia abajo = la copia baja es la que se vence en silencio). commons 208 se reconcilia contra la estructura instalada de linea_entidad_asignaciones. commons:213 pierde la cita muerta o se crea la seccion. catalogos.md:13 y commons:322 se acotan al eje de lectura.