Práctica focalizada · Bloque 4 · Unidad 4.4
EX-B4-14
Hacer converger un seed sin borrar datos ajenos
El seed del catálogo inserta tres categorías cada vez. Funciona sobre vacío, falla al repetirse y no corrige una etiqueta conocida obsoleta.
Cómo abordarla
Preserva significado al evolucionar el schema
Ejecuta primero el baseline. Después modifica la frontera indicada, escribe una regresión positiva y otra negativa y conserva la salida real.
Evidencia objetivo: Los ensayos comparan filas antes/después, revisión actual, roundtrip y convergencia; el checkpoint transfiere el mecanismo a un historial nuevo.
Abrir laboratorio de código
1. Descarga y arranca
- Starter de seed no repetibleSchema y seed local con cinco pruebas de primera ejecución y dos criterios rojos de repetición y propiedad.
2. Escribe y prueba
- Predice claves poseídas, filas ajenas y estado tras dos ejecuciones.
- Reproduce la violación unique y el caso de etiqueta obsoleta más custom.
- Implementa insert/update por clave conocida dentro de una sola transacción.
- Repite ambas suites y registra conteos y filas ordenadas.
3. Demuestra el comportamiento
- Seed convergente y pruebas finales.
- Matriz antes/después de primera, segunda y ejecución con custom.
- evidence.md con frontera de propiedad y alternativa descartada.
La respuesta principal es tu código y sus pruebas. Usa este espacio solo para anotar la predicción inicial y el resultado observado.
Predicción breve antes de ejecutar
¿Qué estado debe producir cualquier número de ejecuciones y cómo limita la clave estable qué filas puede modificar el seed?
Convergencia y propiedad
Dos ejecuciones dejan tres referencias; una ejecución posterior corrige network y conserva custom sin duplicar ni borrar.Comprueba estas tres cosas
- ¿Qué ocurre exactamente en la segunda ejecución?
- ¿Quién posee la fila custom?
- ¿Ignorar conflictos actualizaría una etiqueta obsoleta?
Anota predicción, comando ejecutado y diferencia observada; el código vive en tu workspace.
Sin respuesta guardada.
Pistas opcionales
Pista única · Converge por clave poseída
- Para cada referencia, decide insert, update o no-op.
- No iteres sobre toda la tabla para decidir qué borrar.
Profundización opcional
Convertir la ejecución en una convergencia transaccional sobre claves poseídas y conservar filas que pertenecen al usuario.
Contexto adicional
- Ejecuta el seed una y dos veces antes de cambiarlo.
- Conserva la constraint unique y una sola transacción.
- No borres la tabla, no conviertas el seed en migración y no leas secretos de entorno.
Decisiones abiertas
- Puedes usar select+insert/update o un upsert del dialecto; explica el coste de portabilidad de la segunda opción.
Cómo revisar tu respuesta
- Las cinco pruebas baseline y los dos criterios de convergencia pasan.
- Ejecutar dos veces no falla, no duplica y produce el mismo estado.
- Una etiqueta de referencia obsoleta converge al valor declarado.
- La fila custom permanece intacta y no se borra ninguna fila ajena.
- Todas las modificaciones del seed forman una sola transacción.
Evidencia, revisión y reinicio
- Claves de referencia y frontera de propiedad predichas antes de editar.
- Cinco pruebas baseline verdes y dos criterios de convergencia inicialmente rojos.
- Filas después de primera/segunda ejecución y con una categoría custom.
Revisión: con Codex, utilizando la evidencia y los criterios anteriores; no se publica una solución oficial.
Reinicio: Volver a descomprimir ex-b4-14-idempotent-seed.zip y eliminar solo catalog.db si se creó dentro del intento.