[finding] The #11106 mechanical re-wrap left 45 soft breaks sitting after an ASCII comma between Chinese clauses — each renders as a stray mid-sentence space #12081

Measured while landing the os-dev.md verification pack (#11539 / #11648 / #11419 / #11463 / #11923). Filed unassigned, observation class — ⛔ not fixed in that PR, which is scoped to five named amendments and only surfaced this while paying its ratchet cost by re-flowing prose.

The defect

The corpus wraps CJK prose by inserting a newline. That is correct and the ratchet's own header explains why: a segment break between two wide characters is removed by the CSS segment-break transformation, so it renders as nothing.

But a break placed directly after an ASCII comma / semicolon / colon is not between two wide characters. , is U+002C, and this corpus uses ASCII punctuation throughout (measured on .claude/agents/os-dev.md at origin/main: 197 ASCII commas after a Han character, 0 fullwidth U+FF0C). A soft break there renders as an ordinary space.

So the source

…prompt 的沉默是常
态,
不是许可:

renders as …prompt 的沉默是常态, 不是许可: — with a space the author never wrote, mid-sentence, in Chinese prose that has no spaces anywhere else.

Scale, measured across the line-ratcheted corpus

Counting soft breaks that sit immediately after an ASCII , ; : where the preceding character is Han and the next non-whitespace character is Han:

Why it is worth recording rather than shrugging at

⚠️ It is invisible in the source and visible in the render — the inverse of the usual reading. Every reviewer reads these files as source, where the break looks like ordinary wrapping; the space only exists for the agent that reads the rendered text. That is the whole population these files are written for.

⭐ And it is self-concealing under re-wrap: re-flowing such a paragraph and re-wrapping it faithfully must preserve the space (it is what the text renders as), so the space migrates from a line break into a literal ", " in the source. It looks like the re-wrap introduced it. It did not — it only made an existing render visible. Anyone auditing a future re-wrap by eye will reach the wrong conclusion here, which is why the mechanism is written down.

Not asserted

• ⛔ Not a claim that the wrapLine algorithm is wrong. It only ever moves whitespace and it is correct on its own terms; the question is whether a break after ASCII punctuation should be offered at all in CJK prose, which is a judgement about house typography, not a bug in the wrapper.
• ⛔ Not a claim about how many of the 45 predate [finding] The pm-skill ratchet counts LINES while its header prices a per-session token read — a green 134/134 run grew platform-readings.md ~33% in bytes #11106 versus were introduced by it. The one-off re-wrap re-flowed 555 legacy over-long lines, so it is the likely source, but this seat did not audit the pre-[finding] The pm-skill ratchet counts LINES while its header prices a per-session token read — a green 134/134 run grew platform-readings.md ~33% in bytes #11106 revisions and the fix does not depend on the answer.
• ⛔ No proposal about how to close it. The obvious candidates (add ASCII ,;: to NO_BREAK_AFTER so the wrapper stops offering the break; or a one-off pass closing the 45) have costs — the first re-wraps the corpus again and moves every ceiling, the second is manual and rots. That is a maintainer/skills-seat call, and a wrong guess here is a corpus-wide diff.

Dedup

Enumerated all 380 open issues via the repo-scoped REST list endpoint (5 pages, 408 open items incl. PRs) and filtered titles on re-?wrap|wrapping|空格|stray space|标点|punctuation|comma|soft ?break|行宽|line-length|120 → 9 hits, none of them this. The nearest neighbour is #11947 (133 lines over the 120-byte budget by structural exemption), which is about line length, not about what a break renders as.

⚠️ Positive control, and it is load-bearing: a first pass at this scan returned 5 issues total and 0 control hits — the concatenated-pages JSON was being mis-split, and the zero was an artifact of a dead instrument, not a fact about the backlog. Re-run with each page parsed separately, the control /os-dev|ratchet/ returns 11 hits, so the enumeration is live and the zero above is real.