fix(web): user messages keep their typed list numbers#23369

Approvability

Verdict: Approved at b1b1c21

Macroscope's review found this PR approvable — This is a localized web bug fix that preserves user-entered ordered-list numbers during rendering and copying, with opt-in integration and focused parser/clipboard tests. The additional fixture and seeding files are development-only evidence tooling, and no product defaults or static-analysis suppressions are changed.

Notes:

• This verdict was updated automatically after the outstanding correctness findings were resolved. Macroscope did not re-review the code.

^{You can add or adjust custom eligibility rules. Learn more.}

Review in Change Stack →

No actionable comments were generated in the recent review.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

ℹ️ Recent review info

⚙️ Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: fix/issue-8394
• File: .coderabbit.config.ts
• Commit: b1b1c21
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Team
• Run ID: 7e8383ae-fd78-4f0f-9f60-e4501fccf06a

📥 Commits

Reviewing files that changed from the base of the PR and between f683178905cee83bcb507cee424c3507e2660aad and b1b1c21917ef1fb43a082bdf0195038728c73fc5.

📒 Files selected for processing: 1

• scripts/seed-issue-8394.py

Limit details: You’ve used all 10 included reviews currently available.

Addressed in f683178905: seed backups are created with mkstemp beside the isolated database, mode 0600 under umask 022. SQLite integrity and preserved rows were verified. The shared evidence directory now receives only the synthetic Markdown fixture.

Addressed in b1b1c21917: the synthetic fixture now uses a fresh private temporary directory and exclusive file creation. Seeded file/context references use the generated path. A planted-symlink diagnostic confirmed the victim remained unchanged; directory mode 0700 and script compilation passed.

Nested lists in a user message still show letters with this branch: a list typed as 4. 7. under another item renders as "d." and "g.", because .chat-markdown ol ol sets lower-alpha (and ol ol ol sets lower-roman) in apps/web/src/index.css. Hit the same bug myself and built a fix before finding this PR, so wanted to share what turned up if at all helpful.

I compared this branch's head (b1b1c21) with my branch by copying its plugin and clipboard code into focused tests on current main:

You noted the last two as unchanged, and the partial copy is on main for every ordered list too.

What would fix it

• Nested markers: a rule scoped to user bubbles, such as .chat-markdown[data-typed-list-numbers] ol ol { list-style-type: decimal; }, with the attribute set only when typed numbers are on. Agent replies keep their letters.
• Rebuilt lists: record each typed number while parsing, with a fromMarkdownExtensions exit.listItemValue handler, instead of reading source offsets. Lists that indentation recovery parses a second time then keep their numbers too.
• Copy: parse start with an isNaN check instead of || 1, and when a selection starts partway into a list, write the number shown onto the first copied li as value.

Your same-number rule is better than mine (1. 1. 1. should count up in user messages too), and I'd switch to it.

All of this is in one commit on current main, with tests. Happy to open a follow-up PR once this merges, or you can pull the pieces into this one if that's easier.

Not settled

• Messages agents send: from reading the code, UserMessageBody also renders prompts sent by agents and T3 Code, so their skipped numbers now show as typed. I limited typed numbers to messages with attribution null or "guest". Your same-number rule makes this matter less, so I'm not sure which you'd want.

Thanks @juliusmarminge for the earlier work and detailed evidence. Closing this as a duplicate of #33820 by @tsapa44, which addresses the same sent-message numbering defect and is current and mergeable; this branch is from October 22 and conflicts with main. The selection-copy handling here is separate and could be proposed as a smaller follow-up if still needed.