The backend has full CRUD API for rules (GET/POST/PUT/DELETE /api/rules), but the frontend only shows static toggles. Users cannot create custom rules like “IF sender is boss@company.com THEN send Telegram AND mark important.” This is a core differentiator for InboxOS.
Acceptance Criteria
• Create frontend/src/components/RulesManager.tsx — main rules page
• Create frontend/src/components/RuleBuilder.tsx
— visual rule builder with:
– Condition builder (field dropdown, operator dropdown, value input)
– Action builder (action type dropdown, config fields per action)
– Priority slider (1-100)
– Active toggle
• Create frontend/src/components/RuleCard.tsx — display rule with edit/delete
• Integrate with existing /api/rules endpoints
• Real-time validation with Zod schemas
• Show rule preview: “This rule will match emails where [conditions] and then [actions]”
• Drag-and-drop priority reordering
• Add “Rules” to SidebarNav
Design Constraints
• Dark glassmorphism theme (bg-base: #080b14, accent: #6366f1)
• Responsive: condition builder stacks vertically on mobile
• Loading skeletons while fetching
• Delete requires confirmation modal
Why This Matters
This is the #1 missing piece that prevents InboxOS from being an “operating system” vs just a smart inbox. Users need to define their own routing logic.
The backend has full CRUD API for rules (GET/POST/PUT/DELETE /api/rules), but the frontend only shows static toggles. Users cannot create custom rules like “IF sender is boss@company.com THEN send Telegram AND mark important.” This is a core differentiator for InboxOS.
Acceptance Criteria
• Create frontend/src/components/RulesManager.tsx — main rules page
• Create frontend/src/components/RuleBuilder.tsx
— visual rule builder with:
– Condition builder (field dropdown, operator dropdown, value input)
– Action builder (action type dropdown, config fields per action)
– Priority slider (1-100)
– Active toggle
• Create frontend/src/components/RuleCard.tsx — display rule with edit/delete
• Integrate with existing /api/rules endpoints
• Real-time validation with Zod schemas
• Show rule preview: “This rule will match emails where [conditions] and then [actions]”
• Drag-and-drop priority reordering
• Add “Rules” to SidebarNav
Design Constraints
• Dark glassmorphism theme (bg-base: #080b14, accent: #6366f1)
• Responsive: condition builder stacks vertically on mobile
• Loading skeletons while fetching
• Delete requires confirmation modal
Why This Matters
This is the #1 missing piece that prevents InboxOS from being an “operating system” vs just a smart inbox. Users need to define their own routing logic.