A beginner-friendly, mobile-responsive FAQ and query support system for the Vicharanashala Internship.
The goal of this project is to help interns quickly find answers from existing FAQs, raise queries only when needed, discuss issues with peers/admins, and allow verified answers to become new FAQs.
Interns often ask repeated questions because answers are hard to find or scattered across different places.
This project solves that by creating a simple support flow:
Search FAQ
→ View matching answers
→ If unresolved, raise query
→ Peer/Admin discussion
→ Admin verifies best answer
→ Verified answer becomes new FAQThe system follows an FAQ-first philosophy.
Before creating a new query, users should be encouraged to check:
- Existing FAQs
- Similar solved questions
- Open discussions
This helps reduce duplicate questions and lowers moderation load.
The MVP focuses on the most important product flow.
- FAQ page
- Smart FAQ search
- Raise query page
- Query discussion page
- Admin verify answer flow
- Convert verified answer into FAQ
- Category bubbles
- Voice-search UI
- SP urgent points
- Trending FAQs
- Recently opened FAQs
- Stats cards
- Real AI chatbot
- LLM-generated answers
- Real-time notifications
- WebSockets
- Advanced analytics
- Complex admin dashboard
Frontend:
- React
- TypeScript
- Tailwind CSS
- React Router
- Vite
State management:
- Zustand, only where shared/global state is needed
Search:
- Fuse.js or lightweight fuzzy/synonym search logic
Backend:
- Not required for initial MVP
- Mock services are used first
- Real backend integration can be added later
This repo contains two important planning files:
CONTEXT.md
ENGINEERING_STANDARDS.mdExplains what we are building.
It includes:
- product vision
- MVP scope
- user roles
- FAQ-first philosophy
- duplicate prevention philosophy
- feature priorities
- future scope boundaries
Explains how we should build it.
It includes:
- TypeScript rules
- folder structure
- component rules
- service layer rules
- Zustand usage rules
- mobile safety rules
- accessibility rules
- prompt governance rules
- merge checklist
All contributors and AI tools should follow both files.
src/
features/
faq/
components/
pages/
services/
store/
types/
utils/
mocks/
tests/
queries/
components/
pages/
services/
store/
types/
utils/
mocks/
tests/
admin/
components/
pages/
services/
types/
utils/
shared/
components/
hooks/
utils/
types/The FAQ page should allow interns to:
- view FAQs
- search FAQs
- filter by category
- open accordion answers
- see FAQ source
- see helpful count
- find answers quickly on mobile and desktop
Search should support:
- typo tolerance
- fuzzy matching
- synonyms
- natural language style queries
Example searches:
money → stipend FAQ
work from home → remote/offline FAQ
how long → internship duration FAQ
joining internship → VINS joining/acceptance FAQThe Raise Query page should allow interns to:
- enter a title
- describe their issue
- choose a category
- add tags
- submit a query
Before submitting, the system should suggest:
- matching FAQs
- similar solved questions
- related open discussions
This prevents duplicate questions.
This page should show:
- user’s raised queries
- status badges
- timestamps
- latest reply preview
- resolved/verified status
This page should show:
- query details
- peer/admin replies
- verified answer badge
- reply form
- resolved status
Admins can:
- reply to queries
- verify the best answer
- resolve queries
- convert verified replies into FAQs
Interns cannot:
- verify answers
- convert replies into FAQs
- perform admin moderation actions
This project should be built step by step.
Recommended 3-day MVP plan:
Build:
- frontend setup
- FAQ mock data
- FAQ service
- FAQ page
- smart search
- category filter
- accordion UI
- loading/error/empty states
- mobile-safe layout
Build:
- Raise Query page
- query mock data
- query service
- validation
- duplicate FAQ suggestions
- My Questions / Track Issue page
- status badges
Build:
- Query Discussion page
- reply flow
- admin verify answer flow
- convert verified answer to FAQ
- final mobile polish
- final bug fixing
The first MVP uses mock services.
This means data comes from local mock files first.
Example:
faq.mock.ts
query.mock.ts
reply.mock.tsService files should be written so that real backend APIs can replace mock data later.
Example:
faqService.getFaqs()
queryService.createQuery()
adminService.verifyReply()Later backend routes may include:
GET /faqs
POST /queries
GET /queries
GET /queries/:queryId
POST /queries/:queryId/replies
PATCH /replies/:replyId/verify
PATCH /queries/:queryId/resolve
POST /faqs/from-reply/:replyIdInstall dependencies:
npm installStart development server:
npm run devCreate production build:
npm run buildPreview production build:
npm run previewBefore starting a feature:
git checkout main
git pull
git checkout -b feature/feature-nameExamples:
git checkout -b feature/faq-page
git checkout -b feature/smart-search
git checkout -b feature/raise-query
git checkout -b fix/mobile-overflowBefore committing:
npm run build
git statusCommit:
git add .
git commit -m "Add FAQ page"
git push origin feature/faq-pageWhen using Minimax/OpenClaw, always start with:
Before coding, read CONTEXT.md and ENGINEERING_STANDARDS.md.
Follow them strictly.
Do not rewrite the whole app.
Do not modify unrelated files.
Do not add unrequested features.
Do not create massive monolithic files.
Use strict TypeScript.
Do not use any.
Keep components small.
Use service layer for mock/API data.
Use Zustand only for shared state.
Use local state for forms, modals, and small UI interactions.
Make all UI mobile responsive.
Avoid horizontal overflow.
Include loading, error, and empty states where relevant.
After coding, list files changed, why they changed, and how I should test.Important rules:
- Use strict TypeScript
- Do not use
any - Keep components small
- Use feature-based folders
- Keep API/mock data logic inside services
- Keep validation logic separate from UI
- Use Zustand only for shared state
- Use local state for forms and small UI interactions
- Always handle loading/error/empty states
- Make every page mobile responsive
- Avoid horizontal overflow
- Avoid unnecessary animations
- Avoid adding future-scope features too early
Every component must:
- avoid horizontal overflow
- support long text wrapping
- support small widths
- avoid fixed widths where possible
- use responsive spacing
- keep buttons usable on mobile
- keep cards readable on mobile
Useful Tailwind classes:
w-full
max-w-full
min-w-0
break-words
flex-wrapA feature is complete only if:
- TypeScript passes
npm run buildpasses- responsive UI is verified
- mobile layout is checked
- loading state exists
- error state exists
- empty state exists where needed
- no console errors exist
- no console warnings exist
- components remain maintainable
- service layer is respected
- unrelated files are not modified
- feature follows
CONTEXT.md - code follows
ENGINEERING_STANDARDS.md
The goal is not to build the biggest app.
The goal is to build a simple, secure, reliable, maintainable MVP.
A clean working FAQ + query + verified-answer system is better than a large unfinished AI dashboard.
Project quality will come from:
- stable architecture
- small components
- strict TypeScript
- mobile-safe UI
- controlled AI prompts
- disciplined branching
- incremental development