Skip to content

Comments

feat: improve Reply Zero discoverability and add disable toggle#1154

Closed
rsnodgrass wants to merge 7 commits intoelie222:mainfrom
rsnodgrass:feature/reply-zero-ux-improvements
Closed

feat: improve Reply Zero discoverability and add disable toggle#1154
rsnodgrass wants to merge 7 commits intoelie222:mainfrom
rsnodgrass:feature/reply-zero-ux-improvements

Conversation

@rsnodgrass
Copy link
Contributor

@rsnodgrass rsnodgrass commented Dec 31, 2025

Problem

Reply Zero is a core feature but was completely hidden from users:

  1. Not in sidebar navigation - Only appeared in: Assistant, Bulk Unsubscribe, Deep Clean, Analytics, Calendars
  2. Not in setup checklist - Current steps only showed: AI Assistant, Bulk Unsubscribe, Calendar
  3. No status indication - Users couldn't tell if Reply Zero was enabled for their account
  4. No way to disable - Users had to manually disable individual rules in settings
  5. Per-account confusion - Each email account needs Reply Zero enabled separately, but this wasn't clear

Solution

This PR makes Reply Zero a first-class citizen in the UI:

1. Added to Sidebar Navigation

Reply Zero now appears prominently in the main sidebar navigation, right after "Assistant":

  • Assistant
  • Reply Zero (new)
  • Bulk Unsubscribe
  • Deep Clean
  • Analytics
  • Calendars

2. Added to Setup Progress Checklist

Reply Zero is now part of the "Complete your setup" widget:

  • Set up your Personal Assistant
  • Enable Reply Zero (new)
  • Unsubscribe from a newsletter
  • Connect your calendar

3. Enable/Disable Toggle in Settings

Added a new "Reply Zero" section under Settings > Email Account:

  • Shows clear "Enabled" or "Disabled" badge
  • One-click toggle to enable or disable Reply Zero for the account
  • No need to manually manage individual rules

Why This Matters

As a user, I was confused about whether Reply Zero was enabled for my account at all. I had no idea how to find it (it was buried in the user dropdown menu at the bottom left), no idea if it was active, and no way to disable it if I wanted to. This creates a poor onboarding experience and makes Reply Zero feel like a hidden feature rather than a core capability.

Test Plan

  • New accounts show Reply Zero as an incomplete step in setup checklist
  • Enabling Reply Zero updates the setup progress to show checkmark
  • Reply Zero appears in sidebar navigation for Google accounts
  • Settings > Email Account shows Reply Zero status badge
  • Enable/Disable toggle works correctly
  • Non-Google providers don't see Reply Zero options (feature is Gmail-only)

Summary by CodeRabbit

  • New Features
    • Reply Zero management for Google accounts: enable/disable toggle in Settings with status badge and loading/error handling.
    • Setup checklist and progress now include a Reply Zero step with completion tracking.
    • Warning banner shown in the assistant UI when Reply Zero is disabled, linking to enable it.
    • Immediate user feedback via toast notifications for enable/disable actions.

✏️ Tip: You can customize this high-level summary in your review settings.


Note

Improves Reply Zero visibility and management (Gmail-only).

  • Adds ReplyZeroSection in Settings with enable/disable toggle that updates all CONVERSATION_STATUS_TYPES; shows status badge and toast feedback
  • Shows Reply Zero section only for Google providers in settings/page.tsx
  • Updates setup checklist to include "Enable Reply Zero" step and threads isReplyZeroConfigured through SetupContent
  • Extends GET /api/user/setup-progress to compute steps.replyZero by checking SystemType.TO_REPLY rule enabled
  • In Assistant Rules.tsx, displays an amber warning banner when Reply Zero is disabled with a link to /<emailAccountId>/reply-zero

Written by Cursor Bugbot for commit 33f345b. Configure here.

Reply Zero is a core feature that was completely hidden from users:

- Add Reply Zero to sidebar navigation (appears after Assistant)
- Add Reply Zero step to setup progress checklist
- Add ability to enable/disable Reply Zero in Settings > Email Account
- Show clear status badge indicating if Reply Zero is enabled/disabled

This makes it much easier for users to discover and manage Reply Zero.
Previously, users had to find it buried in the user dropdown menu and
had no way to tell if it was enabled or disable it for their account.
@vercel
Copy link

vercel bot commented Dec 31, 2025

@rsnodgrass is attempting to deploy a commit to the Inbox Zero OSS Program Team on Vercel.

A member of the Team first needs to authorize it.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 31, 2025

Warning

Rate limit exceeded

@elie222 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 6 minutes and 47 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 2820586 and 4e1b0c4.

📒 Files selected for processing (1)
  • apps/web/app/api/user/setup-progress/route.ts
📝 Walkthrough

Walkthrough

Adds Reply Zero feature wiring: UI toggle and warning in assistant rules, a settings section, a setup-step for Google providers, and setup-progress API support that computes Reply Zero configured status from conversation-status rules.

Changes

Cohort / File(s) Summary
Reply Zero Settings Component
apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
New client-side component showing Reply Zero status, badge, and toggle; toggles all CONVERSATION_STATUS_TYPES via toggleRuleAction, handles per-result errors, shows toasts, refreshes setup progress, and manages loading state.
Settings Page Integration
apps/web/app/(app)/[emailAccountId]/settings/page.tsx
Import and conditionally render ReplyZeroSection when isGoogleProvider(emailAccount.provider) is true.
Assistant Rules UI Check
apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
Adds isReplyZeroDisabled runtime check (filters rules by CONVERSATION_STATUS_TYPES, considers missing or all-disabled as disabled); renders warning banner with AlertTriangleIcon and link to enable Reply Zero for Google providers; updated imports.
Setup Flow Enhancement
apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
Adds isReplyZeroConfigured prop to Checklist and SetupPageContent; appends Reply Zero StepItem (gated to Google provider) with MessageCircleReplyIcon; passes and displays step state from fetched data.
Setup Progress API
apps/web/app/api/user/setup-progress/route.ts
Parallelizes fetching via Promise.all, counts enabled conversation-status rules (prisma.rule.count), computes isReplyZeroEnabled vs CONVERSATION_STATUS_TYPES, and exposes new replyZero step flag in API response.

Sequence Diagram(s)

sequenceDiagram
  participant User
  participant Browser
  participant SettingsUI as ReplyZeroSection
  participant API as /api/toggle-rule (server)
  participant DB as Prisma
  participant ProgressAPI as /api/user/setup-progress

  rect rgb(240,248,255)
    Note left of User: User clicks toggle
  end

  User ->> Browser: click enable/disable
  Browser ->> SettingsUI: invoke toggle handler
  SettingsUI ->> API: send toggle requests (parallel for CONVERSATION_STATUS_TYPES)
  API ->> DB: update/create rules per type (parallel)
  DB -->> API: results (success/failure per type)
  API -->> SettingsUI: aggregated results (ok / per-type errors)
  SettingsUI ->> Browser: show toast(s), update local state
  SettingsUI ->> ProgressAPI: refresh setup-progress
  ProgressAPI ->> DB: count enabled conversation-status rules
  DB -->> ProgressAPI: count
  ProgressAPI -->> SettingsUI: updated steps (replyZero true/false)
  SettingsUI ->> Browser: render updated badge/state
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Possibly related PRs

  • #1133 — Touches conversation-status rule handling and assistant rule UI logic; likely overlaps on CONVERSATION_STATUS_TYPES usage.
  • #334 — Implements/renames reply-tracker to Reply Zero and modifies related rules and setup flows; strong functional overlap.

Poem

🐰 I hopped through rules and toggles bright,

Enabled reply-zero by moonlit byte,
A banner warns where settings hide,
Gmail friends, now toggle with pride!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately summarizes the main changes: improving Reply Zero discoverability and adding a disable toggle, which aligns with the primary features added (setup checklist, settings section with toggle, Rules warning, and endpoint enhancement).
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@macroscopeapp
Copy link
Contributor

macroscopeapp bot commented Dec 31, 2025

Add Reply Zero section with enable/disable toggle in settings and include Reply Zero step in setup progress for Google accounts

Introduce a ReplyZeroSection UI with a toggle that batch-updates rules via toggleRuleAction, add conditional rendering in the Email Account settings for Google providers, and extend setup progress to include a replyZero step derived from a SystemType.TO_REPLY enabled rule in route.ts.

📍Where to Start

Start with getSetupProgress in route.ts, then review ReplyZeroSection in ReplyZeroSection.tsx and its integration in page.tsx.


Macroscope summarized 4e1b0c4.

Adds a warning banner on the Rules/Assistant page when Reply Zero rules
are disabled or not configured. This helps users understand why their
conversation tracking rules (To Reply, Awaiting Reply, etc.) aren't
working and provides a direct link to enable Reply Zero.
@elie222
Copy link
Owner

elie222 commented Dec 31, 2025

Hey, so the reason we decided to hide it was because most users were replying from their inbox anyway, and so we wanted to reduce the noise in the main sidebar. But we can consider putting it back

@rsnodgrass
Copy link
Contributor Author

Hey, so the reason we decided to hide it was because most users were replying from their inbox anyway, and so we wanted to reduce the noise in the main sidebar. But we can consider putting it back

Makes sense.

I does seem like encouraging people to continue using their existing email program as normal, except for fine tuning Inbox Zero over time. I'll back out the change that promotes it on the left nav, but keep the rest since I think guiding people into setting up replies is key. Currently it is unclear when Reply Zero is enabled AND no way to disable if it when needed (except going in and editing rules).

Per maintainer feedback: most users reply from their inbox anyway,
so keeping Reply Zero in the main sidebar adds noise. The feature
remains accessible from the bottom-left account dropdown.

All other PR improvements (settings toggle, setup progress step,
Rules page warning) are preserved.
@rsnodgrass rsnodgrass marked this pull request as ready for review December 31, 2025 22:36
Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 5 files

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx (1)

149-163: Use isConversationStatusType helper for consistency.

Line 155 manually checks CONVERSATION_STATUS_TYPES.includes(rule.systemType), but line 217 uses the imported isConversationStatusType() helper for the same purpose. Use the helper consistently throughout the file.

🔎 Proposed fix
   const conversationStatusRules = (data || []).filter(
     (rule) =>
-      rule.systemType && CONVERSATION_STATUS_TYPES.includes(rule.systemType),
+      rule.systemType && isConversationStatusType(rule.systemType),
   );
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 56454e2 and efa9784.

📒 Files selected for processing (5)
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
🧰 Additional context used
📓 Path-based instructions (24)
**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/data-fetching.mdc)

**/*.{ts,tsx}: For API GET requests to server, use the swr package
Use result?.serverError with toastError from @/components/Toast for error handling in async operations

**/*.{ts,tsx}: Use wrapper functions for Gmail message operations (get, list, batch, etc.) from @/utils/gmail/message.ts instead of direct API calls
Use wrapper functions for Gmail thread operations from @/utils/gmail/thread.ts instead of direct API calls
Use wrapper functions for Gmail label operations from @/utils/gmail/label.ts instead of direct API calls

**/*.{ts,tsx}: For early access feature flags, create hooks using the naming convention use[FeatureName]Enabled that return a boolean from useFeatureFlagEnabled("flag-key")
For A/B test variant flags, create hooks using the naming convention use[FeatureName]Variant that define variant types, use useFeatureFlagVariantKey() with type casting, and provide a default "control" fallback
Use kebab-case for PostHog feature flag keys (e.g., inbox-cleaner, pricing-options-2)
Always define types for A/B test variant flags (e.g., type PricingVariant = "control" | "variant-a" | "variant-b") and provide type safety through type casting

**/*.{ts,tsx}: Don't use primitive type aliases or misleading types
Don't use empty type parameters in type aliases and interfaces
Don't use this and super in static contexts
Don't use any or unknown as type constraints
Don't use the TypeScript directive @ts-ignore
Don't use TypeScript enums
Don't export imported variables
Don't add type annotations to variables, parameters, and class properties that are initialized with literal expressions
Don't use TypeScript namespaces
Don't use non-null assertions with the ! postfix operator
Don't use parameter properties in class constructors
Don't use user-defined types
Use as const instead of literal types and type annotations
Use either T[] or Array<T> consistently
Initialize each enum member value explicitly
Use export type for types
Use `impo...

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
apps/web/app/(app)/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/page-structure.mdc)

apps/web/app/(app)/**/*.{ts,tsx}: Components for the page are either put in page.tsx, or in the apps/web/app/(app)/PAGE_NAME folder
If we're in a deeply nested component we will use swr to fetch via API
If you need to use onClick in a component, that component is a client component and file must start with use client

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (.cursor/rules/prisma-enum-imports.mdc)

Always import Prisma enums from @/generated/prisma/enums instead of @/generated/prisma/client to avoid Next.js bundling errors in client components

Import Prisma using the project's centralized utility: import prisma from '@/utils/prisma'

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
apps/web/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)

Import specific lodash functions rather than entire lodash library to minimize bundle size (e.g., import groupBy from 'lodash/groupBy')

apps/web/**/*.{ts,tsx}: Use TypeScript with strict null checks
Do not export types/interfaces that are only used within the same file. Export later if needed

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
**/*.{tsx,ts}

📄 CodeRabbit inference engine (.cursor/rules/ui-components.mdc)

**/*.{tsx,ts}: Use Shadcn UI and Tailwind for components and styling
Use next/image package for images
For API GET requests to server, use the swr package with hooks like useSWR to fetch data
For text inputs, use the Input component with registerProps for form integration and error handling

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
**/*.{tsx,ts,css}

📄 CodeRabbit inference engine (.cursor/rules/ui-components.mdc)

Implement responsive design with Tailwind CSS using a mobile-first approach

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
**/*.tsx

📄 CodeRabbit inference engine (.cursor/rules/ui-components.mdc)

**/*.tsx: Use the LoadingContent component to handle loading states instead of manual loading state management
For text areas, use the Input component with type='text', autosizeTextarea prop set to true, and registerProps for form integration

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
**/*.{js,jsx,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)

**/*.{js,jsx,ts,tsx}: Don't use accessKey attribute on any HTML element
Don't set aria-hidden="true" on focusable elements
Don't add ARIA roles, states, and properties to elements that don't support them
Don't use distracting elements like <marquee> or <blink>
Only use the scope prop on <th> elements
Don't assign non-interactive ARIA roles to interactive HTML elements
Make sure label elements have text content and are associated with an input
Don't assign interactive ARIA roles to non-interactive HTML elements
Don't assign tabIndex to non-interactive HTML elements
Don't use positive integers for tabIndex property
Don't include "image", "picture", or "photo" in img alt prop
Don't use explicit role property that's the same as the implicit/default role
Make static elements with click handlers use a valid role attribute
Always include a title element for SVG elements
Give all elements requiring alt text meaningful information for screen readers
Make sure anchors have content that's accessible to screen readers
Assign tabIndex to non-interactive HTML elements with aria-activedescendant
Include all required ARIA attributes for elements with ARIA roles
Make sure ARIA properties are valid for the element's supported roles
Always include a type attribute for button elements
Make elements with interactive roles and handlers focusable
Give heading elements content that's accessible to screen readers (not hidden with aria-hidden)
Always include a lang attribute on the html element
Always include a title attribute for iframe elements
Accompany onClick with at least one of: onKeyUp, onKeyDown, or onKeyPress
Accompany onMouseOver/onMouseOut with onFocus/onBlur
Include caption tracks for audio and video elements
Use semantic elements instead of role attributes in JSX
Make sure all anchors are valid and navigable
Ensure all ARIA properties (aria-*) are valid
Use valid, non-abstract ARIA roles for elements with ARIA roles
Use valid AR...

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
**/*.{jsx,tsx}

📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)

**/*.{jsx,tsx}: Don't use unnecessary fragments
Don't pass children as props
Don't use the return value of React.render
Make sure all dependencies are correctly specified in React hooks
Make sure all React hooks are called from the top level of component functions
Don't forget key props in iterators and collection literals
Don't define React components inside other components
Don't use event handlers on non-interactive elements
Don't assign to React component props
Don't use both children and dangerouslySetInnerHTML props on the same element
Don't use dangerous JSX props
Don't use Array index in keys
Don't insert comments as text nodes
Don't assign JSX properties multiple times
Don't add extra closing tags for components without children
Use <>...</> instead of <Fragment>...</Fragment>
Watch out for possible "wrong" semicolons inside JSX elements
Make sure void (self-closing) elements don't have children
Don't use target="_blank" without rel="noopener"
Don't use <img> elements in Next.js projects
Don't use <head> elements in Next.js projects

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
!(pages/_document).{jsx,tsx}

📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)

Don't use the next/head module in pages/_document.js on Next.js projects

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
**/*.{js,ts,jsx,tsx}

📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)

**/*.{js,ts,jsx,tsx}: Use lodash utilities for common operations (arrays, objects, strings)
Import specific lodash functions to minimize bundle size (e.g., import groupBy from 'lodash/groupBy')

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
apps/web/**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

apps/web/**/*.{ts,tsx,js,jsx}: Use @/ path aliases for imports from project root
Prefer self-documenting code over comments; use descriptive variable and function names instead of explaining intent with comments
Add helper functions to the bottom of files, not the top
All imports go at the top of files, no mid-file dynamic imports

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
apps/web/app/**/*.{ts,tsx}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

Follow NextJS app router structure with (app) directory

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
apps/web/**/*.{tsx,jsx}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

apps/web/**/*.{tsx,jsx}: Follow tailwindcss patterns with prettier-plugin-tailwindcss for class sorting
Prefer functional components with hooks in React
Use shadcn/ui components when available
Ensure responsive design with mobile-first approach in components
Follow consistent naming conventions using PascalCase for components
Use LoadingContent component for async data with loading and error states
Use React Hook Form with Zod validation for form handling
Use result?.serverError with toastError and toastSuccess for error handling in forms

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
apps/web/**/*.{ts,tsx,js,jsx,json,css}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

Format code with Prettier

Files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
apps/web/app/api/**/route.ts

📄 CodeRabbit inference engine (.cursor/rules/fullstack-workflow.mdc)

apps/web/app/api/**/route.ts: Create GET API routes using withAuth or withEmailAccount middleware in apps/web/app/api/*/route.ts, export response types as GetExampleResponse type alias for client-side type safety
Always export response types from GET routes as Get[Feature]Response using type inference from the data fetching function for type-safe client consumption
Do NOT use POST API routes for mutations - always use server actions with next-safe-action instead

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/app/**/route.ts

📄 CodeRabbit inference engine (.cursor/rules/get-api-route.mdc)

**/app/**/route.ts: Always wrap GET API route handlers with withAuth or withEmailAccount middleware for consistent error handling and authentication in Next.js App Router
Infer and export response type for GET API routes using Awaited<ReturnType<typeof functionName>> pattern in Next.js
Use Prisma for database queries in GET API routes
Return responses using NextResponse.json() in GET API routes
Do not use try/catch blocks in GET API route handlers when using withAuth or withEmailAccount middleware, as the middleware handles error handling

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/app/**/[!.]*/route.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)

Use kebab-case for route directories in Next.js App Router (e.g., api/hello-world/route)

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/app/api/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/security-audit.mdc)

apps/web/app/api/**/*.{ts,tsx}: API routes must use withAuth, withEmailAccount, or withError middleware for authentication
All database queries must include user scoping with emailAccountId or userId filtering in WHERE clauses
Request parameters must be validated before use; avoid direct parameter usage without type checking
Use generic error messages instead of revealing internal details; throw SafeError instead of exposing user IDs, resource IDs, or system information
API routes should only return necessary fields using select in database queries to prevent unintended information disclosure
Cron endpoints must use hasCronSecret or hasPostCronSecret to validate cron requests and prevent unauthorized access
Request bodies should use Zod schemas for validation to ensure type safety and prevent injection attacks

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/app/api/**/*.ts

📄 CodeRabbit inference engine (.cursor/rules/security.mdc)

**/app/api/**/*.ts: ALL API routes that handle user data MUST use appropriate middleware: use withEmailAccount for email-scoped operations, use withAuth for user-scoped operations, or use withError with proper validation for public/custom auth endpoints
Use withEmailAccount middleware for operations scoped to a specific email account, including reading/writing emails, rules, schedules, or any operation using emailAccountId
Use withAuth middleware for user-level operations such as user settings, API keys, and referrals that use only userId
Use withError middleware only for public endpoints, custom authentication logic, or cron endpoints. For cron endpoints, MUST use hasCronSecret() or hasPostCronSecret() validation
Cron endpoints without proper authentication can be triggered by anyone. CRITICAL: All cron endpoints MUST validate cron secret using hasCronSecret(request) or hasPostCronSecret(request) and capture unauthorized attempts with captureException()
Always validate request bodies using Zod schemas to ensure type safety and prevent invalid data from reaching database operations
Maintain consistent error response format across all API routes to avoid information disclosure while providing meaningful error feedback

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/*.ts

📄 CodeRabbit inference engine (.cursor/rules/security.mdc)

**/*.ts: ALL database queries MUST be scoped to the authenticated user/account by including user/account filtering in WHERE clauses to prevent unauthorized data access
Always validate that resources belong to the authenticated user before performing operations, using ownership checks in WHERE clauses or relationships
Always validate all input parameters for type, format, and length before using them in database queries
Use SafeError for error responses to prevent information disclosure. Generic error messages should not reveal internal IDs, logic, or resource ownership details
Only return necessary fields in API responses using Prisma's select option. Never expose sensitive data such as password hashes, private keys, or system flags
Prevent Insecure Direct Object References (IDOR) by validating resource ownership before operations. All findUnique/findFirst calls MUST include ownership filters
Prevent mass assignment vulnerabilities by explicitly whitelisting allowed fields in update operations instead of accepting all user-provided data
Prevent privilege escalation by never allowing users to modify system fields, ownership fields, or admin-only attributes through user input
All findMany queries MUST be scoped to the user's data by including appropriate WHERE filters to prevent returning data from other users
Use Prisma relationships for access control by leveraging nested where clauses (e.g., emailAccount: { id: emailAccountId }) to validate ownership

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/{app,pages}/**/{route,+page}.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/logging.mdc)

**/{app,pages}/**/{route,+page}.{ts,tsx}: Use middleware wrappers (withError, withAuth, withEmailAccount, withEmailProvider) that automatically create loggers with request context in API routes
Enrich logger context within route handlers using logger.with() to add request-specific fields like messageId

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/**/*.{example,ts,json}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

Add environment variables to .env.example, env.ts, and turbo.json

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/app/api/**/*.ts

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

apps/web/app/api/**/*.ts: Create GET API routes wrapped with withAuth or withEmailAccount middleware for fetching data
Export response types from GET API routes using export type GetXResponse = Awaited<ReturnType<typeof getData>>

Files:

  • apps/web/app/api/user/setup-progress/route.ts
🧠 Learnings (26)
📚 Learning: 2025-12-21T12:21:37.794Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-12-21T12:21:37.794Z
Learning: Applies to apps/web/**/*.{tsx,jsx} : Use React Hook Form with Zod validation for form handling

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx
📚 Learning: 2025-07-08T13:14:07.449Z
Learnt from: elie222
Repo: elie222/inbox-zero PR: 537
File: apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx:30-34
Timestamp: 2025-07-08T13:14:07.449Z
Learning: The clean onboarding page in apps/web/app/(app)/[emailAccountId]/clean/onboarding/page.tsx is intentionally Gmail-specific and should show an error for non-Google email accounts rather than attempting to support multiple providers.

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to apps/web/utils/gmail/**/*.{ts,tsx} : Keep Gmail provider-specific implementation details isolated within the apps/web/utils/gmail/ directory

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to apps/web/utils/gmail/**/*.{ts,tsx} : Always use wrapper functions from @/utils/gmail/ for Gmail API operations instead of direct provider API calls

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Design Gmail wrapper functions to be provider-agnostic to support future email providers like Outlook and ProtonMail

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/settings/page.tsx
📚 Learning: 2025-11-25T14:39:23.326Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-11-25T14:39:23.326Z
Learning: Applies to app/api/**/*.ts : Use `SafeError` for error responses to prevent information disclosure - provide generic messages (e.g., 'Rule not found' not 'Rule {id} does not exist for user {userId}') without revealing internal IDs or ownership details

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
📚 Learning: 2025-11-25T14:40:00.833Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-11-25T14:40:00.833Z
Learning: Applies to **/*.test.{ts,tsx} : Use test helpers `getEmail`, `getEmailAccount`, and `getRule` from `@/__tests__/helpers` for mocking emails, accounts, and rules

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to **/*.{ts,tsx} : Use wrapper functions for Gmail thread operations from @/utils/gmail/thread.ts instead of direct API calls

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
📚 Learning: 2025-11-25T14:37:09.306Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/fullstack-workflow.mdc:0-0
Timestamp: 2025-11-25T14:37:09.306Z
Learning: Applies to apps/web/components/**/*.tsx : Use `LoadingContent` component to consistently handle loading and error states, passing `loading`, `error`, and `children` props

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
📚 Learning: 2025-12-21T12:21:37.794Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-12-21T12:21:37.794Z
Learning: Applies to apps/web/**/*.{tsx,jsx} : Use LoadingContent component for async data with loading and error states

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
📚 Learning: 2025-11-25T14:40:13.649Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ui-components.mdc:0-0
Timestamp: 2025-11-25T14:40:13.649Z
Learning: Applies to **/*.{tsx,ts,jsx,js} : Use the `LoadingContent` component to handle loading states

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
📚 Learning: 2025-11-25T14:40:15.063Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/ui-components.mdc:0-0
Timestamp: 2025-11-25T14:40:15.063Z
Learning: Applies to **/*.tsx : Use the `LoadingContent` component to handle loading states instead of manual loading state management

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
📚 Learning: 2025-11-25T14:37:35.343Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/hooks.mdc:0-0
Timestamp: 2025-11-25T14:37:35.343Z
Learning: Applies to apps/web/hooks/use*.ts : Create dedicated hooks for specific data types (e.g., `useAccounts`, `useLabels`) to wrap `useSWR` for individual API endpoints

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
📚 Learning: 2025-11-25T14:37:30.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/hooks.mdc:0-0
Timestamp: 2025-11-25T14:37:30.660Z
Learning: Applies to apps/web/hooks/use*.ts : Create dedicated hooks for specific data types (e.g., `useAccounts`, `useLabels`) that wrap `useSWR`, handle the API endpoint URL, and return data, loading state, error state, and the `mutate` function

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
📚 Learning: 2025-11-25T14:37:22.660Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/gmail-api.mdc:0-0
Timestamp: 2025-11-25T14:37:22.660Z
Learning: Applies to **/*.{ts,tsx} : Use wrapper functions for Gmail label operations from @/utils/gmail/label.ts instead of direct API calls

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
📚 Learning: 2025-11-25T14:36:36.276Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/data-fetching.mdc:0-0
Timestamp: 2025-11-25T14:36:36.276Z
Learning: Applies to **/*.{ts,tsx} : Import error and success toast utilities from '@/components/Toast' for displaying notifications

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx
📚 Learning: 2025-12-21T12:21:37.794Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-12-21T12:21:37.794Z
Learning: Applies to apps/web/**/*.{tsx,jsx} : Use shadcn/ui components when available

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
📚 Learning: 2025-11-25T14:39:23.326Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-11-25T14:39:23.326Z
Learning: Applies to app/api/**/*.ts : Use `withEmailAccount` middleware for operations scoped to a specific email account (reading/writing emails, rules, schedules, etc.) - provides `emailAccountId`, `userId`, and `email` in `request.auth`

Applied to files:

  • apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx
  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-11-25T14:39:27.909Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-11-25T14:39:27.909Z
Learning: Applies to **/app/api/**/*.ts : Use `withEmailAccount` middleware for operations scoped to a specific email account, including reading/writing emails, rules, schedules, or any operation using `emailAccountId`

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-11-25T14:38:07.606Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-11-25T14:38:07.606Z
Learning: Applies to apps/web/utils/ai/**/*.ts : LLM feature functions must import from `zod` for schema validation, use `createScopedLogger` from `@/utils/logger`, `chatCompletionObject` and `createGenerateObject` from `@/utils/llms`, and import `EmailAccountWithAI` type from `@/utils/llms/types`

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-11-25T14:38:07.606Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-11-25T14:38:07.606Z
Learning: Applies to apps/web/utils/ai/**/*.ts : LLM feature functions must follow a standard structure: accept options with `inputData` and `emailAccount` parameters, implement input validation with early returns, define separate system and user prompts, create a Zod schema for response validation, and use `createGenerateObject` to execute the LLM call

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-11-25T14:37:11.434Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-11-25T14:37:11.434Z
Learning: Applies to **/app/**/route.ts : Infer and export the response type for GET API routes using `export type GetResponse = Awaited<ReturnType<typeof getData>>` pattern in Next.js

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-11-25T14:37:22.822Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-11-25T14:37:22.822Z
Learning: Applies to **/app/**/route.ts : Infer and export response type for GET API routes using `Awaited<ReturnType<typeof functionName>>` pattern in Next.js

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-12-21T12:21:37.794Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-12-21T12:21:37.794Z
Learning: Applies to apps/web/hooks/**/*.{ts,tsx} : Use SWR for client-side data fetching with type-safe response types from GET API routes

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-12-21T12:21:37.794Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: apps/web/CLAUDE.md:0-0
Timestamp: 2025-12-21T12:21:37.794Z
Learning: Applies to apps/web/app/api/**/*.ts : Export response types from GET API routes using `export type GetXResponse = Awaited<ReturnType<typeof getData>>`

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-11-25T14:38:37.508Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/prisma-enum-imports.mdc:0-0
Timestamp: 2025-11-25T14:38:37.508Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Always import Prisma enums from `@/generated/prisma/enums` instead of `@/generated/prisma/client` to avoid Next.js bundling errors in client components

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
🧬 Code graph analysis (3)
apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx (4)
apps/web/providers/EmailAccountProvider.tsx (1)
  • useAccount (79-89)
apps/web/utils/reply-tracker/conversation-status-config.ts (1)
  • CONVERSATION_STATUS_TYPES (3-8)
apps/web/utils/actions/rule.ts (1)
  • toggleRuleAction (438-455)
apps/web/components/LoadingContent.tsx (1)
  • LoadingContent (13-31)
apps/web/app/(app)/[emailAccountId]/settings/page.tsx (1)
apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx (1)
  • ReplyZeroSection (14-86)
apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx (2)
apps/web/utils/reply-tracker/conversation-status-config.ts (1)
  • CONVERSATION_STATUS_TYPES (3-8)
apps/web/components/new-landing/icons/Link.tsx (1)
  • Link (1-18)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: cubic · AI code reviewer
🔇 Additional comments (6)
apps/web/app/(app)/[emailAccountId]/assistant/Rules.tsx (3)

149-163: Logic for detecting Reply Zero disabled state looks correct.

The implementation properly:

  • Gates the check to Google providers only
  • Filters for conversation status type rules from actual data (not placeholders)
  • Treats Reply Zero as disabled when no rules exist or all are disabled
  • Uses useMemo appropriately for performance

167-187: Warning banner UI is well-implemented.

The banner provides clear, actionable messaging with:

  • Appropriate visual hierarchy and spacing
  • Dark mode support
  • Descriptive text explaining the issue and solution
  • Direct link to enable Reply Zero

167-187: Link is valid and requires no changes.

The /reply-zero route exists at apps/web/app/(app)/[emailAccountId]/reply-zero/page.tsx and is fully functional. The link prefixPath(emailAccountId, "/reply-zero") correctly targets a working page with conversation tracking tabs (To Reply, Waiting, Done). While Reply Zero may have been removed from the main sidebar, the page remains accessible and the link is appropriate. Users can also enable/disable Reply Zero through the Settings page via ReplyZeroSection.tsx.

apps/web/app/(app)/[emailAccountId]/settings/page.tsx (1)

8-8: LGTM! Proper provider-gated feature rendering.

The conditional rendering of ReplyZeroSection for Google providers is correctly implemented and aligns with the PR's scope constraint that Reply Zero is Gmail-only.

Also applies to: 11-11, 63-64

apps/web/app/(app)/[emailAccountId]/settings/ReplyZeroSection.tsx (1)

35-46: Well-structured error handling and loading states.

The error handling correctly uses result?.serverError per coding guidelines, and the loading states (isToggling, isLoadingStatus) provide good user feedback during async operations. The badge and button states clearly communicate the current status.

Also applies to: 61-83

apps/web/app/(app)/[emailAccountId]/setup/SetupContent.tsx (1)

13-13: LGTM! Well-integrated Reply Zero setup step.

The new Reply Zero setup step is properly:

  • Typed through the component hierarchy
  • Conditionally rendered for Google providers only
  • Styled consistently with other steps
  • Connected to the data flow from useSetupProgress

The integration is clean and follows established patterns in the codebase.

Also applies to: 221-221, 231-231, 276-287, 341-341, 358-358, 368-368, 397-397

ReplyZeroSection toggles all 4 CONVERSATION_STATUS_TYPES (TO_REPLY,
FYI, AWAITING_REPLY, ACTIONED) in parallel. The setup-progress check
was only verifying TO_REPLY existed and was enabled.

Now counts all enabled conversation status rules and compares against
CONVERSATION_STATUS_TYPES.length to ensure Reply Zero is fully enabled.
This prevents false positives in partial enable states.
Reverts 2820586 which required all 4 conversation status rules.

TO_REPLY is the canonical indicator for Reply Zero status - if it's
enabled, Reply Zero is functionally active. ReplyZeroSection toggles
all 4 rules together, so partial states are rare edge cases.

Added documentation comment explaining this design decision.
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between efa9784 and 2820586.

📒 Files selected for processing (1)
  • apps/web/app/api/user/setup-progress/route.ts
🧰 Additional context used
📓 Path-based instructions (20)
**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/data-fetching.mdc)

**/*.{ts,tsx}: For API GET requests to server, use the swr package
Use result?.serverError with toastError from @/components/Toast for error handling in async operations

**/*.{ts,tsx}: Use wrapper functions for Gmail message operations (get, list, batch, etc.) from @/utils/gmail/message.ts instead of direct API calls
Use wrapper functions for Gmail thread operations from @/utils/gmail/thread.ts instead of direct API calls
Use wrapper functions for Gmail label operations from @/utils/gmail/label.ts instead of direct API calls

**/*.{ts,tsx}: For early access feature flags, create hooks using the naming convention use[FeatureName]Enabled that return a boolean from useFeatureFlagEnabled("flag-key")
For A/B test variant flags, create hooks using the naming convention use[FeatureName]Variant that define variant types, use useFeatureFlagVariantKey() with type casting, and provide a default "control" fallback
Use kebab-case for PostHog feature flag keys (e.g., inbox-cleaner, pricing-options-2)
Always define types for A/B test variant flags (e.g., type PricingVariant = "control" | "variant-a" | "variant-b") and provide type safety through type casting

**/*.{ts,tsx}: Don't use primitive type aliases or misleading types
Don't use empty type parameters in type aliases and interfaces
Don't use this and super in static contexts
Don't use any or unknown as type constraints
Don't use the TypeScript directive @ts-ignore
Don't use TypeScript enums
Don't export imported variables
Don't add type annotations to variables, parameters, and class properties that are initialized with literal expressions
Don't use TypeScript namespaces
Don't use non-null assertions with the ! postfix operator
Don't use parameter properties in class constructors
Don't use user-defined types
Use as const instead of literal types and type annotations
Use either T[] or Array<T> consistently
Initialize each enum member value explicitly
Use export type for types
Use `impo...

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/app/api/**/route.ts

📄 CodeRabbit inference engine (.cursor/rules/fullstack-workflow.mdc)

apps/web/app/api/**/route.ts: Create GET API routes using withAuth or withEmailAccount middleware in apps/web/app/api/*/route.ts, export response types as GetExampleResponse type alias for client-side type safety
Always export response types from GET routes as Get[Feature]Response using type inference from the data fetching function for type-safe client consumption
Do NOT use POST API routes for mutations - always use server actions with next-safe-action instead

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/app/**/route.ts

📄 CodeRabbit inference engine (.cursor/rules/get-api-route.mdc)

**/app/**/route.ts: Always wrap GET API route handlers with withAuth or withEmailAccount middleware for consistent error handling and authentication in Next.js App Router
Infer and export response type for GET API routes using Awaited<ReturnType<typeof functionName>> pattern in Next.js
Use Prisma for database queries in GET API routes
Return responses using NextResponse.json() in GET API routes
Do not use try/catch blocks in GET API route handlers when using withAuth or withEmailAccount middleware, as the middleware handles error handling

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (.cursor/rules/prisma-enum-imports.mdc)

Always import Prisma enums from @/generated/prisma/enums instead of @/generated/prisma/client to avoid Next.js bundling errors in client components

Import Prisma using the project's centralized utility: import prisma from '@/utils/prisma'

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/app/**/[!.]*/route.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)

Use kebab-case for route directories in Next.js App Router (e.g., api/hello-world/route)

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/project-structure.mdc)

Import specific lodash functions rather than entire lodash library to minimize bundle size (e.g., import groupBy from 'lodash/groupBy')

apps/web/**/*.{ts,tsx}: Use TypeScript with strict null checks
Do not export types/interfaces that are only used within the same file. Export later if needed

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/app/api/**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/security-audit.mdc)

apps/web/app/api/**/*.{ts,tsx}: API routes must use withAuth, withEmailAccount, or withError middleware for authentication
All database queries must include user scoping with emailAccountId or userId filtering in WHERE clauses
Request parameters must be validated before use; avoid direct parameter usage without type checking
Use generic error messages instead of revealing internal details; throw SafeError instead of exposing user IDs, resource IDs, or system information
API routes should only return necessary fields using select in database queries to prevent unintended information disclosure
Cron endpoints must use hasCronSecret or hasPostCronSecret to validate cron requests and prevent unauthorized access
Request bodies should use Zod schemas for validation to ensure type safety and prevent injection attacks

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/app/api/**/*.ts

📄 CodeRabbit inference engine (.cursor/rules/security.mdc)

**/app/api/**/*.ts: ALL API routes that handle user data MUST use appropriate middleware: use withEmailAccount for email-scoped operations, use withAuth for user-scoped operations, or use withError with proper validation for public/custom auth endpoints
Use withEmailAccount middleware for operations scoped to a specific email account, including reading/writing emails, rules, schedules, or any operation using emailAccountId
Use withAuth middleware for user-level operations such as user settings, API keys, and referrals that use only userId
Use withError middleware only for public endpoints, custom authentication logic, or cron endpoints. For cron endpoints, MUST use hasCronSecret() or hasPostCronSecret() validation
Cron endpoints without proper authentication can be triggered by anyone. CRITICAL: All cron endpoints MUST validate cron secret using hasCronSecret(request) or hasPostCronSecret(request) and capture unauthorized attempts with captureException()
Always validate request bodies using Zod schemas to ensure type safety and prevent invalid data from reaching database operations
Maintain consistent error response format across all API routes to avoid information disclosure while providing meaningful error feedback

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/*.ts

📄 CodeRabbit inference engine (.cursor/rules/security.mdc)

**/*.ts: ALL database queries MUST be scoped to the authenticated user/account by including user/account filtering in WHERE clauses to prevent unauthorized data access
Always validate that resources belong to the authenticated user before performing operations, using ownership checks in WHERE clauses or relationships
Always validate all input parameters for type, format, and length before using them in database queries
Use SafeError for error responses to prevent information disclosure. Generic error messages should not reveal internal IDs, logic, or resource ownership details
Only return necessary fields in API responses using Prisma's select option. Never expose sensitive data such as password hashes, private keys, or system flags
Prevent Insecure Direct Object References (IDOR) by validating resource ownership before operations. All findUnique/findFirst calls MUST include ownership filters
Prevent mass assignment vulnerabilities by explicitly whitelisting allowed fields in update operations instead of accepting all user-provided data
Prevent privilege escalation by never allowing users to modify system fields, ownership fields, or admin-only attributes through user input
All findMany queries MUST be scoped to the user's data by including appropriate WHERE filters to prevent returning data from other users
Use Prisma relationships for access control by leveraging nested where clauses (e.g., emailAccount: { id: emailAccountId }) to validate ownership

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/*.{tsx,ts}

📄 CodeRabbit inference engine (.cursor/rules/ui-components.mdc)

**/*.{tsx,ts}: Use Shadcn UI and Tailwind for components and styling
Use next/image package for images
For API GET requests to server, use the swr package with hooks like useSWR to fetch data
For text inputs, use the Input component with registerProps for form integration and error handling

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/*.{tsx,ts,css}

📄 CodeRabbit inference engine (.cursor/rules/ui-components.mdc)

Implement responsive design with Tailwind CSS using a mobile-first approach

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/*.{js,jsx,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)

**/*.{js,jsx,ts,tsx}: Don't use accessKey attribute on any HTML element
Don't set aria-hidden="true" on focusable elements
Don't add ARIA roles, states, and properties to elements that don't support them
Don't use distracting elements like <marquee> or <blink>
Only use the scope prop on <th> elements
Don't assign non-interactive ARIA roles to interactive HTML elements
Make sure label elements have text content and are associated with an input
Don't assign interactive ARIA roles to non-interactive HTML elements
Don't assign tabIndex to non-interactive HTML elements
Don't use positive integers for tabIndex property
Don't include "image", "picture", or "photo" in img alt prop
Don't use explicit role property that's the same as the implicit/default role
Make static elements with click handlers use a valid role attribute
Always include a title element for SVG elements
Give all elements requiring alt text meaningful information for screen readers
Make sure anchors have content that's accessible to screen readers
Assign tabIndex to non-interactive HTML elements with aria-activedescendant
Include all required ARIA attributes for elements with ARIA roles
Make sure ARIA properties are valid for the element's supported roles
Always include a type attribute for button elements
Make elements with interactive roles and handlers focusable
Give heading elements content that's accessible to screen readers (not hidden with aria-hidden)
Always include a lang attribute on the html element
Always include a title attribute for iframe elements
Accompany onClick with at least one of: onKeyUp, onKeyDown, or onKeyPress
Accompany onMouseOver/onMouseOut with onFocus/onBlur
Include caption tracks for audio and video elements
Use semantic elements instead of role attributes in JSX
Make sure all anchors are valid and navigable
Ensure all ARIA properties (aria-*) are valid
Use valid, non-abstract ARIA roles for elements with ARIA roles
Use valid AR...

Files:

  • apps/web/app/api/user/setup-progress/route.ts
!(pages/_document).{jsx,tsx}

📄 CodeRabbit inference engine (.cursor/rules/ultracite.mdc)

Don't use the next/head module in pages/_document.js on Next.js projects

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/*.{js,ts,jsx,tsx}

📄 CodeRabbit inference engine (.cursor/rules/utilities.mdc)

**/*.{js,ts,jsx,tsx}: Use lodash utilities for common operations (arrays, objects, strings)
Import specific lodash functions to minimize bundle size (e.g., import groupBy from 'lodash/groupBy')

Files:

  • apps/web/app/api/user/setup-progress/route.ts
**/{app,pages}/**/{route,+page}.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/logging.mdc)

**/{app,pages}/**/{route,+page}.{ts,tsx}: Use middleware wrappers (withError, withAuth, withEmailAccount, withEmailProvider) that automatically create loggers with request context in API routes
Enrich logger context within route handlers using logger.with() to add request-specific fields like messageId

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/**/*.{ts,tsx,js,jsx}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

apps/web/**/*.{ts,tsx,js,jsx}: Use @/ path aliases for imports from project root
Prefer self-documenting code over comments; use descriptive variable and function names instead of explaining intent with comments
Add helper functions to the bottom of files, not the top
All imports go at the top of files, no mid-file dynamic imports

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/app/**/*.{ts,tsx}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

Follow NextJS app router structure with (app) directory

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/**/*.{ts,tsx,js,jsx,json,css}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

Format code with Prettier

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/**/*.{example,ts,json}

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

Add environment variables to .env.example, env.ts, and turbo.json

Files:

  • apps/web/app/api/user/setup-progress/route.ts
apps/web/app/api/**/*.ts

📄 CodeRabbit inference engine (apps/web/CLAUDE.md)

apps/web/app/api/**/*.ts: Create GET API routes wrapped with withAuth or withEmailAccount middleware for fetching data
Export response types from GET API routes using export type GetXResponse = Awaited<ReturnType<typeof getData>>

Files:

  • apps/web/app/api/user/setup-progress/route.ts
🧠 Learnings (5)
📚 Learning: 2025-11-25T14:39:23.326Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-11-25T14:39:23.326Z
Learning: Applies to app/api/**/*.ts : Use `withEmailAccount` middleware for operations scoped to a specific email account (reading/writing emails, rules, schedules, etc.) - provides `emailAccountId`, `userId`, and `email` in `request.auth`

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-11-25T14:39:27.909Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/security.mdc:0-0
Timestamp: 2025-11-25T14:39:27.909Z
Learning: Applies to **/app/api/**/*.ts : Use `withEmailAccount` middleware for operations scoped to a specific email account, including reading/writing emails, rules, schedules, or any operation using `emailAccountId`

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-11-25T14:38:07.606Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/llm.mdc:0-0
Timestamp: 2025-11-25T14:38:07.606Z
Learning: Applies to apps/web/utils/ai/**/*.ts : LLM feature functions must import from `zod` for schema validation, use `createScopedLogger` from `@/utils/logger`, `chatCompletionObject` and `createGenerateObject` from `@/utils/llms`, and import `EmailAccountWithAI` type from `@/utils/llms/types`

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-11-25T14:37:11.434Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-11-25T14:37:11.434Z
Learning: Applies to **/app/**/route.ts : Infer and export the response type for GET API routes using `export type GetResponse = Awaited<ReturnType<typeof getData>>` pattern in Next.js

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
📚 Learning: 2025-11-25T14:37:22.822Z
Learnt from: CR
Repo: elie222/inbox-zero PR: 0
File: .cursor/rules/get-api-route.mdc:0-0
Timestamp: 2025-11-25T14:37:22.822Z
Learning: Applies to **/app/**/route.ts : Infer and export response type for GET API routes using `Awaited<ReturnType<typeof functionName>>` pattern in Next.js

Applied to files:

  • apps/web/app/api/user/setup-progress/route.ts
🧬 Code graph analysis (1)
apps/web/app/api/user/setup-progress/route.ts (1)
apps/web/utils/reply-tracker/conversation-status-config.ts (1)
  • CONVERSATION_STATUS_TYPES (3-8)
🔇 Additional comments (3)
apps/web/app/api/user/setup-progress/route.ts (3)

4-4: LGTM!

The import is correct and necessary for the Reply Zero enablement check.


52-54: This logic depends on the fix for the count query above.

The comparison is correct in principle, but relies on the buggy count query flagged in the previous comment. Once that's fixed to use distinct system types, this check will work correctly.


56-61: Integration looks correct, pending the fix above.

The replyZero step is properly integrated into the setup progress. Once the count query is fixed to use distinct system types, this will accurately reflect whether Reply Zero is fully configured.

const hasRules = !!rules?.length;

// Check if Reply Zero is disabled (all conversation status rules are disabled or don't exist)
const isReplyZeroDisabled = useMemo(() => {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed isReplyZeroDisabled banner from the assistant screen. Users can easily toggle on the to reply rule if they want, and this adds visual noise.

Also, it was flashing the banner on screen on load (LoadingContent would have fixed that)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commit 4e1b0c4 addressed this comment by completely removing the isReplyZeroDisabled banner functionality from the assistant screen. The entire useMemo calculation (lines 149-163) and the corresponding banner JSX (lines 167-187) were deleted, along with unused imports like AlertTriangleIcon, eliminating both the visual noise and flashing banner issues mentioned in the comment.

@elie222 elie222 closed this Jan 4, 2026
@elie222
Copy link
Owner

elie222 commented Jan 4, 2026

Hey, I've closed this PR request. It had a lot of things that we don't need. It touches the UI in lots of places and adds complexity to the setup. I'm not sure we need a specific step in the setup for enable reply zero because it's really just part of the regular personal assistant that people are setting up. Also, the icon color blue clashed; it should have been a different icon color, as can be seen in the screenshot. The one place where we would want to show enable reply zero is on the actual reply zero page, and I'm just going to put that in separately in a quick PR request now.

CleanShot 2026-01-04 at 09 52 26

I really appreciate the pull requests. One thing to note is that if you're updating the UI, there's a high chance I won't accept the pull request or will ask for adjustments. So for UI updates, it might be worth sending a message ahead of time. Happy to discuss on Discord or GitHub issues. Discord: http://www.getinboxzero.com/discord

@elie222
Copy link
Owner

elie222 commented Jan 4, 2026

I made a simple fix in this PR:
#1184

If you visit the Reply Zero page and you don't have any conversation rules enabled, it will ask you to enable it. This is the usual onboarding we have for Reply Zero so it was a 1 line change:
CleanShot 2026-01-04 at 10 00 34

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants