[WIP] Per-message user feedback mechanism

[andybraren]

Implementation of a basic user feedback mechanism for individual messages.

This adds thumbs up/down buttons below messages from any agent and a modal for the user to provide more details before submitting their feedback.

This PR is a work in progress and the UI is still being refined. I'm not quite sure how our Langfuse keys/variables are being passed into the UI today, but Claude seems to think our frontend-deployment.yaml manifest needs them.

WIP Screenshots

[github-actions]

Claude Code Review

Summary

This PR implements a per-message user feedback mechanism that integrates with Langfuse. The implementation is well-structured with good separation of concerns (API route, React components, Context provider). However, there are several critical security, privacy, and architectural issues that must be addressed before merging.

Issues by Severity

Blocker Issues

1. Secret Key Exposure Risk in Frontend Deployment

• Location: components/manifests/base/frontend-deployment.yaml and components/manifests/overlays/local-dev/frontend-patch.yaml
• Issue: The manifests add LANGFUSE_SECRET_KEY, LANGFUSE_PUBLIC_KEY, and LANGFUSE_HOST as environment variables to the frontend deployment
• Why Blocker: The frontend is a NextJS application. The secret key should NEVER be in the frontend container at all
• Fix Required: Remove Langfuse env vars from frontend deployment manifests entirely and add them to backend deployment instead

2. Missing Input Validation and Sanitization

• Location: src/app/api/feedback/route.ts lines 85-92
• Issue: User-provided comment and transcript content are sent directly to Langfuse without sanitization
• Why Blocker: Log injection attacks, potential XSS, data exfiltration
• Fix Required: Sanitize all user input

3. Username Trust Issue

• Location: src/app/api/feedback/route.ts line 79
• Issue: The username is accepted from the client request body without server-side validation
• Why Blocker: Any user can impersonate another user
• Fix Required: Extract username from authenticated session token on the server side

Critical Issues

4. Information Disclosure via Error Messages (lines 132-138)

5. Privacy: Transcript Inclusion Without Sufficient Warning (lines 184-202)

6. Missing Rate Limiting - DoS risk

7. Type Safety Violations - Using any types

Major Issues

8. Duplicate Endpoint Logic

9. Feedback State Not Persisted

10. Missing Error Boundary

11. Missing Loading States

Positive Highlights

Good separation of concerns, Shadcn UI compliance, privacy notice included, graceful degradation, accessibility with ARIA labels

Recommendations

Immediate Actions (Before Merge)

1. CRITICAL: Remove Langfuse secrets from frontend deployment manifests
2. CRITICAL: Add input sanitization
3. CRITICAL: Extract username from authenticated session
4. Fix error disclosure
5. Add rate limiting
6. Fix type safety violations

Architecture Consideration

Consider moving feedback API to the Go backend as a proper endpoint for better security and consistency with auth patterns.

Overall Assessment: Good feature implementation with solid UX, but requires security hardening before production use.

---

🔍 View AI decision process (logs available for 90 days)

📋 View memory system files loaded (click to expand)

What Amber Loaded for Code Review

Amber automatically loaded these repository standards from the memory system:

1. CLAUDE.md - Master project instructions, development standards
2. backend-development.md - Go backend, K8s integration patterns
3. frontend-development.md - NextJS, Shadcn UI, React Query patterns
4. security-standards.md - Auth, RBAC, token handling
5. k8s-client-usage.md - User token vs service account patterns
6. error-handling.md - Consistent error patterns
7. react-query-usage.md - Data fetching patterns

Impact: This review used your repository's specific code quality standards, security patterns, and best practices from the memory system (PRs #359, #360) - not just generic code review guidelines.