The interop driver dispatched 19 commands — device, initiate, encrypt, seal,
log_leaf — and not one touched a content envelope. Swift has had
`content_encode`/`content_parse` for a while; Android has never been checked
against any other implementation at this layer.
🔴 **This is the half that most needed it.** SPEC.md §6.10 says so in as many
words, after the `ctl:true` bug: "no vector covers this envelope. It is the
standing argument for the interop harness." That bug was Android writing
`"ctl":true` where iOS decoded a number — and the cost was not a missed flag
but a failed decode that dropped the whole message onto the plaintext path,
while each engine's own tests passed on both sides.
⚠️ The two parsers fail DIFFERENTLY, which is why a round-trip on either
proves so little. This engine reads field by field through `org.json`, whose
bundled Android build coerces a JSON null to the string "null" where Maven's
returns "". iOS decodes all-or-nothing through `Codable`, so one bad field
downgrades the entire envelope to a raw-JSON bubble. The same additive change
degrades differently on each platform.
`content_parse` also reports `isControl`, so the harness can check §6.10's
rule across engines instead of each engine checking itself.
The matching harness stage is flamenet-e2e!27. Proven by breaking it: making
this engine read the SPEC's `ment` instead of the shipped `men` turned
"iPhone mentions parse on Android" red — the exact drift that has been
invisible since the key was chosen.
1190 tests still pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
