feat: Add Instagram as a lead capture option

[Rolfboy]

• Add Instagram to VALID_LEAD_TYPES in backend API
• Update /api/stats endpoint to track Instagram leads
• Add Instagram button (📸) to lead capture flow in UI
• Add Instagram option to lead type dropdown in edit form
• Update lead icon display logic and detail views
• Add Instagram to stats dashboard display
• Update database schema documentation
• Add migration script for database constraint

Closes #5

🤖 Generated with Claude Code

[claude]

Pull Request Review: Add Instagram as Lead Capture Option

Thank you for this PR! Overall, this is a well-implemented feature that systematically adds Instagram support across the stack. Here's my detailed review:

✅ Strengths

1. Complete Implementation: The change touches all necessary layers:

   • Backend validation (api/main.py:28)
   • Database schema (PRD.md, migration script)
   • API endpoint (api/main.py:390-393, 414-418)
   • UI flow (web/src/App.jsx:2021-2024)
   • Display logic (multiple locations in App.jsx)
   • Edit functionality (web/src/App.jsx:2348)

2. Consistent Patterns: The implementation follows existing patterns for LINE and Email throughout the codebase

   • Uses 📸 emoji consistently with other lead types
   • Maintains same ternary operator style for icon/label display
   • Follows validation constant pattern in backend

3. Good Migration Script:

   • Uses DROP CONSTRAINT IF EXISTS to handle idempotency
   • Includes descriptive comments
   • Properly handles NULL values in the constraint

4. Documentation Updated: PRD.md schema documentation updated to match implementation

🔍 Issues & Recommendations

1. Data Consistency Risk (Medium Priority)

Location: migrations/006_add_instagram_lead_type.sql:8-9

Issue: The migration doesn't handle existing data that might have invalid lead_type values before applying the constraint.

Recommendation: Add a data cleanup step before applying the constraint:

-- Update any invalid lead_type values to NULL
UPDATE interactions 
SET lead_type = NULL 
WHERE lead_type NOT IN ('line', 'email', 'instagram', 'none') 
  AND lead_type IS NOT NULL;

-- Add the new constraint with instagram included
ALTER TABLE interactions ADD CONSTRAINT interactions_lead_type_check
    CHECK (lead_type IN ('line', 'email', 'instagram', 'none') OR lead_type IS NULL);

2. Missing Rollback Script (Low Priority)

Location: migrations/

Issue: Other migrations (e.g., 005_realtime_notifications) have rollback scripts, but this one doesn't.

Recommendation: Add 006_add_instagram_lead_type_rollback.sql:

-- Rollback: Remove Instagram from lead_type options
ALTER TABLE interactions DROP CONSTRAINT IF EXISTS interactions_lead_type_check;
ALTER TABLE interactions ADD CONSTRAINT interactions_lead_type_check
    CHECK (lead_type IN ('line', 'email', 'none') OR lead_type IS NULL);

3. No Test Coverage (Medium Priority)

Issue: No tests found in the repository to validate this change.

Recommendation: Consider adding tests for:

• Backend validation accepts 'instagram' as valid lead_type
• Stats endpoint correctly counts Instagram leads
• API rejects invalid lead_type values

4. Minor Code Quality: Long Ternary Chains (Low Priority)

Locations:

• web/src/App.jsx:1159
• web/src/App.jsx:1240

Issue: Nested ternary operators become hard to read:

const leadIcon = item.lead_type === 'line' ? '💚' : item.lead_type === 'email' ? '📧' : item.lead_type === 'instagram' ? '📸' : ''

Recommendation: Consider using an object lookup pattern for better maintainability:

const LEAD_ICONS = {
  line: '💚',
  email: '📧',
  instagram: '📸'
}
const leadIcon = LEAD_ICONS[item.lead_type] || ''

const LEAD_LABELS = {
  line: '💚 LINE',
  email: '📧 Email',
  instagram: '📸 Instagram'
}
const leadLabel = LEAD_LABELS[i.lead_type] || 'None'

This would also make it easier to add future lead types.

🔒 Security

• ✅ Backend validation properly restricts lead_type to allowed values
• ✅ No SQL injection risks (using parameterized queries)
• ✅ No XSS risks (React handles escaping)

⚡ Performance

• ✅ New query for Instagram leads follows same pattern as existing LINE/Email queries
• ✅ No N+1 query issues
• ℹ️ Consider adding a database index on lead_type if filtering/grouping by this field becomes common (not urgent for current usage)

📋 Summary

Verdict: ✅ Approve with minor suggestions

This PR correctly implements the requested feature. The issues identified are minor improvements rather than blockers:

• The migration script should handle edge cases with existing data
• Code readability could be improved with object lookups instead of ternary chains
• Test coverage would help prevent regressions

The implementation is functional and follows the existing codebase patterns well. Great work maintaining consistency across all the display locations!

Closes: #5 ✅

---

Review generated by Claude Code