Key Information Needed:
Product Vision & Goal:
What is the overall product or feature you want to build? (Give me the elevator pitch.)
What specific problem is it solving for users?
What are the primary business goals? (e.g., Increase revenue, improve user engagement, reduce support costs, enter a new market, test a hypothesis?)
Target Audience:
Who are the primary users? (e.g., Small business owners, teenagers, internal employees, specific job roles?)
Are there different types of users (personas) with different needs?
What are their key pain points or needs related to the problem you're solving?
Core Idea / Proposed Solution:
At a high level, how do you envision solving the problem? What will the product do?
Are there any key capabilities or functionalities that are absolutely essential (MVP scope)?
Are there any existing products (competitors or internal tools) that are relevant? What works well/poorly with them?
Context & Constraints:
Is this a brand new product, or an enhancement to an existing one?
Are there any known technical limitations or requirements? (e.g., Must run on mobile, needs to integrate with Salesforce, specific technology stack preference?)
Are there any budget or timeline constraints I should be aware of?
Are there any specific stakeholders whose needs are critical?
Initial Thoughts (Optional but helpful):
Do you have any early ideas about how you might measure success?
Have you identified any obvious risks or dependencies already?

Okay, here is the full Product Requirements Document Draft 1.2, incorporating all the refinements discussed:

Product Requirements Document: LeetCode Spaced Repetition & Progress Sharing App (Draft 1.2)

1. Introduction & Overview

Problem: Developers practicing on platforms like LeetCode struggle to retain solutions and problem-solving patterns over time. Manually tracking problems attempted and scheduling future reviews using general tools like spreadsheets or basic note-taking apps is inefficient, error-prone, difficult to maintain consistently, and lacks features tailored for coding problem practice or collaborative learning.

Product Vision: To create a dedicated web application that empowers developers to effectively memorize LeetCode solutions and algorithmic patterns using the proven principles of spaced repetition (specifically SM-2). The application will streamline the tracking process and enable users to privately share their learning journey and progress with selected peers or mentors.

Goal: Build an intuitive and focused tool that automates the spaced repetition scheduling for LeetCode problems based on user self-assessment using the SM-2 algorithm. It aims to provide centralized tracking, improve long-term retention of concepts, and facilitate controlled progress sharing among registered users, fostering accountability and collaborative learning within a trusted circle.

2. Objectives

O1: Automate Review Scheduling: Eliminate manual tracking by automatically calculating and scheduling the next review date for LeetCode problems using the SM-2 algorithm based on user-provided quality ratings and review history.

O2: Centralize Problem Tracking: Provide a single, dedicated platform for users to log the LeetCode problems they are working on, their review history, and their self-assessed performance on each review.

O3: Improve Retention: Help users commit LeetCode solutions, patterns, and underlying concepts to long-term memory through consistent, algorithmically optimized review intervals.

O4: Facilitate Controlled Progress Sharing: Enable users to securely share their tracked problem list and progress (read-only) with specific, invited registered users of the platform.

O5: Achieve User Adoption & Engagement: Gain initial users (starting with the founder), grow the user base within the target audience, and encourage consistent usage for tracking and reviewing problems.

3. Target Audience

Primary: Individuals actively practicing coding problems on platforms like LeetCode, particularly those preparing for technical interviews, learning data structures and algorithms, or finding manual retention methods challenging.

Secondary: More experienced developers seeking a structured review system; coding bootcamp students; Computer Science students using LeetCode for coursework or practice.

Initial User: The project initiator.

4. Key Features (Minimum Viable Product - MVP)

F1: User Authentication: Ability for users to sign up using email/password and log in. Requires email verification to enable sharing features.

F2: Add LeetCode Problem: Functionality for a logged-in user to select a LeetCode problem from a searchable/browsable list fetched via LeetCode's public API (displaying Title, Difficulty, ID). The app should store selected problem details locally (e.g., frontendQuestionId, title, titleSlug, difficulty, topicTags, paidOnly).

F3: Rate Problem Attempt: After reviewing/solving a tracked problem, allow the user to rate the quality of their response using a 0-5 scale, clearly defined in the UI (e.g., 5=perfect, 4=correct after hesitation, 3=correct with difficulty, 2=incorrect but known, 1=incorrect, 0=complete blackout). This rating is the primary input for the SM-2 algorithm.

F4: Spaced Repetition Scheduling (SM-2): Core backend logic implementing the SM-2 algorithm to calculate the next review date.

Uses the 0-5 quality rating (F3).

Maintains an E-Factor (Ease Factor) per tracked problem instance for each user, starting at 2.5, with a minimum value of 1.3.

Calculates the next inter-repetition interval I(n) based on the previous interval I(n-1) and the current E-Factor EF, using I(n) = I(n-1) * EF. Base cases: I(1)=1 day, I(2)=6 days. Intervals are rounded up to the nearest whole day.

Adjusts the E-Factor after each review based on the quality rating q using the formula: EF' = EF + (0.1 - (5 - q) * (0.08 + (5 - q) * 0.02)).

Resets the repetition sequence (interval calculation restarts from I(1)) if the quality rating q is less than 3, without changing the existing E-Factor.

(Decision for MVP: The SM-2 recommendation to repeat items scoring < 4 within the same study session will be deferred to a potential future release to simplify the initial implementation.)

F5: Review Dashboard: A view displaying a list of all problems whose Next Review Date is on or before the current date, indicating they are due for review. Missed reviews should remain on this list until reviewed.

F6: All Problems List: A view allowing users to see all the LeetCode problems they have added to the system, potentially showing details like Title, Difficulty, Next Review Date, Last Reviewed Date, and current E-Factor.

F7: Manage Sharing: Functionality within a user's account settings to invite other registered and verified users (by email) to view their tracked problem list. Users should also be able to see who currently has access and revoke that access.

F8: View Shared Lists: A dedicated section or mechanism for logged-in users to access and view the tracked problem lists that have been explicitly shared with them by other users (read-only view).

5. User Stories (MVP)

US1: As a logged-in user, I want to browse or search a list of available LeetCode problems (displaying Title, Difficulty) fetched from the official API and select one to add it to my personal tracking list, so that I can start applying spaced repetition to it.

US2: As a logged-in user, when I review a problem from my tracking list, I want to be prompted to rate my recall quality on a clear 0-5 scale (with descriptors), so that the system can accurately calculate the next optimal review date for that problem using the SM-2 algorithm.

US3: As a logged-in user, I want to access a dashboard that clearly lists all the problems that are currently due for review (today or earlier), so that I know what I need to study and can easily catch up on any missed reviews.

US4: As a logged-in user, I want to be able to view my complete list of tracked LeetCode problems, along with relevant status information (like the next review date), so I can get an overview of my learning progress and workload.

US5: As a new user, I want to be able to sign up for an account using my email address and a password, and then verify my email address via a confirmation link, so that I can securely save my progress and utilize features like sharing.

US6: As a logged-in user (Owner), I want to navigate to a sharing management section where I can enter the verified email address of another registered user and grant them read-only permission to view my tracked problem list, so I can share my progress privately with friends or mentors.

US7: As a logged-in user (Viewer), I want to have a section in the application where I can see and access the progress lists that other users have specifically shared with me, so I can follow their learning journey.

US8: As a logged-in user (Owner), I want to view a list of all users I have granted access to my progress list and have the ability to revoke access for any individual user, so I maintain control over who can see my data.

6. Technical Requirements

T1: Frontend/Backend: Full-stack Next.JS (using App Router).

T2: Database ORM: Prisma.

T3: Database: PostgreSQL.

T4: Hosting: Platform to be determined (e.g., Vercel, Fly.io, AWS Amplify, Railway).

T5: Spaced Repetition Algorithm (SM-2 Implementation):

Backend service/logic to implement the SM-2 algorithm precisely as defined in F4.

Database schema must support storing per-user, per-problem state: current_interval_days, ease_factor, repetitions_count, next_review_date.

Requires persistent storage of individual review events: user_id, problem_id, review_timestamp, quality_rating_q, calculated_interval_before_review, ef_before_review.

Ensure calculations handle date arithmetic correctly, including rounding up intervals to whole days. Enforce EF minimum of 1.3. Implement the repetition reset logic for q < 3.

(Decision: Defer same-session reviews for q<4 for MVP).

T6: LeetCode Public API Integration:

Implement reliable fetching of the LeetCode problem list via their public GraphQL endpoint (or alternative public API if available/more suitable).

Parse and store required fields locally: frontendQuestionId (as unique problem identifier), title, titleSlug (for generating LC links), difficulty, topicTags (store as JSON or normalized relation), paidOnly.

Implement a caching strategy (e.g., periodic background job, cache-on-read with TTL) for the fetched LeetCode problem data to minimize external API calls and improve performance.

T7: Sharing Mechanism (Email-based Access Control):

Requires user accounts to have a verified email status.

Implement an invitation/permission system: Owner inputs potential Viewer's email. System checks if Viewer is registered and verified. If yes, creates a permission record.

Database schema required for access control (e.g., a ListShares table with ownerUserId, viewerUserId, permissionType (e.g., 'read'), grantedTimestamp).

Backend authorization logic must enforce these permissions when accessing user problem lists.

Frontend UI for Owners to input emails, view current viewers, and trigger revocation.

T8: User Management & Authentication: Standard email/password sign-up, secure password hashing, login functionality, and an email verification flow (sending a unique link/code).

7. Success Metrics

SM1: User Signups: Total number of registered users with verified email addresses.

SM2: Active Users: Daily Active Users (DAU), Weekly Active Users (WAU), Monthly Active Users (MAU) – focusing on users who log in AND perform a core action (add problem, review problem).

SM3: Problem Tracking Engagement:

Average number of problems tracked per active user.

Total number of problems tracked across the platform.

SM4: Review Completion Rate:

Total number of reviews completed (ratings submitted).

Average number of reviews completed per active user per week/month.

SM5: User Retention: Week 1, Week 4, Month 3 retention rates (percentage of new users returning).

SM6: Sharing Feature Usage:

Total number of unique lists shared (owner-viewer pairs).

Percentage of active users who have shared their list.

Percentage of active users who are viewing at least one shared list.

SM7 (Operational/Insight Metric): Distribution of review quality ratings (0-5) submitted – helps understand user difficulty and algorithm effectiveness.

8. Potential Risks & Dependencies

R1: Algorithm Implementation Complexity: Correctly implementing SM-2 state management (EF, intervals, resets) per user/problem requires careful design and testing. Off-by-one errors or incorrect state updates can degrade user experience.

R2: User Motivation & Churn: The app's value is tied to the user's motivation to practice LeetCode. If users stop practicing, they will likely stop using the app.

R3: Sharing Feature Complexity: Implementing secure, email-based sharing (invites, permissions management, revocation, UI) is significantly more complex than public links and adds considerable development effort for MVP.

R4: Scope Creep: High risk of wanting to add more features to sharing (e.g., commenting, different permission levels) or the SRS algorithm (e.g., customizable intervals, different algorithms) before validating the core MVP loop.

R5: LeetCode API Reliability & Changes: The application depends heavily on the availability, stability, and structure of LeetCode's public API. Any changes, rate limiting, or deprecation could break core functionality (adding problems). Requires monitoring and potential adaptation.

R6: Scalability: As user numbers and tracked problems grow, database queries for dashboards, problem lists, and permission checks need to be performant. Efficient fetching/display of the global LeetCode problem list is also crucial.

R7: User Experience of 0-5 Scale: Users must easily understand the meaning of each numerical rating (0-5) for the SRS algorithm to function as intended. Requires clear labels, tooltips, or onboarding guidance.

D1: SRS Algorithm Fine-tuning: While SM-2 is defined, initial parameters (starting EF, base intervals if deviating slightly) and the exact handling of edge cases need final confirmation. Decision to defer same-session repeats needs to be firm for MVP scope.

D2: LeetCode API Exploration: Thoroughly investigate the specific GraphQL endpoint, its schema, rate limits, and any terms of service regarding its use in third-party applications.

D3: Sharing UI/UX Design: Carefully design the user flows for sending invitations, accepting/viewing shared lists, and managing permissions to be intuitive and secure.

This concludes Draft 1.2. Let me know when you're ready to discuss the next steps, like data modeling.

-- --- User Authentication & Profile ---
-- Links to the master user record in Supabase Auth (or similar)
DROP TABLE IF exists users cascade;
CREATE TABLE users (
    id UUID PRIMARY KEY NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
    email TEXT, -- Optional cache from auth.users
    name TEXT,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create or replace function handle_new_user()
returns trigger as $$
begin
  insert into public.users
  values(new.id, new.email, new.raw_user_meta_data->>'name', new.created_at);

  insert into public.workspaces(owner_user_id)
  values(new.id);

  return new;
end;
$$ language plpgsql security definer;

create or replace trigger on_new_user
after insert on auth.users for each row
execute procedure public.handle_new_user();

-- --- Workspaces ---
-- Represents a container for tracked LeetCode problems.
-- A user might have one or more workspaces (though MVP might focus on one initially).
DROP TABLE IF exists workspaces cascade;
CREATE TABLE workspaces (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- Use built-in UUID generation
    owner_user_id UUID NOT NULL, -- The user who created/owns the workspace
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP, -- Needs trigger for auto-update

    -- Relationship to the owner
    -- Use RESTRICT initially: prevent deleting a user if they still own workspaces.
    CONSTRAINT fk_workspaces_owner FOREIGN KEY (owner_user_id) REFERENCES users(id) ON DELETE RESTRICT
);

-- Index for fetching workspaces owned by a user
CREATE INDEX idx_workspaces_owner_user_id ON workspaces(owner_user_id);

-- --- Canonical LeetCode Problem Data ---
-- (No changes needed here)
DROP TABLE IF exists leet_code_problems cascade;
CREATE TABLE leet_code_problems (
    id TEXT PRIMARY KEY, -- Assuming CUID generated by application
    frontend_question_id TEXT NOT NULL UNIQUE,
    title TEXT NOT NULL,
    title_slug TEXT NOT NULL UNIQUE,
    difficulty VARCHAR(10) NOT NULL,
    paid_only BOOLEAN NOT NULL,
    topic_tags JSONB,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_leet_code_problems_frontend_question_id ON leet_code_problems(frontend_question_id);
CREATE INDEX idx_leet_code_problems_title_slug ON leet_code_problems(title_slug);

-- --- Tracking a Specific LeetCode Problem within a Workspace ---
DROP TABLE IF exists tracked_problems cascade;
CREATE TABLE tracked_problems (
    id bigint primary key generated always as identity, -- Assuming CUID generated by application
    -- **** CHANGED **** Removed user_id, added workspace_id
    workspace_id UUID NOT NULL,
    problem_id TEXT NOT NULL,

    -- SM-2 State (unchanged)
    ease_factor DOUBLE PRECISION NOT NULL DEFAULT 2.5,
    interval_days INTEGER NOT NULL DEFAULT 0,
    repetitions_count INTEGER NOT NULL DEFAULT 0,
    next_review_date TIMESTAMP WITH TIME ZONE NOT NULL,
    last_reviewed_at TIMESTAMP WITH TIME ZONE,

    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,

    -- **** UPDATED **** Foreign key constraint references workspaces table
    CONSTRAINT fk_tracked_problems_workspace FOREIGN KEY (workspace_id) REFERENCES workspaces(id) ON DELETE CASCADE, -- If workspace deleted, delete its tracked problems
    CONSTRAINT fk_tracked_problems_problem FOREIGN KEY (problem_id) REFERENCES leet_code_problems(id) ON DELETE RESTRICT,

    -- **** UPDATED **** Ensure a problem is tracked only once PER WORKSPACE
    CONSTRAINT uq_tracked_problems_workspace_problem UNIQUE (workspace_id, problem_id)
);

-- **** UPDATED **** Indices reflecting the change
CREATE INDEX idx_tracked_problems_workspace_id ON tracked_problems(workspace_id);
CREATE INDEX idx_tracked_problems_problem_id ON tracked_problems(problem_id);
CREATE INDEX idx_tracked_problems_next_review_date ON tracked_problems(next_review_date); -- Still needed for review dashboard query

-- --- Record of a Single Review Event ---
-- (No direct change needed, still links to tracked_problems)
DROP TABLE IF exists reviews cascade;
CREATE TABLE reviews (
    id bigint primary key generated always as identity, -- Assuming CUID generated by application
    tracked_problem_id bigint NOT NULL,
    quality_rating INTEGER NOT NULL,
    reviewed_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT fk_reviews_tracked_problem FOREIGN KEY (tracked_problem_id) REFERENCES tracked_problems(id) ON DELETE CASCADE
);
CREATE INDEX idx_reviews_tracked_problem_id ON reviews(tracked_problem_id);

-- --- Workspace Sharing Permissions ---
-- **** RENAMED and RESTRUCTURED **** (Replaces list_shares)
DROP TABLE IF exists workspace_shares cascade;
CREATE TYPE user_role AS ENUM ('viewer', 'editor', 'reviewer');
CREATE TABLE workspace_shares (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- Use built-in UUID generation
    -- The workspace being shared
    workspace_id UUID NOT NULL,
    -- The user being granted access
    shared_user_id UUID NOT NULL,

    role user_role NOT NULL,
    -- Optional: Add permission level later (e.g., 'read', 'write') if needed

    granted_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,

    -- Relationships
    CONSTRAINT fk_workspace_shares_workspace FOREIGN KEY (workspace_id) REFERENCES workspaces(id) ON DELETE CASCADE, -- If workspace deleted, remove shares for it
    CONSTRAINT fk_workspace_shares_viewer FOREIGN KEY (shared_user_id) REFERENCES users(id) ON DELETE CASCADE, -- If viewer user deleted, remove shares granted TO them

    -- Ensure a user has only one share entry per workspace
    CONSTRAINT uq_workspace_shares_workspace_viewer UNIQUE (workspace_id, shared_user_id)
);

-- Indices for looking up shares by workspace or viewer
CREATE INDEX idx_workspace_shares_workspace_id ON workspace_shares(workspace_id);
CREATE INDEX idx_workspace_shares_shared_user_id ON workspace_shares(shared_user_id);