เอกสารถอดตรรกะการทำงาน ระบบ Teacher V2 Curriculum

เอกสารนี้ถอดตรรกะการทำงานจาก prototype หน้า /teacher/v2/curriculum/ ให้เป็นภาษาที่ PO, UX, และทีม Dev ใช้คุยร่วมกันได้ โดยไม่ต้องเปิดโค้ด Astro แล้วไล่เดาเองว่าปุ่มหรือ component แต่ละส่วนทำอะไร

เป้าหมายของระบบ

ระบบนี้ควรถูกมองเป็น “พื้นที่ทำงานของครูแนะแนว” มากกว่าระบบรายงานหรือ dashboard

ครูเปิดระบบมาเพื่อรู้ว่า:

1. วันนี้ต้องสอนอะไร
2. ต้องใช้กิจกรรม สื่อ หรือใบงานไหน
3. นักเรียนคนไหนต้องติดตาม
4. หลังสอนต้องบันทึกอะไร
5. ระบบสรุปความครอบคลุมของแผนให้อัตโนมัติ

ดังนั้นหน้าแรกควรเป็น Today หรือ “ผู้ช่วยสอนวันนี้” ส่วน Reports เป็นหน้าตรวจภาพรวมภายหลัง ไม่ใช่พระเอกของระบบ

ขอบเขตของ Prototype ตอนนี้

Route หลัก:

• /teacher/v2/curriculum/

ไฟล์หลัก:

• src/pages/teacher/v2/curriculum.astro
• src/components/teacher/CurriculumBuilderApp.astro

ข้อมูลจำลอง:

• src/data/curriculumData.ts

ตาราง mapping แบบ static:

• MVP/table.html

แผนผัง Component

ข้อสังเกตสำคัญ:

ไฟล์ component ย่อยส่วนใหญ่เป็นเพียงโครงหน้าจอ ส่วนตรรกะการทำงานจริงยังรวมอยู่ใน CurriculumBuilderApp.astro ค่อนข้างมาก ถ้าทำ production ควรแยกตรรกะการทำงานออกเป็น service/hook/store ให้ชัด

โครงข้อมูลที่ระบบใช้

หน่วยการเรียนรู้

ใช้บอกว่าแผนแนะแนวต้องครอบคลุมเรื่องใดบ้าง และแต่ละหน่วยควรมีสัดส่วนเท่าไร

ข้อมูลที่ใช้:

• id: เลขหน่วย 1-4
• title: ชื่อหน่วยแบบเต็ม
• shortTitle: ชื่อสั้นสำหรับแสดงบน card/table
• target: สัดส่วนเป้าหมายของหน่วย
• min: สัดส่วนขั้นต่ำที่ควรมี
• description: คำอธิบายหน่วย
• goals: เป้าหมายการเรียนรู้
• color: สีประจำหน่วย
• current: ค่าที่ระบบคำนวณภายหลังว่าแผนปัจจุบันครอบคลุมหน่วยนี้กี่เปอร์เซ็นต์

กิจกรรม

กิจกรรมคือสิ่งที่ครูเลือกเข้าแผน และเป็นฐานในการคำนวณ coverage ทั้งหมด

ข้อมูลที่ใช้:

• id: รหัสกิจกรรม
• title: ชื่อกิจกรรม
• duration: จำนวนชั่วโมง
• unitId: กิจกรรมนี้อยู่ในหน่วยใด
• unitObjectives: ตัวชี้วัตถุประสงค์ เช่น 4.1, 4.2
• gradeLevel: ระดับชั้นที่เหมาะสม
• objectives: วัตถุประสงค์ของกิจกรรม
• materials: สื่อหรือใบงานที่ใช้
• expectedOutcomes: ผลลัพธ์ที่คาดหวัง
• comps: สมรรถนะที่กิจกรรมนี้ช่วยพัฒนา
• skills: ทักษะที่กิจกรรมนี้ช่วยพัฒนา

รายการกิจกรรมในแผน

เมื่อครูเพิ่มกิจกรรมเข้าแผน ระบบจะสร้างรายการกิจกรรมในแผนขึ้นมา

ข้อมูลที่ใช้:

• id: รหัสรายการในแผน
• activityId: อ้างอิงกิจกรรมต้นทาง
• week: สัปดาห์ที่สอน
• date: วันที่สอน
• status: สถานะของกิจกรรม เช่น เสร็จสิ้น / กำลังดำเนินการ / ยังไม่เริ่ม
• subStatus: ข้อความเสริมของสถานะ

สถานะการส่งงานและติดตามนักเรียน

ตอนนี้เป็นข้อมูลจำลองใน browser state เท่านั้น

{
  totalStudents: 35,
  sentCount: 30,
  notStartedCount: 5,
  pendingEvaluationCount: 7,
  offlineLogCount: 0,
  reminderSentCount: 0,
  log: []
}

ถ้าทำจริง ข้อมูลชุดนี้ควรมาจาก assignment/submission API ของห้องเรียนนั้น

ตรรกะการทำงานหลักของระบบ

การคำนวณภาพรวมแผน

Function อ้างอิงใน prototype: calculate()

หน้าที่ของส่วนนี้คือดูว่า “แผนที่ครูเลือกไว้ตอนนี้ครอบคลุมพอหรือยัง”

ระบบคำนวณจากกิจกรรมที่ถูกเลือกเข้าแผนแล้ว โดยสรุปออกมาเป็น:

• จำนวนกิจกรรมทั้งหมด
• จำนวนชั่วโมงทั้งหมด
• สัดส่วนความครอบคลุมของแต่ละหน่วย
• สัดส่วนความครอบคลุมของสมรรถนะ
• สัดส่วนความครอบคลุมของทักษะ
• รายการเรื่องที่ยังขาด
• สถานะว่าแผนพร้อมใช้งานหรือยัง

สูตรปัจจุบัน:

• รวมชั่วโมงของกิจกรรมที่เลือกทั้งหมด
• สำหรับแต่ละหน่วย: เอาชั่วโมงของกิจกรรมในหน่วยนั้น หารด้วยชั่วโมงรวมทั้งหมด
• ถ้าไม่มีชั่วโมงรวม ให้ถือว่าความครอบคลุมเป็น 0%
• หน่วยใดที่ต่ำกว่า min จะถือว่ายังขาด
• สมรรถนะและทักษะคิดจากจำนวนกิจกรรมที่แตะเรื่องนั้น หารด้วยจำนวนกิจกรรมทั้งหมด
• ถ้าสมรรถนะหรือทักษะใดต่ำกว่า 25% จะถือว่ายังขาด

สถานะ “พร้อมใช้งาน” ตอนนี้เกิดขึ้นเมื่อ:

• ไม่มีหน่วยที่ต่ำกว่าเกณฑ์
• ไม่มีสมรรถนะที่ต่ำกว่าเกณฑ์
• ไม่มีทักษะที่ต่ำกว่าเกณฑ์

หมายเหตุสำหรับ production:

• ในโค้ดเดิมใช้ชื่อ canApprove แต่ UX ปัจจุบันไม่ได้มี flow ส่งอนุมัติจริง ควรเปลี่ยนชื่อเป็น isPlanReady หรือ isCoverageReady
• เกณฑ์ 25% ของสมรรถนะ/ทักษะยังเป็นสมมติฐานของ prototype ต้องให้ทีมหลักสูตรยืนยันก่อนใช้จริง

การสรุปเรื่องที่ยังขาด

Function อ้างอิง: gapLabels(summary)

หน้าที่คือแปลงผลคำนวณที่เป็นข้อมูลดิบ ให้กลายเป็นข้อความที่ครูอ่านรู้เรื่อง เช่น:

• ขาดหน่วย 2
• ขาดสมรรถนะการคิดขั้นสูง
• ขาดทักษะ Leadership

ข้อมูลนี้ถูกใช้ใน:

• header สถานะแผน
• ปุ่ม next action
• panel ความครอบคลุม
• หน้า Reports

การแนะนำกิจกรรม

Function อ้างอิง:

• scoreActivity(activity, summary)
• recommendations(summary)

แนวคิดคือ ระบบควรช่วยครูเติมแผนให้ครบ โดยไม่ต้องให้ครูอ่านกิจกรรมทั้งหมดเอง

วิธีคิดคะแนนตอนนี้:

• ถ้ากิจกรรมช่วยเติมหน่วยที่ยังขาด ได้คะแนนเพิ่มมากที่สุด
• ถ้ากิจกรรมช่วยเติมสมรรถนะที่ยังขาด ได้คะแนนรองลงมา
• ถ้ากิจกรรมช่วยเติมทักษะที่ยังขาด ได้คะแนนเพิ่มอีกระดับหนึ่ง
• กิจกรรมที่อยู่ในแผนแล้วจะไม่ถูกแนะนำซ้ำ

น้ำหนักคะแนนใน prototype:

• เติมหน่วยที่ยังขาด: +4
• เติมสมรรถนะที่ยังขาด: +3 ต่อเรื่อง
• เติมทักษะที่ยังขาด: +2 ต่อเรื่อง

สิ่งที่ควรทำเพิ่มใน production:

• แสดงเหตุผลว่า “ทำไมระบบถึงแนะนำกิจกรรมนี้”
• ให้ backend ส่งรายการ recommendation กลับมาพร้อม reason
• ไม่ควรให้ client แต่ละหน้าคำนวณแยกเอง เพราะอาจไม่ตรงกัน

ตรรกะการทำงานรายหน้า

1. Header

Header ทำหน้าที่บอกสถานะแผนแบบเร็วที่สุด

ข้อมูลที่แสดง:

• ลิงก์กลับ Teacher Workspace
• ปีการศึกษา
• จำนวนกิจกรรมและจำนวนชั่วโมง
• สถานะแผน
• สถานะการบันทึก
• ปุ่ม action ถัดไปที่ระบบแนะนำ

สถานะที่แสดง:

• ถ้าแผนพร้อม: แผนพร้อมใช้งาน
• ถ้าแผนยังไม่พร้อม: ยังต้องเติม {จำนวนเรื่อง} เรื่อง

ปุ่ม action ถัดไป:

• ถ้าแผนยังขาด: พาไปหน้า Activities
• ถ้าแผนครบแล้วแต่ยังไม่ได้จัดวัน: พาไป Calendar
• ถ้าแผนพร้อมแล้ว: พาไปขั้นตอนใช้งาน/สอนต่อ

สิ่งที่ต้องเปลี่ยนตอนทำจริง:

• ปีการศึกษาต้องมาจากบริบทโรงเรียน/เทอม
• สถานะบันทึกต้องอิง server ไม่ใช่ localStorage อย่างเดียว
• ปุ่มกลับ Teacher Workspace ไม่ควรปนกับ action ของแผน

2. Navigation

ระบบใช้ tab หลัก 7 หน้า:

• Today
• Calendar
• Activities
• Students
• Materials
• Assessment
• Reports

ใน prototype การเปลี่ยนหน้าใช้ data-view-tab และเปิด/ปิด .cb-view ด้วย JavaScript

ตอนทำจริงควรพิจารณา:

• จะใช้ router จริง หรือเก็บเป็น state ภายในหน้า
• ควรรองรับ browser back/forward หรือไม่
• ถ้าครูส่งลิงก์ให้กัน ควรเปิดมาที่ tab เดิมได้หรือไม่

3. Today

หน้า Today คือหน้าแรกของครู

คำถามที่หน้านี้ต้องตอบ:

• วันนี้สอนกิจกรรมอะไร
• ต้องใช้สื่ออะไร
• ต้องติดตามนักเรียนคนไหน
• หลังสอนต้องทำอะไรต่อ

ตรรกะการเลือกกิจกรรมวันนี้ใน prototype:

1. เรียงกิจกรรมในแผนตามสัปดาห์
2. ถ้ามีกิจกรรมสถานะ “กำลังดำเนินการ” ให้ใช้กิจกรรมนั้น
3. ถ้าไม่มี ให้ใช้กิจกรรมแรกที่ “ยังไม่เริ่ม”
4. ถ้าไม่มีอีก ให้ใช้กิจกรรมแรกในแผน

ข้อจำกัดของตรรกะปัจจุบัน:

• ยังไม่ได้ดูวันที่จริง
• ยังไม่ได้ดูตารางสอนจริง
• ยังไม่ได้ดูห้องเรียนที่ครูกำลังสอนจริง

ตอนทำ production ควรเลือกกิจกรรมวันนี้จาก:

• วันที่ปัจจุบัน
• ตารางสอนของครู
• ห้องเรียนที่เลือก
• กิจกรรมในแผนที่ผูกกับวันนั้น

4. Activities

หน้านี้ช่วยให้ครูเติมกิจกรรมที่แผนยังขาด

มี 2 ส่วน:

• กิจกรรมที่ระบบแนะนำ
• คลังกิจกรรมทั้งหมดสำหรับค้นหาเอง

ตรรกะของกิจกรรมแนะนำ:

• ถ้าแผนยังไม่ครบ ระบบแสดงกิจกรรมที่ช่วยเติม gap ได้ดีที่สุด
• ถ้าแผนครบแล้ว ระบบแสดงสถานะว่าพร้อม และพาไปจัดตาราง

ตรรกะของ filter:

• filter ตามระดับชั้น
• filter ตามหน่วยการเรียนรู้
• กิจกรรม ทุกระดับ ถือว่าใช้ได้กับทุกระดับชั้น

Action หลัก:

• เพิ่มกิจกรรมเข้าแผน
• ดูรายละเอียดกิจกรรม
• เปิดคลังทั้งหมด

สิ่งที่ต้องทำจริง:

• คลังกิจกรรมควรมาจาก API
• การเพิ่มกิจกรรมต้องบันทึกลงแผนบน server
• ป้องกันการเพิ่มซ้ำทั้งฝั่ง client และ server

5. Calendar

Calendar ใช้จัดแผนให้สอนจริงได้

มี 3 ขั้นตอน:

1. จัดลำดับกิจกรรม
2. ตั้งวันสอน
3. ตรวจความพร้อมก่อนใช้

ขั้นตอนจัดลำดับ:

• แสดงกิจกรรมที่เลือกไว้
• ครูเลื่อนขึ้น/ลงได้
• ครูลบกิจกรรมออกจากแผนได้

ขั้นตอนตั้งวัน:

• ครูเลือกวันเริ่มต้น
• ระบบเรียงวันสอนให้เป็นรายสัปดาห์
• ถ้าติ๊กข้ามวันหยุด ระบบจะข้ามวันที่อยู่ในรายการวันหยุด

ขั้นตอนตรวจแผน:

• ถ้าแผนพร้อม ระบบพาไป Students/Delivery
• ถ้ายังไม่พร้อม ระบบแสดง gap และแนะนำกิจกรรมที่ควรเติม

สิ่งที่ต้องทำจริง:

• วันหยุดต้องมาจาก school calendar
• ต้องเช็กวันชนกับตารางสอนจริง
• ต้องเก็บลำดับและวันที่ลง server

6. Students

หน้านี้ใช้ส่งกิจกรรมและติดตามนักเรียน

ตอนนี้ข้อมูลเป็น mock:

• จำนวนนักเรียนทั้งหมด
• จำนวนที่ได้รับงานแล้ว
• จำนวนที่ยังไม่เริ่ม
• จำนวนงานที่รอประเมิน
• log กิจกรรมล่าสุด

Action mock ตอนนี้:

• ส่งกิจกรรมให้ทั้งห้อง
• เตือนนักเรียนที่ยังไม่เปิดงาน
• ตรวจงานที่รอประเมิน
• บันทึกกิจกรรมออฟไลน์

สิ่งที่ต้องทำจริง:

• ทุก action ต้องเป็น API mutation
• ต้องมีรายชื่อนักเรียนจริง ไม่ใช่แค่ตัวเลขรวม
• ต้องมี rollback หรือ error state ถ้าส่งไม่สำเร็จ

7. Materials

หน้านี้แสดงสื่อของกิจกรรมที่ active อยู่

ตรรกะปัจจุบัน:

• ใช้กิจกรรมเดียวกับหน้า Today
• เอา materials ของกิจกรรมนั้นมาแสดง
• กดแล้วเปิด drawer รายละเอียดกิจกรรม

สิ่งที่ต้องทำจริง:

• สื่อควรมีประเภท เช่น slide, worksheet, QR, link
• ต้องมี URL หรือ file reference จริง
• ต้องกำหนดสิทธิ์การเข้าถึงไฟล์

8. Assessment

ตอนนี้เป็น checklist เตือนครูหลังสอน

เนื้อหาปัจจุบัน:

• นักเรียนที่ยังไม่ส่งงาน
• บรรยากาศในห้อง
• หลักฐานการเรียนรู้

สิ่งที่ต้องทำจริง:

• ต้องมี model สำหรับบันทึกหลังสอน
• ควรผูกกับ class session
• ควรแนบหลักฐานหรือไฟล์ได้
• ควรเลือกนักเรียนที่ต้องติดตามต่อได้

9. Reports

Reports ใช้ตรวจภาพรวม ไม่ใช่งานหลักในชีวิตประจำวันของครู

ข้อมูลที่แสดง:

• KPI ความครอบคลุมของหน่วย
• KPI ความครอบคลุมของสมรรถนะ
• KPI ความครอบคลุมของทักษะ
• ตารางหน่วยการเรียนรู้
• metrics ภาพรวม

หลักการสำคัญ:

• Reports ควรใช้ summary เดียวกับ Header และ Today
• ไม่ควรมีสูตรคำนวณซ้ำคนละที่

10. Unit Drawer

Drawer หน่วยใช้ให้ครูเข้าใจว่าแต่ละหน่วยคืออะไร

ข้อมูลที่แสดง:

• ชื่อหน่วย
• เป้าหมายและขั้นต่ำ
• คำอธิบายหน่วย
• เป้าหมายการเรียนรู้
• กิจกรรมในหน่วยนั้น

Action:

• เปิดรายละเอียดกิจกรรม
• ไปหน้า Activities พร้อม filter หน่วยนั้น

11. Activity Drawer

Drawer กิจกรรมใช้ให้ครูตัดสินใจก่อนเพิ่มเข้าแผน

ข้อมูลที่แสดง:

• ชื่อกิจกรรม
• หน่วย
• ระยะเวลา
• ระดับชั้น
• วัตถุประสงค์
• สื่อการสอน
• ผลลัพธ์ที่คาดหวัง
• สมรรถนะและทักษะ

Action:

• ถ้ายังไม่อยู่ในแผน: เพิ่มกิจกรรมเข้าแผน
• ถ้าอยู่ในแผนแล้ว: ปิด drawer

การบันทึกข้อมูล

ตอนนี้ prototype ใช้ localStorage

Key:

• cb-plan-v1

ข้อมูลที่บันทึก:

• รายการกิจกรรมในแผน
• สถานะ delivery mock
• เวลาที่บันทึกล่าสุด

พฤติกรรม:

• แก้ไขแล้วตั้งสถานะกำลังบันทึก
• debounce ประมาณ 800ms
• บันทึกลง localStorage
• เปลี่ยนข้อความสถานะบน header

ตอนทำจริง:

• ต้องเปลี่ยนเป็น server-side draft
• localStorage ใช้ได้แค่ fallback หรือ cache ชั่วคราว
• ต้องรองรับการเปิดจากหลายเครื่อง

Endpoint ที่ควรมี:

• GET /teacher/curriculum-plans/current
• PATCH /teacher/curriculum-plans/{id}
• POST /teacher/curriculum-plans/{id}/activities
• DELETE /teacher/curriculum-plans/{id}/activities/{eventId}
• POST /teacher/curriculum-plans/{id}/auto-schedule
• POST /teacher/curriculum-plans/{id}/deliver

Contract ของ Action ใน Prototype

ตารางนี้ช่วยให้ Dev เห็นว่า DOM action เดิมหมายถึง behavior อะไร

ตอนทำจริงควรเปลี่ยนจาก DOM attribute เป็น typed event/action ของ framework ที่ใช้ แต่ชื่อ action เหล่านี้ยังใช้เป็น reference ได้

ตรรกะการทำงานที่ควรถอดออกหรือแยกเป็น Feature เฉพาะ

Onboarding Tour

Prototype มี tour แนะนำระบบ โดยจำ state ด้วย localStorage key cb-tour-v1

ถ้าจะใช้จริงควร:

• ทำเป็น feature flag
• แยกออกจาก controller หลัก
• มีปุ่มเปิดดูซ้ำได้
• ไม่ควรบังคับทุกครั้งที่เปิดหน้า

Skeleton Loading จำลอง

ตอนนี้ skeleton เกิดจาก timeout เพื่อให้ demo ดูมี transition

ถ้าทำจริงควร:

• ผูกกับ loading state ของ API
• ไม่ใส่ delay ปลอมถ้าข้อมูลมาเร็ว

Delivery Mock Counter

ตัวเลขการส่งงานและเตือนนักเรียนตอนนี้เปลี่ยนใน browser state

ถ้าทำจริงต้อง:

• เรียก API
• มี error state
• มีรายชื่อนักเรียนรายคน

ชื่อ canApprove

ชื่อเดิมทำให้เข้าใจเหมือนมี flow อนุมัติ

UX ปัจจุบันสรุปแล้วว่าไม่ควรมี “ส่งอนุมัติหลักสูตร” สำหรับครูใน flow นี้ จึงควรเปลี่ยนเป็นคำว่า:

• isPlanReady
• isCoverageReady
• readiness.status

ข้อมูล hardcoded

ข้อมูลต่อไปนี้ยังเป็น mock:

• ปีการศึกษา 2569
• ห้อง ม.4/1
• นักเรียนที่ต้องติดตาม
• วันหยุดโรงเรียน
• สถานะส่งงาน

รูปแบบข้อมูล Summary ที่แนะนำ

type CurriculumPlanSummary = {
  academicYear: number;
  classId: string;
  selectedActivityCount: number;
  totalHours: number;
  readiness: {
    status: "ready" | "needs_action";
    gapCount: number;
    gaps: Array<{
      type: "unit" | "competency" | "skill";
      id: string | number;
      label: string;
      currentPercent: number;
      targetPercent: number;
      minimumPercent?: number;
    }>;
  };
  coverage: {
    units: Array<{ id: number; label: string; current: number; target: number; min: number }>;
    competencies: Array<{ id: string; label: string; current: number; target: number }>;
    skills: Array<{ id: string; label: string; current: number; target: number }>;
  };
  recommendations: Array<{
    activityId: string;
    score: number;
    reasons: string[];
  }>;
};

รูปแบบข้อมูลกิจกรรมในแผนที่แนะนำ

type CurriculumPlanItem = {
  id: string;
  activityId: string;
  order: number;
  week: number;
  date?: string;
  classId: string;
  status: "not_started" | "scheduled" | "in_progress" | "completed";
};

ตาราง MVP

ไฟล์:

• MVP/table.html

หน้าที่:

• แสดง matrix ว่ากิจกรรมแต่ละตัวเชื่อมกับวัตถุประสงค์และสมรรถนะใด
• ตอนนี้เป็น static HTML
• ไม่ได้เชื่อมกับ Teacher V2 โดยตรง

แนวทาง production:

• ควรมองเป็น report/export view
• mapping กลางอยู่ใน src/data/curriculumData.ts ผ่าน CURRICULUM_OBJECTIVES, CORE_COMPETENCIES, ACTIVITY_CURRICULUM_MAPPINGS, และ CURRICULUM_COVERAGE_SUMMARY
• report/export ควร generate จาก mapping เดียวกับข้อมูลกิจกรรม
• ไม่ควรดูแลเป็นไฟล์ static แยกจาก source of truth

คำถามที่ PO ต้องตัดสินใจก่อนทำจริง

1. เกณฑ์ readiness อย่างเป็นทางการคืออะไร

• หน่วยใช้ค่า min รายหน่วย
• สมรรถนะ/ทักษะตอนนี้ใช้ 25% แบบ prototype

1. แผนหนึ่งชุดผูกกับอะไร

• ครู
• ห้องเรียน
• ระดับชั้น
• เทอม
• หรือทั้งหมดร่วมกัน

1. หน้า Today ควรอิงจากอะไร

• วันที่ปัจจุบัน
• timetable จริง
• กิจกรรมที่ครูเลือกเป็น active
• หรือห้องเรียนที่กำลังเปิดอยู่

1. การติดตามนักเรียนควรลึกแค่ไหน

• เตือนเท่านั้น
• บันทึก offline completion
• จด note รายคน
• ส่งต่อผู้เกี่ยวข้อง

1. ครูควรส่งกิจกรรมแบบใด

• ส่งทีละกิจกรรม
• ส่งทั้งแผน
• ส่งเฉพาะกิจกรรมวันนี้

1. Reports ต้อง export/print ได้หรือไม่

1. Onboarding tour จะใช้จริงหรือเป็นแค่ demo

ลำดับงานที่แนะนำให้ทีม Dev ทำ

1. แยก data model และสูตรคำนวณ summary ออกจาก UI
2. ทำ draft plan CRUD บน server
3. ทำ Today จาก timetable + plan item + class context
4. ทำ recommendation พร้อมเหตุผล
5. ทำ Calendar ที่ตรวจวันชนกับ school calendar
6. ทำ Students/Delivery จาก assignment/submission จริง
7. ทำ Reports จาก summary endpoint เดียวกัน
8. แปลง MVP table ให้ generate จากข้อมูลจริง