Release and Reproducibility¶
The current repository is a development baseline, not a released benchmark.
The planned public version is 0.1.0; it becomes a release only after an
annotated Git tag, matching GitHub Release assets, green remote CI, and a
published documentation revision.
Read the root CHANGELOG.md and RELEASE_CHECKLIST.md before consuming a
release. They define version consistency, asset provenance, coordinate-frame
migration, and evidence boundaries.
Asset Manifest¶
Every public release should include a release asset manifest that follows
schemas/release_asset_manifest.schema.json. The example file is
examples/release_asset_manifest.example.json; it uses placeholder SHA-256
values and must not be copied unchanged into a real release.
The v0.1.0 research-preview manifest should list these asset groups:
Category |
First public asset |
Scope |
|---|---|---|
Source |
Tagged GitHub source archive |
GitHub Release |
Firmware |
ESP32-C3 app/bootloader/partition binaries with flash offsets |
GitHub Release |
Hardware |
EPRO2 PCB source and any production exports |
Repository or GitHub Release |
Enclosure |
STEP enclosure files |
Repository or GitHub Release |
BOM |
|
Repository |
Documentation |
Built Cloudflare Pages revision and root README files |
Cloudflare Pages / repository |
Schemas |
JSONL, hub-frame, evaluation, and release-manifest schemas |
Repository |
Examples |
Sanitized JSONL replay and manifest examples |
Repository |
Media |
Approved tutorial clips and posters |
Cloudflare Pages |
Release assets must be separated by type: source archive, ESP32-C3 binary, hardware/production files, STEP models, and sanitized replay/evaluation examples. A firmware binary must be reproducible from the same tag and disclose its ESP-IDF version, flash layout, and SHA-256.
Do not treat historical archives or unverified runtime behavior as benchmark evidence. See Evaluation.