1. Elegir el alcance
Decidir si la versión 1 del software solo lee o si lee y escribe. Decidir también si se soporta solo `ENTRY` o `ENTRY` y `LIB`.
Avanzar rápido sin perder lo esencial
Esta página funciona como una rampa de lanzamiento práctica. Resume lo que un equipo debe estabilizar en los primeros días: alcance, modelo interno, lectura, escritura y pruebas. No sustituye a las especificaciones, pero ayuda a no dispersar el esfuerzo demasiado pronto.
Qué hay que fijar desde el principio
Antes de programar refinamientos, el equipo debe alinearse sobre la terminología, los formatos soportados y el comportamiento del writer.
2. Fijar el núcleo de lectura
Todo debe converger hacia un único parser de texto, incluso cuando la entrada llega como `.eevz` o como un `.eevcz` ya emitido que solo hay que leer. La compresión es transporte, no un segundo lenguaje.
3. Diseñar un modelo limpio
Crear estructuras claras para la biblioteca, las entradas, los bloques globales, las matrices, los modos y los `peak_tracks`. Evitar almacenar líneas en bruto durante el mayor tiempo posible.
MVP razonable
- lectura de `.eev` y `.eevz`
- soportar primero `ENTRY`, después `LIB` si hace falta
- validación con errores bloqueantes y advertencias legacy
- usar el writer canónico solo para los campos que el software comprende de verdad
- pruebas round-trip con ejemplos reales
Versión 2 útil
- soporte completo de `LIB`
- soporte de lectura para `.eevc` y `.eevcz`
- preservación más fina de las secciones opcionales
- herramientas de diff y diagnóstico
- compatibilidad legacy más amplia
Primer sprint recomendado
El objetivo del primer sprint no es cubrir toda la especificación. Es producir una cadena fiable, explicable y comprobable.
Parsear un `ENTRY` de texto
Empezar por el caso más simple. Leer la cabecera, abrir `@entry`, reconocer los bloques principales, producir un modelo en memoria y devolver diagnósticos legibles.
Reemitir en orden canónico
A partir del modelo interno, producir un texto estable y determinista. El objetivo es que dos exportaciones idénticas generen la misma salida.
Añadir el transporte comprimido
Cuando el texto funcione, añadir la capa `.eevz`. Descomprimir antes de leer, comprimir después de escribir. Mantener el mismo núcleo de negocio.
Probar con casos reales
Mezclar ejemplos limpios, casos legacy, campos ausentes y capturas reales. Un parser que solo ve ejemplos perfectos sigue siendo frágil.
Errores frecuentes
- confundir el nivel de calidad con el estado documental
- dejar que la cabecera de biblioteca describa una entrada
- reemitar automáticamente todo lo tolerado en lectura
- tratar el hash como un asunto del contenedor comprimido
Reflejo saludable
Cuando aparezca una duda, volver a tres preguntas: ¿se trata del contrato público, de la estrategia de implementación o de la calidad de captura? Esa separación evita mucha confusión en el código y en las discusiones de producto.
Entrega creíble de primera versión
Una primera versión creíble sabe leer correctamente un subconjunto claro del formato, producir diagnósticos honestos, reemitir un texto determinista y documentar explícitamente lo que todavía no gestiona. No es una debilidad: es una base sana.