El ejemplo del comentario canonico de default-open (terra_41) nombra el modulo equivocado Y la cantidad no esta bien definida: dice modulo-4 y marcaImplante es del 1, y 'cuantas cirugias tiene un modulo' contesta distinto por deletedAt que por isActive
terra_41 es la fuente canonica de la regla default-open - el resolver, el guard y el denominador de aplicabilidad de TERRA-178 la citan a ella y no a la base. Su comentario de cabecera ilustraba la regla con un ejemplo concreto y el ejemplo no coincidia con el estado vivo. Corregido en 5946791. Esta descripcion se reescribio al cerrar porque dos de sus afirmaciones resultaron falsas al medirlas, y una fila cerrada que afirma lo contrario de lo que se hizo es peor que una fila abierta. QUE DECIA. Linea 48: "dropping marcaImplante from all ten modulo-4 cirugias with no error anywhere". Linea 268: "marcaImplante gets NO rows (default-open, correct as-is - venus has it on all ten)". QUE ESTABA MAL. marcaImplante es campo del MODULO 1 (Implantologia), con cero filas vivas de alcance - la parte de default-open siempre fue correcta. El modulo 4 es Protesis diente convencional y no tiene ningun campo asociado. O sea: numero de modulo equivocado y nombre de modulo equivocado. PRIMERA CORRECCION A ESTA MISMA FILA: la version anterior decia que la cantidad era "correcta" y despues que el modulo 1 tiene DIECISEIS cirugias y no diez. Las dos cosas no pueden ser ciertas a la vez y ninguna de las dos lo es sola. LA CANTIDAD NO ESTA BIEN DEFINIDA: "cuantas cirugias tiene el modulo 1" contesta 16 por deletedAt IS NULL y 10 por isActive; el modulo 4 contesta 12 y 7. Ninguna cirugia esta borrada logicamente, asi que toda la diferencia es isActive, y las dos lecturas son correctas para preguntas distintas - el formulario ofrece cirugias activas, mientras que fn_terraPracticasCamposValueGuard no consulta terraCirugias.isActive en ningun momento: rechaza un CAMPO retirado por el isActive del campo y despues matchea la lista blanca solo por deletedAt. Esto aparecio unicamente porque db02-terra-cc midio lo mismo sin ver mis numeros y contesto 10 y 7 contra mis 16 y 12. Un solo carril habria escrito uno de los dos y habria quedado mal, verificablemente, para siempre. SEGUNDO ERROR QUE ESTA FILA NO NOMBRABA: el parentesis afirmaba que el conjunto default-open ERA marcaImplante. Son TRES campos - marcaImplante (m1), tipoInjerto (m2) y tipoBarrera (m2) - y la misma key tipoInjerto esta scopeada en el modulo 1 mientras queda default-open en todo el modulo 2, que es exactamente la confusion que el ejemplo existia para evitar. LA PREGUNTA ABIERTA QUEDO CONTESTADA, no descartada: si marcaImplante estuvo alguna vez en el modulo 4, esto seria evidencia de una migracion posterior que reacomodo modulos y no un error de tipeo. NO LO ESTUVO. terra_31 lo asigna a Implantologia en el seed (linea 471) y ademas lo ASERTA en su propia verificacion (linea 585), que aborta la migracion si el mapeo no es ese. El ejemplo de terra_41 era falso el dia que se escribio. Es error de redaccion, no deriva de datos, y no hay ninguna pregunta mas grande atras. SEGUNDA CORRECCION A ESTA FILA, y era la restriccion que la trababa: decia que editar el comentario de una migracion aplicada la desalinea de lo que se ejecuto, y que la correccion "probablemente" iba en una nota aparte. Eso se midio y es falso. La fila de terra_41 en supabase_migrations.schema_migrations tiene 1 statement de 13181 caracteres y CERO lineas de comentario de dos guiones, contra un archivo de 28901 bytes con 201. Supabase saca los comentarios al registrar: mas de la mitad del archivo existe solo en el repo y nunca fue comparable con la base. Un cambio SOLO DE COMENTARIO no desincroniza nada. Cambiar lo que corre sigue necesitando migracion nueva. Verificado aparte por db02-terra-cc con las preguntas y sin mis respuestas. QUE SE HIZO. Las cifras se sacaron en vez de reemplazarse por cifras frescas, porque un numero en un comentario no puede cargar con que definicion se calculo. La regla queda enunciada sin poblacion y va inline la consulta que la contesta. El "venus has it on all ten" del seed se borra en vez de corregirse: es una afirmacion sobre la base de otro proyecto que ningun carril de terra puede consultar, o sea que nunca fue re-chequeable desde aca. La forma canonica sin cifras ya vivia en COMMENT ON TABLE terraCirugiaCampos (linea 156) y la cabecera ahora apunta ahi como la copia a mantener si divergen.
Activity
-
CORRECCION A MI PROPIA FILA, hecha antes de que alguien la trabaje. El titulo y el cuerpo dicen que las TRES cifras del ejemplo de terra_41:48 estan mal. Solo esta mal UNA. Conte las cirugias del modulo 1 sin filtrar isActive y me dieron 16, contra las diez que dice el comentario. Contadas como corresponde son DIEZ ACTIVAS y seis inactivas, y las inactivas no se ofrecen en ningun formulario, asi que la cifra del comentario es la correcta y la mia era la equivocada. campo-scope-core.ts:20-22 dice lo mismo - venus lleva marcaPicker en las diez cirugias del modulo - y coincide. LO QUE SIGUE MAL, y es lo unico: el NUMERO DE MODULO. marcaImplante es del modulo 1 (Implantologia); el comentario dice modulo-4, que es Protesis diente convencional y no tiene ningun campo asociado. O sea que el ejemplo nombra el modulo equivocado con la cantidad correcta, que es peor que estar mal entero: quien lo verifique va a encontrar que el diez cierra y va a dar por bueno el resto. EL ERROR MIO ES EL MISMO QUE ACABO DE CORREGIR EN TERRA-176 Y VIENE DE LA MISMA CONSULTA: conte filas crudas donde la unidad relevante era la fila viva o activa. Un conteo sin el predicado de vigencia responde con fluidez a la pregunta equivocada. La regla que me llevo es contar SIEMPRE con el predicado que usa el consumidor del dato - aca isActive, porque el formulario no ofrece cirugias inactivas.
-
El ejemplo del comentario canonico de default-open (terra_41:48, :268) nombra el modulo equivocado con la cantidad correcta - dice modulo-4 y marcaImplante es del 1
-
Corregido en 5946791, en el archivo aplicado mismo, y la pregunta que trababa la fila se midio en vez de razonarse. LA PREGUNTA ERA DONDE VA LA CORRECCION SIN DESINCRONIZAR UNA MIGRACION YA APLICADA. Respuesta medida: no desincroniza nada. La fila de terra_41 en supabase_migrations.schema_migrations tiene 1 statement de 13181 caracteres y CERO lineas de comentario de dos guiones, contra un archivo de 28901 bytes con 201. Supabase saca los comentarios al registrar, asi que mas de la mitad de ese archivo existe unicamente en el repo y nunca fue comparable con la base en esa parte. Editar prosa en una migracion aplicada es distinto de editar lo que corre: lo segundo sigue prohibido y necesita migracion nueva. Lo verifico db02-terra-cc por separado, con las preguntas y sin mis numeros, y le dio identico. QUE ESTABA MAL. El ejemplo decia "all ten modulo-4 cirugias" para marcaImplante. marcaImplante es del modulo 1 (Implantologia); el modulo 4 es Protesis diente convencional. Modulo equivocado y nombre equivocado. Y es la unica parte del parrafo que un lector puede chequear en treinta segundos, o sea que chequearla desacredita una regla que nunca tuvo defecto. Y HABIA UN SEGUNDO ERROR QUE LA FILA NO NOMBRABA: el parentesis afirmaba que el conjunto default-open ERA marcaImplante. Hoy son TRES campos - marcaImplante (m1), tipoInjerto (m2) y tipoBarrera (m2) - y la misma key tipoInjerto esta scopeada en el modulo 1 mientras queda default-open en todo el modulo 2. Es exactamente la confusion que el ejemplo existia para evitar. LA MITAD MAS AFILADA, Y APARECIO SOLO PORQUE DOS CARRILES MIDIERON SIN VERSE: el numero no esta bien definido. "Cuantas cirugias tiene el modulo 1" contesta 16 por deletedAt IS NULL y 10 por isActive; el modulo 4 contesta 12 y 7. Ninguna cirugia esta borrada logicamente, o sea que toda la diferencia es isActive, y las dos lecturas son correctas para preguntas distintas: el formulario ofrece cirugias activas, mientras que fn_terraPracticasCamposValueGuard no consulta terraCirugias.isActive en ningun momento - rechaza un CAMPO retirado por el isActive del campo, y despues matchea las filas de la lista blanca solo por deletedAt. Un numero metido en un comentario no puede cargar con que definicion se calculo, asi que se lee como autoritativo y esta mal para la mitad de sus lectores. POR ESO NO SE REEMPLAZARON LAS CIFRAS POR CIFRAS FRESCAS: se sacaron. La regla queda enunciada sin poblacion y en su lugar va inline la consulta que la contesta, que es lo unico que no se vence. El "venus has it on all ten" del seed se borra en vez de corregirse, porque es una afirmacion sobre la base de otro proyecto que ningun carril de terra puede consultar - una justificacion que nadie puede verificar es peor que ninguna. LO QUE YA ESTABA BIEN Y SE DEJO: la forma canonica sin cifras vive en COMMENT ON TABLE terraCirugiaCampos, linea 156, que es la copia a la que un lector llega desde psql. La cabecera ahora apunta ahi y dice que esa es la que hay que mantener correcta si alguna vez divergen.
-
El ejemplo del comentario canonico de default-open (terra_41) nombra el modulo equivocado Y la cantidad no esta bien definida: dice modulo-4 y marcaImplante es del 1, y 'cuantas cirugias tiene un modulo' contesta distinto por deletedAt que por isActive
-
was: terra_41 es la fuente canonica de la regla default-open - el resolver, el guard y ahora el denominador de aplicabilidad de TERRA-178 la citan a ella y no a la base. Su comentario de cabecera ilustra la regla con un ejemplo concreto y el ejemplo NO COINCIDE con el estado vivo. QUE DICE. Linea 48: "dropping marcaImplante from all ten modulo-4 cirugias with no error anywhere". Linea 268: "marcaImplante gets NO rows (default-open, correct as-is - venus has it on all ten)". QUE MEDI. marcaImplante es campo del MODULO 1 (Implantologia), id 3a48da07-0b93-488e-bc43-6dc0735809ae, con cero filas vivas de alcance - la parte de default-open es correcta. Pero el modulo 1 tiene DIECISEIS cirugias, no diez, y el modulo 4 es Protesis diente convencional, que tiene doce y ningun campo asociado. Las tres cifras del ejemplo estan mal: el numero de modulo, el nombre implicito del modulo y la cantidad de cirugias. POR QUE NO ES COSMETICO Y POR QUE NO LO ARREGLO SIN DECIDIRLO. La regla que el comentario enuncia SIGUE SIENDO CORRECTA y esta bien redactada; lo que falla es el unico ejemplo que la ancla a datos. Ese ejemplo es lo que lee alguien para convencerse de que entendio la regla, y es la parte que se puede chequear contra la base en treinta segundos - o sea que quien lo chequee va a concluir que la regla tambien esta mal, o peor, va a ajustar su implementacion al ejemplo. La regla misma no cambia con esto y no hay defecto de comportamiento en ningun lado: el resolver, el guard y campoApplicable implementan el texto normativo, no el ejemplo. LA PARTE QUE NO SE, Y ES LA QUE DECIDE QUE HACER: no medi si marcaImplante ESTUVO alguna vez en el modulo 4 con diez cirugias. Si el ejemplo era cierto cuando se escribio y despues algo movio el campo o agrego cirugias, entonces esto no es un error de tipeo sino evidencia de una migracion posterior que reacomodo modulos, y eso es una pregunta mas grande que el comentario. Si nunca fue cierto, es un error al escribir la migracion. Hay que mirar el historico antes de tocar el texto. Y HAY UNA RESTRICCION QUE NO SE PUEDE IGNORAR: terra_41 esta en applied/. Editar el comentario de una migracion ya aplicada cambia el archivo que documenta lo que se corrio y lo desalinea de lo que efectivamente se ejecuto. La correccion probablemente no va ahi sino en una nota aparte que apunte a la linea. Esa eleccion es parte de esta fila, no un detalle de implementacion.
-
La correccion que hice hace una hora traia adentro un defecto de la MISMA CLASE que venia a corregir, y lo encontro el censo de poblacion de db02-terra-cc, no yo. 5946791 saco las cifras equivocadas del comentario canonico de default-open y, en vez de cifras nuevas, dejo inline la consulta que las contesta. Esa consulta seleccionaba todo campo de terraModuloCampos sin fila viva de alcance en terraCirugiaCampos - y OMITIA mc.isActive. Un campo RETIRADO con cero filas de alcance cumple la mitad del alcance y no esta default-open en ningun sentido util: fn_terraPracticasCamposValueGuard rechaza cualquier valor suyo por el isActive DEL PROPIO CAMPO antes de consultar la lista blanca. O sea que la consulta habria contestado default-open para un campo que el guard rechaza de plano. DEVUELVE EL CONJUNTO CORRECTO HOY UNICAMENTE PORQUE LOS SEIS CAMPOS ESTAN ACTIVOS, que es exactamente el mismo accidente que ocultaba las cifras originales: un predicado mal definido que coincide con los datos que tiene enfrente. Corregida y re-corrida: marcaImplante m1, tipoInjerto m2, tipoBarrera m2, los mismos tres. Y quedo escrito al lado, porque confundirlas es lo que produjo esto: terraModuloCampos tiene isActive y NO tiene columna deletedAt, terraCirugiaCampos tiene deletedAt y NO tiene isActive, verificado contra information_schema. LA LECCION NO ES QUE ME EQUIVOQUE, ES DONDE: el error entro en el parrafo que explica por que las cifras se vencen, escrito por quien acababa de medir el problema. Sacar un numero y dejar una consulta es correcto, pero una consulta tambien es una afirmacion y hay que verificarla igual - no hereda correccion por ser ejecutable.