· ReadyStack
Worked example
Real numbers from this tool, line by line.
Eighteen findings in 27 lines. That is what the sample .proto in this repository returns, and every one of them is an edit a backend engineer who owns a gRPC service would wave through in a normal review.
Start with the one that costs the most, because no compiler will mention it. You delete a field from a message. The right move is to leave a reserved statement behind, so the number is spent forever. The common move is to delete the line, because the build is green either way. Six weeks later somebody adds a field and takes the next number that looks free - the one you just freed. Nothing throws. The service starts, the RPC returns, and every reader built before your deletion decodes the new data as the old type. A string arrives where an int64 used to be, and the parse either fails quietly or succeeds into the wrong field. You find out from a dashboard, days later, and the fix is a rollback.
A hole in the field numbers is legal proto. protoc has no opinion about it, and has never seen the mobile client you shipped last quarter - the only thing that makes the hole dangerous. That is the shape of the class: the edits that hurt are the legal ones, and the question is not "does this compile" but "does this change what an already-deployed reader sees".
Proto Wire Break Check applies 17 rules to the .proto in front of you and answers that second question, line by line.
Six are about the tag itself: a field number used twice in one message, a number the message already reserved, a reserved name taken back, an unreserved hole in the numbering, a number inside the protobuf-internal range 19000-19999, and a number outside 1 to 536870911. Two are about names: two fields that serialise to the same JSON key - invoice_id and invoiceId both become invoiceId - and two fields that share a name outright. Three are about enums, where the damage is quietest: a proto3 enum whose first value is not 0, so an unset field decodes as a real state instead of "unspecified"; two values on one number without allow_alias; and a removed state whose number was never reserved, free to be reissued on the same byte. The last six are presence and syntax: no syntax line, so the file silently compiles as proto2; no package; a required field, which can never be removed later; a proto2 default on a proto3 field; a bare proto3 scalar where absent and zero differ, such as amount_cents; and packed = false on a repeated scalar, which writes different bytes for the same values.
The measurement is in the repository, so you can repeat it. _fixtures/dirty.proto is 27 lines and returns 18 findings - 10 errors and 8 warnings - firing 13 of the 17 rules. _fixtures/clean.proto is the same schema written safely and returns 0. One of those 18 reads: field number 2 already belongs to "amount_cents" on line 10 of Invoice.
The same engine runs in the editor and in the browser, byte for byte. The free version checks the file you have open: all 17 rules, every finding, every line number, no key and no account. For one file that is the entire job.
What it does not do is answer the question across a repository at review time. The full version sweeps every .proto in the workspace in one pass and writes PROTO-WIRE-AUDIT.md plus audit.json - one artefact you can commit, attach to a pull request, or fail a build on. It is $29 once, one licence key per person or team seat. The yardstick: a contract backend engineer runs $60+/hour on the public marketplaces, and answering "which field numbers in this service are already spent" by hand is an afternoon of that.
15 seconds — what it actually does
Questions people ask
What does Proto Wire Break Check actually do?
It reads a .proto file and applies 17 rules that catch edits which still compile but change what an already-deployed reader sees: a field number used twice, a reserved number taken back, two fields that share a JSON key, a proto3 enum that does not start at 0. Each finding names the line and the edit that keeps the wire intact.
Who is it for?
Backend and platform engineers who own a gRPC or Connect service and review .proto changes from teammates or AI agents. If a schema edit of yours ships to a mobile client, a partner integration, or a Kafka topic you cannot redeploy in the same hour, this is the class of mistake that costs you a rollback.
Why is protoc or a chatbot not enough?
Roughly half of these edits are legal proto, so protoc never mentions them - an unreserved hole in the numbering, a bare scalar where absent and zero differ, a removed enum state. The rest fail a build you have to wait for. And a language model tells you the file compiles, which is true and is not the question: it cannot know which tags your deployed readers still write.
What is free and what needs a licence key?
Free and without a key: the whole check on the file you have open, all 17 rules, every finding with line numbers. The 27-line sample file returns 18 findings, 10 of them errors. The licence key adds the workspace-wide sweep and the written PROTO-WIRE-AUDIT.md plus audit.json you can commit or gate a build on.
What would this cost me otherwise?
A contract backend engineer runs $60+/hour on the public marketplaces, and walking one service's schema history to answer which field numbers are already spent is an afternoon of that. The full version is $29 once, one licence key per person or team seat,.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. Protobuf Breaking Change Lint - wire compatibility (.proto) checks the file you open against 17 rules from a rule set dated 2026-09-20, and points at the exact line with the fix. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.