CLI markdown renderer creates phantom ordered-list item when content contains a sentence-ending digit (e.g. "Phase 5.")

Summary

When an assistant-authored ordered list contains a list item whose text includes a sentence ending with a digit + period (e.g. Phase 5.), the rendered output in the CLI appears to treat the wrapped 5. as a new ordered-list item. The effect is a visible phantom entry and renumbering of subsequent items.

The source markdown is a single line — no literal newline is present between Phase and 5. — so a spec-compliant CommonMark parser operating on source newlines should not create a new item. This suggests the renderer is either wrapping before parsing, or reparsing wrapped lines.

Reproduction

Have the model emit an ordered list where one item contains a sentence ending in digit., with enough preceding text that terminal wrapping pushes <digit>. to the start of a visually rendered line.

Example source (single paragraph inside item 2):

\\\`

1. ✅ Embedding backfill — done (5,197/5,197 embedded, daily launchd job scheduled)
2. ⏸️ Timeline entries — reframed as Phase 5 pipeline work, not a gap. Only tackle if you want to continue GBrain-integration Phase 5.
3. 🟡 pai cache-secrets bug — still open

\\\`

Actual rendered output (as seen by the user)

\\\`

1. ✅ Embedding backfill — done (5,197/5,197 embedded, daily launchd job scheduled)
2. ⏸️ Timeline entries — reframed as Phase 5 pipeline work, not a gap. Only tackle if you want to continue GBrain-integration Phase

5.

1. 🟡 pai cache-secrets bug — still open

\\\`

(The \5.\ line renders as an empty list item, fragmenting the intended 3-item list into visual confusion.)

Expected

A sentence-final \digit + period\ that appears mid-paragraph in source markdown should remain part of that paragraph after rendering, regardless of terminal width or word-wrap behavior. Wrapping should be a display-only transform applied after markdown parsing.

Workaround

Assistants can defensively avoid sentence-final numeric references inside ordered lists — but the renderer correctness is the right fix.

Environment

• darwin 25.4.0, zsh
• Claude Code CLI (terminal output)
• Model: Opus 4.7 (1M context)
• Observed 2026-04-22