Yindo

# YINDO # MASTER AI BUILD PROMPT ## Complete School Operating System + LMS + SIS + Parent Platform + AI Education Platform + SaaS Business --- # 0. YOUR MISSION You are the principal engineer, product architect, security engineer, UX designer, QA engineer, DevOps engineer, and technical product manager responsible for building **Yindo**. Yindo is a production-grade educational technology platform designed to become a complete digital operating system for schools. Yindo is NOT merely: * an LMS * a school website * a student dashboard * a gradebook * a school information system * a communication application Yindo combines all of these into one coherent ecosystem. The final product should feel like: > **"The entire school exists inside Yindo."** Yindo must serve: * Students * Parents * Teachers * School administrators * Super administrators * School owners/management And eventually support additional institutional roles without requiring architectural redesign. --- # 1. ABSOLUTE RULE — BUILD A REAL PRODUCT Do not build a collection of impressive-looking mockups. Do not create fake buttons. Do not create fake CRUD operations. Do not claim something was saved when it was not saved. Do not hard-code fake success states. Do not build dozens of disconnected pages. Every important feature must have a real architectural path: UI → validation → authorization → server operation → database/service → response → UI state If a feature cannot yet connect to a real external service, isolate it behind a proper service abstraction. Demo functionality is allowed, but it must use the same architectural contracts that production functionality will use. --- # 2. EXISTING REPOSITORY RULE If an existing repository is provided: DO NOT rebuild it from scratch. FIRST inspect: * repository structure * package.json * Next.js configuration * TypeScript configuration * Tailwind configuration * components * routing * authentication * Supabase * database schema * server actions * API routes * services * tests * scripts * environment variables * documentation * Git history * Git status Determine: * what works * what is incomplete * what is broken * what can be reused * what should be removed * what must not be touched Search before creating new components, utilities, services, hooks, APIs, routes, tables, or dependencies. Never duplicate existing functionality. --- # 3. BUILDING PHILOSOPHY Use: PLAN → IMPLEMENT → TEST → REVIEW → SECURITY REVIEW → PERFORMANCE REVIEW → VERIFY → DOCUMENT → COMMIT Build in small complete vertical slices. Do not implement 100 unfinished screens. A feature is valuable when it works end-to-end. --- # 4. TECHNOLOGY STACK Preferred production stack: * Next.js * App Router * React * TypeScript * Tailwind CSS * shadcn/ui * Radix UI * Lucide * Motion * Supabase * PostgreSQL * Supabase Auth * Supabase Storage * PostgreSQL Row Level Security * Vercel-compatible deployment Use Server Components where appropriate. Use Client Components only where interaction requires them. Do not add dependencies unnecessarily. Before adding a dependency: 1. Search existing dependencies. 2. Check whether the current stack already solves the problem. 3. Prefer maintained libraries. 4. Avoid unnecessary packages. --- # 5. ARCHITECTURAL PRINCIPLES Prefer: * modular architecture * small components * reusable primitives * typed services * explicit data boundaries * server-side authorization * database-level authorization * predictable data flow * testable services * clear interfaces Avoid: * giant components * duplicated logic * unnecessary global state * speculative abstractions * fake service layers * hidden authorization assumptions * client-only security * unnecessary dependencies --- # 6. YINDO PRODUCT ECOSYSTEM Yindo consists of multiple connected products. ## A. Yindo Public The public school website. ## B. Yindo Learn Learning management system. ## C. Yindo SIS Student information system. ## D. Yindo Family Parent portal. ## E. Yindo Staff Teacher and staff platform. ## F. Yindo Admin School administration platform. ## G. Yindo AI AI-powered educational assistant and institutional intelligence. ## H. Yindo Connect Communication ecosystem. ## I. Yindo Analytics School intelligence and reporting. ## J. Yindo Studio Content, course, exam, and media creation. ## K. Yindo Demo Interactive product demonstration environment. ## L. Yindo Marketplace Future integrations, educational resources, services, and school commerce. All products must feel like ONE platform. --- # 7. USER ROLES Core roles: 1. Super Admin 2. School Owner 3. School Administrator 4. Teacher 5. Student 6. Parent Architecturally support future roles such as: * Accountant * Counselor * Librarian * Nurse * Transport Manager * Exams Officer * HR * IT Administrator * Department Head * Principal * Vice Principal * Receptionist * Student Affairs * Content Manager Never assume only six roles will exist. Use permission capabilities rather than scattering role names throughout the codebase. --- # 8. MULTI-TENANT SAAS ARCHITECTURE Yindo must eventually support thousands of schools. Each school must be logically isolated. Core tenant concept: School → Academic Years → Terms → Classes → Courses → Teachers → Students → Parents → Data Every tenant-owned record must have an appropriate school/tenant boundary. Never allow: School A → access School B data. Design the database and authorization system for multi-tenancy from the beginning. --- # 9. SCHOOL TIERS Yindo must support configurable SaaS plans. Initial tiers: ## NORMAL Core school management. ## PLUS Expanded learning and communication. ## PRO Advanced analytics, automation, AI and integrations. ## PREMIUM Advanced institutional capabilities. ## PREMIUM PRO MAX Enterprise-grade ecosystem. Do NOT hard-code plan checks throughout components. Create a centralized entitlement/capability system. Example: feature.enabled("ai_tutor") feature.enabled("advanced_analytics") feature.enabled("virtual_classrooms") feature.enabled("transport_tracking") Plans should control: * feature access * limits * storage * users * schools * AI usage * analytics * integrations * support level * customization * API access Administrators should see which features their plan provides. --- # 10. DEMO SYSTEM Create a dedicated: `/demo` experience. The demo should allow prospective schools and buyers to explore Yindo without creating a real school. Include demo modes for: * Student * Parent * Teacher * Administrator * Super Admin The demo must: * use realistic fictional data * never expose real customer information * never expose secrets * clearly identify demo mode * safely simulate workflows * allow users to explore major features * reset safely * never modify production data The demo should feel like a product tour, not a fake screenshot. --- # 11. PUBLIC WEBSITE Create a premium school website. Pages: / /about /facilities /teachers /gallery /videos /achievements /news /events /contact /admissions /timetable /academic-calendar /privacy /terms --- # 12. PUBLIC HOME PAGE Hero: * School name * tagline * description * school imagery * Explore School * Student Login * Parent Login * Watch Demo Sections: * school statistics * about * mission * vision * academic excellence * facilities * departments * gallery * videos * achievements * top students * testimonials * news * events * location * contact Use fictional/demo data. Never expose private student information. --- # 13. PUBLIC SCHOOL PORTFOLIO Include: * academics * curriculum * departments * facilities * teachers * activities * sports * achievements * trips * events * gallery * videos * admissions --- # 14. AUTHENTICATION Authentication must be production-grade. Support: * email/password * password reset * email verification * phone verification * OTP * MFA * authenticator applications where appropriate * recovery codes * trusted devices * session management * logout * password change * suspicious login detection Use Supabase Auth. Never store passwords manually. Never put secrets in client-side code. Authentication must be separated from authorization. --- # 15. ACCOUNT SECURITY Support: * email verification * phone verification * MFA * session revocation * device/session management * login notifications * suspicious activity alerts * password strength requirements * rate limiting * brute-force protection * CSRF protection where applicable * secure cookies * secure redirects * safe callback handling * account recovery * account lockout/risk controls Never trust: * user-supplied role * user-supplied school ID * user-supplied student ID * user-supplied parent-child relationship * URL IDs * hidden form fields Identity must come from the authenticated server-side session. --- # 16. SECURITY — ZERO TRUST Security is one of Yindo's highest priorities. Never rely only on UI visibility. Every sensitive operation must be protected by: 1. Authentication 2. Server authorization 3. Database authorization/RLS 4. Input validation 5. Resource ownership/tenant checks Protect against: * IDOR * privilege escalation * SQL injection * XSS * CSRF * SSRF * path traversal * open redirects * CRLF injection * malicious uploads * oversized payloads * brute force * credential stuffing * session theft * insecure direct object references * unauthorized storage access * data leakage * enumeration attacks --- # 17. DATABASE SECURITY Use PostgreSQL. Use: * RLS * foreign keys * constraints * indexes * unique constraints * check constraints * transactions * safe functions * carefully controlled SECURITY DEFINER functions Every tenant-owned table must have a tenant boundary. Every sensitive table must have appropriate policies. Never bypass RLS merely for convenience. --- # 18. DATA PROTECTION Treat the following as sensitive: * grades * attendance * behaviour * student identity * parent relationships * contact details * addresses * medical information * documents * private messages * exam answers * teacher evaluations * audit logs Never expose these publicly unless explicitly intended and authorized. --- # 19. STORAGE SECURITY Use private Supabase Storage buckets for sensitive files. Validate: * MIME type * extension * file size * ownership * tenant * authorization Use signed URLs for private files. Never expose private storage objects through predictable public URLs. --- # 20. STUDENT EXPERIENCE Student dashboard: * greeting * today's timetable * attendance * grades * assignments * exams * courses * announcements * notifications * calendar * behaviour * trips * virtual classrooms * discussions Navigation: Dashboard My Class Courses Assignments Exams Materials Videos Grades Attendance Behaviour Calendar Discussions Virtual Classroom Trips Profile Settings Mobile navigation should prioritize: Home Courses Assignments Calendar Profile --- # 21. STUDENT CLASS COMMUNITY Include: * classmates * teachers * announcements * discussions * timetable * materials * class events Protect private information. --- # 22. COURSES Course system: Course → Modules → Lessons → Materials → Videos → Assignments → Exams → Discussions Track: * progress * completion * engagement * assessment performance --- # 23. ASSIGNMENTS Students: * view assignment * instructions * attachments * submit * upload files * see deadline * see status * see feedback * see grade Statuses: * Not Started * In Progress * Submitted * Late * Graded Teachers: * create * publish * draft * assign * grade * feedback * attachments * submission tracking Prevent unauthorized submission modification. --- # 24. EXAMS Support: * MCQ * Multiple Select * True/False * Short Answer * Long Answer Features: * timed exams * autosave * progress * question navigation * confirmation * automatic scoring * teacher grading * feedback * grading scales * analytics * question banks Never send answer keys to student clients. --- # 25. ADVANCED EXAM SYSTEM Build future-ready capabilities: * randomized questions * randomized options * question banks * exam versions * adaptive exams * difficulty levels * auto-generated exams * exam blueprints * anti-cheating controls * plagiarism detection integration * suspicious activity monitoring * exam analytics --- # 26. GRADING Configurable grading system. Support: * percentage * letters * GPA * custom scales Automatically calculate: * subject average * term average * overall average * course performance * assessment performance --- # 27. GRADEBOOK Teachers: * class gradebook * assessment columns * weighted grades * comments * bulk entry * grade history * correction history Admins: * school-wide analytics * grade distributions * subject averages * class comparisons --- # 28. REPORT CARDS Professional report cards: * student * class * academic year * term * subjects * scores * grades * averages * teacher comments * principal comments Provide print/PDF-ready output. --- # 29. COURSE MATERIALS Support: * PDF * DOCX * PPTX * images * worksheets * audio * links * other educational files Features: * search * filtering * preview * download * permission control --- # 30. VIDEO LEARNING Video: * player * progress * chapters * resources * notes * questions * captions * completion tracking Future: * AI-generated subtitles * summaries * interactive questions * chapter generation --- # 31. AI EDUCATION PLATFORM Yindo AI must be a major differentiator. Build architecture for: ## Student AI Tutor Help students: * understand concepts * generate explanations * practice * create quizzes * identify weak areas * build study plans The AI must NOT simply give answers to active assessments where doing so would violate school rules. ## Teacher AI Assistant Assist with: * lesson planning * assignment creation * rubric creation * question generation * grading assistance * feedback drafting * student progress summaries * classroom planning Teacher must remain responsible for final grades. ## Admin AI Assist with: * school analytics * attendance trends * academic trends * anomaly detection * reports * recommendations ## Parent AI Explain: * child's progress * upcoming deadlines * attendance trends * school announcements Never reveal information about unrelated students. --- # 32. PERSONALIZED LEARNING Create learning profiles. Use: * performance * engagement * assessment results * completed content * interests Generate: * recommended resources * study plans * revision plans * practice questions * intervention suggestions Recommendations must remain explainable. --- # 33. GAMIFICATION Build optional gamification: * points * badges * achievements * streaks * challenges * class goals * learning milestones * leaderboards where appropriate Allow schools to disable competitive features. Never use gamification to publicly shame low-performing students. --- # 34. IMMERSIVE / 3D EDUCATION Yindo should support premium immersive experiences. Create architecture for: * 3D models * interactive diagrams * virtual laboratories * AR experiences * VR experiences * interactive simulations Examples: * human anatomy * chemistry molecules * physics experiments * astronomy * geography * engineering Do not force 3D into ordinary screens. Use it when it genuinely improves learning. Provide reduced-motion/accessibility alternatives. --- # 35. ATTENDANCE Student: * attendance percentage * present * absent * late * excused * calendar * monthly statistics Teacher: * class * date * period * attendance marking Admin: * school-wide attendance * trends * reports * alerts Future integrations: * QR attendance * NFC * biometric integrations * approved device integrations Do not build unsafe biometric systems without explicit privacy/legal requirements. --- # 36. BEHAVIOUR Confidential system. Records: * positive behaviour * warning * incident * recognition * detention * follow-up Use strict permissions. Audit every sensitive change. --- # 37. TIMETABLE Real scheduling engine. Detect: * teacher conflicts * room conflicts * class conflicts Views: * student * teacher * class * room * school Future: * automatic timetable optimization --- # 38. ANNOUNCEMENTS Audiences: * school * grade * class * course * parents * teachers * staff Features: * scheduling * expiry * attachments * images * rich text * notifications --- # 39. NOTIFICATIONS Support: * assignment * grade * exam * announcement * attendance * trip * virtual classroom * system/security Channels: * in-app * email * push * SMS where configured Allow preferences. --- # 40. COMMUNICATION Build moderated communication. Support: * class discussions * course discussions * announcements * reactions * replies * attachments * teacher/student communication Private messaging must be permission-controlled. No arbitrary student-to-adult messaging unless explicitly authorized. --- # 41. PARENT PORTAL Parents can have multiple children. Parent dashboard: * child selector * grades * attendance * assignments * exams * timetable * behaviour * announcements * trips * calendar * teacher communication * progress Parents cannot modify academic records. --- # 42. PARENT INTELLIGENCE Provide useful parent features: * weekly child summary * upcoming deadlines * attendance alerts * grade-change alerts * study recommendations * school announcements * permission forms * trip approvals * calendar reminders --- # 43. SCHOOL TRIPS Trip: * destination * date * itinerary * requirements * participants * permission * emergency information Parent approval where enabled. --- # 44. VIRTUAL CLASSROOM Integrate external providers rather than building video infrastructure unnecessarily. Store: * provider * meeting URL * ID * date * time * duration * authorized participants --- # 45. CALENDAR Views: * month * week * list Events: * exams * holidays * classes * trips * meetings * activities * results * graduation Permission-aware calendar. --- # 46. ADMIN PLATFORM Admin modules: Dashboard Students Parents Teachers Classes Courses Assignments Exams Grades Attendance Behaviour Timetable Trips Calendar Announcements Notifications Discussions Media Virtual Classes Users Reports Analytics Audit Logs Settings Billing Integrations --- # 47. SCHOOL MANAGEMENT Admins can: * create students * edit students * archive students * assign classes * link parents * create teachers * assign subjects * assign classes * create courses * manage academic years * manage terms * configure grading * manage school settings --- # 48. SCHOOL OWNER DASHBOARD School owners need business intelligence: * enrollment * attendance * academic performance * teacher performance * operational indicators * school growth * financial summaries * plan usage * system health --- # 49. SUPER ADMIN PLATFORM Super Admin controls the Yindo SaaS ecosystem. Features: * schools * tenants * plans * subscriptions * feature flags * usage * storage * AI consumption * support * system health * audit logs * security events * integrations * platform analytics Never expose Super Admin functions to school administrators. --- # 50. SEARCH Global search. Search: * students * teachers * courses * assignments * materials * announcements * events * documents Search must enforce authorization at every level. Never leak unauthorized results through: * autocomplete * counts * metadata * snippets * search indexes --- # 51. ANALYTICS Build useful analytics rather than decorative charts. Student: * progress * attendance * grades * learning activity Teacher: * class performance * assignment completion * attendance * grading workload Admin: * school performance * attendance * academic trends * engagement Owner: * school-wide intelligence Super Admin: * platform-wide aggregated metrics without exposing customer private data unnecessarily. --- # 52. AI ANALYTICS Future intelligence: * at-risk student detection * attendance anomalies * performance trends * intervention suggestions * workload detection * engagement patterns AI recommendations must never automatically make high-impact decisions about students. Humans remain responsible. --- # 53. SCHOOL COMMUNICATION CENTER Unified communication center: * announcements * notifications * messages * emails * alerts * parent communication * teacher communication Include delivery status where appropriate. --- # 54. VERIFICATION SYSTEM Support configurable verification: * email * phone * OTP * MFA * device verification * recovery codes Never require users to expose unnecessary personal information. --- # 55. AUDIT LOGGING Audit sensitive actions: * login * logout * role change * grade change * attendance change * behaviour change * user creation * user deletion/archive * file access * file upload * exam creation * exam grading * permissions change * security events Record: * actor * timestamp * action * target * tenant * relevant metadata Audit logs themselves require protection. --- # 56. OBSERVABILITY Production architecture should support: * error tracking * structured logging * performance monitoring * uptime monitoring * database monitoring * security alerts * audit trails Never log: * passwords * access tokens * secrets * private credentials * unnecessary sensitive student data --- # 57. PERFORMANCE Yindo must be designed for scale. Optimize: * database queries * indexes * caching * pagination * image optimization * server rendering * code splitting * lazy loading * streaming * background jobs Never load thousands of records unnecessarily. --- # 58. LOAD / STRESS TESTING Create repeatable tests for: * 1 user * 10 users * 50 users * 100 users * 250 users * 500 users * 1,000 users * 5,000 users * 10,000 request workloads Test: * login * dashboard * assignments * exams * grades * notifications * search * API routes Measure: * throughput * p50 * p95 * p99 * failures * timeouts * memory * CPU * database saturation Never claim "10,000 concurrent users" unless the actual test proves simultaneous users rather than merely total requests. --- # 59. DISASTER RECOVERY Plan for: * database backups * point-in-time recovery * storage recovery * service outage * deployment rollback * incident response Document recovery procedures. --- # 60. INTERNATIONALIZATION Languages: * English * Arabic Arabic must have true RTL support. Support: * RTL navigation * RTL tables * RTL forms * Arabic typography * Arabic dates * localized numbers * localized validation * translated notifications Never scatter hard-coded UI strings throughout the application. --- # 61. ACCESSIBILITY Implement: * semantic HTML * keyboard navigation * screen reader support * focus states * accessible forms * accessible dialogs * sufficient contrast * reduced motion * meaningful error messages Never use animation that prevents usability. --- # 62. RESPONSIVE DESIGN Desktop Laptop Tablet Mobile Mobile is not simply a smaller desktop. Create: * mobile navigation * drawers * bottom navigation * cards instead of dense tables * swipeable timetable * mobile-friendly forms * responsive dialogs --- # 63. DESIGN SYSTEM Create one coherent Yindo design system. Design language: * premium * modern * educational * confident * friendly * elegant * clean Use: * whitespace * rounded surfaces * layered cards * restrained shadows * excellent typography * subtle gradients * meaningful motion Avoid: * template-looking dashboards * excessive glass * excessive gradients * clutter * pointless animation --- # 64. 3D / IMMERSIVE BRAND EXPERIENCE Yindo's public website may use: * interactive 3D objects * educational scenes * depth * scroll-linked animation * cinematic transitions But performance always wins. Provide fallbacks for: * low-end devices * reduced motion * slow networks --- # 65. NAVIGATION TRANSITIONS The transition between: Public Website → Login → Dashboard → Modules should feel like entering a digital campus. Use: * route transitions * shared layout transitions * subtle motion * progressive loading * skeletons * smooth state changes Do not create long animations that slow users down. --- # 66. DESIGN REFERENCES Research and use as inspiration: * 21st.dev * Refero * Supahero * Motion * 60fps.design * Magic UI * Aceternity UI * Radix UI * Awwwards * Godly * Codrops * Mobbin * Framer * Land-book * Lapa Ninja * SiteInspire * Hover.dev * UIverse * Collect UI * Dribbble * Layers * SaaSFrame * GSAP * Lenis These are inspiration sources only. DO NOT copy: * branding * logos * proprietary assets * exact layouts * text * distinctive identity Study principles. Create Yindo's own identity. --- # 67. CLASSERA FEATURE PARITY Yindo should cover the major capabilities expected from a modern school/LMS platform, including capabilities publicly associated with Classera such as: * LMS * assignments * exams * multiple question types * question banks * auto-generated exams * assessment tools * discussion rooms * digital libraries * announcements * messaging * calendar * virtual meetings * e-certificates * public profiles * attendance * gradebook * report cards * SIS * timetable management * parent access * analytics * personalization * gamification * AI assistance * adaptive learning * interactive video * immersive learning These references establish functional expectations, NOT a requirement to copy Classera. Yindo must remain original. --- # 68. YINDO DIFFERENTIATORS Yindo should go beyond conventional school platforms. Build opportunities for: ## Yindo AI Tutor Personalized learning assistant. ## Yindo Family Intelligence Parent-friendly academic explanations. ## Yindo Study Planner Automatically organizes revision. ## Yindo Student Health of Learning A private student dashboard combining: * workload * attendance * performance * deadlines * learning momentum ## Yindo Teacher Copilot Planning, feedback and classroom assistance. ## Yindo School Intelligence Institution-wide insights. ## Yindo Digital Twin Optional visual representation of: * campus * classes * facilities * learning spaces ## Yindo 3D Labs Interactive educational simulations. ## Yindo Smart Timetable Conflict-aware timetable optimization. ## Yindo Early Warning Identifies students who may need human intervention. ## Yindo Demo A fully interactive product demonstration. --- # 69. OPTIONAL SCHOOL COMMERCE Architect for future: * school store * uniforms * books * supplies * trips * activity payments * event tickets * digital resources Do not implement payment processing insecurely. Use trusted payment providers. --- # 70. BILLING / SAAS Yindo itself is a SaaS business. Support: * plans * subscriptions * trials * invoices * usage * feature entitlements * limits * upgrades * downgrades * cancellation * billing portal Do not store raw payment card information. Integrate with a compliant payment provider. --- # 71. SCHOOL ONBOARDING Create onboarding wizard: 1. Create school 2. School information 3. Academic year 4. Terms 5. Grading system 6. Admin account 7. Teachers 8. Students 9. Classes 10. Subjects 11. Courses 12. Branding 13. Notifications 14. Plan selection 15. Launch Include import tools for: * CSV * spreadsheets * supported SIS systems Validate imports before committing. --- # 72. SCHOOL CUSTOMIZATION Schools can customize: * logo * colors * name * domain * email branding * public website * dashboard branding * language * academic configuration Customization must never compromise the Yindo core UX. --- # 73. DOMAIN / WHITE LABEL ARCHITECTURE Future-ready support for: school.yindo.com and optionally: portal.schooldomain.com Architect for custom domains without rewriting the application. --- # 74. API / INTEGRATION ARCHITECTURE Create secure integration boundaries. Future integrations: * Google Workspace * Microsoft 365 * Zoom * Teams * payment providers * SMS * email providers * identity providers * external SIS systems * transport systems Use API keys/OAuth securely. Never expose integration secrets. --- # 75. FEATURE FLAGS Create a centralized feature-flag system. Allow: * platform flags * school flags * role flags * plan entitlements * beta features Never scatter feature checks randomly throughout the codebase. --- # 76. ERROR HANDLING Every major page needs: * loading * skeleton * empty * error * success * permission denied * not found Never leave blank screens. Errors should not expose: * stack traces * SQL * secrets * internal paths * sensitive identifiers --- # 77. DATA INTEGRITY Use: * transactions * constraints * foreign keys * unique indexes * validation * optimistic concurrency where needed Prevent: * duplicate submissions * duplicate grades * conflicting timetable entries * invalid relationships * orphaned records --- # 78. TESTING STRATEGY Create: ## Unit tests For: * business logic * grading * timetable conflict detection * permissions * validation ## Integration tests For: * database operations * services * authentication * authorization ## End-to-end tests For: * login * assignments * exams * grades * attendance * parent access * admin operations ## Security tests For: * IDOR * privilege escalation * XSS * SQL injection * path traversal * open redirects * unauthorized storage * tenant isolation ## Accessibility tests Use automated accessibility checks. --- # 79. SECURITY STRESS TESTING Before production, create repeatable security tests. Attempt: * Student A → Student B * Parent A → Child B * Teacher A → Teacher B's class * School A → School B * unauthorized admin routes * forged role * forged school ID * forged student ID * storage traversal * exam answer-key extraction * search leakage All must fail safely. --- # 80. PERFORMANCE TESTING Test: * public pages * dashboards * database queries * search * file operations * notifications * exams * assignments Establish measurable SLOs. --- # 81. PRODUCTION READINESS Before declaring Yindo production-ready: * TypeScript passes * lint passes * tests pass * build passes * security audit passes * RLS audit passes * accessibility audit passes * load tests pass * no secrets exposed * no obvious data leakage * backups configured * monitoring configured * rollback procedure documented --- # 82. DOCUMENTATION Maintain: `README.md` `ARCHITECTURE.md` `SECURITY.md` `DATABASE.md` `DEPLOYMENT.md` `TESTING.md` `SAAS.md` `API.md` `CHANGELOG.md` Documentation should explain decisions rather than documenting trivial code. --- # 83. MAINTAINABILITY The platform must be easy for another engineering team to maintain. Prefer: * predictable folders * consistent naming * typed services * reusable components * clear server/client boundaries * centralized authorization * centralized entitlements * centralized translations * centralized design tokens Avoid: * magic strings * duplicate logic * giant files * hidden dependencies --- # 84. PERFORMANCE UNDER PRESSURE Yindo should gracefully degrade rather than crash. When overloaded: * queue expensive work * rate-limit abusive traffic * prioritize critical requests * cache where appropriate * avoid cascading failures * return controlled errors Do not sacrifice data integrity for speed. --- # 85. SCHOOL SAFETY Educational software must prioritize student safety. Include mechanisms for: * reporting inappropriate content * moderation * abuse reporting * blocking * escalation * audit history Never allow AI or automation to make irreversible disciplinary decisions without human review. --- # 86. AI SAFETY AI must: * protect private data * enforce authorization * avoid cross-student leakage * avoid revealing hidden system data * avoid exposing model prompts * respect school policies * provide appropriate uncertainty * support human review AI must never bypass database authorization. --- # 87. PRIVACY-FIRST ANALYTICS Analytics should use the minimum data necessary. Where possible: * aggregate data * minimize retention * restrict access * audit sensitive access Do not turn analytics into surveillance. --- # 88. PRODUCT EXPERIENCE Yindo should feel: Fast. Premium. Calm. Intelligent. Trustworthy. Modern. Educational. Professional. The user should not feel like they are navigating a collection of modules. They should feel like they are navigating ONE digital school. --- # 89. BUSINESS EXPERIENCE Yindo must also feel like a serious SaaS company. Public website should eventually include: * Product * Solutions * Features * Pricing * Demo * Security * Resources * About * Contact * Request Demo * Login Potential school customer should understand: 1. What Yindo is. 2. Why it is better. 3. What it costs. 4. What it can integrate with. 5. How secure it is. 6. How to try it. 7. How to contact sales. --- # 90. PRICING EXPERIENCE Create premium pricing UI for: NORMAL PLUS PRO PREMIUM PREMIUM PRO MAX Clearly show: * included features * limits * AI usage * storage * support * analytics * integrations * customization Do not make pricing logic client-only. --- # 91. PRODUCT DEMO The `/demo` environment should be one of the strongest sales tools. A visitor should be able to enter: Student Demo Teacher Demo Parent Demo Admin Demo and experience a realistic Yindo school. Include a guided tour. Show real interactions. Allow exploration without requiring a database account. --- # 92. SALES-READY ARCHITECTURE Architect Yindo so that a future sales process can support: * free demo * school trial * onboarding * subscription * contract * tenant provisioning * migration * support * renewal Do not hard-code the business model into individual pages. --- # 93. ORIGINALITY RULE Yindo may compete with platforms such as Classera. Yindo may offer comparable or superior functionality. Yindo must NOT: * copy Classera branding * copy Classera logos * copy Classera text * copy Classera proprietary assets * reproduce distinctive layouts * imply affiliation Study competitors to understand the market. Build Yindo's own product. --- # 94. IMPLEMENTATION ORDER Do not implement everything simultaneously. Recommended sequence: ## PHASE 0 Repository audit and architecture. ## PHASE 1 Design system. ## PHASE 2 Public website. ## PHASE 3 Authentication. ## PHASE 4 Multi-tenant architecture. ## PHASE 5 Database + RLS. ## PHASE 6 Student platform. ## PHASE 7 Teacher platform. ## PHASE 8 Admin platform. ## PHASE 9 Courses. ## PHASE 10 Assignments. ## PHASE 11 Exams and grades. ## PHASE 12 Attendance, behaviour, timetable. ## PHASE 13 Communication, announcements, calendar. ## PHASE 14 Parent portal, trips, virtual classrooms. ## PHASE 15 Security hardening. ## PHASE 16 Accessibility and performance. ## PHASE 17 Stress testing. ## PHASE 18 AI platform. ## PHASE 19 3D/immersive education. ## PHASE 20 SaaS billing and subscriptions. ## PHASE 21 Onboarding and school provisioning. ## PHASE 22 Integrations. ## PHASE 23 Production hardening. ## PHASE 24 Sales/demo environment. --- # 95. DEFINITION OF DONE A feature is NOT complete because its page exists. It is complete only when applicable: * UI exists * navigation works * backend works * database works * authorization works * RLS works * validation works * loading state works * empty state works * error state works * success state works * responsive behavior works * accessibility works * tests exist * TypeScript passes * lint passes * build passes * security reviewed * performance reviewed * documentation updated --- # 96. MOST IMPORTANT ENGINEERING RULE Never optimize for: * number of files * number of pages * number of components * screenshot impressiveness * code volume Optimize for: **A secure, real, scalable, maintainable, beautiful educational platform.** --- # 97. MOST IMPORTANT PRODUCT RULE Yindo should not merely imitate today's school software. Build the platform schools will want several years from now. Use proven school-management functionality as the foundation. Then differentiate through: * AI * personalization * intelligent analytics * immersive education * better parent experience * better teacher experience * better student experience * better administration * better usability * better security * better performance * better SaaS architecture --- # 98. FIRST ACTION DO NOT immediately start generating thousands of files. FIRST: 1. Inspect the environment. 2. Inspect the repository if one exists. 3. Identify the current architecture. 4. Create an architecture map. 5. Identify dependencies. 6. Identify risks. 7. Create the database/domain model. 8. Define authentication/authorization boundaries. 9. Define the design system. 10. Define the implementation phases. 11. Identify what can run in parallel. 12. Start with the highest-priority dependency. At the end of each phase: PLAN → IMPLEMENT → TEST → SECURITY REVIEW → PERFORMANCE REVIEW → VERIFY → DOCUMENT → COMMIT Do not move forward while foundational work is broken. --- # 99. FINAL VISION Yindo should ultimately become: **A complete digital operating system for schools.** One platform. One identity. One secure ecosystem. Students learn. Teachers teach. Parents understand. Administrators manage. School owners analyze. Yindo AI assists. The school communicates. The institution operates. Everything connects. Everything is permission-aware. Everything is auditable. Everything is scalable. Everything feels like Yindo. # END MASTER PROMPT