UC 8.2.6

Flow 10.4 - Mentee Feedback: cron hằng ngày gửi survey định kỳ để mentee đánh giá Pod Leader; kết quả được lưu lại và cập nhật điểm trung bình của leader

Field	Value
BA in Charge	Anh Hoang
Date Created	2026-10-12
Version	v1.13
Document References	Zapier Integration V7.pdf (§Flow 10.4, §3.3 Table E) · RFQ_ Stack Trading Prop Tech V7.pdf (§Background Mechanisms — Mentee Organic Survey Monitor, §4.4 #11) · QnA from clients — STAGE 6: Pod System Flow 10 → 11 (`POD-FDBK-02/05/08/09/10`, `POD-PLAN-11`) · QnA_init_docs.md (A-01…A-10, C-03) · CHR-127 (Typeform embedding standard) · Common Rules CR-08, CR-15.2, CR-18

UC_8.2.6 — Flow 10.4: Organic Mentee Feedback

🇻🇳 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.6
Use Case	Flow 10.4: Organic Mentee Feedback
Description	UC này cho mentee đánh giá Pod Leader của mình định kỳ, 60 ngày một lần, qua một survey ẩn danh. Kết quả được lưu lại và dùng để tính điểm trung bình của leader. Hệ thống chỉ lưu kết quả, không cảnh báo khi điểm thấp. Leader không biết ai chấm mình.
Phạm vi	Chỉ survey định kỳ của Flow 10.4. Không gồm survey gửi lúc lên level (Flow 4, UC_8.1.1) và lúc rời chương trình (Flow 7, UC_4.15.2).
Zapier Flow	Flow 10.4 (Organic Mentee Feedback Hook), chỉ Action 1 gửi email
Zapier Table	Table E — `Pod_Leader_Registry` (cột điểm trung bình)
API	Webhook `SEND_MENTEE_SURVEY` (Middleware gửi sang Zapier) · Webhook kết quả survey (Typeform gửi tới Middleware)
Cron Job task	`Mentee Organic Survey Monitor`, chạy hằng ngày lúc 02:00 UTC
3rd Party	Typeform, Zapier

2. Trigger

Cron Job task Mentee Organic Survey Monitor chạy trên Middleware hằng ngày lúc 02:00 UTC để gửi survey (§5.1).
Mentee nộp survey trên Typeform (§5.3).

4. Post-conditions

Mỗi mentee đủ điều kiện đã nhận email mời làm survey, và last_survey_date của mentee là thời điểm gửi.
Survey mentee đã nộp được lưu lại.
Điểm trung bình của leader được tính lại sau mỗi lần nộp.

5. Basic Flow

Đường dẫn, tên trường và định dạng chi tiết của các webhook trong UC này theo BR_8.2.6.4.

5.1 Chọn mentee và gửi survey (Cron Job task `Mentee Organic Survey Monitor`)

Stage 1 — Chọn mentee

Cron chạy 1 lần mỗi ngày lúc 02:00 UTC. Tại một thời điểm chỉ có 1 phiên cron chạy. Không đọc được database hoặc có phiên khác đang chạy thì xem E_8.2.6.1, E_8.2.6.2.
Cron đọc 2 bảng:
- Users: các cột pod_leader_id, pod_join_date, last_survey_date, Level và status để lọc mentee, cùng email và tên mentee để gửi email.
- Pod_Leader_Registry: thông tin leader của mentee.
Cron chỉ chọn mentee thoả tất cả điều kiện sau:
- Mentee đang thuộc một pod (pod_leader_id có giá trị).
- Mentee đã ở pod hiện tại hơn 60 ngày, tính từ pod_join_date. Đổi pod thì đếm lại từ đầu, để mentee chỉ đánh giá leader đã đi cùng mình đủ lâu. VD: mentee vào pod A ngày 01/08, đổi sang pod B ngày 15/09 thì cron đếm 60 ngày từ ngày 15/09.
- Mentee chưa từng được gửi survey (last_survey_date rỗng), hoặc đã qua hơn 60 ngày kể từ last_survey_date. last_survey_date là lần gần nhất hệ thống gửi survey, không phải lần mentee nộp.
- Mentee không ở trạng thái Level 7 Alumni, hoặc tài khoản Terminated (trader LIVE bị Hard Breach hoặc Resign).
- Mentee đang nghỉ DTO hoặc Hiatus vẫn được gửi survey.
Mốc 60 ngày so theo thời điểm đầy đủ, gồm cả ngày và giờ UTC, không làm tròn theo ngày. VD: mentee vào pod lúc 10:00 UTC ngày 2026-08-01 thì đủ 60 ngày lúc 10:00 UTC ngày 2026-09-30. Lượt cron 02:00 UTC ngày 2026-09-30 chưa chọn vì còn thiếu 8 tiếng; lượt 02:00 UTC ngày 2026-10-01 mới chọn.

Stage 2 — Gửi webhook cho từng mentee

Với mỗi mentee được chọn, Middleware đọc tên leader và tạo link survey:
- Link trỏ tới trang wrapper trên stacktrading.com. Trang wrapper là trang của Stack Trading có nhúng survey Typeform bên trong, mentee phải đăng nhập mới mở được.
- Link chứa tham số leader_id, bằng pod_leader_id hiện tại của mentee. Trang wrapper dùng giá trị này để kiểm tra mentee còn thuộc pod của leader đó không (bước 11).
- Trang wrapper lấy mentee_id từ phiên đăng nhập, rồi đưa mentee_id và leader_id vào form dưới dạng hidden field. Hidden field là trường gửi kèm câu trả lời mà mentee không nhìn thấy.

Middleware gửi webhook SEND_MENTEE_SURVEY tới Catch Hook của Flow 10.4, mỗi mentee 1 webhook riêng. Catch Hook là địa chỉ Zapier cấp để nhận webhook và chạy Zap. Bảng dưới là các thông tin tối thiểu để Zap điền email (BR_8.2.6.3):

Input field	Kiểu	Value
`mentee_id`	UUID	`user_id` của mentee
`leader_id`	String	`Leader_ID` của leader hiện tại
Email mentee	String	Địa chỉ nhận email
Tên mentee	String	Điền vào `[Mentee_Name]`
Tên Pod Leader	String	Điền vào `[Leader_Name]`
Link survey	String	Link trang wrapper có gắn `leader_id`. Điền vào `[Typeform_Link]`

Mentee không có email hoặc không còn tồn tại thì xem E_8.2.6.3.

Middleware chỉ ghi Users.last_survey_date khi Zapier trả 200 OK, tức là Zapier xác nhận đã nhận webhook. Giá trị ghi là thời điểm gửi webhook (CR-08). Nhờ vậy mỗi mentee chỉ được gửi 1 lần trong mỗi chu kỳ 60 ngày. Gửi lỗi, chạy lại hoặc lỡ một ngày thì xem E_8.2.6.4 đến E_8.2.6.6. Một mentee lỗi thì Middleware ghi log và chuyển sang mentee kế tiếp, không dừng cả lượt chạy.

5.2 Zapier gửi email mời (Flow 10.4 — Trigger, Action 1)

Stage 3 — Gửi email

Zapier nhận webhook SEND_MENTEE_SURVEY qua Catch Hook. Mỗi webhook ứng với 1 mentee và chạy 1 lượt Zap. Zapier không tự lọc trùng; việc chống gửi trùng dựa hoàn toàn vào last_survey_date ở bước 7.
Zapier gửi email Template_Mentee_Survey tới email của mentee. Nội dung email xem BR_8.2.6.3. Sotatek dựng template và gắn link survey riêng cho từng mentee. Zap lỗi thì xem E_8.2.6.7.
Survey là tự nguyện và không có hạn nộp:
- Mentee không nộp thì hệ thống không gửi nhắc. Qua hơn 60 ngày kể từ last_survey_date thì cron gửi link mới.
- Mentee đã nộp thì chu kỳ sau vẫn được gửi tiếp.
- Trong một chu kỳ 60 ngày, mentee chỉ nộp được 1 lần. Chu kỳ tính từ lần gửi gần nhất. VD: survey gửi ngày 01/10, mentee nộp ngày 03/10. Mentee mở lại link và nộp tiếp ngày 20/10 thì bị chặn. Lần nộp tiếp theo chỉ hợp lệ sau khi cron gửi survey mới, tức là khi đã qua hơn 60 ngày kể từ ngày 01/10.

5.3 Mentee làm survey (Flow 10.4 — Action 2)

Kết quả survey không đi qua Zapier. Typeform gửi thẳng tới Middleware, và Middleware tự cập nhật điểm.

Stage 4 — Mở survey

Mentee mở link survey. Trang wrapper kiểm tra lần lượt:
- Mentee không còn thuộc pod của leader ghi trên link thì xem E_8.2.6.8.
- Mentee đã nộp trong chu kỳ hiện tại thì xem E_8.2.6.9.
- Còn lại thì trang hiện survey. Bộ câu hỏi xem BR_8.2.6.3. Form ghi rõ phản hồi được ẩn danh 100% với leader (BR_8.2.6.2).

Stage 5 — Lưu kết quả và tính điểm

Mentee nộp survey. Typeform gửi webhook kết quả survey (POST) thẳng tới Middleware:

Input field	Kiểu	Bắt buộc	Value
Mã lần nộp	String	✅	Mã Typeform cấp cho mỗi lần nộp, dùng để nhận ra khi Typeform gửi lại cùng một lần nộp
`mentee_id`	UUID	✅	Hidden field, lấy từ phiên đăng nhập
`leader_id`	String	✅	Hidden field, lấy từ link survey
Điểm câu Q1	Integer	✅	Từ 1 đến 10
Câu trả lời Q2	String	✅	Đúng 1 trong `Yes consistently`, `Occasionally`, `Rarely`, `Never`
Câu trả lời Q3	String	❌	Mentee có thể bỏ trống
Thời điểm nộp	Timestamp	✅	Do Typeform ghi

Middleware kiểm tra dữ liệu. Dữ liệu sai, gửi lại, không tìm thấy mentee hoặc leader, mentee đã rời pod, hoặc đã nộp trong chu kỳ, thì xem E_8.2.6.10 đến E_8.2.6.14.
Middleware lưu lần nộp vào một bảng riêng, mỗi lần nộp là một bản ghi gồm mã lần nộp, mentee_id, leader_id, Q1, Q3 và thời điểm nộp. Mỗi thông tin nằm ở một cột riêng, không gộp thành một chuỗi chung. Bảng này tách riêng, không ghi chung vào cột engagement_metrics của UC_8.2.7. Chỗ lưu câu Q2 chưa chốt (§8 #2).
Middleware khoá dòng của leader trong Pod_Leader_Registry để không lần nộp nào khác cập nhật cùng lúc, rồi tính lại điểm trung bình theo BR_8.2.6.1 và ghi vào cột điểm (kiểu số). Bước 14 và bước 15 được ghi xuống database cùng nhau: hoặc cả hai thành công, hoặc không có gì được ghi. Lỗi hệ thống thì xem E_8.2.6.15.
Middleware trả 200 OK cho Typeform để báo đã lưu survey và cập nhật điểm xong. Hệ thống không kiểm tra điểm thấp và không gửi tin báo cho ai, kể cả khi điểm Q1 rất thấp (BR_8.2.6.1).

6. Exceptional Flows

Exception ID	Exception	Condition	System Handling / Fallback
E_8.2.6.1	Cron không đọc được database	Lỗi database ngay lúc cron bắt đầu.	Cron dừng lượt chạy và ghi log, không ghi `last_survey_date` cho mentee nào. Lượt hôm sau tự chọn lại đủ các mentee thoả điều kiện.
E_8.2.6.2	Đang có phiên cron khác chạy	Phiên mới bắt đầu khi phiên trước chưa xong.	Cron bỏ qua phiên mới, để tránh gửi survey 2 lần cho cùng một mentee.
E_8.2.6.3	Mentee không có email hoặc không còn tồn tại	Không có email, hoặc `mentee_id` không còn trong hệ thống.	Middleware bỏ qua mentee đó, ghi log, không ghi `last_survey_date`, rồi chuyển sang mentee kế tiếp.
E_8.2.6.4	Gửi webhook không thành công	Zapier không trả `200 OK`, lỗi mạng hoặc hết thời gian chờ.	Middleware không ghi `last_survey_date` và ghi log, không gửi lại trong lượt này. Lượt hôm sau tự chọn lại mentee đó vì `last_survey_date` chưa đổi.
E_8.2.6.5	Cron chạy lại hoặc chạy trùng	Cron chạy lại trong cùng ngày, hoặc 2 phiên chạy nối tiếp nhau.	Mentee đã gửi thành công có `last_survey_date` mới, nên không bị gửi lần hai.
E_8.2.6.6	Cron lỡ một ngày	Cron không chạy được một ngày do sự cố.	Lượt kế tiếp tự chọn mọi mentee thoả điều kiện, gồm cả mentee lẽ ra được gửi hôm bị lỡ, nên không cần chạy bù riêng. VD: cron không chạy ngày 10. Lượt ngày 11 chọn cả mentee đủ điều kiện từ ngày 10 lẫn mentee mới đủ điều kiện ngày 11.
E_8.2.6.7	Zap lỗi khi gửi email	Một bước trong Zap Flow 10.4 bị lỗi.	Zapier tự chạy lại theo cơ chế của gói đ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. `last_survey_date` đã được ghi lúc Zapier nhận webhook, nên cron không chọn lại mentee này cho tới chu kỳ sau, và mentee lỡ survey của chu kỳ đó. Day 1 chấp nhận trường hợp này, hệ thống không theo dõi email đã tới hộp thư mentee hay chưa.
E_8.2.6.8	Mentee không còn thuộc pod khi mở link	Mentee mở link survey và: `pod_leader_id` rỗng; hoặc `pod_leader_id` khác `leader_id` trên link (mentee đã đổi pod, hoặc ai đó sửa link); hoặc mentee đã ở trạng thái Level 7 Alumni, hoặc tài khoản `Terminated` (trader LIVE bị Hard Breach hoặc Resign).	Trang wrapper không hiện survey mà hiện thông báo `Form Expired`. Luồng kết thúc.
E_8.2.6.9	Đã nộp trong chu kỳ khi mở link	Mentee đã có một lần nộp kể từ `last_survey_date`.	Trang wrapper không hiện survey mà hiện thông báo `You have already submitted this`. Luồng kết thúc.
E_8.2.6.10	Dữ liệu không hợp lệ	Thiếu nội dung bắt buộc; điểm Q1 ngoài khoảng 1 đến 10 (VD 0 hoặc 11); hoặc câu trả lời Q2 không thuộc 4 giá trị cho phép.	Middleware trả `400` và không ghi gì vào database.
E_8.2.6.11	Typeform gửi lại cùng lần nộp (Ref: CR-18)	Mã lần nộp đã có trong bảng lưu survey.	Middleware trả `200 OK` và bỏ qua: không lưu thêm và không tính lại điểm. Typeform coi như đã gửi xong.
E_8.2.6.12	Không tìm thấy mentee hoặc leader (Ref: CR-18)	`mentee_id` hoặc `leader_id` không tồn tại.	Middleware trả `200 OK` và bỏ qua, không ghi gì.
E_8.2.6.13	Mentee đã rời pod lúc nộp (Ref: CR-18)	Lần nộp lọt qua trang wrapper, VD mentee mở form khi còn ở pod rồi đổi pod mới bấm nộp. Middleware tra theo `mentee_id` và thấy: `leader_id` gửi lên khác `users.pod_leader_id` hiện tại; hoặc `pod_leader_id` rỗng; hoặc mentee ở trạng thái Level 7 Alumni, hoặc tài khoản `Terminated` (trader LIVE bị Hard Breach hoặc Resign).	Middleware trả `200 OK` và bỏ qua: không ghi gì và không tính điểm.
E_8.2.6.14	Lần nộp thứ 2 trong cùng chu kỳ (Ref: CR-18)	Mentee đã có một lần nộp khác (mã lần nộp khác) kể từ `last_survey_date`. VD mentee mở form ở 2 tab và nộp ở cả 2.	Middleware trả `200 OK` và bỏ qua, không ghi gì, không tính lại điểm.
E_8.2.6.15	Lỗi hệ thống khi lưu	Lỗi database hoặc hết thời gian chờ ở bước 14 hoặc 15.	Middleware huỷ cả việc lưu lần nộp lẫn cập nhật điểm và trả `500`, database giữ nguyên. Typeform tự gửi lại webhook, và lần gửi lại được xử lý như lần nộp mới. Nhờ kiểm tra mã lần nộp (E_8.2.6.11), một lần nộp không bao giờ bị tính điểm 2 lần.

7. Business Rules

BR_ID	Rule Description
BR_8.2.6.1	Điểm trung bình của leader: Điểm là trung bình cộng đơn giản của điểm Q1 trong mọi survey đã nộp cho leader đó, tính riêng theo từng `Leader_ID`. VD: leader nhận 3 survey với điểm 8, 6 và 10 thì điểm trung bình là 8 (tổng 24 chia cho 3).Điểm được tính ngay từ survey đầu tiên, không cần số survey tối thiểu. VD: leader mới nhận 1 survey 4 điểm thì điểm trung bình là 4.Điểm chỉ để Operations theo dõi. Hệ thống không dùng điểm này khi ghép mentee vào pod (Ref: UC_8.2.1 BR_8.2.1.2).Hệ thống chỉ lưu điểm: không kiểm tra điểm thấp, không gửi cảnh báo cho Operations hay ai khác, và không tự động làm gì với leader. VD: mentee chấm Q1 2 điểm thì hệ thống vẫn chỉ lưu survey và tính lại điểm trung bình.Mentee chấm nhầm (VD chấm Q1 1 điểm nhưng phần Q3 toàn lời khen) thì Operations tự sửa hoặc xoá bản ghi trực tiếp trong database. Hệ thống không có màn hình cho việc này.
BR_8.2.6.2	Ẩn danh và quyền xem: Leader không biết mentee nào chấm mình và không đọc được câu trả lời, để mentee không sợ bị trả đũa. Form survey ghi rõ phản hồi được ẩn danh 100% với leader. Operations và Management xem được đầy đủ điểm và nội dung.
BR_8.2.6.3	Nội dung survey và tin nhắn: xem chi tiết tại §7.1.
BR_8.2.6.4	Quy định chung cho webhook: Đường dẫn, định dạng và tên trường do Sotatek chốt trong OpenAPI spec của Middleware; riêng `mentee_id` và `leader_id` giữ đúng tên. UC này chỉ mô tả nội dung và cách xử lý.Lời gọi không đủ điều kiện xử lý thì Middleware trả `200 OK` và bỏ qua, database không thay đổi và bên gọi không bị báo lỗi (CR-18).Mọi thời điểm ghi database theo chuẩn CR-08.

7.1 BR_8.2.6.3 — Nội dung survey và tin nhắn

Giữ nguyên văn tiếng Anh do khách cung cấp.

Email Template_Mentee_Survey (Zapier gửi, bước 9)

Subject: Your Feedback Requested: Stack Trading Pod Experience Hi [Mentee_Name], To ensure you are receiving the highest quality mentorship, please complete a brief evaluation of your assigned Pod Leader, [Leader_Name]. Your feedback directly impacts our coaching quality and helps us maintain high standards across the firm. Please submit your 30-day Pod evaluation using the link below: [Typeform_Link] Regards, Stack Trading Operations

Survey trên Typeform — Form 4: Bi-Monthly Pod Performance Audit (bước 11)

Thành phần	Nội dung
Form Title	Bi-Monthly Mentor Performance Audit
Welcome Screen	Elite performance requires elite community. At Stack Trading, leadership is graded on results. We require your objective assessment of your Pod Leader's performance. Your candid, anonymous feedback ensures our mentors maintain the highest standards.
Ending Screen	Audit data secured. Thank you for protecting the integrity and standards of the desk.

#	Loại	Bắt buộc	Câu hỏi	Dùng cho
Q1	Opinion Scale từ 1 đến 10. Mức 1 có nhãn `Absent/Ineffective`, mức 10 có nhãn `Exceptional/Transformative`	✅	How effectively has your Pod Leader guided your risk management, corrected your execution, suggested improvements and enforced discipline over the last 60 days?	Điểm trung bình
Q2	Multiple Choice, chọn 1 trong 4: `Yes consistently`, `Occasionally`, `Rarely`, `Never`	✅	Does your mentor actively review your journal entries and hold you accountable to the Trading Plan you submitted?	Lưu cùng survey (chỗ lưu xem §8 #2)
Q3	Long Text	—	Provide specific context on your mentor's performance. Are they responsive to your technical inquiries? Do they provide actionable feedback during your drawdowns?	Nội dung phản hồi

Trang wrapper khi không hiện survey (bước 11)

Form Expired

You have already submitted this

8. Open Items

Chi tiết: QnA_init_docs.md.

#	Câu hỏi	ID
1	Chu kỳ đã chốt 60 ngày, nhưng copy email `Template_Mentee_Survey` vẫn ghi "30-day Pod evaluation". Khách cập nhật copy?	C-03
2	Câu Q2 lưu ở đâu; Operations xoá bản ghi thì điểm có tự tính lại không?	A-03
3	Operations và Management xem kết quả ở đâu?	A-07

9. Phân chia trách nhiệm

Hạng mục	Sotatek build	Stack Trading Ops	Bên thứ 3 tự chạy
Dựng survey trên Typeform (hidden field, 3 câu)	✅	✅ Hỗ trợ nội dung (đã gửi)	Typeform
Trang wrapper cho survey và chặn nộp lần 2 trong cùng chu kỳ	✅	—	—
Cron chọn mentee, webhook, ghi `last_survey_date`	✅	—	—
Template email `Template_Mentee_Survey` và link động	✅	✅ Copy (đã gửi)	Zapier
Nhận kết quả, lưu, tính điểm	✅	—	—
Sửa bản ghi chấm nhầm	—	✅ 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-FDBK-02…10`. Spec V7 bị QnA thay thế: kết quả survey đi thẳng Typeform → Middleware, không qua Zapier (`POD-FDBK-02`); đổi pod thì đếm lại chu kỳ theo `pod_join_date` (`POD-FDBK-09`). BA chốt 2026-10-12: Feedback Survey Gate của Flow 4 và Flow 7 là phần riêng, không trùng UC này.
2026-10-12	v1	Stage 2 bước 4 · BR_8.2.6.3 — kênh Slack điểm thấp	`#operations` (khách ghi), chờ chốt P-01	`#ops-general`	BA chốt: map kênh khách ghi sang kênh Slack hiện có trong CR-15.2 (khách ghi nhầm tên kênh).
2026-10-12	v1.1	Thêm mục API & Cron	Cron, webhook và kết quả survey chỉ được nhắc 1 dòng trong BR_8.2.6.4	Mục API & Cron: spec cron `Mentee Organic Survey Monitor` (điều kiện chọn, lỗi, chạy lại), webhook `SEND_MENTEE_SURVEY` (biến tối thiểu), Zap Flow 10.4, endpoint nhận kết quả survey từ Typeform (input, output, xử lý, lỗi, gọi trùng). Basic Flow trỏ tới từng API; BR_8.2.6.4 rút các dòng cron/webhook. Thêm Hạng mục mở #10 (A-08), #11 (A-09)	BA định nghĩa theo RFQ_ Stack Trading Prop Tech V7.pdf §4.4 #11, #19: mã lỗi `400`/`401`/`500`; status `Saved`/`Skipped`; trường `response_id` để nhận ra Typeform gửi lại; khoá dòng leader khi tính lại điểm; lưu lần nộp + cập nhật điểm cùng nhau; Slack lỗi không huỷ việc lưu; cron chỉ 1 phiên chạy cùng lúc, lỗi 1 mentee không dừng cả lượt; biến tối thiểu payload `SEND_MENTEE_SURVEY` suy từ email T-10. Điều kiện thời gian của cron theo câu chữ V7 ("> chu kỳ", so theo thời điểm đầy đủ).
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 API + input chính → kết quả; Stage 1 mở bằng tên cron `Mentee Organic Survey Monitor` + lịch 02:00 UTC; đặt tên endpoint nhận survey là endpoint nhận webhook survey (dùng thống nhất ở Basic Flow, API & Cron, BR_8.2.6.4); Stage 2 thêm nhánh `status = Skipped` và bước trả `status = Saved`; ghi rõ Stage 2 bước 2–4 chạy bên trong endpoint nhận webhook survey	—
2026-10-13	v1.3	Tên endpoint nhận survey	`Receive Mentee Survey` (tên tự đặt)	Webhook survey Typeform → Middleware — cách gọi theo `POD-FDBK-02`; nguồn không đặt tên endpoint	—
2026-10-13	v1.4	Dùng tên API gốc; bỏ tên tự đặt	Trường `mentee_email`, `mentee_name`, `leader_name`, `survey_link` (payload `SEND_MENTEE_SURVEY`); `response_id`, `q1_score`, `q2_responsiveness`, `q3_feedback`, `submitted_at`, `status` (input/output kết quả survey); status `Saved` / `Skipped`; tiêu đề "Zap Flow 10.4", "Webhook survey Typeform → Middleware", "endpoint nhận webhook survey"; "cron `Mentee Organic Survey Monitor`"	Mô tả nội dung bằng lời; tên do BE chốt trong OpenAPI spec. Tên gốc: Task `Mentee Organic Survey Monitor` (Daily @ 02:00 UTC), webhook `SEND_MENTEE_SURVEY`, Flow 10.4 Action 1, Flow 10.4 Action 2 (Async) — Typeform gửi kết quả survey tới Middleware (`POD-FDBK-02`)	Chỉ giữ tên có trong nguồn
2026-10-13	v1.5	Stage 2 bước 4 — bên gửi Slack điểm thấp	Ghi chắc chắn Middleware gửi	Bên gửi: Hạng mục mở #12 (A-10)	`POD-FDBK-05` (filter Zap) và `POD-FDBK-02` (không qua Zapier) chưa thống nhất
2026-10-13	v1.6	Chu kỳ survey · tên email	Chu kỳ "1 chu kỳ" (30 hay 60 chờ chốt); email `Mentee_Organic_Survey`	Chu kỳ 60 ngày cho cả thời gian ở pod và khoảng cách từ `last_survey_date`; email `Template_Mentee_Survey`	BA chốt 2026-10-13 theo client sheet Flow 10.4. Copy T-10 / Q1 còn ghi 30 ngày: Hạng mục mở #2
2026-10-14	v1.7	Toàn UC — viết lại theo khuôn UC_8.1.x	Có bảng "Giải thích thuật ngữ"; mục "Phạm vi"; Basic Flow trỏ sang spec qua "Ref: API_x"; BR_8.2.6.4 "Thông tin kỹ thuật cho dev"; mục riêng "API & Cron" liệt kê 4 API: API_8.2.6.1 Task `Mentee Organic Survey Monitor` (cron), API_8.2.6.2 `SEND_MENTEE_SURVEY`, API_8.2.6.3 Flow 10.4 Action 1 — gửi email `Template_Mentee_Survey` (Zap), API_8.2.6.4 Flow 10.4 Action 2 (Async) — Typeform gửi kết quả survey tới Middleware; "Hạng mục mở" đặt sau "Phân chia trách nhiệm"	Bỏ bảng thuật ngữ (giải thích ngay câu dùng lần đầu). Thứ tự: Scope · Overview · Trigger (kèm lịch cron 02:00 UTC) · Pre/Post-conditions · Basic Flow · Business Rules · Open Items · Phân chia trách nhiệm. Bỏ mục "API & Cron": điều kiện chọn mentee, chạy lại / chạy trùng, lỗi của cron → Stage 1 bước 1–3; payload `SEND_MENTEE_SURVEY` → bảng input tại Stage 1 bước 3; Zap Action 1 và lỗi Zap → Stage 1 bước 4; input, xử lý, mã lỗi `401`/`400`/`500`, gọi trùng của webhook kết quả survey → Stage 2 bước 1–6 dạng `[If …] →`. Còn 2 API đúng như nguồn: webhook `SEND_MENTEE_SURVEY` (Middleware → Zapier) và webhook kết quả survey Typeform → Middleware (Flow 10.4 Action 2 (Async)). Cron là trigger, Zap Action 1 gửi email và Slack là hành động trong bước — không đánh số API. BR_8.2.6.4 đổi tên "Lưu trữ, xác thực webhook và kênh Slack", nhận thêm quy định chung (HMAC/JWS, OpenAPI spec, CR-18, CR-08) từ mục API & Cron cũ	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 4 → 2 cho khớp nguồn: `SEND_MENTEE_SURVEY` là webhook theo RFQ_ Stack Trading Prop Tech V7.pdf §Background Mechanisms ("Fire the SEND_MENTEE_SURVEY webhook to Zapier") và Zapier Integration V7.pdf §Flow 10.4 Trigger; webhook kết quả survey Typeform → Node.js theo `POD-FDBK-02` (thay "route" qua Zapier của Zapier Integration V7.pdf §Flow 10.4 Action 2 (Async)).
2026-10-14	v1.8	Cron Job task tách khỏi API	Cron gọi là "Task `Mentee Organic Survey Monitor`"	Ghi rõ Cron Job task `Mentee Organic Survey Monitor`; Overview thêm dòng API (2 webhook) 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.9	BR_8.2.6.3 · Stage 2 bước 1–2 · Open Items	Q1 "over the last 30 days", nhãn thang điểm chưa có; Q2 `Highly Responsive` / `Moderately Responsive` / `Unresponsive`; Q3 "Please provide any specific feedback…"; Slack `Text Feedback: "[Text_Feedback]"`; Open Items #1 thang 1-5 hay 1-10 (C-02), #2 copy email và Q1 còn ghi 30 ngày (C-03)	Survey theo Form 4: Bi-Monthly Pod Performance Audit — Form Title, Welcome Screen, Ending Screen; Q1 "over the last 60 days", thang 1-10 nhãn `Absent/Ineffective` – `Exceptional/Transformative`; Q2 hỏi mentor có review journal và giữ mentee theo Trading Plan, 4 lựa chọn `Yes consistently`, `Occasionally`, `Rarely`, `Never`; Q3 mới (Optional). Kiểm tra input Q2 theo 4 giá trị. Slack bỏ ngoặc kép quanh `[Text_Feedback]`. Bỏ Open Item C-02 (thang 1-10); C-03 chỉ còn copy email "30-day Pod evaluation"; đánh số lại #2–#12 → #1–#11	Theo bảng template Stage 6 — POD system khách gửi. Hidden field giữ `mentee_id`, `leader_id` theo `POD-FDBK-03`
2026-10-22	v1.10	Stage 1 bước 5 · Stage 2 bước 1–3 · Open Items · Phân chia trách nhiệm	Mentee đã nộp không bị chặn; cùng một link nộp lần 2: Open Items #3	Mỗi chu kỳ 60 ngày chỉ nộp 1 lần: trang wrapper hiện `You have already submitted this`, Middleware bỏ qua lần 2 lọt qua (đã có lần nộp kể từ `last_survey_date`). Stage 2 thêm bước 1, các bước sau đánh số lại · Bỏ Open Items #3, đánh số lại #4–#11 → #3–#10	Khách trả lời 2026-10-22 (A-02), thay phần "không set cờ chặn" của `POD-FDBK-08`. A-02 đã chốt
2026-10-22	v1.11	Stage 1 bước 1–4 · Stage 2 bước 1–3 · Open Items	Mentee DTO / Hiatus, webhook lỗi, email lỗi, sửa `leader_id`, đổi pod, rời pod: Open Items · ghi `last_survey_date` ngay lúc gửi webhook · link survey gắn `mentee_id`, `leader_id`	DTO / Hiatus vẫn gửi · `last_survey_date` chỉ ghi khi Zapier trả `200 OK`; lỗi → không ghi, không thử lại trong lượt, cron hôm sau gửi lại · email lỗi → lỡ chu kỳ, chấp nhận · trang wrapper hiện `Form Expired` khi `pod_leader_id` rỗng / khác `leader_id` trên link / mentee Level 7 Alumni, Resigned, Terminated; Middleware drop lần nộp lọt qua · `mentee_id` lấy từ phiên đăng nhập (CHR-127) · Open Items còn 4 (đánh số lại)	Khách trả lời 2026-10-22: A-01, A-02 (xác nhận lại), A-04, A-05, A-06, A-08, A-09. Chặn thêm theo status Level 7 / Resigned / Terminated (danh sách `POD-FDBK-10`) — BA chốt
2026-10-22	v1.11	Basic Flow · Business Rules · Document References — kiểm tra chữ ký webhook	Bước kiểm tra chữ ký (HMAC/JWS), sai → `401` (RFQ V7 §4.4 #19)	Bỏ toàn bộ bước kiểm tra chữ ký và các dòng `401`	BA chốt 2026-10-22: yêu cầu bảo mật chung, khách không nói riêng cho flow này
2026-10-22	v1.11	Stage 1 bước 2, 3, 4, 5 · Stage 2 bước 1, 2, 3, 6	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.11	Post-conditions · Stage 1 bước 1, 2, 3, 4, 5 · Stage 2 bước 1, 2, 3, 4, 5, 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.11	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.11	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.12	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 "các điểm khác nguồn"; edge case và nhánh `[If …]` nằm dưới từng bước; BR_8.2.6.1, BR_8.2.6.2, BR_8.2.6.4 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 nguồn" (chu kỳ 60 ngày và kết quả đi thẳng tới Middleware ghi thành câu khẳng định ở §5.1, §5.3). Mục đánh số 1 đến 9; §5 chia 5.1 cron chọn mentee và gửi survey, 5.2 Zapier gửi email, 5.3 mentee làm survey; bước đánh số liên tục 1 đến 17. Edge case gom vào bảng §6 (E_8.2.6.1 đến E_8.2.6.16). BR gom vào bảng §7, nội dung survey và tin nhắn ở §7.1. Mọi BR đều được refer từ bước hoặc exception liên quan. Mã QnA chỉ giữ ở Document References, Open Items và Changelog. Giữ nguyên anchor `BR_8.2.6.1` đến `BR_8.2.6.4`; 4 Open Items giữ nguyên	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.12	§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.13	Frontmatter, §1 Description, 3rd Party · §4 Post-conditions · §5.3 Stage 6 bước 16 · §6 E_8.2.6.11, E_8.2.6.13, E_8.2.6.16 · BR_8.2.6.1 · §7.1 (Q2, tin Slack) · §8 Open Items #4 · §9 RACI	Q1 từ 6 điểm trở xuống thì gửi tin Slack vào `#ops-general` cho Operations xem xét; có E_8.2.6.16 (Slack lỗi), mẫu tin Slack, Open Item #4 (A-10: ai gửi Slack)	Bỏ toàn bộ phần báo điểm thấp: hệ thống chỉ lưu survey và tính điểm trung bình, không kiểm tra điểm thấp, không gửi Slack. Bỏ Stage 6, E_8.2.6.16, mẫu tin Slack, Open Item #4; Q2 chỉ lưu cùng survey; bước trả `200 OK` đánh lại số 16	Báo điểm thấp cho Ops là CR, khách không approve. BA chốt 2026-10-29
2026-10-29	v1.13	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