Vamo Builder — Developer Bounty Spec

You must use the following. No substitutions unless explicitly approved.

What NOT to use

• No Firebase, no Prisma, no Drizzle (use Supabase client directly or raw SQL migrations)
• No service role key — all data access goes through RLS with the anon key + user JWT
• No Next.js Pages Router
• No component libraries other than shadcn/ui (no Material UI, Chakra, Ant Design, etc.)

Auth Flow

• Use Supabase Auth with email/password signup and login.
• Google OAuth is optional but nice-to-have.
• On signup, create a row in the profiles table via a Supabase database trigger (or in the signup flow server-side).
• Use Supabase's onAuthStateChange to manage session on the client.
• Protect all routes except /, /login, /signup, and /marketplace with middleware. Unauthenticated users must be redirected to /login.

Middleware

Create middleware.ts at the project root:

// Must check Supabase session
// Redirect unauthenticated users to /login
// Allow public routes: /, /login, /signup, /marketplace
// Admin routes (/admin) must additionally check profiles.is_admin = true

Admin Role

• The profiles table has an is_admin boolean column (default false).
• To make yourself admin during development, manually set is_admin = true in Supabase dashboard for your user.
• The /admin route must check this flag. If is_admin is false, redirect to /projects.

All tables must have RLS enabled. No exceptions.

Below is the full schema. Deliver these as numbered SQL migration files in supabase/migrations/.

5.1 profiles

CREATE TABLE profiles (
  id UUID PRIMARY KEY REFERENCES auth.users(id) ON DELETE CASCADE,
  email TEXT NOT NULL,
  full_name TEXT,
  avatar_url TEXT,
  is_admin BOOLEAN DEFAULT false,
  pineapple_balance INTEGER DEFAULT 0,
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

-- Users can read their own profile
CREATE POLICY "Users can view own profile"
  ON profiles FOR SELECT
  USING (auth.uid() = id);

-- Users can update their own profile (but not is_admin or pineapple_balance)
CREATE POLICY "Users can update own profile"
  ON profiles FOR UPDATE
  USING (auth.uid() = id)
  WITH CHECK (auth.uid() = id);

-- Admins can read all profiles
CREATE POLICY "Admins can view all profiles"
  ON profiles FOR SELECT
  USING (
    EXISTS (SELECT 1 FROM profiles WHERE id = auth.uid() AND is_admin = true)
  );

-- Insert triggered by auth signup (via trigger or server-side)
CREATE POLICY "Enable insert for auth"
  ON profiles FOR INSERT
  WITH CHECK (auth.uid() = id);

5.2 projects

CREATE TABLE projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  owner_id UUID NOT NULL REFERENCES profiles(id) ON DELETE CASCADE,
  name TEXT NOT NULL,
  description TEXT,
  url TEXT,                          -- linked Lovable/Replit/external URL
  screenshot_url TEXT,
  status TEXT DEFAULT 'active' CHECK (status IN ('active', 'listed', 'sold', 'archived')),
  progress_score INTEGER DEFAULT 0,  -- 0-100
  valuation_low INTEGER DEFAULT 0,
  valuation_high INTEGER DEFAULT 0,
  why_built TEXT,                     -- founder's "why" statement
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Owner can CRUD their own projects
CREATE POLICY "Owner can select own projects"
  ON projects FOR SELECT USING (auth.uid() = owner_id);

CREATE POLICY "Owner can insert projects"
  ON projects FOR INSERT WITH CHECK (auth.uid() = owner_id);

CREATE POLICY "Owner can update own projects"
  ON projects FOR UPDATE USING (auth.uid() = owner_id);

CREATE POLICY "Owner can delete own projects"
  ON projects FOR DELETE USING (auth.uid() = owner_id);

-- Public can view listed projects (marketplace)
CREATE POLICY "Public can view listed projects"
  ON projects FOR SELECT USING (status = 'listed');

-- Admins can view all
CREATE POLICY "Admins can view all projects"
  ON projects FOR SELECT
  USING (
    EXISTS (SELECT 1 FROM profiles WHERE id = auth.uid() AND is_admin = true)
  );

5.3 messages

CREATE TABLE messages (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  project_id UUID NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
  user_id UUID NOT NULL REFERENCES profiles(id) ON DELETE CASCADE,
  role TEXT NOT NULL CHECK (role IN ('user', 'assistant')),
  content TEXT NOT NULL,
  extracted_intent TEXT,              -- AI-extracted intent: feature, customer, revenue, ask, general
  tag TEXT CHECK (tag IN ('feature', 'customer', 'revenue', 'ask', 'general', NULL)),
  pineapples_earned INTEGER DEFAULT 0,
  created_at TIMESTAMPTZ DEFAULT now()
);

ALTER TABLE messages ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Owner can select own messages"
  ON messages FOR SELECT
  USING (auth.uid() = user_id);

CREATE POLICY "Owner can insert messages"
  ON messages FOR INSERT
  WITH CHECK (auth.uid() = user_id);

5.4 activity_events

CREATE TABLE activity_events (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  project_id UUID NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
  user_id UUID NOT NULL REFERENCES profiles(id) ON DELETE CASCADE,
  event_type TEXT NOT NULL CHECK (event_type IN (
    'prompt', 'update', 'link_linkedin', 'link_github',
    'link_website', 'feature_shipped', 'customer_added',
    'revenue_logged', 'listing_created', 'offer_received',
    'reward_earned', 'reward_redeemed'
  )),
  description TEXT,
  metadata JSONB DEFAULT '{}',
  created_at TIMESTAMPTZ DEFAULT now()
);

ALTER TABLE activity_events ENABLE ROW LEVEL SECURITY;

-- Events are IMMUTABLE — insert only, no update or delete for non-admins
CREATE POLICY "Owner can select own events"
  ON activity_events FOR SELECT
  USING (auth.uid() = user_id);

CREATE POLICY "Owner can insert events"
  ON activity_events FOR INSERT
  WITH CHECK (auth.uid() = user_id);

-- No UPDATE or DELETE policies for regular users (immutability)

5.5 reward_ledger

CREATE TABLE reward_ledger (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES profiles(id) ON DELETE CASCADE,
  project_id UUID REFERENCES projects(id) ON DELETE SET NULL,
  event_type TEXT NOT NULL,
  reward_amount INTEGER NOT NULL,
  balance_after INTEGER NOT NULL,
  idempotency_key TEXT UNIQUE NOT NULL,  -- Prevents duplicate rewards
  created_at TIMESTAMPTZ DEFAULT now()
);

ALTER TABLE reward_ledger ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Owner can view own ledger"
  ON reward_ledger FOR SELECT
  USING (auth.uid() = user_id);

-- Users can insert own ledger entries (via API routes that pass the user's session)
CREATE POLICY "Owner can insert own ledger"
  ON reward_ledger FOR INSERT
  WITH CHECK (auth.uid() = user_id);

-- Admins can view all ledger entries
CREATE POLICY "Admins can view all ledger"
  ON reward_ledger FOR SELECT
  USING (
    EXISTS (SELECT 1 FROM profiles WHERE id = auth.uid() AND is_admin = true)
  );

5.6 redemptions

CREATE TABLE redemptions (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES profiles(id) ON DELETE CASCADE,
  amount INTEGER NOT NULL CHECK (amount > 0),
  reward_type TEXT NOT NULL DEFAULT 'uber_eats',
  status TEXT DEFAULT 'pending' CHECK (status IN ('pending', 'fulfilled', 'failed')),
  metadata JSONB DEFAULT '{}',
  created_at TIMESTAMPTZ DEFAULT now(),
  fulfilled_at TIMESTAMPTZ
);

ALTER TABLE redemptions ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Owner can view own redemptions"
  ON redemptions FOR SELECT
  USING (auth.uid() = user_id);

CREATE POLICY "Owner can insert redemptions"
  ON redemptions FOR INSERT
  WITH CHECK (auth.uid() = user_id);

-- Admins can view all redemptions
CREATE POLICY "Admins can view all redemptions"
  ON redemptions FOR SELECT
  USING (
    EXISTS (SELECT 1 FROM profiles WHERE id = auth.uid() AND is_admin = true)
  );

-- Admins can update redemption status (fulfill/fail)
CREATE POLICY "Admins can update redemptions"
  ON redemptions FOR UPDATE
  USING (
    EXISTS (SELECT 1 FROM profiles WHERE id = auth.uid() AND is_admin = true)
  );

5.7 listings

CREATE TABLE listings (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  project_id UUID NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
  user_id UUID NOT NULL REFERENCES profiles(id) ON DELETE CASCADE,
  title TEXT NOT NULL,
  description TEXT,
  asking_price_low INTEGER,
  asking_price_high INTEGER,
  timeline_snapshot JSONB,            -- Frozen copy of activity timeline at listing time
  screenshots JSONB DEFAULT '[]',     -- Array of screenshot URLs
  metrics JSONB DEFAULT '{}',         -- Progress score, traction signals, etc.
  status TEXT DEFAULT 'active' CHECK (status IN ('active', 'sold', 'withdrawn')),
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

ALTER TABLE listings ENABLE ROW LEVEL SECURITY;

-- Owner can manage their own listings
CREATE POLICY "Owner can select own listings"
  ON listings FOR SELECT USING (auth.uid() = user_id);

CREATE POLICY "Owner can insert listings"
  ON listings FOR INSERT WITH CHECK (auth.uid() = user_id);

CREATE POLICY "Owner can update own listings"
  ON listings FOR UPDATE USING (auth.uid() = user_id);

-- Public can view active listings
CREATE POLICY "Public can view active listings"
  ON listings FOR SELECT USING (status = 'active');

5.8 offers

CREATE TABLE offers (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  project_id UUID NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
  user_id UUID NOT NULL REFERENCES profiles(id) ON DELETE CASCADE,
  offer_low INTEGER NOT NULL,
  offer_high INTEGER NOT NULL,
  reasoning TEXT,                      -- AI-generated explanation
  signals JSONB DEFAULT '{}',
  status TEXT DEFAULT 'active' CHECK (status IN ('active', 'expired', 'accepted')),
  created_at TIMESTAMPTZ DEFAULT now(),
  expires_at TIMESTAMPTZ
);

ALTER TABLE offers ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Owner can view own offers"
  ON offers FOR SELECT USING (auth.uid() = user_id);

5.9 analytics_events

CREATE TABLE analytics_events (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES profiles(id) ON DELETE SET NULL,
  project_id UUID REFERENCES projects(id) ON DELETE SET NULL,
  event_name TEXT NOT NULL,
  properties JSONB DEFAULT '{}',
  created_at TIMESTAMPTZ DEFAULT now()
);

ALTER TABLE analytics_events ENABLE ROW LEVEL SECURITY;

-- Authenticated users can insert their own events
CREATE POLICY "Users can insert own analytics"
  ON analytics_events FOR INSERT
  WITH CHECK (auth.uid() = user_id);

-- Admins can read all analytics
CREATE POLICY "Admins can view analytics"
  ON analytics_events FOR SELECT
  USING (
    EXISTS (SELECT 1 FROM profiles WHERE id = auth.uid() AND is_admin = true)
  );

Database Trigger: Auto-create profile on signup

CREATE OR REPLACE FUNCTION public.handle_new_user()
RETURNS TRIGGER AS $$
BEGIN
  INSERT INTO public.profiles (id, email, full_name, avatar_url)
  VALUES (
    NEW.id,
    NEW.email,
    NEW.raw_user_meta_data->>'full_name',
    NEW.raw_user_meta_data->>'avatar_url'
  );
  RETURN NEW;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

CREATE TRIGGER on_auth_user_created
  AFTER INSERT ON auth.users
  FOR EACH ROW EXECUTE FUNCTION public.handle_new_user();

Route: /projects/new

UI Requirements

• Clean form using shadcn Card, Input, Textarea, Button components.
• Fields:
  • Project Name (required, text input, max 100 chars)
  • Description (optional, textarea, max 500 chars)
  • External URL (optional, URL input — for linked Lovable/Replit/etc. project)
  • Why did you build this? (optional, textarea, max 1000 chars)
• "Create Project" button submits to Supabase.
• On success, redirect to /builder/[projectId].

Validation

• Project name is required and must be non-empty after trim.
• URL, if provided, must be a valid URL (starts with http:// or https://).
• Show inline validation errors using shadcn form patterns.

Error Handling

• If Supabase insert fails, show a toast (shadcn Sonner or Toast) with a human-readable error.
• Do not create the project if the user is not authenticated.

What gets created

• One row in projects table.
• One row in activity_events with event_type = 'project_created'.
• User is redirected to the workspace.

Route: /builder/[projectId]

This is the main screen of the application. It must be a 3-panel layout that mirrors Lovable's builder interface.

Layout

┌──────────────────────────────────────────────────────────────────┐
│  Header: Project Name | 🍍 Balance | [List for Sale] [Get Offer] │
├───────────────┬───────────────────────┬──────────────────────────┤
│               │                       │                          │
│  Left Panel   │   Center Panel        │   Right Panel            │
│  Builder Chat │   UI Preview          │   Business Panel         │
│               │                       │                          │
│  - Chat input │   - iframe / screenshot│  - Valuation            │
│  - Messages   │   - Fallback state     │  - Why Built            │
│  - Tags       │                       │  - Progress Score        │
│               │                       │  - Traction Signals      │
│               │                       │  - Activity Timeline     │
│               │                       │                          │
├───────────────┴───────────────────────┴──────────────────────────┤
│  Pineapple indicator (toast or inline on each prompt)            │
└──────────────────────────────────────────────────────────────────┘

Panel Behavior

• Desktop (≥1280px): All three panels visible side by side. Left panel ~300px, center flexible, right ~360px.
• Tablet (768–1279px): Chat collapses to a slide-out sheet (shadcn Sheet). Center + Right visible.
• Mobile (<768px): Tab-based navigation between Chat, Preview, and Business panels. Use shadcn Tabs.

Header

• Project name (editable inline on click).
• Pineapple balance badge (shows current profiles.pineapple_balance).
• "List for Sale" button — opens listing dialog. Only visible if progress_score >= 20.
• "Get Vamo Offer" button — triggers instant offer. Only visible if progress_score >= 10.

Component: ChatPanel.tsx

This is not a general-purpose chatbot. It is a project-centric update logger that uses AI to:

1. Respond to the user's update/prompt.
2. Extract intent (feature, customer, revenue, ask).
3. Auto-update the business panel on the right.
4. Award pineapples.

UI Requirements

• Message list scrolling to bottom on new messages.
• Each message shows:
  • Role avatar (user or AI).
  • Content text.
  • Tag badge if tagged (feature, customer, revenue, ask) — use shadcn Badge.
  • Timestamp (relative — "2 min ago").
  • Pineapple indicator if pineapples were earned on that prompt.
• Input area at the bottom:
  • Text input (shadcn Textarea, auto-resize).
  • Send button.
  • Optional tag selector (dropdown or button group to pre-tag: Feature, Customer, Revenue, Ask).

Chat Flow (on send)

1. Client: Insert user message into messages table.
2. Client: Call POST /api/chat with:

   {
     "projectId": "uuid",
     "message": "shipped landing page",
     "tag": "feature" // optional, user-selected
   }

3. API Route (/api/chat): a. Load last 20 messages for context. b. Load current project data (name, description, why_built, progress_score). c. Call OpenAI with a system prompt:

   You are Vamo, an AI co-pilot for startup founders. The user is building a project called "{project_name}".
   
   Your job:
   1. Respond helpfully to their update or question (keep it concise, 2-3 sentences max).
   2. Extract the intent of their message. Classify as one of: feature, customer, revenue, ask, general.
   3. If the update implies progress (shipped something, talked to users, made revenue), generate an updated business analysis.
   4. Return your response as JSON:
   {
     "reply": "Your response text",
     "intent": "feature|customer|revenue|ask|general",
     "business_update": {
       "progress_delta": 0-5,          // how many points to add to progress_score
       "traction_signal": "string or null",  // e.g., "3 user interviews completed"
       "valuation_adjustment": "up|down|none"
     }
   }

   d. Parse OpenAI response. e. Insert assistant message into messages with extracted intent. f. Insert activity_event with event_type = 'prompt'. g. Call reward engine: award pineapples for the prompt (see Section 11). h. If business_update has a progress_delta > 0, update projects.progress_score. i. Return full response to client.
4. Client: Append assistant message. Show pineapple toast. Trigger business panel refresh.

Error Handling

• If OpenAI fails, return a fallback message: "I couldn't process that right now. Your update has been saved." Still log the message and award the pineapple.
• If Supabase insert fails, show error toast. Do not lose the user's typed message (keep it in the input).

Component: UIPreview.tsx

Requirements

• If projects.url is set:
  • Render an <iframe> with the URL.
  • Set sandbox="allow-scripts allow-same-origin allow-forms".
  • Show a loading skeleton (shadcn Skeleton) while loading.
  • If the iframe fails to load (e.g., X-Frame-Options), show a fallback:
    • Display projects.screenshot_url if available.
    • Otherwise, show a placeholder card: "Preview unavailable. [Open in new tab ↗]" with a link to the URL.
• If projects.url is not set:
  • Show an empty state: "Link a project URL to see a live preview" with a button to open project settings.
• Load time must be < 3 seconds for the iframe or fallback to appear.

Toolbar (top of center panel)

• Refresh button (reloads iframe).
• "Open in new tab" button.
• Device toggle: Desktop / Tablet / Mobile (adjusts iframe width).

Component: BusinessPanel.tsx

This panel is the core differentiator from Lovable/Replit. It shows business progress, not code.

Sections (top to bottom)

10.1 Valuation Range

• Display projects.valuation_low and projects.valuation_high as a range.
• Format as currency: "$1,000 – $5,000".
• If both are 0 (new project), show "Not yet estimated" with a muted badge.
• This value is updated by the AI after meaningful progress events.

10.2 Why I Built This

• Display projects.why_built text.
• Editable inline (click to edit, shadcn Textarea, save on blur or Enter).
• Max 1000 characters with character counter.

10.3 Progress Score

• Circular or linear progress bar showing projects.progress_score out of 100.
• Color-coded: 0–25 red, 26–50 yellow, 51–75 green, 76–100 blue.
• Label: "Early Stage", "Building", "Traction", "Growth" based on range.

10.4 Traction Signals

• A list of traction signals extracted from chat by the AI.
• Stored in activity_events where event_type in ('feature_shipped', 'customer_added', 'revenue_logged').
• Each signal shows:
  • Icon (based on type).
  • Description text.
  • Timestamp.
• If no signals yet, show empty state: "Start logging progress in the chat to see traction signals here."

10.5 Linked Assets

• Show linked assets (LinkedIn, GitHub, Website).
• Each shows a linked/unlinked state.
• "Link" button opens a dialog to paste URL.
• On link, create an activity_event with appropriate event_type and award pineapples.

10.6 Mini Activity Timeline

• Last 10 activity events for this project (most recent first).
• Each shows: icon, description, relative timestamp.
• "View full timeline" link opens a full-page or modal timeline (see Section 15).

Update Triggers

The business panel must re-fetch and re-render after:

• A chat prompt is sent and response is received.
• A link is added.
• An update event is logged.

Use Supabase Realtime subscriptions or polling (every 5 seconds during active session) to keep the panel fresh.

This is a critical system. It must be event-driven, idempotent, and ledger-based.

Reward Schedule

Implementation

API Route: POST /api/rewards

// Input
{
  "userId": "uuid",
  "projectId": "uuid",
  "eventType": "prompt" | "link_linkedin" | "link_github" | ... ,
  "idempotencyKey": "unique-string"  // e.g., `${messageId}-prompt-reward`
}

// Logic:
// 1. Check if idempotencyKey already exists in reward_ledger. If yes, return existing record (no duplicate).
// 2. Calculate reward amount based on event_type.
// 3. Get current pineapple_balance from profiles.
// 4. Insert into reward_ledger with balance_after = current_balance + reward_amount.
// 5. Update profiles.pineapple_balance += reward_amount.
// 6. Insert activity_event with event_type = 'reward_earned'.
// 7. Return { rewarded: true, amount, newBalance }.

Idempotency

• The idempotency_key column in reward_ledger has a UNIQUE constraint.
• The key format must be deterministic: {source_event_id}-{event_type}.
• If a duplicate key is inserted, the API returns the existing record without modifying the balance.

Anti-Spam

• Rate limit: Max 60 prompts per project per hour. After that, prompts still work but award 0 pineapples.
• Implement this check in the API route by counting recent reward_ledger entries.

Route: /wallet

Wallet UI

Balance Card

• Large display of current pineapple balance.
• "Redeem" button (disabled if balance < minimum threshold, e.g., 50 🍍).
• Use shadcn Card.

Reward History

• Table or list of all reward_ledger entries for the user.
• Columns: Date, Event, Project, Amount, Balance After.
• Sorted by most recent first.
• Paginated (20 per page) using shadcn Table + pagination.

Redemption History

• Table of redemptions for the user.
• Columns: Date, Amount, Reward Type, Status.
• Status badges: Pending (yellow), Fulfilled (green), Failed (red).

Redemption Flow

1. User clicks "Redeem" on wallet page.
2. Dialog opens (shadcn Dialog):
   • Shows current balance.
   • Input for amount to redeem (min 50, max current balance).
   • Reward type selector (currently only "Uber Eats Credit").
   • "Confirm Redemption" button.
3. On confirm, call POST /api/redeem:

   // 1. Verify user has sufficient balance.
   // 2. Deduct from profiles.pineapple_balance.
   // 3. Insert into redemptions with status = 'pending'.
   // 4. Insert into reward_ledger with negative amount.
   // 5. Insert activity_event with event_type = 'reward_redeemed'.
   // 6. Return success.

4. Show success toast: "Redemption submitted! You'll receive your reward within 48 hours."
5. For the MVP, fulfillment is manual — the admin panel shows pending redemptions.

Listing Creation

Triggered from the workspace header "List for Sale" button.

1. Dialog opens with auto-generated listing preview:
   • Title: Pre-filled with project name.
   • Description: AI-generated from project data and activity timeline.
   • Asking Price Range: Pre-filled from projects.valuation_low / valuation_high. Editable.
   • Timeline Snapshot: Frozen copy of current activity_events for this project.
   • Screenshots: Upload area (store in Supabase Storage or as URLs). At least prompt the user to add one.
   • Metrics: Auto-populated from progress_score, number of prompts, number of traction signals.
2. User reviews and edits, then clicks "Publish Listing".
3. On publish:
   • Insert into listings table.
   • Update projects.status to 'listed'.
   • Insert activity_event with event_type = 'listing_created'.
   • Log analytics event.

Marketplace Page (/marketplace)

• Public page (no auth required to view).
• Grid of active listings using shadcn Card.
• Each card shows: title, description excerpt, asking price range, progress score, screenshot thumbnail.
• Click opens detail view (can be a separate page or modal).

Triggered from workspace header "Get Vamo Offer" button.

Flow

1. User clicks "Get Vamo Offer".
2. Client calls POST /api/offer:

   // Input: { projectId }
   // 1. Load project data.
   // 2. Load all activity_events for project.
   // 3. Load message count, traction signal count, links count.
   // 4. Call OpenAI with:
   //    System: "You are a startup valuation engine. Based on the following project data and activity, provide a non-binding offer range and explanation."
   //    User: JSON dump of project data + activity summary.
   //    Expected response:
   //    {
   //      "offer_low": number,
   //      "offer_high": number,
   //      "reasoning": "string explaining the offer",
   //      "signals_used": ["list", "of", "signals"]
   //    }
   // 5. Insert into offers table.
   // 6. Insert activity_event with event_type = 'offer_received'.
   // 7. Return offer to client.

3. Display offer in a dialog:
   • Offer range formatted as currency.
   • Reasoning text.
   • Signals used as a list.
   • Disclaimer: "This is a non-binding estimate based on your logged activity."
   • Buttons: "Dismiss" / "List for Sale" (opens listing flow with offer pre-filled).

Offer must update dynamically

• If the user has received an offer before and makes more progress, the next offer should reflect the new data.
• Old offers are marked as status = 'expired' when a new one is generated.

Accessible from:

• Business Panel (mini timeline, last 10 events).
• Full timeline page/modal (all events).

Requirements

• Immutable: Users cannot edit or delete events. No UPDATE/DELETE RLS policies for non-admins.
• Chronological: Sorted by created_at ascending (oldest first) in full view, descending in mini view.
• Searchable: Full timeline has a search input that filters events by description text.
• Filterable by event_type using shadcn ToggleGroup or filter dropdown.

Timeline Item UI

Each event shows:

• Icon based on event_type (use Lucide icons from shadcn).
• Event description.
• Relative timestamp.
• Metadata (if any) shown as subtle secondary text.

Every significant user action must be tracked in analytics_events.

Track these events:

Implementation

• Create a utility function trackEvent(eventName, properties) in lib/analytics.ts.
• This function inserts directly into analytics_events using the authenticated Supabase client (anon key + user JWT). The RLS policy allows users to insert their own events.
• Call trackEvent from client components after significant actions.
• The admin panel reads these events for reporting (RLS allows admins to SELECT all).

Route: /admin

Gated by profiles.is_admin = true. If the user is not an admin, redirect to /projects.

Sections

17.1 Overview Dashboard

• Total users count.
• Total projects count.
• Total prompts sent (all time).
• Total pineapples earned (all time).
• Total pineapples redeemed (all time).
• Active listings count.

Display these as a grid of shadcn Card components with large numbers.

17.2 Users Table

• List all profiles.
• Columns: Email, Name, Pineapple Balance, Projects Count, Joined Date.
• Click a user to see their projects and activity.

17.3 Pending Redemptions

• Table of redemptions where status = 'pending'.
• Columns: User Email, Amount, Reward Type, Requested Date.
• Action buttons: "Mark Fulfilled" / "Mark Failed".
• These actions update redemptions.status and redemptions.fulfilled_at.

17.4 Analytics

• Simple event log from analytics_events.
• Filterable by event name and date range.
• Show as a table with pagination.

17.5 Projects

• List all projects across all users.
• Columns: Name, Owner, Status, Progress Score, Created Date.
• Click to view project detail.

Implementation Note

All admin operations (viewing all users, updating redemption status, viewing analytics) work through RLS policies that check profiles.is_admin = true. No service role key is needed. The admin's authenticated session + the RLS policies handle authorization. Add the necessary admin RLS policies to each table (SELECT all for admins on profiles, projects, redemptions, analytics_events; UPDATE on redemptions for admins).

Required Loading States

Every async operation must show a loading state:

• Chat: typing indicator / skeleton while waiting for AI response.
• Business panel: skeleton or spinner on refresh.
• UI Preview: skeleton while iframe loads.
• Wallet: skeleton while loading balance and history.
• Forms: button disabled + spinner while submitting.

Use shadcn Skeleton component for loading states. Do not use raw spinners unless contextually appropriate.

The bounty is complete when a brand new user can do ALL of the following without any manual database operations, server restarts, or developer assistance:

• Sign up with email and password.
• Create a new project with a name.
• Enter the builder workspace and see the 3-panel layout.
• Send a chat prompt and receive an AI response within 3 seconds.
• See the prompt appear in the activity timeline.
• See pineapples awarded for the prompt (toast notification + balance update in header).
• Tag a prompt as "Feature" and see the tag badge on the message.
• Link a GitHub URL in the business panel and see pineapples awarded.
• See the progress score update after logging meaningful progress.
• See traction signals appear in the business panel.
• Edit the "Why I Built This" field in the business panel.
• View the UI preview (iframe or fallback) if a URL is set.
• Navigate to the wallet page and see correct pineapple balance.
• See reward history with all earned pineapples.
• Submit a redemption request (if balance ≥ 50).
• Click "Get Vamo Offer" and see an AI-generated offer with reasoning.
• Click "List for Sale" and publish a marketplace listing.
• View the public marketplace page and see the listing.
• Log in as admin and see the admin dashboard with correct counts.
• See pending redemptions in the admin panel.
• Mark a redemption as fulfilled in the admin panel.
• All pages are responsive (mobile, tablet, desktop).
• No console errors in production build.
• All RLS policies work correctly (user A cannot see user B's data).

You must address these. Failure on any of them invalidates the build.

20.1 Pineapple Spam

• Risk: User sends 1000 prompts in a loop to farm pineapples.
• Mitigation: Rate limit of 60 rewarded prompts per project per hour. After 60, prompts work but award 0 pineapples. Enforce in /api/rewards.

20.2 Reward Abuse

• Risk: Duplicate rewards for the same event.
• Mitigation: idempotency_key UNIQUE constraint on reward_ledger. The API must check for existing key before inserting.

20.3 Hallucinated Analysis

• Risk: AI generates nonsensical business analysis or inflated valuations.
• Mitigation: Constrain OpenAI prompts. Progress delta max is 5 per prompt. Valuation must be based on logged signals only. Include "If insufficient data, say so" in system prompts.

20.4 Valuation Credibility

• Risk: Valuations look absurd to users.
• Mitigation: Always display as a range. Always show reasoning. Include a disclaimer: "Estimates based on logged activity only."

20.5 Timeline Integrity

• Risk: Users or bugs modify historical activity events.
• Mitigation: No UPDATE or DELETE RLS policies on activity_events for regular users. Append-only design.

20.6 Balance Integrity

• Risk: Balance goes negative or gets out of sync with ledger.
• Mitigation: Redemption API must check balance before deducting. Use a transaction (or Supabase RPC) to atomically deduct balance and insert ledger entry. The balance_after field in reward_ledger provides an audit trail.

When you submit, provide:

1. GitHub repo (public or invite us) with clean commit history.
2. Deployed preview URL on Vercel.
3. .env.local.example with all required environment variables documented.
4. README.md with:
   • Setup instructions (clone, install, env, run).
   • Supabase setup instructions (how to run migrations, enable RLS, create trigger).
   • How to set yourself as admin (manually set is_admin = true in Supabase dashboard).
   • Confirmation that no service role key is used anywhere in the codebase.
   • Any known limitations.
5. Demo video (3-5 min) walking through the full acceptance test from Section 19.

Contact Bolun!