(Found during the compact-preset-transport work, not the recipe-model branch — filing here since it's an internal/preset gap, unrelated to recipe-model.)
internal/preset/compact.go:155 returns the resolved preset directly after decoding a compact code, whereas the browser implementation decodes, resolves against the catalogue, and then re-encodes canonically before comparing/accepting.
Today's catalogue appears to be injective (each resolved preset maps back to one canonical compact code), so this doesn't currently produce a divergence. But if a future palette alias makes the catalogue non-injective, Go could accept a compact code that the browser's canonical re-encoding step would reject — a silent client/server disagreement.
Suggested fix: in the exhaustive Go test, assert EncodeShare(decoded) == originalCode for every code exercised, so any future non-injective catalogue entry fails the test loudly instead of shipping a divergence.
(Found during the compact-preset-transport work, not the recipe-model branch — filing here since it's an internal/preset gap, unrelated to recipe-model.)
internal/preset/compact.go:155returns the resolved preset directly after decoding a compact code, whereas the browser implementation decodes, resolves against the catalogue, and then re-encodes canonically before comparing/accepting.Today's catalogue appears to be injective (each resolved preset maps back to one canonical compact code), so this doesn't currently produce a divergence. But if a future palette alias makes the catalogue non-injective, Go could accept a compact code that the browser's canonical re-encoding step would reject — a silent client/server disagreement.
Suggested fix: in the exhaustive Go test, assert
EncodeShare(decoded) == originalCodefor every code exercised, so any future non-injective catalogue entry fails the test loudly instead of shipping a divergence.