You are a Senior Solution Architect, UI/UX Architect, Full-Stack Developer and Technical Lead. I want you to design and develop a production-ready application based on the attached M-TEER Workbook and project requirement documents. IMPORTANT: The attached documents are the PRIMARY SOURCE OF TRUTH for the educational/medical content. Do not invent, modify, reinterpret or replace medical content from the source documents. If a requirement is not available in the documents, clearly mark it as: "REQUIREMENT CLARIFICATION NEEDED" Do not silently make assumptions about medical content. ============================================================ 1. PROJECT OVERVIEW ============================================================ We are developing an interactive M-TEER educational application. The system will have THREE major components: 1. Flutter Mobile Application 2. React.js Admin Panel 3. Node.js + NestJS Backend/API Database: MySQL Storage: Object storage external storage folder Architecture: Flutter Mobile App | | HTTPS REST API | v Node.js + NestJS Backend | +----------------+ | | v v MySQL Object Storage | | React Admin Panel -------+ ============================================================ 2. MOST IMPORTANT REQUIREMENT ============================================================ THE ADMIN PANEL IS THE PRIMARY CONTENT MANAGEMENT SYSTEM. The application must be FULLY DATA-DRIVEN. The Flutter application must NOT contain hard-coded educational content. The Flutter application should contain: - Reusable UI components - Reusable activity components - Drawing engine - Annotation engine - Quiz engine - Decision-tree engine - Case-study engine - Content rendering engine - Progress engine - Offline/cache engine But the actual educational content must come from the backend/API. For example: Admin creates: Module I1 | +-- Lesson | +-- Text | +-- Image | +-- Video | +-- Drawing Activity | +-- Quiz | +-- Reflection Admin publishes it. Flutter automatically retrieves the new content from the API and displays it. NO Flutter code change should be required. NO new mobile application release should be required just because a new educational module was created. This is a CRITICAL architecture requirement. ============================================================ 3. ADMIN PANEL PURPOSE ============================================================ The React Admin Panel will be used to: - Create new content - Modify existing content - Delete/archive content - Reorder content - Upload media - Create modules - Create lessons - Create activities - Create drawing activities - Create colouring activities - Create annotation activities - Create measurement activities - Create quizzes - Create MCQs - Create case scenarios - Create decision trees - Create procedural steps - Create complication scenarios - Create reflection activities - Manage quick-reference content - Publish content - Unpublish/archive content - Preview content before publishing - Manage users - Manage roles - Manage permissions - View audit logs - View analytics The Admin Panel must behave like a CMS/content-management platform, not simply a reporting dashboard. ============================================================ 4. ADMIN ROLE AND ACCESS MANAGEMENT ============================================================ The Admin Panel requires login. Implement: - Email/password login - JWT authentication - Refresh token - Logout - Password reset - Account activation/deactivation - Role-based access control - Permission-based authorization - Audit logs Suggested roles: SUPER_ADMIN CONTENT_ADMIN MEDICAL_EDITOR CONTENT_REVIEWER MEDIA_MANAGER REPORT_VIEWER Do NOT hard-code roles in the application. Implement: Users Roles Permissions UserRoles RolePermissions Example permissions: dashboard.view section.view section.create section.update section.delete section.publish module.view module.create module.update module.delete module.publish lesson.view lesson.create lesson.update lesson.delete lesson.publish activity.view activity.create activity.update activity.delete activity.publish media.view media.upload media.update media.delete case.view case.create case.update case.delete case.publish decision_tree.view decision_tree.create decision_tree.update decision_tree.delete decision_tree.publish user.view user.create user.update user.delete role.view role.create role.update role.delete audit.view analytics.view settings.view settings.update Authorization must be enforced on the backend. Frontend permission checks are only for UI visibility and usability. ============================================================ 5. MOBILE LOGIN REQUIREMENT ============================================================ The Flutter mobile application must NOT require login. Users should be able to: - Open the app - Browse modules - Read content - Watch videos - Perform activities - Draw - Annotate - Complete quizzes - Create educational cases - Save notes - Track progress without creating an account. For progress synchronization, use an anonymous device/session identifier if required. Do not require email/password for normal mobile users. ============================================================ 6. SOURCE CONTENT STRUCTURE ============================================================ The supplied M-TEER Workbook contains the major learning sections. Use the exact structure and terminology from the source document. The workbook includes: SECTION A — KNOW IT Anatomy Drawing Modules A1 — The Mitral Valve Apparatus: Build It from Scratch A2 — Scallop Segmentation Map A3 — The Subvalvular World A4 — The Mitral Valve in 3D Space SECTION B — SEE IT Echo Tracing & Interpretation B1 — TEE View Tracing Library B2 — Measure It Yourself B3 — Jet Location Map SECTION C — MAP IT Pathology Classification C1 — Carpentier Classification Drawing Pages C2 — DMR vs. SMR Side-by-Side Sketch C3 — Barlow's Disease Anatomy Map SECTION D — PLAN IT Pre-Procedural Case Planning D1 — The TEER Case Planning Sheet D2 — The “TEER-able or Not?” Decision Tree Sketchpad D3 — Challenging Anatomy Sketchbook SECTION E — DO IT Procedural Step Visualisation E1 — The Transseptal Puncture Map E2 — Clip Positioning: The Approach Vector E3 — The Double-Clip Strategy Map E4 — The “Perfect Clip” vs. “Acceptable Clip” Illustration SECTION F — FIX IT Complication Scenario Mapping F1 — Complication Recognition Cards F2 — My Toughest Cases Log SECTION G — COLOUR IT Creative Studio G1 — The Living Valve — Full Anatomical Colouring Plates G2 — The Echo Art Studio G3 — Build Your Own MitraClip G4 — The Heart Team Ecosystem — Visual Map SECTION H — OWN IT Personal Reflection H1 — My Fellowship Timeline H2 — “Maisano's Teachings” — My Personal Collection H3 — My 100 Cases Log H4 — Letter to My Future Self Also implement: Quick Reference - Anatomy Quick Map - Procedure Checklist IMPORTANT: Before implementation, inspect the attached documents and extract the COMPLETE content hierarchy. Do not assume the above list is complete if the source documents contain additional activities/pages/content. ============================================================ 7. CONTENT HIERARCHY ============================================================ Use the following generic content architecture: Section | +-- Module | +-- Lesson | +-- Activity | +-- Content Blocks Example: Section A | +-- Module A1 | +-- Introduction +-- Learning Goal +-- Instructions +-- Image +-- Drawing Activity +-- Clinical Insight +-- Reflection The system must support arbitrary future modules. ============================================================ 8. DYNAMIC CONTENT BLOCK SYSTEM ============================================================ Create reusable content block types. At minimum: TEXT HEADING IMAGE VIDEO AUDIO INFO_BOX INSTRUCTION CLINICAL_INSIGHT QUOTE CHECKLIST DRAWING_CANVAS COLOURING_CANVAS ANNOTATION_CANVAS MEASUREMENT_TABLE FORM QUIZ MCQ DECISION_TREE CASE_SCENARIO PROCEDURE_STEP REFLECTION REFERENCE The exact content should be configurable through Admin Panel. Example API response: { "type": "DRAWING_CANVAS", "title": "Drawing Canvas", "instructions": "...", "templateUrl": "...", "allowUndo": true, "allowRedo": true, "allowClear": true, "allowSave": true } Flutter should map the type to a reusable widget. Example: TEXT -> TextBlockWidget IMAGE -> ImageBlockWidget VIDEO -> VideoBlockWidget DRAWING_CANVAS -> DrawingCanvasWidget COLOURING_CANVAS -> ColoringCanvasWidget QUIZ -> QuizWidget DECISION_TREE -> DecisionTreeWidget CASE_SCENARIO -> CaseScenarioWidget REFLECTION -> ReflectionWidget ============================================================ 9. ADMIN CONTENT CREATION ============================================================ Admin must be able to create a completely new module. Example: Admin Panel Sections -> Add Section Section I -> Add Module Module I1 -> Add Lesson Lesson 1 -> Add Activity Activity Type: DRAWING_CANVAS Admin enters: Title Description Instructions Background Template Canvas Size Allowed Colours Stroke Width Allow Eraser Allow Undo Allow Redo Allow Save Admin clicks: SAVE DRAFT Then: PREVIEW Then: SUBMIT FOR REVIEW Then authorized reviewer: APPROVE Then authorized publisher: PUBLISH After publishing: Flutter automatically displays the module. ============================================================ 10. CONTENT STATUS ============================================================ Implement: DRAFT IN_REVIEW PUBLISHED ARCHIVED Only PUBLISHED content should be available to normal mobile users. Admin users should be able to preview DRAFT and IN_REVIEW content. ============================================================ 11. CONTENT VERSIONING ============================================================ Medical/educational content should be version controlled. Example: Module A1 Version 1 - Published Admin edits content. Create: Version 2 - Draft After review: Version 2 - Published Keep Version 1 available in history. Store: version_number created_by created_at change_reason published_by published_at Allow authorized admins to view previous versions. ============================================================ 12. ADMIN CONTENT BUILDER ============================================================ Create a visual Activity Builder. Admin selects: Activity Type Then show relevant configuration fields. Supported activity types: READING IMAGE VIDEO DRAWING COLOURING TRACING ANNOTATION MEASUREMENT QUIZ MCQ DECISION_TREE CASE_SCENARIO PROCEDURE_STEPS REFLECTION CHECKLIST REFERENCE Do not require developers to manually create every new activity. ============================================================ 13. DRAWING ENGINE ============================================================ Drawing is a CORE feature. Create reusable drawing engine for Flutter. Features: - Freehand drawing - Pencil - Eraser - Multiple colours - Stroke width - Undo - Redo - Clear - Save - Continue later - Reset - Zoom - Pan - Background image/template - Optional text labels - Optional arrows - Optional shapes Store vector stroke information where practical. Do not store only screenshots. Example: drawing_id activity_id anonymous_session_id template_id canvas_width canvas_height strokes_json preview_image created_at updated_at ============================================================ 14. IMAGE ANNOTATION ENGINE ============================================================ Support: - Freehand - Arrow - Circle - Rectangle - Text - Highlight - Pin - Label Original medical/reference image must remain unchanged. Store annotations separately. ============================================================ 15. DECISION TREE ENGINE ============================================================ Decision trees must be dynamically configurable from Admin. Admin can create: Decision Tree | +-- Start Node | +-- Question Node | +-- Option | +-- Next Node | +-- Result Node Admin can modify: - Node title - Question - Options - Description - Next node - Result - Explanation - Image - Reference Flutter renders the decision tree dynamically. Do NOT hard-code the D2 decision tree. ============================================================ 16. CASE SCENARIO ENGINE ============================================================ Admin can create case scenarios. Example: Case Title Case Description Patient Code Age Sex MR Etiology NYHA EF STS Anatomy Image Questions Drawing Area Decision Tree Reflection Expert Teaching Use the exact fields from the source documents. Do not add patient-identifying information unnecessarily. ============================================================ 17. QUIZ ENGINE ============================================================ Admin can create: - MCQ - Multiple answer - True/false - Image-based question - Matching if required by source Fields: Question Image Options Correct answer Explanation Score Display order Flutter renders quiz dynamically. ============================================================ 18. PROCEDURAL CONTENT ============================================================ Support configurable procedural steps. Each step may contain: Title Description Image Video Instructions Drawing Annotation Reflection Admin can reorder steps. Flutter displays steps dynamically. ============================================================ 19. MEDIA MANAGEMENT ============================================================ Admin Panel must provide a Media Library. Support: Images Videos Audio PDF/reference files Drawing templates Media fields: id file_name file_type mime_type file_size storage_path thumbnail caption alt_text status created_by created_at updated_at Store large files in object storage. Do not store large media files directly in MySQL. Use signed URLs where appropriate. ============================================================ 20. MOBILE APPLICATION ============================================================ Technology: Flutter Dart Use a scalable architecture. Recommended: Feature-based architecture Riverpod or Bloc Dio GoRouter SQLite/Isar/Hive for local persistence CustomPainter or suitable drawing package Mobile screens: Splash Home Section List Module List Module Detail Lesson Activity Drawing Annotation Quiz Case Decision Tree Progress My Work Favorites Quick Reference Settings No login screen. ============================================================ 21. MOBILE HOME ============================================================ Home should show: M-TEER Sections: KNOW IT SEE IT MAP IT PLAN IT DO IT FIX IT COLOUR IT OWN IT Also: Continue Learning Recent Activity Progress My Cases Favorites Quick Reference Design should be premium, modern, medical and educational. ============================================================ 22. OFFLINE SUPPORT ============================================================ Mobile should support offline usage where practical. Cache: - Published modules - Text - Images - Templates - Reference content Store locally: - Progress - Drawings - Notes - Cases - Favorites When internet is available: Synchronize changes. Implement: local_version server_version Download only changed content. ============================================================ 23. PROGRESS TRACKING ============================================================ Track: - Section progress - Module progress - Lesson progress - Activity progress - Last visited - Time spent - Drawing completed - Quiz completed - Case completed - Reflection completed Example: Module Progress = completed activities / total activities Section Progress = completed modules / total modules ============================================================ 24. ANONYMOUS USER/DEVICE ============================================================ Because mobile has no login: Create anonymous session/device identifier. Example: anonymous_session_id Use it for: - Progress - Drawings - Notes - Favorites - Cases Do not collect unnecessary personally identifiable information. If user clears app data, explain that locally stored progress may be lost unless synchronized. ============================================================ 25. ADMIN DASHBOARD ============================================================ Dashboard: - Total Sections - Total Modules - Published Modules - Draft Modules - Total Activities - Total Media - Total Cases - Active Anonymous Sessions - Completion statistics Charts: - Most viewed modules - Most completed modules - Most used activities - Drawing usage - Case activity ============================================================ 26. ADMIN PANEL STRUCTURE ============================================================ Sidebar: Dashboard CONTENT Sections Modules Lessons Activities Content Blocks LEARNING Cases Decision Trees Questions Progress MEDIA Media Library Drawing Templates ADMINISTRATION Users Roles Permissions Audit Logs Settings ============================================================ 27. DATABASE ============================================================ Design normalized MySQL database. At minimum: users roles permissions user_roles role_permissions sections modules lessons activities content_blocks media media_relations drawing_templates drawings cases case_entries case_annotations questions question_options decision_trees decision_tree_nodes decision_tree_edges procedure_steps progress favorites notes content_versions anonymous_sessions audit_logs app_settings Add additional tables if required by the source documents. Before coding, provide complete ERD. ============================================================ 28. BACKEND ============================================================ Technology: Node.js NestJS TypeScript MySQL Recommended modules: auth users roles permissions sections modules lessons activities content media drawings cases decision-trees questions progress favorites notes analytics audit settings Use: DTO validation Authentication guards Permission guards Exception filters Logging API versioning ============================================================ 29. API ============================================================ Use: /api/v1/ Examples: GET /api/v1/sections GET /api/v1/sections/:id GET /api/v1/modules/:id GET /api/v1/activities/:id GET /api/v1/reference POST /api/v1/progress PUT /api/v1/progress/:id POST /api/v1/drawings PUT /api/v1/drawings/:id GET /api/v1/drawings/:id POST /api/v1/cases GET /api/v1/cases PUT /api/v1/cases/:id Admin: POST /api/v1/admin/auth/login GET /api/v1/admin/modules POST /api/v1/admin/modules PUT /api/v1/admin/modules/:id DELETE /api/v1/admin/modules/:id POST /api/v1/admin/modules/:id/publish POST /api/v1/admin/media GET /api/v1/admin/users GET /api/v1/admin/roles GET /api/v1/admin/permissions GET /api/v1/admin/audit-logs Use consistent API response: { "success": true, "message": "Success", "data": {}, "meta": {} } ============================================================ 30. SECURITY ============================================================ Backend security: - JWT - Refresh tokens - Password hashing - Rate limiting - Helmet - CORS - DTO validation - SQL injection protection - Authorization guards - Permission guards - Secure headers - Request size limits - File validation Never trust permissions received from frontend. ============================================================ 31. AUDIT LOG ============================================================ Log every important admin change. Examples: MODULE_CREATED MODULE_UPDATED MODULE_DELETED MODULE_PUBLISHED MODULE_ARCHIVED CONTENT_CREATED CONTENT_UPDATED CONTENT_PUBLISHED MEDIA_UPLOADED MEDIA_DELETED USER_CREATED USER_UPDATED ROLE_CREATED ROLE_UPDATED Log: user_id action entity_type entity_id old_value new_value ip timestamp Do not log passwords or secrets. ============================================================ 32. ADMIN PREVIEW ============================================================ VERY IMPORTANT: Admin must be able to preview content exactly as the mobile application will render it. Create: Preview Mode The Admin Panel should use the same content schema/API structure as Flutter. This ensures: Admin Content | v Preview | v Publish | v Flutter ============================================================ 33. SEARCH ============================================================ Mobile: Search modules Search lessons Search reference Search topics Admin: Search modules Search activities Search cases Search media Search users Search audit logs ============================================================ 34. QUICK REFERENCE ============================================================ Implement: Anatomy Quick Map Procedure Checklist These should be accessible quickly from mobile. Content must also be manageable from Admin. ============================================================ 35. MEDICAL SAFETY ============================================================ This is an educational application. Do not position the application as an autonomous clinical decision-making system. Do not generate medical recommendations that are not contained in the supplied source. Medical content must be editable/reviewable through Admin. Include appropriate educational disclaimer messaging. Use patient codes rather than actual patient names wherever possible. ============================================================ 36. TESTING ============================================================ Backend: Unit tests Integration tests Authorization tests API tests Admin: Component tests Permission tests Content CRUD tests Publishing workflow tests Flutter: Widget tests Navigation tests Drawing tests Offline tests Synchronization tests Content renderer tests End-to-end: 1. Admin login 2. Create section 3. Create module 4. Add lesson 5. Add content block 6. Add drawing activity 7. Upload image/template 8. Save draft 9. Preview 10. Publish 11. Open Flutter 12. Fetch new module 13. Complete activity 14. Save drawing 15. Close app 16. Reopen app 17. Verify drawing/progress 18. Modify module from Admin 19. Publish new version 20. Verify Flutter gets updated version ============================================================ 37. DEVELOPMENT PHASES ============================================================ DO NOT attempt to generate the entire application in one response. Work in phases. PHASE 1 Requirement analysis PHASE 2 Architecture PHASE 3 Database ERD PHASE 4 API specification PHASE 5 NestJS backend foundation PHASE 6 Admin authentication + RBAC PHASE 7 Admin CMS PHASE 8 Flutter foundation PHASE 9 Dynamic content renderer PHASE 10 Drawing/annotation engine PHASE 11 Decision tree engine PHASE 12 Quiz engine PHASE 13 Case scenario engine PHASE 14 Progress/offline synchronization PHASE 15 Analytics/audit PHASE 16 Testing PHASE 17 Deployment ============================================================ 38. FIRST RESPONSE REQUIREMENT ============================================================ DO NOT START CODING IMMEDIATELY. First analyze ALL attached source documents. Then provide: 1. Complete Requirement Analysis 2. Complete Module/Activity Matrix 3. Application Architecture 4. Database ERD 5. Database Table Definitions 6. API Architecture 7. Complete API Endpoint List 8. Flutter Screen Map 9. React Admin Screen Map 10. Admin RBAC Matrix 11. Content Model 12. Dynamic Content Block Architecture 13. Drawing/Annotation Architecture 14. Decision Tree Architecture 15. Quiz Architecture 16. Case Scenario Architecture 17. Offline Architecture 18. Content Publishing Workflow 19. Versioning Strategy 20. Audit Strategy 21. Development Phases 22. Detailed Development Backlog 23. Requirement Clarifications Clearly separate: SOURCE DOCUMENT REQUIREMENTS from: TECHNICAL RECOMMENDATIONS from: REQUIREMENT CLARIFICATIONS NEEDED Do not invent missing medical requirements. ============================================================ 39. IMPLEMENTATION RULE ============================================================ After presenting the architecture, wait for approval before implementing the complete application. Once approved: Implement one phase at a time. For each phase provide: - Files to create - Files to modify - Code - Database migrations - API changes - Tests - Setup instructions - Acceptance criteria Do not provide pseudo-code when production code is requested. Use production-quality TypeScript, React and Flutter code. ============================================================ 40. CODE QUALITY ============================================================ Follow: SOLID DRY Clean Architecture where useful Feature-based architecture Reusable components Strong typing Separation of concerns Secure coding practices Avoid: - God classes - Huge controllers - Huge React components - Hard-coded content - Hard-coded permissions - Hard-coded module IDs - Duplicate API logic - Medical content embedded in Flutter - Business logic inside UI components ============================================================ 41. CORE ARCHITECTURAL PRINCIPLE ============================================================ The most important principle of this project is: ADMIN CREATES/MODIFIES DATA ↓ NESTJS API ↓ MYSQL / OBJECT STORAGE ↓ FLUTTER DYNAMIC CONTENT ENGINE ↓ USER SEES UPDATED CONTENT Therefore: ADMIN PANEL = CONTENT CREATION + MANAGEMENT NESTJS = BUSINESS LOGIC + API MYSQL = STRUCTURED DATA OBJECT STORAGE = MEDIA FLUTTER = DYNAMIC LEARNING ENGINE The mobile app should NOT be rebuilt merely because an administrator creates or modifies educational content. ============================================================ 42. FINAL GOAL ============================================================ Build a scalable M-TEER educational platform where the medical/content team can independently manage the application content through the React Admin Panel. The system must allow: Existing content to be modified. New content to be created. New modules to be created. New activities to be created. New cases to be created. New decision trees to be created. New quizzes to be created. New drawing templates to be created. New videos/images/references to be uploaded. All of these must become available to the Flutter mobile application through the API without requiring source-code changes or a new mobile release. The application should therefore be treated as: A CONTENT-DRIVEN INTERACTIVE LEARNING PLATFORM and not as: A STATIC MOBILE APP BASED ON THE WORKBOOK.