EMmind MTL project overview
Evidence snapshot: 2026-08-26. MTL repository facts were checked against
cbt-core origin/devat99afedaa5f74,cbt-webapp origin/mainat550a3bb64a00, andcbt-cmsapp origin/devatae02c19aaea8. Fork provenance uses the three imported root commits dated 2026-02-25. AWS facts were checked read-only in accounts050752624503and564141170168, regionap-southeast-1. Current Studio Twist repository heads, live Redis placement, MTL secret delivery, and the mechanism that activates MTL images on EC2 remain unverified.
Edition map
EMmind has two deployed editions. They share the original CBT product base but use separate domains, AWS accounts, data stores, buckets, images, and application hosts.
| Edition | Users and scope | Application hosts | Source and AWS boundary |
|---|---|---|---|
| Public EMmind | Users of the public deployment | emmind.aimet.tech and cms.emmind.aimet.tech | Studio Twist cbt-* repositories and AWS account 050752624503 |
| EMmind MTL | Internal corporate service for Muang Thai Life Assurance employees | mtl.emmind.aimet.tech and cms.mtl.emmind.aimet.tech | Aimet cbt-* repositories and AWS account 564141170168 |
The public account owns the emmind.aimet.tech Route 53 zone and delegates mtl.emmind.aimet.tech to the MTL account. This folder documents the MTL edition. Public facts are included when they explain shared source history, edition differences, asset ownership, or the deployment-event boundary.
Purpose
EMmind MTL is a LINE-based cognitive behavioral therapy product for employees of Muang Thai Life Assurance. The employee application helps users check depressive symptoms, record emotions, work through CBT lessons and exercises, plan activities, build a personal safety plan, and find urgent support.
The privacy notice in cbt-webapp states that this edition is provided to employees of บริษัท เมืองไทยประกันชีวิต จำกัด (มหาชน). After LINE authentication, the entry UI instructs employees to use a @muangthai.co.th Google account.
EMmind provides CBT lessons and exercises directly through the employee application. Its terms direct users to an appropriate support organization or medical care when symptoms require it.
Shared product base and MTL changes
The imported public snapshots already contained the main EMmind product: LINE entry, consent, 9Q, CBT paths and lessons, emotion journals, activity planning, safety plans, feedback, reminders, and the CMS. The MTL repositories retain that structure and add corporate behavior.
| Area | Public snapshot | MTL edition |
|---|---|---|
| Employee identity | LINE authentication and consent | LINE authentication followed by Google OAuth re-verification. The UI asks employees to use @muangthai.co.th; the reviewed source does not enforce the email suffix. |
| Default post-consent destination | Journal | 9Q |
| Next 9Q reminder | Two weeks | 30 days |
| Employee upload limit | 2 MB | 10 MB |
| Edition-specific content | General public terms and privacy copy | Muang Thai Life privacy copy, identity-confirmation messaging, and MTL feedback or message assets |
| Additional MTL code | No Google verification modules in the imported snapshot | Google verification modules and user fields, request logging, a core health endpoint, web analytics events, and CMS sentiment icons |
Product surfaces
| Surface | Primary users | Responsibility |
|---|---|---|
| LINE Official Account and rich messages | Employees | Starts onboarding, responds to greeting, distress, and danger keywords, sends reminders, and opens LIFF routes. |
| EMmind LIFF web app | Employees | Runs identity verification, consent, 9Q, CBT learning paths, emotion journals, activity planning, safety plans, feedback, and account settings. |
| EMmind core API | Web app, CMS, LINE webhooks, scheduled jobs | Owns authentication, user and therapy records, progress, reminders, media upload URLs, LINE messaging, and admin APIs. |
| EMmind CMS | Admin and staff users | Lists users, 9Q results, emotions, activities, scenarios, and feedback. User detail also shows journals, safety-plan data, quiz history, and skill progress. |
Product capability map
| Capability | Employee experience | System owner |
|---|---|---|
| Entry and identity | Open EMmind from LINE, complete Google OAuth, and accept terms and privacy | cbt-webapp and cbt-core |
| Mental-health check | Complete the Thai 9Q questionnaire and receive result-specific guidance | cbt-webapp; cbt-core stores submissions created through the current backToLine flow |
| CBT learning | Follow one of three concern-based paths or open an individual skill | cbt-webapp lesson content and cbt-core progress records |
| Daily reflection | Record emotions, situations, thoughts, stories, and journal summaries | cbt-webapp journal flows and cbt-core journal entities |
| Activity planning | Plan activities, set reminders, and rate pleasure and achievement | cbt-webapp, scheduled core jobs, and LINE push messages |
| Safety and support | Build a safety plan and open urgent-support options | cbt-webapp, stored safety-plan data, and LINE messages |
| Product administration | Browse users, 9Q results, emotions, activities, scenarios, skills, and feedback | cbt-cmsapp and cbt-core /admin/* APIs |
Repository boundary
The Aimet repositories are snapshot imports rather than GitHub-native forks. Their first commits are 5dfda5f for core, c1b52e3 for the employee web app, and 81ec526 for the CMS, each with the message forked from studiotwist/.... Those commits have no parent, so the exact Studio Twist commit used for each import is not recoverable from Aimet Git history. The repository map records the boundary in detail.
| Module | Repository | Main runtime |
|---|---|---|
| Core API and jobs | cbt-core | NestJS 11 on Node.js 22, PostgreSQL through TypeORM, Redis, S3, LINE Messaging API, and Google OAuth |
| Employee application | cbt-webapp | Remix 2 server-rendered application, LINE LIFF SDK, Redis-backed web sessions, and server-side calls to the core API |
| Admin application | cbt-cmsapp | React Router 7 server-rendered application with cookie sessions and server-side calls to the core API |
Infrastructure summary
The editions run separate infrastructure stacks:
| Edition | Environments | Compute and ingress | Database | Image namespace |
|---|---|---|---|---|
| Public EMmind | Development, UAT, production | cbt-dev, cbt-uat, and cbt-prod EC2 instances behind cbt-alb | Aurora PostgreSQL cluster db-1, engine 16.11 | cbt/cbt-core, cbt/cbt-webapp, cbt/cbt-cmsapp |
| EMmind MTL | Development and production | emmind-mtl-dev and emmind-mtl-prod EC2 instances behind separate development and production ALBs | RDS PostgreSQL dev-db and emmind-mtl-prod, engine 17.9 | emmind/emmind-core, emmind/emmind-webapp, emmind/emmind-cmsapp |
All three MTL repositories contain buildspecs configured for AWS account 564141170168 in ap-southeast-1. They target images under the emmind/ ECR namespace:
| Application | Build image name | Manual deploy event name |
|---|---|---|
| Core | emmind/emmind-core | cbt-core |
| Employee web app | emmind/emmind-webapp | cbt-webapp |
| CMS | emmind/emmind-cmsapp | cbt-cmsapp |
The buildspecs publish dev from the dev branch and publish version tags as matching image tags. Manual GitHub workflows send deployment requests to an SNS topic in a separate DevOps account, 050752624503.
The live development and production services run as three container targets on one EC2 instance per environment, behind Application Load Balancers. Host and path rules route the employee site, /api/*, and the CMS to ports 3000, 3001, and 3002 respectively. Each environment has a PostgreSQL RDS instance and separate asset and user-content buckets. The live ECR repositories and CodeBuild projects match the three application repositories.
| Environment | Employee application and API host | CMS host |
|---|---|---|
| Development | https://dev.mtl.emmind.aimet.tech | https://dev.cms.mtl.emmind.aimet.tech |
| Production | https://mtl.emmind.aimet.tech | https://cms.mtl.emmind.aimet.tech |
The application repositories define image builds and the deployment-event contract, but not the live AWS infrastructure. This review established the runtime topology but not the repository or team that owns its infrastructure definitions. See infrastructure and deployment for the verified resource map and remaining ownership boundaries.
How to use this handover
- Read system architecture for service boundaries and request paths.
- Use business logic before changing onboarding, 9Q, learning progress, reminders, or urgent-support behavior.
- Use data and integrations before changing entities, deletion, Redis state, S3 uploads, LINE, or Google verification.
- Use infrastructure and deployment for build, image, configuration, migration, runtime, and monitoring ownership.
- Use the design and content directory to locate product routes, checked-in artwork, Thai copy, fonts, LINE assets, and the question export.
Document directory
| Topic | Document |
|---|---|
| Service boundaries, entry paths, and runtime flows | System architecture |
| Onboarding, 9Q, learning paths, journals, activities, safety, reminders, and CMS | Business logic |
| PostgreSQL entities, Redis state, S3, LINE, Google, and deletion | Data and integrations |
| AWS image builds, deploy events, runtime configuration, migrations, health routes, and local services | Infrastructure and deployment |
| Repository ownership, snapshots, API collections, and cross-repo calls | Repository map |
| Figma UI, handoff, system-flow and roadmap sources; employee and CMS routes; artwork, fonts, copy, LINE assets, and question data | Design and content directory |