Implement custom Kapa support handoff chat with polished codeblock UX

[dannyneira]

Summary

This PR restores a custom Kapa side-chat experience for docs and adds a robust support handoff flow to Front, while preserving Kapa answer quality and improving chat UX.

What’s included

• Re-enabled custom Kapa chat launcher/panel behavior in docs.
• Added trigger-based Create ticket handoff UX (uncertainty/downvote/conversation depth paths).
• Added docs API route for support handoff submission.
• Switched handoff transport to Hookdeck-backed endpoint routing.
• Upgraded chat code block rendering to match docs styling with:
  • syntax highlighting,
  • stable copy button behavior,
  • horizontal scrolling,
  • no streaming flicker,
  • corrected line spacing.
• Improved handoff success/error states and inline form behavior.

Verification

• npm run build passes.
• End-to-end smoke verified:
  • chat renders/streams correctly,
  • code blocks highlight and copy correctly,
  • support handoff submission succeeds.

Notes

• This is a clean-history replacement PR for the earlier iterative branch.

Co-Authored-By: Warp Agent agent@warp.dev

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 11, 2026 11:47pm

[oz-for-oss]

Overview

This PR restores the custom Kapa chat panel, adds code-block rendering and copy UX, documents MCP OAuth workarounds, and introduces support handoff/highlight API routes.

Concerns

• The code highlighting cleanup path can still emit an unhandled rejection when Shiki highlighting fails.

Security

• The new support handoff endpoint is public and can be scripted to create support tickets without a rate limit or proof that the request came from a real Kapa conversation.

Verdict

Found: 0 critical, 2 important, 0 suggestions

Request changes

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

⚠️ [IMPORTANT] [SECURITY] This public route forwards directly into support ticket creation using only client-supplied fields (page_url, email, thread id) as proof, so anyone can script POSTs and spam Front through the shared server secret; require an anti-abuse gate such as rate limiting plus a CAPTCHA/Kapa-issued token or server-side thread verification before forwarding.