System Requirements Document for mission-ai

1. Introduction

MISSION AI is a complete, production-ready, mobile-first student learning platform. Its tagline is Learn Smarter, Achieve More. It is an AI-powered study, practice, notes, homework, test, examination, competitive-exam preparation, and personalized learning platform for students.

The product intent is to give students from Class 6 through Class 12 and Beyond Class 12 a single real application — not a demo, static prototype, landing page, or collection of mock screens — in which they can:

• authenticate with real Firebase authentication and complete a personalized onboarding,
• study class-appropriate NCERT books and chapters,
• take NCERT-based quizzes and exercises with real question logic and exact question counts,
• receive AI evaluation of objective and subjective answers,
• read ready-made Prepared Notes (Competitive / Career Notes for Beyond Class 12),
• run independent Missions for each selected competitive or school-level examination,
• create and manage Tests and Examinations with real dates and preparation actions,
• create, edit, complete, and delete homework and personal notes,
• consult an AI Mentor that uses their authorized stored context,
• and have all of this persisted, isolated by class, and secured.

The audience is students in India preparing for school study and for competitive and school-level entrance examinations, including Navodaya, Simultala, Ramakrishna Mission, Sainik School, Military School, applicable BHU school-level entrances, scholarships, UPSC, NEET, JEE, BPSC, SSC, Banking, Railway, Defence, and Teaching. The application must be suitable for Android phones, tablets, iPhone/iPad, desktop, and laptop browsers, with Android phones prioritized.

2. System Overview

MISSION AI is delivered as a real, production-oriented, mobile-first educational platform for web and Android. It uses React (or the platform's recommended framework), responsive CSS/Tailwind, Firebase Authentication, Firestore, secure backend APIs, and reusable components. API secrets are kept server-side.

Current delivery includes:

• Real navigation with a mobile-friendly bottom navigation: Home, Practice, Mission Mode, Prepared Notes, AI Mentor, Settings. Prepared Notes is renamed to Competitive / Career Notes for Beyond Class 12.
• Real authentication through Firebase using Google, Apple, Microsoft, and email/password, with registration, sign-in, password confirmation, email verification, password reset, persistence, sign-out, provider linking, and proper error handling.
• Real database persistence in Firestore for notes, homework, quizzes, tests, examinations, practice history, scores, missions, progress, bookmarks, recent notes, study plans, and preferences.
• Real user profiles storing Firebase UID, name, email, photo, class, subjects, exams, language, preferences, and onboarding status.
• Real educational data: class-appropriate books and actual chapters, including applicable NCERT books such as Curiosity Science for Classes 6–8, Ganita Prakash, Malhar, Vasant, Poorvi, Honeysuckle, Honeycomb, Sanskrit books, Computer, and GK where appropriate.
• Real quiz/exercise logic with objective question types (MCQ, True/False, Fill in the Blank, Match the Column, One Word, Assertion–Reason, Case Based, Picture Based) and subjective short, long, and very long answers.
• Real AI Mentor integration providing Explain Topic, Ask Doubt, Make Study Plan, Revise Me, Analyze Mistakes, and Ask Anything.
• Real practice history, real mission tracking, real notes, real homework, and real tests and examinations.
• Responsive design, validation, loading states, error handling, and secure backend architecture.

Actors are the Student (primary in-product actor), the Content Author / Notes Editor (authorized editing, validation, and version history of prepared content), and the Platform Administrator (security rules, backend authorization, AI endpoint abuse protection, secret management, and platform monitoring). Firebase Authentication and Firestore are provider-owned services; the AI provider is an external service reached only through the secure backend.

Narrow exclusions and boundaries:

• No simple demo, static prototype, landing page, or collection of mock screens.
• No static demo, fake authentication, simulated APIs, or nonfunctional controls.
• Never store plaintext passwords, fake OTPs, or bypass verification.
• Never guarantee perfect accuracy of AI-generated content.
• Never claim a feature works unless it has been implemented and tested.

2a. Product Interpretation and Delivery Boundary

MISSION AI is a first-party application with application-owned identity. Authentication is mandatory before accessing private features or personal data. The anonymous entry point is the Landing page, which explains MISSION AI before any identity establishment. Identity is established on the Login page, which is anonymously reachable and owns registration, sign-in, password confirmation, email verification, password reset, session persistence, sign-out, and provider linking. Protected state remains unavailable until identity is established.

After authentication, the application checks onboarding status and resumes incomplete onboarding on the Onboarding page, collecting name, class (6–12 or exactly Beyond Class 12), appropriate subjects, multiple selected examinations, language, and preferences, and saving all selections to the user's profile.

Content Author / Notes Editor and Platform Administrator access is provisioned rather than self-enrolled, with returning verification on the shared Login surface. Their working surfaces, Content Studio and Admin Console, are role-restricted.

Current delivery covers all accepted behavior described in this document. The following are explicitly out of current scope and are recorded as future horizons only: expandable future exams beyond the currently supported catalog, and any additional integrations not named in the authoritative requirements. Provider-owned responsibilities — Firebase Authentication, Firestore, and the external AI provider — remain with those providers and are reached only through the secure backend, which holds all secrets and server credentials.

2b. Source Content Inventory

No reference directive in this request declares content_source authority, so no source content inventory is included.

2c. Page Content and Component Coverage

Landing

• Information/state: MISSION AI wordmark and logo, tagline "Learn Smarter, Achieve More.", a plain statement that MISSION AI is an AI-powered study, practice, notes, homework, test, examination, competitive-exam preparation, and personalized learning platform for students, and the entry actions to establish identity.
• Primary actions: Navigate to Login to register or sign in.
• Supporting actions: Read the product explanation; view the supported class range (6–12 and Beyond Class 12) and the supported examination families.
• Domain entities: Product identity, tagline, supported classes, supported examination catalog summary.
• Component responsibilities: Poster hero band carrying the wordmark and tagline; typographic statement of the platform's scope; primary entry control; subject/exam pictogram strip.
• States: Loading (initial asset/typography load), empty (not applicable — static explanatory content), success (page rendered), error (asset load failure with retry), recovery (retry control).

Login

• Information/state: Provider choices Google, Apple, Microsoft, and email/password; registration form; sign-in form; password confirmation field; email verification status; password reset entry; provider linking entry; session persistence indicator.
• Primary actions: Register with email/password; sign in with email/password; sign in with Google, Apple, or Microsoft; confirm password; verify email; reset password; link an additional provider; sign out.
• Supporting actions: Resend verification email; switch between register and sign-in; recover from provider errors.
• Domain entities: Firebase UID, email, provider identity, verification state, session.
• Component responsibilities: Provider buttons; credential form with validation; password confirmation matcher; verification notice; reset flow; error banner with actionable message and retry.
• States: Loading (provider handshake, submission), empty (no session), success (authenticated session established and routed to onboarding check), error (invalid credentials, unverified email, provider failure, network failure) with actionable messages and retries, recovery (retry, reset password, resend verification).

Onboarding

• Information/state: Name, class selection (6, 7, 8, 9, 10, 11, 12, and exactly Beyond Class 12), relevant subjects for the chosen class, expandable examination choices with multiple selection, language, and preferences; current onboarding status.
• Primary actions: Enter name; select class; select subjects; select multiple examinations; select language; set preferences; save selections to profile.
• Supporting actions: Expand examination categories; revise earlier steps; resume an incomplete onboarding.
• Domain entities: Profile, class, subjects, examinations, language, preferences, onboarding status.
• Component responsibilities: Stepped form; class selector; subject selector filtered by class; expandable exam selector; language selector; preferences controls; save action; resume logic that restores previously entered values.
• States: Loading (profile fetch), empty (no selections yet), success (profile saved and routed to Home), error (validation failure, save failure, network failure) with actionable messages and retries, recovery (resume incomplete onboarding without re-asking stored information).

Home

• Information/state: Personalized progress, continue learning, today's practice, active missions, upcoming tests/examinations, recent notes, quick actions, homework, and study planning.
• Primary actions: Continue learning; start today's practice; open an active mission; open an upcoming test or examination; open a recent note; use a quick action; open homework; open study planning.
• Supporting actions: Navigate to any bottom-navigation destination.
• Domain entities: Progress records, practice history, missions, tests, examinations, notes, homework, study plans.
• Component responsibilities: Numbered section bars (01 PROGRESS, 02 TODAY'S PRACTICE, 03 ACTIVE MISSIONS) reading as a programme; progress display; continue-learning entry; today's practice entry; active mission list; upcoming tests/examinations list; recent notes list; quick actions; homework summary; study planning entry; countdown ticker.
• States: Loading (skeletons for each section), empty (meaningful empty states per section, e.g. no active missions, no upcoming tests), success (all sections populated), error (per-section error with actionable message and retry), recovery (retry individual section without losing the rest of the page).

Practice

• Information/state: Subject selection, book selection, chapter/topic selection, question count selection, All Subjects Mixed, All Chapters Mixed, Maximum questions: 100, and the entry to Exercises.
• Primary actions: Select Subject → Book → Chapter/Topic → Question Count → Start; choose All Subjects Mixed; choose All Chapters Mixed; choose 10, 50, 100, or a custom count; enter a custom count in the field with the exact placeholder "Enter how many quiz questions you want"; start the quiz; open Exercises.
• Supporting actions: Review previous practice history and accuracy.
• Domain entities: Subjects, books, chapters, topics, question bank, quiz configuration, practice history.
• Component responsibilities: Cascading selectors; mixed-mode toggles; count presets; custom count input with the exact placeholder; Maximum questions: 100 display; validation enforcing 1–100; start action; shortage explanation surface.
• States: Loading (catalog fetch), empty (no questions available for the selection, with explanation), success (quiz session started with exactly the requested number of unique questions), error (validation error outside 1–100, shortage of unique questions explained, network failure) with actionable messages and retries, recovery (adjust selection or count and retry).

Quiz Session

• Information/state: Current question, question type, Question X of N, selected/entered answer, skipped question markers, remaining questions.
• Primary actions: Answer a question; Previous; Skip; Next; submit the quiz.
• Supporting actions: Revisit a skipped question; change a previously given answer.
• Domain entities: Quiz attempt, questions, answers, skipped set, submission.
• Component responsibilities: Question renderer per objective type (MCQ, True/False, Fill in the Blank, Match the Column, One Word, Assertion–Reason, Case Based, Picture Based) and per subjective type (short, long, very long); navigation controls; Question X of N indicator; answer persistence; skipped-question list; submit control.
• States: Loading (question fetch), empty (not applicable within an active session), success (answer persisted, navigation works, submission accepted), error (save failure, network failure) with actionable messages and retries, recovery (retry save without losing the current answer). Answers and feedback are hidden until submission.

Quiz Results

• Information/state: Correct, wrong, unanswered, score, percentage, and explanations; AI evaluation of subjective answers with correctness, marks, missing points, explanations, model answers, and improvement suggestions; saved attempts, scores, accuracy, and history.
• Primary actions: Review each question's result and explanation; review AI evaluation of subjective answers; return to Practice; start another quiz.
• Supporting actions: Open practice history.
• Domain entities: Attempt record, score, accuracy, per-question result, AI evaluation record.
• Component responsibilities: Score and percentage display; correct/wrong/unanswered breakdown; per-question explanation list; AI evaluation panel; history entry.
• States: Loading (evaluation in progress for subjective answers), empty (not applicable after submission), success (results and evaluations displayed and persisted), error (evaluation failure or save failure) with actionable messages and retries, recovery (retry evaluation or retry save).

Exercises

• Information/state: Single or multiple subject selection, All Subjects, 50/100 marks per subject, balanced objective and subjective question composition, accurate total marks.
• Primary actions: Select subjects; choose All Subjects; choose 50 or 100 marks per subject; start the exercise; answer objective and subjective questions; submit.
• Supporting actions: Review the computed total marks before starting.
• Domain entities: Subjects, marks configuration, question composition, exercise attempt, total marks.
• Component responsibilities: Subject selector; All Subjects toggle; marks selector; composition display; total marks computation; question renderer; submit control.
• States: Loading (catalog and composition fetch), empty (no questions available for the selection, with explanation), success (exercise started with accurate total marks and balanced composition), error (validation failure, network failure) with actionable messages and retries, recovery (adjust selection and retry). Answers are never revealed before submission.

Mission Mode

• Information/state: One independent Mission per selected exam, each with exam information, verified syllabus, subjects, topics, prepared notes, practice, daily tasks, progress, remaining topics, important topics, revision, weak areas, and countdowns when official dates are available.
• Primary actions: Open a Mission; read exam information and verified syllabus; work through subjects and topics; open prepared notes; start practice; complete daily tasks; mark revision; review weak areas; view countdown.
• Supporting actions: Move between simultaneous missions without affecting each other.
• Domain entities: Mission, exam, syllabus, subjects, topics, daily tasks, progress, remaining topics, important topics, revision state, weak areas, countdown.
• Component responsibilities: Mission list; mission detail with syllabus and topic tree; daily task list; progress and remaining-topic indicators; important-topic and weak-area panels; revision entry; countdown chip when an official date exists.
• States: Loading (mission and syllabus fetch), empty (no missions yet, with guidance to select examinations in Settings), success (missions rendered independently), error (missing syllabus or missing official date handled explicitly; network failure) with actionable messages and retries, recovery (retry fetch; countdown omitted when no official date is available).

Prepared Notes

• Information/state: Ready-made notes organized by Class → Subject → Book → Chapter → Topic, including definitions, explanations, examples, tables, formulas, diagrams, flowcharts, quick revision, and important questions where relevant.
• Primary actions: Navigate Class → Subject → Book → Chapter → Topic; read a note; use quick revision; open important questions.
• Supporting actions: Move between topics within the same book.
• Domain entities: Prepared note, class, subject, book, chapter, topic, revision block, important questions.
• Component responsibilities: Hierarchical navigator; note renderer supporting definitions, explanations, examples, tables, formulas, diagrams, flowcharts, quick revision, and important questions; approval indicator for published content.
• States: Loading (content fetch), empty (no prepared notes for the selection, with explanation), success (approved prepared content displayed), error (missing content, network failure) with actionable messages and retries, recovery (retry fetch or choose another topic). Only content that has passed Generate → Validate → Quality Check → Publish is presented as approved prepared content.

Competitive / Career Notes

• Information/state: Exam-specific Competitive / Career Notes for Beyond Class 12, organized by exam and topic, with the same content forms as Prepared Notes where relevant.
• Primary actions: Select an exam; navigate its topics; read a note; use quick revision; open important questions.
• Supporting actions: Move between exams.
• Domain entities: Competitive/career note, exam, topic, revision block, important questions.
• Component responsibilities: Exam selector; topic navigator; note renderer; approval indicator for published content.
• States: Loading (content fetch), empty (no notes for the selected exam, with explanation), success (approved content displayed), error (missing content, network failure) with actionable messages and retries, recovery (retry fetch or choose another exam). This destination replaces Prepared Notes for Beyond Class 12.

AI Mentor

• Information/state: Authorized student context (profile, class, subjects, books, chapters, syllabus, missions, notes, homework, tests, examination dates, performance, weak areas); conversation and response area; language selection English, Hindi, or Hindi + English.
• Primary actions: Explain Topic; Ask Doubt; Make Study Plan; Revise Me; Analyze Mistakes; Ask Anything.
• Supporting actions: Change response language; open the resulting study plan in the Study Planner.
• Domain entities: Mentor request, mentor response, context snapshot, language, generated study plan.
• Component responsibilities: Mode selector for the six capabilities; context indicator showing which stored information is being used; response renderer adapted to class level; language control; handoff to Study Planner.
• States: Loading (response generation), empty (no conversation yet, with suggested starting modes), success (response displayed using stored context without re-asking for it), error (AI failure, abuse protection rejection, network failure) with actionable messages and retries, recovery (retry the request).

Study Planner

• Information/state: Realistic, adjustable study plans based on available days, syllabus, difficulty, priorities, and performance; plan items and their schedule.
• Primary actions: View a generated plan; adjust the plan; open a plan item; regenerate using updated stored details and remaining time.
• Supporting actions: Return to AI Mentor.
• Domain entities: Study plan, plan items, available days, syllabus scope, difficulty, priorities, performance inputs.
• Component responsibilities: Plan timeline; item list; adjustment controls; regeneration action that automatically uses stored details and remaining time.
• States: Loading (plan generation), empty (no plan yet, with entry to Make Study Plan), success (plan displayed and persisted), error (generation failure, network failure) with actionable messages and retries, recovery (retry generation or adjust inputs).

Tests

• Information/state: Test subject, book, chapters, date, and time; upcoming tests; historical test records.
• Primary actions: Create a test with subject, book, chapters, date, and time; use Prepare for Test.
• Supporting actions: Review past tests in history.
• Domain entities: Test, subject, book, chapters, date, time, preparation plan.
• Component responsibilities: Test creation form; chapter selector; date and time pickers; Prepare for Test action that automatically uses stored details and remaining time; upcoming list; history list.
• States: Loading (test list fetch), empty (no tests yet, with creation entry), success (test created and listed as upcoming), error (validation failure, date error, save failure, network failure) with actionable messages and retries, recovery (retry save). Past events are excluded from the upcoming list while remaining in history.

Examinations

• Information/state: Examination name, multiple subjects, books, chapter selections or all chapters, syllabus, date, and time; upcoming examinations; historical examination records.
• Primary actions: Create an examination; use Prepare for Examination; Change Date; Postpone; Remove; Cancel.
• Supporting actions: Review past examinations in history.
• Domain entities: Examination, name, subjects, books, chapters or all chapters, syllabus, date, time, preparation plan, status.
• Component responsibilities: Examination creation form; multi-subject and multi-book selectors; chapter selection with all-chapters option; syllabus field; date and time pickers; Prepare for Examination action that automatically uses stored details and remaining time; Change Date, Postpone, Remove, and Cancel controls; upcoming list; history list.
• States: Loading (examination list fetch), empty (no examinations yet, with creation entry), success (examination created, updated, postponed, removed, or cancelled with the interface updated), error (validation failure, date error, save failure, deletion failure, network failure) with actionable messages and retries, recovery (retry the failed operation). Past events are excluded from the upcoming list while remaining in history.

Homework

• Information/state: Subject, title/question, description, due date; pending list; completed list.
• Primary actions: Create homework; edit homework; mark homework complete; delete homework; open Solve Homework to pass the selected stored homework directly to AI Mentor.
• Supporting actions: Switch between pending and completed lists.
• Domain entities: Homework record, subject, title/question, description, due date, completion state.
• Component responsibilities: Homework form; pending list; completed list; edit, complete, and delete controls; delete confirmation; Solve Homework action that passes the selected stored homework directly to AI Mentor.
• States: Loading (homework fetch), empty (no pending or no completed homework, with meaningful empty states), success (record created, edited, completed, or deleted and the interface updated), error (validation failure, save failure, deletion failure, network failure) with actionable messages and retries, recovery (retry the failed operation). Deletions are confirmed and permanently remove the selected record.

My Notes

• Information/state: Title, content, subject, chapter, topic, bookmark state, and persistent text-level colors such as black, blue, and red.
• Primary actions: Create a note; edit a note; apply text-level color to a selection; bookmark a note; delete a note.
• Supporting actions: Filter by subject, chapter, or topic; open bookmarked notes.
• Domain entities: Personal note, title, content, subject, chapter, topic, bookmark, text-level color spans.
• Component responsibilities: Note editor with text-level color application that does not recolor unrelated text; metadata selectors; bookmark toggle; delete control with confirmation; note list.
• States: Loading (note fetch), empty (no notes yet, with creation entry), success (note saved with colors and bookmark persisted), error (validation failure, save failure, deletion failure, network failure) with actionable messages and retries, recovery (retry the failed operation). Deletions are confirmed and permanently remove the selected record.

Settings

• Information/state: Profile, class, subjects, exams, language, notifications, theme, AI preferences, security, privacy, support, About, and sign-out.
• Primary actions: Edit profile; change class; change subjects; change exams; change language; manage notifications; change theme; manage AI preferences; open security; open privacy; open support; open About; sign out.
• Supporting actions: Review stored profile fields (Firebase UID, name, email, photo, class, subjects, exams, language, preferences, onboarding status).
• Domain entities: Profile, class, subjects, exams, language, preferences, notification settings, theme, AI preferences, security settings, privacy settings, support, About.
• Component responsibilities: Profile section; class switcher with manual switching; subject and exam editors; language selector; notification controls; theme control; AI preference controls; security, privacy, support, and About sections; sign-out action.
• States: Loading (profile fetch), empty (not applicable — profile always exists after onboarding), success (changes saved and reflected across the application), error (validation failure, save failure, network failure) with actionable messages and retries, recovery (retry save). Changing classes preserves old data and restores it when the class is revisited; eligible classes advance automatically on April 1 while preserving previous records.

Content Studio

• Information/state: Prepared notes and competitive/career notes in the pipeline, their Generate → Validate → Quality Check → Publish stage, version history, and the class/subject/book/chapter/topic alignment of each item.
• Primary actions: Generate content; validate content; run quality check; publish content; edit content; view version history.
• Supporting actions: Filter by class, subject, book, chapter, topic, or exam.
• Domain entities: Content item, pipeline stage, version, alignment metadata, author identity.
• Component responsibilities: Pipeline stage board; content editor; validation and quality-check result panels; publish control; version history viewer.
• States: Loading (content list fetch), empty (no content items yet, with generation entry), success (content published and available to students as approved prepared content), error (generation failure, validation failure, quality-check failure, publish failure, network failure) with actionable messages and retries, recovery (retry the failed stage). Content is never presented to students as approved before it passes all four stages, and perfect accuracy is never guaranteed.

Admin Console

• Information/state: Firebase Security Rules configuration state, backend authorization and input validation status, AI endpoint abuse protection status, secret management state, exam and syllabus catalog, and platform monitoring signals.
• Primary actions: Configure and review restrictive Firebase Security Rules; review backend authorization and input validation; configure AI endpoint abuse protection; manage secrets and server credentials; manage the exam and syllabus catalog including expandable future exams; monitor platform health.
• Supporting actions: Review automated and end-to-end test results for authentication, access control, class isolation, scoring, timers, and failure recovery.
• Domain entities: Security rule set, authorization policy, validation policy, abuse protection policy, secret reference, exam catalog, syllabus record, monitoring signal, test result.
• Component responsibilities: Security rule editor and reviewer; authorization and validation status panels; abuse protection controls; secret management surface that never exposes secret values; exam and syllabus catalog manager; monitoring dashboard; test result viewer.
• States: Loading (configuration and monitoring fetch), empty (no catalog entries or no monitoring data yet, with meaningful empty states), success (configuration applied and monitoring displayed), error (configuration failure, monitoring failure, network failure) with actionable messages and retries, recovery (retry the failed operation). No secrets or server credentials are ever exposed.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-01 — Real, non-demo application (explicit) As a Student, I should use a complete, production-ready MISSION AI application with real navigation, real authentication, real database persistence, real user profiles, real educational data, real quiz/exercise logic, real AI Mentor integration, real practice history, real mission tracking, real notes, real homework, and real tests and examinations, so that I am not using a demo, static prototype, landing page, or collection of mock screens.

• Trigger/input: The Student opens the application.
• Observable result: Every listed capability performs real work against real persistence; no control is nonfunctional and no API is simulated.
• Access state: Anonymous on Landing; authenticated for private features.
• Failure/recovery: Any unavailable integration is clearly identified rather than faked.
• Continuation: The Student proceeds into authentication and onboarding.
• Provenance: explicit.

FR-02 — Tagline and brand identity (explicit) As a Student, I should see the MISSION AI brand and the tagline "Learn Smarter, Achieve More." presented consistently, so that the product feels like a polished, modern, bold, energetic, intelligent, premium, student-friendly platform.

• Trigger/input: Any page render.
• Observable result: A polished MISSION AI logo and a consistent design system are present across the application.
• Access state: All states.
• Failure/recovery: Asset load failure shows a retry.
• Continuation: The Student continues using the application.
• Provenance: explicit.

FR-03 — Cross-device responsive delivery (explicit) As a Student, I should use MISSION AI on Android phones, tablets, iPhone/iPad, desktop, and laptop browsers, with Android phones prioritized, so that the application is usable on my device.

• Trigger/input: The Student opens the application on any supported device.
• Observable result: The interface adapts without horizontal overflow, clipped text, inaccessible buttons, keyboard-obscured inputs, broken dialogs, or unusable navigation.
• Access state: All states.
• Failure/recovery: Layout defects are treated as defects to fix, not accepted behavior.
• Continuation: The Student continues the current task.
• Provenance: explicit.

FR-04 — Accessible controls, loading, empty, and error states (explicit) As a Student, I should encounter accessible controls, loading indicators, meaningful empty states, and clear error messages, so that I always understand what the application is doing.

• Trigger/input: Any data load, empty result, or failure.
• Observable result: Loading indicators appear during work; empty states explain the absence of content; error messages are clear and actionable.
• Access state: All states.
• Failure/recovery: Errors offer retries.
• Continuation: The Student retries or continues elsewhere.
• Provenance: explicit.

FR-05 — Real Firebase authentication with four providers (explicit) As a Student, I should register and sign in using Google, Apple, Microsoft, or email/password through real Firebase authentication, so that my identity is genuine and my private data is protected.

• Trigger/input: The Student chooses a provider or enters credentials on Login.
• Observable result: A real authenticated session is established.
• Access state: Anonymous entry on Login; authenticated session afterwards.
• Failure/recovery: Provider and credential errors are handled with actionable messages and retries.
• Continuation: The Student proceeds to the onboarding check.
• Provenance: explicit.

FR-06 — Registration, sign-in, password confirmation, verification, reset, persistence, sign-out, and provider linking (explicit) As a Student, I should complete registration, sign-in, password confirmation, email verification, password reset, session persistence, sign-out, and provider linking, so that my account lifecycle is complete and secure.

• Trigger/input: The Student performs any of these account actions on Login.
• Observable result: Each action completes with the expected state change; sessions persist across refreshes; sign-out ends the session; linked providers appear on the account.
• Access state: Anonymous entry on Login; authenticated for linking and sign-out.
• Failure/recovery: Each action has proper error handling with actionable messages and retries.
• Continuation: The Student returns to the task they were performing.
• Provenance: explicit.

FR-07 — No plaintext passwords, fake OTPs, or verification bypass (explicit) As a Student, I should have my credentials handled without plaintext password storage, fake OTPs, or bypassed verification, so that my account is genuinely protected.

• Trigger/input: Any authentication action.
• Observable result: No plaintext password is stored; no fake OTP is issued; verification is never bypassed.
• Access state: All authentication states.
• Failure/recovery: Not applicable — this is a binding constraint.
• Continuation: Not applicable.
• Provenance: explicit.

FR-08 — Onboarding status check and resume (explicit) As a Student, I should have my onboarding status checked after authentication and my incomplete onboarding resumed, so that I never repeat completed steps.

• Trigger/input: Successful authentication.
• Observable result: Complete onboarding routes to Home; incomplete onboarding resumes at the correct step with previously entered values restored.
• Access state: Authenticated.
• Failure/recovery: Fetch failure shows an actionable message and retry.
• Continuation: The Student completes onboarding and reaches Home.
• Provenance: explicit.

FR-09 — Onboarding data collection and profile save (explicit) As a Student, I should provide my name, class, appropriate subjects, multiple selected examinations, language, and preferences during onboarding, so that MISSION AI personalizes my experience.

• Trigger/input: The Student completes the onboarding steps.
• Observable result: All selections are saved in the Student's profile.
• Access state: Authenticated.
• Failure/recovery: Validation and save failures show actionable messages and retries.
• Continuation: The Student reaches Home with personalized content.
• Provenance: explicit.

FR-10 — Class options 6–12 and exactly Beyond Class 12 (explicit) As a Student, I should choose my class from 6, 7, 8, 9, 10, 11, 12, and exactly Beyond Class 12, so that content matches my level.

• Trigger/input: Class selection during onboarding or in Settings.
• Observable result: Only the listed class options are offered; the selected class drives content filtering.
• Access state: Authenticated.
• Failure/recovery: Not applicable — the option set is fixed.
• Continuation: The Student continues with class-appropriate content.
• Provenance: explicit.

FR-11 — Relevant subjects and expandable exam choices (explicit) As a Student, I should see only relevant subjects for my class and expandable examination choices, so that selection is focused and manageable.

• Trigger/input: Class selection, then subject and examination selection.
• Observable result: Subjects are filtered to the chosen class; examination choices expand by category and allow multiple selection.
• Access state: Authenticated.
• Failure/recovery: Missing subject or exam data shows an actionable message.
• Continuation: The Student saves selections and continues.
• Provenance: explicit.

FR-12 — Mobile-friendly bottom navigation (explicit) As a Student, I should navigate using mobile-friendly bottom navigation with Home, Practice, Mission Mode, Prepared Notes, AI Mentor, and Settings, so that primary destinations are always reachable.

• Trigger/input: The Student taps a bottom-navigation item.
• Observable result: The corresponding destination opens.
• Access state: Authenticated.
• Failure/recovery: Navigation failure shows an actionable message and retry.
• Continuation: The Student continues in the chosen destination.
• Provenance: explicit.

FR-13 — Prepared Notes renamed for Beyond Class 12 (explicit) As a Beyond Class 12 Student, I should see Prepared Notes renamed to Competitive / Career Notes, so that the destination matches my exam-focused content.

• Trigger/input: The Student's class is Beyond Class 12.
• Observable result: The navigation label and destination read Competitive / Career Notes and present exam-specific content.
• Access state: Authenticated.
• Failure/recovery: Missing content shows an actionable message.
• Continuation: The Student reads competitive/career notes.
• Provenance: explicit.

FR-14 — Personalized Home content (explicit) As a Student, I should see personalized progress, continue learning, today's practice, active missions, upcoming tests/examinations, recent notes, quick actions, homework, and study planning on Home, without overcrowding, so that I can resume work immediately.

• Trigger/input: The Student opens Home.
• Observable result: All listed sections render with the Student's real data and remain legible without overcrowding.
• Access state: Authenticated.
• Failure/recovery: Per-section errors show actionable messages and retries without losing the rest of the page.
• Continuation: The Student opens the section they need.
• Provenance: explicit.

FR-15 — Objective question types (explicit) As a Student, I should answer MCQ, True/False, Fill in the Blank, Match the Column, One Word, Assertion–Reason, Case Based, and Picture Based questions, so that I practise every objective format.

• Trigger/input: The Student encounters a question of one of these types in a quiz or exercise.
• Observable result: The question renders in its correct format and accepts an answer.
• Access state: Authenticated.
• Failure/recovery: Render or save failure shows an actionable message and retry.
• Continuation: The Student moves to the next question.
• Provenance: explicit.

FR-16 — Subjective answer types (explicit) As a Student, I should answer subjective short, long, and very long questions, so that I practise written formats.

• Trigger/input: The Student encounters a subjective question.
• Observable result: A free-text answer area appropriate to the length is provided and accepts the answer.
• Access state: Authenticated.
• Failure/recovery: Save failure shows an actionable message and retry.
• Continuation: The Student submits for AI evaluation.
• Provenance: explicit.

FR-17 — AI evaluation of answers (explicit) As a Student, I should receive AI evaluation providing correctness, marks, missing points, explanations, model answers, and improvement suggestions, so that I understand my performance.

• Trigger/input: The Student submits answers.
• Observable result: Evaluation output includes correctness, marks, missing points, explanations, model answers, and improvement suggestions.
• Access state: Authenticated.
• Failure/recovery: AI failure shows an actionable message and retry.
• Continuation: The Student reviews results and continues practising.
• Provenance: explicit.

FR-18 — Saved attempts, scores, accuracy, and history (explicit) As a Student, I should have my attempts, scores, accuracy, and history saved, so that I can track progress over time.

• Trigger/input: Quiz or exercise submission.
• Observable result: Attempt, score, accuracy, and history records persist and are visible.
• Access state: Authenticated.
• Failure/recovery: Save failure shows an actionable message and retry.
• Continuation: The Student reviews history or starts new practice.
• Provenance: explicit.

FR-19 — NCERT-based quiz flow (explicit) As a Student, I should create a quiz through the flow Subject → Book → Chapter/Topic → Question Count → Start, so that I practise exactly the material I choose.

• Trigger/input: The Student makes each selection in order on Practice.
• Observable result: Each step filters the next; Start launches the quiz with the chosen scope.
• Access state: Authenticated.
• Failure/recovery: Missing content for a selection shows an actionable message.
• Continuation: The Student starts the quiz.
• Provenance: explicit.

FR-20 — All Subjects Mixed and All Chapters Mixed (explicit) As a Student, I should choose All Subjects Mixed and All Chapters Mixed, so that I can practise across my whole syllabus.

• Trigger/input: The Student selects either mixed option.
• Observable result: The quiz draws from all selected subjects or all chapters as chosen.
• Access state: Authenticated.
• Failure/recovery: Insufficient content shows an actionable message.
• Continuation: The Student starts the quiz.
• Provenance: explicit.

FR-21 — Question count options and exact placeholder (explicit) As a Student, I should choose 10, 50, 100, or a custom count using the field with the exact placeholder "Enter how many quiz questions you want", so that I control quiz length.

• Trigger/input: The Student selects a preset or types a custom count.
• Observable result: The chosen count is applied; the custom field displays exactly "Enter how many quiz questions you want".
• Access state: Authenticated.
• Failure/recovery: Invalid input shows an actionable validation message.
• Continuation: The Student starts the quiz.
• Provenance: explicit.

FR-22 — Maximum questions: 100 and 1–100 enforcement (explicit) As a Student, I should see "Maximum questions: 100" and have counts enforced between 1 and 100, so that quiz length is bounded and predictable.

• Trigger/input: The Student enters or selects a count.
• Observable result: "Maximum questions: 100" is displayed; counts outside 1–100 are rejected with an actionable message.
• Access state: Authenticated.
• Failure/recovery: Out-of-range input is rejected with an actionable message.
• Continuation: The Student corrects the count and starts the quiz.
• Provenance: explicit.

FR-23 — Exact unique question count or explained shortage (explicit) As a Student, I should receive exactly the requested number of unique questions or an explanation of the shortage, so that I am never misled about quiz length.

• Trigger/input: The Student starts a quiz with a chosen count.
• Observable result: The quiz contains exactly the requested number of unique questions, or the shortage is explained.
• Access state: Authenticated.
• Failure/recovery: Shortage is explained rather than silently padded.
• Continuation: The Student proceeds with the quiz or adjusts the count.
• Provenance: explicit.

FR-24 — No duplicate or superficial questions (explicit) As a Student, I should never be given invented duplicates or superficial questions, so that my practice is genuine.

• Trigger/input: Quiz or exercise generation.
• Observable result: Questions are unique and substantive.
• Access state: Authenticated.
• Failure/recovery: Not applicable — this is a binding constraint.
• Continuation: Not applicable.
• Provenance: explicit.

FR-25 — Answers and feedback hidden until submission (explicit) As a Student, I should have answers and feedback hidden until I submit, so that my practice is honest.

• Trigger/input: The Student is answering questions.
• Observable result: No answer or feedback is visible before submission.
• Access state: Authenticated.
• Failure/recovery: Not applicable — this is a binding constraint.
• Continuation: The Student submits and then sees results.
• Provenance: explicit.

FR-26 — Quiz navigation and answer persistence (explicit) As a Student, I should use Previous, Skip, Next, see Question X of N, have my answers persisted, and revisit skipped questions, so that I can manage my attempt.

• Trigger/input: The Student navigates or skips during a quiz.
• Observable result: Navigation works; Question X of N updates; answers persist; skipped questions remain revisitable.
• Access state: Authenticated.
• Failure/recovery: Save failure shows an actionable message and retry without losing the answer.
• Continuation: The Student continues or submits.
• Provenance: explicit.

FR-27 — Quiz results content (explicit) As a Student, I should see correct, wrong, unanswered, score, percentage, and explanations in my results, so that I understand my outcome.

• Trigger/input: Quiz submission.
• Observable result: All listed result values and explanations are displayed.
• Access state: Authenticated.
• Failure/recovery: Result computation or save failure shows an actionable message and retry.
• Continuation: The Student reviews explanations and continues practising.
• Provenance: explicit.

FR-28 — Exercise configuration (explicit) As a Student, I should configure exercises with single or multiple subjects, All Subjects, and 50/100 marks per subject, so that I can practise at the right scale.

• Trigger/input: The Student configures an exercise on Exercises.
• Observable result: The chosen subject scope and marks per subject are applied.
• Access state: Authenticated.
• Failure/recovery: Invalid configuration shows an actionable message.
• Continuation: The Student starts the exercise.
• Provenance: explicit.

FR-29 — Balanced exercise composition and accurate total marks (explicit) As a Student, I should receive balanced objective and subjective questions with accurate total marks, so that my exercise reflects the marks I chose.

• Trigger/input: The Student starts an exercise.
• Observable result: The composition is balanced across objective and subjective questions and the total marks are accurate.
• Access state: Authenticated.
• Failure/recovery: Composition or marks mismatch is surfaced as an error with retry.
• Continuation: The Student completes the exercise.
• Provenance: explicit.

FR-30 — Exercise answers never revealed before submission (explicit) As a Student, I should never see exercise answers before submission, so that my practice is honest.

• Trigger/input: The Student is answering an exercise.
• Observable result: No answer is visible before submission.
• Access state: Authenticated.
• Failure/recovery: Not applicable — this is a binding constraint.
• Continuation: The Student submits and then sees results.
• Provenance: explicit.

FR-31 — Class-appropriate books and actual chapters only (explicit) As a Student, I should see only class-appropriate books and actual chapters, so that I never study content that does not exist for my class.

• Trigger/input: The Student browses books and chapters.
• Observable result: Only books and chapters valid for the selected class are shown.
• Access state: Authenticated.
• Failure/recovery: Missing content shows an actionable message.
• Continuation: The Student selects a valid chapter.
• Provenance: explicit.

FR-32 — Supported NCERT books (explicit) As a Student, I should access applicable NCERT books including Curiosity Science for Classes 6–8, Ganita Prakash, Malhar, Vasant, Poorvi, Honeysuckle, Honeycomb, Sanskrit books, Computer, and GK where appropriate, so that my syllabus is covered.

• Trigger/input: The Student browses books for their class and subject.
• Observable result: The applicable books from this list are available where appropriate for the class and subject.
• Access state: Authenticated.
• Failure/recovery: Missing book data shows an actionable message.
• Continuation: The Student opens a book and its chapters.
• Provenance: explicit.

FR-33 — Content matched to class, subject, book, chapter, and language (explicit) As a Student, I should have questions and notes matched to my selected class, subject, book, chapter, and language, so that everything I see is relevant.

• Trigger/input: Any content retrieval.
• Observable result: Returned questions and notes match all five dimensions.
• Access state: Authenticated.
• Failure/recovery: Mismatch or missing content shows an actionable message.
• Continuation: The Student continues with matched content.
• Provenance: explicit.

FR-34 — Prepared Notes organization and content forms (explicit) As a Student, I should read ready-made Prepared Notes organized by Class → Subject → Book → Chapter → Topic, including definitions, explanations, examples, tables, formulas, diagrams, flowcharts, quick revision, and important questions where relevant, so that I can study and revise effectively.

• Trigger/input: The Student navigates the Prepared Notes hierarchy.
• Observable result: Notes render with the applicable content forms for the selected topic.
• Access state: Authenticated.
• Failure/recovery: Missing content shows an actionable message and retry.
• Continuation: The Student continues to the next topic or uses quick revision.
• Provenance: explicit.

FR-35 — Competitive / Career Notes for Beyond Class 12 (explicit) As a Beyond Class 12 Student, I should receive exam-specific Competitive / Career Notes, so that my preparation matches my target exams.

• Trigger/input: The Student opens Competitive / Career Notes.
• Observable result: Exam-specific notes are presented for the selected exam.
• Access state: Authenticated.
• Failure/recovery: Missing content shows an actionable message and retry.
• Continuation: The Student continues studying or revising.
• Provenance: explicit.

FR-36 — Generate → Validate → Quality Check → Publish pipeline (explicit) As a Student, I should only see AI-generated content that has passed Generate → Validate → Quality Check → Publish as approved prepared content, so that I can trust what is presented as approved.

• Trigger/input: AI-generated content is produced for prepared notes.
• Observable result: Content is presented as approved prepared content only after passing all four stages.
• Access state: Authenticated for students; role-restricted for Content Author / Notes Editor.
• Failure/recovery: Failure at any stage prevents publication and surfaces an actionable message with retry.
• Continuation: The author retries the failed stage.
• Provenance: explicit.

FR-37 — Authorized editing and version history (explicit) As a Content Author / Notes Editor, I should edit prepared content with authorized access and maintain version history, so that corrections are traceable.

• Trigger/input: The author edits a content item in Content Studio.
• Observable result: The edit is saved with a new version recorded in version history.
• Access state: Role-restricted.
• Failure/recovery: Save failure shows an actionable message and retry.
• Continuation: The author continues editing or publishes.
• Provenance: explicit.

FR-38 — No guarantee of perfect accuracy (explicit) As a Student, I should understand that AI-generated content accuracy is never guaranteed, so that I use it appropriately.

• Trigger/input: Viewing AI-generated prepared content.
• Observable result: No claim of perfect accuracy is made anywhere in the product.
• Access state: Authenticated.
• Failure/recovery: Not applicable — this is a binding constraint.
• Continuation: Not applicable.
• Provenance: explicit.

FR-39 — Independent Mission per selected exam (explicit) As a Student, I should have each selected exam create an independent Mission, so that my preparation tracks are separate.

• Trigger/input: The Student selects examinations during onboarding or in Settings.
• Observable result: One independent Mission exists per selected exam.
• Access state: Authenticated.
• Failure/recovery: Mission creation failure shows an actionable message and retry.
• Continuation: The Student opens a Mission.
• Provenance: explicit.

FR-40 — Supported examination catalog (explicit) As a Student, I should prepare for Navodaya, Simultala, Ramakrishna Mission, Sainik School, Military School, applicable BHU school-level entrances, scholarships, UPSC, NEET, JEE, BPSC, SSC, Banking, Railway, Defence, and Teaching, with expandable future exams, so that my target exams are covered.

• Trigger/input: The Student browses or selects examinations.
• Observable result: The listed examinations are available, and the catalog is expandable for future exams.
• Access state: Authenticated.
• Failure/recovery: Missing exam data shows an actionable message.
• Continuation: The Student selects an exam and receives its Mission.
• Provenance: explicit.

FR-41 — Mission contents (explicit) As a Student, I should find exam information, verified syllabus, subjects, topics, prepared notes, practice, daily tasks, progress, remaining topics, important topics, revision, weak areas, and countdowns when official dates are available inside each Mission, so that I can run my campaign from one place.

• Trigger/input: The Student opens a Mission.
• Observable result: All listed elements render with real data; countdowns appear only when an official date is available.
• Access state: Authenticated.
• Failure/recovery: Missing syllabus or missing official date is handled explicitly; network failure shows an actionable message and retry.
• Continuation: The Student works through topics, tasks, and revision.
• Provenance: explicit.

FR-42 — Simultaneous missions stay independent (explicit) As a Student, I should have simultaneous missions remain independent, so that progress in one never affects another.

• Trigger/input: The Student works in one Mission while others are active.
• Observable result: Progress, tasks, and weak areas are scoped to each Mission.
• Access state: Authenticated.
• Failure/recovery: Not applicable — this is a binding constraint.
• Continuation: The Student switches between missions freely.
• Provenance: explicit.

FR-43 — Separate Test system (explicit) As a Student, I should create Tests with subject, book, chapters, date, and time and use Prepare for Test, so that I can prepare for school tests.

• Trigger/input: The Student creates a test on Tests.
• Observable result: The test is created with all fields and Prepare for Test produces a preparation plan.
• Access state: Authenticated.
• Failure/recovery: Validation, date, or save failure shows an actionable message and retry.
• Continuation: The Student follows the preparation plan.
• Provenance: explicit.

FR-44 — Separate Examination system (explicit) As a Student, I should create Examinations with multiple subjects, books, chapter selections or all chapters, syllabus, name, date, and time, so that I can prepare for examinations.

• Trigger/input: The Student creates an examination on Examinations.
• Observable result: The examination is created with all fields, including multiple subjects and all-chapters selection.
• Access state: Authenticated.
• Failure/recovery: Validation, date, or save failure shows an actionable message and retry.
• Continuation: The Student manages or prepares for the examination.
• Provenance: explicit.

FR-45 — Examination management actions (explicit) As a Student, I should use Prepare for Examination, Change Date, Postpone, Remove, and Cancel on my examinations, so that I can manage changing schedules.

• Trigger/input: The Student selects an examination and chooses an action.
• Observable result: The chosen action completes and the interface updates.
• Access state: Authenticated.
• Failure/recovery: Action failure shows an actionable message and retry.
• Continuation: The Student continues managing or preparing.
• Provenance: explicit.

FR-46 — Past events excluded from upcoming, retained in history (explicit) As a Student, I should have past events excluded from upcoming lists while historical records are retained, so that my upcoming view stays accurate and my history stays complete.

• Trigger/input: The Student views upcoming lists or history.
• Observable result: Past events do not appear in upcoming lists; they remain available in history.
• Access state: Authenticated.
• Failure/recovery: Date handling errors show an actionable message and retry.
• Continuation: The Student continues with current events.
• Provenance: explicit.

FR-47 — AI preparation plans use stored details and remaining time (explicit) As a Student, I should have AI preparation plans automatically use my stored details and remaining time, so that plans are realistic without re-entering information.

• Trigger/input: The Student invokes Prepare for Test or Prepare for Examination.
• Observable result: The plan is generated from stored details and the remaining time to the event.
• Access state: Authenticated.
• Failure/recovery: Generation failure shows an actionable message and retry.
• Continuation: The Student follows the plan.
• Provenance: explicit.

FR-48 — AI Mentor authorized context (explicit) As a Student, I should have the AI Mentor use my authorized context — profile, class, subjects, books, chapters, syllabus, missions, notes, homework, tests, examination dates, performance, and weak areas — so that its answers are personalized.

• Trigger/input: The Student makes any AI Mentor request.
• Observable result: Responses reflect the authorized stored context.
• Access state: Authenticated.
• Failure/recovery: Context fetch failure shows an actionable message and retry.
• Continuation: The Student continues the conversation.
• Provenance: explicit.

FR-49 — AI Mentor capabilities (explicit) As a Student, I should use Explain Topic, Ask Doubt, Make Study Plan, Revise Me, Analyze Mistakes, and Ask Anything, so that I get help for every study need.

• Trigger/input: The Student selects a mode and provides input.
• Observable result: The selected capability produces a relevant response.
• Access state: Authenticated.
• Failure/recovery: AI failure or abuse protection rejection shows an actionable message and retry.
• Continuation: The Student continues with another mode or question.
• Provenance: explicit.

FR-50 — Class-adapted explanations and three languages (explicit) As a Student, I should receive explanations adapted to my class level in English, Hindi, or Hindi + English, so that I understand the material in my language.

• Trigger/input: The Student selects a language and asks for an explanation.
• Observable result: The explanation matches the class level and the selected language.
• Access state: Authenticated.
• Failure/recovery: Language or generation failure shows an actionable message and retry.
• Continuation: The Student continues learning.
• Provenance: explicit.

FR-51 — Realistic, adjustable study plans (explicit) As a Student, I should receive realistic, adjustable study plans based on available days, syllabus, difficulty, priorities, and performance, so that my plan fits my situation.

• Trigger/input: The Student requests Make Study Plan or adjusts an existing plan.
• Observable result: The plan reflects the listed inputs and can be adjusted.
• Access state: Authenticated.
• Failure/recovery: Generation failure shows an actionable message and retry.
• Continuation: The Student follows or adjusts the plan.
• Provenance: explicit.

FR-52 — Study Planner integration (explicit) As a Student, I should have AI-generated plans integrated with the Study Planner, so that my plan lives in one place.

• Trigger/input: A plan is generated by the AI Mentor.
• Observable result: The plan appears in the Study Planner and remains adjustable there.
• Access state: Authenticated.
• Failure/recovery: Integration failure shows an actionable message and retry.
• Continuation: The Student works from the Study Planner.
• Provenance: explicit.

FR-53 — Never repeatedly ask for stored information (explicit) As a Student, I should never be repeatedly asked for information already stored, so that using MISSION AI stays efficient.

• Trigger/input: Any AI Mentor or planning interaction.
• Observable result: Stored information is reused rather than re-requested.
• Access state: Authenticated.
• Failure/recovery: Not applicable — this is a binding constraint.
• Continuation: Not applicable.
• Provenance: explicit.

FR-54 — Homework creation, editing, completion, deletion, and lists (explicit) As a Student, I should create, edit, complete, and delete homework and view pending and completed lists, so that I can manage my assignments.

• Trigger/input: The Student performs a homework action on Homework.
• Observable result: The record is created, edited, completed, or deleted; pending and completed lists reflect the change.
• Access state: Authenticated.
• Failure/recovery: Validation, save, or deletion failure shows an actionable message and retry.
• Continuation: The Student continues managing homework.
• Provenance: explicit.

FR-55 — Homework fields (explicit) As a Student, I should record subject, title/question, description, and due date for each homework item, so that each assignment is fully described.

• Trigger/input: The Student creates or edits homework.
• Observable result: All four fields are captured and persisted.
• Access state: Authenticated.
• Failure/recovery: Validation failure shows an actionable message.
• Continuation: The Student saves and continues.
• Provenance: explicit.

FR-56 — Solve Homework passes stored homework to AI Mentor (explicit) As a Student, I should use Solve Homework to pass the selected stored homework directly to AI Mentor, so that I get help without retyping.

• Trigger/input: The Student selects a stored homework item and chooses Solve Homework.
• Observable result: The selected stored homework is passed directly to AI Mentor and a response is produced.
• Access state: Authenticated.
• Failure/recovery: AI failure shows an actionable message and retry.
• Continuation: The Student continues the conversation or returns to Homework.
• Provenance: explicit.

FR-57 — Personal note fields and editing (explicit) As a Student, I should create and edit personal notes with title, content, subject, chapter, and topic, so that my notes are organized.

• Trigger/input: The Student creates or edits a note on My Notes.
• Observable result: All fields are captured, persisted, and editable.
• Access state: Authenticated.
• Failure/recovery: Validation or save failure shows an actionable message and retry.
• Continuation: The Student continues writing or organizing notes.
• Provenance: explicit.

FR-58 — Bookmarks (explicit) As a Student, I should bookmark personal notes, so that I can return to important notes quickly.

• Trigger/input: The Student toggles the bookmark on a note.
• Observable result: The bookmark state persists and bookmarked notes are identifiable.
• Access state: Authenticated.
• Failure/recovery: Save failure shows an actionable message and retry.
• Continuation: The Student opens bookmarked notes.
• Provenance: explicit.

FR-59 — Persistent text-level colors without recoloring unrelated text (explicit) As a Student, I should apply persistent text-level colors such as black, blue, and red to my notes without recoloring unrelated text, so that my highlighting stays precise.

• Trigger/input: The Student selects text and applies a color.
• Observable result: Only the selected text receives the color; the color persists across sessions; unrelated text is unaffected.
• Access state: Authenticated.
• Failure/recovery: Save failure shows an actionable message and retry.
• Continuation: The Student continues editing.
• Provenance: explicit.

FR-60 — Confirmed, permanent deletion with interface update (explicit) As a Student, I should have deletions confirmed, the selected record permanently removed, and the interface updated after successful operations, so that deletion is deliberate and accurate.

• Trigger/input: The Student deletes a note or homework item.
• Observable result: A confirmation is required; on confirmation the record is permanently removed and the interface updates.
• Access state: Authenticated.
• Failure/recovery: Deletion failure shows an actionable message and retry.
• Continuation: The Student continues working with the remaining records.
• Provenance: explicit.

FR-61 — Stored profile fields (explicit) As a Student, I should have my Firebase UID, name, email, photo, class, subjects, exams, language, preferences, and onboarding status stored, so that my profile is complete and portable.

• Trigger/input: Authentication and onboarding.
• Observable result: All listed fields are persisted in the profile.
• Access state: Authenticated.
• Failure/recovery: Save failure shows an actionable message and retry.
• Continuation: The Student uses the application with a complete profile.
• Provenance: explicit.

FR-62 — Settings sections (explicit) As a Student, I should find profile, class, subjects, exams, language, notifications, theme, AI preferences, security, privacy, support, About, and sign-out in Settings, so that I can control my experience.

• Trigger/input: The Student opens Settings.
• Observable result: All listed sections are present and functional.
• Access state: Authenticated.
• Failure/recovery: Save failure shows an actionable message and retry.
• Continuation: The Student continues using the application with updated settings.
• Provenance: explicit.

FR-63 — Persistence of all educational records (explicit) As a Student, I should have notes, homework, quizzes, tests, examinations, practice history, scores, missions, progress, bookmarks, recent notes, study plans, and preferences persisted, so that nothing is lost.

• Trigger/input: Any create, update, or completion action.
• Observable result: All listed record types persist and survive refresh.
• Access state: Authenticated.
• Failure/recovery: Save failure shows an actionable message and retry.
• Continuation: The Student resumes where they left off.
• Provenance: explicit.

FR-64 — Class isolation with preservation and restoration (explicit) As a Student, I should have educational records isolated by class, with old data preserved when I change classes and restored when I revisit them, so that my history stays intact.

• Trigger/input: The Student changes class.
• Observable result: Records are scoped to their class; previously created records reappear when the class is revisited.
• Access state: Authenticated.
• Failure/recovery: Isolation or restore failure shows an actionable message and retry.
• Continuation: The Student continues in the selected class.
• Provenance: explicit.

FR-65 — Automatic April 1 advancement with manual switching (explicit) As a Student, I should have eligible classes advance automatically on April 1 with previous records preserved, and be able to switch manually, so that my class stays current without losing history.

• Trigger/input: April 1 arrives, or the Student switches class manually.
• Observable result: Eligible classes advance automatically; previous records are preserved; manual switching remains available.
• Access state: Authenticated.
• Failure/recovery: Advancement failure shows an actionable message and retry.
• Continuation: The Student continues in the correct class.
• Provenance: explicit.

FR-66 — Restrictive Firebase Security Rules (explicit) As a Student, I should be protected by restrictive Firebase Security Rules so that I can access only my own private records, so that my data stays private.

• Trigger/input: Any data read or write.
• Observable result: Access to another user's private records is denied.
• Access state: Authenticated.
• Failure/recovery: Denied access shows an actionable message.
• Continuation: The Student continues with their own records.
• Provenance: explicit.

FR-67 — Backend authorization and input validation (explicit) As a Student, I should have authorization and input validated on the backend, so that invalid or unauthorized requests are rejected.

• Trigger/input: Any backend request.
• Observable result: Unauthorized or invalid requests are rejected with actionable messages.
• Access state: Authenticated.
• Failure/recovery: Rejection shows an actionable message and retry where appropriate.
• Continuation: The Student corrects the request and continues.
• Provenance: explicit.

FR-68 — AI endpoint abuse protection and no exposed secrets (explicit) As a Student, I should have AI endpoints protected against abuse and no secrets or server credentials exposed, so that the platform stays secure.

• Trigger/input: Any AI request.
• Observable result: Abuse is blocked; no secret or server credential is exposed to the client.
• Access state: Authenticated.
• Failure/recovery: Blocked requests show an actionable message.
• Continuation: The Student retries appropriately.
• Provenance: explicit.

FR-69 — Comprehensive error handling with actionable messages and retries (explicit) As a Student, I should have network, authentication, AI, database, validation, missing-content, date, save, and deletion errors handled with actionable messages and retries, so that I can recover from any failure.

• Trigger/input: Any of the listed error conditions occurs.
• Observable result: An actionable message is shown and a retry is offered where applicable.
• Access state: All states.
• Failure/recovery: This requirement is itself the recovery behavior.
• Continuation: The Student retries or continues elsewhere.
• Provenance: explicit.

FR-70 — Caching, pagination, deduplication, and loading states (explicit) As a Student, I should benefit from appropriate caching, pagination, deduplication, and loading states, so that the application stays fast and clear.

• Trigger/input: Any list or content load.
• Observable result: Content is cached appropriately, paginated, deduplicated, and accompanied by loading states.
• Access state: Authenticated.
• Failure/recovery: Load failure shows an actionable message and retry.
• Continuation: The Student continues browsing.
• Provenance: explicit.

FR-71 — Automated and end-to-end verification (explicit) As a Platform Administrator, I should verify authentication and access control, onboarding recovery, CRUD operations, persistence after refresh, class isolation, mobile responsiveness, exact quiz counts, scoring, timers, AI evaluation, mission independence, date handling, and failure recovery through automated and end-to-end tests, so that the platform is proven to work.

• Trigger/input: The test suite runs.
• Observable result: Each listed area is covered by automated or end-to-end tests with recorded results.
• Access state: Role-restricted.
• Failure/recovery: Failing tests are reported with actionable detail.
• Continuation: The administrator fixes and re-runs.
• Provenance: explicit.

FR-72 — Honest delivery reporting (explicit) As a Platform Administrator, I should have implemented features, required configuration, unavailable integrations, and remaining work clearly identified, and no feature claimed to work unless implemented and tested, so that delivery is honest.

• Trigger/input: Delivery reporting.
• Observable result: The report distinguishes implemented, configured, unavailable, and remaining work.
• Access state: Role-restricted.
• Failure/recovery: Not applicable — this is a binding constraint.
• Continuation: Not applicable.
• Provenance: explicit.

FR-73 — Anonymous Landing entry (required_inference) As an anonymous visitor, I should reach a Landing page explaining MISSION AI before any identity establishment, so that I understand the product before signing in.

• Trigger/input: The visitor opens the application without a session.
• Observable result: The Landing page renders with the product explanation and an entry to Login.
• Access state: Anonymous.
• Failure/recovery: Asset load failure shows a retry.
• Continuation: The visitor proceeds to Login.
• Provenance: required_inference.

FR-74 — Provisioned author and administrator access (required_inference) As a Content Author / Notes Editor or Platform Administrator, I should have my access provisioned rather than self-enrolled, with returning verification on the shared Login surface, so that privileged surfaces stay controlled.

• Trigger/input: The provisioned user signs in on Login.
• Observable result: The user reaches Content Studio or Admin Console according to their provisioned role.
• Access state: Role-restricted.
• Failure/recovery: Failed verification shows an actionable message and retry.
• Continuation: The user continues in their privileged surface.
• Provenance: required_inference.

4. User Personas

Student

Product context. The Student is the primary in-product actor: a Class 6–12 or Beyond Class 12 learner in India preparing for school study and for competitive or school-level entrance examinations. They are mobile-first, frequently on an Android phone, and often study in a mix of Hindi and English. They may be running several preparation campaigns at once — a school test next week, a Navodaya or Sainik School entrance, and a long-horizon goal such as JEE, NEET, or UPSC.

Primary goal. Make measurable progress across subjects and exams, with persistent records isolated by class, and feel that studying is a campaign they are winning rather than a chore.

Distinct accepted responsibilities.

• Authenticate with Google, Apple, Microsoft, or email/password, confirm password, verify email, reset password when needed, link providers, persist the session, and sign out.
• Complete onboarding by providing name, class (6–12 or exactly Beyond Class 12), appropriate subjects, multiple selected examinations, language, and preferences, and resume incomplete onboarding without re-entering stored information.
• Study class-appropriate books and actual chapters, including applicable NCERT books such as Curiosity Science for Classes 6–8, Ganita Prakash, Malhar, Vasant, Poorvi, Honeysuckle, Honeycomb, Sanskrit books, Computer, and GK where appropriate.
• Configure and take NCERT-based quizzes through Subject → Book → Chapter/Topic → Question Count → Start, including All Subjects Mixed and All Chapters Mixed, with counts of 10, 50, 100, or a custom value entered in the field with the exact placeholder "Enter how many quiz questions you want", bounded by "Maximum questions: 100" and 1–100.

• Navigate a quiz with Previous, Skip, Next, Question X of N, persisted answers, and revisitable skipped questions, with answers and feedback hidden until submission.
• Configure and take exercises with single or multiple subjects, All Subjects, and 50/100 marks per subject, with balanced objective and subjective questions, accurate total marks, and answers never revealed before submission.
• Submit objective and subjective answers for AI evaluation and review correctness, marks, missing points, explanations, model answers, and improvement suggestions.
• Track attempts, scores, accuracy, and practice history.
• Read ready-made Prepared Notes organized by Class → Subject → Book → Chapter → Topic, and, when Beyond Class 12, exam-specific Competitive / Career Notes.
• Run one independent Mission per selected exam, working through exam information, verified syllabus, subjects, topics, prepared notes, practice, daily tasks, progress, remaining topics, important topics, revision, weak areas, and countdowns when official dates are available.
• Create Tests with subject, book, chapters, date, and time and use Prepare for Test; create Examinations with multiple subjects, books, chapter selections or all chapters, syllabus, name, date, and time and use Prepare for Examination, Change Date, Postpone, Remove, and Cancel.
• Create, edit, complete, and delete homework with subject, title/question, description, and due date, and use Solve Homework to pass the selected stored homework directly to AI Mentor.
• Create and edit personal notes with title, content, subject, chapter, topic, bookmarks, and persistent text-level colors such as black, blue, and red without recoloring unrelated text.
• Use the AI Mentor for Explain Topic, Ask Doubt, Make Study Plan, Revise Me, Analyze Mistakes, and Ask Anything, with class-adapted explanations in English, Hindi, or Hindi + English.

• Build and adjust realistic study plans based on available days, syllabus, difficulty, priorities, and performance, integrated with the Study Planner.
• Manage profile, class, subjects, exams, language, notifications, theme, AI preferences, security, privacy, support, About, and sign-out in Settings.

Relevant inputs and decisions. Which class and subjects to study; which examinations to pursue; how many questions to attempt; which question types to practise; whether to skip or answer a question; when to submit; which homework to solve with AI; which notes to bookmark and how to color them; which test or examination dates to set, change, postpone, remove, or cancel; which language to receive explanations in; when to change class manually.

Interactions with other accepted participants. The Student consumes prepared content produced and published by the Content Author / Notes Editor, and relies on the Platform Administrator for the security, reliability, and content integrity of the platform. The Student interacts with Firebase Authentication and Firestore as provider-owned services and with the AI provider only through the secure backend.

Observable success. Progress, scores, accuracy, missions, notes, homework, tests, examinations, bookmarks, recent notes, study plans, and preferences persist across refreshes; records remain isolated by class and are restored when a class is revisited; eligible classes advance automatically on April 1 with previous records preserved; quizzes return exactly the requested number of unique questions or explain the shortage; answers stay hidden until submission; and every failure produces an actionable message with a retry.

Content Author / Notes Editor

Product context. The Content Author / Notes Editor is a provisioned, non-self-enrolled role responsible for the quality of the prepared content that students read. The specification requires authorized editing and version history for prepared notes and a Generate → Validate → Quality Check → Publish pipeline before AI-generated content is presented as approved prepared content.

Primary goal. Ensure that every prepared note and competitive/career note presented to students as approved has passed the full pipeline, is correctly aligned to class, subject, book, chapter, and topic, and has a traceable version history.

Distinct accepted responsibilities.

• Generate content for a specific class, subject, book, chapter, and topic, or for a specific exam in the case of competitive/career notes.
• Validate generated content against its intended scope.
• Run the quality check on validated content.
• Publish only content that has passed all three preceding stages.
• Edit published or in-pipeline content with authorized access.
• Maintain version history for every edit.
• Never present content as approved before it passes all four stages, and never claim perfect accuracy.

Relevant inputs and decisions. Which class, subject, book, chapter, topic, or exam a content item targets; whether generated content passes validation; whether validated content passes quality check; whether to publish, hold, or edit; how to correct a published item while preserving version history.

Interactions with other accepted participants. The Content Author / Notes Editor produces the approved prepared content that the Student reads in Prepared Notes and Competitive / Career Notes. Access is provisioned rather than self-enrolled, with returning verification on the shared Login surface. The role works within the security and reliability posture established by the Platform Administrator.

Observable success. Every item visible to students as approved prepared content has a recorded pass through Generate → Validate → Quality Check → Publish; every edit produces a new version in version history; and no content reaches students as approved while any stage is incomplete.

Platform Administrator

Product context. The Platform Administrator is a provisioned, non-self-enrolled role responsible for the security, reliability, and content integrity of MISSION AI. The specification requires restrictive Firebase Security Rules, backend authorization and input validation, AI endpoint abuse protection, no exposed secrets or server credentials, and automated and end-to-end verification of authentication, access control, class isolation, scoring, timers, and failure recovery.

Primary goal. Keep the platform secure, reliable, and verifiably correct, with a maintained exam and syllabus catalog and no exposed secrets.

Distinct accepted responsibilities.

• Configure and maintain restrictive Firebase Security Rules so users access only their own private records.
• Ensure backend authorization and input validation are enforced.
• Protect AI endpoints against abuse.
• Manage secrets and server credentials so that none are exposed.
• Manage the exam and syllabus catalog, including expandable future exams.
• Monitor platform health and reliability.
• Run and review automated and end-to-end tests covering authentication and access control, onboarding recovery, CRUD operations, persistence after refresh, class isolation, mobile responsiveness, exact quiz counts, scoring, timers, AI evaluation, mission independence, date handling, and failure recovery.
• Report clearly which features are implemented, which configuration is required, which integrations are unavailable, and what work remains, and never claim a feature works unless it has been implemented and tested.

Relevant inputs and decisions. Security rule changes; authorization and validation policy; abuse protection thresholds; secret rotation; exam and syllabus catalog additions; test results and monitoring signals; delivery reporting accuracy.

Interactions with other accepted participants. The Platform Administrator protects the Student's private records and the Content Author / Notes Editor's privileged surfaces, and owns the security posture that both rely on. Access is provisioned rather than self-enrolled, with returning verification on the shared Login surface.

Observable success. Unauthorized access to another user's private records is denied; invalid or unauthorized backend requests are rejected; AI endpoints resist abuse; no secret or server credential is exposed; the exam and syllabus catalog is current and expandable; and the test suite demonstrably covers every listed verification area.

5. Core User Flows

Flow 1 — Anonymous visitor learns about MISSION AI and establishes identity (Student)

1. The visitor opens MISSION AI without a session and lands on Landing, which explains that MISSION AI is an AI-powered study, practice, notes, homework, test, examination, competitive-exam preparation, and personalized learning platform for students, and shows the tagline "Learn Smarter, Achieve More."
2. The visitor selects the entry action and arrives at Login.
3. The visitor chooses Google, Apple, Microsoft, or email/password. For email/password registration they enter credentials and confirm the password; for sign-in they enter existing credentials.
4. Observable result: A real Firebase authenticated session is established. If email verification is required, the visitor is told to verify and can resend the verification email. If credentials are wrong or the provider fails, an actionable message appears with a retry.
5. Next step: The application checks onboarding status and routes the Student to Onboarding if onboarding is incomplete, or to Home if it is complete.

Flow 2 — Student completes or resumes onboarding

1. After authentication, the Student arrives at Onboarding.
2. If onboarding was previously started, the Student resumes at the correct step with previously entered values restored; stored information is not requested again.
3. The Student enters their name, selects their class from 6, 7, 8, 9, 10, 11, 12, or exactly Beyond Class 12, selects the subjects relevant to that class, expands the examination choices and selects multiple examinations, selects a language, and sets preferences.
4. Observable result: All selections are saved in the Student's profile, including Firebase UID, name, email, photo, class, subjects, exams, language, preferences, and onboarding status.
5. Failure/recovery: A validation or save failure shows an actionable message and a retry; the Student's entered values are preserved.
6. Next step: The Student arrives at Home with personalized content, and one independent Mission exists for each selected examination.

Flow 3 — Student takes an NCERT-based quiz with an exact question count

1. The Student opens Practice from the bottom navigation.
2. The Student selects Subject → Book → Chapter/Topic, or chooses All Subjects Mixed and/or All Chapters Mixed.
3. The Student selects a question count of 10, 50, 100, or a custom value typed into the field with the exact placeholder "Enter how many quiz questions you want", with "Maximum questions: 100" displayed.
4. Observable result: Counts outside 1–100 are rejected with an actionable message. If the requested number of unique questions is unavailable, the shortage is explained rather than padded with duplicates or superficial questions.
5. The Student selects Start and enters Quiz Session.
6. In Quiz Session, the Student answers questions of the applicable objective types (MCQ, True/False, Fill in the Blank, Match the Column, One Word, Assertion–Reason, Case Based, Picture Based) and subjective types (short, long, very long), using Previous, Skip, Next, and the Question X of N indicator. Answers persist, skipped questions remain revisitable, and no answer or feedback is visible before submission.
7. Failure/recovery: If an answer fails to save, an actionable message appears and the Student retries without losing the answer.
8. The Student submits and arrives at Quiz Results.
9. Observable result: Results show correct, wrong, unanswered, score, percentage, and explanations. Subjective answers receive AI evaluation with correctness, marks, missing points, explanations, model answers, and improvement suggestions. The attempt, score, accuracy, and history are saved.
10. Failure/recovery: If AI evaluation or saving fails, an actionable message appears and the Student retries.
11. Next step: The Student returns to Practice to start another quiz or reviews practice history.

Flow 4 — Student takes an exercise with balanced composition and accurate total marks

1. The Student opens Exercises from Practice.
2. The Student selects a single subject, multiple subjects, or All Subjects, and selects 50 or 100 marks per subject.
3. Observable result: The exercise composition is balanced across objective and subjective questions and the total marks are accurate for the chosen configuration.
4. The Student starts the exercise and answers the questions. Answers are never revealed before submission.
5. The Student submits.
6. Observable result: Results and AI evaluation are presented as in Flow 3, and the attempt is saved to practice history.
7. Failure/recovery: A configuration, composition, or save failure shows an actionable message and a retry.
8. Next step: The Student returns to Practice or reviews history.

Flow 5 — Student studies prepared notes and revises

1. The Student opens Prepared Notes from the bottom navigation (or Competitive / Career Notes if their class is Beyond Class 12).
2. The Student navigates Class → Subject → Book → Chapter → Topic.
3. Observable result: The note renders with the applicable content forms — definitions, explanations, examples, tables, formulas, diagrams, flowcharts, quick revision, and important questions where relevant. Only content that has passed Generate → Validate → Quality Check → Publish is presented as approved prepared content, and no guarantee of perfect accuracy is made.
4. Failure/recovery: If content is missing for the selection, an actionable message appears and the Student retries or chooses another topic.
5. Next step: The Student moves to the next topic, uses quick revision, or opens important questions.

Flow 6 — Student runs an independent Mission for a selected exam

1. The Student opens Mission Mode from the bottom navigation.
2. The Student selects one of their Missions. Each selected exam has its own independent Mission, and simultaneous missions do not affect one another.
3. Observable result: The Mission shows exam information, verified syllabus, subjects, topics, prepared notes, practice, daily tasks, progress, remaining topics, important topics, revision, weak areas, and a countdown when an official date is available.
4. The Student works through topics, completes daily tasks, marks revision, and reviews weak areas.
5. Failure/recovery: If the syllabus is missing or no official date is available, the application states this explicitly rather than inventing data; a network failure shows an actionable message and a retry.
6. Next step: The Student switches to another Mission or returns to Home.

Flow 7 — Student creates and manages a Test

1. The Student opens Tests.
2. The Student creates a test with subject, book, chapters, date, and time.
3. Observable result: The test is created and appears in the upcoming list. Past events are excluded from upcoming lists while remaining in history.
4. The Student selects Prepare for Test.
5. Observable result: An AI preparation plan is generated automatically from stored details and the remaining time to the test.
6. Failure/recovery: A validation, date, or save failure shows an actionable message and a retry.
7. Next step: The Student follows the preparation plan or returns to Home.

Flow 8 — Student creates and manages an Examination

1. The Student opens Examinations.
2. The Student creates an examination with name, multiple subjects, books, chapter selections or all chapters, syllabus, date, and time.
3. Observable result: The examination is created and appears in the upcoming list. Past events are excluded from upcoming lists while remaining in history.
4. The Student selects Prepare for Examination.
5. Observable result: An AI preparation plan is generated automatically from stored details and the remaining time to the examination.
6. The Student uses Change Date, Postpone, Remove, or Cancel as their schedule changes.
7. Observable result: The chosen action completes and the interface updates; the examination's history is retained.
8. Failure/recovery: An action, date, or save failure shows an actionable message and a retry.
9. Next step: The Student follows the preparation plan or returns to Home.

Flow 9 — Student manages homework and solves it with AI Mentor

1. The Student opens Homework.
2. The Student creates homework with subject, title/question, description, and due date, or edits an existing item.
3. Observable result: The item appears in the pending list; completed items move to the completed list.
4. The Student selects a stored homework item and chooses Solve Homework.
5. Observable result: The selected stored homework is passed directly to AI Mentor, which responds using the Student's authorized context without asking for information already stored.
6. The Student marks the homework complete.
7. Observable result: The item moves to the completed list and the interface updates.
8. Failure/recovery: A validation, save, or AI failure shows an actionable message and a retry.
9. Next step: The Student continues with other homework or returns to Home.

Flow 10 — Student writes, colors, bookmarks, and deletes personal notes

1. The Student opens My Notes.
2. The Student creates a note with title, content, subject, chapter, and topic, or edits an existing note.
3. The Student selects text and applies a persistent text-level color such as black, blue, or red.
4. Observable result: Only the selected text receives the color; unrelated text is not recolored; the color persists across sessions.
5. The Student bookmarks the note.
6. Observable result: The bookmark persists and the note is identifiable as bookmarked.
7. The Student deletes a note.
8. Observable result: A confirmation is required; on confirmation the selected record is permanently removed and the interface updates.
9. Failure/recovery: A save or deletion failure shows an actionable message and a retry.
10. Next step: The Student continues writing or returns to Home.

Flow 11 — Student consults the AI Mentor and builds a study plan

1. The Student opens AI Mentor from the bottom navigation.
2. The Student selects Explain Topic, Ask Doubt, Make Study Plan, Revise Me, Analyze Mistakes, or Ask Anything, and selects English, Hindi, or Hindi + English.
3. Observable result: The response uses the Student's authorized context — profile, class, subjects, books, chapters, syllabus, missions, notes, homework, tests, examination dates, performance, and weak areas — is adapted to the Student's class level, and is delivered in the selected language. The Student is never repeatedly asked for information already stored.
4. When the Student selects Make Study Plan, the plan is built from available days, syllabus, difficulty, priorities, and performance, and is adjustable.
5. Observable result: The plan is integrated with the Study Planner and appears there.
6. Failure/recovery: An AI failure or abuse-protection rejection shows an actionable message and a retry.
7. Next step: The Student opens Study Planner to work from the plan, or continues the conversation.

Flow 12 — Student adjusts a study plan in the Study Planner

1. The Student opens Study Planner.
2. The Student reviews the generated plan and its items.
3. The Student adjusts the plan or regenerates it.
4. Observable result: The adjusted plan is saved and reflects updated stored details and remaining time.
5. Failure/recovery: A generation or save failure shows an actionable message and a retry.
6. Next step: The Student works through plan items or returns to AI Mentor.

Flow 13 — Student manages profile, class, and preferences in Settings

1. The Student opens Settings from the bottom navigation.
2. The Student edits profile details, class, subjects, exams, language, notifications, theme, AI preferences, security, privacy, support, or About.
3. Observable result: Changes are saved and reflected across the application. Changing class preserves old data and restores it when the class is revisited. Eligible classes advance automatically on April 1 with previous records preserved, and manual switching remains available.
4. The Student selects sign-out.
5. Observable result: The session ends and the Student returns to the anonymous entry point.
6. Failure/recovery: A save failure shows an actionable message and a retry.
7. Next step: The Student signs in again or continues on Landing.

Flow 14 — Content Author / Notes Editor publishes approved prepared content

1. The Content Author / Notes Editor signs in on Login with provisioned access and reaches Content Studio.
2. The author generates content for a specific class, subject, book, chapter, and topic, or for a specific exam in the case of competitive/career notes.
3. The author validates the generated content.
4. The author runs the quality check on the validated content.
5. Observable result: Only content that has passed Generate → Validate → Quality Check can be published. Content that fails any stage is not presented to students as approved prepared content.
6. The author publishes the content.
7. Observable result: The content becomes available to students in Prepared Notes or Competitive / Career Notes as approved prepared content, with no guarantee of perfect accuracy.
8. The author edits a published item when a correction is needed.
9. Observable result: The edit is saved with a new version recorded in version history.
10. Failure/recovery: A failure at any stage shows an actionable message and a retry for that stage.
11. Next step: The author continues with the next content item.

Flow 15 — Platform Administrator secures, monitors, and verifies the platform

1. The Platform Administrator signs in on Login with provisioned access and reaches Admin Console.
2. The administrator configures and reviews restrictive Firebase Security Rules so that users access only their own private records.
3. The administrator reviews backend authorization and input validation, configures AI endpoint abuse protection, and manages secrets and server credentials so that none are exposed.
4. The administrator maintains the exam and syllabus catalog, including expandable future exams.
5. The administrator runs and reviews automated and end-to-end tests covering authentication and access control, onboarding recovery, CRUD operations, persistence after refresh, class isolation, mobile responsiveness, exact quiz counts, scoring, timers, AI evaluation, mission independence, date handling, and failure recovery.
6. Observable result: Unauthorized access is denied, invalid or unauthorized requests are rejected, abuse is blocked, no secret is exposed, the catalog is current, and test coverage is recorded.
7. Failure/recovery: A configuration or monitoring failure shows an actionable message and a retry; failing tests are reported with actionable detail.
8. Next step: The administrator reports clearly which features are implemented, which configuration is required, which integrations are unavailable, and what work remains, never claiming a feature works unless it has been implemented and tested.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Paula Scher, and the headline idea is typography as architecture — a study platform that reads like a public-theater poster. Words fill the frame, colour blocks collide, and energy wins over polish. This maps directly onto the product's core nouns: Mission Mode, Prepare for Test, Prepare for Examination, Learn Smarter Achieve More. Every screen header becomes a rallying cry rather than a label, and hierarchy comes from scale and colour coding instead of generic dashboard cards — which keeps a dense six-section app legible on a 375px phone.

Colour tokens (light mode)

Rules: never more than two colour blocks in one viewport; always hard-edged, never gradient. Body text on the off-white ground is #111111 at 16px minimum, giving a contrast ratio above 15:1. Red blocks carry white text only at 20px and above; small white text on red is forbidden — use black on yellow instead.

Typography

• Headings: Anton, all-caps, tight tracking (-0.01em), line-height 0.9, stacked flush-left in two or three lines so the headline occupies the full column width.
• Secondary headings: Archivo Black at 24–32px for section titles.
• Micro-labels: Archivo SemiBold uppercase 12px with 0.14em letterspacing (SUBJECT, CHAPTER, QUESTION 7 OF 100).
• Numerals: Anton at display scale — a score of 87 is a poster element, not a stat chip.
• Devanagari: Noto Sans Devanagari at matching weights so bilingual copy never looks bolted on.
• Body: Archivo.

Type scale, 1.25 modular with poster jumps:

Shape language

Hard edges only — 0px radius on cards, buttons, inputs, and modals. Colour blocks are perfect rectangles that bleed to the viewport edge. Diagonal bands (skewY -4deg) separate major sections. Rules are 3px solid black, used as section dividers and to underline active tabs. Chips and pills are the one exception: fully rounded stadium shapes, because they read as stickers pasted onto the poster. No soft shadows — depth comes from flat colour overlap and 3–4px black offset borders.

Layout

Asymmetric poster grid: a 12-column desktop grid where content occupies columns 1–7 and a colour block or oversized numeral occupies 8–12. On mobile it collapses to a single column where the colour block sits above the content as a full-bleed band. Section headers are full-width black bars with white uppercase type, numbered (01 PROGRESS, 02 TODAY'S PRACTICE, 03 ACTIVE MISSIONS) so the home screen reads as a programme. Bottom navigation is a fixed 5-item bar (Home, Practice, Missions, Notes, Mentor) with the sixth destination (Settings) behind the avatar in the top-right; each active item shows a red underline stroke that wipes in from left. Quiz questions occupy the full width with the question number set as a giant Anton numeral in the left margin, and answer options are full-width ruled rows separated by 3px black lines, not cards.

Imagery

Typography is the image. No stock photography of students, no 3D blobs, no illustrations of people. Visual interest comes from oversized numerals as graphic objects, flat colour blocks with high-contrast type reversed out, a small set of thick-stroke single-colour pictograms for subjects and exam categories drawn at 32px on a 2px grid, and halftone-dotted texture at 8% opacity over red blocks for print-poster grain. Book covers and chapter art are rendered as flat colour rectangles with the book title set in Anton, not as photographic thumbnails.

7. Signature Design Concept

The Campaign Poster Home. The authenticated Home screen opens with a full-bleed poster band, not a dashboard: a solid red #E4321B rectangle spanning the viewport, 42vh tall on mobile and 52vh on desktop, containing the Student's name set in Anton at clamp(44px, 11vw, 132px) in black, stacked across two or three lines flush left — for example "ARJUN, / CLASS 9. / 47 DAYS TO / NAVODAYA." The countdown numeral is the largest object on the screen. The red block bleeds off the right edge and is overlapped on its lower-left by a white card carrying today's practice CTA and a 3px black rule. A black ticker tape runs along the bottom edge of the band with the Student's upcoming tests and exam dates.

There is no centred headline, no subtext, and no button under a hero image — the name, the class, and the countdown are the hero, and the composition is deliberately asymmetric with the type running off the right edge of the band. Readable text and controls stay whole at 375px, 768px, and 1280px: the headline wraps or scales using its clamp() mobile size rather than being clipped, and the gesture of running off the edge is carried by the red colour block and the halftone texture, never by the type.

Below the band, the home screen continues as a printed programme: numbered black section bars — 01 PROGRESS, 02 TODAY'S PRACTICE, 03 ACTIVE MISSIONS — each a full-width #111111 band with white uppercase Anton type, followed by the corresponding real content: personalized progress, continue learning, today's practice, active missions, upcoming tests/examinations, recent notes, quick actions, homework, and study planning. The composition recomposes only accepted content, states, and controls; it introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: The MISSION AI wordmark and the tagline "Learn Smarter, Achieve More." set in Anton, occupying the full column width as a poster headline, with the platform's scope statement beneath it in Archivo.
• Input → transformation → outcome thesis: As the Landing page loads, the headline wipes up from a clipped baseline in 400ms with cubic-bezier(0.16,1,0.3,1); the red colour block slides in from the left edge to settle behind the wordmark; and the entry control resolves into place. The outcome is a composed poster first frame in which the product's identity and its single entry action are unmistakable — one gesture, no stagger cascade.
• Motion vocabulary: Typographic wipe-up from a clipped baseline; colour-block slide-in from the left edge; instant colour-block wipes for state feedback (180ms, no bounce); a black ticker tape scrolling at 28s linear that pauses on hover and on focus.
• Composed first frame: A warm off-white #F4F1EA ground; a red #E4321B block bleeding off the right edge with 8% halftone grain; the MISSION AI wordmark and tagline reversed out in black on the red block at display scale; the scope statement in Archivo beneath; the entry control as a hard-edged black-bordered rectangle; and a black ticker tape along the lower edge carrying the supported class range and examination families.
• Reduced-motion state: With prefers-reduced-motion, the ticker becomes a horizontally scrollable row with snap points so every item can be brought fully into view, and headline reveals become instant opacity changes. The composed first frame is otherwise identical, and no readable text or control is ever cropped, clipped, or covered.

9. Non-Functional Requirements

NFR-01 — Mobile-first responsiveness across devices (explicit) The application must be suitable for Android phones, tablets, iPhone/iPad, desktop, and laptop browsers, with Android phones prioritized. Rationale: the authoritative specification names these devices and prioritizes Android phones.

NFR-02 — No layout defects (explicit) The interface must prevent horizontal overflow, clipped text, inaccessible buttons, keyboard-obscured inputs, broken dialogs, and unusable navigation. Rationale: these are named as defects to prevent.

NFR-03 — Accessible controls and clear states (explicit) Controls must be accessible, and the application must provide loading indicators, meaningful empty states, and clear error messages. Rationale: named as required presentation behavior.

NFR-04 — Restrictive Firebase Security Rules (explicit) Restrictive Firebase Security Rules must ensure users access only their own private records. Rationale: named as a security requirement.

NFR-05 — Backend authorization and input validation (explicit) Authorization and input must be validated on the backend. Rationale: named as a security requirement.

NFR-06 — AI endpoint abuse protection and secret isolation (explicit) AI endpoints must be protected against abuse, and no secrets or server credentials may be exposed. API secrets must be kept server-side. Rationale: named as a security requirement.

NFR-07 — No plaintext passwords, fake OTPs, or verification bypass (explicit) Plaintext passwords must never be stored, fake OTPs must never be issued, and verification must never be bypassed. Rationale: named as a binding security constraint.

NFR-08 — Comprehensive error handling with retries (explicit) Network, authentication, AI, database, validation, missing-content, date, save, and deletion errors must be handled with actionable messages and retries. Rationale: named as a reliability requirement.

NFR-09 — Caching, pagination, deduplication, and loading states (explicit) Appropriate caching, pagination, deduplication, and loading states must be used. Rationale: named as a performance and clarity requirement.

NFR-10 — Automated and end-to-end verification (explicit) Authentication and access control, onboarding recovery, CRUD operations, persistence after refresh, class isolation, mobile responsiveness, exact quiz counts, scoring, timers, AI evaluation, mission independence, date handling, and failure recovery must be verified through automated and end-to-end tests. Rationale: named as a verification requirement.

NFR-11 — Honest delivery reporting (explicit) Implemented features, required configuration, unavailable integrations, and remaining work must be clearly identified, and no feature may be claimed to work unless it has been implemented and tested. Rationale: named as a delivery requirement.

NFR-12 — No guarantee of perfect accuracy (explicit) Perfect accuracy of AI-generated content must never be guaranteed. Rationale: named as a binding constraint.

NFR-13 — Class isolation and preservation (explicit) Educational records must be isolated by class; changing classes must preserve old data and restore it when revisited; eligible classes must advance automatically on April 1 with previous records preserved, with manual switching available. Rationale: named as a data-integrity requirement.

NFR-14 — No repeated requests for stored information (explicit) The application must never repeatedly ask for information already stored. Rationale: named as a binding constraint.

NFR-15 — Real, non-simulated behavior (explicit) The application must not be a static demo, must not use fake authentication, must not use simulated APIs, and must not contain nonfunctional controls. Rationale: named as a binding delivery constraint.

10. Tech Stack

Source-specified choices are preserved exactly:

• Frontend: React or the platform's recommended framework, with responsive CSS/Tailwind and reusable components.
• Authentication: Firebase Authentication, supporting Google, Apple, Microsoft, and email/password.
• Database: Firestore, with restrictive Firebase Security Rules.
• Backend: Secure backend APIs that keep API secrets server-side, validate authorization and input, and protect AI endpoints against abuse.
• AI: An external AI provider reached only through the secure backend, powering AI evaluation and the AI Mentor.
• Target platforms: Web and Android, with Android phones prioritized, and support for tablets, iPhone/iPad, laptops, and desktops.

Supporting infrastructure:

• Containerization: Docker and docker-compose for the application services.
• Orchestration: Kubernetes only where deployment requires it.

11. Assumptions and Constraints

Constraints (binding)

1. Do not create a simple demo, static prototype, landing page, or collection of mock screens.
2. Do not deliver a static demo, fake authentication, simulated APIs, or nonfunctional controls.
3. Authentication is mandatory before accessing private features or personal data.
4. Never store plaintext passwords, fake OTPs, or bypass verification.
5. Class options are 6–12 and exactly Beyond Class 12.
6. Quiz question counts are enforced at 1–100; return exactly the requested number of unique questions or explain the shortage; never invent duplicates or superficial questions.
7. Hide answers and feedback until submission for quizzes; never reveal answers before submission for exercises.
8. Keep simultaneous missions independent.
9. Exclude past events from upcoming lists while retaining historical records.
10. AI-generated content must pass Generate → Validate → Quality Check → Publish before being presented as approved prepared content.
11. Never guarantee perfect accuracy of AI-generated content.
12. Keep API secrets server-side; expose no secrets or server credentials.
13. Implement restrictive Firebase Security Rules so users access only their own private records.
14. Isolate educational records by class; changing classes must preserve old data and restore it when revisited.
15. Automatically advance eligible classes annually on April 1, preserving previous records, with manual switching available.
16. Never repeatedly ask for information already stored.
17. Never claim a feature works unless it has been implemented and tested.
18. Clearly identify implemented features, required configuration, unavailable integrations, and remaining work.

Assumptions (narrow and labeled)

1. [Assumption — required_inference] The anonymous Landing page is the entry point that explains MISSION AI before identity establishment, and Login is anonymously reachable so that a protected destination never owns the interaction that establishes access to itself.
2. [Assumption — required_inference] Content Author / Notes Editor and Platform Administrator access is provisioned rather than self-enrolled, with returning verification on the shared Login surface.
3. [Assumption — required_inference] The AI provider is an external service reached only through the secure backend; the backend holds all provider credentials.
4. [Assumption — required_inference] Firebase Authentication and Firestore are provider-owned services whose responsibilities remain with those providers.
5. [Assumption — required_inference] The exam and syllabus catalog is expandable for future exams, and countdowns appear only when an official date is available.
6. [Assumption — required_inference] Class records are isolated and preserved across manual class switching and automatic April 1 advancement.

Presentation and technology defaults

• [Default — not specified by user] Docker and docker-compose are used to run the application services; Kubernetes is used only where deployment requires it.
• [Default — not specified by user] The visual system follows the supplied creative direction: Paula Scher-inspired poster typography, the specified palette, Anton/Archivo/Noto Sans Devanagari type families, hard-edged 0px-radius surfaces, and expressive typographic motion.

12. Glossary

• MISSION AI — The student learning application specified in this document. Tagline: Learn Smarter, Achieve More.
• Student — The primary in-product actor: a Class 6–12 or Beyond Class 12 learner.
• Content Author / Notes Editor — The provisioned role that generates, validates, quality-checks, publishes, edits, and versions prepared content.
• Platform Administrator — The provisioned role that owns security rules, backend authorization and validation, AI abuse protection, secret management, the exam and syllabus catalog, monitoring, and verification.
• Onboarding — The post-authentication step that collects name, class, subjects, examinations, language, and preferences, and resumes if incomplete.
• Mission — An independent preparation track created for each selected examination, containing exam information, verified syllabus, subjects, topics, prepared notes, practice, daily tasks, progress, remaining topics, important topics, revision, weak areas, and countdowns when official dates are available.
• Prepared Notes — Ready-made notes organized by Class → Subject → Book → Chapter → Topic, containing definitions, explanations, examples, tables, formulas, diagrams, flowcharts, quick revision, and important questions where relevant.
• Competitive / Career Notes — The exam-specific notes destination that replaces Prepared Notes for Beyond Class 12.
• Quiz — An NCERT-based practice session configured through Subject → Book → Chapter/Topic → Question Count → Start, with counts of 10, 50, 100, or a custom value between 1 and 100.
• Exercise — A practice session configured with single or multiple subjects, All Subjects, and 50/100 marks per subject, with balanced objective and subjective questions and accurate total marks.

• Test — A school-test record with subject, book, chapters, date, and time, supporting Prepare for Test.
• Examination — An examination record with name, multiple subjects, books, chapter selections or all chapters, syllabus, date, and time, supporting Prepare for Examination, Change Date, Postpone, Remove, and Cancel.
• AI Mentor — The assistant providing Explain Topic, Ask Doubt, Make Study Plan, Revise Me, Analyze Mistakes, and Ask Anything, using the Student's authorized context and adapting to class level in English, Hindi, or Hindi + English.
• Study Planner — The destination where AI-generated study plans are stored, adjusted, and worked from.
• Solve Homework — The action that passes a selected stored homework item directly to AI Mentor.
• Generate → Validate → Quality Check → Publish — The mandatory four-stage pipeline that AI-generated prepared content must pass before being presented to students as approved prepared content.
• Beyond Class 12 — The single class option above Class 12, receiving exam-specific Competitive / Career Notes.
• Class isolation — The rule that educational records are scoped by class, preserved when the class changes, and restored when the class is revisited.
• April 1 advancement — The automatic annual advancement of eligible classes on April 1, preserving previous records, with manual switching still available.