chore(release): staging to production - 2026.01.28

[github-actions]

🚀 Release: Staging to Production

Release Date: 2026-01-28

Changes in this release

• fix(SUPPORT-5): use contained secondary for credential action buttons (f8c00c8)
• fix(SUPPORT-5): auto-save on credential connect (25c750d)
• fix(SUPPORT-5): add ConfirmDialog and persist disconnect to API (4cb3541)

---

This PR is automatically created/updated when commits are pushed to staging.
Merging this PR will trigger the release workflow to create a new GitHub release.

[vercel]

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

Project	Deployment	Review	Updated (UTC)
answerai-docs	Building	Preview	Jan 28, 2026 8:19pm
the-answerai	Building	Preview	Jan 28, 2026 8:19pm

[claude]

PR Review: Staging to Production - 2026.01.28

Overview

This release PR merges 3 bug fixes from staging to production related to guardrails credential management (SUPPORT-5).

---

✅ Code Quality & Best Practices

Strengths

1. Auto-save implementation: The new onSave callback properly persists credential changes immediately to the API, improving UX by eliminating the need for manual save clicks
2. Consistent pattern: Auto-save is correctly applied in all credential selection flows:
   • Creating new credentials (line 149)
   • Disconnecting credentials (line 196)
   • Selecting existing credentials (line 416)
3. UI improvements: Button variants changed from outlined to contained with secondary color provides better visual hierarchy and consistency
4. ConfirmDialog integration: Properly imported and rendered for the disconnect confirmation flow

Suggestions

1. Props interface documentation: Consider adding JSDoc comments to MasterConfigProps to document when onSave is called vs onConfigChange:

   interface MasterConfigProps {
       config: GuardrailConfig
       /** Called for optimistic UI updates (no API call) */
       onConfigChange: (updates: Partial<GuardrailConfig>) => void
       /** Called to persist changes to API immediately */
       onSave: (config: GuardrailConfig) => void
   }

2. Potential race condition: The auto-save pattern calls both onConfigChange (optimistic update) and onSave (API call) simultaneously. Consider if onConfigChange is needed when onSave already updates the config via setConfig(newConfig) in GuardrailsSettings.tsx:71

---

🐛 Potential Issues

1. Error handling gap in auto-save

The onSave calls don't handle errors. If the API call fails, the UI state and server state will be out of sync.

Current code (line 149):

onSave({ ...config, credentialId, enabled: true })
// No await, no try/catch

Recommendation:

try {
    await onSave({ ...config, credentialId, enabled: true })
} catch (error) {
    // Revert optimistic update
    setSelectedCredential('')
    setEnabled(false)
    showSnackbar('Failed to save credential selection', 'error')
}

2. Duplicate config spreading

Lines 149, 196, 416 use { ...config, ... } but some properties in config might be stale or contain unexpected fields.

Current:

onSave({ ...config, credentialId, enabled: true })

Safer approach:

onSave({ 
    enabled, 
    credentialId,
    // Only spread if you need other config properties
})

3. ConfirmDialog missing props

Line 435 renders <ConfirmDialog /> without any props. Based on the useConfirm hook usage (line 66), this is likely correct, but verify that the dialog connects to the confirm() calls correctly.

---

🚀 Performance Considerations

1. No blocking issues - Changes are minimal and localized
2. API calls: Auto-save increases API traffic slightly, but this is acceptable for better UX on credential management
3. Re-renders: Multiple state updates (lines 146-149) might cause 2-3 re-renders. Consider batching:

   // Use React 18 automatic batching or wrap in startTransition
   setSelectedCredential(credentialId)
   setEnabled(true)
   onConfigChange({ credentialId, enabled: true })
   await onSave({ ...config, credentialId, enabled: true })

---

🔒 Security Concerns

✅ No security issues identified

• Credential management follows existing patterns
• No sensitive data exposed
• API calls go through existing authentication layer
• Organization-scoped credentials maintained

---

🧪 Test Coverage

Missing Tests

This PR doesn't include test updates. Recommended E2E test cases:

// apps/web/e2e/tests/guardrails.spec.ts
test('auto-saves when connecting credential', async ({ page }) => {
    // 1. Create new credential
    // 2. Verify API called with POST /api/v1/guardrails/:orgId
    // 3. Verify UI shows connected state
})

test('auto-saves when disconnecting credential', async ({ page }) => {
    // 1. Click disconnect
    // 2. Confirm dialog
    // 3. Verify API called with updated config
})

test('auto-saves when switching credentials', async ({ page }) => {
    // 1. Click change button
    // 2. Select different credential
    // 3. Verify API called immediately
})

Suggested Manual Testing

1. Happy path: Create credential → verify auto-save → refresh page → verify persisted
2. Error handling: Disconnect network → select credential → verify error message
3. Multi-user: User A connects credential → User B sees read-only mode → User B can disconnect
4. Button styles: Verify "Change" buttons use contained secondary style

---

📋 Checklist Review

Per .claude/rules/web-app.md:

• ✅ Client components properly marked with 'use client'
• ✅ No server-side data fetching added (only API calls)
• ✅ Error handling uses existing patterns
• ⚠️ E2E tests not updated (see recommendations above)

Per repository standards:

• ✅ Conventional commit messages
• ✅ PRs against staging (this is staging→production, correct flow)
• ⚠️ No migration changes (N/A for UI-only changes)
• ⚠️ Auto-save error handling needs improvement

---

🎯 Recommendations

Priority 1 (Before Merge)

1. Add error handling to auto-save calls - Critical for production reliability
2. Verify ConfirmDialog integration - Manually test disconnect flow

Priority 2 (Follow-up PR)

1. Add E2E tests for auto-save behavior
2. Consider batching state updates for performance
3. Add JSDoc comments to props interface

Priority 3 (Nice to have)

1. Consider if both onConfigChange and onSave are needed
2. Evaluate spreading entire config object vs explicit properties

---

Summary

Overall Assessment: ✅ Approve with minor suggestions

The changes are well-implemented and follow established patterns. The auto-save UX improvement is valuable. Main concerns:

1. Error handling for auto-save calls should be added before production
2. Test coverage should be added in a follow-up PR

The UI changes (button styles, ConfirmDialog) are straightforward and low-risk.

Recommendation: Approve for merge after addressing error handling, or merge with a follow-up ticket for error handling improvements.

---

Reviewed by: Claude Code (automated review)
Review focus: Code quality, security, performance, test coverage per CLAUDE.md guidelines