The note added a moment ago sat inside `properties` as
`"_comment_no_vt_tray": "..."`, which declares a property whose schema is a
string - and in draft 2020-12 a subschema has to be an object or a boolean.
It parses as JSON and reads fine, and a strict validator would reject the
whole schema. `$comment` is the keyword for this and belongs beside
`properties` rather than inside it.
Swept the rest of schemas/ for the same shape while here: every other
property value is a real subschema.
Two things the live captures showed that the schemas did not say.
`msg` was missing from the v1 push_status schema, which is the one version
where it is load-bearing. v1 pushes only the fields that changed, except for
a pushall-triggered push which is the whole object, and `msg` is how a v1
message self-describes which it is (0 forced/full, 1 automatic/partial). A
consumer that replaces its cached object with a partial push silently unsets
every field that push did not mention, and there is no other way to tell:
push_status does not echo `sequence_id`, so there is no correlation back to
the pushall that asked for it. continuum-proxy has read this field since the
cache was written; the schema just never declared it.
v2 had it with no description. It is informational there - v2 sends the whole
object every time - so it now points at the v1 note rather than repeating it.
The other half is an absence, which a schema cannot express by staying
silent: v2 has no `vt_tray` because a real v2 printer omits the key entirely
rather than sending an empty object. That is recorded as a comment so nobody
adds it for symmetry with v1, because the distinction is the thing: absence
means "not reported", not "no external spool", and it is exactly why
`EXTERNAL_SPOOLS` in continuum-proxy is a constant instead of being counted
from a report.
Confirmed live: both BambuMQTT versions reply to a calibration request
with a dedicated print.calibration report, not just push_status - the
v1 request schema's own description said the opposite ("printer responds
with push_status instead of calibration"), and v2's report schema framed
this as a v1-vs-v2 contrast that no longer holds. Both descriptions
corrected; the printer does still send ordinary push_status updates
alongside the dedicated report as calibration progresses, same as any
other print job, not instead of it.
Added v1/report/print/calibration.schema.json (only existed for v2
before) and wired it into v1/report.schema.json's print category
dispatcher, which never listed it since the file didn't exist.
- 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
octoturge