My Github Profile · Agniv Dutta

I built Beyond-the-Crease, a TypeScript, frontend-only React prototype for the ICC Global Hackathon, Track 1 — Sport Visibility & Engagement. Its product framing is “Every match has a story. Not every story gets heard.” It combines AI-style storytelling, a visibility-parity tracker, and inclusive multilingual fan communities; the scope is cricket-first and cross-sport ready. The repository description says it started in 2026-10 and was last updated in 2026-10.

The demo runs entirely in the browser with mock data: it has no backend, API keys, or external AI service. All athletes, teams, statistics, quotations, and events are fictional. Its product features include story creation and fairness tools, parity analytics, athlete and match views, moderated fan circles, accessibility settings, partner information, developer tools, and design previews. The supplied project context describes seeded story generation and fairness checks as reproducible review aids, not real AI or proof of fairness; it also describes MSW and in-process transports simulating 300–900 ms latency and a 5% failure rate.

I organize Beyond-the-Crease under src/ into API, components, data, hooks, internationalization, mocks, pages, store, styles, types, webhooks, and utilities. src/api/resolvers.ts is the single source of truth for endpoint behavior; MSW handlers are generated from its route table, so the app makes real fetch calls and receives real status codes. If the service worker is unavailable, src/api/client.ts calls the resolver directly. Both transports simulate 300–900 ms latency and a 5% failure rate so loading, empty, and error states can be exercised on every screen. Moving to a real backend means removing the MSW layer and pointing the client at the backend host, without changing pages or components.

I use four webhook event types for the live surface: match.moment, story.published, circle.message, and milestone.reached. User actions and simulations on /live and the home ticker emit events, and /dev logs each delivery’s latency and outcome. In the Studio, checkFairness scores body copy on every keystroke and flags diminishing phrasing; applyFairnessFixes can rewrite flagged phrases so the copy describes the work rather than the body. The same fairness function scores the 40 hand-written stories. I treat this as a prompt to review copy before shipping, not proof of fairness. The seeded generator produces the same draft for identical inputs, making demos reproducible without calling an external model.

I call the visual system Mithai Dusk: an Indian sweet-shop counter at golden hour, with pistachio barfi, rose sweets, saffron, and silver varq against deep aubergine dusk. Tokens live in tailwind.config.js and CSS variables; components do not hardcode hex values. The /design reference reads stylesheet values with getComputedStyle so it stays aligned with the implementation. I use Fraunces for display, Bricolage Grotesque for body text, and Atkinson Hyperlegible as the dyslexia-friendly fallback. Motifs include scalloped card edges, jaali lattice, paper grain, sticker badges, silver hairlines, and dusk-fruit and barfi-glow gradients. The approximate color balance is 60% kulfi or aubergine, 30% rose and mulberry, and 10% pomelo, kesar, and pistachio. I use aubergine text on pomelo and kesar buttons because cream on gold fails AA. Kulfi Cream and Aubergine Dusk are both contrast-checked themes.

I designed for WCAG AA contrast in both themes; /access shows the computed ratio for the current pairing. Controls are keyboard-reachable and operable with a visible focus ring. Accessibility features include a skip link, landmarks, aria-live announcements for toasts and live updates, labelled toggles, and pressed states on toggle buttons. The app supports six languages, including Arabic with RTL layout, plus per-story translations in circle threads. Preferences include text scaling up to 140%, a dyslexia-friendly font, high contrast, reduced motion, and low-data mode, which drops animations and simplifies charts to tables. The parity chart also has a table fallback and no-animation mode. Loading, empty, and error states are present throughout.

I keep all Beyond-the-Crease demo content invented. The dataset contains 24 cricketers, 12 matches, 40 hand-written stories, eight fan circles, and a deterministic 24-month visibility dataset. Football, tennis, hockey, and athletics data are generated from shared shapes. Visibility figures are illustrative, not derived from real broadcast, sponsor, or social datasets; team crests, athlete portraits, and venue imagery are abstract motifs, not likenesses or logos. The project’s tagline and hashtag are #BeyondTheCrease.

The README route inventory includes / (The Pavilion Gate landing page, with hero, gate transition, live ticker, and parity teaser); /today (story feed, filters, pagination, and scouting badges); /live (live and completed matches, ball-by-ball moments, and webhook-driven ticker); /match/:id (score, win probability, timeline, and related stories); /athletes and /athlete/:id (search and filters across 24 cricketers, career arcs, statistics, follow, and alerts); /studio (template story generator, fairness scoring, fixes, drafts, publishing, and PNG share card); /parity (broadcast, mention, clip, and sponsor shares, charts, regional heat, projection, and CSV); /circles and /circle/:id (eight moderated fan rooms and threaded chat features); /access (accessibility settings and moderation and fairness logs); /story/:id (story, translations, fairness explainer, and report action); /about (product thesis, dataset, and fairness-engine explanation); /partners (three partnership tracks and demo enquiry form); /dev (API routes, webhook simulation, fairness rules, and persisted-store controls); /design (Mithai Dusk design previews); and * (accessible 404 page). The README table has 20 route entries counting the wildcard; the supplied route descriptions do not account for every entry. The broader project context describes a dataset of 24 cricketers, 12 matches, and 40 stories; six supported languages, including Arabic RTL; a 24-month parity teaser; and text scaling up to 140%.

I built “The Pavilion Gate” as the light, lazily loaded marketing page at /, implemented in src/pages/Landing.tsx and src/features/landing/. The former Home moved to /today, and navigation items, logo links, breadcrumbs, command-palette entries, and 404 suggestions follow the new route. The landing page applies data-theme="dusk" on mount and restores the visitor’s saved theme on unmount without changing the stored preference. It is a single route-level lazy chunk of about 8 kB gzip, with no video or new libraries; it uses React, framer-motion, and react-i18next already shipped by the app.

I structure the page as Hero → live ticker → visibility gap → how it works → tone playground → parity teaser → circles & languages → cross-sport picker → final CTA. The ticker is a pausable, reduced-motion-aware marquee; the visibility gap uses paired bars and a count-up; the four-tone playground includes a fairness fix; and the parity teaser shows 24-month SVG lines and a gap-closer slider. Circles & languages provides join buttons and a six-language grid that re-renders the page live, while the cross-sport picker swaps the story feed per sport. Every control navigates, mutates a store, opens a modal, or calls the mock API, and the primary CTA leads to /today.

Choosing “Enter the Pavilion” closes two aubergine doors over the page, flips prefs.hasEntered, restores the theme, and opens the doors again over /today. The transition includes an aria-live announcement, prefetches the Today bundle on hover or focus, and uses a fade-only path under prefers-reduced-motion. The ticker, gap, parity, and circles sections use the same API layer, backed by MSW now with real endpoints planned later; their loading, empty, and error states are genuine. The hero offers “Skip the intro next time,” and /access can re-enable the landing page. Sport chips pre-seed onboarding, so onboarding skips its sport-selection step.

I mapped the landing page to Track 1 through visibility-gap bars, parity lines, and KPIs (with a demo-data note); fan engagement through the ticker, tone playground, join buttons, and CTAs into Studio, Parity, and Circles; and inclusive community through moderated-circle cards, access mentions, and a six-language grid including Arabic RTL. Storytelling uses a headline-to-feed narrative, per-sport story previews, and a 60-second tour modal. The craft and access goals include a curtain entrance that settles static, WCAG AA dusk contrast, keyboard support, and reduced-motion support. The parity teaser spans 24 months, the tone playground offers four tones, and the language grid covers six languages.

npm install
npm run dev        # start the Vite dev server
npm run build      # typecheck and production build
npm run typecheck  # tsc --noEmit
npm run lint       # ESLint, zero warnings allowed
npm run preview    # serve the production build

I treat the listed AI-style and fairness features as prototype functionality, not evidence of an external AI service or validated fairness: the supplied material does not specify the fairness formula, the data behind parity measures, or the implementation details of webhooks and machine translation. It gives no live deployment URL, API contract, named athletes or teams, or real-world performance and usage results.

I organize Musafir around a Python backend and a TypeScript frontend. The backend has a LangGraph-orchestrated ReAct agent in agent_core.py, a FastAPI application in server.py, and a tools/ package for budget estimation, calendar events, currency conversion, destination information, meal planning, itinerary generation, web search, transport pricing, and weather forecasting.

My frontend structure includes a typed travel API client, home and planner pages, a trip-planning hook, shared layout and UI components, and planner views for itineraries, weather, currency, destinations, agent traces, budgets, calendars, transport prices, and weather warnings. The project uses Vite and Tailwind configuration.

I set up the project with Python 3.11 or higher, Node.js 18 or higher, npm or yarn, and API keys for Groq and ExchangeRate-API. The documented ExchangeRate-API free tier allows 1500 calls/month. I create and activate a .venv for backend dependencies, install from backend/requirements.txt, and run npm install from frontend/. The root-level requirements.txt is described as optional.

python -m venv .venv
.\.venv\Scripts\Activate.ps1
source .venv/bin/activate
pip install -r backend/requirements.txt

# Root .env
GROQ_API_KEY=your_groq_api_key_here
EXCHANGE_RATE_API_KEY=your_exchange_rate_api_key_here

cd frontend
npm install

I can optionally create a frontend .env; the setup instructions say the defaults work and suggest copying from .env.example if needed. The setup documents instructions only, not a completed installation, test result, or runtime outcome.

I use GitHub as a portfolio for projects across AI/ML, fintech, analytics, civic and community tools, travel, health insurance, developer tooling, and consumer applications. My profile is @agniv-dutta; I am based in Mumbai, have been on GitHub since 2024, and the captured profile showed 12 followers. My bio reads, “Your average tech enthusiast and an insatiable hunger to learn everyday.” These repository descriptions, performance figures, and update dates are profile-provided claims, not independently verified; the capture date is unspecified.

Travel and general-purpose AI: Musafir is a Python and React travel-planning agent using LangChain and Groq AI for destination research, weather forecasts, currency conversion, and itinerary generation, with Nominatim, OpenMeteo, RestCountries, and ExchangeRate APIs. It showed 1 star and 1 fork and was last updated 2026-04. DataPilot lets people upload CSVs and ask questions in plain English; it returns answers, SQL/Pandas code, charts, anomaly detection, and explanations using FastAPI, DuckDB, LLM tool calling, a sandboxed executor, React, Tailwind, and Docker (2026-10). MechMind-AI applies OCR, document and diagram understanding, hybrid RAG, knowledge graphs, and citation-backed answers to industrial troubleshooting (2026-09). Energem combines agentic AI, RAG, scenario modelling, geopolitical signals, maritime tracking, and commodity intelligence to forecast Indian energy-supply disruption and recommend procurement strategies; its examples include Hormuz closure, sanctions, and shipping attacks (2026-07). LiveCoach uses Gemini Live API to coach interview and pitch answers on clarity, examples, and impact (2026-07).

I describe DataPilot in its README as an AI Data Analyst: people upload one or more CSVs and ask questions in natural language. The agent inspects schemas, generates SQL or pandas, executes it in a hardened sandbox, and streams answers, tables, charts, and anomaly highlights to the browser. It supports bar, line, area, pie, scatter, and histogram charts rendered with Recharts and exportable to PNG; anomaly detection uses z-score, IQR, or IsolationForest, and the Inspector reports per-column statistics, a quality score, and summaries of nulls, duplicates, and outliers. Related CSVs can be joined and queried together with DuckDB.

I describe the architecture as a React 18, Vite, strict-TypeScript SPA using Tailwind CSS, Recharts, and TanStack Query, communicating with a FastAPI backend over REST and Server-Sent Events under /api. Backend layers run from api/ routes to services/ business logic to core/ configuration, LLM access, and sandboxing. A SessionStore holds datasets, history, and cache; an AnalystAgent runs a Groq-backed tool-calling loop. The backend stack includes Python 3.11, pandas, DuckDB, Pydantic v2, sqlglot, and scikit-learn. LLM access goes through a provider interface in core/llm.py, with openai/gpt-oss-120b as the documented default model.

I document several deliberate safety boundaries. Each session uses a read-only DuckDB connection with uploaded DataFrames registered as views, and the connection does not expose the filesystem. sqlglot validation permits only a single SELECT or WITH query, rejecting DDL/DML, PRAGMA, COPY, ATTACH, INSTALL, LOAD, and file-reading table functions. The pandas runner parses snippets, rejects imports, dunders, open/exec/eval, and filesystem-accessing pandas attributes, then runs accepted code in a spawned worker with a wall-clock timeout. Generated SQL and pandas are validated and run with time and row limits; failures are returned to the agent for self-correction. API keys come from environment variables and are not logged or committed. Identical SQL within a session is served from an LRU cache.

I document Server-Sent Events for status updates, tool calls, charts, anomaly results, final answers, and errors. Because browser EventSource cannot POST, the client uses fetch to stream and parse event:/data: frames; a synchronous JSON chat endpoint is also available. The API includes health, session creation and deletion, CSV upload and removal, dataset listing, Inspector reports, streaming chat, and synchronous chat routes. The README reports 80 backend tests and describes CI on every push and pull request, running backend ruff, mypy, and pytest alongside frontend eslint and a production build.

I record these documented defaults and sample-data details:

# Docker Compose, from a clean clone
 docker compose up --build
# Frontend: http://localhost:3000; API: http://localhost:8000
curl http://localhost:8000/api/health
curl -I http://localhost:3000/
docker compose down

# One-command development, from the repository root
node scripts/dev.mjs  # or: make dev

# Backend tests and checks, from backend/
python -m pytest
ruff check . && mypy app
ruff format .

# Frontend checks, from frontend/
npm run lint
npm run build

# Run the six README evaluation prompts against a running API
make eval

I note that Docker Compose uses backend/.env.example so the stack can start without credentials; adding a real GROQ_API_KEY to backend/.env enables live analysis, and Compose loads that optional file after the example so its values override defaults. The Docker frontend and API use ports 3000 and 8000; the development backend and frontend use 8000 and 5173, and local preview uses 4173. For a deployed frontend, I can serve frontend/dist behind a static host and point /api at the backend, setting VITE_API_URL only when the API is on another origin.

I record the README's limitations: sessions and rate limiting are in-memory and per-process, with no persistence or cross-worker sharing, so the session store is described as suitable for a demo rather than multi-node scale. CSV is the only supported format; Excel and Parquet are possible next steps. Complex questions may need to be split because of the tool-loop limit. The README leaves screenshots, a demo video, and a deployed live-demo link as placeholders and specifies no performance benchmarks, production deployment provider, or persistence strategy.

SQL and pandas execution timeouts are 10 seconds each; query results are capped at 10000 rows, while LLM-facing query results retain 50 rows.
Each uploaded file is capped at 26214400 bytes (25 MB); the in-memory per-IP rate limit is 60 requests per minute.
An agent tool-calling loop is capped at 6 iterations. A session can contain up to 20 files; profiling is capped at 200000 rows per dataset and schema samples contain 5 rows.
The session query cache holds 128 entries; the memory token budget is 8000, the LLM-facing tool-result budget is 6000 characters, and maximum generated tokens are 4096.
The shipped related sample CSVs are sales.csv with 2000 rows and seeded anomalies, customers.csv, and products.csv. The README suggests questions about regional and monthly revenue, top customers, anomalies, customer tiers, and product margins.

I built Musafir as a travel-planning agent that uses LangGraph ReAct and Groq LLaMA 3.1 (llama-3.1-8b-instant) to analyze travel preferences, destination context, and real-time data. It generates personalized itineraries, dynamic budgets, weather guidance, and transport recommendations, including multi-destination routes and stopovers. It incorporates dietary restrictions and other preferences throughout planning, and adapts meal suggestions to travel styles such as cultural, beach, nightlife, shopping, and adventure trips.

Musafir includes per-day meal suggestions, regional specialties, themed meal costs, and cuisine suggestions covering 7+ countries. Its destination research covers cultural tips, local food, attractions, and geography; weather features include 7-day forecasts, alerts, and recommendations. It converts budgets between currency pairs using live exchange rates and estimates expenses for flights, accommodation, food, activities, and transport. It also compares flight, train, and bus prices across providers and exports itineraries as .ics calendar files.

The interface is described as mobile-optimized, with a dark theme and glassmorphism styling, and includes a step-by-step ReAct reasoning trace. When APIs are rate-limited, a fallback is described as dynamically synthesizing a context-aware itinerary from actual trip details rather than templates; the README does not explain how that fallback is implemented. The backend stack includes FastAPI, LangChain, LangGraph, Groq, Python Requests, iCalendar, and Python-dotenv. The frontend uses React 18, TypeScript 5.5, Tailwind CSS 3.4, Vite 5.4, React Router v6, Axios, Framer Motion, React Big Calendar, Lucide React, Recharts, and Date-fns.

The README lists Groq API, ExchangeRate-API, Open-Meteo, Travelpayouts, Nominatim (OpenStreetMap), REST Countries API, and DuckDuckGo Search as external services for inference, currency conversion, weather, transport pricing, geocoding, country metadata, and web search. The repository is listed as Python, with 1 star and 1 fork, and a start date and last-updated date of 2026-04. These are README and repository-description claims; the captured material does not report measured itinerary quality, forecast accuracy, performance, or user adoption. The project lists Agniv Dutta, Aditya Choudhuri, Aaryan Dubey, and Aditya Pratap Singh as contributors.

Prediction, analytics, and organizational tools: I built ElasticMind as an ML-driven cloud resource manager using LightGBM P50/P90 forecasts, a predictive autoscaling controller with reactive fallback, and evaluation of accuracy, utilization, latency, cost, and energy; its stack includes FastAPI, React, SQLite, Docker, and Terraform for deployment to AWS ECS Fargate (2026-10). PetroPulseAI combines XGBoost/LSTM production forecasting, Isolation Forest anomaly detection, and SHAP explainability to prioritize hydrocarbon asset interventions (2026-08). Compass uses ensemble ML and explainable AI to forecast six-month aluminum and PVC raw-material cost trends for pharmaceutical procurement (2026-08). ToolProbe analyzes 100+ apps for authentication, API surface, self-service access, and agent-integration buildability; it groups patterns and includes human verification and accuracy tracking in an interactive HTML report (2026-08). Cortex ingests meetings, playbooks, and vendor data to produce organizational decision briefs; its description claims an 80% reduction in decision latency across portfolio companies (2026-08). LMS-AutoGrader uses LightGBM for code-quality prediction and a text classifier with confidence thresholds for student-query triage, with cross-validation, class-imbalance handling, and an optional inference API (2026-08). FlowmapDash tracks e-commerce sessions, clicks, and user journeys with a React/TypeScript frontend and Flask/MongoDB backend; it is described as production-ready (2026-06). NOVA centralizes organizational vitality dashboards, employee insights, sentiment analysis, and risk indicators with Vite, React, TypeScript, Tailwind, and shadcn-ui; it showed 2 forks (2026-04). FinPulse is a FastAPI/Python NSE stock dashboard with 52W highs and lows, daily returns, seven-day moving averages, volatility scores, ML price predictions, and market, analytics, and comparison views (2026-04).
Finance, lending, and insurance: FinSaathi is a Claude- and Groq-powered health-insurance claims assistant for policy questions, coverage verification, eligibility checks, and claim tracking. It is a frontend prototype with no backend dependencies and was submitted to a Paytm Fintech hackathon (2026-09). Samajh is an open-source, frontend-only Indian-loan self-assessment copilot: with no bureau pull and no login, it asks about 10 questions and returns rate bands, eligibility ceilings, EMI limits, and a lender negotiation card (2026-09). 1fi-marketplace is a React/TypeScript, Tailwind, and Vite storefront for shopping with mutual-fund-backed buy-now-pay-later, including product comparison and no-cost EMI plans (2026-09). Drishti is an open-source, Razorpay-agnostic Indian fintech revenue-recovery agent that orchestrates retry, SMS, call, offer, and escalation; its description claims 55–70% recovery of failed payments and mentions LLM strategy selection, AutoML risk scoring, and audit compliance (2026-09). AnchorFi assesses DeFi insurance risk from an Ethereum contract address or protocol name and returns a risk score, plain-English explanation, and premium estimate using Groq AI, Etherscan, GoPlus Security, and DefiLlama (2026-04). ClearCredit uses interpretable decision-tree rules, imbalance handling, ROC-AUC evaluation, depth analysis, and EDA for credit-card-default prediction (2026-04). VaulTex is a TypeScript/Express finance-data API with JWT authentication, role-based access, SQLite/Prisma, soft deletes, analytics, validation, rate limiting, tests, and seed data (2026-04).

I describe FinSaathi as an AI health-insurance claims assistant and a Paytm Build for India Hackathon submission on my GitHub. It aims to make claims transparent, fair, and fast for India’s 50M+ health-insurance policyholders. The repository is JavaScript, started and was last updated in 2026-09, and is a full frontend prototype with no backend dependencies. An initial project summary says it was built with Claude and Groq; the README identifies Groq API as the LLM backbone, using openai/gpt-oss-120b, and does not clarify Claude’s role.

I describe nine integrated tools: upload and AI intake of policy PDFs; plain-language coverage, deductible, copay, and exclusions breakdown; policy-question chat; line-item hospital-bill analysis against policy terms; a document checklist; human-escalation guidance; pre-authorization estimates of out-of-pocket costs; claim-status tracking with timelines and notifications; and side-by-side policy comparison before renewal. The README also describes Network Hospital Intelligence that checks whether both a hospital and department are in-network, deduction explanations with appeal strategies and success rates, and financial justification for upgrade decisions. It says Groq structured JSON responses power all nine features.

The README frames document checking as a way to prevent delays, pre-authorization as a way to avoid surprise bills, and policy comparison as support for upgrade decisions. It cites IRDA 2024 for 82% of claim delays being due to missing documents, Bimahub for 65% of policyholders renewing without comparing policies, an industry average settlement time of 45+ days, and unexpected deductions in 60% of claims. The README also claims the compliance checker prevents 82% of claim delays; the captured material gives no methodology or independent validation for that claim or the cited figures.

I document a React and Tailwind CSS frontend, a Groq client in lib/groqClient.js with nine specialized functions, and no backend dependencies. components/ClaimBot.jsx orchestrates the flow; components/steps/ contains Step1Upload.jsx through Step9PolicyComparison.jsx. The README calls out Network Hospital Intelligence in Step2Breakdown.jsx, the Deduction Explainer in Step4ClaimAnalysis.jsx, and the Document Compliance Checker in Step5Documents.jsx. data/samplePolicies.js contains HDFC policy, claim-item, document, and settlement data. The README says design specs are in gitignored docs/.

The sample demo policy names HDFC Health Insurance and policyholder Raj Kumar, with Rs.5,00,000 sum insured, Rs.10,000 deductible, and 20% copay. The captured description does not establish whether policy parsing, claim-status tracking, or settlement data is connected to live services; the repository description identifies a frontend prototype and sample policy data.

git clone https://github.com/agniv-dutta/FinSaathi.git
cd finsaathi/frontend
npm install
echo "REACT_APP_GROQ_API_KEY=your_key_here" > .env.local
npm start

# Visit http://localhost:3000, click "Try Demo Policy", and explore all 9 steps.
# Get a free Groq API key at https://console.groq.com/keys

Civic, community, events, and consumer applications: Beyond-the-Crease is a frontend-only React demo with mock data for AI-assisted women’s-cricket storytelling, visibility parity, and multilingual fan communities; it was built for ICC Global Hackathon Track 1 (2026-10). Awaaz aggregates NGO field reports into a needs dashboard and uses AI matching to dispatch volunteers in Mumbai wards; it was built for Google Solution Challenge 2026 (2026-07). RoadSoS provides emergency road assistance through multilingual XLM-RoBERTa + CRF triage, CAP v1.2 alerts, geolocation dispatch, and an offline-first PWA; it was built for IIT Madras Road Safety Hackathon 2026 using FastAPI, React, and Leaflet (2026-05). Relaxena is a FastAPI/Next.js 14 sporting-event platform with crowd tracking, virtual queues, a Groq/Llama3 assistant, live scores, and personalized navigation (2026-04). MoodMeal is a React/FastAPI emotion-first recipe generator using Oxlo AI, with a dark visual design and Cormorant Garamond typography (2026-04). Followbaze is a TypeScript CRM for leads, conversations, pipeline organization, discussion histories, and follow-up scheduling (2026-10).

For my Followbaze demo, I show a status change, close and reopen the lead, and confirm the status persisted; I also show one overdue follow-up and one due today in their section. I can capture the full dashboard, overdue section, timeline dialog, add-lead dialog, API docs at /docs, and passing test output. The repository has no screenshots, video, public URL, or test results fabricated as evidence; these are items to capture, not existing evidence. I exercise the combined status filter (All + 6) and case-insensitive name search, verify inline status persistence through PATCH /leads/{id}, and check follow-up classification against the timezone implementation and tests.

My 17-item demo checklist maps evaluation requirements to implementation locations:

Single-screen app; lead opens in a dialog without a route change — features/leads/LeadDashboard.tsx, ui/Modal.tsx.
Dashboard shows name, company, status badge, latest note, relative time, and follow-up — features/leads/LeadRow.tsx.
Due-today section derives from persisted data — features/leads/FollowUpSection.tsx.
Overdue follow-ups are prominent in red — components/ui/FollowUpIndicator.tsx.
Pinned leads are not duplicated in the main list — LeadDashboard.tsx (rest excludes pinned).
Status filter (All + 6) and case-insensitive name search work together — features/leads/FilterBar.tsx, useLeads.ts.
Loading, empty, no-results, and API-error states — components/ui/Feedback.tsx.
Timeline dialog has newest-first history, a composer, and optional follow-up — features/leads/LeadTimelineDialog.tsx.
Discussion and follow-up updates are atomic and preserve an existing reminder — backend/app/services/discussion_service.py.
Inline status update is persisted and reflected — LeadTimelineDialog.tsx, PATCH /leads/{id}.
Add-lead dialog has client and server validation and no false success — features/leads/AddLeadDialog.tsx.
Follow-up classification is timezone-correct and testable — backend/app/core/timezone.py, frontend/src/lib/followUp.ts.
REST API contract, error envelopes, CORS, and docs — backend/app/api/**, /docs.
Migrations, indexes, and foreign-key integrity — backend/alembic/**, backend/app/models/__init__.py.
Deterministic, idempotent seed covers all cases — backend/scripts/seed.py.
Backend, frontend, and end-to-end tests — backend/tests, frontend/src/**/*.test.tsx, frontend/e2e.
Docker Compose, .env.example, persistent SQLite, and health checks — docker-compose.yml, .env.example.

I built Followbaze, a lightweight CRM for sales representatives, as a Pravar AI full-stack assessment. It is a TypeScript repository on my GitHub, started and last updated in 2026-10. The app uses FastAPI and Next.js, runs locally without external services, and has no LLM or third-party dependency; I used AI only as a development aid. I use it to manage leads, track discussions, update pipeline status, and schedule follow-ups from a single-screen dashboard.

I organize the dashboard into mutually exclusive Overdue, Due today, Upcoming, and Unscheduled follow-up groups, with overdue items highlighted in red. Overdue means the scheduled instant is strictly before now; Due today uses the app timezone’s local calendar day and excludes past appointments. Timestamps are stored and exchanged in UTC, then displayed in the configured timezone, which defaults to Asia/Kolkata. The six pipeline statuses are New, Contacted, Qualified, Proposal Sent, Won, and Lost; changing a lead to Won or Lost does not clear its scheduled follow-up. Overdue and Due-today sections are pinned and excluded from the main list; pinned leads sort by soonest follow-up, while the main list sorts by most recently updated, with id as a deterministic tiebreaker. Search and status filters work together and also filter pinned sections. Selecting a lead opens an accessible dialog with its newest-first discussion timeline, note composer, optional next follow-up, and inline status changes. Adding a discussion and updating its follow-up is atomic, and a note without a new follow-up preserves the existing reminder.

I built the frontend with Next.js 15 (App Router), React 19, TypeScript, and Tailwind CSS 3, using reusable components, a centralized typed API client, and portal-based dialogs. The FastAPI backend uses Pydantic v2, SQLAlchemy 2.0, and Alembic; HTTP routers call services for business logic and persistence, which use the models. Presentation components are separated from API calls and follow-up/date logic. SQLite is the development default, while the models support SQLAlchemy database URLs; the custom UTCDateTime type normalizes values to UTC on write and reattaches UTC on read. Alembic migrations remain the schema source of truth, including in Docker and CI. The backend includes validation, consistent error envelopes, CORS, centralized error handling, and N+1-free lead-list queries. It has no authentication, which I intentionally omitted to protect the core workflow.

I test the backend with pytest and TestClient, the frontend with Vitest and Testing Library, and the end-to-end flow with Playwright against a real API and an isolated e2e.db rather than mocks. The seed script creates exactly 6 leads covering every status, a lead with no discussions, one with multiple discussions, and follow-ups due today, overdue, in the future, and unscheduled. Seed dates are relative to run time; seeding is idempotent unless I use --reset, which deletes all leads before reseeding. Docker Compose persists SQLite in the followbaze-data volume, applies migrations when the backend starts, and waits for backend health before starting the frontend. For production, the README recommends setting DATABASE_URL to Postgres and running migrations; it does not provide deployment results, test pass counts, or performance measurements.

# Local backend setup, from the repository root
cd backend
python -m venv .venv
# Activate the virtual environment and install requirements.txt
alembic upgrade head
python -m scripts.seed
uvicorn app.main:app --reload --port 8000

# In another terminal
cd frontend
npm install
npm run dev

# Docker alternative, from the repository root
docker compose up --build

# Seed demo data in Docker
docker compose exec backend python -m scripts.seed

# Migrations
alembic revision --autogenerate -m "message"
alembic downgrade -1

# Tests and frontend checks
.\.venv\Scripts\python.exe -m pytest
npm run test
npm run typecheck
npm run lint
npm run build
npm run e2e

Developer tools, operations, messaging, and data workflows: StreakKeeper is a React/FastAPI/SQLite habit tracker for daily check-ins, consecutive-day streaks, and missed-date backfilling. Its description calls out DST, multiple timezones, edge cases, tests, Docker, and comprehensive documentation (2026-08). hobbyfi-copilot combines a FastAPI and Groq (llama-3.3-70b) backend with a Next.js/React frontend for query classification, tool calls, approval workflows, WebSocket updates, and a dashboard; its dark theme uses #1FD85D green on black (2026-07). Vigil is a containerized FastAPI/MediaPipe/PostgreSQL face-detection API that streams annotated video over WebSockets, stores ROI bounding boxes, and serves a React dashboard, with zero OpenCV dependencies (2026-07). Whispr is a Signal Messenger clone using Next.js/TypeScript, FastAPI, SQLite, and WebSockets for one-to-one and group chats, delivery receipts, and typing indicators; it was a fullstack SDE assignment (2026-06). Veridian ingests SAP IDoc, utility CSV, and corporate-travel data into normalized, scope-tagged carbon records; it is multi-tenant and audit-trailed, with analyst review before emissions data is locked for auditors (2026-05). ledger-lens reconciles user and exchange crypto CSVs using configurable matching tolerance and exposes audit-ready reports through a Node.js/MongoDB REST API (2026-05). leadflow-api is a FastAPI/SQLAlchemy/SQLite lead-management API with status filters, lifecycle updates, Pydantic v2 validation, and duplicate detection; it was built as a backend internship assessment (2026-05). Parcour normalizes guest messages from WhatsApp, Airbnb, Booking.com, and other channels, classifies intent, and drafts Claude replies with confidence scoring and escalation for luxury-villa rentals (2026-05).
Other portfolio entries and ML work: image-captioning-main uses VGG16-LSTM with Flickr8k, preprocessing, CNN feature extraction, caption generation, BLEU evaluation, and an interactive web interface (2026-10). ClearLedger (Python; 2026-09), TenantEase (Python; 2026-10), BellWether (TypeScript; 2026-10), Beacon (Python; 2026-08), and ClauseIQ (Python; 2026-07) had no descriptions in the captured profile. My profile also describes work spanning XGBoost/LSTM, Isolation Forest, SHAP, ensemble forecasting, decision trees and ROC-AUC, AutoML risk scoring, XLM-RoBERTa + CRF, and VGG16-LSTM. Across the portfolio, recurring technologies include Python, TypeScript, JavaScript, React, FastAPI, LLMs, and SQLite. Several projects explicitly emphasize operational considerations such as deployment, audit trails and compliance, analyst review, human verification, tests, confidence thresholds, configurable tolerance, timezone/DST handling, offline-first behavior, and WebSocket updates. The profile lists hackathon or assignment contexts for Beyond-the-Crease, FinSaathi, Awaaz, RoadSoS, and Whispr; it provides no independent verification evidence or source-code contents for the project descriptions, claimed outcomes, or deployment status.

I describe TenantEase Khata as a synthetic-data rent-collection prototype on my GitHub. It turns a manager’s historical payment ledger into a leakage-tested late-payment reminder worklist, explains risk and suggests a reminder plan, then drafts a guarded message for human review. Scores are only for reminder scheduling—not eviction, rent pricing, or tenant screening—and messages are never sent automatically.

I generate all demo tenants, properties, units, payment messages, and rent outcomes; no real tenant records are used. Names and phone numbers use Faker’s en_IN locale, the seed defaults to 42, and the generator plants known payment-risk effects and deterministic vacancy gaps. The payment-parser fixtures also come from seeded synthetic tenants. These data and evaluations do not establish real-world accuracy, fairness, causal impact, or suitability for decisions about tenants.

I document a pipeline in which Faker en_IN with seed 42 feeds a SQLite ledger; an as-of feature builder tested for leakage feeds training and calibration, and the resulting risk score is used only for reminder timing. FastAPI connects the database and model to a React and TypeScript interface with ledger, portfolio, and outlook views. Reminder drafts pass message guardrails, while payment messages are parsed for a manager to review and confirm. The append-only audit records activity, and an optional LLM has a template fallback. The backend uses SQLModel, LightGBM, calibration, and evaluation; the frontend uses Vite, token-based CSS, and hand-built SVG charts.

On a seeded synthetic evaluation set of 528 lease-cycle rows with base rate 0.1667, the shipped calibrated model reports PR-AUC 0.3180, ROC-AUC 0.6882, Brier score 0.1313, and top 10% precision 0.4423. The late-last-cycle baseline reports PR-AUC 0.2754, ROC-AUC 0.6534, Brier score 0.1913, and top 10% precision 0.4615. These metrics are not evidence of production accuracy or tenant outcomes. The README table is generated from backend/app/ml/artifacts/metrics.json; after evaluation I refresh it with python backend/scripts/update_readme_metrics.py.

I use a 5-day grace window to define on-time collection for collection-efficiency reporting. The current-cycle outlook and reminder what-if use model probabilities and an assumed effect; no reminder treatment effect has been measured. The payment parser ranks possible leases but cannot confirm a payment, so a manager selects and confirms the record. The app has no production identity, access control, payment-provider integration, or deployment hardening.

I can run the demo locally with make setup, make seed, make train, and make eval, then start the API and web app in separate terminals with make api and make web. The app opens at http://localhost:5173; make check runs backend and frontend checks, and docker compose up --build starts the local demo on port 8080. No LLM key is required because reminder drafting falls back to templates. A payment confirmation may change the demo dataset; make seed restores it. There is no public deployment, and external hosting is needed for a public demo.

I describe ClearLedger as a Python repository on my GitHub, started and last updated in 2026-09. Track A is a four-hour challenge to repair a small local invoice-and-payment register for a fictional service business. The application runs and its starter tests pass, but six seeded defects span import, matching, reporting, and browser workflows; the smoke tests do not cover the whole specification, and fixing all six is not required for a strong submission. The owner reports disagreements between open invoices and the overview, imports that can move numbers again when retried, differences between downloaded reports and the screen, and completed imports that may not create the expected records.

I use BUSINESS_RULES.md as the specification and prioritize reproducible, important problems rather than special-casing sample files. The challenge asks me to investigate and prioritize, repair the most important problems within the time limit, add meaningful regression checks, and leave a concise HANDOVER.md. Verification must include a failing-before/passing-after reproduction, an additional input case I designed, recorded commands and actual results, and preservation checks for the existing register. I should preserve the public HTTP routes and response fields; a focused patch is welcome, and a rewrite is unnecessary.
I must preserve the owner's records beyond a fresh demo, support valid new invoice and payment imports after loading the supplied register and after restart, and keep the original fixtures/ intact. Resetting working data does not satisfy preservation; historical payment corrections are out of scope because supplied allocations are correct. If I change the schema, I must include and test the necessary migration. The working database is .local/clearledger.sqlite3; I should exclude .local/, caches, and virtual environments from submission. The register is synthetic INR data for fictional customers, so no accounting expertise, credentials, external services, or real financial records are needed.
I can run the app from the extracted track-a directory with python app.py, then open http://<redacted>:8787; I keep the terminal open and press Ctrl+C to stop it. If the port is occupied, I can use python app.py --port 8790 and http://<redacted>:8790. On Windows I can use py, and on macOS or Linux python3, in place of python throughout. I run the starter tests with python -m unittest discover -s tests -v. With the server stopped, I can reset demo data using python app.py reset-demo, or load the owner's working register using python restore_fixture.py --replace; after starting the app, I verify fixture records and starting totals against fixtures/README.md, then test valid invoice and payment imports, including after restart.

I have four hours total, including setup and choosing a track, and must submit within seven calendar days of the invitation. The suggested 240-minute allocation is 35 minutes to read, run, and investigate; 130 to prioritize, fix, and add regression checks; 40 for one useful improvement; and 35 for clean-run verification and handover. The improvement must go beyond restoring behaviour required by BUSINESS_RULES.md; I should explain the owner problem it solves, demonstrate it, and check it. If reliability work uses the available time, I should describe the proposed improvement and its first test instead of rushing implementation. Scoring weights are correctness and reliability 30%, verification 25%, investigation and prioritization 20%, useful improvement 15%, and handover and tool judgment 10%; bug-count claims, visual polish, code volume, and model choice are not rewarded.

The repository map identifies app.py for startup and reset; ledger/ for validation, storage, importing, matching, reporting, and HTTP routes; web/ for plain HTML, CSS, and JavaScript; samples/ for small CSVs including mixed-validity and incorrect-header examples; fixtures/ for existing records and documentation; restore_fixture.py for restoring the register; tests/ for passing smoke tests; and BUSINESS_RULES.md for intended behaviour and the public API. The challenge requires Python 3.10+ and a modern browser, and the starter has no third-party dependencies. I submit the chosen track's code, tests, and HANDOVER.md under the independent-work and submission rules in ../START_HERE.md; the handover should give reproducible evidence, remaining issues, and exact run and test commands, including what remains after four hours. No deployment is required; I should provide instructions for any additional dependencies.

I describe image-captioning-main as my VGG16–LSTM image-captioning repository on GitHub, started in 2026-09 and last updated in 2026-10. It uses Flickr8k and includes preprocessing, CNN feature extraction, caption generation, BLEU evaluation, and a web interface. The README describes a Flask inference API and a React/Tailwind app; its setup requirements are Python 3.11, Node.js, and approximately 8 GB of free RAM.

My documented captioning pipeline uses VGG16 with ImageNet weights on 224 × 224 RGB images, extracting the fc2 activation as a 4096-dimensional feature vector. The active decoder checkpoint is python model/IC_MODEL.keras, a Keras Functional model with 5,992,741 parameters. It accepts image features shaped (None, 4096) and text shaped (None, 35), embeds tokens from an 8,485-class vocabulary into 256 dimensions, processes them with an LSTM(256), fuses the image and text branches with Add, and predicts through Dense(256) and Dense(8485) with softmax. Greedy decoding starts with startseq, selects one word per timestep for up to 35 tokens, and stops at endseq; the documented target is Keras 3 / TensorFlow 2.16.

Flickr8k has 8,091 images and five human-written captions per image, or 40,455 captions total, and is distributed under the Flickr data license. My committed captions.txt is truncated to 15,949 rows, although features.zip contains the complete 8,091 × 4096 feature matrix produced by preprocessing.py. The README identifies this corpus truncation as the cause of the tokenizer/model mismatch: the tokenizer has 5,465 vocabulary slots against 8,485 model output classes, leaving 3,020 classes unmapped. Greedy decoding can select an unmapped index, causing idx_to_word to return None and generation to stop early; one reported garbled live caption is to is outfit child bat on the bat. The documented recovery path is to restore the full corpus at 8kdataset_full/captions.txt and validate it with python model/validate_dataset.py --dataset-root 8kdataset_full; the documentation does not establish that this restoration has happened.

The training notebook records historical results on the original full corpus: loss fell from 5.7976 to 1.7049 over 50 epochs, with vocab_size = 8485 and max_length = 35; its sample caption is startseq woman rides bike down rocky path endseq. Notebook-recorded BLEU-1 and BLEU-2 were 0.513414 and 0.290109, respectively, and are training-time figures rather than held-out results. A held-out BLEU score is currently unavailable because 319 of 320 test-split images are zero-byte files and the remaining image is missing. A fallback evaluation on 389 usable training images is explicitly training-fit only: BLEU-1 0.302159, BLEU-2 0.107995, BLEU-3 0.020670, and BLEU-4 0.000000.

The repository layout places the Flask API, model assets, preprocessing, training, and evaluation code under python model/, the image dataset under 8kdataset/, and the React/Tailwind app under frontend/. The README identifies IC_MODEL.keras as the active decoder checkpoint and describes CL_FD_MODEL_V2.keras as a redundant duplicate with the same architecture and weights that is safe to delete; it points to python model/TRAINING_PIPELINE_FORENSIC_REPORT.md for the comparison. Recovery and audit references include python model/CAPTION_RECOVERY_REQUIREMENTS.md, python model/DATASET_RECOVERY.md, python model/TRAINING_PIPELINE_FORENSIC_REPORT.md, MODEL_BASELINE_INFO.txt, BLEU_EVALUATION_REPORT.txt, TOKENIZER_MISMATCH_REPORT.md, and TOKENIZER_ARTIFACT_SEARCH_REPORT.md.

My documented web UI accepts JPG, PNG, WEBP, and GIF uploads. The Model page provides drag-and-drop upload, preview, a size badge, client-side validation, loading and result states, and a caption card with copy feedback; it presents clean error messages instead of raw backend stack traces. The Home page explains the UPLOAD -> ANALYZE -> GENERATE workflow, while the About page shows the IMAGE -> CNN -> FEATURE VECTOR -> LSTM -> TEXT pipeline. The interface also includes responsive navigation, scroll-spy, a mobile menu, a dark UI, and reduced-motion accessibility mode. The REST API uses POST /predict with multipart form field file, enables CORS, and serves on port 5000; the frontend runs on port 3000 and expects the backend at http://<redacted>:5000/predict. Documented responses are HTTP 200 with {"result": "a woman rides a bike down a rocky path"} on success, HTTP 400 with {"error": "no image file provided"} when file is absent, HTTP 400 with {"error": "not a valid image"} for an undecodable image, and HTTP 500 with {"error": "error processing image"} on feature-extraction failure.

# Backend setup in PowerShell
py -3.11 -m venv .venv
.venv\Scripts\python.exe -m pip install -r "python model\requirements.txt"
.\run.bat

# Frontend setup
cd frontend
npm install
npm start
# Production build: npm run build
# Tests: npm test

# Example prediction request
curl.exe -F "file=@C:\path\to\image.jpg" http://<redacted>:5000/predict

The README explains that run.bat sets PYTHONUTF8=1 because TensorFlow’s progress bar uses U+2501, which crashes on the Windows cp1252 console, and starts Flask with use_reloader=False to keep a single process. VGG16 ImageNet weights download on first run. The documented UI workflow and recovery steps are instructions, not evidence that the corpus has been restored or that the current model produces reliable captions.

I built BellWether, a TypeScript repository on my GitHub started and last updated in 2026-10, as a full-stack AI retail app for the Google AI Builder Cup 2026. Its React 18, Vite, TypeScript, and Tailwind v4 frontend uses “The Shopfront” design system; its FastAPI backend uses Gemini through the google-genai SDK. The catalog covers Apparel, Footwear, Home & Living, Beauty, Kitchen, and Accessories. The repository separates the API in backend/ from the UI in frontend/.

I provide semantic product search at /api/search, uploaded-image visual search at /api/search/visual, and a conversational shopping assistant with tool calling at /api/chat. The merchant copilot supports read-only natural-language SQL analytics at /api/merchant/ask and low-stock and fast-selling alerts at /api/merchant/alerts.
My setup prerequisites are Python 3.11, Node 20+, and a Gemini API key from Google AI Studio. In backend/, I install requirements.txt and copy .env.example to .env. Backend configuration includes GEMINI_BACKEND (api by default, or vertex), GEMINI_API_KEY, GOOGLE_CLOUD_PROJECT for Vertex, GOOGLE_CLOUD_LOCATION (Vertex default us-central1), GEMINI_MODEL (example gemini-2.5-flash), EMBEDDING_MODEL (example gemini-embedding-001), and DB_PATH for SQLite.

cd backend
docker build -t bellwether .
docker run -p 8080:8080 \
  -e GEMINI_API_KEY=your-gemini-api-key \
  -e GEMINI_MODEL=gemini-2.5-flash \
  -e EMBEDDING_MODEL=gemini-embedding-001 \
  -e DB_PATH=/data/bellwether.db \
  -v bellwether-data:/data \
  bellwether

The Docker example maps port 8080 to 8080 and stores SQLite data at /data/bellwether.db in the bellwether-data:/data volume. The container's only filesystem dependency is the database path from DB_PATH; other configuration comes from environment variables.

I seed 200 products, baskets, customers, and personas with python scripts/seed.py, and 400 shopper search events with python scripts/seed_events.py. python scripts/smoke_test_ai.py verifies AI access and python scripts/embed_catalog.py embeds the catalog; both require GEMINI_API_KEY. I run the API with uvicorn app.main:app --reload and use http://localhost:8000/docs for its interactive API UI. Backend tests use pytest.
In frontend/, I run npm install, copy .env.example to .env, set VITE_API_URL (default http://localhost:8000) and VITE_USE_MOCKS (true for mock data and false for live API calls), then run npm run dev at http://localhost:5173. The navbar/footer toggle switches mock and live modes at runtime and persists the choice in localStorage. I build with npm run build and run frontend checks with npm run lint.
Shopper and merchandising endpoints include GET /api/products/trending for top sellers by recent units, GET /api/products/{id}/complete-the-look for co-purchased items ranked by lift, GET /api/merchant/overview for revenue and units KPIs, at-risk count, and unmet demand, GET /api/merchant/demand-gaps?days= for clustered unmet demand, and GET /api/merchant/forecast?product_id= for days of cover and a 14-day forecast.
Search accepts persona_id values aarav, meera, and riya for personalised re-ranking. Searches, visual searches, and chat queries are logged to search_events; a query is a Demand Radar miss if it has zero results or its top score is below DEMAND_MISS_THRESHOLD. Out-of-stock hits are replaced by the nearest in-stock substitute with an explanatory note.
Until the catalog is embedded, search falls back to lexical keyword search so the API remains usable without a Gemini key. Semantic and visual search, chat, and insight paths call Gemini and require GEMINI_API_KEY.
My profile also lists these repositories, with descriptions and update dates that I have not independently verified:

The second profile summary reports repository language totals of Python 29, TypeScript 16, JavaScript 12, HTML 3, and Jupyter Notebook 3. It does not explain how multi-language repositories were counted or which repositories were included. The listed projects span updates from 2025-07 through 2026-03; the descriptions do not provide repository URLs, commit details, test results, or validation evidence. HireLens is described as using Python/Groq and React while its listed repository language is JavaScript; the profile does not explain that difference.

I also list one merged pull request each to AdityaC-07/project-aether, titled “Updates for a full-fledged AI Engineering Project,” and AdityaC-07/PathPilot, titled “Add root-level README for PathPilot.”

HashWatch (Python; 1 fork; 2026-03) monitors file integrity with SHA-256 baselines and watchdog, detecting additions, deletions, and modifications and logging timestamped events. SVM-Tumor-Classification (Python; 2026-03) classifies Breast Cancer dataset cases as malignant or benign using an SVM, preprocessing, feature scaling, hyperparameter tuning, and accuracy, precision, recall, F1, and confusion-matrix evaluation.
WealthLens (TypeScript; 1 fork; 2026-03), built for ET AI Hackathon 2026 (#PS9), describes CAMS-statement analysis for true XIRR, overlap, expense-ratio drag, and rebalancing, plus a Couple's Money Planner and Tax Wizard. Its profile description targets India's 14Cr+ retail investors and promises a plan in 10s. CFOne (Python; 1 fork; 2026-03) uses AWS Bedrock Nova models and a FastAPI/React multi-agent system for SME cash-flow forecasts, risk detection, compliance tracking, and insights. HireLens (listed as JavaScript; 2026-03), an AI Automation Internship Assessment submission, describes Python/Groq resume screening and a React recruiter dashboard. Tata-Motors-TechBlog (JavaScript; 2026-03) is a React 18/Material UI employee-and-admin blog portal with a Markdown editor and curated mobility articles, deployed on Netlify; lead-dashboard (JavaScript; 2026-03) uses React, Vite, and CSV-driven Tata Motors lead-quality, funnel, heatmap, call-density, model, alert, and impact analysis.
JobFlow/job-tracker-agent (Python; 1 fork; 2026-02) combines FastAPI, React, MongoDB, and JWT with job tracking, AI matching, resume parsing, and analytics. PipelineIQ (Python; 2026-02) describes FastAPI/Next.js B2B SaaS revenue attribution connecting ad spend to pipeline and revenue through multi-touch attribution, deal scoring, and budget insights. MedAssist (JavaScript; 2026-01), built for GDG Cloud Udaipur Hackathon 2026, uses Gemini for symptom analysis, triage, and medical-history tracking; its profile claims it reduces diagnosis delay from days to minutes for 800M+ underserved people, without providing supporting evidence. ProfileGuard (JavaScript; 2026-01) detects suspected fake social profiles from attributes, activity, and behavioral signals while aiming to minimize false positives. stock-health-reorder-intelligence (Python; 2026-01) uses Snowflake and a Streamlit dashboard to classify hospital and NGO inventory risk and recommend reorders to prevent stock-outs.
Real-Estate-Prediction (Python; 2025-12) compares Linear Regression, Random Forest, and XGBoost with preprocessing, feature engineering, and an interactive valuation dashboard. HealthQuest (JavaScript; 2025-12) gamifies wellness with daily quests, boss battles, mood and activity tracking, and personalized AI insights. BookVerse-Django-Mini-Project (Python; 2025-11) is a Bootstrap Django bookstore with listings, profiles, cart, order tracking, and secure authentication. green-ai-orchestrator (Jupyter Notebook; 2025-10) describes optimizing AI inference for sustainability without compromising performance. solar-index-prediction- (Jupyter Notebook; 2025-10) fetches solar irradiance from NASA POWER, analyzes time series, and engineers 41+ features for solar-energy prediction in Mumbai regions. caprae-lead-scorer (HTML; 2025-10) is a lead-scoring tool for a Caprae Capital interview. Smart-Product-Pricing-Challenge (Python; 2025-10) combines BERT text features and ResNet image features for e-commerce price prediction. AI-Study-Buddy--ThinkPal (Python; 2025-10) generates explanations, quizzes, and flashcards. User-Question-Answering-Model (Python; 2025-07) answers questions from passages using transformer models such as BERT. Sentiment-Analysis-on-Movie-Reviews (Python; 2025-07) classifies movie reviews with methods such as logistic regression and SVM, covering data collection, preprocessing, training, and evaluation.

The Musafir API documentation gives http://localhost:8000/api as its base URL. POST /api/plan accepts destination, origin, duration, budget amount and currency, budget level, travel style, and constraints; its example response includes a final answer, intermediate steps (identify_destination, generate_itinerary, estimate_budget), and trip context. GET /api/weather takes a city-and-country destination and documents a 7-day forecast with date, condition, temperatures, precipitation, wind speed, and weather code. GET /api/currency accepts from, to, and amount (default 100) and returns the input currencies and amount, converted amount, rate, and timestamp.

Food and trip-cost endpoints include POST /api/food for a trip food estimate, POST /api/food/day-plan for itinerary-aware daily meals, and POST /api/budget for a breakdown of flights, accommodation, food, activities, and transport. The day-plan request can include itinerary_days; its daily results can include a theme and context, breakfast/lunch/dinner suggestions and amounts, daily total, and nearby source.

The documented examples illustrate response shapes and sample figures: a USD-to-EUR conversion of 500 gives 462.50 at rate 0.925, timestamped 2026-04-04T10:30:00Z; a 5-day Bangkok food estimate is 1200 THB daily and 6000 THB total. A 5-day Zagreb day-plan example reports 450 HRK daily and 2250 total, with a beach-themed day totaling 720 from breakfast 120, lunch 280, and dinner 320. A Bangkok trip from Tokyo for 2 travelers, dated 2026-04-15 to 2026-04-22, shows a 6000 USD total (1200 flights, 2400 accommodation, 1500 food, 600 activities, 300 transport) and 857 daily average. The transport example shows a New York–London flight on 2026-05-01 for 450 USD, taking 7h 30m with Travelpayouts, resolving to JFK and LHR; its train result is null. The calendar example uses 2026-05-01 through 2026-05-08 and Tokyo-2026-05-01.ics.

# Root .env
GROQ_API_KEY=your_groq_api_key_here
EXCHANGE_RATE_API_KEY=your_exchange_rate_api_key_here
BACKEND_PORT=8000
DEBUG=false

# frontend/.env
VITE_API_BASE_URL=http://localhost:8000

# Development commands (Windows PowerShell)
.\.venv\Scripts\Activate.ps1
uvicorn backend.server:app --host <redacted> --port 8000 --reload

# Alternative backend command
python backend/server.py

# Frontend, from C:\Musafir\frontend
npm run dev

# Production frontend, from frontend
npm run build
npm run preview

# Production backend
pip install gunicorn
gunicorn backend.server:app --workers 4 --worker-class uvicorn.workers.UvicornWorker --bind <redacted>:8000

The README documents backend access at http://localhost:8000, Swagger UI at http://localhost:8000/docs, and the Vite frontend at http://localhost:5173. CORS also accepts http://localhost:3000 and a redacted IPv4-localhost origin on port 5173; the production Gunicorn bind host is likewise redacted. Setup is to clone the repository, enter Musafir, create and activate a Python virtual environment, install backend/requirements.txt, and install frontend dependencies with npm install. The backend tools demo is python backend/run_tools_demo.py; Uvicorn --reload and Vite HMR provide development hot reload. The documentation recommends PEP 8 and Black for Python, Prettier for TypeScript/React, and Tailwind utility classes for CSS, with Python, Pylance, FastAPI, TypeScript Vue Plugin, Tailwind CSS IntelliSense, and Thunder Client or REST Client among the suggested VS Code extensions.

The API documentation describes Musafir's LangGraph ReAct flow: LLaMA 3.1 reasons about trip requirements, calls specialized destination, weather, transport, food, and budget tools, iteratively refines results, and dynamically generates contextual itineraries if primary tools fail. It claims itineraries use real data rather than templates, food plans adapt to activities and regional cuisines, budgets incorporate real-time exchange rates and provider pricing, and dietary and travel-style constraints influence recommendations. The product is described as open source under the MIT License, with a mobile-first Tailwind interface, dark glassmorphism styling, real-time responses with loading states, and calendar integration. The documentation does not specify API error formats, authentication, rate limits, most data providers, or how sample prices and forecasts are obtained.

POST /api/transport compares modes such as flights, trains, and buses; GET /api/transport queries prices using origin, destination, date, and travel class. GET /api/destination returns destination details such as currency, timezone, language, best time to visit, attractions, local food, culture, safety, and budget tips.
POST /calendar/export exports itinerary events to an .ics file and returns a download URL and filename; GET /calendar/download retrieves a generated file by filename. GET /api/places/suggest searches for cities and attractions using query and max_results (default 5). The request and response values in the documentation are examples, not evidence of live results.