feat: add message retry and regenerate functionality

[Ashok161]

Summary

• add retry buttons for error assistant messages and regenerate actions for the latest successful assistant reply
• refactor widget sending so normal send, retry, and regenerate share the same streaming path and preserve history state
• add server-side regenerate support by removing the previous assistant reply and avoiding duplicate user messages with stable message ids
• add tests for message actions, widget retry/regenerate flows, conversation removal, and regenerate handling in the server

Verification

• corepack pnpm --filter @chatcops/widget test
• corepack pnpm --filter @chatcops/server test -- tests/handler.test.ts
• corepack pnpm --filter @chatcops/core test -- tests/conversation/manager.test.ts
• corepack pnpm -r typecheck
• corepack pnpm --filter @chatcops/core build
• corepack pnpm --filter @chatcops/widget build
• corepack pnpm --filter @chatcops/server build

Closes #18

[vercel]

@Ashok161 is attempting to deploy a commit to the CODERCOPS Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
chatcops-website	Ready	Preview, Comment	Mar 27, 2026 1:54am

[anurag629]

Hey @Ashok161, this PR has merge conflicts with dev — likely from the tool timeout PR (#38) that was merged earlier. Can you rebase on latest dev and resolve the conflicts? Then I'll do a proper review.

git fetch upstream
git rebase upstream/dev
# resolve conflicts
git push --force-with-lease

[anurag629]

Also one thing — as per our contributing guide, the workflow is to work directly on your fork's dev branch and PR from dev → upstream dev. Feature branches work too but keeping it on dev keeps things simpler. No need to change this PR, just for next time.

[Ashok161]

@anurag629 I was following the guide, but then I was working on multiple PR's so I thought of using custom branch name's. I will follow the guide from next and try to work on one issue at a time

[anurag629]

Good work on this @Ashok161, the retry and regenerate logic is well thought out. The retryRequests Map for preserving request context across retries is a nice touch. Found a couple of things that need fixing before we merge this.

[anurag629]

So right now error messages with status: 'error' are getting saved to localStorage. If someone gets an error and refreshes the page, they'll see the error bubble with a retry button — but the retry won't work because retryRequests is an in-memory Map and it gets cleared on refresh.

The simplest fix would be to filter out error messages when saving:

messages: this.messages.filter(m => m.status !== 'error').map(...)

Or if you want retry to survive refresh, you'd need to persist the retry context too, but I think filtering them out is the cleaner approach.

[anurag629]

Both RETRY_ICON and REGENERATE_ICON are the same SVG. You can just use one shared constant instead of duplicating it. Or better, use different icons so the user can visually tell the difference between retry (error recovery) and regenerate (get a new response).