A version-specific review of FieldLens v1.2 (3ab5e7f), domain.js and backup-view.js. Eighteen existing domain/practical checks passed during the preceding repository review; this note does not claim a new model or full UI evaluation.
A valid JSON file can still be the wrong restore
A backup may contain new samples, exact duplicates, a revised note with the same id, or a malformed region. Restoring all of them with one assignment hides the decisions that matter.
In this version parseBackup validates the application and schema, normalizes records, and classifies each entry before anything is persisted. The UI shows a preview so the user can choose.
Four outcomes should lead to different actions
- New: the id does not exist locally. Adding it is selected by default.
- Duplicate: normalized content is identical. Skip it.
- Conflict: the id exists but content differs. Keep the existing record unless the user explicitly chooses replacement.
- Invalid: validation fails, or the backup itself repeats an id. Show the reason and skip the entry.
A preview can become stale
backup-view captures the current record list before displaying the dialog. At confirmation it compares the current list again. If it changed, the user must close and re-import, rather than apply choices to an unseen baseline.
mergeBackup calculates a new list and rejects a result above the 30-record history limit before persistence. When saving fails, the dialog keeps an error visible. This is a local application guard, not a distributed transaction or an automatic multi-device merge protocol.
Write down what the backup does not contain
The JSON backup carries record metadata and detection results, but not the original images. A restored report cannot recreate its source photograph. The existing preview states this explicitly.
If a future version supports image bundles, it would also need file manifests, integrity checks, missing-image behavior and storage estimates. Those are follow-up design tasks, not features implied by the current export button.
A small recovery drill
- Use synthetic records. Export one, change its local note, then import the older backup and inspect the conflict comparison.
- Keep the local record once, then repeat and explicitly replace it. Confirm the two choices have different outcomes.
- Try an invalid schema version and a file with repeated ids. Neither should silently become an accepted record.
- At the record limit, try adding one more. Check that an error leaves the previous list intact.
Make the decision visible before the write
This is the same lesson I would apply to batch imports, configuration uploads and migration tools: classify the change, show its effect, and recheck the baseline before committing. A successful parser is only the beginning.
Sources & further reading
Compiled from code and documents, with AI-assisted drafting and translation. Examples and proposed checks are learning material; only linked evidence establishes what was run.