docs: Add PRD V2 with comprehensive review and next phase roadmap#28
Conversation
- Comprehensive assessment of all 18 PRs (#10-27) - Identified 5 critical issues requiring immediate attention: 1. In-memory storage (subscribers, settings) - needs Supabase migration 2. Unprotected API endpoints - needs authentication middleware 3. Email compliance - needs unsubscribe links 4. Landing page issues - fictional testimonials, dead links 5. AI model settings not integrated with research pipeline - 4-week roadmap for production readiness: - Week 1-2: Production readiness (storage, security, compliance) - Week 2-3: Integration & testing - Week 3-4: Documentation, demo video - Week 4: Deployment & launch - New database schema for notification_subscribers and user_settings - Environment variables checklist - Risk assessment and success metrics
Original prompt from Datakult |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
📝 WalkthroughWalkthroughA new Phase 2 Product Requirements Document is added to Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@docs/PRD-V2.md`:
- Around line 434-447: Add explicit RLS policies for the
notification_subscribers table similar to user_settings: create three policies
(e.g., "Users can view own subscriptions", "Users can update own subscriptions",
"Users can insert own subscriptions") that grant FOR SELECT USING (auth.uid() =
user_id), FOR UPDATE USING (auth.uid() = user_id), and FOR INSERT WITH CHECK
(auth.uid() = user_id) respectively; alternatively, if a service role should
bypass RLS, document that intent and show the appropriate role-based policies or
use a SECURITY DEFINER function instead.
- Around line 120-142: The two table schemas diverge and must be unified: choose
a canonical schema for notification_subscribers and user_settings and update
both places (Section 2.1.1 and Appendix 6.2) to match exactly; specifically
ensure notification_subscribers includes fields unsubscribe_token and is_active
and any desired defaults/constraints, and ensure user_settings includes the
preset CHECK constraint, UNIQUE(user_id), custom_models, timestamps, and the
intended RLS policies; update the SQL snippets and any accompanying prose so
both occurrences reference the same table names (notification_subscribers,
user_settings), columns, constraints (e.g., CHECK on preset, UNIQUE(user_id)),
default values, and RLS policy text.
🧹 Nitpick comments (1)
docs/PRD-V2.md (1)
123-142: Note required UUID extension forgen_random_uuid().
Consider adding a short note to enablepgcrypto(or whichever extension is expected) so the schema is reproducible across environments.Also applies to: 413-433
| **Tasks:** | ||
| 1. Create `notification_subscribers` table in Supabase | ||
| ```sql | ||
| CREATE TABLE notification_subscribers ( | ||
| id UUID PRIMARY KEY DEFAULT gen_random_uuid(), | ||
| email TEXT UNIQUE NOT NULL, | ||
| preferences JSONB DEFAULT '{"deadlines": true, "newGrants": true, "weeklyDigest": true}', | ||
| created_at TIMESTAMPTZ DEFAULT NOW(), | ||
| updated_at TIMESTAMPTZ DEFAULT NOW() | ||
| ); | ||
| ``` | ||
|
|
||
| 2. Create `user_settings` table in Supabase | ||
| ```sql | ||
| CREATE TABLE user_settings ( | ||
| id UUID PRIMARY KEY DEFAULT gen_random_uuid(), | ||
| user_id UUID REFERENCES auth.users(id), | ||
| preset TEXT DEFAULT 'low-cost', | ||
| custom_models JSONB, | ||
| created_at TIMESTAMPTZ DEFAULT NOW(), | ||
| updated_at TIMESTAMPTZ DEFAULT NOW() | ||
| ); | ||
| ``` |
There was a problem hiding this comment.
Align table definitions between Section 2.1.1 and Appendix 6.2.
The notification_subscribers and user_settings schemas differ (e.g., unsubscribe_token, is_active, preset CHECK, UNIQUE(user_id), RLS policies). This can lead to partial implementations. Pick a single canonical definition and update both sections to match.
Also applies to: 409-447
🤖 Prompt for AI Agents
In `@docs/PRD-V2.md` around lines 120 - 142, The two table schemas diverge and
must be unified: choose a canonical schema for notification_subscribers and
user_settings and update both places (Section 2.1.1 and Appendix 6.2) to match
exactly; specifically ensure notification_subscribers includes fields
unsubscribe_token and is_active and any desired defaults/constraints, and ensure
user_settings includes the preset CHECK constraint, UNIQUE(user_id),
custom_models, timestamps, and the intended RLS policies; update the SQL
snippets and any accompanying prose so both occurrences reference the same table
names (notification_subscribers, user_settings), columns, constraints (e.g.,
CHECK on preset, UNIQUE(user_id)), default values, and RLS policy text.
| -- Enable RLS | ||
| ALTER TABLE notification_subscribers ENABLE ROW LEVEL SECURITY; | ||
| ALTER TABLE user_settings ENABLE ROW LEVEL SECURITY; | ||
|
|
||
| -- RLS policies | ||
| CREATE POLICY "Users can view own settings" ON user_settings | ||
| FOR SELECT USING (auth.uid() = user_id); | ||
|
|
||
| CREATE POLICY "Users can update own settings" ON user_settings | ||
| FOR UPDATE USING (auth.uid() = user_id); | ||
|
|
||
| CREATE POLICY "Users can insert own settings" ON user_settings | ||
| FOR INSERT WITH CHECK (auth.uid() = user_id); | ||
| ``` |
There was a problem hiding this comment.
Add RLS policies for notification_subscribers.
RLS is enabled but no policies are defined, so all access will be denied. Please add explicit SELECT/INSERT/UPDATE policies (or clarify if a service role is intended for all access).
🤖 Prompt for AI Agents
In `@docs/PRD-V2.md` around lines 434 - 447, Add explicit RLS policies for the
notification_subscribers table similar to user_settings: create three policies
(e.g., "Users can view own subscriptions", "Users can update own subscriptions",
"Users can insert own subscriptions") that grant FOR SELECT USING (auth.uid() =
user_id), FOR UPDATE USING (auth.uid() = user_id), and FOR INSERT WITH CHECK
(auth.uid() = user_id) respectively; alternatively, if a service role should
bypass RLS, document that intent and show the appropriate role-based policies or
use a SECURITY DEFINER function instead.
1 participant
Summary
Adds a comprehensive Product Requirements Document (PRD V2) that reviews all 18 PRs created across Sessions 1-9 and Phases 2-4, identifies critical issues blocking production deployment, and outlines a 4-week roadmap for the next development phase.
Key findings from the review:
Proposed roadmap:
Review & Testing Checklist for Human
notification_subscribersanduser_settingstables to ensure they integrate with existing schemaRecommended review approach: Read through the Executive Summary and Section 1.3 (Critical Issues) first, then skim the roadmap sections to validate the proposed approach aligns with your priorities.
Notes
This is a documentation-only PR with no code changes. The PRD will serve as the planning document for the next development phase.
All 18 referenced PRs (#10-27) are currently open and awaiting merge in the specified order.
Link to Devin run: https://app.devin.ai/sessions/9573820f0f6d41dab1cff8a61c26c981
Requested by: @Datakult0r
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.