sapna jha

MemoryVerse AI '26

## Setup Steps 1. Clone the repo and run `npm install` 2. Create a `.env.local` file with: - NEXT_PUBLIC_SUPABASE_URL=<your_supabase_url> - NEXT_PUBLIC_SUPABASE_ANON_KEY=<your_anon_key> 3. In Supabase SQL Editor, run the schema migrations for: documents, entities, relationships, timeline_events tables 4. Create a Supabase Storage bucket named `documents` 5. Run `npm run dev` → open http://localhost:3000 ## Test Credentials - Sign up with any valid email via the /login page - No pre-seeded test account required — Supabase Auth handles registration ## Design Decisions - Next.js 14 App Router used for layout nesting and server components - Supabase chosen as full BaaS (Auth + PostgreSQL + Storage) to avoid separate backend - ReactFlow powers the knowledge graph (entities & relationships) - Row Level Security (RLS) enforced on all tables — users only see their own data - Framer Motion used for page transitions and micro-animations - Optional FastAPI Python backend available for heavier AI processing (OpenAI integration) ## Known Limitations - AI processing is simulated on the frontend if no Edge Function is deployed - Storage bucket must be manually created in Supabase dashboard

Queue Cure '26 — Real-Time Clinic Token Queue

76% of India's 1.5 million clinics still run queues on paper slips and shouting across the room. Patients sit for 2-3 hours with zero idea when they'll be called. Receptionists track everything from memory, and doctors have no visibility into how the queue is moving. I wanted to fix the literal object causing the chaos — the paper token slip — by replacing it with two screens that talk to each other in real time, not a generic "queue app." I decided early what NOT to build — no login, no database, no multi-clinic support — so the actual ask, two screens staying in sync, stayed sharp. I picked Socket.io over Supabase Realtime because this hackathon explicitly asks for a socket event diagram, and I wanted the events to be the architecture, not hidden behind someone else's platform. What didn't work first try: I linked the two screens with React Router inside one browser tab. That reused the same socket connection, so the second screen never got the server's initial data push and just sat empty, even though the first screen already had real patients. Fix: every screen now asks the server for current state the moment it mounts, instead of relying on a one-time push at connection. Both screens update the instant "Call Next" is clicked — no refresh, no polling. Wait time isn't hardcoded: it's tokens-ahead times the receptionist's own average-consult-time input, recalculated live. The receptionist screen disables "Call Next" while a request is in flight and "Issue Token" until a name is typed, so accidental double-clicks can't skip a patient or submit empty data. If I had more time, I'd add a printable/QR token slip, a WhatsApp ping when a patient is two tokens away, and basic persistence so the queue survives a server restart instead of resetting. I'd add a printable or QR token slip so patients don't have to remember their number, plus a WhatsApp ping when someone is two tokens away so they can step outside instead of sitting in the waiting room. I'd also add basic persistence so the queue survives a server restart instead of resetting — fine for a one-week MVP, but the first real gap if this went beyond a demo.

Queue Cure '26 — Real-Time Clinic Token Queue

Replaces paper token slips with two screens that sync instantly — zero refreshes, wait time calculated live from the real queue, not hardcoded.

1→2Screens synced per event