swaitsandClaude Opus 4.7
d785e35919
Set up the protocol spec as an mdBook and add a GitHub Actions workflow that builds it on every push/PR and deploys to GitHub Pages on main. The repo is now both a machine-readable corpus and a browsable, searchable site. Structure changes (one-time, mechanical): - Rename the spec source directory from `spec/` to `src/` to match mdBook's default convention. All 21 chapter files move; their internal relative cross-links are unchanged. - Add `src/SUMMARY.md` as the mdBook table of contents, grouping chapters under Wire Format, Payloads, Cryptography & Identity, and Routing & Higher-Layer Protocols. - Add `book.toml` at repo root: title, author, search enabled, fold enabled, edit-on-GitHub links, navy theme. - Add `.github/workflows/mdbook.yml`: build on push + PR, deploy on push to main only (configure-pages + upload-pages-artifact + deploy-pages from actions/). - Add `/book/` to .gitignore. Reference updates so the old path is fully retired: - Every `spec_ref` in `corpus/**/*.json` rewritten from `spec/` to `src/` (54 files). - Schema description text and example path in `corpus/schema/test-vector.schema.json`. - `README.md`: prominent link to the published site near the top; "What's Here" updated for the new layout. - `CONTRIBUTING.md`: spec-editing instructions point at `src/` and note the SUMMARY.md requirement. - `CLAUDE.md`: directory-layout notes updated. CHANGELOG.md historical entries intentionally keep their `spec/` paths since those record what the paths were at the time of those commits. After this lands, the user needs to enable GitHub Pages in repo settings with source = "GitHub Actions" (one-time, manual). The workflow will then publish to https://swaits.github.io/meshcore-spec/ on every push to main. Verified locally: `mdbook build` produces a clean book/ tree with all 21 chapters rendered and the SUMMARY-driven sidebar populated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
37 lines
1.5 KiB
Markdown
37 lines
1.5 KiB
Markdown
# Contributing to MeshCore Spec
|
|
|
|
## Adding Test Vectors
|
|
|
|
1. Choose the appropriate directory under `corpus/` based on protocol layer and
|
|
packet type.
|
|
2. Add vectors to an existing JSON file, or create a new file if testing a
|
|
distinct aspect.
|
|
3. Every JSON file must validate against `corpus/schema/test-vector.schema.json`.
|
|
4. Use uppercase hex for binary data. Whitespace is allowed for readability.
|
|
5. Each vector needs a unique `id` within its file and a clear `description`.
|
|
6. For `encode_decode` vectors, verify both directions: encoding the structured
|
|
form produces the binary, and decoding the binary recovers the structure.
|
|
|
|
## Editing the Specification
|
|
|
|
1. Spec documents live in `src/` (the mdbook source root) and are numbered for
|
|
reading order. New chapters must also be listed in `src/SUMMARY.md`.
|
|
2. Use RFC 2119 language (MUST, SHOULD, MAY) for normative requirements.
|
|
3. Include ASCII wire format diagrams where applicable.
|
|
4. Cross-reference related spec sections and test vector files.
|
|
5. The C++ reference implementation is the source of truth — if the spec
|
|
disagrees with the firmware, the spec needs updating.
|
|
|
|
## Generating Vectors from Reference Implementation
|
|
|
|
See `tools/generate/README.md` for instructions on building and running the
|
|
corpus generation harness against the C++ MeshCore library.
|
|
|
|
## Validating the Corpus
|
|
|
|
```bash
|
|
python tools/validate.py
|
|
```
|
|
|
|
This checks all JSON files against the schema and verifies internal consistency.
|