- v2/common/device/device.schema.json: stray backtick in bed $ref broke resolution
- v2/report/print/print.schema.json: ams $ref pointed at wrong path (missing ams/ subdir)
- v2/common/device/plate.schema.json: $id was copy-pasted from bed.schema.json
- Add v2/request.schema.json and v2/report.schema.json dispatchers - v2's leaf
schemas were unreachable without them, same oneOf convention as v1
- Rewrite schemas/bambulab/README.md layout section, which still described
v1's pre-rename paths and claimed v2 was removed
- PrintJob.status serialized as a raw i32 in Rust (prost stores proto3 enums
as i32) while ts-types' TypeBox schema validates full enum name strings -
add serde with= on the field so Rust JSON matches TS and protobuf's own
canonical JSON enum mapping, plus a regression test
- print.schema.json, _ams.schema.json, _ams_unit.schema.json still
pointed at the pre-rename filenames (ams.schema.json, ams_unit.schema.json,
ams_tray.schema.json) after the underscore-prefix split - fixed all
three, verified with a full jsonschema + referencing validation run
against real captures (get_version, pushall, a full print/ams/xcam
report with both empty and loaded trays) plus negative tests.
- _upgrade_state.schema.json: fixed its $id (pointed at report/info/,
file lives under report/print/) and its title (said "ModuleInfo",
clearly copy-pasted from _module_info.schema.json). Wired it into
print.schema.json as the print report's `upgrade_state` property -
the file existed but nothing referenced it yet.
- Deleted schemas/bambulab/v2/, which had been recreated as stale,
broken copies of an older v1 (missing the envelope allOf, missing
the underscore renames, $ids still pointing at v1/ paths) - the
repo's own README documents v2 as intentionally removed until V2's
wire format is known to differ from V1's.
- Updated schemas/bambulab/README.md's layout tree and inheritance-
example reference, both stale after the underscore rename.
- Removed stray tsc -b build output (packages/ts-types/src/*.d.ts/js)
that isn't meant to be committed (outDir is dist/, gitignored).
Verified: cargo check clean (continuum-proxy, continuum-ai-worker,
rust-types), tsc clean (continuum-backend, continuum-common ts-core),
10/10 JSON Schema validation cases passing.
Each root JSON key ('info', 'pushing', 'print') now gets its own category
folder under request/ and report/, so a category can hold multiple command
schemas without flattening them into one directory - v1/request.schema.json
and v1/report.schema.json route into these via oneOf per category (also
future-proofs for a category ever needing more than one shape).
Split pushall's ams/xcam fields the same way module_info was already
split: ams.schema.json/ams_unit.schema.json/ams_tray.schema.json/
xcam.schema.json/print.schema.json, each referencing the next by relative
$ref. ams_tray.schema.json uses oneOf for the empty-vs-loaded tray shapes
- verified (and initially got wrong, then fixed) that LoadedTray needs
every field required, not just id, or a bare {"id":"0"} validates
against both branches and oneOf fails, since oneOf demands exactly one
match.
Real correction: the report/ category for what a pushall request
triggers is "print", not "pushing" - re-reading the original examples,
pushall's REQUEST goes to "pushing", but the resulting state-push stream
arrives under "print", a different root key. report/pushing/ (my
original mistake) is removed; report/print/ holds the corrected content.
request/pushing/ is untouched - that side was correct.
Also: v2/ removed (found as broken copy-pasted stubs still pointing at
v1 $ids - no real V2-specific content yet, better to have nothing than
broken duplicates); all $ids switched to real, verified Gitea raw-file
URLs (raw/branch/main/<path> - confirmed this is the correct pattern,
not raw/<path>) instead of a placeholder domain; fixed a broken relative
$ref in the request-side files left over from an earlier move (still
pointing 2 levels up instead of 3 after nesting one level deeper).
Re-validated everything against real examples after restructuring,
including the full ams/xcam print report and two negative cases -
see schemas/bambulab/README.md for the validation script.
Schemas (any notation - proto, JSON Schema) belong in the schemas repo
regardless of how many languages currently consume them; that's what
makes this 'the schemas repo'. Rust-only code (the hand-written structs
in continuum-proxy's bambu_commands/) is a different category and stays
where it was.
Also restructured per readability feedback:
- envelope.schema.json moved out of v1/ to the bambulab/ root - it's
shared across protocol generations, not v1-specific, same principle
already applied to the (now-removed) proto/bambulab/common.proto.
- v1/ split into v1/request/ and v1/report/, one file per command in
each, instead of *.request.schema.json / *.response.schema.json
filename suffixes doing the same job less clearly. The two top-level
dispatcher schemas (matching BambuRequest/BambuReport) stay at the v1/
root since they aren't themselves a single command's schema.
Re-verified after restructuring, not just moved and assumed still
correct: resolution now has to handle a real basename collision
(get_version.schema.json exists in both request/ and report/) — switched
the validation approach to register schemas by (their actual base
URI) rather than by filename, which is what makes relative resolve
correctly here. All three real examples plus the negative tests from the
original version still pass.
Reconsidered after actually feeling the friction: this data is JSON over
MQTT (not binary protobuf), only continuum-proxy ever parses it (raw
vendor wire format, never crosses into TS), so none of protobuf's actual
value (cross-language codegen, binary wire efficiency) applied here.
Every gotcha hit while building this (field_attribute's oneof/variant
path collision, needing .bambulab-scoped type_attribute calls, explicit
#[serde(default)] per not-always-present field) came from forcing
prost-build's codegen model onto a plain-JSON, Rust-only use case.
Verified the replacement is strictly simpler, not just smaller: a
hand-written struct's Option<T> field needs zero extra attributes to
handle a missing JSON key (prost's generated String needed an explicit
field_attribute call per field), and #[serde(flatten)] on a hand-written
field has no ambiguity at all (prost-build's oneof/variant path collision
doesn't exist without prost-build's codegen in the picture).
The replacement lives in continuum-proxy: src/printer/bambu_commands/.
continuum.v1 is unaffected — that schema is genuinely cross-language and
proto still earns its keep there.
The rest of proto/bambulab/ was pure boilerplate/comments with nothing
concrete to copy from. This one message (sequence_id + command, matching
Bambu's real get_version request) is wired all the way through: real
proto, real generated Rust struct, lib.rs actually include!'d instead of
commented out. continuum-proxy's bambu_protocol_demo example serializes it
and diffs the output against Bambu's actual wire JSON byte for byte.
Verified with cargo build (this crate) and cargo run --example
bambu_protocol_demo (continuum-proxy) - output matches exactly.
Adds bambulab/v1 and bambulab/v2 to the prost-build pipeline, scoped
separately from continuum.v1's camelCase convention: bambulab.* uses
snake_case, matching Bambu's actual MQTT wire JSON exactly, since this is
edge-only traffic (continuum-proxy) that has to match the printer's real
format rather than a schema we get to design.
Verified the scoping doesn't collide: type_attribute calls are cumulative,
so the existing '.' blanket selector had to become '.continuum' specifically
- keeping it global would stack a second, conflicting #[serde(rename_all)]
onto every bambulab type too and fail to compile.
No message bodies added - proto/bambulab/{common,v1/*,v2/*}.proto are
intentionally just syntax+package+guidance comments (matching what was
already started for v1). build.rs has inline notes on the two real gotchas
already hit while prototyping this: the field_attribute path-matching
oneof/variant collision (solution: hand-write the envelope enum in Rust
instead of modeling it as a proto oneof), and serde needing #[serde(default)]
on fields that aren't always present.
protoc warned that print_job.proto imported template.proto without using it
- removed. ts-types/package.json was missing protobufjs and long, which the
ts-proto-generated code imports at runtime - tsc failed with 'cannot find
module'. src/index.ts also re-exports './generated' as a namespace, but
ts-proto wasn't configured to emit an index barrel file for it - added
outputIndex=true to the protoc invocation.
Verified with a clean 'bun run build' (both TS and Rust codegen) and
'tsc -b'.
Protobuf data model (Template/PrintJob/MaterialProfile/PrintParameters)
with codegen targets for TypeBox+TS types (packages/ts-types) and
prost-derived Rust structs (packages/rust-types).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
octoturge
