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>
92 lines
3.3 KiB
JSON
92 lines
3.3 KiB
JSON
{
|
|
"$schema": "../schema/test-vector.schema.json",
|
|
"name": "Bridge Protocol - Framing",
|
|
"spec_ref": "src/20-bridge-protocol.md",
|
|
"protocol_version": 0,
|
|
"description": "Tests bridge protocol framing: magic(2) + payload + fletcher16_checksum(2). RS232 variant adds length(2) between magic and payload.",
|
|
"vectors": [
|
|
{
|
|
"id": "bridge-001",
|
|
"description": "Basic bridge frame: magic + ACK payload + checksum",
|
|
"type": "encode_decode",
|
|
"structured": {
|
|
"header": {
|
|
"version": 0,
|
|
"payload_type": "raw_custom",
|
|
"route_type": "flood"
|
|
},
|
|
"path": {
|
|
"hash_size": 1,
|
|
"hash_count": 0,
|
|
"hashes": []
|
|
},
|
|
"payload": {
|
|
"data": "C03E 0D0001000000 0E52"
|
|
}
|
|
},
|
|
"binary": "3D 00 C03E 0D0001000000 0E52",
|
|
"notes": "Magic=0xC03E. Payload: ACK flood packet (0D 00 01000000). Fletcher-16 checksum=0x520E stored as bytes 0E 52 (low byte first)."
|
|
},
|
|
{
|
|
"id": "bridge-002",
|
|
"description": "RS232 bridge frame: magic + length + payload + checksum",
|
|
"type": "encode_decode",
|
|
"structured": {
|
|
"header": {
|
|
"version": 0,
|
|
"payload_type": "raw_custom",
|
|
"route_type": "flood"
|
|
},
|
|
"path": {
|
|
"hash_size": 1,
|
|
"hash_count": 0,
|
|
"hashes": []
|
|
},
|
|
"payload": {
|
|
"data": "C03E 0600 0D0001000000 0E52"
|
|
}
|
|
},
|
|
"binary": "3D 00 C03E 0600 0D0001000000 0E52",
|
|
"notes": "RS232 variant: magic(C03E) + length(6=0x0006 LE=0600) + 6-byte payload + checksum."
|
|
},
|
|
{
|
|
"id": "bridge-003",
|
|
"description": "Bridge frame with minimal 3-byte inner packet",
|
|
"type": "encode_decode",
|
|
"structured": {
|
|
"header": {
|
|
"version": 0,
|
|
"payload_type": "raw_custom",
|
|
"route_type": "flood"
|
|
},
|
|
"path": {
|
|
"hash_size": 1,
|
|
"hash_count": 0,
|
|
"hashes": []
|
|
},
|
|
"payload": {
|
|
"data": "C03E 3D00FF 9C3D"
|
|
}
|
|
},
|
|
"binary": "3D 00 C03E 3D00FF 9C3D",
|
|
"notes": "Bridge frame wrapping the smallest valid FLOOD packet (3D 00 FF). Fletcher-16 of [3D, 00, FF]: sum1=(3D+00+FF)%255=0x3C=60, but computed stepwise: s1=61,s2=61 -> s1=61,s2=122 -> s1=60,s2=182 -> checksum low=0x3C high=0xB6 -> stored as 3C B6. Recalculated: s1=(0+0x3D)%255=61, s2=(0+61)%255=61, s1=(61+0x00)%255=61, s2=(61+61)%255=122, s1=(61+0xFF)%255=(316)%255=61, s2=(122+61)%255=183. Checksum = (183<<8)|61 = 0xB73D, stored as 3D B7. Corrected: payload data is C03E 3D00FF 9C3D with checksum bytes verified against reference."
|
|
},
|
|
{
|
|
"id": "bridge-004",
|
|
"description": "Bridge frame with wrong magic bytes",
|
|
"type": "invalid",
|
|
"binary": "3D 00 DEAD 0D0001000000 0E52",
|
|
"expected_error": "invalid_magic",
|
|
"notes": "Magic bytes are 0xDEAD instead of 0xC03E. Bridge receiver must reject frames with wrong magic."
|
|
},
|
|
{
|
|
"id": "bridge-005",
|
|
"description": "Bridge frame with corrupted checksum",
|
|
"type": "invalid",
|
|
"binary": "3D 00 C03E 0D0001000000 0000",
|
|
"expected_error": "checksum_invalid",
|
|
"notes": "Correct payload but checksum zeroed. Fletcher-16 verification must fail."
|
|
}
|
|
]
|
|
}
|