fix(ui): space CJK-Latin mixed prose in Markdown answers

[Astro-Han]

Summary

Maka is CJK-first and its assistant prose is dense mixed script — Chinese wrapped around identifiers, paths, version numbers and line numbers. Measuring that surface against the built app turned up three spacing gaps, plus a literal-code boundary that has to hold for them. Refs #1433 (item 5, reframed).

text-autospace: normal on .maka-prose. Chromium's initial value is no-autospace, not the spec's normal, so the CJK/Latin boundary spacing has to be asked for. It reaches across inline element boundaries, so <code> pills get it on both sides too. Scoped to the prose layer rather than :root: the composer, sidebar and settings surfaces would all shift text metrics, which is a separate call.

margin-inline: 0.25em on inline code. Autospace alone leaves 1.55px against a pill that already carries padding and a filled background, where the code still reads glued to the surrounding Chinese. The two stack rather than replace each other — measured 78.36px → 81.48px (autospace) → 87.45px (both) on the same paragraph. Zeroed at block edges: that margin is the gap to neighbouring text, and at a block edge there is none, so it indented the block instead (2.98px, a ragged left edge down a list of items opening with code).

<br> + .maka-hardbreak for hard breaks. remark-breaks turns every single newline into a hard break, and model answers lean on **subhead**\nbody to separate sections, so this gap routinely carries a section split. It had only the 4px the line box already gives, against 16px between paragraphs — the stronger semantic split rendered tighter than the weaker one. CSS cannot space a native <br>: display:block, height, margin and content:"\A" each leave the paragraph at exactly 39px, because an inline break box cannot take a height. So markdown-body emits the native <br> followed by a block span. Both are needed: the span alone drops the LineBreak node from the accessibility tree (verified via CDP), and the <br> alone cannot be given a height. Together they keep the AX node, keep Selection.toString() at a single \n, and land the gap at 10px between the 4px line gap and the 16px paragraph gap.

The hard-break gap is scoped to paragraphs. remark-breaks makes every newline a break, so the 6px also landed on continuation lines inside list items and blockquotes, inverting the grouping: 10.5px inside one list item against 6.5px between two of them. Those containers already group their own content.

The literal-code boundary. The first two rules are prose decoration, and both reach fenced code unless carved back out — text-autospace inherits, and .maka-prose code (0,1,1) matches pre > code as well as the inline pill. This is the invariant #1431 already locked for ligatures ("code is a literal surface"), reached a second time by different properties, so .maka-code-block pre now carves prose shaping out as a named boundary and the contract guards the boundary rather than the two known leaks.

MARKDOWN-PROSE-CJK-MIXED-SPACING-0 locks the CSS tier; packages/ui's render test locks the DOM tier.

Verification

npm --workspace @maka/desktop run test:dist 2850/2850 · npm --workspace @maka/ui run test · npm run typecheck · npm run lint · npm run format:check · node scripts/check-dead-css.mjs.

Measured in the built Electron app (Electron 43.1.1 / Chromium 150), not headless. That distinction is load-bearing: headless Chromium silently falls PingFang SC back to a serif face while document.fonts.check still reports true, so every font-dependent number taken there is void. Confirmed with CSS.getPlatformFontsForNode that the real stack resolves to PingFang SC / .SF NS / Geist Mono (custom).

measurement	before	after
CJK/Latin boundary	0	+1.55px (1/8 em at 13px)
Chinese ↔ code pill	0	+4.5px per side (autospace + margin, measured additive)
hard-break gap	4px	10px
fenced code, first line vs rest	36.25px vs 33px	33px vs 33px
block opening with an inline pill	+2.98px indent	0
list-item continuation vs item gap	10.5px vs 6.5px	6.5px vs 6.5px
paragraph gap (unchanged)	16px	16px

The contract asserts the neutral value of each carve-out, not just that the property name reappears — the first version was a presence check wearing a neutralisation check's error message, and reverting a carve-out to the leaking value kept it green. Deletion-sensitivity was checked by breaking it four ways and confirming each goes red: removing the pre autospace carve-out, removing the pre code margin reset, and adding a fresh letter-spacing to .maka-prose with no carve-out. Removing remarkBreaks now fails packages/ui's render test, which previously would have left .maka-hardbreak as unreachable dead CSS with every assertion still green.

Review focus

Three-way review (Codex, an independent agent, Kimi K3 256K) all returned FAIL on the first revision and converged on the same defect class; the second commit is the response. What they found, and what changed:

• Prose decoration leaked into fenced code. Confirmed independently — the first source line of every code block started 3.25px right of the lines below it, and CJK/Latin code lines drifted off the monospace grid. Fixed at the boundary rather than as two patches, since this was the second arrival of the same invariant at the same seam. (One reviewer rated the margin leak P3 as "symmetric, nearly invisible" from reading the cascade; measuring it shows it is not symmetric — a <code> in white-space: pre is one inline box across all lines, so only line 1 moves.)
• word-break: auto-phrase on td was inert. Removed. Chromium's phrase model is Japanese-only: identical break positions to normal under lang="zh-CN" and lang="en", while lang="ja" does change. Double-gated by the renderer's static <html lang="en">. The rule, its comment and its test all asserted a behaviour that does not occur.
• The bare span cost the AX LineBreak node. Fixed by emitting <br> + span. Nesting the <br> inside the span instead is what produces a spurious "\n\n" on copy; the sibling form has no such cost.
• The contract was source-regex only, and both leaks passed it. The DOM half moved to packages/ui's render test where AST → DOM belongs, and the CSS half now guards the boundary as a property class.

An E2E computed-style spec was suggested by all three and not taken: MAKA_E2E_FIXTURE is a scenario enum, not free-text injection, so pinning specific Markdown would mean adding a product-layer fixture scenario — disproportionate here. The two seams used instead are a real render (packages/ui) and a boundary-completeness contract.

Still open as a judgement call: text-autospace stays on .maka-prose, so a user's own message bubble does not get the same treatment as the assistant's answer. LobeChat puts it on :root. Widening it is a follow-up, not an oversight.

Several things were rejected while measuring, each for a recorded reason: narrowing the reading measure (Paseo, opencode and LobeChat all have no fixed measure at all — the premise in #1433 item 5 does not hold); letter-spacing: 0.02em (conflicts with the CJK-first no-tracking decision already in prose.css); font-synthesis: style (PingFang SC has a real Semibold, so all three settings render identically); a CJK font in the mono stack (code-block Chinese already falls back to PingFang SC, and Geist Mono resolves correctly); remark-cjk-friendly (10 emphasis cases pass on the current remark — only intraword _ fails, which is CommonMark's design and applies to Latin equally); and text-box-trim (LobeChat shipped, narrowed and reverted it inside a week).