---
description: 
globs: 
alwaysApply: false
---
Objective: Deliver the minimum set of features a user would expect from a basic form backend service. 

use notes.md to track progress!

Task 2.1: User Dashboard & Form Management UI (Replacing current "admin")
* Mindset Shift: This is no longer your admin panel. It's the user's control center.
* Subtask 2.1.1: Design User Dashboard Layout:
* [ ] Wireframe basic layout: List forms, create form, account settings (placeholder).
* [ ] Decide on frontend tech (EJS is fine for MVP if you make it dynamic with client-side JS, or consider a simple SPA framework if comfortable).
* Subtask 2.1.2: "My Forms" View:
* [ ] Fetch and display forms owned by the logged-in user.
* [ ] Show key info: name, submission count, endpoint URL, created date.
* [ ] Links to: view submissions, edit settings, delete.
* Subtask 2.1.3: "Create New Form" Functionality (for logged-in user):
* [ ] UI and backend logic. Associates form with req.user.id.
* Subtask 2.1.4: "View Form Submissions" (Scoped & Paginated):
* [ ] UI and backend for a user to view submissions for their specific form.
* [ ] Pagination is critical here (as you have).
* Subtask 2.1.5: Form Settings UI (Basic):
* [ ] Allow users to update form name.
* [ ] Placeholder for future settings (thank you URL, notifications).
* Subtask 2.1.6: Delete Form/Submission (with soft delete/archival consideration):
* [ ] You have is_archived. Solidify this. Users should be able to archive/unarchive.
* [ ] True delete should be a confirmed, rare operation.

Task 2.2: Per-Form Configuration by User
* Mindset Shift: Empower users to customize their form behavior.
* Subtask 2.2.1: Database Schema Updates for forms Table:
* [ ] Review existing fields (thank_you_url, thank_you_message, ntfy_enabled, allowed_domains). These are good.
* [ ] Add email_notifications_enabled (boolean).
* [ ] Add notification_email_address (string, defaults to user's email, but allow override).
* Subtask 2.2.2: UI for Form Settings Page:
* [ ] Create a dedicated page/modal for each form's settings.
* [ ] Allow users to edit: Name, Thank You URL, Thank You Message, Allowed Domains, Email Notification toggle, Notification Email Address.
* Subtask 2.2.3: Backend to Save and Apply Settings:
* [ ] API endpoints to update these settings for a specific form (owned by user).
* [ ] Logic in /submit/:formUuid to use these form-specific settings.

Task 2.3: Email Notifications for Submissions (Core Feature)
* Mindset Shift: Ntfy is cool for you. Users expect email.
* Subtask 2.3.1: Integrate Transactional Email Service:
* [ ] Sign up for SendGrid, Mailgun, AWS SES (free tiers available).
* [ ] Install their SDK. Store API key securely (env vars).
* Subtask 2.3.2: Email Sending Logic:
* [ ] Create a service/function sendSubmissionNotification(form, submissionData).
* [ ] If email_notifications_enabled for the form, send an email to notification_email_address.
* Subtask 2.3.3: Basic Email Template:
* [ ] Simple, clear email: "New Submission for [Form Name]", list submitted data.
* Subtask 2.3.4: Error Handling for Email Sending:
* [ ] Log errors if email fails to send; don't let it break the submission flow.

Task 2.4: Enhanced Spam Protection (Beyond Basic Honeypot)
* Mindset Shift: Your honeypot is step 1. Real services need more.
* Subtask 2.4.1: Integrate CAPTCHA (e.g., Google reCAPTCHA):
* [ ] Sign up for reCAPTCHA (v2 "I'm not a robot" or v3 invisible). Get site/secret keys.
* [ ] Frontend: Add reCAPTCHA widget/JS to user's HTML form example.
* [ ] Backend: /submit/:formUuid endpoint must verify reCAPTCHA token with Google.
* Subtask 2.4.2: User Configuration for Spam Protection:
* [ ] Allow users to enable/disable reCAPTCHA for their forms (and input their own site key if they want, or use a global one you provide).
* Subtask 2.4.3: (Future Consideration) Akismet / Content Analysis.

Task 2.5: Basic API for Users to Access Their Data
* Mindset Shift: Power users and integrations need an API.
* Subtask 2.5.1: API Key Generation & Management:
* [ ] Allow users to generate/revoke API keys from their dashboard.
* [ ] Store hashed API keys in DB, associated with user.
* Subtask 2.5.2: Secure API Endpoints:
* [ ] Create new API routes (e.g., /api/v1/forms, /api/v1/forms/:uuid/submissions).
* [ ] Authenticate using API keys (e.g., Bearer token).
* Subtask 2.5.3: Basic API Documentation:

* [ ] Simple Markdown file explaining authentication and available endpoints.