Paul HittandClaude Opus 5
c336139555
The content layer had no vectors. Everything from section 6.6 onward was
guarded by round trips through this same codec, which would pass
unchanged if this app and Android disagreed about every key. That is how
SPEC 6.18 specified `ment` for as long as it existed while both clients
have always sent `men`: the only thing that could have caught it is a
conformance test written from the spec, and there was none.
`ContentVectorGenerator` builds fifteen envelopes with the shipped
encoders and, when asked, writes them out. That file is now the
published vector. Generating it by RUNNING the encoders is the point:
transcribing a wire format by reading it is exactly how `ment` got into
the spec.
Android reads the same file with a different codebase, which is the
independent half. This side checks drift: the vector records what these
encoders emit, so if somebody changes one, every implementation built
against that file is wrong from that moment, and this turns it into a
failed test rather than a report from somebody whose mentions stopped
working.
The comparison is structural, and it has to be. Nested objects here go
through `JSONEncoder`, which does not order its keys, so the same
message encodes as `{"mid":…,"author":…}` on one run and
`{"author":…,"mid":…}` on the next. That costs nothing on the wire,
where everyone parses, but it does mean a vector can pin what an
envelope says and never the bytes it says it in. Comparing strings
failed nine of fifteen cases on the first run, every one of them key
order, not one a difference any receiver could observe.
The drift gate did not cover `content-v1.json`, and had not covered
`backup-v1.json` either until yesterday. Both loops now list it.
Proven capable of failing: flipping `men` to `ment` in the pinned file
turns three tests red.
Full suite: 126 tests in 24 suites, all passing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2 lines
41 B
Plaintext
2 lines
41 B
Plaintext
588929cca79e252c62fb8d50a77218bb4a6f884a
|