Harden streaming markdown rendering

[blove]

Summary

• consume @cacheplane/partial-markdown 0.5.5, published through npm trusted publishing with provenance
• add streaming markdown torture coverage for lists, fences, nested inline formatting, and blockquotes
• keep the existing table streaming coverage pinned to the published parser behavior

Why

The upstream parser fix keeps streamed blockquote paragraphs nested in their owning blockquote and preserves open-line nested preview updates. The chat package should consume that release and cover nearby streaming surfaces so future parser changes do not regress table or blockquote rendering.

Validation

• git diff --check
• npx vitest run src/lib/streaming/streaming-markdown.torture.spec.ts src/lib/streaming/streaming-markdown.table-stream.spec.ts --config vite.config.mts --reporter=verbose
• npx nx build chat
• Chrome MCP local smoke with mocked LangGraph backend: streamed markdown kitchen sink rendered one table with rows inside the table and blockquote text inside the blockquote

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
threadplane	Ready	Preview, Comment	Jul 7, 2026 4:26am

[github-actions]

Automated approval: this PR received an intelligent (AI) code review. See the review comments on this PR.

[github-actions]

Claude finished @blove's task in 2m 40s —— View job

---

PR Review

• Read changed files and diff
• Analyze test coverage and correctness
• Check dependency update
• Post findings

---

Summary

The dependency bump is clean — @cacheplane/partial-markdown 0.5.4 → 0.5.5 with a valid SHA-512 integrity hash, and the PR description correctly attributes the fix to blockquote paragraph nesting. The new torture spec file is a good addition and the four test scenarios cover the right surfaces (lists, fenced code, nested inline, blockquotes). A few assertion weaknesses worth tightening before merge:

Fenced code test (line 55): el.querySelector('p')?.textContent ?? '' only checks the first <p> element — if the parser regresses and leaks ``` into a second paragraph, this assertion passes silently. Should assert across all paragraphs or on el.textContent directly. See inline comment.

Nested inline test (line 65): Only the **strong delimiter is checked for leakage; the opening *em delimiter could leak without being caught. See inline comment.

Blockquote textContent (line 73): 'hellowor' (no space between lines) is correct for 0.5.5's hard-break continuation behavior, but a one-line comment explaining why no space is expected would help future readers. See inline comment.

No correctness bugs, no security issues, no type-safety problems, no subscription leaks. The package-lock.json version bumps on internal @threadplane/* packages (0.0.53 → 0.0.55) are from the prior support-packages refresh commit and are expected.

[github-actions]

Weak assertion — checks only the first <p>. querySelector returns a single element, so if the parser leaks ``` into a second paragraph this passes silently. Either widen to all paragraphs or assert on the whole element:

Suggested change

	expect(el.querySelector('p')?.textContent ?? '').not.toContain('```');
	expect([...el.querySelectorAll('p')].some((p) => p.textContent?.includes('```'))).toBe(false);

Alternatively: expect(el.textContent).not.toContain('```') — simpler, catches leakage anywhere.

[github-actions]

Only the **strong opener is checked. The opening *em delimiter could still leak without being caught here. Consider also asserting:

Suggested change

	expect(el.textContent).not.toContain('**strong');
	expect(el.textContent).not.toContain('**strong');
	expect(el.textContent).not.toContain('*em');

[github-actions]

'hellowor' (no space) pins the parser's hard-break behavior for blockquote continuations. This is correct for 0.5.5 and the <br> check below confirms it intentionally, but a short comment would make the why obvious for future readers:

Suggested change

	expect(paragraph?.textContent).toBe('hellowor');
	// Continuation `> wor` joins via <br>, not a space — check textContent has no space
	expect(paragraph?.textContent).toBe('hellowor');