# TNSU Education Management Platform — Agent Knowledge Base Read this file first. It tells you what the project is, which documents to read for a given task, and which facts you can trust. ## What this project is A proposed platform for **Thailand National Sports University (TNSU, มหาวิทยาลัยการกีฬาแห่งชาติ)** that manages both university education and sports schools on one central system: - **17 campuses (วิทยาเขต)**: university level (undergraduate) - **13 sports schools (โรงเรียนกีฬา)**: secondary level (ม.1–ม.6), boarding schools - Admission through graduation, plus athletes, dormitories, welfare, finance, student loans (กยศ.), scholarships, e-documents and e-signature, executive dashboard, AI analytics and an AI bot. - Channels: Student Mobile App, Parent Mobile App, Student Web Portal, Staff Backoffice, Executive Dashboard. The vendor proposing it is **Stream** (the "บริษัทฯ" in the proposal). ## Project status (as of 2026-10-30) - **Stage: discovery and early design.** The tech stack is decided ([ADR-0001](../adr/0001-tech-stack.md)), including the database: **SQL Server**. A draft Role Matrix and Security Matrix exist. There is no data model or code yet. - **Greenfield:** there is no legacy system to migrate from (the proposal's "ระบบเดิม E-Education" does not apply). - **Policy values** (fees, refund rules, grading criteria, thresholds, limits, retention periods) are **configured by the university and by lecturers** in the system. The system must make them configurable; do not hard-code them or wait for them. - **Next design work** (planned by the project owner): data model researched and designed module by module; sitemap and mockup screens (on request); external integrations specified together with the module that needs them. - Sources: 1. **Use cases** (`use_cases/UC1-Explorer.dc.html`, added 2026-10-30): 162 use cases in 35 modules, taken from the team's "เล่ม 02 Workflow". This is the **most detailed source for behaviour**: actors, steps, approvals and business rules. See [12-use-cases.md](12-use-cases.md) and the generated catalog [use-cases/](use-cases/README.md). 2. **BA draw.io source** (`TNSU_EDU 191069.drawio` in the repo root, received 2026-10-30): 23 modules split into university (UNI-01…08) and sports school (SS-01…15), the organisation structure, the curriculum list and two process flows. This is the client-facing **list of functions per education level**. See [03-modules.md](03-modules.md); generated rendering in [ba-drawio.md](ba-drawio.md). 3. **Proposal** `TNSU_EDU_Proposal_281069_Stream.docx` (v1.0, 27-10-2026) in the repo root: vision, channels, AI, plan. 4. **Mockups** inside the proposal: illustrative UI. - On behaviour, follow the use cases. On which functions exist per education level, follow the BA chart. Record conflicts in [11-open-questions-and-known-issues.md](11-open-questions-and-known-issues.md). Areas no source covers in detail (AI, legacy E-Education migration) stay **open** and are not dropped. ## Rules for agents 1. **Proposal §5 (5.1–5.3) and §7 have not been written for TNSU yet.** They contain leftover template text from another project. **Ignore that content completely.** Do not quote or reuse it, including in `source/proposal-extracted.md` where it has been removed. 2. When a fact is marked **[confirmed in proposal]**, it appears consistently in the TNSU-specific text. **[mockup]** means it comes only from UI mockup images (sample data, illustrative). **[inferred]** means it is our reading and has not been stated. **[unknown]** means it must be asked. 3. Do not invent a tech stack, database schema or vendor integration and present it as decided. If a task needs one, propose it explicitly as a proposal and record the decision. 4. Keep Thai domain terms as they are (see [02-glossary.md](02-glossary.md)). Users and the client speak Thai; UI copy is Thai. 5. Years in the domain use the **Buddhist Era (พ.ศ.)**: 2568 = 2025 CE. Semesters are written `1/2568` (semester/academic year). 6. When you learn something that changes these docs (a decision, a clarified requirement), update the relevant file and the "Open questions" list rather than leaving it only in chat. ## Document map | File | Read it when you need | |---|---| | [01-project-overview.md](01-project-overview.md) | Background, problems, goals, benefits per stakeholder, differentiators | | [02-glossary.md](02-glossary.md) | Thai ↔ English domain terms, abbreviations (กยศ., DGA, มอบตัว, คำร้อง…) | | [03-modules.md](03-modules.md) | **BA module structure** (UNI-01…08, SS-01…15, with every function), mapping to the proposal's TNSU-01…12, and scope gaps | | [04-roles-and-access.md](04-roles-and-access.md) | User roles, channels per role, data-scoping rules (campus / school / level / role) | | [05-workflows.md](05-workflows.md) | The 7 core business workflows, with diagrams | | [06-ux-ui.md](06-ux-ui.md) | Per-channel UX guidelines and what each mockup screen shows (menus, widgets, sample data) | | [07-architecture-and-integrations.md](07-architecture-and-integrations.md) | Intended architecture principles and the integrations that are really in scope for TNSU | | [08-non-functional-requirements.md](08-non-functional-requirements.md) | Security, PDPA, audit, availability: what is stated and what is still open | | [09-delivery-plan.md](09-delivery-plan.md) | 10-month timeline, phases, team structure, success factors | | [10-kpis.md](10-kpis.md) | Success indicators and how they are measured in-system | | [11-open-questions-and-known-issues.md](11-open-questions-and-known-issues.md) | Inconsistencies in the proposal and questions to resolve with the client | | [13-role-matrix.md](13-role-matrix.md) | **Role Matrix (draft)**: role codes, scopes, channels, duties, and the approval-authority matrix | | [14-security-matrix.md](14-security-matrix.md) | **Security Matrix (draft)**: data classification, access per data domain and role, authentication, SoD, privileged access, audit | | [../adr/](../adr/) | Architecture decision records. [ADR-0001](../adr/0001-tech-stack.md): tech stack | | [15-preparation-task-briefs.md](15-preparation-task-briefs.md) | Actionable preparation-task briefs, intended respondents and question/answer tracking; hosting example T-303 | | [17-mockup-workspace.md](17-mockup-workspace.md) | Mockup menus, shared screen/state/component artifacts, Sitemap/Page flow and revision workflow | | [16-use-case-review-2026-10-31.md](16-use-case-review-2026-10-31.md) | Full 162-case review, proposed workflow corrections and decisions, Thai primary sources, and questions UR-Q01…10. Proposals require human confirmation | | [12-use-cases.md](12-use-cases.md) | **Use-case overview**: the 35 UC modules, mapping to BA and proposal, key cross-cutting concepts (guardians, SoD, PolicySet, lifecycle cascade, athlete leave, health vault), external systems, decisions | | [use-cases/](use-cases/README.md) | **Generated catalog** of all 162 use cases (W-xx) with actors, steps and relations, one file per module, plus role index. Search it with `grep -rn "W-49" docs/agent/use-cases/` | | `tools/gen_use_cases.py` | Regenerates `use-cases/` from `use_cases/UC1-Explorer.dc.html` | | [ba-drawio.md](ba-drawio.md) | **Generated** rendering of every page of the BA draw.io file. Regenerate with `python3 docs/agent/tools/gen_ba_drawio.py` | | `tools/gen_ba_drawio.py` | Regenerates `ba-drawio.md` from the newest `TNSU_EDU*.drawio` in the repo root | | `assets/ba-module-structure.png` | Earlier image of the BA module chart (superseded by the draw.io source) | | `assets/ui/` | Mockup images for the six screens (open them if you can read images) | | `assets/workflows/` | Original workflow diagrams from the proposal | | `source/proposal-extracted.md` | Full raw text of the proposal, for checking original wording. Search it rather than opening the .docx | ## One-paragraph summary to paste into a prompt > TNSU Education Management Platform: one central platform for Thailand National Sports University covering 17 university campuses and 13 sports (boarding) schools. BA functional scope (primary): **University** UNI-01…08 (settings, fees and permissions; admission; registrar and requests; curriculum, courses and prerequisites; course registration; assessment, GPA/GPAX and graduation audit; instructor evaluation; alumni). **Sports schools** SS-01…15 (admission; registry and parents; curriculum and timetable; assessment; dormitory; roll call and missing-student tracking; leave and off-campus permission; nutrition; health and injuries; training; competitions; fitness testing; discipline and counselling; parent services; executive reports). The team's use cases (162 use cases W-1…W-163 in 35 modules: platform IAM/ORG/NOTI/ENG/SVC/CASE/DOC/PRIV/AUD/ANA/RPT/ADMIN; academic ADM/CUR/REG/ATT/EXM/ASM/REC/GRD/GRAD/PRA/SSC/LMS; student services FIN/SCH(scholarships and กยศ.)/HOU/AFF/SAFE/HLT/ALU; sports ATH/FAC/LAB/REV) detail the behaviour: Thai QR payments, กยศ. via DSL, ThaID, guardian relations and consent, SoD and 4-eyes approvals, versioned DMN policies, health vault, child safeguarding, athlete competition leave, graduate studies and practicum. The proposal also promises an AI bot and AI analytics, a student web portal and integration with the legacy E-Education system; none of these has a use case yet. Data is shared centrally and scoped by education level, campus, school and role. Stack: Vue/Nuxt.js (SSR), Go Stream Framework, RustFS, Redis, Kubernetes (Rancher, ArgoCD, Harbor), OpenSearch logs, Grafana; database SQL Server (queues on RabbitMQ). Greenfield, no legacy system. Policy values are configured by the university. Plan: 10 months, phased, 22-person team. Status: discovery; requirements are not confirmed.