UC 8.2.4
Flow 10.2 - SLA Enforcement: cron mỗi giờ theo dõi 2 hạn Plan_Due (mentee) và Induction_Due (Pod Leader), gửi email nhắc trước 12 giờ và email breach + Slack khi quá hạn
| Field | Value |
|---|---|
| BA in Charge | Anh Hoang |
| Date Created | 2026-10-12 |
| Version | v1.11 |
| Document References | Zapier Integration V7.pdf (§Flow 10.2) · RFQ_ Stack Trading Prop Tech V7.pdf (§3.3 Background Workers — Mentorship SLA Monitor, §4.4 #11) · CR-20260818-001 (Flow 7 — Pod Impact & Dispersal) · QnA from clients — STAGE 6: Pod System Flow 10 → 11 (POD-SLA-01…05, POD-PLAN-11) · QnA_init_docs.md (A-09) · Common Rules CR-08, CR-15.2 |
UC_8.2.4 — Flow 10.2: Mentorship SLA Enforcement
🇻🇳 Section này viết bằng tiếng Việt để BA review. Mọi ID, anchor, tên field/API và text hiển thị cho user giữ nguyên tiếng Anh.
1. Overview
| Field | Content |
|---|---|
| ID | UC_8.2.4 |
| Use Case | Flow 10.2: Mentorship SLA Enforcement |
| Description | UC này theo dõi 2 hạn bắt buộc trong Pod: mentee phải nộp Trading Plan trong 72 giờ sau khi vào pod, và Pod Leader phải đặt lịch họp đầu tiên với mentee trong 5 ngày sau khi mentee nộp. Hệ thống gửi email nhắc khi sắp hết hạn, và báo cho người vi phạm cùng ban quản lý khi đã quá hạn. |
| Phạm vi | UC này gồm bảng SLA_Deadlines (2 loại hạn, vòng đời bản ghi) và việc nhắc hạn, báo breach. Việc mở và đóng hạn do UC_8.2.1, UC_8.2.2, UC_8.2.3 làm. |
| Zapier Flow | Flow 10.2 (Mentorship SLA Enforcement) |
| Zapier Table | — |
| API | Webhook do Cron Job task Mentorship SLA Monitor gửi sang Zapier (Trigger của Flow 10.2) |
| Cron Job task | Mentorship SLA Monitor, chạy mỗi giờ |
| 3rd Party | Zapier, AWS SES, Slack |
2. Trigger
- Cron Job task
Mentorship SLA Monitorchạy mỗi giờ theo giờ UTC trên Middleware (tác vụ nền Node.js). UC này không có endpoint nào nhận vào, chỉ có cron gửi webhook ra Zapier.
3. Pre-conditions
- Bảng
SLA_Deadlinescó ít nhất 1 bản ghi hạn chưa đóng, tức là mentee chưa nộp Trading Plan hoặc leader chưa đặt lịch Induction Sync.
4. Post-conditions
- Mỗi hạn nhận tối đa 1 email nhắc và tối đa 1 email breach.
- Đã gửi email nhắc thì cột
warning_sent_atcó thời điểm gửi. Đã gửi email breach thì cộtbreach_sent_atcó thời điểm gửi. - Mỗi lần breach có đúng 1 Slack alert trong kênh
#ops-risk. - Cron không sửa hạn
deadline_timestamp, không đóng và không xoá bản ghi nào.
5. Basic Flow
5.1 Cron quét hạn (Cron Job task Mentorship SLA Monitor)
Stage 1 — Đọc các hạn đang mở
- Cron chạy mỗi giờ một lần, theo giờ UTC. VD: cron chạy lúc 09:00, 10:00, 11:00, và lần nào cũng làm đủ các bước 2 đến 7.
- Cron đọc bảng
SLA_Deadlinesvà bảngUsersđể lấy các bản ghi hạn chưa đóng. Các cột của bảng xem BR_8.2.4.4; vòng đời bản ghi xem BR_8.2.4.1. Không đọc được database thì xem E_8.2.4.1. - Cron bỏ qua bản ghi của user đang tạm dừng (BR_8.2.4.2):
- Hạn
Plan_Due: bỏ qua khi mentee đang tạm dừng. - Hạn
Induction_Due: bỏ qua khi leader hoặc mentee đang tạm dừng.
- Hạn
Stage 2 — Xếp loại và xác định người nhận
-
Với mỗi bản ghi còn lại, cron so hạn với thời điểm chạy và xếp vào 1 trong 2 loại:
Loại Điều kiện Event key Breach Hạn deadline_timestampđã tới hoặc đã qua, vàbreach_sent_atcòn rỗng (chưa gửi email breach lần nào)Mentee_Plan_Breachcho hạnPlan_Due,Mentor_Induction_Breachcho hạnInduction_DueWarning Hạn chưa tới nhưng chỉ còn tối đa 12 giờ, và warning_sent_atcòn rỗng (chưa gửi email nhắc lần nào)Mentee_Plan_Warningcho hạnPlan_Due,Mentor_Induction_Warningcho hạnInduction_DueVD: hạn của một bản ghi là 20:00 ngày 15.
- Cron chạy lúc 07:00 ngày 15: còn 13 giờ, chưa gửi gì.
- Cron chạy lúc 08:00 ngày 15: còn đúng 12 giờ, bản ghi thuộc loại Warning.
- Cron chạy lúc 20:00 ngày 15 hoặc muộn hơn: hạn đã tới, bản ghi thuộc loại Breach.
Bản ghi đã quá hạn mà chưa từng được gửi email nhắc thì xem E_8.2.4.2.
-
Cron xác định người nhận theo
sla_type. Cron đọc tên và email của mentee, cùng tên và email của Pod Leader hiện tại của mentee:sla_typeNgười nhận CC Plan_DueMentee Email @stacktrading.comcủa Pod LeaderInduction_DuePod Leader, vào email @stacktrading.comKhông CC ai, kể cả Operations Email gửi leader chỉ gửi vào
@stacktrading.com(Ref: UC_8.2.3 BR_8.2.3.1). Không tìm thấy người nhận thì xem E_8.2.4.3. Cron xử lý từng bản ghi riêng, một bản ghi lỗi không làm dừng các bản ghi còn lại.
Stage 3 — Gửi webhook sang Zapier
-
Với mỗi bản ghi loại Warning hoặc Breach, cron gửi webhook (
POST) vào Catch Hook của Zap Flow 10.2. Catch Hook là địa chỉ nhận webhook mà Zapier cấp riêng cho Zap này. Payload chi tiết xem BR_8.2.4.5.Input Value Event key Theo bảng ở bước 4 Mã bản ghi, sla_type,deadline_timestampLấy từ bản ghi trong SLA_DeadlinesEmail người nhận, email CC Theo bảng ở bước 5 Tên mentee, tên Pod Leader, link Typeform Trading Plan hoặc link Master Calendar của leader Các giá trị để Zapier điền vào mẫu email -
Zapier nhận webhook thành công thì cron ghi thời điểm gửi vào
warning_sent_at(loại Warning) hoặcbreach_sent_at(loại Breach). Từ đó các lần quét sau không gửi lại loại email đó cho bản ghi này (BR_8.2.4.6). Zapier lỗi thì xem E_8.2.4.4, E_8.2.4.5.
5.2 Zapier gửi email (Flow 10.2)
Stage 4 — Gửi email nhắc hoặc email breach
- Trigger: Zap Flow 10.2 nhận webhook mà cron gửi ở bước 6. "AWS Cron Job" trong flow của khách chính là Cron Job task
Mentorship SLA Monitor. Mỗi webhook mang 1 trong 4 event key:Mentee_Plan_Warning,Mentee_Plan_Breach,Mentor_Induction_Warning,Mentor_Induction_Breach(BR_8.2.4.5). - Action 1: Zapier dựa vào event key để biết hạn bị trễ là của ai: của mentee thì là hạn nộp Trading Plan 72 giờ, của Pod Leader thì là hạn đặt lịch Induction 5 ngày. Event key cũng cho biết đây là email nhắc hay email breach. Từ đó Zapier chọn 1 trong 4 mẫu email (BR_8.2.4.3).
- Action 2: Zapier gửi email qua AWS SES tới người nhận, CC thêm nếu có. Nội dung email xem BR_8.2.4.3. Email nhắc không kèm Slack alert. Zap lỗi thì xem E_8.2.4.8.
5.3 Slack alert khi breach
Bước này không có trong Flow 10.2 của Zapier Integration V7.pdf, khách bổ sung qua QnA.
Stage 5 — Báo Operations
- Với mỗi bản ghi loại Breach, hệ thống gửi Slack alert vào kênh
#ops-risk, để Operations biết ai vi phạm và xem xét bằng tay. Alert gồm vai trò người vi phạm (Mentee hoặc Pod Leader), tên vàuser_id, loại vi phạm (72-Hour Trading Plan hoặc 5-Day Induction Sync). Nội dung xem BR_8.2.4.3. BE chốt bên nào gửi alert này, Zapier hay Middleware. Prod dùng kênh#ops-risk(C0BREC78LGH), Test dùng kênh#test-ops-risk(C0BRAMTDYMQ) (Ref: CR-15.2). - Breach không có hậu quả tự động: hệ thống không gỡ mentee khỏi pod, không thu hồi role Discord, không đẩy người vi phạm khỏi kênh và không ghi strike. Nếu breach kéo dài thì Operations tự xử lý dựa trên Slack alert. Mentee đã bị breach vẫn nộp được Trading Plan, xem E_8.2.4.9.
6. Exceptional Flows
| Exception ID | Exception | Condition | System Handling / Fallback |
|---|---|---|---|
| E_8.2.4.1 | Không đọc được database | Cron không đọc được SLA_Deadlines hoặc Users. | Cron dừng lần chạy này và ghi log lỗi. Lần chạy của giờ sau quét lại toàn bộ từ đầu. |
| E_8.2.4.2 | Đã quá hạn mà chưa từng nhắc | Bản ghi đã quá hạn nhưng warning_sent_at vẫn rỗng. Chỉ xảy ra khi cron ngừng chạy suốt 12 giờ cuối trước hạn, hoặc lần gửi email nhắc nào cũng lỗi cho tới lúc quá hạn. | Cron chỉ xét Breach, không gửi bù email nhắc. Cron gửi email breach và để warning_sent_at rỗng. VD: hạn là 20:00, cron bị sập từ 07:00 tới 21:00. Lúc 21:00 cron chạy lại, bản ghi đã quá hạn nên chỉ gửi email breach. |
| E_8.2.4.3 | Không tìm thấy người nhận | Không tìm thấy mentee hoặc leader của bản ghi, hoặc người nhận không có email. | Cron bỏ qua bản ghi đó và ghi log, không ghi warning_sent_at hay breach_sent_at. Vì 2 cột vẫn rỗng nên lần chạy sau bản ghi được xét lại. |
| E_8.2.4.4 | Zapier không nhận webhook | Zapier báo lỗi, không phản hồi hoặc quá thời gian chờ. | Cron không ghi warning_sent_at hay breach_sent_at và ghi log lỗi. Lần chạy của giờ sau gửi lại. Riêng email nhắc chỉ gửi lại nếu bản ghi vẫn chưa quá hạn. VD: hạn là 20:00. Lúc 08:00 gửi email nhắc lỗi, lúc 09:00 cron gửi lại. Nếu lần nào cũng lỗi tới 20:00 thì bản ghi chuyển sang loại Breach và không gửi email nhắc nữa. |
| E_8.2.4.5 | Zapier đã nhận nhưng cron không ghi được cờ (Ref: BR_8.2.4.6) | Zapier đã nhận webhook, nhưng Middleware không nhận được phản hồi, hoặc ghi warning_sent_at hay breach_sent_at bị lỗi. | Cron ghi log lỗi. Vì cột vẫn rỗng nên lần chạy của giờ sau gửi lại, và người nhận có thể nhận 2 email giống nhau. Hệ thống chấp nhận rủi ro này để không bỏ sót email. |
| E_8.2.4.6 | Cron ngừng chạy vài giờ (Ref: BR_8.2.4.6) | Cron không chạy trong một khoảng thời gian do sự cố. | Lần chạy đầu tiên sau sự cố chỉ xét các bản ghi theo thời điểm đó, không chạy bù cho từng giờ bị lỡ. Bản ghi đã quá hạn thì xử lý theo E_8.2.4.2. VD: cron ngừng từ 09:00 tới 13:00. Lúc 13:00 cron chạy lại và chỉ xét theo thời điểm 13:00, không chạy bù 4 lượt cho 09:00, 10:00, 11:00 và 12:00. |
| E_8.2.4.7 | Hai lần chạy chồng nhau (Ref: BR_8.2.4.6) | Lần chạy trước chưa xong mà đã tới giờ chạy tiếp. | Tại một thời điểm chỉ có 1 lần chạy. Lần chạy sau thấy lần trước vẫn đang chạy thì không làm gì và chờ tới giờ kế tiếp. VD: lần chạy lúc 09:00 kéo dài tới 10:05. Lần chạy lúc 10:00 bỏ qua, lần kế tiếp là 11:00. |
| E_8.2.4.8 | Zap lỗi khi gửi email | Một bước trong Zap Flow 10.2 bị lỗi. | Zapier tự chạy lại bước lỗi, số lần tuỳ gói Zapier đang dùng. Vẫn lỗi thì Zapier gửi "Zap Error" (ghi tên Zap và bước lỗi) vào kênh Slack của Operations. Sotatek chỉ cấu hình Zapier Manager và Slack để nhận thông báo, không viết xử lý lỗi riêng. Vì cờ đã ghi lúc Zapier nhận webhook nên cron không gửi lại webhook. Zap không báo kết quả gửi email về Middleware. |
| E_8.2.4.9 | Mentee nộp Trading Plan sau khi đã breach | Hạn Plan_Due đã breach rồi mentee mới nộp. | Hệ thống vẫn đóng Plan_Due và mở Induction_Due cho leader như bình thường (Ref: UC_8.2.2). VD: hạn Plan_Due là 20:00 ngày 15, mentee nộp lúc 10:00 ngày 16. Hệ thống đóng Plan_Due và mở Induction_Due cho leader với hạn 10:00 ngày 21. |
7. Business Rules
| BR_ID | Rule Description |
|---|---|
| BR_8.2.4.1 | Bảng SLA_Deadlines và vòng đời bản ghi: xem chi tiết tại §7.1. |
| BR_8.2.4.2 | Tạm dừng hạn: Hạn của user bị tạm dừng khi user ở 1 trong 2 trạng thái:- Inactive_Hold: trạng thái của Flow 12, khi user không giao dịch suốt 30 ngày.- Tài khoản bị khoá vì DTO hoặc Hiatus (Flow 13). DTO là nghỉ phép có lương cho nhân sự W-2; Hiatus là tạm nghỉ cho nhân sự International. BE tự quyết định đọc trạng thái này từ cột nào.Hạn Plan_Due tạm dừng khi mentee đang tạm dừng. Hạn Induction_Due tạm dừng khi leader hoặc mentee đang tạm dừng. Trong thời gian tạm dừng, cron không gửi email nhắc và không báo breach.Hết DTO hoặc Hiatus: hạn được cộng thêm đúng bằng thời gian đã tạm dừng; hệ thống lưu lại thời điểm bắt đầu tạm dừng để tính. VD: mentee bắt đầu DTO khi hạn Plan_Due còn 20 giờ, DTO kéo dài 3 ngày. Hết DTO, hạn được lùi thêm 3 ngày nên mentee vẫn còn đủ 20 giờ.Hết Inactive_Hold: mentee đã bị đưa ra khỏi pod (Flow 12), nên không cộng bù thời gian. Quay lại pod cũ thì bỏ hạn cũ, tính hạn mới từ lúc quay lại. Vào waitlist thì xoá bản ghi. Được ghép pod mới thì xử lý như khi đổi pod (§7.1). |
| BR_8.2.4.3 | Nội dung tin nhắn: xem chi tiết tại §7.2. |
| BR_8.2.4.4 | Các cột của bảng SLA_Deadlines (tối thiểu):- id: khoá chính.- user_id: khoá ngoại trỏ tới Users. Hạn Plan_Due thì là mentee; hạn Induction_Due thì là Pod Leader.- sla_type: 'Plan_Due' hoặc 'Induction_Due'.- deadline_timestamp: thời điểm hết hạn.- warning_sent_at: thời điểm đã gửi email nhắc.- breach_sent_at: thời điểm đã gửi email breach.- created_at: thời điểm tạo bản ghi.Cách lưu một bản ghi đã đóng hay chưa do BE tự thiết kế. |
| BR_8.2.4.5 | Payload webhook sang Zapier: xem chi tiết tại §7.3. |
| BR_8.2.4.6 | Chống gửi trùng: Cron dùng 2 cột warning_sent_at và breach_sent_at làm cờ đánh dấu đã gửi. Cột có giá trị thì email đó đã gửi, không gửi lại. Cách này thay cho thiết kế "stateless" (không lưu gì về việc đã gửi) của RFQ V7.Cron chỉ ghi cờ sau khi Zapier nhận webhook thành công, nên lần gửi lỗi được thử lại ở giờ sau (E_8.2.4.4).Cron không chạy bù giờ bị lỡ (E_8.2.4.6) và không chạy chồng (E_8.2.4.7). Trường hợp hiếm có thể gửi 2 email giống nhau xem E_8.2.4.5. |
7.1 BR_8.2.4.1 — Bảng SLA_Deadlines và vòng đời bản ghi
SLA_Deadlines là bảng mới trong PostgreSQL, tách riêng khỏi Users và Pod_Leader_Registry. Bảng chỉ lưu 2 loại hạn, không có loại hạn SLA định kỳ nào khác:
Plan_Duelà hạn của mentee: nộp Trading Plan trong 72 giờ liên tục kể từ lúc được gán vào pod. VD: mentee được gán pod lúc 09:00 ngày 10 thì hạn là 09:00 ngày 13.Induction_Duelà hạn của Pod Leader: đặt lịch Induction Sync (buổi họp 1-1 đầu tiên với mentee) trong 5 ngày lịch kể từ lúc mentee nộp Trading Plan. VD: mentee nộp lúc 14:00 ngày 12 thì hạn của leader là 14:00 ngày 17.
| Sự kiện | Thay đổi | UC thực hiện |
|---|---|---|
| Mentee được gán vào pod | Tạo hạn Plan_Due, bằng thời điểm gán cộng 72 giờ liên tục | UC_8.2.1 |
| Mentee nộp Trading Plan, kể cả nộp muộn | Đóng hạn Plan_Due. Tạo hạn Induction_Due, bằng thời điểm nộp cộng 5 ngày lịch | UC_8.2.2 |
| Leader đặt lịch Induction Sync, là cuộc họp có mời email của mentee và notetaker | Đóng hạn Induction_Due. Buổi họp không cần diễn ra trong 5 ngày, chỉ cần đặt lịch trong 5 ngày | UC_8.2.3 |
Mentee rời chương trình, tức tài khoản thành Terminated (trader LIVE bị Hard Breach hoặc Resign), theo Flow 7 | Xoá mọi bản ghi hạn còn treo của mentee | Flow 7 — UC_4.17.2 BR_4.17.2.10 |
| Pod Leader bị terminate (Flow 15C) | Xoá mọi bản ghi hạn còn treo của leader | UC_8.2.11 |
Mentee đổi sang pod khác trong lúc hạn Induction_Due còn treo, do Flow 15A ghép lại pod hoặc Ops chuyển pod qua POST /admin-pod-reassignment | Xoá hạn Induction_Due của leader cũ. Nếu mentee đã nộp Trading Plan thì tạo hạn Induction_Due mới cho leader mới, bằng thời điểm gán pod mới cộng 5 ngày lịch. Hạn Plan_Due nếu còn thì giữ nguyên | Flow 15A · UC_8.2.9 |
| Mentee mất leader và phải vào waitlist, vì leader bị terminate mà không ghép được sang pod khác | Xoá cả Plan_Due và Induction_Due liên quan tới mentee. Khi mentee được ghép pod mới thì mở lại hạn từ đầu | Flow 15A · UC_8.2.8 |
| Mentee lên Level 7, tức là tốt nghiệp và tự rời pod | Xoá mọi bản ghi hạn còn treo liên quan tới mentee | UC_8.1.1 |
Mentee vào Inactive_Hold rồi quay lại | Xem BR_8.2.4.2 | Flow 12 |
- Bản ghi
Induction_Duegắn với Pod Leader (user_idlà của leader), nhưng phải cho biết hạn ứng với mentee nào, để khi leader có lịch họp với đúng mentee đó thì đóng được hạn. BE tự thiết kế cách lưu thông tin mentee này. - Khi người dùng rời chương trình, hệ thống xoá bản ghi để không gửi email cho người không còn tham gia. Khi mentee rời đi thì xoá luôn hạn
Induction_Duecủa leader liên quan tới mentee đó. - Cron chỉ ghi 2 cột
warning_sent_atvàbreach_sent_at, không sửadeadline_timestamp, không đóng và không xoá bản ghi. - Mọi thời điểm lưu theo chuẩn CR-08.
7.2 BR_8.2.4.3 — Nội dung tin nhắn
Giữ nguyên văn tiếng Anh do khách cung cấp.
Mentee_Plan_Warning — gửi mentee, CC leader.
Subject: ACTION REQUIRED: Trading Plan Deadline in <12 Hours Hi [Mentee_Name], Your 72-hour window to submit your mandatory Trading Plan expires in less than 12 hours. Please submit it immediately via the link below to remain in good standing. [Typeform_Link]
Mentee_Plan_Breach — gửi mentee, CC leader.
Subject: URGENT: Trading Plan SLA Breached Hi [Mentee_Name], Your 72-hour window to submit your mandatory Trading Plan has expired. Please submit it immediately via the link below to remain in good standing. [Typeform_Link]
Mentor_Induction_Warning — gửi leader, không CC.
Subject: ACTION REQUIRED: Induction Sync Deadline in <12 Hours Hi [Leader_Name], Your 5-day window to schedule an induction sync with [Mentee_Name] expires in less than 12 hours. Please schedule this meeting immediately using your master booking link to avoid compliance strikes. [Calendar_Link]
Mentor_Induction_Breach — gửi leader, không CC.
Subject: URGENT: Induction Sync SLA Breached Hi [Leader_Name], Your 5-day window to schedule an induction sync with [Mentee_Name] has expired. Please schedule this meeting immediately using your master booking link to avoid compliance strikes. [Calendar_Link]
Slack alert vào #ops-risk — chỉ gửi khi breach (bước 11).
SLA Breach Alert Role: [Mentee / Pod Leader] Name: [User_Name] (ID: [User_ID]) Violation: Failed to complete [72-Hour Trading Plan / 5-Day Induction Sync] within the required window. Manual review required.
7.3 BR_8.2.4.5 — Payload webhook sang Zapier
Tên trường, đường dẫn và định dạng chi tiết do Sotatek chốt trong OpenAPI spec của Middleware. UC này chỉ chốt payload gửi những dữ liệu gì. Mọi thời điểm theo chuẩn CR-08.
| Nội dung | Kiểu | Ghi chú |
|---|---|---|
| Event key | String | 1 trong 4 event Mentee_Plan_Warning, Mentee_Plan_Breach, Mentor_Induction_Warning, Mentor_Induction_Breach. Action 1 dựa vào giá trị này để chọn mẫu email |
Mã bản ghi SLA_Deadlines (cột id) | UUID | Dùng để tra log khi cần |
sla_type | String | Plan_Due hoặc Induction_Due |
deadline_timestamp | String (ISO 8601) | Hạn của bản ghi |
| Email người nhận | String | Event Mentee_Plan_*: email đăng ký của mentee. Event Mentor_Induction_*: email @stacktrading.com của leader |
| Email CC | String hoặc null | Event Mentee_Plan_*: email @stacktrading.com của leader. Event Mentor_Induction_*: luôn null |
| Tên mentee | String | Biến [Mentee_Name] |
| Tên Pod Leader | String hoặc null | Biến [Leader_Name]. Bắt buộc với event Mentor_Induction_*, để null với event Mentee_Plan_* |
| Link trang wrapper của form Trading Plan | String hoặc null | Biến [Typeform_Link]. Link trỏ tới trang wrapper trên stacktrading.com và không chứa user_id; trang wrapper lấy user_id từ phiên đăng nhập của mentee (Ref: UC_8.2.2 Pre-conditions). Cùng link đã gửi trong email Pod_Assignment_Confirmation của UC_8.2.1. Chỉ có với event Mentee_Plan_* |
| Link Master Calendar của leader | String hoặc null | Biến [Calendar_Link]. Khi gửi webhook, BE gọi API để tạo hoặc lấy link đặt lịch của leader, không lưu sẵn link (Ref: UC_8.2.3 bước 6). Chỉ có với event Mentor_Induction_* |
- Đây là các biến tối thiểu, suy ra từ mẫu email ở §7.2. BE chốt nội dung cuối cùng của payload.
- Middleware tự tra mentee và leader của từng bản ghi để điền vào payload.
8. Open Items
Không còn hạng mục mở. Chi tiết: QnA_init_docs.md.
9. Phân chia trách nhiệm
| Hạng mục | Sotatek build | Stack Trading Ops | Bên thứ 3 tự chạy |
|---|---|---|---|
Bảng SLA_Deadlines, cron hằng giờ, webhook | ✅ | — | — |
| 4 template email trong Zap | ✅ Map biến | ✅ Copy (đã gửi) | AWS SES |
| Slack breach alert | ✅ | ✅ Copy (đã gửi) | Slack |
| Xử lý breach kéo dài | — | ✅ Thủ công | — |
Changelog
| Date | Version | Updated item | Before | After | Notes |
|---|---|---|---|---|---|
| 2026-10-12 | v1 | Initial document | — | — | Bản tiếng Việt để BA re-check trước khi chuyển tiếng Anh. Nguồn chính: QnA POD-SLA-01…09, POD-PLAN-06/07/08. Spec V7 bị QnA thay thế: Flow 10.2 không còn "stateless" — thêm warning_sent_at / breach_sent_at (POD-SLA-03); thêm email breach + Slack (POD-SLA-02). Kênh #risk-ops khách ghi → #ops-risk theo CR-15.2. |
| 2026-10-12 | v1.1 | Thêm mục API & Cron | Cron và webhook chỉ được nhắc 1 dòng trong BR_8.2.4.4 | Mục API & Cron: spec cron Mentorship SLA Monitor (lịch chạy, điều kiện chọn bản ghi, xử lý, lỗi, chạy lại / chạy trùng), webhook 4 event key (payload), Zap Flow 10.2. Basic Flow trỏ tới từng API; cờ chỉ ghi sau khi Zapier nhận thành công; BR_8.2.4.4 rút các dòng API. Thêm Hạng mục mở #12 (A-12), #13 (A-13) | Do BA định nghĩa theo RFQ_ Stack Trading Prop Tech V7.pdf §4.4 #11: ghi cờ sau khi Zapier nhận thành công, lỗi thì giờ sau gửi lại (suy từ POD-SLA-03); chỉ 1 lần chạy cron tại một thời điểm; xử lý từng bản ghi độc lập; bản ghi quá hạn chỉ xét breach; trường sla_id và biến tối thiểu của payload (suy từ T-05, T-06). |
| 2026-10-12 | v1.2 | Basic Flow — mô tả lời gọi API | Bước gọi API chỉ gắn "(Ref: API_x)", không rõ bên gọi / bên nhận / kết quả | Mỗi bước gọi giữa các hệ thống ghi dạng [Bên gọi → Bên nhận] tên cron / webhook + event key + trường chính; Stage 1 mở bằng tên cron Mentorship SLA Monitor (mỗi giờ, UTC); Stage 2–3 rẽ nhánh theo kết quả Zapier nhận webhook (thành công → ghi warning_sent_at / breach_sent_at; lỗi → không ghi cờ, giờ sau gửi lại), gộp bước ghi cờ vào nhánh của bước gửi webhook | — |
| 2026-10-13 | v1.3 | Dùng tên API gốc; bỏ tên tự đặt | Trường payload webhook event_key, sla_id, recipient_email, cc_email, mentee_name, leader_name, typeform_link, calendar_link; tên "Webhook SLA", "Zap Flow 10.2" (bước 1–3); "cron Mentorship SLA Monitor" | Mô tả nội dung bằng lời; tên do BE chốt trong OpenAPI spec. Bảng payload đổi cột Trường → Nội dung. Cron gọi theo nguồn: Task Mentorship SLA Monitor (Hourly); webhook = "Webhook do Task Mentorship SLA Monitor gửi sang Zapier — Trigger của Flow 10.2"; bước Zap theo nguồn: Trigger, Action 1 (xác định vi phạm mentee / leader), Action 2 (gửi email) | Chỉ giữ tên có trong nguồn: 4 event key Mentee_Plan_Warning, Mentee_Plan_Breach, Mentor_Induction_Warning, Mentor_Induction_Breach (POD-SLA-01); cột SLA_Deadlines (POD-SLA-03); biến mẫu email [Mentee_Name], [Leader_Name], [Typeform_Link], [Calendar_Link] (T-05, T-06) |
| 2026-10-14 | v1.4 | Toàn UC — viết lại theo khuôn UC_8.1.x | Có bảng "Giải thích thuật ngữ"; Basic Flow trỏ sang mục "API & Cron" liệt kê 3 API: API_8.2.4.1 Task Mentorship SLA Monitor (cron), API_8.2.4.2 Webhook do Task Mentorship SLA Monitor gửi sang Zapier, API_8.2.4.3 Flow 10.2 Action 1 – Action 2 (Zap); điều kiện chọn bản ghi, lỗi, chạy lại / chạy trùng, payload nằm trong mục API; BR_8.2.4.4 "Thông tin kỹ thuật cho dev"; mục "Hạng mục mở" đứng sau RACI | Bỏ bảng thuật ngữ (giải thích ngay chỗ dùng: Plan_Due / Induction_Due ở Overview và BR_8.2.4.1, DTO / Hiatus ở BR_8.2.4.2, Catch Hook ở Stage 2). Lịch chạy cron ghi ở Trigger. Basic Flow 3 Stage: điều kiện chọn bản ghi (bảng Breach / Warning) vào Stage 1 bước 4; các trường hợp lỗi thành nhánh [If …] tại Stage 1 bước 1, 2, 5 và Stage 2–3 bước 1; input webhook ghi ngay tại Stage 2 bước 1; xử lý lỗi của Zap vào Stage 2 bước 2. Bỏ mục "API & Cron": còn 1 API — webhook do Task Mentorship SLA Monitor gửi sang Zapier (Trigger của Flow 10.2). Cron là Trigger, Flow 10.2 Action 1–2 và Slack alert là hành động trong bước, không đánh số API. Payload webhook → BR_8.2.4.5 mới; chạy lại / chạy trùng → BR_8.2.4.6 mới. BR_8.2.4.4 đổi tên thành "Cột bảng SLA_Deadlines và kênh Slack" (bỏ dòng cron / webhook đã có trong Basic Flow). "Open Items" đặt trước RACI | Theo yêu cầu BA: mô tả và thứ tự như UC_8.1.1 / UC_8.1.2. Nội dung nghiệp vụ và BR ID giữ nguyên. Sửa số API 3 → 1 cho khớp nguồn: Zapier Integration V7.pdf §Flow 10.2 (Trigger: "Webhook received from AWS Cron Job"; Action 1, Action 2 là bước Zap) và RFQ_ Stack Trading Prop Tech V7.pdf §3.3 (Task Mentorship SLA Monitor "fire webhook to Zapier"). Document References đổi "§Background Mechanisms" → "§3.3 Background Workers" theo đúng mục trong V7 |
| 2026-10-14 | v1.5 | Cron Job task tách khỏi API | Cron gọi là "Task Mentorship SLA Monitor" | Ghi rõ Cron Job task Mentorship SLA Monitor; Overview thêm dòng API (webhook sang Zapier) và Cron Job task | Theo yêu cầu BA: Cron Job task là tác vụ nền chạy theo lịch, khác API; phải ghi rõ "Cron Job task" như API ghi rõ "API". Nguồn: RFQ_ Stack Trading Prop Tech V7.pdf §3.3 Background Workers (Cron Jobs). |
| 2026-10-16 | v1.6 | BR_8.2.4.3 · Stage 2 bước 2 · Open Items · RACI | Email warning: "dùng cùng nội dung email breach, thay câu đã hết hạn bằng expires in less than 12 hours"; subject / body chính xác: Open Items #10 (A-10) | Thêm nguyên văn Mentee_Plan_Warning (Subject: ACTION REQUIRED: Trading Plan Deadline in <12 Hours) và Mentor_Induction_Warning (Subject: ACTION REQUIRED: Induction Sync Deadline in <12 Hours); bỏ Open Items #10, đánh số lại #11–#13 → #10–#12; RACI ghi copy 4 email đã gửi | Theo bảng template Stage 6 — POD system khách gửi. |
| 2026-10-16 | v1.7 | BR_8.2.4.5 — link Typeform trong payload | Link gắn sẵn user_id | Gắn sẵn user_id và mentor_email của leader hiện tại | Theo UC_8.2.2 v1.11 (hidden field Form 3) |
| 2026-10-16 | v1.8 | Stage 1 bước 2–3, Stage 3 bước 3, BR_8.2.4.1, BR_8.2.4.2, BR_8.2.4.4, BR_8.2.4.5 · Open Items | 12 hạng mục mở | Induction_Due gắn với Pod Leader (A-01). Cách lưu "đóng" (A-02), cột status DTO/Hiatus (A-04), payload webhook (A-11), bên gửi Slack breach (A-13): BE tự thiết kế. Tạm dừng DTO/Hiatus cộng bù thời gian đã dừng (A-03); Induction_Due tạm dừng khi leader hoặc mentee tạm dừng (A-12). BR_8.2.4.1 thêm 4 sự kiện: đổi pod (A-05), Inactive_Hold rồi quay lại — tính lại từ đầu, không cộng bù (A-06), mất leader vào waitlist (A-07), lên Level 7 (A-08). Còn 1 hạng mục: A-09 | BA chốt 2026-10-16. Thêm: mentee rời đi thì xoá cả Induction_Due của leader liên quan tới mentee đó — cùng mục đích chặn email "ma" của POD-SLA-09 |
| 2026-10-22 | v1.9 | Stage 1 bước 4 (điều kiện chọn bản ghi), Stage 2 bước 1 · BR_8.2.4.6 · Open Items | Warning: thời điểm chạy < deadline < thời điểm chạy + 12 giờ · quá hạn mà chưa gửi warning: Open Items #1 | Warning khi còn lại > 0 và ≤ 12 giờ · quá hạn (còn lại ≤ 0) → không gửi bù warning, chỉ gửi breach, kể cả khi warning gửi lỗi tới lúc quá hạn · Open Items: không còn | Khách trả lời 2026-10-22: A-09 |
| 2026-10-22 | v1.9 | Stage 1 bước 3, bước 4 (ghi chú dưới bảng) · Stage 2 bước 2 · Stage 3 bước 2 · BR_8.2.4.2 (status DTO / Hiatus) | Một số câu gộp nhiều ý trong 1 dòng | Tách thành các ý riêng (sub-bullet) | Viết lại cho dễ hiểu, không đổi nghiệp vụ |
| 2026-10-22 | v1.9 | Stage 1 bước 3, 4, 5 · Stage 2 bước 1, 2 · Stage 3 bước 1, 2, 3 · BR_8.2.4.2 · BR_8.2.4.6 | Một số câu viết tắt / mơ hồ | Diễn giải rõ nghĩa | Viết lại cho dễ hiểu, không đổi nghiệp vụ |
| 2026-10-22 | v1.9 | Toàn UC — Basic Flow, Business Rules | Văn phong ký hiệu, rút gọn, khó đọc | Viết lại bằng câu đầy đủ, kèm VD | Theo mẫu BA duyệt 2026-10-22, không đổi nghiệp vụ |
| 2026-10-22 | v1.9 | Basic Flow · Business Rules — cấu trúc lại theo flow gốc | Basic Flow tự sắp xếp, tách rời Business Rules | Mỗi bước trích nguyên văn flow khách + bổ sung, edge case; BR ngắn gộp vào flow (giữ anchor), BR dài được trỏ từ flow | Theo mẫu UC_8.2.2, không đổi nghiệp vụ |
| 2026-10-29 | v1.10 | Toàn UC — cấu trúc lại theo khuôn UC_1.8.7 (giống UC_8.2.1 v1.12) | Mỗi bước trích nguyên văn flow gốc của khách; đoạn "2 điểm khác tài liệu gốc"; edge case và BR_8.2.4.4, BR_8.2.4.6 nằm trong flow; mã QnA trong thân doc | Bỏ dòng trích nguyên văn và đoạn "điểm khác tài liệu gốc" (nội dung ghi thành rule ở BR_8.2.4.6 và câu dẫn §5.3). Mục đánh số 1 đến 9; §5 chia 5.1 cron quét hạn, 5.2 Zapier gửi email, 5.3 Slack alert khi breach; bước đánh số liên tục 1 đến 12. Edge case gom vào bảng §6 (E_8.2.4.1 đến E_8.2.4.9). BR gom vào bảng §7; BR_8.2.4.2, BR_8.2.4.4, BR_8.2.4.6 nằm trong bảng; BR_8.2.4.1 ở §7.1, BR_8.2.4.3 ở §7.2, BR_8.2.4.5 ở §7.3. Mọi BR đều được refer từ bước hoặc exception liên quan. Mã QnA chỉ giữ ở Document References và Changelog. Giữ nguyên anchor BR_8.2.4.1 đến BR_8.2.4.6, open-items | BA yêu cầu viết dễ hiểu như UC_1.8.7, không đổi nghiệp vụ |
| 2026-10-29 | v1.11 | §7.3 BR_8.2.4.5 — 2 dòng payload: link Trading Plan, link Master Calendar | Link Typeform Trading Plan "đã gắn sẵn user_id của mentee và mentor_email của leader"; nơi lưu Master Calendar link "xem UC_8.2.3 Hạng mục mở #2" | Link trang wrapper của form Trading Plan, không chứa user_id, trang wrapper lấy user_id từ phiên đăng nhập; Master Calendar link do BE gọi API tạo hoặc lấy lúc gửi webhook, không lưu sẵn | Đồng bộ với UC_8.2.1 (A-07, CHR-127), UC_8.2.2 v1.12 và UC_8.2.3 A-02 (mục Open Item cũ đã đóng). BA xác nhận sửa 2026-10-29 |
| 2026-10-29 | v1.11 | §1 Overview — Description | Mô tả chi tiết các bước, tên API, field và nhánh xử lý | Chỉ ghi tổng quan: UC dùng để làm gì và nội dung chính, bằng câu thường; chi tiết xem §5 | BA yêu cầu Description chỉ ghi tổng quan, không đổi nghiệp vụ |
| 2026-10-29 | v1.11 | Các chỗ ghi status tài khoản Terminated / Failed | Ghi status không kèm nguyên nhân, hoặc ghi "resign hoặc bị terminate", "Resigned hoặc Terminated" | Ghi kèm nguyên nhân: Terminated là trader LIVE bị Hard Breach hoặc Resign; Failed là trader SIM bị Hard Breach hoặc Resign. Không có status Resigned riêng | BA yêu cầu 2026-10-29, để biết status xuất hiện khi nào |