Source compatibility is promised, and verified in one language

[Onwcan]

What is promised

buf.yaml uses the FILE breaking rule rather than only PACKAGE or WIRE.

The reason matters.

WIRE compatibility alone would allow a protobuf field to be renamed. The encoded bytes would remain compatible, but generated source APIs would change and existing consumers could stop compiling.

Source compatibility for generated consumers is therefore part of the compatibility promise made by this repository.

What is verified today

tests/test_compatibility.cpp contains 12 tests using three independent schema versions compiled into one binary.

Messages are serialised with one version and parsed using another.

That is the correct kind of compatibility test and provides substantial coverage.

It is also entirely C++.

Why this is a gap

The reason for using protobuf at the boundary is precisely that both sides do not need to use the same implementation language.

A realistic cell might have:

• a C++ controller
• a Python diagnostic or tooling process
• another consumer written in Go or a similar language

The compatibility promise concerns generated code, and generated APIs differ between languages.

For example:

• Python exposes fields as attributes.
• Go exports identifiers according to its own naming conventions.
• Enum names become language-specific generated identifiers.

The repository currently verifies the broader promise only in the language where it happens to be cheapest to test.

Acceptance criteria

• Add at least one compatibility consumer test in a second language.
• Prefer Python unless there is a reason to choose another language.
• The second-language suite does not need to duplicate all 12 C++ tests.
• At minimum, test parsing a v2 message using v1 generated code and verify that known fields survive.
• Round-trip a v2 message through v1 generated code and verify that unknown fields survive.
• Verify that an absent enum field is read as UNSPECIFIED.
• Run the second-language compatibility suite in the existing CI pipeline.
• Do not treat a test that runs only locally as a compatibility gate.
• If maintaining a second generated-language test is judged not worth the CI cost, narrow the README's compatibility promise explicitly to C++ consumers instead.

Either outcome is acceptable.

What should not remain is a compatibility promise broader than the evidence supporting it.