1. Choose the scope
Decide whether version 1 of the software is read-only, or reads and writes. Also decide whether you support only `ENTRY`, or both `ENTRY` and `LIB`.
Move fast without missing the essentials
This page is a practical launch ramp. It summarizes what a team should stabilize in its first days: scope, internal model, reading, writing, and tests. It does not replace the specifications, but it helps avoid scattering effort too early.
What to lock down first
Before refining anything, the team should align on terminology, supported formats, and writer behaviour.
2. Fix the reading core
Everything should converge to a single text parser, even when input arrives as `.eevz` or as an already-issued `.eevcz` that you only need to read. Compression is transport, not a second language.
3. Design a clean model
Create clear structures for the library, entries, global blocks, matrices, modes, and `peak_tracks`. Avoid storing raw lines for as long as possible.
Reasonable MVP
- read `.eev` and `.eevz`
- support `ENTRY` first, `LIB` next if needed
- validation with blocking errors and legacy warnings
- use the canonical writer only for fields the software truly understands
- round-trip tests on real examples
Useful version 2
- full `LIB` support
- read support for `.eevc` and `.eevcz`
- finer preservation of optional sections
- diff and diagnostics tooling
- richer legacy compatibility
Suggested first sprint
The goal of the first sprint is not to cover the entire spec. It is to produce a chain that is reliable, explainable, and testable.
Parse one text `ENTRY`
Start with the simplest case. Read the header, open `@entry`, recognize the main blocks, produce an in-memory model, and surface readable diagnostics.
Re-emit in canonical order
From the internal model, produce stable, deterministic text. The goal is that two identical exports yield the same output.
Add compressed transport
Once text works, add the `.eevz` layer. Decompress before reading, compress after writing. Keep the same business core.
Test on real cases
Mix clean examples, legacy cases, missing fields, and real captures. A parser that only sees perfect examples stays fragile.
Frequent traps
- mixing quality tier with documentary status
- letting library headers describe one entry
- automatically re-emitting everything tolerated on read
- treating the hash as a compressed-container concern
Healthy reflex
When doubt appears, return to three questions: is this public contract, implementation strategy, or capture quality? That separation avoids a lot of confusion in code and product discussions.
Credible first-version deliverable
A credible first version can correctly read a clearly defined subset of the format, produce honest diagnostics, re-emit deterministic text, and explicitly document what it does not handle yet. That is not a weakness: it is a healthy base.