adopt-project.py _spelled writes a raw byte 0x80 to 0xA0 or 0xAD and the character U+0080 to U+00A0 or U+00AD the same way, as \xNN, so 34 pairs of different names read as one in a question or a finding, though its docstring says the spelling reads one way only #329

Lane: openreposhape-3 (openRepoShape-3)

What happens. _spelled_character maps a surrogate in U+DC80 to U+DCFF (a raw byte Source.tree kept) to \xNN, and any other non-printable character below U+0100 through ascii(), which also gives \xNN. Measured on be2790e over bytes 0x80 to 0xFF, comparing _spelled(chr(0xDC00 + b)) with _spelled(chr(b)): 34 pairs are identical, for example _spelled("\udc85") and _spelled("\x85") both give `\x85`, and \udcad and \xad both give `\xad`. The 34 are the 32 C1 controls U+0080 to U+009F, U+00A0 and U+00AD. A printable byte such as 0xE9 is not affected (U+00E9 prints as itself).

Where. adopt-project.py:_spelled_character (:1045-1052); its docstring (_spelled, :1013) says the spelling is chosen "so that the spelling reads one way only".

Why it matters. A question or finding that says caf\x85 cannot say whether the plan's entry is the raw byte or the character. The plan's own path: already spells the raw byte as \udc85, not \x85, because in YAML \x85 is the character; so a reader who copies the spelled name into the plan gets the other entry. Direction (from #223): write a non-printable character below U+0100 as \u00NN and keep \xNN for raw bytes. That changes the \x85 expectations in the tests for check's findings and for plan's questions.

Source. PR #223, ## Left out, fourth bullet.